Subject: Re: [Emailcore] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster'

From: John C Klensin <[email-masked]>
Date: Sat, 05 Mar 2022 21:19:58 -0500

--On Monday, February 21, 2022 14:10 -0500 John Levine
<[email-masked]> wrote:

> It appears that Sabahattin Gucukoglu  <[email-masked]> said:
>> If I'm honest, I'm just not a fan of code 556. If
>> somebody finds it useful, fair enough, but it seems to me to
>> require a special-case treatment of a non-existent domain,
>> which must be configured to be useful.
> 
> No, 556 doesn't need any special cases. The likely scenario is
> that you have a submission server, someone sends 
> 
>   RCPT TO:<[email-masked]> 
> 
> and the submission server sees that example.wtf has a null mx
> so it knows there's no point to accepting the mail. It doesn't
> need to look at the mailbox.  I suppose it would also be
> appropriate if the domain does not exist at all, again
> unrelated to the mailbox.
> 
> There's also 521 and 554 which say "I am not a mail server." I
> don't think that we can realistically change that to "I am not
> a mail server except that I can send postmaster mail
> somewhere."

Speaking personally, not as editor: John's "not a mail server
except that I accept mail for an address or two" would lead us
into all sorts of silly cases... and break the way things have
been specified since RFC 821.

Recent off-list correspondence leads me to believe that I see
more cases than John Levine did at the time I wrote him, but,
AFAICT, I can't see any special cases here.   If the SMTP server
knows that no mail is accepted but an attempt to open a mail
transaction is received anyway, 556 might reasonably be returned
at connection time.  As I read Section 4.2.4.2 of rfc5321bis-09
(and -10 -- any changes are not going to make it into that
version), 521 would be preferred if the SMTP server doesn't
figure out the it isn't accepting mail for that particular
domain until it gets a RCPT command, but 556 would be more
emphatic if the server were aware that there was a null MX
record for that domain and, speaking personally, I don't see
much value in trying to absolutely prohibit it for that case.

These things can get a tad more complicated if there is a
configuration inconsistency or misunderstand between the SMTP
server and the relevant authoritative DNS server/zone, but I
think the current text is robust against such problems.

Now, as editor, three requests/suggestions, the first for
Sabahattin and the other two for everyone:

(1) If, with John Levine's explanation and mine, you still don't
understand that this is not about special cases, please explain
what those cases are in a bit more detail.

(2) Please read Section 4.2.4.2, which is intended to cover all
of this, carefully.  If it still leaves loose ends or introduces
problems, please identify those as explicitly as possible and,
if possible suggest text or at least particular sentences that
need fixing.

(3) John Levine has pointed out that rfc5321bis-09 covers
substantially everything that is in RFC 7505 except the enhanced
status codes.   Especially given that we propose to obsolete
7505, should some words be added to that section to point to the
IANA registry with those codes in it?

thanks,
    john

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 6 Mar 2022 19:41:43 +0000

> been specified since RFC 821.

Accepted, absolutely. I do not propose to make the cost of refusing all mail prohibitive and it would be burdensome and unnecessary to require a server intended to refuse all mail to accept mail just for postmaster.

And yes, if a non-public intermediate or submission server performs checks in real time on mail being submitted against destination MXs or mailboxes then it can obviously be expected to informatively explain to the client that the destination domain is unreachable and no further configuration is necessary to achieve that effect. (I expect that many submission servers will refuse to do this for policy reasons, though, or to support submission clients or users that react poorly to failed submissions.)

> much value in trying to absolutely prohibit it for that case.

OK, I re-read section 4.2.4.2 and RFCs 7504-5 and think I see what’s happened. If it is intended that 556 is used at connection-opening time on a public host then, firstly, I think section 4.2.4.2 needs a bit of work because the juxtaposition of the discussion of code 521 at connection-opening time (first paragraph) and the discussion of code 556 in intermediate system, submission and “the server domain” as well (second paragraph) makes it all but inevitable that people like me will erroneously think the latter paragraph is only concerning a post-RCPT response by implication (which, incidentally, is not indicated in section 4.3.2 where as its use in connection establishment was and I clearly missed it) and, secondly, I would agree that no harm was done in that case.

