David MacQuigg wrote:
I just did an experiment with Sendmail using telnet as the client. If I
send one line of data, then pause, Sendmail waits 10 minutes then
disconnects with no message to telnet. There is no timeout in telnet,
so it just sits there until I force a disconnect on that end.
So it seems that Sendmail is doing what I suggested earlier - the least
possible work on the receiver side, no TCP reset, no attempt to close
the connection, just disconnect and let the transmitter hang.
It probably broke out of the receiver DATA loop, and is probably
waiting for the client to send QUIT. That is what our receiver will
do and if that doesn't happen in 5 minutes, it will close the socket
and kill the session.
220-winserver.com Wildcat! ESMTP Server v6.3.452.9 ready
220-************** WARNING: FOR AUTHORIZED USE ONLY!
**********************
220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY
COMPUTERS *
220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE
UNSOLICITED *
220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT
ACCESS *
220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY.
*
220
************************************************************************
EHLO HDEV1
250-winserver.com, Pleased to meet you.
250-SIZE 10240000
250-SUBMITTER
250-ETRN
250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
250-AUTH=LOGIN
250 HELP
MAIL FROM:<xxxxxxxxx>
250 <xxxxxx>... Sender ok.
RCPT TO:<xxxxxxxxxxxxx>
250 <xxxxxxxxxx>... Recipient ok
DATA
354 Start mail input; end with <CRLF>.<CRLF>
421 Idle Timeout - Server closing transmission channel.
Connection to host lost.
----------------------------
Watching my clock, 354 was issued at 1:37pm. The telnet terminal
"connection to host lost" message came at 1:45pm.
Looking at the server code, we have a default 3 minute IDLE timeout
for client data to arrive. It dropped out of the loop (1:40pm) and 5
minutes later (1:45pm) it closed the session.
The server side log is:
13:38:46 C: DATA
13:38:46 S: 354 Start mail input; end with <CRLF>.<CRLF>
13:46:47 S: 421 Idle Timeout - Server closing transmission channel.
13:46:47 ** Completed
So as you can see (server clock is off by 1 or my watch is <g>), the
server does try to send out a 421 reply code and in TELNET you will
most likely see this.
But I don't think that a dedicated SMTP client will be ready to see
that 421 - or rather we can't presume it is designed to be ready to
read and see it. We don't know.
Does anyone have experience with other MTAs? It's a simple experiment.
Overall, I found when server drops logic was used, unwanted
retransmissions occur due the SMTP's implicit client 451 reply code
assumption. I did not find any other way but to allow the client to
terminate gracefully within the provided time limits.
--
Sincerely
Hector Santos
http://www.santronics.com