To work around broken mailers? I think not.
Sendmail is broken? RFC 822 is "broken"?
Actually, oftenso, yes.
My main point is that all of these issues are out of scope. Let your
MTA best decide how to deal with non-standard SMTP and presume that it
will present standard rfc2822 to a verifier.
The same applies for signing. I can cite any amount of broken submit
code - largely because most of it is passthru rather than verify - but
as signers and verifiers our mechanism should assume legitimate input.
In short, this is a layering issue and DKIM does not deal at the
transport layer.
Apropos your concern, I would suggest that at best we *might* want to
give some BCP on how non-standard streams should be dealt with by MTAs
and SUBMITs prior to presentation for verification and signing,
respectively. But that's about it. We definitely do not want to get
into compensating for transport layer bugs. After all, what happens
when we we use this for SIP or HTTPS or ... do we want to embed support
for their peccadilloes as well?
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html