Re: Comments on Malformed Message BCP draft

John C Klensin <[email protected]>
Newsgroups gmane.ietf.apps-discuss,gmane.ietf.rfc822
Message-ID <[email protected]>

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

    john
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.