Why you shouldn't bounce spam and viruses.


No one reports the From address on a spam as the source because they know it's forged. So why would you 'return' a spam to that same forged address? I'm all for returning spam to the sender, but to do that you have to reject, not bounce. This page is about not bouncing spam. Rejecting spam is fine.


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.

December 1, 2008. There are two items of good news.

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.

The short version.
Who this page is for.
Who can use this page?
Why I wrote it.
Bouncing vs. Rejecting
What are the spammers up to?
Why not bounce spam?
What can you do?
Invalid Recipient Addresses
Auto-responders, Out of Office messages.
Challenge/Response, why not. (It's not a question.)
What about viruses?
How can you test your server?
Could it be too late? How to see if you're already listed.
What can you do if you're getting hammered with Backscatter?
Related links
My Privacy Policy and a disclaimer.

Who is this page for? Back to the Index.

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.

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

In Section 4.3.2 it states that a 550 (rejection for policy reasons) is allowed after DATA. This allows a server to accept a message and hold the connection open [for a reasonable amount of time] while the message is scanned, then return a 550 and properly reject the message even after the DATA transfer. Many servers have been doing this, but now it's officially sanctioned.

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 usefully delivered.

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.

Spammers have changed the way that they send spam, and this is forcing a change in the way that email is handled. It used to be A Good Thing to return email if it couldn't be delivered for any reason. Personally, up until a couple of years ago I was adamant that in my opinion all undeliverable email needed to be returned. Whether it was a bounce or a rejection didn't make a lot of difference at that time. That way the sender was notified that there was a problem and they could take steps to fix it. This worked fine as long as the vast majority of email was legitimate and had valid headers. But spammers are ruining that. In December 2006 the percentage of email that was spam went to 94%. Estimates on the amount of spam vs. legitimate emails in 2007 ranged up to 90%. In 2008 (Javascript required to see the chart) that percentage was above 95% for most of the year, dropping in October when a large spam source lost their connectivity for a while. According to Postini spam increased 146% in 2006. But it gets worse. That's just the raw numbers. Because many spammers are now using images or other attached files to try to foil filters, the required bandwidth jumped by 334%. Your mail servers have to be able to handle that volume increase. And now that a single spammer can send millions of emails (or more) in a day, all with forged From addresses, it's counter productive to return all the undeliverable emails. Sometimes those forged addresses belong to someone. I can guarantee that they don't belong to the spammer, so someone else is going to get the bounces. I know of people who have gotten 10s of thousands of bogus bounces a day while some spammer was doing a big run with their address. Usually it's just coincidence, but it can also be malicious if someone has irritated a spammer and they're performing a Joe Job. Any server that is the source of backscatter becomes a source of internet abuse. The resources available to determined spammers and/or someone with money to spend are overwhelming. See this wired.com article about botnets. Spammers have become very sophisticated in the way they manage their botnets, and the SpamThru Trojan is the leading example at the moment. In at least one case the botnet consisted of over 73,000 computers. In another analysis by Secureworks.com a botnet that size can send over a billion spams per day. The SpamThru Trojan even keeps it's own set of statistics, so they were able to use that in their research.

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.

What can you do about it? Back to the Index.

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.

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:

Auto-responders and Out of Office messages. Back to the Index.

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.

How do you test your server? Back to the Index.

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.

Could it be too late? How to see if you're already listed. Back to the Index.

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.


Getting Backscatter yourself? Back to the Index.

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/

Note 1

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.

Whenever I have time, I try to notify the actual sending server, instead of just going upstream. Often that requires checking a website, and if your pages require Flash and/or Javascript just to see anything, you'll never hear about your problem directly from me, I'll just report your server using Spamcop. At a minimum you should be sure that your pages degrade gracefully for those who don't want all the bells and whistles. One thing that will increase the likelihood of me reporting backscatter no matter how busy I am or how many I get is an indication that it was identified as spam and bounced anyway. This especially applies to anything from a Barracuda Spam Firewall or anything similar. You'd think that a company that deals with spam for a living would know better than to recommend bouncing spam. I also aggressively report all Challenge/Responses.

Links: Back to the Index.

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 Yes to 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.

My Privacy policy:

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.

Disclaimer:

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.

Got an issue? Feel free to <email me>


hit counter image Views since January 2007


Page last updated July 28, 2011


Back to the Top of the page.

Copyright 2007, 2008, 2009, 2010 by bounceabuse@dontbouncespam.org


valid_html_401 (1K) Validated with Total Validator and Validated by HTML Validator (based on Tidy)