>> 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 know of only one counterexample. It is possible to write PostScript that
depends on line termination characters not changing from one character to two
or vice versa. (The specific underlying technical issue is that there's an
operator in the language that takes a counted sequence of characters, possibly
containing line breaks, as an argument and if you change the length around
you'll desynchronize the reading process. I forget the specific operator but I
can look it up if anyone cares.)
Now, if such PostScript is sent unencoded (as is sometimes the case -
PostScript looks textual so people figure they can get away with handling it as
text), you now have a situation where changing those bare CRs and LFs to CRLFs
effectively destroys the content. Of course anyone who sends unencoded
PostScript around is asking for trouble, since there are plenty of other things
you can do with PostScript content that don't conform to either 7bit or 8bit
text restrictions (overly long lines, binary content, etc.).
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.
I haven't seen this problem in well over five years so I suspect that the
systems that did it are long gone. (The sorts of PostScript that get generated
have also changed dramatically over time.) Our solution to the problem at the
time was to write a PostScript fixer-upper utility that dealt with this and
several other corruption issues. (There are a bunch that are far more common
than this one.)
What's the benefit of being backward compatible with buggy behavior that
nobody depends on?
Very little, I believe. I will also point out that while RFC 821/822 don't
prohibit the use of bare CR and LF in messages, they are somewhat
self-contradictory in specifying their handling. For one thing, section 3.1.2
of RFC 822 in effect bans the use of bare CR and LF in header field bodies, but
the ABNF for some header fields allows them (via the "text" production). And
while bare CR and bare LF are allowed in messages bodies and presumably are
distinct from CRLF line breaks, section 3.4.10 of RFC 822 makes it clear that
converting messages to and from local line termination conventions is OK even
when those conventions will have the effect of causing those bare LFs, CRs, or
both to be converted to CRLFs.
It is therefore a stretch to believe that there was this happy world of systems
merrily exchanging messages containing mixtures of line terminators with nary a
problem, foot loose and fancy free, up until big nasty old RFC 2821/2822 came
along and told them they had to stop. The fact is that bare CRs and LFs have
never interoperated worth spit and that's the reason why RFC 2821/2822 banned
their use. it's one thing to remove something from the allowed set when things
have worked well, quite another when things worked poorly.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html