Charles Lindsey wrote:
>
> No, I don't think that is what Tony was claiming the majority of
> implementations did (I think it is what the current wording says to do,
> but I think Tony was saying all those should result in an empty body to
> be hashed).
>
> Anyway, here is some wording:
>
> The "simple" body canonicalization removes empty lines from the end
> of the body until either the last line is non-empty, or no lines
> remain. An empty line is a line of zero length after removal of any
> terminating CRLF. If the body is not now empty and the last line is
> not already terminated by CRLF, a CRLF is added to it.
>
> INFORMATIVE NOTE: Following [RFC 2822}, the CRLF which separates the
> header fields from the body is NOT part of the body, and therefore is
> never presented to the signing or verification algorithm. In the case
> of a pure binary message (such as one with a
> Content-Transfer-Encoding of 'binary') the concept of "lines" may not
> be meaningful. Nevertheless,
> wherever the pair of octets that represent CRLF happens to occur,
> that is to be considered as the end of a "line" for the purposes
> of this canonicalization algorithm.
>
> Now, you are all invited to find some way of misinterpreting that :-).
I can live with the above.
I was going to suggest ABNF, but that's where we got into trouble last
time. :-) If we *were* to add ABNF to the above, it would have to have
two cases.
> Next, for body length counts which, as I now see from 3.4.5, are to be
> applied _after_ canonicalization. (BTW, I misinterpreted those counts as
> line counts rather than byte counts in an earlier message).
>
> Here is another example to amuse you:
>
> Last-header: foobarCRLF
> CRLF
> ----------------
> 12345678CRLF
> 12345678CRLF
> 12345678
> ----------------
>
> Now sign that with l=29 :-)
> (don't forget to add the CRLF to the last line first)
The text on when l= counts should be applied hasn't changed meaning,
thankfully. It's very specific: it's an octet count applied after
canonicalization.
Canonicalization produces:
----------------
12345678CRLF
12345678CRLF
12345678CRLF
----------------
and l=29 produces:
----------------
12345678CRLF
12345678CRLF
12345678CR
----------------
Tony Hansen
[EMAIL PROTECTED]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
