Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Seems that I opened some old wounds of religious arguments on whose MTA is better than whose...that was not my intention, my apologies to those whose favorite mail server software was slighted. Rather, my intention was to prompt those who know more than I about this topic to post critiques and suggestions on whether/how to implement various spam-control techniques. Derek suggested: > Of course, if you're wrong, then you're potentially negatively > impacting the service of the sender ...These delays probably don't > impact spammers too significantly The techniques that I used take advantage of the inherent desire for anonymity that spammers have. Misconfigured mailers deserve to be delayed a bit. Properly configured mailers won't see any delay at all until the last step of my checks, the greylist. And if a mere several hundred recipients did the same thing that I (and those who have read exim spam-control articles online) have, the impact on spammers adds up quickly. He then suggested: > The conservative RBLs suck. Perhaps we're using the word "conservative" in opposite sense. What I did was look through my hundreds of thousands of archived spam messages, along with my legitimate messages, to see how spamassassin had tagged them over the past couple of years. The "conservative" RBLs were those which didn't register any false-positives that I could find. Spamhaus.org, for example, with the return-value of 127.0.0.2. Question on this topic: what configuration options (for the benefit of those who run sendmail and postfix) are needed to do an RBL check prior to the message DATA directive? In exim, you put these directives into the rcpt-to ACL: drop (<- or deny) message = Your email server $sender_host_address is listed \ at $dnslist_domain: POLICY_MSG log_message = [RR18] listed at $dnslist_domain dnslists = sbl-xbl.spamhaus.org=127.0.0.2 : \ ... delay = 40s I defined my POLICY_MSG macro to give instructions to anyone who might have gotten a false-positive, and a URL reference for more info on reaching me. The nice thing about this is that a rejection causes less collateral spam (misdirected bounce messages) than a bounce. If your filtering technique waits until after the message data is accepted, you have to either circular-file the spam or send a bounce message. If you circular-file it, you might miss valid messages amid the sea of junk (and that's what I've endured for years). If you bounce it, you're probably going to wind up on an RBL list yourself quickly, among other problems. This technique provides feedback to the correspondent without those issues. > You've already said you don't mind occasionally losing legitimate > mail to save yourself from spam Sometimes your commentary here is unnecessarily combative. That is not what I said. I said: "I just had to assume that an occasional important message would get dev-nulled". This is not something I, or anyone else installing spam-control software, wanted to have happen. Rather than argue about this, let's devote our mutual efforts toward educating the lurkers on the BLU list about what the most useful features of <name your favorite MTA> are. For example, instead of declaring (accurately, I'll concede) that my old sendmail configuration was inadequate--post a specific suggestion on a helpful addition to that configuration for anyone else who might be wondering how to restrict outsiders from accessing a mailbox like "backup-reports at site.name", or from sending to more than 3 invalid-recipients per hour? Tom Metro gave some good clarifying comments about greylisting, which is not one of those annoying challenge/response agents which requires the correspondent to confirm an email to get on a whitelist. (I agree with Derek on those, people who require me to respond to one of those are less likely to hear from me by email again!) He says this: > The real problem with grey-listing is that it teaches spammers that > sending more spam (iterating over their mailing list multiple times) Without a doubt, spammers will eventually regain the upper hand over any software configuration that I install on my system. What exim, and the techniques that I have now learned, does is give me the upper hand in a much bigger way than spamassassin did when I first installed it 2 years ago. I have greater confidence that my next overhaul will be more than 2 years from now. The specific response that a spammer must take to get around grey-listing is more complex and nuanced than simply repeat-sending to a big mailing list. For example, I also do a Razor2 check prior to my grey-list check. If their first attempt to send a message reached me early (before Razor2 recorded their message contents), then repeating it an hour later will likely trigger the Razor2 check because many others will have gotten the message by then. But yeah, some spammer will figure out some way to stay out of the Razor2 system--I'll have to adapt to whatever solution they find. My hope is that my email address will get pruned out of many of the spammers' lists because they know my machine causes transmission delays. It's sort of like putting a cheap lock on your cheap bicycle. If the bike isn't all that worthwhile, it won't get stolen if the other bikes parked next to it are nicer or are left unlocked. Most people's email boxes are essentially still unlocked. If we want to do a BLU meeting on message-transfer agents: I'll contribute to the forum. -rich
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |