The problem of backscatter, part 12 - Don't make the problem worse by contributing to it

Many of the web sites that discuss backscatter encourage mail administrators to not further contribute to the problem of backscatter.  I would be remiss if I did not include a section on it.

• Don't accept mail, and then bounce.   The primary problem of general backscatter is when email servers accept a message, discover they can't deliver it and then send a bounce notification back to the person who "sent" the message without verifying that they actually sent the message. Remember that if a recipient mail server cannot deliver the mail and figures this out during the SMTP conversation, it rejects delivery and the sending mail server has to generate the bounce.  After the recipient mail server accepts it, it's too late.

  Make sure you configure your mail server to not do this.

While that is the primary problem of backscatter, Al Iverson of Spam Resource has some more suggestions for not contributing to the problem of backscatter, some of which I have paraphrased and reprinted below. 

• Don't use Challenge/Response, and don't allow your users to, either.  

  While Challenge/Response spam filters fix your spam problem, it irritates and annoys everyone else.  SpamCop says that this is a selfish method of spam filtering, and I agree.  It offloads the spam filtering onto the senders (ie, I send you a message and you expect me to filter it... hey, filter your own mail!). 

  But even worse, if a spammer spoofs an email address and you send a challenge back to the sender in the MAIL FROM, you are sending piles of challenge notifications to people who never sent mail.  In other words, you become a source of backscatter.

  Don't do this.

• Configure your virus scanner to silently strip or discard viruses/worms instead of sending a notification back to the sender.  

  Viruses and worms that sent via email do not have valid sender addresses, they are spoofed.  If your mail filter catches the virus and sends a notification back to the sender, it goes to the wrong person, an innocent third-party. This is backscatter, and your server just succeeded in annoying somebody.  It's the same as the Challenge/Response problem.

• Don't run autoresponders, out-of-office notifications, etc.

  The idea here is that autoresponders annoy people and your mail could end up being blocked.  The issue here is the same as the above, spammer sends a mail to your autoresponder which bounces a message back to the "sender" who is thinking "Who is this guy?  I don't care if he is out-of-office."

  I have mixed feelings on this one.  While on the one hand I can see the anti-autoresponder's point, on the other hand I find OOF notifications very useful.  Whenever I send someone at my company an email and I get an OOF notification, I am glad to know that their response will be delayed.  Similarly, when I have been on vacation and people sent me mail, they were wondering where I was because I hadn't responded.  So, in the business world I believe that there is a need to use an autoresponse/OOF notification.

  Microsoft Exchange has the ability to separate autoresponders to internal users vs external users.  At the very least, I think that you should let people know you are OOF if they are within your organization.  You might be able to get away with not setting anything for senders outside of your org.

  Or maybe you only send auto-responses to senders who pass a DKIM or SPF check.

So, even if we all can't stop backscatter, let's not make it worse by contributing to it.  Don't send mail automatically if can't deliver it or without verifying that whoever sent the message actually sent it.