A better backscatter killer?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

A better backscatter killer?

dennisthetiger
Looking at options here for eliminating backscatter.  

I've reviewed the Howto for this, but it only seems to be effective
against backscatter where one's home domain is forged - not too useful,
IMNSHO, because spammers aren't always going to forge the home domain.  

One thing I've been looking at doing is basically checking headers, and
if the From: header is null, then reject it immediately.

Other approach is to eliminate my 2ary MX from DNS - most of my spam
comes from that.  I don't really want to do that, though, because the
idea of a 2ary MX is for a fallback.

Thoughts?

-Dennis

Reply | Threaded
Open this post in threaded view
|

RE: A better backscatter killer?

MacShane, Tracy
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Dennis Carr
> Sent: Tuesday, 14 April 2009 12:15 PM
> To: [hidden email]
> Subject: A better backscatter killer?
>
> Looking at options here for eliminating backscatter.  
>
>
> One thing I've been looking at doing is basically checking
> headers, and if the From: header is null, then reject it immediately.
>

Then you won't receive some genuine messages, both bounce and
non-bounce.

Try the ips.backscatterer.org RBL; it works well for us.

http://www.mailinglistarchive.com/postfix-users@.../msg57402.htm
l

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Noel Jones-2
In reply to this post by dennisthetiger
Dennis Carr wrote:
> Looking at options here for eliminating backscatter.  
>
> I've reviewed the Howto for this, but it only seems to be effective
> against backscatter where one's home domain is forged - not too useful,
> IMNSHO, because spammers aren't always going to forge the home domain.  

and how do you receive it otherwise?

> One thing I've been looking at doing is basically checking headers, and
> if the From: header is null, then reject it immediately.

Of course this will reject legit bounces, which DO exist.  And
why check headers?  the From: header in bounces usually has
some form of postmaster, mailer-daemon, or such.
Maybe you're confusing envelope with headers, or maybe you
need to clarify what you're referring to.

Generally it's a poor trade to break the mail system structure
because of a few bad apples.  In times of severe stress it's
(mostly) acceptable to reject all bounces, but only as a
temporary measure to keep other mail flowing.

> Other approach is to eliminate my 2ary MX from DNS - most of my spam
> comes from that.  I don't really want to do that, though, because the
> idea of a 2ary MX is for a fallback.

Yes, a secondary MX is a spam magnet.  Unless you have the
time and resources to keep a secondary locked down as tight or
tighter - including a valid recipient list - than the primary
MX it's not worth the headaches.

>
> Thoughts?
>
> -Dennis
>

We use ips.backscatterer.org to reject bounces from known
backscatter sources.  Something like this:
# main.cf
smtpd_data_restrictions =
   check_sender_access regexp:/etc/postfix/backscatter.regexp

# backscatter.regexp
# check null sender bounces
/^<>$/  reject_rbl_client ips.backscatterer.org

Important note:  Do NOT use ips.backscatterer.org as a
general-purpose RBL.  It *will* reject legit mail.

The above example limits rejects to only mail with the null
sender.  This will reject legit bounces from known backscatter
sources, but at least the damage is limited.
Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Ralf Hildebrandt
In reply to this post by dennisthetiger
* Dennis Carr <[hidden email]>:
> Looking at options here for eliminating backscatter.  
>
> I've reviewed the Howto for this, but it only seems to be effective
> against backscatter where one's home domain is forged - not too useful,
> IMNSHO, because spammers aren't always going to forge the home domain.  

Uhhh, what else? Otherwise it wouldn't come "back" to you!

--
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
Der Router unseres ISPs verliert dauernd Pakete. Was zum Geier nutzen
die? Fisher Price, mein erster Router?
Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Ralf Hildebrandt
In reply to this post by dennisthetiger
* Dennis Carr <[hidden email]>:

> One thing I've been looking at doing is basically checking headers, and
> if the From: header is null, then reject it immediately.

The From: header is never null, since it has

From: MAILER-DAEMON
in it

> Other approach is to eliminate my 2ary MX from DNS - most of my spam
> comes from that.  I don't really want to do that, though, because the
> idea of a 2ary MX is for a fallback.
>
> Thoughts?

Apply constinstent rules and recipient verifisation on ALL your MX
hosts.

--
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of
their C Programs.
Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Ralf Hildebrandt
In reply to this post by MacShane, Tracy
* MacShane, Tracy <[hidden email]>:

