-
Type:
Suggestion
-
Resolution: Invalid
-
None
-
Component/s: Enterprise
Some mail servers and mail proxies treat the NOOP SMTP command as a trigger to slow down communication between the mail client and the mail server resulting in delayed mail delivery.
Important: it is important to note that some anti-virus software interfere with normal SMTP operations and can be the root cause of incorrect command pipe lining of SMTP commands. I have not investigated this in detail, because this is outside of the scope of this story.
Sendmail by default only allows 20 NOOP instructions before closing the connection to the mail client. A snippet from the O'Reilly Sendmail (4th edition)
Prior to V8.14, the only way to change the limit on useless commands was to change the setting for the MAXNOOPCOMMANDS compile-time macro in sendmail/srvrsmtp.c. Beginning with V8.14, however, you may override that default with your own limit by setting this MaxNOOPCommands option, which is declared like this: O MaxNOOPCommands=num ← configuration file (V8.14 and later) -OMaxNOOPCommands=num ← command line (V8.14 and later) define(`confMAX_NOOP_COMMANDS',`num') ← mc configuration (V8.14 and later) Here, num is of type numeric. If num is negative, non-numeric, or zero, no limit is placed on the number of useless commands that the client may send. If this option is entirely omitted, the default is the original value of 20.
From a bug report to Sendmail:
We have some code that sends out emails to our customers. The way our code is currently written, it uses the SMTP NOOP command to see if the connection is still open. We deployed it over the weekend and everything worked, but we noticed that emails were being sent out *very* slowly, at the rate of one every 4 minutes. After a lot of debugging, it turns out that sendmail, after about 20 NOOP commands, starts delaying the responses to these, 1 second, 2 seconds, 4 seconds, etc., up until 4 minutes. This is an antispam feature apparently.
Postfix documentation indicates that they don't recommend clients sending NOOP commands to keep network connections alive. The reasoning is not clear, but they seem to imply that it results in extra server load to keep these IDLE connections open. The text below taken from postfix.org documentation about how to configure Postfix as a production mail server.
Use an smtpd_junk_command_limit of 1 instead of the default 100. This prevents clients from keeping idle connections open by repeatedly sending NOOP or RSET commands.
Microsoft Exchange Server also seems to be affected, eventually closing the connection to the mail client with the following message:
NOOP 250 2.0.0 OK NOOP 250 2.0.0 OK NOOP 250 2.0.0 OK NOOP 250 2.0.0 OK 421 Too many errors on this connection---closing
The general trend seems to be open a connection when required, send emails and disconnect. NOOP and RSET commands can be used to keep connections alive but they should be avoided.