Spam filtering speed
Question asked by Matthew Titley - January 5 at 12:08 PM
Unanswered
Hi all, 
 
I've received complaints regarding the length of time that Smartermail takes to analyze and accept messages during the spam filtering process. Trying to speed up the process I disabled all spam tests save for my Cyren/Commtouch Antispam subscription which has made a difference but message scanning still ranges from 15 seconds to a minute or so before delivery to a local inbox. Local messages don't have this problem as they're already authenticated and thus skipped.
 
All I have for tests right now are Cyren. Previously, I had Cyren/Declude/ and a slew of RBLs. Could this be a lookup turnaround time issue or more of a server processing/performance issue? It bothers me in that when I send a test email from Gmail, the server receives it practically instantly but then I watch it sit in the spool queue tagged with "Spam Check" for some random length of time up to a minute prior to deliver. Any ideas would be helpful in trying to speed this up. 
 
Thanks,
 
Matt

1 Reply

Reply to Thread
0
Scarab Replied
Matt,
 
The primary delay in mail delivery would be due to the SETTINGS > GENERAL > SPOOL > DELIVERY DELAY setting. The default is 1 sec but depending on what command-line checks and antispam checks you are running you may have to increase this setting to 3-5 secs. Just make sure that this setting isn't set too high and causing the delay you are experiencing.
 
However, if this setting is low but delivery is still taking upwards of a minute then check your average time in SETTINGS > ANTISPAM > RBL LISTS & URIBL LISTS (assuming that you are on a recent build of v16). If there is one taking longer than 1000+ ms that could be the culprit, and if they all are taking longer than 1000+ ms that is definitely the problem (I had this problem on an Incoming Gateway with Win2K8R2 Server where RBLs & URIBLs were taking 20,000+ ms, whereas on Win2K12 the same RBLs & URIBLs took under 70ms on the same network using the exact same DNS Servers...never did run the cause to ground although I pulled my hair out trying). 
 
It certainly could also be latency from your DNS Servers, I would suggest running a DNSPERF and RESPERF to do the following steps from your Mail Server:
 
  1. Test the latency between the stub resolver and the DNS Resolver.
  2. Test the recursion between the DNS Resolver and the DNS Authority.
  3. Test the internal DNS Resolver delays.
     
If you have disabled all antispam checks and still experiencing slow delivery then the next thing I would check is your Peak & Avg load CPU and Memory usage. For an example, although the volume of our mail load has remained consistent over the years and our Avg CPU load has never gone above 3-5% we've had to add additional Incoming Gateways and upgrade them 4 times since SmarterMail 4.X to handle the ever increasing Peak demand on CPU & Memory which would top out at 100%...and still despite every upgrade our Spool still occasionally chokes @4 times a year due to Peak traffic resulting in 100% Peak CPU usage which causes delivery delays.
 
All in all, the problem you are experiencing isn't most likely going to be simple to find (although when all else fails, have you tested your network cable and tried using a different port on your switch?). Ultimately a 1m delay in delivery isn't terribly bad considering RFC allows up to 96 hours for email delivery (although I have seen overly zealous 2FA that are set to 60-120 seconds verification windows so that can definitely be a problem when delivery takes > 1m). When you are working on lowering delivery below 1m the task is challenging as it can be caused by many different things from you registry settings for your network stack, cabling, routing, DNS, CPU and more. You might end up having to install Wireshark on your Mail Server and taking a look at the packets to figure out where the delay ultimately is. 

Reply to Thread