--On Friday, March 06, 2015 13:21 -0800 "Murray S. Kucherawy"
<superuser@xxxxxxxxx> wrote:
>...
> 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.
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