[ietf-dkim] Possible problem with "simple" body canonicalization -- trailing CRLFs

[Eric Allman]

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.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.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).
>