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:<NJ09BPIMA(_at_)mail(_dot_)house(_dot_)gov> SIZE=30462
20:27:51.023 S: 250 <NJ09BPIMA(_at_)mail(_dot_)house(_dot_)gov>... Sender validation
pending. Continue.
20:27:51.081 C: RCPT To:<andrea(_dot_)santos(_at_)santronics(_dot_)com>
20:27:56.555 ** WCX Process: wcsap ret: -1 (5473 msecs)
20:27:56.555 S: 250 <andrea(_dot_)santos(_at_)santronics(_dot_)com>...
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
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp