Re: Comments on Malformed Message BCP draft

> Dave Cridland <[email protected]> wrote:
> >
> > It may be that the discussion suggests rejecting, in which case I suggest the
> > document should clearly explain why, and what the implications of not doing so
> > are, beyond "it makes some problems harder to diagnose".

> It does not make sense to have a uniform policy for dealing with corrupt
> messages. Some kinds of corruption are caused by common legitimate
> software, in which case you will want to treat it leniently; others are
> caused by malware or rare kinds of incompetence, in which case it makes
> more sense to reject. You can only determine which is which based on
> operational experience, and the least-worst response changes from time to
> time.

Bingo. This is precisely the concern I have with this effort - the IETF
consensus process operates in a time scale that will make it very difficult to
capture a sensible set of recommendations in a specification. And even if we do
manage to capture something useful, it will need to be updated regularly to
remain useful. Are we prepared to do that?

And it isn't a binary choice between rejection and fixup either. What sort of
fixup makes sense can change over time.

Consider the invalid header line case. There was a period a few years ago
when it seemed like half the email agents out there couldn't consistently
fold header lines. As a result the strategy of accepting such messages
and not terminating the header seemed to work best.

But as this issue was starting to disappear, a new one, where some group of
agents decided that the blank line between the header and body was  superfluous
and could be omitted, started to show up. A strategy of treating an invalid
header line as a stopping point works best in this case. But who's to say
what's going to happen next month?

This sort of behavior shifting over time is especially prevalent in certain
problem areas like CJK charset usage and labeling.

Another aspect to this that hasn't been discussed yet is where some
agent can only tolerate a subset of what the standards allow. Is it OK
to reformat messages to avoid using legitimate but neverthless problematic
features?

My personal favorite of these was the one where, several years back, a very
popular product refused to accept MIME messages where the 
content-tranfer-encoding field appeared prior to the content-type in the
message header.

				Ned