ietf
[Top] [All Lists]

Re: We need an architecture, not finger pointing.

2015-10-28 17:18:49
On Wed, Oct 28, 2015 at 04:36:29PM -0400, John C Klensin wrote:

[ I've been co-maintaining a widely used MTA (one that for example
delivers all ietf.org list mail) for ~15 years now and was postmaster
for ~60k users for 10 of those years. Any apparent ignorance of
the architecture, specifications and current practice of SMTP on
my part is a failure to communicate, rather than a lack of competence.
I am also quite aware of your history in this space and have no
material disagreement with you on substance.  We differ on style. ]

You're clearly sending mail to poorly operated systems, likely
to systems where the attachments are rejected somewhere other
than at the edge MX host.  Such systems should not be
rejecting the attachments, it is too late for that, once it
crossed the line from "outbound" to "inbound".  The systems in
question need to apply their attachment policy closer to the
"edge", i.e. at the first inbound hop.

If you are describing what you consider good practice, then
fine.  

Yes.  Of course a best practice, but over time as standards age,
they need to be supplemented with a decent dose of BCP.

And please don't talk about "edge MX host" when you probably
mean "final delivery MTA" or equivalent.

No, I mean the "edge MX host".  Or whatever you might call the
first machine on the forward path that is accepting inbound mail
rather than sending outbound mail.

They are different and
the spec very deliberately allows some cases that "edge MX host"
probably doesn't cover.

I am well aware of the distinctions, and chose my words with care,
though in this case not a standard term of art.

Postfix has header/body checks that reject based on content,
and supports milters and proxy filter that can do the job out
of process. The reply for bad content in Postfix defaults to
"550 5.7.1 message content rejected".

Good for Postfix.  The last I heard, it was not the standard.

See BCP comment above.

Systems where content inspection happens after mail is queued,
and unwanted content triggers bounces are misconfigured.

Thank you for your opinion.    While I also generally prefer to
have them configured some other way when that is feasible,
"misconfigured" goes too far.

Yes, this explicitly goes much farther than justified by standards,
but in practice backscatter-generating systems are problematic in
a world where a lot of the mail they reject has a forged return
path.

Therefore, in practice on today's Internet, (IMNSHO, and representing
apparent consensus in at least the Postfix community) the only
right thing to do is to not generate backscatter (especially when
the content is suspect).

As a particular example, it is often desirable to configure one or more
lower-preference MTA to collect mail traffic when the preferred delivery
server is not available.

Yes, backup MX hosts are a prime source of backscatter when operated
by third-parties with different content inspection policies than
the destination domain.  They've mostly outlived their usefulness.
I advise Postfix users to avoid arms-length backup MX services.

But we digress.  The message I responded to claims that backscatter
is the norm, and that it can be eliminated.  Both are wrong.
Backscatter is no longer the norm, but (agreeing with you) it cannot
always be eliminated, rather we can make it increasingly rare with
"proper" configuration.


MUAs are a very different issue.  The MSA should generally
accept and bounce back to the authenticated user, this is
fine, because the MSA authenticates the client.  MUAs are
often not able to deal with rejection at submission time,
especially rejection for a subset of the recipients.  Nor is
it possible for the MSA to synchronously report remote rejects
from (some subset of) the receiving domains.

Some of that may be an argument for MUA using proprietary and/or
out-of-band means, rather than slightly modified SMTP, to
communicate with the submission server.  But that has been
allowed since the beginning of SMTP and was normal practice for
many years.    But expecting such rejections to always be
detected and reported in real time requires that the submission
server attempt mail delivery when the MUA connection to it is
still open _and_ that it be able to make a direct connection to
the final delivery MTA and do on its first attempt.  See Dave
Crocker's notes about those assumptions.

I agree, those assumptions are unreasonable.

-- 
        Viktor.