Great! Thanks for the pointer. So it's not a problem with DATA.
Do we want to worry about the BDAT case? My suggestion would work
for that (but break your implementation).
It also occurs to me that there is an assumption in DKIM (and
probably a lot of other specs) that the mail body is text. It
doesn't have to be if you use BODY=BINARYMIME [RFC3030]. Is this
worth considering? It seems like it would either require redefining
simple body canonicalization if you have a BINARYMIME message, or
defining a new canonicalization ("binary"?) that allows absolutely no
changes. Of course, a new canonicalization can be added later.
eric
--On July 13, 2006 10:12:29 AM -0400 Tony Hansen <tony(_at_)att(_dot_)com>
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.
Tony Hansen
tony(_at_)att(_dot_)com
Eric Allman wrote:
In doing an end-to-end read on -base this morning I came up with a
possible difficulty with simple body canonicalization.
The description says that simple reduces CRLF 0*CRLF at the end of
a message to a single CRLF. But what if the message has no
trailing CRLF at all?
Remember that in the sequence CRLF . CRLF, both CRLFs are part of
the terminator, not part of the message. Thus, a message reading:
thanks <CRLF>
. <CRLF>
in fact has no trailing CRLF on the message. (This could also
happen with BDAT, but that's not widely implemented.)
An approach to this might be to say that simple reduces 0*CRLF to a
single CRLF (which is quite possibly what the current
implementations actually do).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html