Email Help, Backscatter, and How to Stop Spam Spoofing with SPF
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.
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:
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.
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
- 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!!!!!