Tony Hansen wrote:
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.
I must be missing something. The 821 input string of:
a b</body></html>CRLF
.
CRLF
already contains the final CRLF of the body, so there wouldn't be a
situation
where you'd ever see an input string of the form: a b</body></html> (no
crlf),
right? Or are you saying that's the case for DATA, but maybe not BDAT?
Mike
Tony Hansen
tony(_at_)att(_dot_)com
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