John K, regarding the Timeouts, I was more facetious than serious
here. However, there are situations we already talked about in the
past. We could highlight some of them, but I believe the main one was
the 5 mins after the transaction was completed and a RSET/MAIL can
start a new transaction. The server has to wait 5 minutes. This is a
wasteful timeout. By far, the majority, and for most system, 100% of
the time, a new shorter wait time would be more scale efficiency,
offer more load management friendliness.
This should be an adjustable per domain timeout state. The known sites
that correctly issue multiple transactions in a single session can be
allowed a longer period to start new transactions.
On 3/5/2020 3:05 PM, John C Klensin wrote:
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
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp