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

["Murray S. Kucherawy" <[e-mail]>]

On Fri, Mar 6, 2015 at 1:51 PM, John C Klensin <[e-mail]> 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.
>

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.


> > 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.
>

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.

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.
>

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

-MSK