Hi all, In the brief SMTP session shown below: 220 myExchange Microsoft ESMTP MAIL Service ready at Mon, 25 Jul 2011 12:40:31 +0100 NOOP 250 2.0.0 OK ...there is a five second gap between issuing the NOOP command and Exchange replying with the 250. Why so long? Is this delay configurable? many thanks, alec

Seems like Exch tarpitinterval - http://technet.microsoft.com/en-us/library/bb125140.aspx Adjust this if you wish. Sukh

Hi Sukh, Yes, that's exactly it. Thanks for your help! alec

On Mon, 25 Jul 2011 11:44:18 +0000, Alec Waters wrote: >220 myExchange Microsoft ESMTP MAIL Service ready at Mon, 25 Jul 2011 12:40:31 +0100 NOOP 250 2.0.0 OK > >...there is a five second gap between issuing the NOOP command and Exchange replying with the 250. > >Why so long? Is this delay configurable? Tarpitting. If your intention is simply to keep the SMTP session alive then 5 seconds shouldn't matter. Just send the NOOP less frequently (or adjust the tarpit interval). Or stop sending NOOP and just terminate the session when you're done sending. The NOOP is frequently used by directory harvesters and spammers which is probably why it's encountering that delay. Keep in mind that the intention of tarpitting is to prevent directory harvesting. It's also an abuse of the RFCs governing the way SMTP works (no matter what you set the tarpit interval to you're bound to screw up something). Turning tarpitting off _probably_ won't affect anything with SMTP except allow more frequent submission of SMTP commands. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich, Thanks for the reply. We use an application that sends frequent emails; before each one is sent, it connects to the mailserver and sends a NOOP before disconnecting. It then opens a second TCP connection and proceeds to send the email. I don't know why it does this; my best guess is that the NOOP is a check that the mailserver is alive and well, but it seems a totally redundant operation to me - any error condition would become apparent during the course of sending the email anyway. The net effect of the tarpitting in my case was to slow down the sending of emails to the point that they were being generated faster than they could be sent with the five second tarpit overhead, leading to a messaging backlog. Turning off the tarpitting has gone a long way to solving this issue for us. Thanks again, alec

Related: http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/ Mike Crowley | MVP My Blog -- Planet Technologies

On Mon, 25 Jul 2011 22:03:30 +0000, Alec Waters wrote: >We use an application that sends frequent emails; before each one is sent, it connects to the mailserver and sends a NOOP before disconnecting. It then opens a second TCP connection and proceeds to send the email. > >I don't know why it does this; my best guess is that the NOOP is a check that the mailserver is alive and well, but it seems a totally redundant operation to me - any error condition would become apparent during the course of sending the email anyway. The NOOP's only function is to keep a connection from timing out without actually doing anything. Back in the days of dial-up connections and slow machines it served a purpose (but so did UUCP!). Replace that NOOP with a RSET and you'll be happier. :-) >The net effect of the tarpitting in my case was to slow down the sending of emails to the point that they were being generated faster than they could be sent with the five second tarpit overhead, leading to a messaging backlog. Turning off the tarpitting has gone a long way to solving this issue for us. If the application is single-threaded I can understand its slowness. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Tue, 26 Jul 2011 23:34:20 +0000, Mike Crowley wrote: >Related: http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/ Good point. One way to get away from this with that single-threaded application is to have it send its e-mail to a plain old Windows SMTP server) or Sendmail, Postfix, EXIM, etc.) and let a real SMTP server handle the message delivery (and any error conditions). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP