<[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: 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, <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] > 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:<[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). 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
