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
