ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-base-08 submitted

2007-01-22 13:59:48
Eric Allman wrote:
The revised wording achieves what it was intended to achieve,
namely that  an empty/absent <body> result in a single <CRLF> to be
hashed.

What is not clear is WHY this alternative was chosen (as opposed to
letting it result in an empty <body>).

I could easily envision a situation where a completely empty body got sent via BDAT to an intermediate MTA that had to convert it to DATA format for retransmission. It wasn't hard to make a guess that some such MTAs might a CRLF before the final dot. It's not likely, but possible, and canonicalizing in this way prevents that problem.

Other than that it's an arbitrary choice. It was always my intent that it be included, and the ABNF was clear that it should be included, so that seemed to be the right way to go.

Regardless of how the message became "empty" either by BDAT or some other side-line "mail creator" that puts the new outbound mail into a DKIM signing queue, or whatever, I think it is very significant to sign the DKIM based empty body simply to let the world known that it is empty indeed, regardless of how it got that way.

I personally can see many reasons why a message would be empty from an application standpoint, e.g.; "Mail to Cell" messages where the subject line is used for text, no body required, Mail Events, Notifications or even LIST SERVER commands based on subject text, etc. Although the general rule of thumb is to throw in some tear line, there are many reasons why a message could be "empty."

---
HLS




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