Backscatter

I've seen an increase in backscatter emails recently. Perfectly valid  
headers (AFAICT)

Return-Path: <>
X-Original-To: [hidden email]
Delivered-To: [hidden email]
Received: from mail9.webair.com (mail9.webair.net [74.206.236.69])
        by mail.covisp.net (Postfix) with ESMTPS id 4FC10118B5B0
        for <[hidden email]>; Sat,  4 Apr 2009 00:18:38 -0600 (MDT)
Received: (qmail 45760 invoked for bounce); 4 Apr 2009 06:18:36 -0000
Date: 4 Apr 2009 06:18:36 -0000
From: [hidden email]
To: [hidden email]
Subject: failure notice
Message-Id: <[hidden email]>

But the message they are bouncing is not mine:

--- Below this line is a copy of the message.

Return-Path: <[hidden email]>
Received: (qmail 45698 invoked by uid 89); 4 Apr 2009 06:18:34 -0000
Received: from unknown (HELO m4mlux-m4f14) (85.9.127.134)
  by mail9.webair.com with SMTP; 4 Apr 2009 06:18:34 -0000
Received-SPF: neutral (mail9.webair.com: 85.9.127.134 is neither  
permitted nor denied by SPF record at kreme.com)
Message-ID: <20090404134844.3352.qmail@m4mlux-m4f14>
To: [hidden email]
Reply-To: [hidden email]
Subject: RE:U.S.A. Pharmacy Discount ID948168547


