In our testing at Cisco, we are seeing a small but
significant number of failure mainly due to various system
bots that send naked CR's in a message. What I have found
is that at the very least, sendmail and Ironport handle
these two cases differently. Thus for the input:
testing 1\n
\r
\r
2 3\r
\r\n
.\r\n
sendmail yields:
testing 1\r\n
\r
\r
2 3\r
\r\n
.\r\n
Ironport yields:
testing 1\r\n
\r\n
\r\n
2 3\r\n
\r\n
.\r\n
Ie, both Ironport and Sendmail are doing CR stuffing for
naked LF's. However, for Ironport it's always doing LF
stuffing for naked CR's in the input stream. I suspect
that sendmail's behavior is right, but that's not really
what is at issue here.
First my suspicion is that this kind of confusion is not
uncommon in the wild. We've already found out that it's
pretty common, especially with mailbot's in our own
organization. Nor do I doubt that Ironport is an outlyer
here -- I'd guess that this is a common transformation.
Here's my suggestion: we fix this by modifying the relaxed
body canonicalization such that any lone CR or LF is
*always* canonicalized as CRLF.
Please, please -- if people know about other wrinkles to
this let's get them out in the open now. As it stands,
simple body canonicalization fails some pretty common cases.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html