Mail server configuration and recipient filtering

What settings should be set up to manage the receipt of emails from non-existent users? Today, there are generally two options for dealing with non-existent users on a mail server.

The first option, known as “bounce”, was historically the default on all mail servers. During communication between the sending server and the receiving server, the message is systematically accepted by the receiving server, for further processing. Since recipient verification is carried out a posteriori, if the e-mail fails to be delivered, the server must create and send an e-mail called a bounce, the purpose of which is to inform the sender of the original message that his e-mail was unsuccessful.

The second option is in-protocol analysis for recipient filtering. During the email transmission phase, the recipient server tells the sender server directly that the recipient does not exist. To do this, during the SMTP transaction, after the RCPT TO, it simply sends a 500 refusal code. In this case, the sending server is directly responsible for informing the user that the message could not be delivered.

There are many arguments in favor of the second setting, and we’ll list some of them here.

1. In the case of bounce, accepting all emails and only processing them later saturates the customer’s mail server unnecessarily. In this case, not only does the incoming mail have to be processed and stored, but the mail server also has to use additional machine resources to generate the bounce. For each erroneous e-mail received, the server must consume twice as many resources as for a standard e-mail!

2. Certainly due to the upsurge in spam, bounces are increasingly considered as spam. Like spam, these are unsolicited messages. All the more so as it’s not uncommon to receive bounces on emails we didn’t originate, simply because a spammer has used our email address to send spam. As more and more anti-spam software is refusing to accept these e-mails, the sender is never informed that his message has not been delivered.

3. For each incorrect address, a bounce is sent. The mail server therefore generates an unnecessary flow of email. We complain that over 80% of the world’s e-mail traffic is now spam, and the proportion of bounces is not negligible.

4. As mentioned above, some spammers use spoofed third-party e-mail addresses to send their spam. This is why users sometimes find themselves inundated by bounces, even though they are not the originators of the original message. Some people find themselves really bombarded and saturated with emails they have no use for.

5. Worse still, these bounces may well be sent to bogus senders who are actually blacklist spamtraps. Many notorious blacklists use spamtraps to generate their mailing lists. In this case, these spamtraps receive a large number of e-mails from your mail server IP. As a result, your mail server could very quickly find itself blacklisted.

Conversely, the only argument put forward for keeping the bounce configuration is that it would be easy for a malicious person to reconstitute the list of active e-mail addresses in the company, by “brute-force” testing of all possible combinations. However, that’s forgetting that this is also possible in bounce mode, in which case all you have to do is analyze the emails returned in error – the bounces! Addresses for which no bounces are received are valid addresses. This makes it easy to build up a list of valid addresses.

As mentioned above, most mail servers used to be configured to bounce, because there wasn’t too much traffic and, above all, there was little or no spam. Today, all the major e-mail software publishers have gone back to this configuration and integrate our second option – on-the-fly recipient analysis – into the SMTP protocol as standard. Under Lotus, the setting associated with this configuration is called: “Check that local domain recipients exist in the Domino directory”, under Exchange it is : “Recipient filtering” and under MDeamon : “Refuse mail destined for unknown local users”.

If you’re a postmaster, please do your utmost to avoid setting your server to bounce mode. To simply check your server’s configuration, use our online tool at https://www.altospam.com/outil/ and run a scan on an invalid address (for example: cetteadressenexistepas@votredomaine.com ). If the return generates a code 500 after the RCPT TO, your server is indeed analyzing the recipient during the SMTP transaction.

Please note, however, that just because a server accepts emails for all users doesn’t necessarily mean it’s configured for bounce. It could also be a case of ‘CATCH-ALL’. This feature, implemented on some servers, allows you to specify an email address to be used as a receptacle for all emails from a given domain. If this is the case, we advise against using this type of configuration.

Updated 01/24/2012:
Here are the pages of two specific blacklists identifying legitimate bounce-sending servers, on which they explain why bounce is to be avoided :
http://www.backscatterer.org/?target=bounces
http://www.spamcop.net/fom-serve/cache/329.html