On Fri, Mar 6, 2015 at 1:51 PM, John C Klensin <john-ietf@xxxxxxx> wrote:
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:
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.
> 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.
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