> -----Original Message-----
> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 12:51 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
>
> Joey wrote, at 10/13/2008 11:57 AM:
>
> > For us greylisting was a problem because it put a big delay on email when
> you were sitting waiting for a message from someone you were talking to, but
> that catches A LOT of email.
>
> Consider Nolisting. It doesn't have the delay associated with
> greylisting, and will turn away the first wave of connections from spambots:
>
> http://nolisting.org
>
> If your concern is reducing load on your server, this will help decrease
> obviously spammy connections without introducing much overhead at all.
>
> > Basically you take a list of IP blocks by country or manual lists like so:
> > 91.124.0.0/9
> > 92.113.0.0/9
> > 92.112.0.0/9
> > 83.110.0.0/9
> > 217.132.0.0/9
> > 71.0.0.0/8
> >
> > These above connected to my server over the past 24 hours about 4K times.
> > You feed these into iptables like so
> > iptables -A INPUT -s 91.124.0.0/9 -p tcp -j LOG --log-prefix "SPAM-BLOCK-
> CIDR-LIST_NAME_HERE"
> > iptables -A INPUT -s 91.124.0.0/9 -p tcp -m tcp --dport 25 -j DROP
> >
> > you can then tail /var/log/messages and see how many times you get SPAM-
> BLOCK working.
> >
> > I wrote a script to tail messages and count the amount of times "SPAM-BLOCK"
> entry shows up.
> > When I run that script I get the original line from messages along with the
> first part of the line which shows:
> > [RunTime:20 seconds]--[Spam:242]--[MsgHour:43560.00]-- Original Message here
> >
> > That's how I know the numbers I represented in my email.
> >
> > Here is an example of an additional line which is generated by a similar
> application tailing maillog:
> > -----------------[MsgHour:4947.95]------------------------------[
> TMsg:6644]---[GMsg:227 3%]---[TSpam:6416 97%]-----[RunTime:1 hour, 20 minutes
> and 34 seconds]-------
> >
> >
> > While I did check that I was getting spam from these sources in some cases,
> I went blindly to those top spam countries. My clients are good about letting
> me know when they aren’t getting email.
>
> It's no surprise to anyone here that the overwhelming number of delivery
> attempts are spam. As a result, it's easy to fool yourself into thinking
> you're making a dent against spam when you're actually exposing ham to
> increased risk. I can tell you from experience that outright blocking of
> countries is a Bad Thing. It's unsustainable and will eventually come
> back to bite you.
>
> This doesn't mean that all networks are the same. When I developed
> Unlisting, I discovered it was too aggressive for general use. But I
> have been using Selective Unlisting with some success, targeting
> networks with bad reputations, while allowing most of the legitimate
> mail through. If you try Nolisting and are happy with the results,
> consider implementing Selective Unlisting (but be warned that the
> configuration is far more complex and must be implemented with care):
>
> http://unlisting.org
> http://unlisting.org/selective.html
>
> Selective Unlisting relies on the ipt_recent module, and requires that
> the first MX always rejects, and the second MX only accepts connections
> if the first has been tried:
>
> iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.3 --dport 25 -m
> recent --set --name UNLIST -j REJECT --reject-with tcp-reset
> iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -m
> recent --rcheck --name UNLIST --seconds 4000 -j ACCEPT
> iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -j
> REJECT --reject-with tcp-reset
>
> In this example, 10.0.0.0/16 is the suspect network, 192.168.1.3 is the
> primary (nonfunctioning) MX, and 92.168.1.4 is the secondary
> (functioning) MX. This is most easily set up on a single machine, but it
> can also be configured on a transparent filtering bridge. You can target
> as many networks as you like. But read the documentation carefully and
> understand the caveats. And definitely try Nolisting first, along with
> other techniques that are lightweight and safer than country blocks.
>
I already do nolisting which I have no way to measure how much that does for me.
In respect to the unlisting example, my issue is in some cases we have the
nolist IP on a different box than the
True MX so knowing we attempted connection at the primary before talking to the
secondary is probably a bit too complicated.
I agree that these methods are AGGRESSIVE, NO question, but if I'm getting no
complaints from clients how can I not continue to utilize this method given
that there aren't a whole lot of things that can be done.
People have told me over time that I am too aggressive with the RBL's I use,
but it has been successful with almost no FP.
My list:
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client psbl.surriel.com,
reject_rbl_client ix.dnsbl.manitu.net,
You reach a point where the money we think we are profiting from services sucks
up all our time and resources and somehow we have to reduce that overhead and
SPAM.
Imagine that we are blocking millions of spam messages a month through various
methods and we have clients complaining about spam... what are we to do. It
gets really old.
