> <[EMAIL PROTECTED]> 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, <[EMAIL PROTECTED]>, 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:<[EMAIL PROTECTED]> an attempt to
> report problems to <[EMAIL PROTECTED]> 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 "[EMAIL PROTECTED]".)
> 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 <[EMAIL PROTECTED]>, if "[EMAIL PROTECTED]" 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