> Then you won't receive some genuine messages, both bounce and
> non-bounce.
>
> Try the ips.backscatterer.org RBL; it works well for us.
>
> http://www.mailinglistarchive.com/postfix-users@.../msg57402.html

They are retarded. mail.charite.de is listed in it.

--
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
MMDF: A jumped up mailroom boy with a chip on his shoulder. Loves the
bureaucracy and takes great pride in stamping "illegal address" in red
ink on any mail it passes. Unpacks all the mail and repacks it in his
own special envelopes before delivery to end users.  
Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Paweł Leśniak
W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze:
> They are retarded. mail.charite.de is listed in it.
>    
You're definitely not right.
Testresult for 141.42.4.200:

This IP IS CURRENTLY NOT LISTED in our Database.

B U T, it was listed in the past !

History:
2008/05/13 08:49    listed
2008/06/10 09:30    expired
2008/07/08 09:38    listed
2008/08/22 11:30    expired
2009/03/02 17:00    listed
2009/04/12 13:07    expired

If they send too many bounces, or do SAV, they are listed on
backscatterer.org. That's simple.

Further - BECAUSE they are sending too many bounces it's quite good to
stop receiving bounces from them.

Anyways, I've found that backscatterer.org is able to stop large flows
of backscatter if they happen. When I was getting backscatter from many
different IPs, backscatterer.org was not helping at all. But that's when
body_checks work perfectly. As long as I'm a small site with ~10-20k
SMTP connections daily, I'm fine with this configuration. Also I've
found that 2 months after starting to use body_checks, the number of
rejects lowered dramatically from ~15-45k daily to ~10-18k daily. More
precisely number of rejects lowered from ~850k in january to ~410k in march.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Rod Whitworth-3
On Tue, 14 Apr 2009 09:24:09 +0200, Pawe+‚ Le+›niak wrote:

>W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze:
>> They are retarded. mail.charite.de is listed in it.
>>    
>You're definitely not right.
>Testresult for 141.42.4.200:
>
>This IP IS CURRENTLY NOT LISTED in our Database.
>
>B U T, it was listed in the past !
>
>History:
>2008/05/13 08:49    listed
>2008/06/10 09:30    expired
>2008/07/08 09:38    listed
>2008/08/22 11:30    expired
>2009/03/02 17:00    listed
>2009/04/12 13:07    expired
>
>If they send too many bounces, or do SAV, they are listed on
>backscatterer.org. That's simple.
>
>Further - BECAUSE they are sending too many bounces it's quite good to
>stop receiving bounces from them.
>
>Anyways, I've found that backscatterer.org is able to stop large flows
>of backscatter if they happen. When I was getting backscatter from many
>different IPs, backscatterer.org was not helping at all. But that's when
>body_checks work perfectly. As long as I'm a small site with ~10-20k
>SMTP connections daily, I'm fine with this configuration. Also I've
>found that 2 months after starting to use body_checks, the number of
>rejects lowered dramatically from ~15-45k daily to ~10-18k daily. More
>precisely number of rejects lowered from ~850k in january to ~410k in march.
>
>Pawel Lesniak
>

Oh dear, that's all really too much trouble. I have OpenBSD's spamd
running in front of my MTA. A script checks all greylisted entries for
invalid recipients with <> sender and tarpits them.

You cannot have a legitimate bounce going to an invalid sender for
bleedin' obvious reasons. So stick it to 'em.

It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!

*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device


Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Paweł Leśniak
W dniu 2009-04-14 11:56, Rod Whitworth pisze:
> Oh dear, that's all really too much trouble. I have OpenBSD's spamd
> running in front of my MTA. A script checks all greylisted entries for
> invalid recipients with<>  sender and tarpits them.
>    
If mail goes to invalid recipient it can be *rejected*. It's not really
dependent on sender.

> You cannot have a legitimate bounce going to an invalid sender for
> bleedin' obvious reasons. So stick it to 'em.
>    
I hope you mean recipient not sender. Are you sure that null sender is
only used in bounces?

