Re: [apps-discuss] Comments on Malformed Message BCP draft

John C Klensin wrote:
> 
> 
> --On Monday, April 18, 2011 13:19 +0100 Tony Finch
> <[email protected]> wrote:
> 
>> Murray S. Kucherawy <[email protected]> wrote:
>>> I don't think this work is targeted at intermediaries.  In
>>> fact, I'd be completely fine with expressly saying it's meant
>>> to address processing at ingress MTAs only.
>> If you are going to make that kind of restriction, it should
>> happen at submission servers only.
>>
>> There is a history of MX servers making "helpful" fix-ups to
>> messgaes (e.g. inserting missing message-id or from headers)
>> before handing them over to anti-spam software, which can make
>> spam/legit checks invalid in both the positive and negative
>> senses. So I think MXs should be as transparent as possible so
>> that downstream security software is less likely to have
>> interop problems. Intermediate relays should also be as
>> transparent as possible.
> 
> Of course, this is exactly what RFCs 4409, 5068, and 5321 say:
> considerable flexibility for making fixes for the submission
> server, which is presumably under the control of (or at least
> responsible to) the sender; relays don't mess with message
> contents until they get to the delivery server.  Various
> operational considerations have modified that somewhat but, if
> this specification doesn't apply to intermediaries, it changes
> nothing except, as Eric Burger points out, the practical
> definition of well-formed messages.
> 
> IMO, if we want to do that (and I'd personally not favor it), we
> should do so in some 5322bis, not try to sneak the changes in
> via a BCP that is inconsistent with 5322.

+1

You can see one common issue the malformed message I-D shows as an 
example with the field-name having a space:

    "field-name :"

This would be akin to the SMTP space syntax debates, with the example:

    Mail From:space<address>

Recognizing this long time issue, this note was added to RC5322 
(Section 3.3)

    Since it has been a common source of errors, it is worth noting that
    spaces are not permitted on either side of the colon following FROM
    in the MAIL command or TO in the RCPT command.  The syntax is exactly
    as given above.

Implementators are going to decide on whether they will accept the 
illegal form with the space all depending on the severity of 
frequency.  In the past, the #1 MUA was the offending problem so while 
we didn't encourage relaxation, it had to be noted.

IMO, I don't think this a similar consideration applies to similar 
5322 header syntax errors.  It was reasonable to see why the SMTP 
systems had to consider relaxing it due to a wide world major 
deployment of the offending software.   We don't have that here with 
RFC 5322 headers, do we?

-- 
HLS