Now, if after this explanation of my error in comprehension, there is still any relevance to public non-submission SMTP hosts (which might include intermediate systems that permit relay to certain destinations, but which are always configured as an MX target for domains for which they are responsible), I believe what we are left with is the question of whether it is proper to refuse mail at RCPT time with code 556. I would, I think, remain against — it seems to me that any MTA capable of, in theory, receiving any mail for local mailbox storage or onward transmission to a mailbox store elsewhere ought in principle to receive postmaster mail for any of its domains, whether MX targets or A/AAAA implicit-MX targets or address-literal targets. To refuse mail with code 556 at RCPT time would require the public MX to know about a domain for which it did not receive mail, including postmaster mail, and would in effect be a special case for the refusal of mail for postmaster. Code 556 in response to RCPT should therefore only ever be used on submission servers or intermediate servers used internally for onward transmission for a restricted set of clients, i.e. which are not public servers that restrict mail acceptance to a fixed set of configured destinations and which could therefore be expected to perform MX lookups for unknown destination domains and react to NULL MX records, IMO. But, if that is thought overly disciplinarian, I am quite happy to see the consensus go the other way — though I do think it would undermine the case for ‘postmaster’. My reading of RFCs 7504-5 do not leave me with any doubt that code 556 is not relevant on a public MX post-RCPT, and the error in interpreting 5321bis is all mine in that regard. If so, then a little clarity to that effect in section 4.2.4.2 is all that’s required.

> think the current text is robust against such problems.

Agreed completely.

> what those cases are in a bit more detail.

If code 556 is relevant post-RCPT on a public MX host, it must be configured to refuse mail destined for an “unserviced” domain, as above, otherwise it would normally just refuse to relay mail for policy reasons for domains it didn’t know about, or refuse mail for unknown mailboxes for domains it did.

> if possible suggest text or at least particular sentences that

Code 556 should be explicitly called out as being valid at connection-opening in section 4.2.4.2; it shouldn’t be left to the command-reply sequences list. I think 5321bis is relevant to code 556 post-RCPT and this needs to be clarified; even though 5321bis doesn’t pertain to submission, it does concern intermediate systems, which include SMTP relays used in a trusted environment, therefore the command-reply sequence list needs to acknowledge 556 as a possible reply to RCPT. Finally, we need a discussion of whether code 556 post-RCPT on a public MX is appropriate at all, and to add text accordingly.

I hope this clarifies my thinking.

Cheers,
Sabahattin

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2022 21:59:34 -0500

It appears that Sabahattin Gucukoglu  <[email-masked]> said:
>And yes, if a non-public intermediate or submission server performs checks in real time on mail being submitted
>against destination MXs or mailboxes then it can obviously be expected to informatively explain to the client that the
>destination domain is unreachable and no further configuration is necessary to achieve that effect. (I expect that
>many submission servers will refuse to do this for policy reasons, though, or to support submission clients or users
>that react poorly to failed submissions.)

Given a choice between rejecting at submission time and a bounce
later, I'll take the reject. In my experience MUAs don't do a fabulous
job of explaining the failure, but it's better than trying to figure
out a bounce.  This is the most likely scenario for 556.

>If code 556 is relevant post-RCPT on a public MX host, it must be configured to refuse mail destined for an
>“unserviced” domain, as above, otherwise it would normally just refuse to relay mail for policy reasons for
>domains it didn’t know about, or refuse mail for unknown mailboxes for domains it did.

I'm with you. An MTA is either configured to accept mail for a domain
or it isn't, and it's not likely to provide helpful opinions about the
ones it's not configured for.

I can imagine some arcane edge cases like an MTA set up as a secondary for a null MX, but now we're
into "don't do that" territory.

blah.wtf. MX 0 .
          MX 10 secondary.wtf.  <-- that one might give a 556, maybe

R's,
John

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 7 Mar 2022 10:39:08 +0000

> ones it's not configured for.

Agreed.

