Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
TidSmtpServer hangs on some connections
#1
Hi,

I am hoping for some advice on how to proceed to resolve the following incoming mail issue.

Ordinarily transactions come in like this and are handled perfectly
Code:
70.xxx.xxx.xxx:55906 Stat Connected.
70.xxx.xxx.xxx:55906 Sent 1/6/2019 6:36:45 PM: 220 Welcome to WWOL Server<EOL>
70.xxx.xxx.xxx:55906 Recv 1/6/2019 6:36:45 PM: EHLO mx01.kmtel.com<EOL>
70.xxx.xxx.xxx:55906 Sent 1/6/2019 6:36:45 PM: 250-Hello mx01.kmtel.com<EOL>250-AUTH LOGIN<EOL>250-ENHANCEDSTATUSCODES<EOL>250-PIPELINING<EOL>250-SIZE 0<EOL>250-CHUNKING<EOL>250-8BITMIME<EOL>250 BINARYMIME<EOL>
70.xxx.xxx.xxx:55906 Recv 1/6/2019 6:36:45 PM: MAIL FROM:<MAILER-DAEMON@kmtel.com> SIZE=10078<EOL>
70.xxx.xxx.xxx:55906 Sent 1/6/2019 6:36:45 PM: 250 2.1.0 MAILER-DAEMON@kmtel.com Address Okay<EOL>
70.xxx.xxx.xxx:55906 Recv 1/6/2019 6:36:45 PM: RCPT TO:<info@domain.com><EOL>
70.xxx.xxx.xxx:55906 Sent 1/6/2019 6:36:45 PM: 250 2.1.5 info@domain.com Address Okay<EOL>
70.xxx.xxx.xxx:55906 Recv 1/6/2019 6:36:46 PM: DATA<EOL>
70.xxx.xxx.xxx:55906 Sent 1/6/2019 6:36:46 PM: 354 Start mail input; end with <CRLF>.<CRLF><EOL>
however for some the negotiation looks like this
Code:
52.xxx.xxx.xxx:60351 Stat Connected.
52.xxx.xxx.xxx:60351 Sent 1/6/2019 6:34:44 PM: 220 Welcome to WWOL Server<EOL>
52.xxx.xxx.xxx:60351 Recv 1/6/2019 6:34:44 PM: EHLO NAM01-BY2-obe.outbound.protection.outlook.com<EOL>
52.xxx.xxx.xxx:60351 Sent 1/6/2019 6:34:44 PM: 250-Hello NAM01-BY2-obe.outbound.protection.outlook.com<EOL>250-AUTH LOGIN<EOL>250-ENHANCEDSTATUSCODES<EOL>250-PIPELINING<EOL>250-SIZE 0<EOL>250-CHUNKING<EOL>250-8BITMIME<EOL>250 BINARYMIME<EOL>
52.xxx.xxx.xxx:60351 Recv 1/6/2019 6:34:44 PM: MAIL FROM:<> SIZE=83225<EOL>RCPT TO:<info@domain.com><EOL>
52.xxx.xxx.xxx:60351 Stat Disconnected.
the difference here is the remote server is compounding the mail from and rcpt to transactions into a single transaction and when this happens Indy never responds to the transaction and the thread hangs until it is cleaned up several minutes later.
Unfortunately several domains including the microsoft domains do this and for me this constitutes a very large number of messages.  
I am hoping someone can advise a way to work around this issue.

Thanks for any guidance,
-Allen

I experienced the issue above with PIPELINING set to true.  Changing that to false causes everything to function as expected.  

I guess that answers my question, sorry for the silly question, unless there is something I ought to have done to enable pipeling to function properly.

-Allen
Reply
#2
(01-06-2019, 07:50 PM)bluewwol Wrote: however for some the negotiation looks like this

The client is utilizing Command Pipelining, due to the existence of the PIPELINING capability in the server's EHLO response (which means you intentially set the TIdSMTPServer.AllowPipelining property to true, as it is false by default). That basically just means the client can send a batch of multiple commands in the same TCP send block without waiting for a response in between each one, and then it can read all of the responses after sending. TIdSMTPServer will still process and reply to each command individually.

(01-06-2019, 07:50 PM)bluewwol Wrote: 52.xxx.xxx.xxx:60351 Recv 1/6/2019 6:34:44 PM: MAIL FROM:<> SIZE=83225<EOL>RCPT TO:<info@domain.com><EOL>
52.xxx.xxx.xxx:60351 Stat Disconnected.[/code]

the difference here is the remote server is compounding the mail from and rcpt to transactions into a single transaction and when this happens Indy never responds to the transaction and the thread hangs until it is cleaned up several minutes later.

That happens because that client did not send a DATA or BDAT command after RCTP in the "transaction".

When TIdSMTPServer detects pipelining is being used while processing a MAIL, RCPT, or RSET command (because there are more commands already waiting on the socket), TIdSMTPServer caches subsequent responses, and then currently flushes the cache only when:

1. the DATA/BDAT response has been cached, and TIdSMTPServer is ready to read the client's email data.

2. the client sends an AUTH, STARTTLS, NOOP, or QUIT command.

Reading RFC 2920, it seems that TIdSMTPServer does not implement all of the required server-side processing for pipelining, in particular all of the cases when it should flush the response cache, so I will have to look into fixing that (I have opened a ticket in Indy's issue tracker: #239 Pipelining is broken in TIdSMTPServer). In the meantime, you should disable pipelining, by resetting the TIdSMTPServer.AlowPipelining property back to false.

Reply
#3
Remy,


As always thank you for your considered and thorough answers.  My project currently has no real requirement for pipelining and if I can find some time in the next few weeks I will be happy to contribute some effort in this direction. 

Thanks again for your assistance,

-Allen
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)