Alessandro Vesely wrote:
3) For text parts, completely remove /any/ whitespace. Additionally,
remove most punctuation, especially from begin and end of lines.
Do we really need this? Do you know of cases related to this?
The idea is to anticipate any unknown signature breaker. My three
points above are rather generic. They are meant to be expanded so as
to include your five points below, and more.
I think it is quite obvious that MIME rewriting generates new
boundaries, and may alter an entity's header.
Non-text binary content that arrives corrupted deserves breaking a
signature. However, a rewriter may decode a base64 entity for local
storage, and then re-encode it with a different line length.
Text undergoes any kind of massage, trailing "=" may be leftover,
CRLFs may be doubled, "From " turned into ">From ", besides the
leading dots you mention in point five.
Why not just DKIM Signer ALWAYS base64 a MIME message/rfc822, sign it
and thats it? :)
4 - Lines over 998 (1000 with CRLF), this is an invalid RFC5322, but
its possible some verifiers are designed to do a buffered C14N
and don't check for RFC5322 line lengths between two memory points
in the buffer as oppose as a line by line feed into the C14N
function. Why buffer vs line? speed.
I imagined the C14N function reads characters one by one. On finding
CRLF it can go back a few bytes to remove end-of-line punctuation.
However you code c14n(), it will be sparklingly faster than sha256().
The code can be written to do the C14N first, then do a time hash
call, or you can do it on the fly C14N/HASH. I use memory file maps
to deal any potential large mail and the line parsing doesn't hurt speed.
and I just found a yet another problem which I was currently
investigating to see where it this "mite" is occurring:
5 - Incorrect handling of lines beginning with dots, for example
I sent a message containing a line beginning with:
Yes, dot is one of the punctuation characters that should be removed.
This turned out to be a bug in our beta code, revamped to support I/O
completion ports and the code for undotting of the leading dot (per
RFC5321 4.5.2) fell thru the crack. So we can nix this one. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html