Sometimes SmarterMail can exhibit some behavior in which servers sending to your SmarterMail environment encounter a large delay after the Mail From command has been issued. When this occurs there will be entries in the SMTP log that look similar to the session below:

07:17:57 [xxx.xxx.xxx.xxx][27654292] rsp: 220 mail.smartertools.com
07:17:57 [xxx.xxx.xxx.xxx][27654292] connected at 25/03/2014 07:17:57
07:17:57 [xxx.xxx.xxx.xxx][27654292] cmd: EHLO mail.google.com
07:17:57 [xxx.xxx.xxx.xxx][27654292] rsp: 250-mail.smartertools.com Hello [xxx.xxx.xxx.xxx]250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-STARTTLS250 OK
07:17:57 [xxx.xxx.xxx.xxx][27654292] cmd: MAIL FROM:<user@domain.com> SIZE=33717
07:18:57 [xxx.xxx.xxx.xxx][27654292] disconnected at 25/03/2014 07:18:57
07:20:37 [xxx.xxx.xxx.xxx][27654292] rsp: 250 OK <helpline@nectar.com> Sender ok

 

In this session you can see that the sending server issued the Mail From:<user@domain.com> command, and that the server took over 2 minutes to respond with a 250 OK. By the time this command was issued, the sending server has already disconnected. This leads to a permanent failure on the sending servers side and mail never arrives.

 

When the Mail From: command is issued, SMTP Blocking checks are run based on the checks you have specified under Antispam ->  Spam Checks. These are DNS-based checks that validate the IP address of the sending server against publicly accessible black lists.

 

With that being said, one of two things can be occurring.

 

1. Your DNS provider is having issues with DNS lookups. This can range from issues with latency, problems with DNS forwarders, etc. If your DNS servers are provided to you by your ISP, you will want to reach out to them to see if they are experiencing any issues. 

 

2. One or more of the RBL\URIBL checks specified under Antispam -> Spam Checks could be timing out.

 

To troubleshoot scenario 1, you can modify your DNS server to use Google's Public DNS. This is configured under General Settings -> Server Info.

 

For the Primary DNS server you can specify 8.8.8.8 and for the secondary server you can specify 8.8.4.4. Once these have been set, click Save.

 

Now to test this, you can telnet to the IP address of your server over port 25 and enter in the following commands:

 

EHLO

The server then should then issue a 250 response.

Then enter in Mail From: test@example.com

You should then receive a 250 - Sender OK response

 

If the 250 response is not received promptly there may be an issue with a single RBL\URIBL check that is hanging the process.

 

To test scenario 2, navigate to Antispam -> Spam Checks and disable all Incoming SMTP blocking checks with the exception of SPF, RDNS, DKIM, and Domain Keys and save your settings.

 

Perform the same telnet test as outlined above and see if the response time has improved. If it has, slowly add your SMTP Blocking checks back in place, and perform the telnet test again to see if the issue persists. Once the issue resurfaces after adding a couple checks, this should tell you which RBL was responsible for the slow response.