Build 7523, URIBLs changes?
Problem reported by Eric Tykwinski - 8/10/2020 at 6:08 AM
I just upgraded our server from 7242 to the new version, and everything seemed to be okay until I came in this morning.  Spool was rather backed up, so I started investigating and noticed that all URIBLs went from 1-2 seconds to 30-40 seconds thus causing the backup.  We run our own Unbound caching server and response times have not changed.  We graph respose times in RRD.  Is there something in the new version that changed with the spam check?

4 Replies

Reply to Thread
Steve Norton Replied
I also went from 7242 but to 7503, I'd only read the changes to that point and was satisfied that there were no gotchas... so wrong. 7482 states 'Fixed: Some RBLs or URIBLs are taking an excessive amount of time to resolve, which causes spool delays.' My URIBL average times went up just like yours and after looking into the network communications I found that mailservice.exe spends an excessive amount of time trying to talk to a configured DNS server that spends most of its time offline. I’ve removed the IP address of the offline backup DNS server and times spent in spool have gone down from 20 minutes to 20 seconds.
My DNS offline/online configuration is nothing new so the difference appears to stem from the changes in 7482.
Dear support, I see that SM does its own DNS lookups rather than using the OS, there needs to be code that detects dead DNS servers and only retries them every xx minutes or on a service restart.
Robert Emmett Replied
Employee Post
@Steve, that is a wonderful idea of retaining a copy of dead DNS servers with a limited retry or not until service restart. I have added this to our list.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
Steve Norton Replied
I also note that SM does no honour OS level DNS server address changes, during a DR exercise I moved to a new DNS server IP address at the OS level (old server taken offline) which resulted in hours of mail issues until I noticed/restarted the SM service.
Ron Raley Replied
Likely so.  The Primary and Secondary DNS settings must be entered into SmarterMail settings.  I have not seen a setting to have SmarterMail adhere to operating system DNS.  Probably a good idea.


Reply to Thread