I’ve been blacklisted by www.backscatterer.org and have been trying to figure out exactly how this has happened.
The initial blacklisting happened on the 18th October, and I think I have found the culprit, but need some more information regarding backscatter as I’m a little confused as to a few things.
When an email is sent to an account that doesn’t exist, the mail server at the moment sends this:
Delivery to the following recipient failed permanently:
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.1.1 firstname.lastname@example.org: Recipient address rejected: User unknown in virtual alias table (state 14).
----- Original message -----
Received: by 10.100.200.14 with SMTP id x14mr2202787anf.52.1257428197067; Thu,
05 Nov 2009 05:36:37 -0800 (PST)
Date: Thu, 5 Nov 2009 13:36:37 +0000
From: Paul email@example.com
Content-Type: multipart/alternative; boundary=0016368e1a8f044c8f04779fd1a9
Is this counted as Backscatter?
ways to avoid is using greylisting and not sending bounce messages, instead do a reject. There is more but you may want to consult the wiki on it.
The default configuration of Postfix and the mail processing stack in Virtualmin is pretty resistant to backscatter…but there are a handful of configuration settings that can make it more likely.
It looks like you’ve setup a catch-all forwarding alias? That would definitely open you up to backscatter, as your mail server cannot reject during the initial connection, and can only forward the message along to the forward address. Catch-alls of pretty much any type that then bounce during delivery will permit backscatter.
Actually, any kind of bounce (anything that happens during mail delivery rather than during the initial connection) will permit backscatter. So, if you configure the spam or AV filters to bounce rather than quarantine or delete the mail, backscatter will be enabled. We frequently get folks asking to bounce spam or viruses, by default, but that’s old school thinking…you just can’t do it these days, because you become an active participant in spamming by doing so.
As ronald mentioned, greylisting will dramatically reduce backscatter…but it’s a side effect of the way spammers currently operate, and probably won’t always be true. The only real way to completely stop it is to never bounce and never forward to recipients that might bounce (realistically, one still probably needs to bounce under some circumstances; quota overage, primarily).
Thanks for the responses. I’m pretty sure that Postfix is doing the right thing and sending rejects. What is interesting is that I have had one ‘count’ of backscatter:
A total of 1 Impacts were detected during this listing. Last was 18.10.2009 12:00 CEST +/- 10 minutes.
Earliest date this IP can expire is 15.11.2009 11:00 CET.
Seems a little draconian don’t it?
lol so one count of backscatter gets you blacklisted. Gheez, we better shut down the servers.
according to there website…
Listing Policy is quite simple. Every IP which backscatters or does sender callouts will be listed the next 4 weeks here.
Seems to be harsh and sender callouts is quite common, even SourceForge uses this method.
But then again UCEPROTECT is much harsher then even SORBS is and there is almost no 100% way to prevent backscatter unless you d/c from the net.
There IS an easy 100% way to prevent backscatter, and the default Postfix configuration provides it.
Do not enable address verification, and do not send bounce messages.
The reasoning is clear. Much spam is sent with forged Sender addresses. Verification and bounce messages abuse innocent parties who had nothing whatsoever to do with the mail you’re receiving.