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

[John C Klensin <[e-mail]>]

A placeholder for whether we need to review some of all of the
timeouts has been added to the working copy of 5321bis-03.  As
with all of the other Appendix G entries for which there is not
already text in the I-D (text that was inserted either as an
obvious fix or after extended discussion on this list), I am
taking no position about what, if anything, should be done: I'm
just keeping a list.  One implication of that is that, if anyone
is going to suggest something that they don't think belongs on
the list... well, either say that or don't suggest it. 

Each one of those I add is more work for a possible WG to do
although I continue to hope and believe that such a WG could
quickly go through the list and divide things up into:

	* Handle in an Applicability Statement
	
	* Hold for future work to supplement SMTP (or other
	email protocols)
	
	* Requires work on 5321bis.

For the last category, I also continue to hope that, at least
for the subset of issues for which we do not already have
proposed text, there will be no, or almost no, entries.

Question for this list: I have not planned on posting -03 until
we have a WG.  It differs from the current draft on the servers
(-02) only in that Appendix G has been expanded a bit, most
recently with the "1yz" and timeout topics.  If anyone thinks
having it posted before IETF 107 would be helpful, e.g., to
facilitate any informal conversations that might occur then,
please say so and say so soon.  

best,
   john


--On Friday, March 6, 2020 10:22 -0500 Hector Santos
<hsantos=[e-mail]> wrote:

