> >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
