Re: Multiple instances of a header field

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Fri, 8 Jun 2012 17:10:36 -0700 (PDT)

(dropping opendkim-users)

On Fri, 8 Jun 2012, Ken Murchison wrote:
> Does libopendkim properly handle multiple instances of a header field per
> section 5.4.2 of RFC 6376 (where they are supposed to be hashed in
> last-to-first order)?

It does.

> My reading of the code leads me to believe that they are hashed in the
> order that they are added with dkim_header(). If so, then the
> dkim_chunk() interface is broken since it will process multiple
> instances first-to-last.

What code are you reading? The order reversal occurs in
dkim_canon_selecthdrs() in libopendkim/dkim-canon.c.

> Would it not make sense to have dkim_header() reverse the order of the
> headers as they are added (add headers to the head of the internal
> header list, rather than the tail)?

dkim_header() causes the headers to be stored in order. This is
convenient for debugging, for example, because examining the data
structures shows the order in which they were handed to the library.

> Of course, if we make this change, any existing applications that
> already call dkim_header() in last-to-first order will be broken.
>
> Thoughts?

Much of the API (not including dkim_chunk()) mirrors the milter API, since
they have a common genesis. The header callback in milter is called as
header fields are identified by the MTA, so it's expected that
dkim_header() will receive them in the order in which they were presented.
It's therefore up to the library to reverse them when canonicalizing the
header. So yes, altering that implicit handling would mess with a lot of
things.

-MSK
Received on Sat Jun 09 2012 - 00:10:56 PST