The short version of this whole page for those who are too busy to read all of it: DON'T BOUNCE SPAM, THE FROM IS FORGED. You should only send non-delivery notifications to your own users, anything else that can't be rejected during the SMTP transaction and is later found to be undeliverable should be dealt with locally, don't bounce it or your server becomes part of the problem. Thank you.Skip to the Index.
Backscatter bounces are Non-Delivery Notifications, but they're for email you didn't send. A spammer sends out some of his spew with one or more of your addresses as the From, and poorly configured servers don't properly reject it, instead they send an NDN to the forged From address. So you get notices for something you had nothing to do with. To give you an idea of the size of the problem, I received over 10,300 backscatter bounces in the 8 months starting with October 2006. Of the bounces that specified a reason for not accepting the spam, the vast majority were for an invalid recipient address. The next most common reason is because the spam was identified as spam, followed by over quota mailboxes and identified viruses. Invalid addresses and over quota mailboxes can normally be determined during the SMTP transaction and rejected, but in the cases where I'm getting them as bounces they weren't rejected or I'd never see them. So those mail servers are obviously accepting those emails and processing them before bouncing them. Most servers do body scanning for spam and virus after accepting the email, then many of them bounce it. But it is possible to receive [not accept] the body of an email, scan it, then accept or reject the final packets, avoiding causing backscatter. Exim is one example of a mail server that can be configured to do that. As of October 2008 this has been written into the RFCs. See the box below. Something over half of the bounces that I receive don't specify the reason for the bounce.
First, Barracuda has released a firmware update that sets the Send Bounce option to No, overriding existing settings. Better late than never. And it's not all good news, see this note for details.
Second, there have been some changes to the RFCs, and a couple of the items deal specifically with spam filtering and bounces. RFCs 2821 and 2822 have been obsoleted by RFCs 5321 and 5322. The key change from the point of view of this web site is that
rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. Bounces for spam, viruses and a few other unwanted messages will NOT be usefully delivered since they won't go back to the source. Rejections are fine. See Bouncing vs. Rejecting for more details.
This page is primarily intended for people who run mail servers that receive email for multiple users. Individuals who get their email through an ISP or company server normally won't have much control over what needs to be done to solve this problem.
There are a few positive things that end users can do though. They can certainly help put pressure on their email admins if something needs to be fixed. In many cases it's just a matter of the people in charge not realizing how things have changed since about the beginning of 2006. And if they haven't adjusted, the mail server may have ended up on blacklists. If so your email could be blocked from at least some sites.
End users should never use a program to bounce spam in hopes of abusing the spammer or getting removed from spam mailing lists. Spammers will never see those fake bounces, they'll go to an innocent person who may report the bouncer for sending them spam. Use of a Challenge/Response spam filter can also cause the server to end up on blacklists. It's also not a good idea to try and retaliate against spammers in any way other than reporting the spam you receive, there's far too much potential for abuse of innocent third parties.Who can use this page? Back to the Index.
Anyone who wants to refer someone to this page is welcome to do so. If the goal is educate someone on the evils of bouncing spam so that they'll modify their servers actions, please be sure that you're notifying the right person. Please use caution, not cluing someone in is probably preferable to irritating the wrong person who may already be doing it right.Why did I write this page? Back to the Index.
Lately I've been getting a lot of bounced spam. up to 1000 a day although most days are far less than that. And of course I didn't send any of the spam, so I report as many as possible as spam, which they are to me. See note 1 Even before the volume got out of control, I got tired of typing out emails and filling in contact forms explaining why the sender of the bounces shouldn't do that, so I created this site. The information on this page comes from knowledge I've gathered in years of dealing with computers and poking around the internet and newsgroups, as well as my own experiences dealing with spammers. I received some suggestions and corrections from people far more knowledgeable than I am. And I've done my best to verify that everything here is accurate, but it's up to you to make sure that it's appropriate for your situation. And of course, at some point this information will be outdated.
The internet is a constantly changing medium. Some changes are for the better, some for the worse. Unfortunately spammers have forced several of these changes, and now they're forcing another one.
My goal is to provide information that will convince more people that bouncing spam is a bad idea. The same reasoning applies to bouncing viruses found in incoming email. Anyone who thinks it would help is welcome to send a link to this page to anyone who has sent them bounce spam. Please make sure that they really are the source though, spammers also forge bounces.
If someone sent you a link to this page it's because they received some bounced spam from your server, or a Challenge/Response, or possibly an Out of Office reply to a spam that had their address forged as the From. It might even have been me who sent you the link, although anyone who wants to is certainly welcome to do the same. If you are responsible for any of the above you should seriously consider fixing your system. There are people getting thousands of bounces etc. per day and they had nothing to do with the original spams. Backscatter is becoming a huge problem, and at least one DNSBL (DNS based Blacklist) is now aggressively including backscatter sources in his lists. As of the beginning of 2007 the operator of TQMcube.com had reported that his parser was adding about 50 backscatter sources to his lists every hour. And he said that his lists were being used to filter about 200 million emails per day. You do not want to be there. And his list isn't the only one you could end up on. Spamcop now allows backscatter bounces to be reported as spam, and once there are enough reports, they also add the server to their blacklists. Most blacklists that add backscatter sources will result in blocking all email from that server. But now www.backscatterer.org is providing a list that is just Backscatter and Sender Callout sources. That list can be used to reject just unwanted NDNs.Bouncing or rejecting? Back to the Index.
There's a big difference between rejecting email and bouncing email. Rejecting email is the acceptable way of handling undeliverable email, bouncing email is the one that is causing problems.
Rejecting is done during the SMTP transfer when the sending and receiving servers are talking to each other. If the receiving server rejects an incoming email, then the only one who will get the rejection is the sending server. If it's a legitimate email that server should notify their local sender with a failure report. See RFC 5321 for details. That RFC is new as of October 2008, replacing RFC 2821. If it's spam then the sending server is probably a bot, and it's not likely to be listening. Rejections can be temporary (a 4xx code, like
mail box busy) or permanent (a 5xx code like
no such user). A great deal of spam would disappear forever if it was simply rejected during the SMTP transaction when
no such user is appropriate. Appendix D on page 87 of the RFC has some examples of SMTP conversations. D.2 shows a rejection.
Bouncing is done after the receiving server accepts the email and the connection with the sender is closed. So the email has to be sent somewhere instead of simply rejected. The only way to determine where to send it at this point is to look in the headers, normally the From or the Return Path. TQMCube.com, Spamcop and other blacklists now consider misdirected bounces as spam, and they are treated as such. If your server is bouncing spam you will eventually get listed as a spam source.
The way it should work is that the sender sends an email to their mail server. That server contacts the recipient's server, which determines whether or not the email should be accepted. If it's rejected, the sending server gets that notification before closing the SMTP connection, and it's then the responsibility of that server to notify the original sender. Ideally, bounces should only be sent to local recipients, not to someone on another server since you can't guarantee the validity of the headers. A receiving server should be very cautious about notifying the original sender directly, servers should usually only provide notifications to their own users.
Sender --> Sender's server --> Recipient's server --> Recipient.
Effective October 2008 RFCs 2821 and 2822 have been replaced by RFCs 5321 and 5322. Apparently the main purpose was to clarify some of the statements. But there are several changes which apply specifically to spam filtering and Mail Rejection.
In RFC 5321 Section 4.2.2 a 550 is defined as
Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons).
Section 6.2 deals with
Unwanted, Unsolicited, and "Attack" Messages. While it discusses the importance of delivering any message that can be delivered, it recognizes the problems that can be caused by unsolicited messages:
Utility and predictability of the Internet mail system requires that messages that can be delivered should be delivered, regardless of any syntax or other faults associated with those messages and regardless of their content. If they cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction, they should be "bounced" (returned with non-delivery notification messages) as described above. In today's world, in which many SMTP server operators have discovered that the quantity of undesirable bulk email vastly exceeds the quantity of desired mail and in which accepting a message may trigger additional undesirable traffic by providing verification of the address, those principles may not be practical.
The RFC goes on to state that bounces [as opposed to rejections] SHOULD NOT be sent in the case where they can not be expected to be
Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content.
So if your server and/or filters have determined that a message is spam, or a virus, or a phishing attempt, then it SHOULD NOT be bounced because of the additional problems that can cause. Rejections are still fine (and preferred] since that will only involve the originating server [or spam bot]. And in the case of a false positive, the originating server can still notify the sender. But do not bounce spam or viruses.
For a very complete analysis of the changes in both RFCs see MailChannels' Anti-Spam Blog.
Once an email has been passed on to the recipient's server, there is no longer a safe way to automatically notify the sender of problems.What have the spammers done now? Back to the Index.
Since 2006 botnets have gotten even bigger and more sophisticated. The Srizbi spam botnet in late 2008 controlled about 500,000 computers and at one time may have been responsible for up to 40% of the world's spam. Other bot nets are close to that, at least in volume. Every now and then the control center for one of them is identified and taken off-line. There's an immediate and unfortunately temporary drop in spam volumes until the bots can reestablish contact.Why you shouldn't bounce spam. Back to the Index.
Spam (and viruses) shouldn't be bounced because the From and Return Path are invariably forged. Sometimes they're not valid addresses and they go nowhere, although it takes some server and DNS activity for even that to happen. But far too often, the forged address belongs to someone. Some spammers use an address off of their mailing list as the From. It used to be common to use one address for an entire run of many thousands of spams. If someone actually owned/used that address they would get thousands of bounces. More recently the spammers seem to be inserting a different address from their mailing list in each spam, the same way they rotate the To, Subject and Body. The main reason is probably to help them get around filters that collect massive numbers of emails looking for duplicates. It also makes it impractical to block specific senders since you'll probably never get another spam from the same 'person'. When the From is legitimate, this method results in less bounces to each victim. But they're still going to someone who had nothing to do with the spam. And if you got one of those spams you're also likely to have your address used for some of the forged Froms, meaning you're likely to get some bounces yourself. websiterepairs.net has some good information on the problems caused by bouncing spam.
Spammers have even started deliberately crafting their spams so that they are bounced by a poorly configured server and end up where the spammer wants them by making the From address be that of the target. Bounce spam attacks can cripple the server that is picked to do the bouncing. Bounce spam will often pass right through filters since it usually comes from legitimate servers that aren't on blacklists and the headers won't look like spam. However those
legitimate servers are now getting added to blacklists as a result of sending the bounces. As an example, Spamcop now allows backscatter bounces (as well as virus notifications, out of office response and C/R emails) to be reported as spam. So I report as many of them as I can. See Note 2.
The best way to avoid causing collateral damage is for the mail server to filter incoming email before accepting it and reject known spam and invalid addresses. There are several things you can do.
One of the best is to reject invalid recipient addresses at the SMTP transaction. That means of course that the SMTP server needs to know all the valid addresses. If your server is accepting mail for other servers, you may not be able to do that, and you may need to re-evaluate your setup. A large proportion of the bounces I get were apparently sent to invalid addresses and never should have been accepted by the receiving server, which would have prevented the later bounce.
Greylisting is an excellent way to reduce incoming spam, I've seen reductions of up to 90% in the amount of spam received. When email is received for/from a new combination of addresses the receiving server simply tells the sending server that it's
busy, please try again later. Since most spam senders (and viruses) send their spew without waiting for a response, they don't see the
resend notice, and don't try again. That means it never clogs up the system. Even if they do pay attention and retry later it costs them time and reduces the number of spams they can send. That's one of the few things that you can do that will cost spammers money. And by the time they retry they're often listed on DNSBL's and may be rejected on that basis.
Use a DNSBL to validate the source of the incoming email. I recommend a very conservative list for rejecting email, it's better to accept a few spams than reject some valid and wanted email. Spamhaus has a blacklist that consists of dynamic and non-MTA customer IP ranges which can be used to block a significant portion of zombied residential computers that are spewing spam.
It's possible to scan headers and body for spam and virus indicators before the final acceptance of the email, which means that they can be properly rejected. Most servers seem to accept the email before they scan it, then bounce it. Exim (and probably other servers) can be configured to not acknowledge the final acceptance of the email body until the scanning is complete, allowing it to be properly rejected.
Use local blacklists of known compromised and unwanted destination addresses.
Do not use a Barracuda Spam Firewall. Barracudas are very effective for many things. But I have to question the wisdom of a company that specializes in dealing with spam, but hasn't got enough sense not to bounce emails that it's product identifies as spam. I've gone so far as to call them and complain, and was given the email addresses of a Division Manager and a higher level manager. Neither one bothered to respond. So I continue to report their customers as the spammers they are. Some of them have been very appreciative of the notification and have adjusted the settings. In other cases the reports are bounced as spam. Or the address that the bounce says to use for contacting them (usually postmaster@) is invalid. But the real problem is that the Barracuda's default settings are just ignorant. I"m not the only one that feels this way. Spamfighter has written Read this before you buy a Barracuda Spam Firewall. He also has a blog entry about how Barracuda Networks and their customers could to do more to stop the backscatter.
November 2008: It appears that Barracuda has seen a glimmer of light under the crack of the door. Don sent me this notice he received from them:
As of version 3.5.12, the following configuration changes will be made on ALL SYSTEMS upgrading from a pre-3.5.12 release:
TheSend Bounceoption will be SET TO NO on all systems, regardless of your previous setting. If you wish notifications to go out to any sender whose email was blocked, you can re-enable this option from theBASIC-> Spam Scoringpage, in the Spam Bounce (NDR) Configuration section.
Version 3.5.12 firmware was released on 10/24/2008.
There is no effective warning about the risks of re-enabling it though. At least they recommend not turning it back on. Don sent me the text of the help pop-up too:
Spam Bounce (NDR) Configuration
Send Bounce controls whether notifications are sent to senders when a message is blocked due to spam scoring or content filtering. No is recommended.
When a bounce message is about to be sent, the Check SPF for Bounce Recipients option first validates the email against the sender's Sender Policy Framework (SPF) records; if the email fails the SPF rules, no bounce message will be sent.
This configuration option differs from the SPF Configuration settings on the Advanced > Email Protocol page in that the SPF Configuration settings decide whether SPF lookups should be used to determine the spam status of a message, whereas the Check SPF for Bounce Recipients option decides whether an SPF lookup should be performed after a message has already been determined to be spam, to avoid sending email bounces to forged sender addresses.
Regardless of this setting, no bounce message will ever be issued for messages that were determined to be spam because of SPF match failures; thus, it is unnecessary to enable this option if general SPF checking has been enabled.
The good news is that no bounces will be sent to any address that fails an SPF check. The bad news is that it looks like those settings default to Off, and since there are a lot of domains not using SPF, they'll still get the backscatter bounces even if the setting is enabled.
November 2009: Just over a year ago Barracuda started using their own blocklists. They use what they call a
Reputation System to reject email from IPs that they have identified as spam sources. They also use a URL filter as part of that system, it blocks emails if there's a listed URL in the email. You can check to see if your mail server's IP address is listed using their Lookup page. There's a removal request page you can use if you've been listed. And if you want to avoid the risk you buy your way off the list. Keep in mind that you have to pay for each set of IPs and domain names, if you have more than one domain name, or mail server, you need to pay more than once. Not only do they use non-standard techniques and lots of buzzwords, but you can simply buy your way off the list and not have your email blocked, all of which makes me question their competence. Again. If you're using a Barracuda Firewall, you should give careful consideration to the use of their blocklist, there are better options out there.
For those servers that accept mail for upstream servers and therefore don't have a list of final recipients, you may be able to combine greylisting with address verification. Temporarily reject the initial email if it's not an already known sender/recipient combination. Then request an address confirmation from the final server before the sending server makes another attempt. If the final server reports the address as invalid, reject the next attempt. It would be a good idea for the final server to only perform address verifications that originate from specific servers so that spammers can't use that function to generate or clean mailing lists. That puts the burden on you, but that's the way that spam works unfortunately, the sender has minimal costs of any kind and the recipient bears the burden.
If your server forwards to an AOL server and gets a 554 response, that email may be deleted. AOL gives a 554 when the body of the email contains domain names that are associated with spam or phishing.
Devon Granger has written a Windows ITPro Ebook titled Email Discovery and Compliance. The previous copies that had unlimited access seem to have been removed, free registration is required to view this one. The relevant section is a sidebar in Messaging Security. It's an excellent discussion of why it can be cheaper in resources to Reject spam rather than deal with it beyond the first server. Remember that by some accounts up to 90% of the email your server processes is spam, get rid of it as soon as you can.
But remember this is all rejecting before the SMTP transaction is completed. There are several advantages to this. One is that rejections only go back to the computer that's attempting to send the email, and if it's a legitimate server with a legitimate email the true sender will get the non-delivery notification. Another major advantage is that rejecting spam reduces the load on everything except the sending server or spam bot, and that makes it the spammer's problem.
If your mail server is accepting the email for processing rather than rejecting the ones that you don't want, then you can add some processing steps that will sort the majority of spam locally to reduce the backscatter bounces. If you must accept mail then bounce some, based on the backscatter I get a great deal of backscatter can be eliminated by:
If someone will be away for a while and their emails can't wait, let whoever is taking care of their work also take care of their emails. Considering that over 90% of email traffic is spam, over 90% of your Auto-responses have the potential to be backscatter. Spamcop.net has some suggestions if you absolutely must use an auto-response of some kind, including Out of Office messages. Among other things, put a spam filter in front of it so that anything with even a remote likelihood of being spam is diverted and/or deleted before it can be responded to. This is a place to use an aggressive spam filter. Delete things that are certainly spam. Have someone inspect anything that may be spam so that a human makes the final decision. That will minimize auto-responses to spam, which will go to forged From addresses. Your Auto-responses are also more likely to be rejected or identified as spam now that spammers are abusing Auto-responses to get past filters.Challenge/Response Back to the Index.
As a spam filter, Challenge/Response has got it exactly backwards. It may block the spam sent to the person using C/R, but it puts the burden of doing that on the other people who may want to write to that person. Worse yet, with the proliferation of forged Froms in spam, it dumps those C/Rs on people who have no connection with the spam or the intended recipient. With estimates of up to 90% of all email currently being spam, that could mean that up to 90% of Challenges are going to someone who wasn't involved in the original email. C/R may be relatively effective at blocking the spam for the intended recipient, but it increases the spam for others. Plus it's easily abused and relatively easy to circumvent. And finally it causes no trouble for the spammers who never see the challenges and don't seem to care if their spam actually gets delivered. After all, they're just playing the percentages anyway.
Challenge/Response will eventually get your mail server listed on blacklists. Remember that spammers forge the From addresses on their spam runs, generally using other addresses from their lists. A percentage of those harvested addresses are going to belong to spamtraps and eventually one will end up as the forged From on a spam sent to a user on your server. When their C/R goes back to that spamtrap, your server is listed. If your server is or has been listed at backscatterer.org the odds are good that it will end up on other lists too.
If you're still unconvinced, go read the opinions of some people who say it much better than I do. There's a 971 KB PDF file from John Graham Cummings on why he hates Challenge/Response. Or you can read Google's HTML version. There's a long article about Challenge/Response from Karsten Self. Richard Clayton doesn't think much of C/R systems and points out a number of things wrong with them. I use the link to this Spamcop article when I respond to to a C/R, which also releases the spam to intended target. I didn't send the spam, I don't want to get your challenge to it. I report all C/Rs as spam.What about viruses? Back to the Index.
Basically everything that applies to bouncing spam applies to bouncing viruses. Even more so since the bounce can actually be dangerous in this case. For some idiotic and certainly outdated reason most of the bounced viruses I get include the virus. And many of them are bounced because the email is identified as containing a virus. I know that because the bounce message very politely informs me that a virus was found in the email, so they're sending it back. Well then, delete the thing, don't pass it on. Since I didn't send it, I'm probably not infected. Hopefully I'm smart enough not to get infected by the bounced virus. But some of those bounced viruses probably will go to someone who wants to see that
Video of Saddam's hanging or that
picture of Natalie naked. And since many, maybe even most, of the recent email viruses are being sent by spammers to increase the size of their bot fleet, you're just making it worse in several ways when you pass that virus on. Bouncing a virus to a forged From just increases the chance of infecting additional computers.
You may want to test your mail server to be sure that it's doing what you expect. Another case where you may want to do some testing is if you're a domain owner who wants to see how your domain host is handling spam. Be advised that the mail server may do different things in different situations. Two examples are invalid addresses and matching a rejection rule. A lot of the backscatter spam I get was sent to an
invalid address. Many mail servers are accepting mail before they validate the recipient address, then bouncing it when they determine that it's not valid. Often this is because a server further along the path has the address list. It's good to test both invalid addresses [if appropriate] and a server rejection rule. Keep in mind that a rejection rule in your mail client will work very differently than a rule at the server level. You should never bounce email once it's gotten as far along as your mail client. You will also need to be able to send email through a different server than the one you're testing.
If you know with absolute certainty that unknown addresses are rejected, you can send email to an address that isn't in your list of valid addresses. It should be rejected not bounced. To test rejection rules (DNSBL, address blacklists, etc.) you'll need to be able to set up a rejection rule on the server. It can't be a rule in your email client since that gets the email after the original SMTP transaction has closed and it's too late to reject so all you can do then is bounce it, and you don't want to do that. If your mail host allows you to set up specific spam filters you can do that, perhaps by making a rule that will reject (or delete) mail with a certain unlikely word in the subject. You don't want it to catch anything other than your test email. Delete your test rule when you're done.
You need to send an email that will be rejected and has a Return Path that is different than the From. It should be a different domain with a different mail host to make it clear where the rejection ends up and how it gets there. Ideally it needs to be sent via a third mail host. As far as I know you can not do this with any web mail, even one that lets you appear to be sending with a different From address. Make sure that the email really does have the headers you need by sending one to yourself and checking.
Be sure to substitute your own appropriate domains here where I use
examples. Send a test email to your example.org account with the right subject using your mail server at example.com and with the From set to be example.net. I used one of my Gmail addresses as the From. The mail should go from the sending email program to your email host, which will send it to the receiving email host that you want to test. That server should reject it based on what you're testing, and refuse to accept it. If that happens, the first server will return it to the account that sent it. If the receiving server accepts the email before determining that it needs to be refused, then it will have to send it back to the different From address (Gmail in my case). If the bounce shows up at that different address, it's not being done right and you could be part of the backscatter problem. There are a lot of variables in the test though, so double check that it makes sense for your situation. And that the test email is set up properly.
If your server has been bouncing spam and viruses, you could already be in some Blacklists. Many of these lists are based on spam trap addresses that have been posted where spam bots can harvest them, and they're never used for anything else. Any emails to those addresses can safely be assumed to be spam, and the sender is automatically added to their blacklist. With the increasing tendency of spammers to rotate forged Froms in their spam run, they are more and more likely to use one of those spam trap addresses as the From. If that spam happens to be sent to your server and you bounce it, that bounce will go to the spam trap. Since your server was the last one to handle it, that would be considered to be the source of the spam. In the past most blacklists seemed to be willing to exclude bounces from causing a server to be listed. Due to spammers latest methods that's changing. Backscatter has become such a problem that bouncing servers are now being listed more aggressively. And if your server is on a blacklist, any mail server using that list to determine if an email source is a spammer is likely to reject your user's emails.
One place to check the status of your server is mxtoolbox.com. They will look up your IP Address in over 100 different databases. To use it, enter your mail server's IP address in the box and press the
Lookup button. The results page will give you a summary at the top of the page, and a list of all the DNSBLs queried. Each line in that list will have a link to the DNSBL's web site. Ones that have the tested IP address flagged as a spam source will be listed at the top. You can use the link to go to the site and find out how to try and get de-listed. Some lists are easier to get off of than others. Remember that these lists are used by mail server admins to determine whether or not to accept mail sent from you and/or your server. You do NOT want to get on any of these lists.
DNSStuff.com used to have a free spam database lookup, but now you have to register for the free 30 day trial, then pay to use it after that.
You can use SenderBase.org to look up statistics for your server's IP address to see if there are problems with it.
You can check to see if your server has been a backscatter source at backscatterer.org. This list is only backscatter sources and should not be used for normal spam filtering.
While not all blacklist sites have a way that you can query their database via a web page, DNSStuff.com and Mxtoolbox.com can still check many of them. But if you want to check some specific sites or to get more information on how they work here's a few individual sites.
If you're getting hammered with Backscatter yourself there are only a few things you an do, and what they are depends on how much control you have over the server. If you're an end user about all you can do is report the sources as spammers and hope that they get a clue. They can be reported pretty easily using Spamcop.net. Note that it's .net, the .com site is someone else, apparently capitalizing on the name similarity. When you report sites as spammers, Spamcop.net will send a notification email to them or someone upstream. Feel free to include a link to this page. The only other thing you can do is to create some rules to filter or delete Delivery Status Notifications.
backscatterer.org provides a list of servers that have been a source of backscatter bounces or sender callout. Their front page has a line showing the number of servers currently listed. Servers drop off the list after 4 weeks with no repeated backscatter so it's a good indicator of spam volumes. During 2008 the number has ranged from a low of 49,006 up to 88,064 at the times I've checked.
Someone sent me this rule that he's using with Exim. It will reject emails with a Null Return Path if the source is listed at backscatterer.org and include a message suggesting that they fix their server configuration. At the time it was rejecting about 50% of his backscatter, but that percentage should improve as their list gets bigger. (Verify the format of the rule before using it.)
deny senders = :
dnslists = ips.backscatterer.org
message = This message looks like a bounce, and your server is listed at \
ips.backscatterer.org, so I assume that this is "backscatter". \
Please configure your mail server to not send "backscatter spam". \
For advice, try http://www.dontbouncespam.org/
Because of the volume of bounces I'm getting I now report most of my backscatter bounces through Spamcop. If I have time to do a little research I'll include a notification to the domain because Spamcop often sends the report upstream. Sometimes I'll go to the trouble of checking a website for a contact address and use that via Spamcop. Occasionally I'll find that that address turns out not to be valid. For a lot of reasons you want to be sure that addresses listed on your website are valid. I do recommend obscuring them to minimize harvesting and the amount of spam sent to them. You should also make sure that your domain has a valid reporting/contact address. You can register one at Abuse.net and Spamcop will use that. At least that way you'll know about problems instead of having the reports sent to dev null or someone upstream who may not contact you. Many bounces contain a contact address (usually Postmaster@) to use in case of problems. It appears that they are often just the default address that came with that function of the mail server rather than a deliberately chosen, working address. I have sometimes used that address for notifications since it's specifically listed in the bounce as a contact address. And sometimes that bounces too.Note 2
My single report of a bounce will probably not get a server put on a blacklist. However sometimes in a large spam run I'll get several bounces from the same server, and if I report all of them that may be enough to blacklist the server. The way I do it should get the admin a notification of the problem though, assuming that there is a contact address available. And keep in mind that if I'm getting backscatter, others almost certainly are too. And if they're also reporting them that can result in blacklisting. If you have the ability, check the logs and see how many emails are being bounced to get an idea of how much backscatter you're generating. Remember that way over 90% of those bounces are likely to be spam, with forged addresses that may land them in someone's inbox, or a spamtrap.
www.uceprotect.net has a list of 4 suggested steps to reduce email abuse.
UCEProtect.net also has Backscatterer.org which specifically lists servers that are the source of backscatter abuse.
Barracuda Networks and their customers could to do more to stop the backscatter is a blog entry from Spamfighter, who also gets a lot of Barracuda Backscatter. He lists two major problems with the Barracuda Spam Firewall, both of which could easily be fixed, but Barracuda appears to prefer remaining clueless and ignorant.
Chris Fuhrman has an interesting analysis of the headers of some email that became backscatter.
SpamFighter's home page has links and information about backscatter. He gets lots of it, even more than I do.
If your domain does not have a contact address registered for people to use in case of abuse, you can register one by following the instructions at Abuse.net.
Spamlinks.net have some pages explaining some of the problems with Backscatter.
Spamlinks.net also has some links to spam filter vendors explanations of why their product doesn't include a bounce function, followed by a list of spam filter vendors that do bounce spam. These products should have that
feature disabled and they've included links to instructions. This includes the Barracuda spam firewall, which has the spam filter set to bounce by default. Barracuda's are the source of a significant percentage of my bounces. To turn off the bounce change the
Send Bounce setting from
No on the Spam Scoring page. At least they recommend not bouncing viruses, although it is possible to turn it on. Don't do that. In late 2008 a firmware upgrade for Barracudas finally set the bounces options to No by default.
spam.abuse.net has links to lots of articles and sites related to combating spam.Spamnix.com has an explanation of why their product won't generate fake bounces, which coincidentally is exactly why spam shouldn't be bounced at all.
RFC 5321 lays out the specifications for the SMTP protocol. Also see RFC 5322
Internet Message Format. Effective October 2008 these replace RFC 2821 and RFC 2822.
A Wikipedia.org article on Backscatter.
What's wrong with bouncing spam from Castlecops.com.
2 bounce or not 2 bounce from georgedillon.com
The problem with fake bounces from spamfaq.net This site may not be available any more.
Why Spampal doesn't include the ability to fake bounces.
Spam Zombies are the source of a lot of spam that ends up as backscatter.
Spamsieve is a Bayesian spam filter for email clients running on MACs.
The only information that I collect is page hit counts. My web host One&One keeps track of lots of things and makes the information available to me in pretty graphs and logs. I look at them occasionally, but there is no personally identifiable information there.
If anyone sends me email their address is used only to respond if necessary. It is never traded, sold or shared in any other way. If I post content on my web site from emails I receive, all personally identifiable information will be removed first.
I am not responsible for any sites linked to from my pages. They may look different to you, or even have effects on your browser or computer that are different than what I see due to differences in filters and browsers. They could have also changed since I looked at them. To the best of my knowledge, they are all safe. But as always, you surf at your own risk.