On Fri, Mar 6, 2015 at 1:51 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
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