In the months since we went live with probably hundreds of millions
of messages passing through our signers/verifiers, this is the only thing
that I've seen with any consistency that breaks the body with simple.
Right. So fix the message, then sign it, thereby making the message and
signature robust regardless of what MTAs it may later pass through. Is
there some reason this wouldn't work? Does something downstream depend on
getting naked CRs in the message?
My strong suggestion is to say that if you want your DKIM signatures
to interoperate, you should only sign compliant mail.
That's completely unhelpful.
Just in case you missed it the last three times I said this: make the
message compliant, then sign it.
I suppose I can sort of imagine hypothetical situations where two hosts
would be passing messages back and forth that require naked CR or LF, but
that's a private network, not SMTP. I am utterly unable to imagine why an
IETF standard should require DKIM to handle such messages when we all know
that the only reason they happen is software bugs, and it's already common
practice to fix them up at a relay.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html