Subject: [Emailcore] rfc5321bis G.7.1.1 (Ticket #6); G.7.18, Section 4.2.4.2. -- "no mail accepted"

From: John C Klensin <[email-masked]>
Date: Sun, 03 Oct 2021 00:18:15 -0400

Hi.

In the absence of input from the WG, I've tried to sort out the
issues with codes 521, 554, and 566 so that people have text to
which to respond.   In the note below "rfc5321bis-04" or just
"-04" refer to draft-ietf-emailcore-rfc5321bis-04 (coming soon).

My assumption is that the intent of RFC 1846 (and hence 7504)
was to replace the use of 554 with 521 in the connection-opening
state when no mail was being accepted from any source.   I have
made that substitution.  The changes could not have been made in
2821 or 5321 because the relevant standards track specs were not
published until some time after the latter.  However, in going
through the text and thinking about a recent thread on a
non-IETF list, it occurs to me that there are actually three or
four plausible cases on connection-opening in addition to the
"normal" one:

(i) The server responding on the SMTP port is actually a stub
whose intent is to tell people that no mail is accepted at that
address, ever.  This was, AFAICT, the focus of RFC 1846 (carried
forward into 7504). 

(ii) The server accepts mail from some sources, under some
circumstances, but does not accept it from the particular
sending client, origin address. etc.  AFAICT from RFC 7504, 554
should continue to be used for that case.

(iii) The client should have determined, via the "Null MX"
convention specified in RFC 7505, that it should not try to open
a connection at all.  If it does anyway, code 556 should be
returned in preference to 521 (or 554).

(iv) The server accepts mail from at least some sources, but is
temporarily down or shutting down but something is still able to
respond (see below for codes).

Now, three questions:

(1) Is that description correct?  If it is not, comments and/or
text that might go into 5321bis would be welcome, but I am not
going to hold up -04 waiting.  Text suggestions are hence likely
to wait until after it is posted.

(2) Case (iv) above suggests that there should be a code for
temporary service outage in which the "real" server is
unavailable.  We could use 450 (server shutting down) for that
purpose or add a new code (457?).  Thoughts?

(3) Should we aspire to get enough of the text from RFCs 1846,
7504, and maybe 7505 into 5321bis to obsolete those specs
entirely (even if they are used as historical references)?   I
have made some moves in that direction in -04, but have probably
not gone all the way.   If so, what is needed that is not in
there (as of rfc5321bis-04 if not earlier) already?   The
alternative would seem to be including text in 5321bis
describing its relationship to those specs and increasing
confusion about just what specs make up "SMTP".  On the other
hand, incorporating the substances of 7504, probably 7505, and
(at least implicitly) 1846 would, I think, require someone doing
implementation reports for 7504 and 7505, but I assume they
would be straightforward.

-04 and supporting notes follow... soon.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2021 18:32:00 -0400

It appears that John C Klensin  <[email-masked]> said:
>Now, three questions:
>
>(1) Is that description correct?

Looks correct to me.

>purpose or add a new code (457?).  Thoughts?

I think 450 is appropriate.  Whatever mailbox you want, it's unavailable at the moment.

>entirely (even if they are used as historical references)? 

Unless it's a ridiculous amount of work, I would prefer that we decrease
the number of RFCs that people have to read to implement a working SMTP
package, so yes.

R's,
John