> On 3/6/2020 4:02 AM, Paul Smith wrote:> On 06/03/2020 02:45,
> Hector Santos wrote:
>>> 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.
>> 
>> I thought the main one was with delays after the the
>> terminating '.', where the client is meant to wait 10 minutes
>> for the server acknowledgement, but usually gives up a lot
>> sooner than that, leading to duplicate messages.
> 
> There are basically two:
> 
> At all the states EHLO, MAIL, RCPT and DATA, etc. Each state
> can spawn scripts, shims, hooks, mfilters, etc. Once upon a
> time, a concern was scripts, current or future, can
> potentially take longer than the allotted idle timeout period
> per state. So there is technically runtime limits &
> restrictions at all states.  10 mins for DATA, 5 for the rest.
> 
> But the one that was real and significant, are with clients
> who do complete the DATA state, get a 2yz, 4yz or 5yz response
> to complete a transaction. Then instead of issuing a QUIT, it
> keeps the socket connection open and waits for a new outbound
> message to be queued to begin a new RSET/MAIL command to start
> a new transaction.  This may help scale clients but not
> servers because of wasteful session residence time. Depending
> on your server load settings, the server
> threads/processes/ports could be consumed honoring the 5
> minute wait.   However, most of the time, no new transaction
> begins.  So it is very wasteful and wcSMPT provides an
> operator option to shorten it.
> 
> I think since the last review of this, over a decade ago, some
> operators reading the threads got some operational, practical
> input on this, agreed it was wasteful for the server and
> probably shorten the "new transaction" wait time so that the
> client does not chew up server resources.  I recall one big
> domain waiting the 5 minutes but today, looking at the logs, I
> see they have cut that down to 5 seconds!  So if no new mail
> is queued on the sender side within 5 seconds, it issues a
> QUIT.
> 
> Here is one example where the client is waiting and my
> particular wcSMTP server setup disconnects after 35 seconds.
> It is set in the registry "PostDataTimeoutSecs" DWORD 35  and
> the default is 0 (the SMTP 5 mins limit to wait for a new
> transaction).
> 
> **************************************************************
> ************
> Wildcat! ESMTP Server v8.0.454.9
> SMTP log started at Thu, 05 Mar 2020  20:27:49
> Connection Time: 20200305 20:27:49  cid: 00003F96 tid: 00001390
> SSL-Enabled=YES No-Quit-Cancel=OFF Receiver-Bin=ON
> Client IP: 143.228.181.88:25678 (unknown) Host IP:
> 76.245.57.69:25
> 20:27:49.763 ** WCX Process: smtpcmd-connect  ret: -1
> 20:27:49.763 S: 220-winserver.com Wildcat! ESMTP Server
> v8.0.454.9 ready
> 20:27:49.763 S: 220-************** WARNING:  FOR AUTHORIZED
> USE ONLY! **********************
> 20:27:49.763 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF
> ITS PROPRIETARY COMPUTERS    *
> 20:27:49.763 S: 220-* AND COMPUTER NETWORKS TO ACCEPT,
> TRANSMIT, OR DISTRIBUTE UNSOLICITED *
> 20:27:49.763 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS
> SYSTEM WILL RESTRICT ACCESS *
> 20:27:49.763 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT
> CLIENTS ONLY.                       *
> 20:27:49.763 S: 220
> **************************************************************
> **********
> 20:27:50.120 C: EHLO s-bulk2-p.house.gov
> 20:27:50.126 ** WCX Process: smtpcmd-check-ehlo  ret: -1
> 20:27:50.126 S: 250-winserver.com, Pleased to meet you.
> 20:27:50.126 S: 250-SIZE 102400000
> 20:27:50.126 S: 250-8BITMIME
> 20:27:50.126 S: 250-SUBMITTER
> 20:27:50.126 S: 250-ETRN
> 20:27:50.126 S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN
> PLAIN-MD5 SHA-1
> 20:27:50.126 S: 250-AUTH=LOGIN
> 20:27:50.126 S: 250-HELP
> 20:27:50.126 S: 250 STARTTLS
> 20:27:50.535 C: STARTTLS
> 20:27:50.536 S: 220 Ready to start TLS
> 20:27:50.536 ** Begin SSL negotiation
> 20:27:50.807 ** SSL negotiation successful
> 20:27:50.863 C: EHLO s-bulk2-p.house.gov
> 20:27:50.869 ** WCX Process: smtpcmd-check-ehlo  ret: -1
> 20:27:50.869 S: 250-winserver.com, Pleased to meet you.
> 20:27:50.869 S: 250-SIZE 102400000
> 20:27:50.869 S: 250-8BITMIME
> 20:27:50.869 S: 250-SUBMITTER
> 20:27:50.869 S: 250-ETRN
> 20:27:50.869 S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN
> PLAIN-MD5 SHA-1
> 20:27:50.869 S: 250-AUTH=LOGIN
> 20:27:50.869 S: 250 HELP
> 20:27:51.022 C: MAIL From:<[e-mail]> SIZE=30462
> 20:27:51.023 S: 250 <[e-mail]>... Sender
> validation pending. Continue.
> 20:27:51.081 C: RCPT To:<[e-mail]>
> 20:27:56.555 ** WCX Process: wcsap ret: -1 (5473 msecs)
> 20:27:56.555 S: 250 <[e-mail]>...
> Recipient ok
> 20:27:57.502 C: DATA
> 20:27:57.502 S: 354 Start mail input; end with <CRLF>.<CRLF>
> 20:27:59.441 ** end of data received. (bytes: 31708) (15.9 K/s)
> 20:28:00.539 ** WCX Process: SmtpFilterHookLoader  ret: 1
> (1098 msecs)
> 20:28:00.539 ** Authentication-Results: dkim.winserver.com;
> 20:28:00.539 **      dkim=pass header.d=mail.house.gov
> header.s=November2012-msg-mhg header.i=mail.house.gov;
> 20:28:00.539 **      dkim=pass header.d=mail.house.gov
> header.s=November2012-msg-mhg header.i=mail.house.gov;
> 20:28:00.540 ** message copied to router prespool
> 20:28:00.540 ** Router signaled to begin handling new messages
> 20:28:00.540 S: 250 Message accepted for delivery. (bytes:
> 31708)
> 20:28:37.045 S: 421 Idle Timeout - Server closing transmission
> channel.
> 20:28:37.045 ** Completed. Elapsed Time: 47300 msecs