> It wastes resources on all the misconfigured bounce-instead-of-reject
> dummies out there and places no load on my lovely Postfix server. Heh!
>    
Could you explain how? If you greylist those mails instead of rejecting,
you are getting additional SMTP connection(s). If you reject them, they
are discarded. What am I missing?
> Rod/
> /earth: write failed, file system is full
> cp: /earth/creatures: No space left on device
>    
Check your storage.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Rod Whitworth-3
On Tue, 14 Apr 2009 12:27:55 +0200, Pawe+‚ Le+›niak wrote:

>W dniu 2009-04-14 11:56, Rod Whitworth pisze:
>> Oh dear, that's all really too much trouble. I have OpenBSD's spamd
>> running in front of my MTA. A script checks all greylisted entries for
>> invalid recipients with<>  sender and tarpits them.
>>    
>If mail goes to invalid recipient it can be *rejected*. It's not really
>dependent on sender.

Of course, but it is a low cost way of punishing the dills who don't
configure their MX properly.

>
>> You cannot have a legitimate bounce going to an invalid sender for
>> bleedin' obvious reasons. So stick it to 'em.
>>    
>I hope you mean recipient not sender.

It was a forged sender (to the backscatter source) and in our case they
could not have been the true sender because they do not exist as valid
recipients of incoming mail. i.e. they are not our users.

Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.

> Are you sure that null sender is only used in bounces?

What else?

>
>> It wastes resources on all the misconfigured bounce-instead-of-reject
>> dummies out there and places no load on my lovely Postfix server. Heh!
>>    
>Could you explain how? If you greylist those mails instead of rejecting,
>you are getting additional SMTP connection(s). If you reject them, they
>are discarded. What am I missing?

They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)

>> Rod/
>> /earth: write failed, file system is full
>> cp: /earth/creatures: No space left on device
>>    
>Check your storage.

Check the population of /earth for yourself ................... ;-(

*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device


Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Paweł Leśniak
W dniu 2009-04-14 13:54, Rod Whitworth pisze:

Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.
  
I'd imagine somewhat better usage of spam-traps then grey-jail. And if it's "system-wide" - read on.

  
Are you sure that null sender is only used in bounces?
    

What else?
  
- SAV
- Auto-replies   (...)Since in most cases it is not appropriate to respond to
   an automatic response, and the responder is not interested in
   delivery status messages, a MAIL FROM address of <> MAY be used for
   this purpose.(...)  RFC3834
- Any type of automated notifications (...)In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and nondelivery notifications), the
   reverse-path may be null (see section 3.7).(...)  RFC2821

It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!
   
      
Could you explain how? If you greylist those mails instead of rejecting, 
you are getting additional SMTP connection(s). If you reject them, they 
are discarded. What am I missing?
    

They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)
  
IMHO: You are wasting also your resources, and you are slowing down the network. While it's
almost sure the other side will not correct configuration, the prize is smaller than the price.
Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device
   
      
Check your storage.
    