(I did just update this spf record to "v=spf1 a mx  
ip4:75.148.117.94/29 ~all" which I expect will help some)

Is there some sort of strategy I can implement that will reject a good  
portion of these kinds of messages? What are other people doing to  
deal with backscatter? I read up on SRS, but it doesn't sound like a  
great idea.

--
Satan oscillate my metallic sonatas

[Paweł Leśniak]

W dniu 2009-04-04 20:09, LuKreme pisze:

> I've seen an increase in backscatter emails recently. Perfectly valid
> headers (AFAICT)
>
> Return-Path: <>
> X-Original-To: [hidden email]
> Delivered-To: [hidden email]
> Received: from mail9.webair.com (mail9.webair.net [74.206.236.69])
>     by mail.covisp.net (Postfix) with ESMTPS id 4FC10118B5B0
>     for <[hidden email]>; Sat,  4 Apr 2009 00:18:38 -0600 (MDT)
> Received: (qmail 45760 invoked for bounce); 4 Apr 2009 06:18:36 -0000
> Date: 4 Apr 2009 06:18:36 -0000
> From: [hidden email]
> To: [hidden email]
> Subject: failure notice
> Message-Id: <[hidden email]>
>
>
> (I did just update this spf record to "v=spf1 a mx
> ip4:75.148.117.94/29 ~all" which I expect will help some)
>
> Is there some sort of strategy I can implement that will reject a good
> portion of these kinds of messages? What are other people doing to
> deal with backscatter? I read up on SRS, but it doesn't sound like a
> great idea.
>

I'd recommend using rbl checks specified for this:
backscatter.map:
<> reject_rbl_client ips.backscatterer.org, reject_rbl_client
bl.spamcannibal.org
postmaster reject_rbl_client ips.backscatterer.org, reject_rbl_client
bl.spamcannibal.org
MAILER-DAEMON reject_rbl_client ips.backscatterer.org, reject_rbl_client
bl.spamcannibal.org

Add
check_sender_access hash:/etc/postfix/backscatter.map
at the very last of RBLs in smtpd_recipient_restrictions (or other
restrisctions if you prefer). For sure you should also read info on
those blacklists.

IP you've provided as source of backscatter is listed in backscatterer.org.

Moreover, SPF won't help you much, because other mailserver admins would
have to check it, and it's rarely supported.

Pawel Lesniak

[Noel Jones-2]

Paweł Leśniak wrote:
> W dniu 2009-04-04 20:09, LuKreme pisze:
>> I've seen an increase in backscatter emails recently. Perfectly valid
>> headers (AFAICT)
>>
>> Return-Path: <>
...

Not surprising, since the message is sent by a real MTA.

>>
>> Is there some sort of strategy I can implement that will reject a good
>> portion of these kinds of messages? What are other people doing to
>> deal with backscatter? I read up on SRS, but it doesn't sound like a
>> great idea.
>>
> I'd recommend using rbl checks specified for this:
> backscatter.map:
> <> reject_rbl_client ips.backscatterer.org, reject_rbl_client
> bl.spamcannibal.org

Good suggestion.  This will reject bounces from known
backscatter sources.

> postmaster reject_rbl_client ips.backscatterer.org, reject_rbl_client
> bl.spamcannibal.org
> MAILER-DAEMON reject_rbl_client ips.backscatterer.org, reject_rbl_client
> bl.spamcannibal.org

These two will never match anything.  With a little adjustment
they *might* be useful in a PCRE map.

>
> Add
> check_sender_access hash:/etc/postfix/backscatter.map
> at the very last of RBLs in smtpd_recipient_restrictions (or other
> restrisctions if you prefer). For sure you should also read info on
> those blacklists.

Best in smtpd_data_restrictions so you don't reject
sourceforge and others sender verification probes.

>
> IP you've provided as source of backscatter is listed in backscatterer.org.
>
> Moreover, SPF won't help you much, because other mailserver admins would
> have to check it, and it's rarely supported.

True.  It "seems" that sites with SPF are less frequently
chosen as joe-job victims, but there's no guarantee.  At any
rate, adding SPF shouldn't hurt anything.

Other suggestions...

Add the header_checks suggested in
http://www.postfix.org/BACKSCATTER_README.html
Note the examples will need to be "customized" for your site.

If you're using SpamAssassin, the VBOUNCE rules are helpful.

If you're using amavisd-new, it has some bounce-killer
features that might help.  Check amavisd-new release notes for
details.  IIRC this is part of the "penpals" feature of
amavisd-new.

If you're using clamav, the Sanesecurity addon signatures kill
some common backscatter.

If all else fails and your system is drowning, it might not be
unreasonable to TEMPORARILY reject all mail from the null
sender.  This is a last resort measure and will reject legit mail.

   -- Noel Jones

On 4-Apr-2009, at 16:02, Noel Jones wrote:
> Best in smtpd_data_restrictions so you don't reject sourceforge and  
> others sender verification probes.

Is there anything I need to be concerned about having/not having in  
smtpd_data_restrictions?  it is currently commented out.  if I simply  
put:

smtpd_data_restrictions =
     reject_unauth_pipelining,
     reject_rbl_client ips.backscatterer.org,
     reject_rbl_client bl.spamcannibal.org
     permit

is that good enough?  (the pipelining was there before in the  
commented out declaration along with the permit). I am sad to say I am  
still a little unclear about how the various smtpd_mumble_restrictions  
work together.

>> IP you've provided as source of backscatter is listed in  
>> backscatterer.org.
>> Moreover, SPF won't help you much, because other mailserver admins  
>> would have to check it, and it's rarely supported.
>
> True.  It "seems" that sites with SPF are less frequently chosen as  
> joe-job victims, but there's no guarantee.  At any rate, adding SPF  
> shouldn't hurt anything.

Well, I am hoping spf helps a bit. I'd left off the ~all on some  
domain's configuration and I've noticed a lot os this backscatter has

Received-SPF: neutral (mail9.webair.com: 85.9.127.134 is neither  
permitted nor denied by SPF record at kreme.com)

> Other suggestions...
>
> Add the header_checks suggested in http://www.postfix.org/BACKSCATTER_README.html
> Note the examples will need to be "customized" for your site.

Oh, those look like a good idea in general, backscatter or not. At  
least in the header_checks.  I am leery of running body_checks as it  
seems those would be expensive.

> If you're using SpamAssassin, the VBOUNCE rules are helpful.


Yeah, but SA is run after reception.  I'd rather reject backscatter  
than discard it, if possible.

Thanks, this is great info.

--
I'll trade you 223 Wesley Crushers for your Captain Picard

[Sahil Tandon]

On Sat, 04 Apr 2009, LuKreme wrote:

> On 4-Apr-2009, at 16:02, Noel Jones wrote:
>> Best in smtpd_data_restrictions so you don't reject sourceforge and  
>> others sender verification probes.
>
> Is there anything I need to be concerned about having/not having in  
> smtpd_data_restrictions?  it is currently commented out.  if I simply  
> put:
>
> smtpd_data_restrictions =
>     reject_unauth_pipelining,
>     reject_rbl_client ips.backscatterer.org,
>     reject_rbl_client bl.spamcannibal.org
>     permit

The trailing permit is unnecessary.  And some people worry about blocking
legitimate mail from sites listed on those RBLs.  If you share that fear, you
could use an access(5) table to limit the RBL lookups (and rejections) only
to null envelope senders.

> is that good enough?  (the pipelining was there before in the commented
> out declaration along with the permit). I am sad to say I am still a
> little unclear about how the various smtpd_mumble_restrictions work
> together.

For more clarity and general illumination, see:
http://www.postfix.org/SMTPD_ACCESS_README.html

--
Sahil Tandon <[hidden email]>

On 4-Apr-2009, at 16:02, Noel Jones wrote:
> Best in smtpd_data_restrictions so you don't reject sourceforge and  
> others sender verification probes.


That didn't go well:

Apr  4 20:15:28 mail postfix/smtpd[16843]: 60D15118AC14: reject: DATA  
from english-breakfast.cloud9.net[168.100.1.7]: 554 5.7.1 Service  
unavailable; Client host [168.100.1.7] blocked using  
ips.backscatterer.org; Sorry 168.100.1.7 is blacklisted at http://www.backscatterer.org/?ip=168.100.1.7 
; from=<[hidden email]> to=<[hidden email]>  
proto=ESMTP helo=<english-breakfast.cloud9.net>


--
Say, give it up, give it up, television's taking its toll
That's enough, that's enough, gimme the remote control
I been nice, I been good, please don't do this to me
Turn it off, turn it off, I don't want to have to see

[Paweł Leśniak]

W dniu 2009-04-05 04:27, Sahil Tandon pisze:

On Sat, 04 Apr 2009, LuKreme wrote:

  

On 4-Apr-2009, at 16:02, Noel Jones wrote:
    

Best in smtpd_data_restrictions so you don't reject sourceforge and  
others sender verification probes.
      

Is there anything I need to be concerned about having/not having in  
smtpd_data_restrictions?  it is currently commented out.  if I simply  
put:

smtpd_data_restrictions =
    reject_unauth_pipelining,
    reject_rbl_client ips.backscatterer.org,
    reject_rbl_client bl.spamcannibal.org
    permit
    

The trailing permit is unnecessary.  And some people worry about blocking
legitimate mail from sites listed on those RBLs.  If you share that fear, you
could use an access(5) table to limit the RBL lookups (and rejections) only
to null envelope senders.
  

You should NEVER use ips.backscatterer.org as global RBL. You'll block legitimate mails for sure. The question is only how many.
Also using bl.spamcannibal.org for all senders is not very safe. Before using ANY RBL read what it actually does.

From backscatterer.org site:
"Listing Policy is quite simple. Every IP which backscatters or does sender callouts will be listed the next 4 weeks here."
So every host which does email verification would be entirely blocked, and that's almost surely not what one would want.
And on more citation:
"Unfortunable many and also big providers do still backscatter. They are flooding you with bounces but will almost always send real mail too.
As long as you are not a BOFH nor having the intention to boycott such servers 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.
Used in safe mode ips.backscatterer.org will protect you against misdirected bounces and sender callouts while you can not loose any real mail."

A bit different situation is with spamcannibal. It's "normal" RBL, but in my place it was giving 10 to 50 false positives daily. A month ago spamcannibal was stopping some backscatter. Now I get rarely any hits, but it's used as the very last RBL to check emails from <> ans postmaster. Soem citation from their site:

"The ONLY way you can get into SpamCannibal's database is by sending spam or virus ladened email to our mail servers!
SpamCannibal does not block email access except for IP addresses and ranges that have sent or relayed what we believe to be spam or other unsolicited email directly to our email servers. SpamCannibal uses its database to block access by IP addresses ONLY for its own mail servers, however, the database we use for that purpose is freely available for anyone to look at and use as they see fit. "

So if one would do a typo in email and got into their honeypot, the host (or subnet) is getting blacklisted. For me it's much to simple to get blacklisted at spamcannibal.org.


Pawel Lesniak

[mouss-4]

LuKreme a écrit :

> On 4-Apr-2009, at 16:02, Noel Jones wrote:
>> Best in smtpd_data_restrictions so you don't reject sourceforge and
>> others sender verification probes.
>
> Is there anything I need to be concerned about having/not having in
> smtpd_data_restrictions?  it is currently commented out.  if I simply put:
>
> smtpd_data_restrictions =
>     reject_unauth_pipelining,
>     reject_rbl_client ips.backscatterer.org,
>     reject_rbl_client bl.spamcannibal.org
>     permit
>

The RBL checks you added will reject legitimate mail. As already
suggested, use a check_sender_access map to call these RBLs only when
the sender is "null".


> is that good enough?  (the pipelining was there before in the commented
> out declaration along with the permit). I am sad to say I am still a
> little unclear about how the various smtpd_mumble_restrictions work
> together.
>

in the default setup (smtpd_delay_reject=yes):

- smtpd_client_restrictions, smtpd_helo_restrictions,
smtpd_sender_restrictions and smtpd_recipient_restrictions are done
after each RCPT TO command.

- smtpd_data_restrictions is done after the DATA command

An smtp transaction goes like this (I am only showin client commands)

EHLO host.example.net
MAIL FROM:<[hidden email]>
RCPT TO:<[hidden email]>
RCPT TO:<[hidden email]>
RCPT TO:<[hidden email]>
...
DATA
...
QUIT


>
> Well, I am hoping spf helps a bit. I'd left off the ~all on some
> domain's configuration and I've noticed a lot os this backscatter has
>

AFAIK, there is no evidence that SPF helps at all. There were some
debate on this on the spamassassin and (if my memory can be trusted) on
the amavisd-new lists.

What I can tell is that I have no SPF records, and while the server gets
a lot of spam, backscatter happens (relatively) rarely (yes, it happens
as huge storms, but the overall frequency is very low).

> [snip]
> Oh, those look like a good idea in general, backscatter or not. At least
> in the header_checks.  I am leery of running body_checks as it seems
> those would be expensive.
>

if you only put few checks, it's ok.

>> If you're using SpamAssassin, the VBOUNCE rules are helpful.
>
>
> Yeah, but SA is run after reception.  I'd rather reject backscatter than
> discard it, if possible.
>

sure, but you can't reject all backscatter. so you need a way to at
least deliver the missed ones to a specific location... etc.

[Noel Jones-2]

LuKreme wrote:

> On 4-Apr-2009, at 16:02, Noel Jones wrote:
>> Best in smtpd_data_restrictions so you don't reject sourceforge and
>> others sender verification probes.
>
>
> That didn't go well:
>
> Apr  4 20:15:28 mail postfix/smtpd[16843]: 60D15118AC14: reject: DATA
> from english-breakfast.cloud9.net[168.100.1.7]: 554 5.7.1 Service
> unavailable; Client host [168.100.1.7] blocked using
> ips.backscatterer.org; Sorry 168.100.1.7 is blacklisted at
> http://www.backscatterer.org/?ip=168.100.1.7; 
> from=<[hidden email]> to=<[hidden email]>
> proto=ESMTP helo=<english-breakfast.cloud9.net>
>
>

The example showed using an access map that only checked mail
with the null sender.

As you see, using ips.backscatterer.org as a general purpose
RBL is unsafe.

   -- Noel Jones

[Scott Lewis-14]

On Apr 5, 2009, at 2:53 AM, Paweł Leśniak wrote:

> A bit different situation is with spamcannibal. It's "normal" RBL,  
> but in my place it was giving 10 to 50 false positives daily. A  
> month ago spamcannibal was stopping some backscatter. Now I get  
> rarely any hits, but it's used as the very last RBL to check emails  
> from <> ans postmaster. Soem citation from their site:

Agree with your both of your comments but in the interest of brevity  
only quoted the above. One has to be super careful in checking against  
RBLs - understand their criteria! I've ended up doing three:

1) Barracuda's BRBL http://www.barracudanetworks.com/ns/news_and_events/index.php?nid=305 
  - This is fantastic, and as a Barracuda customer I've always had  
access to it - it's now free.
2) Spamcop.net
3) Spamhaus

Another thing to watch for is if your particular RBL has a blacklist  
of dynamic IP addresses, that you either disable deep header scanning,  
or disable it just for that one RBL. It's one thing to refuse mail  
from hosts whose reverse DNS points to  
254.1.168.192.dynamic.adsl.bellsouth.net, but if you are scanning all  
headers, you might find an address like that from somebody who  
legitimately sends mail through their from a mail client.

Backscatter looks very interesting, though, I was not aware of it and  
will check into it immediately.

On 5-Apr-2009, at 06:33, Noel Jones wrote:
> The example showed using an access map that only checked mail with  
> the null sender.


Oh, right. Doh.

--
In England 100 miles is a long distance. In the US 100 years is a
        long time