Slow 250 response after Mail From command is issued during an SMTP session.

Applies to All Versions of SmarterMail

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 Security -> Anti-Spam Administration -> 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 Security -> Anti-Spam Administration -> 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 Settings -> 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. You will then want to stop the SmarterMail service, and ensure mailservice.exe is no longer running within the Windows task manager. Then start the service back up.
 
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 Security -> Anti-Spam Administration -> 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.
 
This process has been made easier with SmarterMail 12.x, under Security -> Anti-Spam Administration -> Spam Checks, there will be MS indicators next to your Spam Checks that show how long the RBL\URIBL is taking to respond. If any of these are taking longer than 10 seconds to query, ATTENTION NEEDED will be flagged next to it. Simply disable any SMTP blocking check that has this flagged and you should notice an improvement in the 250 response after the mail from command has been issued.

 

Learn more about SmarterMail's enterprise email features and benefits.

Feedback

Add Feedback
Awesome - just what I was looking for - debugging this issue and had come tot he conclusion it was spam checking / rdns type issue. Thanks for this.
Shane

Shane Hollis (February 23, 2016 at 5:22 PM)

Add Feedback