Check the population of /earth for yourself ................... ;-(

  
There's still some room ;-)

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

mouss-4
In reply to this post by Ralf Hildebrandt
Ralf Hildebrandt a écrit :

> * MacShane, Tracy <[hidden email]>:
>
>> Then you won't receive some genuine messages, both bounce and
>> non-bounce.
>>
>> Try the ips.backscatterer.org RBL; it works well for us.
>>
>> http://www.mailinglistarchive.com/postfix-users@.../msg57402.html
>
> They are retarded. mail.charite.de is listed in it.
>

and I guess postfix members would be bothered to block:
        camomile.cloud9.net[168.100.1.3]
        english-breakfast.cloud9.net[168.100.1.7]

$ host 3.1.100.168.ips.backscatterer.org
3.1.100.168.ips.backscatterer.org has address 127.0.0.2
$ host 7.1.100.168.ips.backscatterer.org
7.1.100.168.ips.backscatterer.org has address 127.0.0.2

so if one uses this list, then
- use a whitelist (dnswl and possibly local WL)
- use it in smtpd_data_restrictions to avoid blocking SAV sources. while
you may hate SAV, it's different than backscatter.

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

mouss-4
In reply to this post by Noel Jones-2
Noel Jones a écrit :
> Dennis Carr wrote:
>> Looking at options here for eliminating backscatter.
>> I've reviewed the Howto for this, but it only seems to be effective
>> against backscatter where one's home domain is forged - not too useful,
>> IMNSHO, because spammers aren't always going to forge the home domain.  
>
> and how do you receive it otherwise?
>

I guess he meant they don't forge the Received header.

>[snip]
Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Paweł Leśniak
In reply to this post by mouss-4
W dniu 2009-04-14 23:11, mouss pisze:
Ralf Hildebrandt a écrit :
  
* MacShane, Tracy [hidden email]:

    
Then you won't receive some genuine messages, both bounce and
non-bounce.

Try the ips.backscatterer.org RBL; it works well for us.

http://www.mailinglistarchive.com/postfix-users@.../msg57402.html
      
They are retarded. mail.charite.de is listed in it.

    

and I guess postfix members would be bothered to block:
	camomile.cloud9.net[168.100.1.3]
	english-breakfast.cloud9.net[168.100.1.7]

$ host 3.1.100.168.ips.backscatterer.org
3.1.100.168.ips.backscatterer.org has address 127.0.0.2
$ host 7.1.100.168.ips.backscatterer.org
7.1.100.168.ips.backscatterer.org has address 127.0.0.2

so if one uses this list, then
- use a whitelist (dnswl and possibly local WL)
- use it in smtpd_data_restrictions to avoid blocking SAV sources. while
you may hate SAV, it's different than backscatter.
  
I think that you're missing something.
I'm getting emails from this list as:
[hidden email] -> [hidden email]
Where's the place where emails would be rejected? Is this list doing SAV?
I'd even ask - is ANY list doing SAV? It's hard for me to imagine sending thousands of emails to users who had already confirmed email address during "registration".

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

mouss-4
Paweł Leśniak a écrit :

> W dniu 2009-04-14 23:11, mouss pisze:
>> Ralf Hildebrandt a écrit :
>>  
>>> * MacShane, Tracy <[hidden email]>:
>>>
>>>    
>>>> Then you won't receive some genuine messages, both bounce and
>>>> non-bounce.
>>>>
>>>> Try the ips.backscatterer.org RBL; it works well for us.
>>>>
>>>> http://www.mailinglistarchive.com/postfix-users@.../msg57402.html
>>>>      
>>> They are retarded. mail.charite.de is listed in it.
>>>
>>>    
>>
>> and I guess postfix members would be bothered to block:
>> camomile.cloud9.net[168.100.1.3]
>> english-breakfast.cloud9.net[168.100.1.7]
>>
>> $ host 3.1.100.168.ips.backscatterer.org
>> 3.1.100.168.ips.backscatterer.org has address 127.0.0.2
>> $ host 7.1.100.168.ips.backscatterer.org
>> 7.1.100.168.ips.backscatterer.org has address 127.0.0.2
>>
>> so if one uses this list, then
>> - use a whitelist (dnswl and possibly local WL)
>> - use it in smtpd_data_restrictions to avoid blocking SAV sources. while
>> you may hate SAV, it's different than backscatter.
>>  
> I think that you're missing something.
> I'm getting emails from this list as:
> <owner-**********@********.org> -> <[hidden email]>

it doesn't matter. if you block bounces from the server, you'll block
all bounces, be them legitimate or backscatter.

the problem with backscatterer.org is that we have no idea why IPs are
listed. mixing SAV and backscatter sources is a bad idea. I am not a fan
of SAV, but this is a different problem than backscatter. anyway, let's
not discuss this here as it is off topic. feel free to contact me
offlist if you want.

> Where's the place where emails would be rejected? Is this list doing SAV?
> I'd even ask - is ANY list doing SAV? It's hard for me to imagine
> sending thousands of emails to users who had already confirmed email
> address during "registration".

unfortunately, there are a few issues:
- membership validation is done by the list manager software, at
delivery time, long after the "first" relay has accepted the message.
- most list managers use the From: header to validate membership

sure, the list of valid members may be exported to be used by the relay,
but it's not how things are done, and MLMs don't make it easy (the only
free one I know of that makes this easy is "sympa").
Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

Noel Jones-2
In reply to this post by Paweł Leśniak
Paweł Leśniak wrote:
> I'd even ask - is ANY list doing SAV? It's hard for me to imagine
> sending thousands of emails to users who had already confirmed email
> address during "registration".

Some lists accept posts from un sub scribed senders.  Some of
those lists do SAV.   Some of the sourceforge lists fall in
this category.  And yes, they probe registered senders too.
If you want to play with them, you need to accept their probes.

   -- Noel Jones



Reply | Threaded
Open this post in threaded view
|

RE: A better backscatter killer?

MacShane, Tracy
In reply to this post by mouss-4
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of mouss
> Sent: Wednesday, 15 April 2009 7:11 AM
> To: [hidden email]
> Subject: Re: A better backscatter killer?
>
> Ralf Hildebrandt a écrit :
> > * MacShane, Tracy <[hidden email]>:
> >
> >> Then you won't receive some genuine messages, both bounce and
> >> non-bounce.
> >>
> >> Try the ips.backscatterer.org RBL; it works well for us.
> >>
> >>
> http://www.mailinglistarchive.com/postfix-users@.../msg57402.
> >> html
> >
> > They are retarded. mail.charite.de is listed in it.
> >
>
> and I guess postfix members would be bothered to block:
> camomile.cloud9.net[168.100.1.3]
> english-breakfast.cloud9.net[168.100.1.7]
>
> $ host 3.1.100.168.ips.backscatterer.org
> 3.1.100.168.ips.backscatterer.org has address 127.0.0.2 $
> host 7.1.100.168.ips.backscatterer.org
> 7.1.100.168.ips.backscatterer.org has address 127.0.0.2
>
> so if one uses this list, then
> - use a whitelist (dnswl and possibly local WL)
> - use it in smtpd_data_restrictions to avoid blocking SAV
> sources. while you may hate SAV, it's different than backscatter.
>
>

I do whitelist one of our backscatterers, since it's our Defence department. As it happens, it seems all of the backscatter I've trapped from them *is* backscatter, because they're bounces to non-existent addresses or evident spam messages. But I accept it all from them just in case. And yes, my restriction is in smtpd_data_restrictions, as shown in the original message I linked to.

Frankly, I'm not that fussed about blocking potential bounces from list mail. Also, if I were running an ISP rather than a corporate email system, I probably wouldn't use this RBL. I do wish there were a slightly less problematic one - ie. one that would respond promptly to requests for removal without gouging 50 euro, and which didn't care so much about SAV - but I don't think it's *that* problematic.

Our main source of spam that was getting through our header checks was from backscatter, and since I've instituted the RBL, it has entirely gone. Only a couple of hundred or so messages a day currently, but it makes a difference to our end-users, some of whom were disproportionally affected by the problem (we have a tag-and-forward content scanner, and some of these individuals were having to review and discard hundreds of messages a week).
Reply | Threaded
Open this post in threaded view
|

Now OT. Terminating thread (was Re: A better backscatter killer?)

Rod Whitworth-3
In reply to this post by Paweł Leśniak
--Original Message Text---
From: Pawe+‚ Le+›niak
Date: Tue, 14 Apr 2009 14:50:57 +0200
8>< snip---------
I don't like top-posting but......
Due to your message formatting it is not possible for someone to easily see who said what in your reply. So simply for the benefit of others who may have had a passing interest, I'll make closing comments.

All talk about RFCs in your message is irrelevant because messages from the null sender addressed to a fictitious recipient will NEVER be delivered anyway. RFC3834 is NOT a standard BTW, and we should hope it never is as it contemplates things like sending virus notifications. Echhhk!

So we trapit <> to invalid addresses and reading the logs shows that the probability of those messages being bounces from servers configured by amateurs is something like .999977.

You have no idea how little load this places on our firewall. It is not even measurable when there is a spambot storm in progress. It does not consume any Postfix resources. It also seems that the tarpitting we do on other spammy senders is noticed by some of them as the number of trapped IPs at any instant is now about a quarter of what it was a year ago.

We don't slow down our network by tarpitting. The sender gets 1 char/ 4 seconds and typically gives up after about 1500 seconds with the settings I use.

For more info see http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

And that's all folks! Back to lurking for me.
-----


W dniu 2009-04-14 13:54, Rod Whitworth pisze:

Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.

I'd imagine somewhat better usage of spam-traps then grey-jail. And if it's "system-wide" - read on.
Are you sure that null sender is only used in bounces?

What else?

- SAV
- Auto-replies- -  (...)Since in most cases it is not appropriate to respond to
- -  an automatic response, and the responder is not interested in
- -  delivery status messages, a MAIL FROM address of <> MAY be used for
- -  this purpose.(...)-  RFC3834
- Any type of automated notifications (...)In some types of
- -  reporting messages for which a reply is likely to cause a mail loop
- -  (for example, mail delivery and nondelivery notifications), the
- -  reverse-path may be null (see section 3.7).(...)-  RFC2821

It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!

Could you explain how? If you greylist those mails instead of rejecting,
you are getting additional SMTP connection(s). If you reject them, they
are discarded. What am I missing?

They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)