>          MX 10 secondary.wtf.  <-- that one might give a 556, maybe

I remember when it was trendy to allow yourself to be a backup MX for anybody who wanted to use your services; you’d check the MX list to see if you were a non-primary MX for the recipient domain and accept and queue the mail if you were. I don’t know anyone doing that in 2022 because it would make your reputation harder to protect from complete strangers using your system to contact others on their behalf or to inject forged mail for subsequent bouncing to a victim, but just in case, I suppose we could distinguish between “configured” and “unconfigured” (or similar) domains for the purposes of the description of code 556 if that was still thought useful.

Cheers,
Sabahattin

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Mar 2022 22:15:12 -0500

--On Sunday, March 6, 2022 21:59 -0500 John Levine
<[email-masked]> wrote:

>> And yes, if a non-public intermediate or submission server
>> performs checks in real time on mail being submitted against
>> destination MXs or mailboxes then it can obviously be
>> expected to informatively explain to the client that the
>> destination domain is unreachable and no further
>> configuration is necessary to achieve that effect. (I expect
>> that many submission servers will refuse to do this for
>> policy reasons, though, or to support submission clients or
>> users that react poorly to failed submissions.)

(no hat)

This is far out of scope for SMTP and hence 5321bis, but I have
trouble imagining why a submission server configuration would
feel a need to hide information about a destination domain
refusing to accept mail from the submitting client.  After all,
those two are supposed to have a close relationship.  The
submission server is not some random host on the network at
which the client lobs a message. RFC 5068/BCP 134 specifies that
it authenticate the client and RFC 8314 requires encryption.
>From the standpoint of a user sitting in front of that client,
the most likely cause of a 556 error is trying to use a bad
address, possibly the result of a typographical error and it is
in everyone's interest that such a problem be reported with an
appropriate level of clarity so that error can be corrected.
Now, I suppose that if one were running an open submission
server (sort of like an open relay), accepting traffic on port
25 rather than 587, the situation would be quite different.
But, to put it mildly, we don't consider running such servers to
be a good practice and have not for many years.

Now, if someone tells me that some of the very large mail
providers don't handle submission very well and hence needed to
obscure information to cover up their own failings, I guess I
would not be surprised.  However...

> Given a choice between rejecting at submission time and a
> bounce later, I'll take the reject. In my experience MUAs
> don't do a fabulous job of explaining the failure, but it's
> better than trying to figure out a bounce.  This is the most
> likely scenario for 556.

Agreed.

>> If code 556 is relevant post-RCPT on a public MX host, it
>> must be configured to refuse mail destined for an
>> "unserviced" domain, as above, otherwise it would
>> normally just refuse to relay mail for policy reasons for
>> domains it didn't know about, or refuse mail for unknown
>> mailboxes for domains it did.
> 
> I'm with you. An MTA is either configured to accept mail for a
> domain or it isn't, and it's not likely to provide helpful
> opinions about the ones it's not configured for.

For the vast majority of cases, I agree.  See below.
 
> I can imagine some arcane edge cases like an MTA set up as a
> secondary for a null MX, but now we're into "don't do that"
> territory.
> 
> blah.wtf. MX 0 .

Right, but that would be so blatantly stupid that I assume that,
were it common, those who produce DNS software would be
considering adding it to their sanity test tools.   But let me
walk through a moderately complicated --but, IMO, plausible--
scenario because I'm no longer sure what 5321bis should say.
Consider the following with the understanding that this is
probably uncommon at best:

As I think I mentioned in another message, consider the
possibility of an enterprise, call it LittleCo, in which those
who maintain DNS records and those who maintain servers that
handle mail are in separate organizations.  It would be an
especially nasty case if one organization had outsourced, e.g.,
mail and web services to one provider (example1.net) but DNS
services to a different one (example2.net).  I gather that
occurs a lot (even if it would not pass for "common").   Also
assume that both example1.net and example2.net (and
example3.net, which I will get to in a moment), provide services
to multiple domains.  Skipping assorted possible complications
and using CNAME, not because it is a good idea but because it
makes the example shorter, we have, on the authoritative
example2.net:

   LittleCo.example.     IN CNAME example1.net.
   www.LittleCo.example. IN CNAME example1.net.
   LittleCo.example.     MX 0 example1.net.

