<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:
I'm not sure what you mean by "direct-to-MX", but regardless, I must say that I
view the <postmaster> convention as a fairly pointless anachronism at this
point. I don't know of a single widely used client that will let you send a
message to such an address. And most users aren't going to know how to do it
using telnet.
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.
For about the fifth time, that's not what 2821bis says. You keep dropping the
vital qualification that the requirement only applies to systems, _including_
_relays_, that operate an SMTP receiver. There is no requirement that a system
with an SMTP client also have an SMTP server up and running.
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.
I have no idea what you're talking about.
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 ?
I'm very much afraid it's because your reading is quite simply wrong.
| 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.
They can if there's an SMTP server on the host to send it to. But it is in no
way a standards violation if there isn't. Nor is there apparently any
requirement that a host actually accept mail sent using an address literal
specifying one of its IP addresses. (I could have sworn handling such addresses
was required but I just checked and it apparently isn't.) And regardless of
what's required, the fact is a lot of systems either won't accept address
literals or don't know their own address literal "names" when they see them,
and no amount of rulemaking is likely to change this.
...
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.
There is no such rule and repeated statements to the contrary isn't going to
bring such a rule into existance. Again, the statements in section 4.1.3 are
all qualified by clauses like "by all receivers" and "that includes an SMTP
server" and so on. You cannot simply ignore these qualifiers because you don't
like what they imply.
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.
Yep. I do it all the time.
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.
Yes, well, there are lots of dire consequences lurking everywhere. That's life
in the food chain.
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).
Again, the present-day reality is that postmaster addresses, especially
host-specific ones, are often unmonitored and may even be routed straight to
the bitbucket. If all you have is the IP address of a problem system I suspect
a better approach is to figure out who the address belongs to, then find an
approprirate technical contact address to report the problem to. (And the odds
are pretty good it won't be "postmaster(_at_)anything".)
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.
There is no such rule and therefore the people are "ignoring" nothing.
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.
You might want to review the rfc-ignorant.org criteria for such listings, which
is also quite clear:
If the right-hand-side of an address doesn't have a postmaster address (e.g.,
given an address of <foo(_at_)example(_dot_)tld>, if
"postmaster(_at_)example(_dot_)tld" bounces as
non-existent (on any of the valid MX servers for 'example.tld'), then
example.tld would be listed.
In other words, this is all about postmaster addresses corresponding to the
domain used in some address not working. There is nothing in the criteria that
would support listing a domain because they don't have an SMTP server accesible
on every system that operates an SMTP client.
Ned