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

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.

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.)