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.Īpproach #3 eliminates the possibility of Backscatter. It reduces the possibility of your server getting blacklisted or DoSed. It also puts more load on your server and upload bandwidth, because it has to send the bounce message.Īpproach #2 is pretty much universally better than approach #1. 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. There is little reason to use approach #1 anymore. The sender will have no idea whether or not the message was received. The sender's SMTP server will be responsible for the generating the Undeliverable message.Īccept the message and silently delete it. There are actually 3 approaches for an invalid recipient:Īfter the recipient is determined to be invalid, send an Undeliverable message back to the sender.Ĭlose the SMTP connection while the message is still "in flight". 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. But I cannot come up with a situation in which silently dropping the mail is better than rejecting it during the SMTP transaction. In those cases it makes little difference if you reject the RCPT TO command or if you accept the mail and silently drop it. 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. 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.Silently dropping the mail is a problem, because if any legitimate mail was sent, the sender can never know that it wasn't delivered.This is a problem, because you have no proper way out. 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. I do however see a problem in accepting the mail. (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.) In case of spam, it means the spammer will have to generate bounces. Your mail server took no responsibility for the mail, and the sending mail server is now responsible for bouncing it. In both cases, the end result will be the same. 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. What are the pros and cons of each approach?Īs 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. Also, I keep discovering new spam traps and adding them to my "spam black hole" list, which is a waste of time. I can just delete the item from my aliases file and the email will bounce. The benefit of bouncing them is that it is less maintenance for me. 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 sending the email to /dev/null is that a spammer can't use me to generate bounce messages (Backscatter spam). 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.įorward all mail to these accounts to /dev/null. If the account was used by a person, I let the email bounce so that anyone trying to contact them knows something is wrong. Many of them receive literally thousands of emails a day, all spam. I have a lot of unused (old, dead) accounts on my machine.
0 Comments
Leave a Reply. |