ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Clarification on z=

2006-06-12 06:02:12
--On June 10, 2006 2:53:06 PM -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com> wrote:
Arvel Hathcock wrote:

How are multi-line header field values to be handled with z=?  Do
we  encode the fold (by adding =0D=0A for example) or do we unfold
the  header field value first and then add that result to z=?  Is
preserving the fold important at all?

Another interesting question looking at your headers is that you
include the leading space of the header while I don't (due to that
artifact of milters). I'd say that you're probably right given my
previous message.

Eric, what do you think?

I had intended that the format be unambiguous, so that all white space (which should be SWSP) is encoded. Given the current ABNF, this means that the only folding permitted would be before a "|" or after a ":", which may not be what we want.

I think it's a bad idea to allow white space (including CRLF) to mean literal white space, since one of the things we are probably trying to preserve in z= is the original white space and folding of the original header fields. So it seems that requiring all SWSP to be encoded and then allowing perhaps arbitrary addition of real SWSP simply to keep down line lengths may be the right thing to do.

Much of this violates RFC 2045 section 6.7, notably points (4) and (5). Point (5) (soft line breaks) is especially problematic since they are indicated by "=CRLF" in 2045, but header folding requires at least one white space after the CRLF.

This clearly needs to be fixed up --- it is definitely ambiguous now. My suggestion is to require that all SWSP in the original header be encoded, and all physical SWSP in the z= tag (specifically, qp-hdr-value in the ABNF) be ignored.

eric
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html