
Backscatter is the flood of messages received when an email address is forged as the sender on spam messages. Backscatter is caused by people who don't reject mail during delivery, but instead accept the mail and then later send back a bounce message.
Problems arise with bounces if they are sent by a mail server to a non-local recipient. Technically bounces are called non-delivery reports (NDR) or delivery status notifications (DSN). If a message did not originate locally, then a mail server cannot know for sure if the address it is sending the bounce to is forged or not. This quickly leads to this unsolicited “backscatter” (or more rarely “outscatter”), sent to sites that never originated the email.
GFI
MailEssentials for Exchange/SMTP – www.gfi.com/mes/
– Stop
98% of spam mail, including phishing emails, image spam and PDF spam!
Download GFI MailEssentials for Exchange/SMTP free 30 day trial today! FREEWARE
version available with disclaimers.
MagicSpam
– www.magicspam.com/
Mail
Non Delivery Message DDoS Attacks - www.techzoom.net/publications/papers.en#mailbomb
Backscatter
from spam firewalls and anti-virus - www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#109
Collateral
spam - www.ja.net/services/csirt/advice/policies/collateral-spam.html
The Backscatter Problem
- www.tuffmail.com/backscatter.php
Misconfigured Email: Is
Your IT Department Breaking the Law? - unixworks.net/papers/wp-020.pdf
Bouncing is evil -
www.sput.nl/spam/bad-bounce.html
Why you shouldn't bounce spam and
viruses - www.dontbouncespam.org/
Backscatter:
What is it? How do I stop it? - www.spamresource.com/2007/02/backscatter-what-is-it-how-do-i-stop-it.html
spam backscatter
and joe-jobs - secondwheel.googlepages.com/backscatter
Email
backscatter victims unite - backscattervictims.blogspot.com/2007/10/email-backscatter-victims-unite.html
Probe the Net — backscatter
server results - www.probethenet.com/results
It is not easy to cope with the floods of backscatter email that occur when a spammer forges your email addresses. Options include blacklisting the worst culprits, and enabling bounce, session and message verification techniques such as BATV, SPF and DomainKeys - the bounce verification lets you determine which bounces are in response to your own email, and session and message verification can help reduce the number of backscatter emails sent back.
Postfix Backscatter
Howto - www.postfix.org/BACKSCATTER_README.html
How can I control
unsolicited bounces? - www.spamcop.net/fom-serve/cache/380.html
Backscatterers - www.backscatterers.com/
How
to deal with backscatter - www.spamnation.info/notes/guides/BackscatterFAQ.html
Dealing
with joe jobs - research.mince.ac.nz/NZNOG_2007_Dealing_With_Joe_Jobs.ppt
My
email address is being used in spam! - www.spamresource.com/2007/07/ask-al-my-email-address-is-being-used.html
Bounce pi: where did my bounce come from?
- bouncepi.com/
If you run a mail server you have a responsibility not to send backscatter. Bounces should ideally only be generated by a mail server to a local recipient. Mail servers should not generate bounces to non-local recipients, but should instead reject the mail during the SMTP session, and leave the remote sending server to handle the bounce: if a rejected mail is a legitimate message, the bounce gets generated by the remote sending machine, as expected; if a rejected mail is not a legitimate message, the remote end will probably not generate a bounce, and all is still well.
The MX should be made aware of the status of user mailboxes on the local system that the mail will eventually be delivered to. To reduce the chances of a bounce being necessary, DNSBLs should be used to reject spam during the SMTP session based on the sending IP address, and content based spam filters should be used to identify and reject spam during the SMTP session, during the DATA phase.
If your mail server isn't listed here, try reading the FAQ or the user manual of your mail server about this issue, in particular for how to query LDAP servers for valid user accounts. If you find a useful resource about this, contact us. Otherwise, you might find an addon for your mail server that can reject mail, or there might be a server-side spam filter for your platform that can carry out this rejection.
If you are planning to run LDAP queries on your Active Directory (or other internal LDAP server) then you should probably mirror it onto a custom LDAP server to avoid affecting internal lookups.
SPAM
SMTP Reply Code:
Proposal - jamesthornton.com/writing/spam-smtp-reply-code.html
MTAs bouncing incorrectly
- goldmark.org/email/badbounce.html
No “Fast Fail”
in James - wiki.apache.org/james/NoFastFail
Unintended consequences
– Backscatter vectors - chris-linfoot.net/d6plinks/CWLT-6F5CM3
Bouncing messages
do no good - pm-lib.sourceforge.net/README.html#2
Spam Bounces
Considered Harmful - www.ja.net/services/csirt/threats/bounce.html
The
Problem of Backscatter - www.tpa.secnap.com/support/faqs/email-spam-backscatter.html
If Sendmail is your only mail relay, it by default rejects mail to non-existant
local users. If you are using Sendmail as a relay to a further destination
host you can use several M4
features to tackle this problem. Depending on your setup you may find
virtusertable,
access_db,
or ldap_routing
useful. If those don't do the job then milter-ahead is specifically designed
to help, and other milters
may also include this sort of feature.
milter-ahead
- www.milter.info/sendmail/milter-ahead/
scam-backscatter
- www.elandsys.com/scam/scam-backscatter/
How to
avoid Backscatter in Sendmail - elqui.dcsc.utfsm.cl/util/email/backscatter.html
- simple how-to with access_db
ldap_routing
- www.sendmail.org/m4/ldap_routing.html
- feature to enable
LDAP lookups
virtusertable
- www.sendmail.org/m4/features.html#virtusertable
- feature to allow
more flexible user table handling
Rejecting
Unknown Recipients - www.postfix.org/LOCAL_RECIPIENT_README.html
Postfix
as a relay in front of Exchange - postfix.state-of-mind.de/patrick.koetter/mailrelay/
goodrcptto - www.chater.demon.co.uk/qmail/
LDAP with qmail - www.lifewithqmail.org/ldap/
bad-rcpt-noisy-patch
- www.iecc.com/bad-rcpt-noisy-patch.txt
qmail-realrcptto - code.dogmap.org./qmail/
Recipient checking
- http.netdevice.com:9080/qmail/rcptck/
Qmail-LDAP
- www.qmail-ldap.org/wiki/index.php/Main_Page
Exim : Checking maildir quotas at SMTP RCPT time - www.timj.co.uk/linux/rcpt-time-quota-maildir.php
How to control non-delivery
reports when you use Exchange 2000/2003 - support.microsoft.com/?kbid=294757
Using Clam AntiVirus with MIMEDefang: Reject all Malware - sial.org/howto/mimedefang/clamav/#s3.2
Warning
on enabling NDR generation - forums.gfi.com/Warning:_Enabling_NDR_generation_for_DH_module_may_allow_spammers_to_exploit_ME_server/m_900744292/tm.htm
- GFI MailEssentials
Controlling
backscatter in Mailman - wiki.list.org/display/SEC/Controlling+spam
- Mailman
How does Sympa deal with
spam? - www.sympa.org/dev-manual/antispam
- Sympa
Preventing
Backscatter in MailEnable - www.mailenable.com/kb/Content/Article.asp?ID=me020492
- MailEnable
Some client-side spam filters are starting to use a “fake bounce” feature. The concept of sending fake bounces can be very seductive to those who don't understand the consequences. Firing off a fake bounce gives a temporary feeling of power to the spammed, but it is futile and abusive.
The Anti-Virus
Industry Scam - www.infowarrior.org/articles/2004-05.html
Anti-Virus
Companies: Tenacious Spammers - attrition.org/security/rant/av-spammers.html
80% of the spam I get is
from Norton Antivirus - www.jwz.org/gruntle/virus.html
Clueless virus
filters spam innocent third parties - www.joewein.de/sw/spam-virus-warnings.htm
Yes,
(some) antivirus companies are spammers - www.f-prot.com/news/gen_news/040130_open_letter.html
Callouts or callbacks (aka Sender Address Verification - SAV) are a form of backscatter. They are used by receiving systems to attempt to verify that a remote user mailbox exists, by attempting delivery to that mailbox and viewing the response. If badly implemented then they can cause a denial of service on a system that had its domain forged into the spam. They use a RCPT TO command to test delivery, attempting to replicate what the (often disabled) VRFY command allowed.
Exim
"Callout verification" - www.exim.org/exim-html-4.50/doc/html/spec_39.html
Limitations
of address verification - www.postfix.org/ADDRESS_VERIFICATION_README.html#limitations
Callback verification
- en.wikipedia.org/wiki/Callback_verification
Sender
Callout Verification - tldp.org/HOWTO/Spam-Filtering-for-MX/smtpchecks.html#callback
Validating the sender
domain - www.avertlabs.com/research/blog/?p=241
Whatever
happened to VRFY? - www.spamresource.com/2007/01/whatever-happened-to-vrfy.html
No
anti-UBM measure for SMTP-based Internet mail works - homepages.tesco.net/J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html#CallBackVerification
How not to design an MTA
— part 6 — address verification - fanf.livejournal.com/70432.html
Sender Address Verification
considered harmful - taint.org/2007/03/16/134743a.html
Challenge/Response is often implemented in a similar fashion to non-delivery reports, or bounces. Done that way, it can carry many of the same problems that are associated with bounces.