I don't think it matters because SMTP design docs do not talk about
client/server "Keep Alive" concepts.
We could of corrected the semantics of mixed reply codes without
removing (without explanation) 1yz reply codes. Modern RFC5321
clients should not have a problem. I think the original RFC2821 4.2.1
last paragraph applies more correctly than the current RFC5321
paragraph replacement which asserts persistent multi-line reply codes.
I don't know what the answer is but if RFC821 legacy compliancy is
still important, then please allow for IP literals to remain a part of
the basic protocol. Engineering Consistency is all implementers can
On 3/5/2020 3:05 PM, John C Klensin wrote:
I have added a placeholder for this to the list in Appendix G
Section 7 of the working draft.
FWKW, my personal opinion is that would be a significant change,
outside the scope contemplated for 5321bis. YMMD and that is,
IMO, a decision that can be made only by the WG when there is
one. However, if others agree with me, your best course forward
is to write and post an I-D explaining what you think would be
desirable and why, see if you can get it standardized and
implementation reports generated, and then propose it for
inclusion in 5321bis.
--On Thursday, March 5, 2020 12:56 -0500 Hector Santos
On 3/5/2020 11:28 AM, Hector Santos wrote:
I used the reply group:
1yz Positive Preliminary reply
I had forgotten that RFC5321 had removed this 1yz code.
All because of the 1yz potentially used as a "preliminary"
multiple lines "1yz-" response before the final response was
issued and a possible legacy 821 client that looked only at
the first response line because it didn't expect multiple
I don't fully recall the discussions. While I would had
accepted the decision for backward compatibility reasons over
a decade ago, I am pretty sure I would of been somewhat
disappointed by the removal of "1yz Positive preliminary
reply" codes, removing even the possibility of a keep alive
concept. Today speeds allow for fast data processing, so even
today, 5, certainly 10 minutes of idle timeout is outdated and
probably should be a design taboo today. If we don't want
ESMTP 2821 clients to use 1yz, well, maybe for RFC5321bis, we
can lower the timeouts. I already do for after a successful
transactions where there is additional 5 minutes wait for a
new transaction. I reduced to less than 1 minute to because
clients from the BIG boys were 99.9% of the time holding up my
servers and never doing a 2nd MAIL transaction. So wcSMTP
will drop clients who chews up available mail service time
from the server threads.
ietf-smtp mailing list
ietf-smtp mailing list