Email Help, Backscatter, and How to Stop Spam Spoofing with SPF
Document Actions
You have been directed to this web page to correct some sort of problem with email that has been sent to our domain. The majority of these are misdirected bounces, backscatter, and wrong addresses. Here's how you can reduce spam and other unwanted internet traffic, and that would make all of us happy.
Welome to our little domain! We hope we can be of some help.
You received a "550" response (or something similar) from the mailserver for this domain, or an automated response from "donotreply" or "catchall" at this domain. These reasons cover just about all of the email errors we see:
- The originating email was spam, using an illegally forged email address at our domain. The originating spam did not come from any person or computer at our domain, yet your mailserver (or MTA) accepted it, probably because it does not implemented SPF. An SPF check could have rejected and/or deleted the spam, and kept it from moving beyond it's source.
- Your mail server or MTA sent us a spam induced "Misdirected Bounce" or "Backscatter". Once again, the originating email it references was from a spammer who illegally forged an address at our domain. The originating spam did not come from any person or computer at our domain, yet your mailserver "bounced" it back to us. Once again, SPF could have prevented this.
- You really are trying to reach someone at our domain, but you have an error in the address (i.e., you mispelled the user name before the "@domain.com").
- Something really is wrong with our configuration somewhere, either with SPF, TMDA, qmailadmin, etc.
If the problem is #1 or #2: please direct the administrator for your mail server to this URL. We suggest they implement SPF, which would reduce spam for everyone by deleting a large amount of spam messages with "forged sender envelopes". If they have implemented SPF, thank them and send them a box of chocolates, and suggest they check their SPF set up.
If the problem is #3 or #4: please send us a message. If you give us a little time, we can see if we find the accurate information, or fix the problem:
Or you can do nothing, and just delete the message you received, and that's fine as well. We're all busy, and if we're lucky, we won't get any more backscatter from you, and you didn't need to get in touch with anyone here any way.
That's the short version. If you want a few ideas on how to reduce spam, unnecessary traffic flow, and other bad things on the internet, please read on:
You received a message claiming to be from someone at this domain. If it was spam, it wasn't from any person or machine at this domain. We then received a message from your mail server or MTA that was most likely "backscatter" or a "misdirected bounce". This is the result of spammers using "Sender Address Forgery", or "spoofing", to illegally forge a fake user name at our domain for the "From" and/or "Reply To" headers of their spam messages (UBE, or "Unsolicited Bulk Email"). Your mail server (or MTA) received such a message, and bounced it (incorrectly) to our mail servers and domain.
If you are not an administrator or postmaster for a mail server or MTA, it's probably safe to just ignore the message. Please just delete it, or send it on to whoever handles your email service. No one at our domain sent the message, and it's just bouncing around the internet.
If you are a server or MTA admin, you may be thinking that bouncing such messages are the best way to handle them, and backscatter is just an unfortunate consequence of SMTP. Let me give you a few reasons why you should re-think this:
If you are a server or MTA admin, you may be thinking that bouncing such messages are the best way to handle them, and backscatter is just an unfortunate consequence of SMTP. Let me give you a few reasons why you should re-think this:
- Your machine is actually increasing the amount of spam on the internet, sometimes by a considerable magnitude. In fact, some spammers count on backscatter, and some even try to mimic it. That's why they forge so many addresses to send out just one spam. Not only does it hide their activity from the ISP they are hijacking, it greatly increases the number of messages they deliver when backscattering tries to deliver all those failed messages. That's one reason why SpamCop now considers misdirected bounces a form of UBE, or spam.
- You have to make a decision about what to do with email that is undeliverable, and you need to think about what you reject, and what you bounce. In some cases, bouncing the message is the correct thing to do, and every approach is debateable and has its pros and cons. But in most cases, your backscatter effectively passes off the task of filtering mail to another victim of the spammer, that is, the user and domain whose address was forged (not to mention their MTA and mail admin). SPF can make your task and decision much easier, and it allows other servers to help you, and to help us all.
- Backscatter can be used to do very malicious things, like DoS ("Denial of Service") attacks. You don't want to help people do that.
If you are a server or MTA admin, please consider using SPF ("Sender Policy Framework"), or some other MTA policy, to reduce or stop misdirected bounces and backscatter from spam. Regardless of the size of your operation, consider the fact that no person or machine in your organization nor ours had anything to do with generating this spam, but this misdirected bounce has wasted the bandwidth and resources of all of us.
SPF is already bundled into most server mail or MTA programs (sendmail, qmail, Courier, etc.). SPF can greatly reduce, and in some cases even prevent, spam and misdirected bounces by eliminating email from forged or "spoofed" addresses and domains.
Our domain host, HighSpeedRails, encourages SPF, and has publish extensive SPF domain name records for us. Lots of other domains big and small, use SPF, including google, aol, and microsoft.
If you already have implemented SPF, that's great, thank you. Keep it up, and you might want to tighten your rules (within reason, and however it makes sense for your organization). It is highly likely, however, that if you received a "550" message from us that your domain and servers have SPF bundled with your mail server software, but you haven't configured or activated it yet. SPF is entirely voluntary, but please do consider it. You can do this even if you do not wish to publish an SPF record for your domain, and you would save yourself, and those of us who do publish SPF records, effort and bandwidth.
Information on SPF is at: http://www.openspf.org.
SpamCop now considers "backscatter" or "misdirected bounces" a form of spam, or "Unsolicited Bulk Email" (UBE):
http://www.spamcop.net/fom-serve/cache/329.html#bounces
IronPort estimates the damage from backscatter or misdirected bounces in the billions of dollars per year:
http://www.ironport.com/company/pp_network_world_04-24-2006.html
And now for stuff that you really don't want to read, but if you're new to this, it might help.
Why do you use TMDA? Isn't the "consensus" that Challenge/Response is bad? Won't SpamCop blacklist TMDA addresses?
Don't spammers exploit SPF themselves to send their messages? So what good is it?
Wow, you really need to switch to decaf, increase your meds, get a life, and listen to less Green Day. In this case, I am not sympathetic to the general suspicion of the liberal, whack job, anti-globalist, black-heliocopter crowd (but I only say this in the most kind, and loving way!). Let's say, for example, that Microsoft, or the Department of Justice, or banks, fiduciaries, business, etc., use SPF on their servers to reduce phishing and spam attacks. Guess what: that benefits everyone else who chooses to use SPF. Reducing forged email as close as possible to the source is good for everyone. As long as it's voluntary, what is the downside for everyone else?
Capitalist tool! Did you not write all these questions yourself? Take your own advice!- What in the world is a "550" message? You really didn't send me a "550" message! Outrageous!
-
Well, technically, if my mailbox got backscatter, your server sent me a "550" message. 550 messages are usually about relaying mail, such as "Relaying Denied", "Unable to relay for email address", "user unknown", "Mail undeliverable", "Relaying is prohibited", "This address is not allowed", "not local host somehost.com , not a gateway", or the rare but beautiful #571: "email address we do not relay". The spammer forged an email address at this domain, your server tried to relay it, found no receiving address, and bounced it back to our mailbox. Nobody here, however, had anything to do with the original message. So 550 to you to. Get SPF. Use it. Stop backscatter, and all will be forgiven. Love will reign, peace on earth, etc.
- Seriously? Do you really mean 550 to me too?
- I didn't send you a "real" 550 message, in the technical definition. You sent your backscatter to the mail server at our domain host, and it sent you the 550 message. "Real" 550 messages come from MTA servers, and not from responders, challenge systems, etc. So, no, I don't really mean it. 550 messages are necessary parts of the internet, so genuine email messages, relays, etc., can operate.
- So you're an expert on this stuff?
- Nope, just the opposite. I'm just someone who got sick of spam and backscatter, and the evil vermin who forge someone else's domain name (spoofing), especially mine. I'm only putting stuff up here that I have read elsewhere. But, hey, you sent me the 550 message first. Thanks for sharing!
- We just recently quit using TMDA and "catch all" mailboxes. SpamCop doesn't like TMDA, and the domain host suggest we don't use "catch all" mailboxes. They both have very good reasons for this. I still think the idea could work, but it would take too much effort and cooperation at the moment, and some of that would have to come from me (oh no!). So perhaps I'll try it again later, but not for the forseeable future.
- SpamCop frowns on autoresponders in general. The domain host, highspeedrails, thinks catch all mailboxes are spam magnets. I'm not seeing a "consensus" on this on the internet (but be wary of consensus! see below), and I'm still not sure how "catchall" mailboxes validate usernames for a domain. Maybe spammers don't need to actually validate user names with smtp, but "catchalls" help them in other ways.
- That's really too bad, because catchall boxes serve a good purpose: they can allow domains to help out email users who happen to mis-spell an address. I don't know enough to say, but I'm guessing that catchalls, TMDA, Blacklisting, SPF - in fact, any system to validate genuine email - has a valuable use, but usually in limited situations. Problems usually require a variety of solutions, and the more the merrier. My guess is that SPF has the greatest potential to solve the problem of "Sender Address Forgery". That won't stop all spam, but it will put a huge dent in the ability of spammers to get through to mailboxes. SpamAssasin, TMDA, etc., would have much less work to do.
- We formerly used TMDA on our "catch all" mailbox to direct people to this web page. We don't use it for other mailboxes. But we have a very small number of users. So I have no idea about the "consensus". "Consensus" sounds good, but wouldn't we all be walking behind oxcarts, and going to the doctor for leeches and blood letting if we relied on consensus alone? Doesn't the lack of consensus make the internet such a great (if, at times, unpleasant) thing? Think about that before you take away innovation, creation, freedom, and a host of other things by appealing to consensus.
- I have heard back from SpamCop. They suggest I not use a catchall with TMDA. It appears that the only auto-respondsers they suggest at the actual 550 messages from mailservers: http://www.spamcop.net/fom-serve/cache/329.html
- This is beyond my expertise, but I'm going out on a limb here, and say that spammers will - and do - exploit any tool developed, even those designed to reduce spam. Backscatter, that is, MTA's bouncing messages, is just one. They will also publish SPF records for their own domains: http://news.bbc.co.uk/1/hi/technology/3631350.stm. But the BBC article seems to miss the point, and the impression it leaves is false. SPF only claims to be one part of the answer to spam and email integrity. The developers of SPF will tell you don't count on it or any other single tool to get rid of spam.
- You can find threads, fora, etc., that argue for and against deploying SPF: http://www.imc.org/ietf-mxcomp/mail-archive/msg04591.html. SPF, SenderID, PRA, try to ask the question of "authenticity", not "spamness". Does the domain name in the sender address list the server from which the message came? If not, it's probably not authentic, and probably spam. SpamAssassin attempts to determine "spamness". TMDA tries to authenticate the sender with an actual response. Lists (white, black) relay on reporting input for spammer IP's. Gmail appears to try to do all of the above.
-
So the end part of the URL of this page is wrong, or an exaggeration, isn't it? You can't really stop spam with SPF, you can only slow it down.
- That's up to you, but practically, yes, you would find that any of these tools alone could prevent all spam, but you would also stop a lot of legitimate messages. Look for "Received-Spf:" headers in your email. Qmail servers, for example, can use SPF to take up to six different actions: http://www.saout.de/misc/spf/ ("2" seems to be the default for most MTA's). You can do something similar with your email client.
- Isn't SPF just a tool of the global-industrial-governmental-ngo-evil-bush-hitler-burton complex?!!!? It only benefits domain owners, not email users! That's why Microsoft and AOL use it! Cuba Libre! WHAT ABOUT THE CHILDREN!???!!!! THE POLAR BEARS ARE DROWNING!!!!!