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.
Incorrect. They could be applications that were built well before the
issuing of RFC 2822, were following STD11 and thus completely in spec.
It's hardly asking very much to expect IETF specs to be liberal in what
they receive when it comes to previous full standards with 25 years of
legacy.
I have never come across an application that depended on naked CR or LF
being passed through SMTP. I've seen lots and lots of of naked CR and LF
(particularly since I've been using an MTA that spits them back since
about 1999) and without exception they are due to bugs. If anyone is
aware of deliberate naked CR or LF, I would sure like to hear about it,
and how they deal with the large fraction of mail relays that silently
discard them or stuff the missing LF or CR.
What's the benefit of being backward compatible with buggy behavior that
nobody depends on?
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html