DNS Caching on Anti-Spam Checks

Idea shared by Scarab - 4/28/2015 at 3:35 PM

Under Consideration

We have been primarily using Bruce's excellent Anti-Spam guide with Smartermail, however our mail volume is beginning to exceed the Terms of Service for many of the Anti-Spam checks. After receiving warning emails from many of the RBLs used in Bruce's Anti-Spam guide we are facing having to reduce the number of RBLs and URIBLs we use by 33%-50% to reduce the number of queries to acceptable levels.

Generally Spam that comes in is dumped in lots of 300 - 3000 messages that are exactly the same from the same Mail Server. Rather than make 300-3000 RBL checks for the same IP or URIs, it would seem more efficient to have a caching mechanism where if the results of the last query was cached Smartermail wouldn't do another query but use the last result. This would dramatically reduce the number of queries being made to RBLs and URIBLs.

Is it possible currently to utilize caching in Smartermail Anti-Spam checks? If not, could this be seriously considered as a new toggle-on feature for an upcoming version of Smartermail?

7 Replies

Reply to Thread

Employee Replied

4/28/2015 at 4:01 PM

Employee Post

Scarab, that is a great idea. I have added this to our features request list. I like your think of including a toggle checkbox so the system admin can elect to use or not use a cached RBL/URIBL check. Additionally, I see the benefit of including an entry to cache time limit: after the specified time, SM would be required to make another actual RBL/URIBL check.

What other ideas do you or anyone else of have pertaining to this feature request?

Bruce Barnes Replied

4/28/2015 at 6:47 PM

I think this is a great idea.

The alternative is to cache the entire spam database locally and update periodically from the source.

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

Joe Wolf Replied

4/28/2015 at 7:07 PM

First off I'm not trying to be a jerk in any way, but I think SmarterMail should stay out of the DNS business. I would never recommend using the existing SmarterMail DNS caching system as well. It's dangerous to cache any DNS record beyond its TTL. Those are stale records and shouldn't be used.

The default TTL most RBL / URIBL is 120 seconds. So if your DNS resolver simply honors the default TTL it would not query the same RBL / URIBL for the same query within the TTL of the record. They use a 120 second TTL for a reason... things change rapidly on the Internet. What was a good domain 5 minutes ago could be spewing out millions of spam messages right now (and vice versa).

If you WANT to cache records then you can do so if you run your own DNS resolver. You just set your server to force a minimum TTL to whatever length of time desired. I think it's a bad idea, but it's easy to do if you wanted to do it.

Again, I don't think that SmarterMail should be in the DNS business other than to properly query the DNS resolvers you define as the System Admin. Any DNS caching rules should be set up on your DNS resolver... not SmarterMail.

Our practice is that we honor TTL up to 4 hours. In other words even if a DNS query has a TTL of 86,400 seconds (a popular TTL that many use) we will only honor the TTL up to 14,400 seconds. Too many things change in a day... domains transfer, etc. and not everyone knows how to use DNS properly (or I should actually say there are few that know how to use DNS properly).

Thanks, -Joe

Bruce Barnes Replied

4/28/2015 at 8:36 PM

Joe, I think the original poster was talking about caching the RBL query responses.

However, your DNS post also raises questions about this, as an invalide RBL listing, which has been purged, but is still in a cache on a local server, might penalize a legitimate sender.

Good points.

Joe Wolf Replied

4/28/2015 at 9:32 PM

Thanks Bruce. The TTL on a RBL or URIBL is 120 seconds for a reason. They would love to make it longer but it would be irresponsible to do so. It's not OK to block a valid sender (which can change in less than 60 seconds) or vice versa. The RBL / URIBL people know what their doing and have a 120 second TTL for a very VALID reason. To cache a stale DNS record is WRONG under ANY circumstances.

Thanks,
-Joe

Thanks, -Joe

Bruce Barnes Replied

4/28/2015 at 9:59 PM

As I said, Joe, you brought up a valid point.

The alternative is to subscribe to the RBL feed and cache it locally - making certain to download fresh updates frequently.

Joe Wolf Replied

4/29/2015 at 12:16 AM

The bottom line is that SmarerMail shouldn't be in the DNS business. If you want to fail to honor DNS TTL then that's a DNS resolver issue... not SmarterMail. -Joe

Thanks, -Joe

Back to Community Threads

Please leave this box unchecked

7 Replies

Reply to Thread

Tags

Related Knowledge Base Articles