WHM/cPanel: Default to blackhole

Big Dan

EQ Forum Moderator
Spammers are some shady characters and lots of times they will dictionary attack a mail server. That means they will try common name/word combinations against a domain in hopes that 1 or 2 get through. The may try say [noparse]asmith@domain.com, bsmith@domain.com,[/noparse] etc, etc.

What happens is now your server spends a whole bunch of time and wastes resources sending bounce messages to all the addresses to do not exist. It's is just plain wasteful all around. You would rather have your server serving web pages than useless bounce messages.

To set this up you must log in to Web Host Manager as root and set the default action to blackhole.

Log to WHM, click tweak settings, scroll down to the mail section and under "Default catch-allo/default address behavior for new accounts" select blackhole and save your settings. Here's a screenshot:

WHMblackhole.JPG

Please note this will not effect existing accounts those you most login to individually and configure blackhole under mail settings.
 

EQ Admin

EQ Forum Admin
Staff member
What happens is now your server spends a whole bunch of time and wastes resources sending bounce messages to all the addresses to do not exist. It's is just plain wasteful all around. You would rather have your server serving web pages than useless bounce messages.
I understand that users of control panels often do not have full control of their servers and that blackholing may be the best available option, although generally this is not the fix I would use to address this problem.

I agree that accepting an e-mail you are guaranteed to bounce later is bad. The result of this problem is known as backscatter. The best thing to do is not accept an e-mail that is going to be bounced later by enabling valid recipient checking on a mail server. I am a qmail user, and use the chkuser patch mentioned in the backscatter article on my incoming mail servers.

A side effect of blackholing is that legitimate bounce messages are never created. If someone accidentally mistypes an address to someone in your domain they will not get a bounce message and know that there was a problem. Another possible problem is that if your server does spam content filtering checks as it is receiving e-mails you may be wasting CPU cycles scanning e-mails that are heading to the bit bucket.

By enabling valid recipient checking you fix the backscatter problem by never accepting an e-mail you are later going to bounce. A minimal amount of resources is used, typically slightly more than an RBL check. It is also possible to log the invalid recipient errors and block IP addresses generating a high percentage of error from making connections at all with either a local blacklist or by firewalling them of from being able to connect to your mail server.

Enabling valid recipient checking does mean that it is technically possible for a spammer to quickly make many connections to your mail in an attempt to generate a list of valid recipients who can later be spammed. As I mentioned this problem can be monitored for and resolved with local backlistings. When measured against the other problems mentioned above I'd rather have to deal with monitoring my logs and blocking sources generating a high volume of user unknown errors (all low resource activities) than potentially break expected e-mail functionality for my users.

On a standard mail server I will have the following measures in place, in this order as an e-mail is received:

At the border before the connection reaches an actual mail server:

  • A few IP addresses that caused ongoing problems may be blocked at the firewall
  • Our F5 load balancer also happens to check TrustedSource.org
Checks that are performed by the mail servers themselves:

  • Is the IP address allowed to connect?

  1. Permanently reject (5xx) IP addresses in public RBL's
  2. Temporarily defer connections (4xx) from IP addresses in my local blacklist

  • Is the e-mail destined for any invalid recipients? If so permanently reject the connection.
  • Does the email contain executable content? If so, drop the connection.
  • Does the e-mail contain a virus? Check with ClamAV

  • At this point, if the e-mail has not failed any checks, it begins to work it's way through a users personal preferences. These can include personal whitelists, personal blacklists, forwards, and resource intensive spam checks such as checking the e-mail with SpamAssassin.
I think that about covers it. There are more checks but those are the big ones.

My goal is to give the reader a wide range of options so they can choose which features are best for them and their users.

-Raymond
 

Big Dan

EQ Forum Moderator
Thanks Ray. You've posted a lot of information for me to swallow. You're the mail expert. I know a lot less about the server side then client side. :) Personally I don't do any server side spam or virus checking since I forward into Gmail I consider it a waste of my resources. I let Gmail take care of that. Anyone else who runs mail from my domains, I warn that their virus scanner should be kept up to date. Most I talk into forwarding into Gmail anyhow. ;)

For my production domains I have catch-alls setup but I never thought about legitimate typo bounces.
 
Top