[ietf-dkim] NEW ISSUE: NAKED CR & LF issues with body canonicalization

[John L]

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