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