This article applies to:

• Trustwave MailMarshal (SEG)

Symptoms

• Slow incoming email
• Multiple receiver threads active
• Number of receiver threads at maximum
• Multiple connections from the same external host
• Internal email server shows outbound messages queued to be sent through MailMarshal.

Causes

Potential causes include

• Spam attack
• DHA (Directory Harvest) attack
• DoS (Denial of Service) attack
• Network connectivity issues

Information:

Email moving very slowly through a MailMarshal SMTP server can be a sign of malicious activity such as a Denial of Service or Directory Harvest attack. It could also be due to a wave of spam.

You can make a number of configuration changes in MailMarshal that will help to reduce the effects of these problems.

Checking for problems:

You can check for many of the symptoms mentioned above by using the MailMarshal Console.

• Expand Servers or Mail Servers, and view the information for each server.
  • Check the number of Receiver threads in use.
  • View the Receiver item for each server and check the details of connections and messages being received. When you refresh this view you should see changes in status, and different servers connecting.
  • If there are many connections persisting, connections not progressing past initial greeting, or similar connections being created repeatedly, that could indicate a problem.

General recommendations:

• Upgrade MailMarshal to the latest version. Recent versions have enhanced protection against many of the possible causes.
• Enable DoS and DHA protection. In the Management Console (10.0 and above) or the Configurator (8.X), see Array Properties > Receiver > Attack Prevention. Background information about DoS and DHA is available in the MailMarshal User Guide. Details of the configuration steps are provided in Help.
• Implement Anti-Spam Best Practices. See the suggestions in Q10810: What are MailMarshal SMTP anti-spam best practices? This article also has links to further information.
• Configure Receiver binding: If your server has multiple network interfaces, you can ensure that outgoing email has priority by setting limits on the Receiver threads available to each interface. See Q10249: How do I change the default SMTP ports in MailMarshal SMTP?

Additional Steps:

You can make temporary changes in some MailMarshal settings that can help to decrease delays.

• Block hosts with receiver rules: Even if you don't normally use DNS Blocklist rules at the Receiver, you can reduce server load by enabling these rules. Note that the lookups also take time, so it is best not to enable more than one or two. 
  • The Marshal IP Reputation Service is a blocklist maintained by Trustwave and included with all MailMarshal subscriptions. 
  • Spamhaus ZEN is another generally effective list (it may require payment to Spamhaus, see article Q12009).
• Block hosts by name or IP address: If you identify specific external servers that are creating malicious load, you can refuse connections from those servers. See Array Properties > Receiver > Blocked Hosts.
• Increase Receiver threads: If the delays seem to be related to legitimate email, you can increase the number of available Receiver processing threads. See Array Properties > Advanced > (Additional Options) > Server Threads. You can manually increase the number of threads up to 200.
  • In a DoS attack situation, this action probably won't help.
• Lower timeout values: You can improve availability of the Receiver by reducing the time that MailMarshal waits for a response. In most cases legitimate email servers respond quickly.
  • You can change the timeouts for the initial connection and send/receive responses from the MailMarshal Configurator > Server and Array Properties > Advanced > (Additional Options) > Times. In particular, you can lower the Initial Greeting setting to 30 seconds.
  • An additional value can be set in the Registry. See Q10399: How do I lower the Receiver socket timeout value?

Notes:

You should monitor the effects of these changes carefully. Aggressive use of blocking and lower timeouts can cause legitimate email to be refused. In most cases you should return to the default values once a particular situation is resolved.