Enhance spam prevention with Domino's blacklist scanning exceptions

In this tip, an administrator explains the steps he has taken to block spam and reduce false positives -- all without the use of third-party products or services.

DNS Blacklist scanning is currently, in my opinion, the most powerful form of spam prevention that is included free with Domino. The difficulty is choosing which lists to scan, primarily for two reasons: performance and false positives.

Performance: At one point I was scanning 10 different lists in response to the ever-increasing volume of incoming spam. Although the desired effect was adequately achieved, the price was a delay in all incoming mail, since Domino had to scan all 10 lists on legitimate messages before delivering them. This issue was relieved somewhat when I pulled statistics on how many messages were being blocked by each list and resorted them to be scanned in order of likelihood of a match. Of the nearly 14,000 messages our servers now block every day, approximately 11,000 are blocked by a hit from sbl-xbl.spamhaus.org, so the server's work is done after scanning a single list for the majority of incoming messages. But on approximately one million spam messages annually, the server still has to query up to six more lists before it decides to block the message.

False Positives: When scanning any blacklist, you put yourself at the mercy of its owner. A quick way to incur management's ire is to sever the connection between local operations and a contract manufacturer by scanning a blacklist whose owner suddenly gets carried away and decides to block all of China. The performance issue associated with scanning numerous lists can be mitigated somewhat by scanning fewer but more aggressive lists, but the rate of false positives will spike, and I think most of us would agree that receiving the occasional nuisance message is preferable to rejecting a message that could mean the difference between closing and losing a multi-million dollar deal.

Domino Administrator Help states, "Any host that is authorized to relay is exempt from blacklist checks." Herein lies a powerful option. For most organizations, it isn't a viable approach to switch from blacklisting to whitelisting, which is defined as only accepting connections from a server that's already on the list -- or treating your SMTP server like a trendy nightclub. However, unless addition of valid senders to the list is automated -- which often introduces new risks of spammer exploitation and/or has a hefty price tag attached to it -- maintaining it can be a full-time job.

The majority of our contacts are not on any blacklist and should not have to be specifically listed before they are allowed to e-mail us. This may or may not be true of your organization depending on your industry and the geographical location of other organizations with which you conduct business. Because Domino allows us to combine the two lists, we can block messages if the sender is blacklisted, but not if we've also whitelisted them.

So here's three steps I now use to approach spam prevention:

1. I've updated the custom SMTP response to rejected messages, specifying our IT hotline number and instructing senders to call us to report delivery failures. At first I was a bit nervous about providing department contact information to spammers, but then I remembered that spammers don't actually read delivery failures. If an actual human sees that number, he or she is most likely someone we want to be able to find us.

2. I've replaced a couple of the safe but relatively ineffective blacklists with slightly more aggressive lists. I don't, however, advocate going overboard and blocking a list like BLARSBL or JAMMDNSBL.

3. When the inevitable occasional false positive is encountered, I query the list that is blocking the sender's IP address. If it turns out they're blocked because they're an open relay, I request that they resolve the issue and get de-listed. However, if they're being considered "guilty by association" -- blocked because other users of their ISP have misbehaved and the entire netblock is now listed -- I add their IP to the list of hosts allowed to relay. This signals Domino to skip blacklist scanning for any messages from them.

Ever since implementing this combination, we receive very little spam. At first, we were averaging approximately one false positive a week. That's dwindled to one every month or two, because any of our existing contacts that are on blacklists have already been added to our exception list. We now only have to update the list when we begin dealing with a new customer or vendor -- and only if they're on a blacklist that we scan -- or if an organization we have already been dealing with suddenly gets listed.

Do you have comments on this tip? Let us know.

Please let others know how useful it is via the rating scale at the end of the tip. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.

This was first published in July 2005

Dig deeper on Lotus Notes Domino Antispam Software and Spam Filtering

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWinIT

Search400

  • iSeries tutorials

    Search400.com's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...

SearchEnterpriseLinux

SearchVirtualDataCentre.co.UK

Close