Dealing with Backscatter

'Backscatter' is the name given to messages that are generated when a spammer uses your mail address or an invented mail address at a domain that you own in the 'From:' line of their messages. If the spammer's message can't be delivered for any reason, the receiving host will send back a non-delivery report to the address in the 'From:' line.

Most backscatter consists of non-delivery reports, but you may also see messages from challenge-response systems and even personal responses from recipients.

If a spammer sends a large number of messages, you may receive literally hundreds or thousands of 'bounces'.

Many mail systems will not deliver mail if the 'From:' line in the message references a non-existent domain (or a known spam domain). Spammers try to get past this test by using addresses at other people's domains instead.

Spammers put two kinds of forged addresses in their 'From:' lines. Sometimes they simply take a randomly chosen address from the same list of addresses to which they send spam. This typically generates only small amounts of backscatter.

Often, however, the spammer will choose someone else's domain and invent addresses at that domain, i.e. 'xgyu@yourdomain', 'bdfdssd@yourdomain' etc. These invented addresses are used on large spam runs, and can generate huge amounts of backscatter.

This FAQ is mostly intended for victims of the second kind of spammer.

No. The spammer is just putting your address on their messages. They don't need access to your server to do that.

Probably not. Most people who know anything about email will realize that the spam didn't come from you and will understand that there's nothing you can do to stop a spammer forging your domain in this way.

It's possible but not very likely. Most anti-spam administrators now recognize that checking the 'From:' line is not a very good way to identify spam, precisely because spammers routinely forge other people's addresses.

The good news is that the deluge of error messages probably won't go on indefinitely. Spammers will eventually switch addresses, not out of respect for you, but simply because if they use the same address or domain for too long, spam filters will eventually start blocking it.

In our experience, spammers will typically switch addresses every few hours or days. Unfortunately, there's nothing to stop them returning to an address that they've used before, and they often do.

Generally, you can't. The spammers who do this are usually the ones who are hardest to track down and the most contemptuous of any laws, such as stock spammers. There's no way to write to them and say "Please stop", and even if you could, they'd just ignore you.

There are three main things you can do to reduce the amount of backscatter that you see. The first is to turn off your 'catch-all' address. If you are unable to do this, you can filter incoming messages to remove the bounces. The third is to set up an SPF record for your domain.

You may also choose to report the bounces you receive to the administrators of the systems generating the bounces, or to Spamcop.

These options are explained in more detail below.

Many people have their domains set up so that any messages sent to an unrecognized address at the domain are automatically delivered to a single mailbox. This mailbox is known as the 'catch-all'.

A 'catch-all' address is convenient, but it means that when a spammer invents addresses at your domain, all the bounces go to that mailbox.

The simplest solution is to turn off the 'catch-all'. Instead of accepting all mail sent to your domain, you should accept only mail sent to addresses that you recognize. Anything else should be silently thrown away.

The procedure varies depending on how your domain is set up. Ask your hosting provider or ISP; they should be able to help you.

You should set things up so that you accept mail sent to the addresses that you know you use. In other words, if you use 'bob@mydomain', you should make sure that any mail sent to 'bob' will be accepted. Again, your provider should be able to help.

Make sure that you specifically configure your system to accept mail to all the addresses you use.

You should also accept mail sent to what are known as 'role' accounts. These are some standard addresses that are defined by RFC 2142. RFC 2142 is a recommendation, not a requirement, but you should accept mail sent to 'postmaster' (which is a required address - see RFC 822) and 'abuse' as a minimum.

The addresses recommended by RFC 2142 are:

• postmaster
• abuse
• webmaster
• info
• sales
• security
• hostmaster
• support
• marketing
• noc
• usenet
• news
• www
• uucp
• ftp

These are in roughly descending order of importance. Most sites support the first seven, but the others are really optional: if you don't use the 'uucp' program (a very old program from the early days of the Internet), there's no need for you to have 'uucp@mydomain'.

Be aware that spammers will send spam to all these addresses.

You may lose mail if someone mistypes your address. If someone types 'bobb' when they meant to type 'bob', you'll never see that message.

It's also more time-consuming to list all the addresses you accept, rather than just saying 'accept everything'.

There may be reasons why turning off the 'catch-all' address isn't an option for you. If this is the case, then you'll need to filter your messages.

Yes. Many bounces will contain strings that can be recognized by a mail filter. You won't be able to filter all the bounce messages out, but you may be able to reduce the number you see.

Every mail system seems to invent its own way of reporting undeliverable mail. There is absolutely no standard form for the return messages and they can contain any address in the 'From:' line. Challenge-response systems are even worse than regular MTA's, which are at least slightly consistent.

And yes, this is a stupid state of affairs.

I conducted a few tests on a mailbox full of bounces and came up with the following, in descending order of effectiveness.

These tests may or may not work for you. They will probably reduce the number of bounces you see, but they will not catch all of them.

Sender Policy Framework (SPF) is a way of declaring which mail servers are allowed to send mail with your domain's address in the 'From:' line. If a recipient gets mail that includes an address at your domain, but the message was sent from a host which isn't specified in your SPF record, they know it's either spam or a virus and can reject it accordingly.

More details about SPF, including tools to help setting up SPF records for your domain, are available from OpenSPF.

In the short term, probably not. I have SPF records for most of the domains that I administer, but spammers still forge addresses at those domains.

In the longer run, as SPF gets more widely adopted, the situation may change.

No. In fact, there's a small possibility that it may increase it. Some domains use SPF inappropriately as part of their filtering strategy, and will generate bounce messages if their filters detect a message that fails an SPF check. Fortunately, these domains appear to be in a minority.

SPF is a nice idea with some significant problems, some of which are pointed out in this post by Suresh Ramasubramian.

I would currently recommend creating an SPF record if you have a domain that will never appear in the 'From:' line of your message. In this case, you can simply say that there are no allowable senders for the domain, and any SPF-savvy recipients will know to throw away any messages they receive that appear to come from your domain.

In other cases, it's less clear-cut. Use it if you like the idea, but be aware that there are some problems with the proposal and that it may not help very much in cutting down the number of bounces that you see.

Yes. You can contact the administrators of the system sending the bounces to suggest that they configure their systems to reduce or eliminate these messages. The WHOIS record for the domain will often list a technical contact, or you may simply mail 'postmaster@' the domain in question.

As always when reporting spam, be polite and try to provide as much information as possible to allow the postmaster to resolve the problem.

SpamCop accepts reports of backscatter, and will notify the administrators of affected systems. For more information, see the SpamCop wiki entry on misdirected bounces. SpamCop also provides advice for administrators on preventing backscatter.