--On December 15, 2006 10:17:16 AM -0800 Mark Delany
<markd+dkim(_at_)yahoo-inc(_dot_)com> wrote:
FWIW, this problem was similarly discovered in DK. The early text
read:
-01
o All trailing empty lines are ignored. An empty line is a line
of
zero length after removal of the local line terminator. The
empty line that separates the header from the body is a to be
included in this process.
and the later text read:
-06
o All trailing empty lines are ignored. An empty line is a
line of
zero length after removal of the local line terminator.
If the body consists entirely of empty lines, then the
header/body line is similarly ignored.
In short, if the last empty line of the email is the header/body
separator, then it should not be fed into the canonicalization.
The "simple" in DKIM, as I understand it, is merely re-codifying the
same function.
I *think* there are three cases here:
(1) Some body with l=0. I think we're agreed that this should result
in an empty input into the hash algorithm.
(2) Header, CRLF, no body; that is, the input to a DATA would be:
Header: foobar<CRLF>
<CRLF>
<CRLF>.<CRLF>
The last line of the example is the separator, so the initial CRLF
doesn't count.
(3) Header, no CRLF, no body:
Header: foobar<CRLF>
<CRLF>.<CRLF>
It seems to me that all three of these should match after
canonicalization. I'm not sure the -07 draft is explicit enough to
ensure this.
In short, I'm not sure we have guarantied DK compatibility based on
the current wording, regardless of intent.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html