The other day a customer on a Plesk-based Ubuntu 10 server of mine sent me a question
concerning a blocked email from him to an address at AT&T. It contained the following:
DNSRBL: Blocked for abuse. See http://att.net/blocks.
The AT&T link is useless except for the following explanation of why they return 521.
A nondelivery report containing the error code 521 indicates that a specified mailing system is blocked because it has displayed behavior consistent with spamming or other forms of abuse of network resources. This behavior has been noted by our system, by other reputable monitors of network activity, or by both.
We're spammers?? No one is more of an anti-spam fiend than I (more on that later), so I head over to DNSBL.info and here's what I find.
Wellwellwell! Who are these guys that AT&T trusts so completely that they'll block all mail from a modern well-maintained virtual-host server, even though there is no other indication that this server has done anything wrong? I hop over to backscatterer.org to have a look. My first impression is pretty good: they provide a log pointer that even includes a link to a time converter to convert from Berlin time (although if you think about it for a second, a UTC or a Unix Timestamp would have been better).
To track down what happened investigate your smtplogs near 05.03.2011 11:44 CET +/-1 minute.
I check the logs, and find that we received a piece of spam 'from' an address that must be part of backscatterer.org's spam trap (in appreciation for their classiness in showing it to us, and in case I'm wrong about them being evil, I've decided not to reveal it), to which our server (qmail) responded with a bounce. Here is what backscatterer.org says about bounces. Notice, however, the example they give:
Spammer fakes ‘from’ to be email@example.com and sends out 30 million emails with that forged sender, what do you think will happen?
If yourcompany.tld has a properly configured mail server, the SMTP dialog will look like this:
MAIL FROM: firstname.lastname@example.org
RCPT TO: NoSuchUser@yourcompany.tld
550 User unknown
They're saying reject don't bounce, and absolutely: if your server is sending out thousands of 'unknown user' errors as bounces rather than rejections, you are definitely contributing to the backscatter problem. You might ask: what's the difference between a rejection and a bounce? A rejection happens in the conversation between the sending and receiving MTA's, what backscatterer.org calls the 'SMTP dialog', and it looks like their example above. A bounce happens after the receiving MTA has accepted the message. If it then decides it can't deliver the message, it sends a failure message to the address specified in the 'from' field of the original message. The bounce messsage usually includes stuff like "Sorry it didn't work out..." and quotes the original message. These traditions were established in less brutish times. You can see how sending bounces about unknown users can contribute significantly to internet traffic, especially if a server has no provision for dictionary attacks.
Here's the thing though: our server didn't send an 'unknown user' bounce; it sent a 'mail quota exceeded' bounce. Now, do I think receiving MTA's should reject messages when the receiving mailbox is full, and rely on the sending MTA to report the error to the sender? Absolutely! I think they should do that about every error condition that can reasonably be known at the time of the 'SMTP dialog'. The problem is they don't. It's not a configuration error by 'lazy' admins; there is no way that I have ever found to configure either qmail or Postfix (the two mail servers available with Plesk) to do that. If anyone out there knows a way, let me know; I will joyfully implement it and post your correction here. How about you backscatterer.org? What's that setting in /etc/postfix/main.cf? Update 120304: still no responses at all.
Where does that leave us? Essentially backscatterer.org is saying that all servers using qmail and Postfix—two of the top mail servers in the world— should be banned, even if they have never sent a single piece of spam. How about Exim and Sendmail? Are they configurable as described? Offhand I don't know; probably not. Sure, if you ban every mail server in the world there won't be any spam, but that's because there won't be any email.
Update 120313: Ta-da! I just found the following item in the Plesk 10.4.0 update notes, so at least for 'mail quota exceeded' things look better.
[+] (Only for Linux) Mailboxes do not accept new mail if the mailbox quota is exceeded. Both Qmail and Postfix will reject incoming mail when the target mailbox is over quota instead of bouncing it as before. The previous behavior was known as backscattering and might have caused Plesk server getting in antispam DNS blacklists.
Now let's have a look at the aforementioned 'email@example.com', backscatterer.org's artificial invented 'victim', for whom they labor so hard, shall we? I looked up the SPF record of the 'from' address of the logged spam. Nothing! So let me get this straight poor innocent fake victim: you continue to use an email address that has been compromised by spammers, and you don't bother to publish an SPF record? A mail server that sends a few pieces of backscatter a month is not the problem; YOU are the problem. That server would not have sent the bounces it sent if you hadn't been so pathologically feeble (or sleazy), because it would have seen from your SPF record that the spammer's sending MTA was not allowed, and dropped the message dead.
People, we don't need Yet Another Realtime Blackhole List, especially one that produces ugly false-positives that victimize real people to protect imaginary victims who, if they really existed, deserve their fate. The best place to attack spam is at the harvesting end. In April of 2002, I had one email address and was getting about 80 spams a day; now (in a much uglier environment) I have about 300, run no spam filters, and get no spam (I run server SPF checks but that doesn't affect my mail; for why see rule #4 below). How? Here is a good set of rules that tries to avoid any unforseen consequences of overzealousness.
Back in 2002, inspired by a sweet little cgi script named WPoison, I wrote a PHP script to guard contact pages. We warned bots using robots.txt and robots meta tags, then threw them into infinite recursion. I then retired the bad address. That was painful, of course, because I had to notify everyone I knew (see rule #3 above), but it changed my life.
You might ask: if it's this easy, and you give away the rules for free, what's with this giant multi-billion dollar industry? Good question.
At first I thought I might send backscatterer.org the above anaysis of the problems with their algorithm, so I hit the Contact link, where we are all told in obnoxious terms that we cannot contact them because they are permanently perfect in every way and the entire rest of the world is a bunch of scummy little worms who just want to beg them for mercy. I also notice that they ban IP's for 4 weeks (!Didn't I just recommend banning known attackers for an hour?), offer 'expressdelisting' for an undisclosed sum (update 110725: now explicitly $131 US), and threaten that your IP will be 'permanent listed' if you take 'legal action against the UCEPROTECT-Network.' Wow! This is mobster protection-racket talk. Did they just say they will list an IP even if that's a lie? I thought they were incompetent, but maybe they're evil! What were you thinking AT&T?
backscatterer.org: shame on you for being sleazy faux-righteous scumbags, and not publishing SPF records for your spam trap domains because you know that if you did 90% of your racket would go away.
AT&T: shame on you for hurting your customers and their correspondents by thoughtlessly using backscatterer.org as a 'reputable monitor' without sufficient research into their competence and practices, or even their own usage recommendations:
ATTENTION: ips.backscatterer.org is NOT a spammerlist. It's a Backscatterer list !!!
...we strongly recommend to use ips.backscatterer.org in SAFE MODE to prevent false positives. SAFE MODE means you will do DNSBL-Querys if MAIL FROM: is <> or postmaster only.
Update 150823: backscatterer.org's 'legal action' threat is gone.