<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
Mail to <postmaster> at this host is still supposed to work.
Say what? That's only the case if the host runs an SMTP server,
in which case it is entirely logical to require support of a
postmaster address. It is entirely possible for a host to have
an SMTP client and no server.
For pure clients I'd look into RFC 4409, 4954, and 5068.
4409: Submission. Irrelevant in the context of the relay operations we're
discussing.
4954: SMTP AUTH. Although defined for relay as well as submit, irrelevant in
practice.
5068: Submission requirements. Also irrelevant.
When the server in question is sure that it's not talking with one
of its own users and acting as MSA, where clients might have
funny names like "oemcomputer" or "xyzzy.invalid", an MX could
assume that an unknown stranger talking to it is an SMTP relay.
We're not talking about MSAs or submission operations here.
And for SMTP relays 2821bis 4.5.1 says "postmaster MUST work".
Actually, it says nothing of the sort. The text is very clear: It says that
SMTP *receivers* must have a postmaster address. It says *nothing* about SMTP
clients always having to operate a receiver or having to have postmaster
address. Furthermore, it says that the bare local name "postmaster" is what has
to work. It says *nothing* about postmaster(_at_)random-host-system-name having
to
work.
I think your problem here is you're conflating hosts with administrative
domainss. For small setups all transport and storage services often run on a
single host so they may be effectively the same thing. But this isn't how
things work in larger setups. Architectures change once you start talking about
handling millions of users, transfer rates in the thousands of messages a
second, hundreds of thousands of simultaneous connections, and multiple network
connections with different performance and traffic shaping policies.
It is very common in large multihost deployments to have specific hosts
dedicated to specific tasks: Incoming relay from the Internet, outbound relay
to the Internet, submission from local users, spam filtering, virus detection,
message storage, download points, and so on. (One of the main reasons for this
is that the hardware requirements for an MTA tend to be quite different from
those for a store. MTAs are well-suited to rack-and-stack so a bunch of blades
are often used whereas stores are I/O-heavy and usually end up on a smaller set
of much bigger boxes with lots of disks.)
And in many cases messages travel internally using heavily extended or even
entirely nonstandard protocols and mechanisms. As a result it is entirely
possible for a given host in such a setup to engage in relay operations but
only support a client, a server, neither, or both. And even if, say, an
outbound relay host also operates an SMTP server, in many setups it will not
accept incoming connections from the Internet - it's instead reserved for
messages coming from "inside".
And all this still ignores issues like network performance, multihoming,
failover and clustering, and having multiple zones on a single physical box. We
have an entire deployment engineering team that does nothing but design such
setups. These folks are intimately familiar with the performance of the various
hardware boxes, filesystems, disks, interconnects, and heaven knows what else.
(I myself am woefully ignorant of almost all of these details, but I've seen
first hand the difference between a well-designed and poorly-designed large
scale setup.)
2821bis 4.1.1.3 does not help to decide if the other side is a
client or relay. In the <tm> real SMTP </tm> that might have
been obvious in the reverse-path, more than one hop is a relay.
postmaster is only required for servers that perform delivery
or relay functions. I presume that's so a stub server that
always returns 5xy errors isn't required to accept postmaster
mail.
That point is explicitly mentioned in 4.5.1, yes. It is kind
of obvious that MTAs always saying 554 instead of 220 cannot
accept mail to <postmaster>, nevertheless 2821bis mentions it.
But once again it is quite clearly talking about a server's implementation
of the RCPT TO command.
But for an MX tormented by a client out of control a mail to
<postmaster> asking to fix whatever is broken can make sense,
if just blocking this client doesn't help or is undesirable.
OK... Assuming there's something who actually reads postmaster mail
(increasingly unlikely, more's the pity), sending something directly to the
postmaster address to the server that is coresident with the misbehaving cliwnt
might be worth a try in such a situation. But there's no standards violation to
complain about if it doesn't work. And in most cases a better idea would be to
send to the postmaster address associated with the domain listed in the MAIL
FROM address.
I couldn't tell without cheating (= looking into 2821bis)
if that's MUSTard, SHOULD, or between the lines.
Well, now you forced me to check it.
If you believe otherwise you'll need to cite the relevant
sections of 2821bis to support your point. I couldn't find
anything along the lines of what you appear to be claiming
in there.
From the POV of an MX talking to a client that definitely is
not "one of ours", i.e. an unknown stranger, and that does
not use RFC 821 reverse-paths, assuming that "direct-to-MX"
is bad, it can be only a relay, and for relays it's a MUST.
No it isn't. See above.
Please don't tell me that this assumption is unjustified,
I'm afraid I don't have a choice. The requirements you appear to be advocating
are unjustified and unworkable in practice. If you're thinking about proposing
a language change saying that all systems engaged in SMTP client activities
MUST or even SHOULD also have an acessible server to accept problem reports,
that's simply not going to happen.
Ned