ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] SMTP Reply code 1yz Positive Preliminary reply

2020-03-05 14:06:20
Hector,

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.  

best,
   john


--On Thursday, March 5, 2020 12:56 -0500 Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:


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.

https://tools.ietf.org/html/rfc5321#section-4.2.1

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

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp