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?
- Permanently reject (5xx) IP addresses in public RBL's
- 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