Adding l= into the mix makes no change to any of the arguments, as the
l= length is done off of the canonicalized form of the body. That is,
you conceptually canonicalize first, and then use the l= bytes from that
canonicalized form.
That is, for a body of "a b</body></html>", if this were canonicalized
to either "a b</body></html>" or "a b</body></html>CRLF", applying l=3
to that still reduces the body to "a b".
After posting the message below, I was convinced by the other arguments
that the *canonicalized* form of the message should always end with a
final CRLF. If you buy the argument that there are MTAs out there that
will potentially add extraneous CRLFs to a message, then the verifier
cannot differentiate between a message that has a CRLF on its last line
and one that didn't start that way and had one added by an MTA. So the
verifier *must* assume that that last CRLF is a valid part of the
message. Subsequently, this means that the signer must guarantee that
the canonicalized form of the body ends in a CRLF.
And I've changed my code accordingly to guarantee that the last line of
the body *does* have a CRLF after canonicalization.
Tony Hansen
[EMAIL PROTECTED]
Michael Thomas wrote:
> Tony Hansen wrote:
>
>> This not a problem when using DATA. Check 2821 section 4.1.1.4; the
>> ending crlf.crlf was clarified as being the trailing crlf of the last
>> line of the message followed by the terminator sequence.
>>
>> Note that the first <CRLF> of this terminating sequence is also the
>> <CRLF> that ends the final line of the data (message text) or, if
>> there was no data, ends the DATA command itself.
>>
>> You are correct that the problem exists when using BDAT.
>>
>> My implementation uses the last CRLF in if it's there. If there is no
>> last CRLF, it does *not* add one.
>>
>>
>>
> Having just worked through this myself, I'll say that Tony's interpretation
> *has* to be the correct one otherwise an l= less than the body length won't
> be correct. Namely:
>
> "a b</body></html>" where l=3 is: "a b" not "a b<crlf>" or any other
> weird interpretation. This is definitely worth a mention in the draft.
>
> Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
