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.