IMHO: You are wasting also your resources, and you are slowing down the network. While it's almost sure the other side will not correct configuration, the prize is smaller than the price.
Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device


Check your storage.


Check the population of /earth for yourself ................... ;-(


There's still some room ;-)
Not enough for all the irresponsible breeders.

Pawel Lesniak



*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device
Reply | Threaded
Open this post in threaded view
|

Re: Now OT. Terminating thread (was Re: A better backscatter killer?)

Paweł Leśniak
W dniu 2009-04-15 04:21, Rod Whitworth pisze:
> --Original Message Text---
> *From:* Pawe+‚ Le+›niak
> *Date:* Tue, 14 Apr 2009 14:50:57 +0200
> 8>< snip---------
> I don't like top-posting but......
> Due to your message formatting it is not possible for someone to
> easily see who said what in your reply. So simply for the benefit of
> others who may have had a passing interest, I'll make closing comments.
Talking about formatting - try to use somewhat newer client, with good
message formatting. I have no problem to follow the thread.
> All talk about RFCs in your message is irrelevant because messages
> from the null sender addressed to a fictitious recipient will NEVER be
> delivered anyway. RFC3834 is NOT a standard BTW, and we should hope it
> never is as it contemplates things like sending virus notifications.
> Echhhk!
>
Have a look at http://www.postfix.org/bounce.8.html. Specially part
STANDARDS. So it looks like RFC3834 IS a standard indeed.
> So we trapit <> to invalid addresses and reading the logs shows that
> the probability of those messages being bounces from servers
> configured by amateurs is something like .999977.
>
You can do whatever you want. But do not enforce others to break RFCs.
Talking about amateurs ... I do agree with that. But you won't do any
good by messing. It would give better effect if you'd report them to
some RBLs. If they get blacklisted with zen, they'll have to think over
their configuration.

> You have no idea how little load this places on our firewall. It is
> not even measurable when there is a spambot storm in progress. It does
> not consume any Postfix resources. It also seems that the tarpitting
> we do on other spammy senders is noticed by some of them as the number
> of trapped IPs at any instant is now about a quarter of what it was a
> year ago.
>
> We don't slow down our network by tarpitting. The sender gets 1 char/
> 4 seconds and typically gives up after about 1500 seconds with the
> settings I use.
>
I did not mean your network. If there were many sites like your, it
would be simple to fill up network attacked by few spambots. Have you
ever thought that some sites share network connection?

Of course it gives up after first limit (client or server side) occurs.
So it can be 300 seconds when sender stops (5 minutes limit is proposed
in standard), or any other limit configured at the other side.
> For more info see
> http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
>
> And that's all folks! Back to lurking for me.
>
One more thing... you forgot to comment the part about what kind of
emails can be sent with null sender address.
- SAV
- Auto-replies- -  (...)Since in most cases it is not appropriate to
respond to
   an automatic response, and the responder is not interested in
   delivery status messages, a MAIL FROM address of <> MAY be used for
    this purpose.(...)-  RFC3834
- Any type of automated notifications (...)In some types of
    reporting messages for which a reply is likely to cause a mail loop
    (for example, mail delivery and nondelivery notifications), the
    reverse-path may be null (see section 3.7).(...)-  RFC2821

Still - you can do whatever you want.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: A better backscatter killer?

kj-12
In reply to this post by dennisthetiger
Dennis Carr wrote:

> Looking at options here for eliminating backscatter.  
>
> I've reviewed the Howto for this, but it only seems to be effective
> against backscatter where one's home domain is forged - not too useful,
> IMNSHO, because spammers aren't always going to forge the home domain.  
>
> One thing I've been looking at doing is basically checking headers, and
> if the From: header is null, then reject it immediately.
>
> Other approach is to eliminate my 2ary MX from DNS - most of my spam
> comes from that.  I don't really want to do that, though, because the
> idea of a 2ary MX is for a fallback.
Do recipient verification on your secondary MX.

Or even better, don't use a secondary MX.  Real servers sending to you,
will try again. If you expect to have more than four odd days at a time,
you have bigger things to worry about anyway.


--kj