ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] canonicalized null body and dkim

2006-12-15 09:09:32
Tony Hansen wrote:
Mike Thomas and I have been having a conversation about how empty
message bodies should be canonicalized.

Go and reread section 3.4.3. There is text in there that was added to
handle the case of a message body that has been transmitted using
CHUNKING and doesn't have a CRLF at the end of its last line. It
specifies that a missing CRLF must be added to the last line before
passing it to the canonicalizer.

Prior to adding this text, I think that an empty message body would be
canonicalized into an empty input into the canonicalizer. However, a
careful reading of the text in section 3.4.3 indicates that it *would*
have the side affect of adding a CRLF to an empty body as well.

Personally, I think this is an incorrect side affect, and an empty body
should have an empty canonicalization. Several implementations already
canonicalize an empty body into an empty string.

Note that l=0 should still mean that the final potentially virtual CRLF would
not be added to the hash. I'm not proposing that as a solution, just an
observation.

The thing that I've seen is that at the very least sendmail will strip a body
with a single CRLF to a null body in its output stage; I would not be
surprised to hear that other MTA's do similar transformations. For something
either like a milter or something simply upstream of those mungers, the
net effect is that the way the current spec is written, they will still pass
verification. If we change that, they will not. That to me is a good reason
to keep it the way it currently reads, but add an implementation note to
the effect.

Just to be clear: this is a fairly common edge situation -- all one has to
do to reproduce this is to type a subject line in Thunderbird with no
body and it will produce a message body with a single CRLF. Other
MUA's may well make the same mistake, and at Cisco we're seeing
about 5k or so of those kinds of messages a day.

      Mike
I know we've hit and passed LC, but I think this issue needs a
clarification, one way or another way, before we go to RFC status.

I'd like to see either one of these two statements added to the end of
section 3.4.3:

   a)   As a limiting case, an empty message body would be canonicalized
into a single CRLF pair.

   b)   An empty message body should be canonicalized into an empty string.

        Tony Hansen
        tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html