<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
For pure clients I'd look into RFC 4409, 4954, and 5068.
4409: Submission. Irrelevant
[...]
If you consider "direct-to-MX" as perfectly okay it is
unlikely that we find a model where the MUST in 2821bis
for <postmaster> makes sense from an MX-POV:
If the "unknown stranger" connecting to an MX is a MUA
or any MTA not accepting mail, then <postmaster> won't
work. As you said 2821bis doesn't require <postmaster>
for anything that sends, it requires it for relays.
We're not talking about MSAs or submission operations
here.
When "direct-to-MX" doesn't work, as it's often the case
today, users submit their mail, and after that what is
left talking to an MX is a relay. Either directly the
used MSA, or some outbound relay behind the MSA.
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.
We are talking about the same three lines, you say that's
very clear, why is it that we interpret this different ?
| Any system that includes an SMTP server supporting mail
| relaying or delivery MUST support the reserved mailbox
| "postmaster" as a case-insensitive local name.
Ignoring "direct-to-MX" cases, and the normal operations
on the side of the receiver: The last hop on the side of
the originator talking as client to the first hop on the
side of the receiver (MX or simple A-fallback server) is
a relay.
It's the outbound relay behind or identical with the MSA.
And it's a relaying server, any MSA is a relaying server.
And a separate outbound relay behind the MSA also acts as
server when it gets outbound mail from the MSA. When it
has something in its send queue it connects - as client -
to the MX (or A-fallback or AAAA-toaster), and that is
where it might cause trouble.
The admin of the MX trying to figure out whatever goes
wrong has the connecting IP, maybe also a dubious EHLO,
but the IP is good enough, and can send a mail to this
relay, <postmaster(_at_)[IP]>, asking what's going on.
Furthermore, it says that the bare local name
"postmaster" is what has to work.
Yes, I don't insist on the domain-literal, the important
point is that the IP of the client causing trouble is
known, and minus "direct-to-MX" cases this client is a
relay.
It says *nothing* about postmaster(_at_)random-host-system-name
having to work.
Right, I don't insist that the EHLO FQDN of the relay
makes sense, using <postmaster> at the known IP may be
better to discuss whatever goes wrong.
I think your problem here is you're conflating hosts
with administrative domainss.
No, I don't think that's the misunderstanding. I think
the model MUA -> MSA -> outbound relay -> MX covers all
potentially dangerous shortcuts, we don't need to make
it more complex.
There can be separate administrative domains on the
side of the sender, but from an MX POV trying to report
trouble caused by the outbound relay that's irrelevant
and invisible, all it has is the IP and maybe a more or
less useful EHLO FQDN.
specific hosts dedicated to specific tasks: Incoming
relay from the Internet, outbound relay to the
Internet, submission from local users, spam filtering,
[...]
Yes, "do NOT assume that your MSA is the host talking
to MXs, there can be separate outbound relays" belongs
to the things folks learn when they ask for help on the
SPF HELP list. Shortly before or after they mastered
"MX is not necessarily related to outbound mail".
Oversimplifications are dangerous, but we don't need to
make it more complex than necessary. Unfortunately all
these important points at the "border" are not discussed
in email-arch. The email-arch focus is on "there can be
more ADMDs involved than you think". Which is true, but
not relevant for the "border" cases.
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".
Then it IMO missed a critical point of the <postmaster>
rule for relays. If there is no way to report trouble
with a misbehaving outbound relay the only alternative
is to block it, firewall its IP or similar. And for a
setup with only one outbound relay it will be difficult
to discuss the removal of this block after the trouble
was fixed.
once again it is quite clearly talking about a server's
implementation of the RCPT TO command.
ACK, anything with <postmaster> is about RCPT TO, nobody
should try MAIL FROM:<postmaster>, for that 2821bis has
MAIL FROM:<>.
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.
That is the idea, or maybe today only an ideal. I don't
insist that it works, but 2821bis says MUST for a reason.
The only reason I can imagine is to report trouble. With
potentially dire consequences if it doesn't work.
in most cases a better idea would be to send to the
postmaster address associated with the domain listed in
the MAIL FROM address.
If the trouble we're talking about reaches the point where
you have more than only the IP and maybe EHLO. When you
get MAIL FROM:<somebody(_at_)xyzzy(_dot_)claranet(_dot_)de> an attempt to
report problems to <postmaster(_at_)xyzzy(_dot_)claranet(_dot_)de> won't do
what you want (at the moment disabled + over quota, but
when it worked you'd talk with me - and in the case of a
random de.clara.net user they won't be able to help you
fix whatever is wrong).
As things are today the trouble you try to report might be
even no de.clara.net problem, you better don't trust that
MAIL FROM addresses mean anything at all (as it happens
you'd have an SPF PASS or FAIL in this example, but I fear
the majority of MAIL FROMs still is "unclear")
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.
I'm not exactly advocating it, I quoted 2821bis and think
it makes sense. Folks ignoring this rule will find out if
they can get away with it. Whenever I need to report some
trouble and find that postmaster@ doesn't work, I note the
fact in the postmaster.rfc-ignorant.org zone. It's nothing
personal, just a public "don't waste your time" notebook.
Frank