Should I let email bounce or send it to a blackhole?

Question

I have a lot of unused (old, dead) accounts on my machine. Many of them receive literally thousands of emails a day, all spam.

If the account was used by a person, I let the email bounce so that anyone trying to contact them knows something is wrong. However I'm not sure what to do about the hundreds of accounts that were used for other purposes, such as throw-away accounts I used to use for websites that asked for my email address, or address that I used to list on web pages.

Option 1:
Forward all mail to these accounts to /dev/null. The sender doesn't receive a bounce.

Option 2:
Let the email bounce.

The benefit of sending the email to /dev/null is that a spammer can't use me to generate bounce messages (Backscatter spam). i.e.: forge the "from" line to be someone they don't like, then use me to send tons of bounce messages to that person.

The benefit of bouncing them is that it is less maintenance for me. I can just delete the item from my aliases file and the email will bounce. Also, I keep discovering new spam traps and adding them to my "spam black hole" list, which is a waste of time.

What are the pros and cons of each approach?

Answer 1

As long as you bounce the mail by refusing to receive it in the first place, then a spammer cannot use you to annoy somebody innocent with a lot of bounces.

You can either return an error on the RCPT TO command, which is what usually happens in case of a non-existent address, or you can return success on the RCPT TO command but return an error at the end of DATA.

In both cases, the end result will be the same. Your mail server took no responsibility for the mail, and the sending mail server is now responsible for bouncing it. In case of spam, it means the spammer will have to generate bounces. (And if that's what they wanted to do, they could have done so without even trying to deliver the mail to you in the first place.)

I see no problem in this approach.

I do however see a problem in accepting the mail. I.e. if your mail server responds with success all the way through the transaction including at the end of DATA, then it becomes the responsibility of your mail server to deliver the mail. This is a problem, because you have no proper way out.

• Silently dropping the mail is a problem, because if any legitimate mail was sent, the sender can never know that it wasn't delivered.
• Sending bounces from your mail server is a problem, because in that case spam bounces to some innocent person's mailbox instead of back to the spammer.

There may be cases where distribution of the email-address in the first place was so limited, that you know there couldn't be any legitimate mail send to the address. In those cases it makes little difference if you reject the RCPT TO command or if you accept the mail and silently drop it. But I cannot come up with a situation in which silently dropping the mail is better than rejecting it during the SMTP transaction.

Answer 2

I'm going to make this answer fairly generic because the terminology and configuration details will vary depending on your specific mail server/spam filter software.

There are actually 3 approaches for an invalid recipient:

1. After the recipient is determined to be invalid, send an Undeliverable message back to the sender.

2. Close the SMTP connection while the message is still "in flight". The sender's SMTP server will be responsible for the generating the Undeliverable message.

3. Accept the message and silently delete it. The sender will have no idea whether or not the message was received.

There is little reason to use approach #1 anymore. In the case of a Backscatter attack, your server will look like the spammer (even though it is an innocent victim), and you will be the one who gets blacklisted. It also puts more load on your server and upload bandwidth, because it has to send the bounce message.

Approach #2 is pretty much universally better than approach #1. It reduces the possibility of your server getting blacklisted or DoSed. It does not eliminate the possibility of a backscatter against an innocent third party address, but at least your server is not the one sending the bounce messages.

Approach #3 eliminates the possibility of Backscatter. It also helps to guard against a Directory Harvest Attack. However, it also means that if an external sender mistypes your address, they will never know. It can also be a problem if someone leaves your company, and a customer tries to contact the former employee.

I inherited an e-mail system that used Approach #3 due to concerns about DHA. It caused more trouble than it was worth. We now use approach #2. (Note there are other ways to mitigate DHA.)

Answer 3

If your email server is configured properly, you should reject email to unknown users during the SMTP transaction.

Reject Email During the SMTP Transaction

Your server should be configured to reject email to unknown users during the SMTP transaction phase. Doing so returns a 550 SMTP error code to the sending server. Since this happens during the SMTP transaction, your server never sends a Non Delivery Report (aka bounce).

Properly configured, this prevents backscatter since the rejection is sent directly to the sending server and other email headers are ignored.

Benefits

The benefits of this approach is that you are rejecting email very soon in the SMTP transaction process. This could mean:

• Lower resource utilization on your server, especially if all email is sent for processing after it is accepted (virus/av filtering).
• Senders will often remove these email addresses from their lists to prevent being blacklisted.

Consider that if you null route the email, the sending server thinks the message was delivered successfully. There is no reason for them to stop emailing these defunct addresses. As a result, as these old addresses pile up, you need more and more server resources to process the email.

To implement this, you simply need to delete the users from the email system. If you need backups of current email, that is fine, you just want your server to send the 550 user unknown response.