Now, someone in the management of LittleCo decides that it does
not like the mail service being provided by example1.net and
wants to move it to example3.net.  They get the service set up
on example3.net and then  send out memos to the provider who
runs example1.net telling them that they no longer have a
contract to support mail for LittleCo and to LittleCo's DNS
provider telling them to change the MX RR.  If they are smart
and good negotiators, they get example1.net to host a relay for
a while, presumably several times the TTL, so the target DNS
structure during that period looks like:

   LittleCo.example.     IN CNAME example1.net.
   www.LittleCo.example. IN CNAME example1.net.
   LittleCo.example.     MX 10 example1.net.
   LittleCo.example.     MX 0 example3.net.

If those changes do not occur in the right order and with some
luck, there might be a period in which example1 still thinks it
is providing a final delivery service rather than a relay one
and LittleCo would be smart to plan for that.  Otherwise, so
far, so good. But eventually the contract between LittleCo and
example1 about mail service runs out and the the DNS is changed
to 

   LittleCo.example.     IN CNAME example1.net.
   www.LittleCo.example. IN CNAME example1.net.
   LittleCo.example.     MX 0 example3.net.

Now, for the case of concern, if someone has a cache that should
have expired but has not and opens an SMTP connection to
example1.net (which is also providing mail support for other
domains, so it cannot return a 5yz code at initial connection
time).  The client sends EHLO and MAIL commands as usual, then 
   RCPT TO:<[email-masked]>

Question 1: Would we prefer that example1.com reply with 556 or
521, indicating that example1 is not providing mail service for
that domain, or 550 (no mailbox for that address).   Either of
the first two provide much more information than the 550 and, I
think, do not give out any secret information.

Question 2: Assuming 556 or 521, do we have a preference and
why?  Do we want to reserve 556 for connection-opening only so
521 is returned here?  If not, what is 521 good for?

Question 3: Sections 4.2.3 and 4.2.2 say, for 554, 
	"(Or, historically in the case of a connection-opening
	response, "No SMTP service here".  521 is now preferred
	for that function at connection-opening if the server
	never accepts mail.)"
Is that just wrong, i.e. should it say 556 instead of 521?

... and, now...

Suppose LittleCo is in the process of going out of business but
still owns the domain name.  Assuming it can do so, it changes
the DNS entries to

   LittleCo.example.     IN CNAME tombstone.example1.net.
   www.LittleCo.example. IN CNAME tombstone.example1.net.
   LittleCo.example.     MX 0 .

Now, if during some transition period (inside or outside the DNS
TTL), example3.net. gets a connection attempt exactly like the
one for example1.net above, i.e., the connection attempt
succeeds because example3.net provides SMTP service to domains
that have nothing to do with LittleCo, the EHLO and MAIL
commands go through without problems, and it then gets the same
RCPT command as above.  

Questions 4 and 5 are identical to Questions 1 and 2 above, but
it is not clear that the answers should be.

If it is clear what the WG wants the text to say in those five
cases, I can fix at least those parts of 4.2.4.2.   I am now
confused about the answers to some of those questions (although
I have preferences) and am wondering a bit why we introduced the
556 code (which might be close to Sabahattin's original
concern... or not).

    john

---

From: "John R Levine" <[email-masked]>
Date: 9 Mar 2022 13:01:18 -0500

On Tue, 8 Mar 2022, John C Klensin wrote:
> that domain, or 550 (no mailbox for that address).

In practice it's this or something close to it:

  550 5.1.0 Mail system is not configured to accept that recipient

> Is that just wrong, i.e. should it say 556 instead of 521?

No, that's fine.

> it is not clear that the answers should be.

Same answer:

  550 5.1.0 Mail system is not configured to accept that recipient

I don't know how many ways to say that MTAs know who they accept mail for 
and who they don't, but they don't know *why* they don't accept mail for 
the ones they don't.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly