Subject: Re: Last Call: <draft-klensin-smtp-521code-05.txt> (SMTP 521 and 556 Reply Codes) to Proposed Standard

From: "John Levine" <[email-masked]>
Date: 6 Mar 2015 01:46:41 -0000

In article <[email-masked]> you write:
>
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'SMTP 521 and 556 Reply Codes'
>  <draft-klensin-smtp-521code-05.txt> as Proposed Standard

I have reviewed this draft and think it's just fine.  It provides
return codes useful with the upcoming null MX RFC, and since null MX
is in active use (Google told me today that gmail checks for it), the
return codes are likely to be useful, too.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Mar 2015 13:21:59 -0800

On Thu, Mar 5, 2015 at 12:02 PM, The IESG <[email-masked]> wrote:

> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-04-02. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This memo defines two Simple Mail Transfer Protocol (SMTP) reply
>    codes, 521 and 556.  The 521 code was originally described in an
>    Experimental RFC in 1995 and is in wide use, but has not previously
>    been formally incorporated into SMTP.  The 556 code was created for
>    RFC-nullMX.  These codes are used to indicate that an Internet host
>    does not accept incoming mail at all (not just under particular
>    circumstances).
>

I support publication of this work.  I have the following minor comments:

Section 2 says that a client trying to talk to a server that provides no
SMTP service will eventually time out.  That's not universally true; trying
to talk to a server that's up but not offering SMTP service can also cause
an immediate error if an RST comes back in reply to the SYN because there's
nothing listening on port 25.

In Section 3, there's an errant semicolon.

Should Section 5.1 also add 521 to the list of valid connection termination
conditions in Section 3.8 of RFC5321?

-MSK

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 16:51:35 -0500

--On Friday, March 06, 2015 13:21 -0800 "Murray S. Kucherawy"
<[email-masked]> wrote:

>...
> Section 2 says that a client trying to talk to a server that
> provides no SMTP service will eventually time out.  That's not
> universally true; trying to talk to a server that's up but not
> offering SMTP service can also cause an immediate error if an
> RST comes back in reply to the SYN because there's nothing
> listening on port 25.

Please propose text.  Also check 5321 to see if an erratum is
needed because, IIR, it makes some related comments.  Do note,
however, that if the client attempts to establish a TCP
connection on port 25 and the server responds with a RST, there
is nothing in this document that is relevant because the server
is certainly not going to see generate any reply code in that
situation.  This gets into territory that 5321 discusses a bit
(and, btw, encourages the client to retry and keep retrying, so
it may not be a good server strategy... hence nullMX) and that
1846 sort of got into, contributing to the decision to not just
try to update and standardize it.

> In Section 3, there's an errant semicolon.

Caught and fixed in working copy, thanks to Дилян
Палаузов.

> Should Section 5.1 also add 521 to the list of valid
> connection termination conditions in Section 3.8 of RFC5321?

Personal opinion: Maybe.  I can argue it either way, but note
that putting text to this effect into 5321 without authorizing
things we don't want to authorize (e.g., if 521 is used during a
mail transaction, we wouldn't normally want the server to send
it and disconnect) is a little more tricky than adding a bullet
and code.  I think that 5321 could probably use a discussion of
handling things that happen before a mail connection has been
established -- e.g., before HELO/EHLO are sent by the client and
maybe before positive responses to them are sent by the server,
but note that VRFY and EXPN don't require mail sessions-- but
hanging that onto this draft or trying to write and edit it by
committee seems like a terrible idea.

Recommendation: Let it go here and post a note to ietf-smtp at
your convenience suggesting exactly what should be done to 5321.
I don't think a separate updating I-D is needed, but YMMD.

Again, that is just personal opinion (and, as the stuckee for
5321bis, personal preference).

thanks,
    john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Mar 2015 15:33:47 -0800

> try to update and standardize it.

My only quibble is with the claim that such connections will time out,
which isn't always the case.  When they do time out, your text is exactly
right.  Here are two suggestions (I prefer the latter):

OLD:

   Many Internet hosts are not in a position -- whether technically,
   operationally, or administratively-- to offer email service.  If an
   SMTP client (sender) attempts to open a mail connection to a system
   that does not have an SMTP server, the connection attempt will time
   out.  SMTP requires that timeouts result in the client queuing the
   message and retrying it for an extended period.  That behavior will
   result in wasted resources and long delays in getting an error
   message back to its originator.

NEW #1:

   Many Internet hosts are not in a position -- whether technically,

   operationally or administratively -- to offer email service.  If an

   SMTP client (sender) attempts to open a mail connection to a system

   that does not respond to such requests, the connection attempt will

   time out.  SMTP requires that timeouts result in the client queueing the

   message and retrying it for an extended period.  That behavior will

   result in wasted resources and long delays in getting an error

   message back to its originator.

NEW #2:
   Many Internet hosts are not in a position -- whether technically,
   operationally or administratively -- to offer email service.  If an
   SMTP client (sender) attempts to open a mail connection to a system
   that does not respond to such requests, the connection attempt will
   time out.  Alternatively, the system might reject the connection
   outright.  SMTP requires that timeouts and other connection failures
   result in the client queueing the message and retrying it for an
   extended period.  That behavior will result in wasted resources and
   long delays in getting an error message back to its originator.

> committee seems like a terrible idea.

The only reason this tripped for me is that RFC5321 is one about which we
tend to be rather strict, or at least that's been my experience.  With
enough argument that this is really OK, I'll probably drop it, but please
indulge me a bit longer... ;-)

Anyway, to dive into it a bit deeper:

Section 3.8 of RFC5321 enumerates the only conditions under which a server
can drop a connection, with an exception carved out for Section 7.8 which
deals with responses to attacks.  The language used there seems to be
pretty strict about it.  It doesn't appear to me that this qualifies under
the exception, because it's not definitely an attack, though one could
argue that there's no legitimate reason for a client to be talking to such
a server in the first place.

It seems therefore that your draft is indeed trying to authorize connection
drops for the case where (according to the text you have in the last
paragraph of your Section 3) resource conservation by a 521-aware server is
desirable.  Thus, I think this would be an appropriate or even necessary
change to RFC5321.

Assuming the above holds water, and that you want to avoid the issue for
this simple document, what about one or more of the following?:

1) Remove the clause in your Section 3 that allows for connection dropping,
leaving that for RFC5321bis;

2) Spend a paragraph or two in your Section 3 explaining more specifically
the use (or not) of 521 during a mail transaction;

3) More simply, limit 521 such that if you're going to use it, it MUST be
the reply to all MAIL commands, and MAY be the reply to anything else
(including the connection itself) until the client goes away;

4) More simply still, limit 521 such that if you're going to use it, it
MUST be your reply to all commands until the client goes away.

> I don't think a separate updating I-D is needed, but YMMD.

Will do, once I've exhausted this exploration.  :-)

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Mar 2015 02:21:54 -0000

>   out.

How about just making it "will be rejected or time out."

  SMTP requires that timeouts result in the client queuing the

"that timeouts" -> "that such failures"

>   message back to its originator.

It's shorter, says what needs to be said.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 Mar 2015 11:33:55 -0400

> It's shorter, says what needs to be said.

That seems to me to be the perfect level of change here, though I
would prefer the first be "will fail or time out", as there's no
active rejection going on (but I don't care enough to argue the point
further).

It's very important to remember that the purpose of what the document
is saying there is purely to give enough background for readers to
understand the purpose and usage of the codes.  Getting into finer
details of how SMTP works in these situations and debating too much
about whether "time out" is strictly and completely correct will just
distract from getting a simple, useful change in the status codes
standardized.

Barry