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

Douglas Otis <[email protected]> Mon, 18 Apr 2011 15:56:08 -0700
Newsgroups gmane.ietf.rfc822,gmane.ietf.apps-discuss
Message-ID <[email protected]>
On 4/18/11 5:48 AM, 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.
Fully Agree.

-Doug