[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Benjamin A'Lee wrote: > > I found Simon's Postfix Greylisting howto very useful. > > http://www.debian-administration.org/articles/168 Simon's blog says; http://www.debian-administration.org/users/simonw/weblog/44 It is now getting to be significant amount per user per day (circa 10 spam a day from retrying bots for me, okay I have a lot of email addresses at work that are spammed to death without these kind of defences so ten or so spam a day is not that bad a result, but effectiveness of the approach is falling fast. The philosophy behind the approach is worth understanding. 1) Block early. Block suspected spam and viruses before the SMTP transaction is complete. This way you don't generate spurious DSNs (delivery status notifications), but should you generate a false positive the sender is notified their email failed promptly. 2) Minimize content filtering. Content filtering is a very powerful way of filtering spam, but it is also inherently error prone. It is error prone because it is not (only?) the content, but the unsolicited AND bulk nature of spam that makes it unwanted. Content filtering typically can't identify mail that is sent in bulk, you don't want to reject all bulk email (DCGLUG), and you don't want to block all unsolicited emails as you'd never make new friends that way. Similarly as discussed before content filtering has a high risk of false positives, as it generates an arms race. 3) Self help We struggle to minimize false positives, but also we want a system where if it does trigger a false positive the sender can do something about it without bothering us. This is important both practically, and psychologically, as well as reducing the recipient admins workload. Practically you get email you should. Psychologically, those you block feel there is something they can do to correct the situation, rather than just feeling rejected. The SBL-XBL black list offers a self remove behind CAPTCHAs. The frustration with systems like AOLs is the errors are incomplete, and when I eventually tracked down what was triggering the "Redirecting HTTP" filter recently, it turned out to be a vital part of the message (content filtering again). So we want to focus on the type of systems that send bulk and unsolicited emails. Hence the focus on blacklists (reputation -- this is a known bad client), and greylisting (does it behave like a genuine email server). One warning, don't get carried away with block lists, the SBL-XBL black list consists of a selection of different types of list, built from different criteria put together in a considered fashion. As soon as you start combining blacklists, you must realise that where they overlap you gain no benefits in spam protection, where as typically they will all have fairly different set of sites that shouldn't have been included. Anyway there is no excuse for rejecting genuine email when playing with Postfix see: warn_if_reject http://www.postfix.org/uce.html#warn_if_reject soft_bounce http://www.postfix.org/postconf.5.html#soft_bounce Beware with soft_bounce, you don't for example want to leave it enabled, and discover that there are 10,000's of genuine emails retrying every few seconds reducing your email server to a crawl. I usually reject where the senders domain doesn't exist, but make sure this doesn't trap your own administrative emails first. I'm looking at HELO/EHLO restrictions in Postfix (note that like senders domains not existing it is technically an RFC infringement to reject email on this basis). But where present the HELO argument should be unique, so "localhost", your IP address, and your domain name are off limits for others. But I haven't deployed anything in anger yet. What I want is a mail system so "self aware" that it learns to recognise traffic patterns, senders (even when they use different email addresses), topics of correspondence, and thus can effectively spot what isn't spam. Probably the closest to that so far is to run Bayesian filtering as a milter, but the Bayesian stuff places a tad too much emphasis on content (which can be fooled, any spam mentioning "GNU", "Linux" or in one case "thyrotropin" got by the Bayesian filters I have tried), rather than context. Such a system should use a C/R built into the SMTP rejection mechanism for self help purposes -- but C/R is a dirty word in spam filtering circles. I haven't tried out the distributed checksum stuff, which sounds sensible (content filtering is acceptable if you know it is bulk as well), but I assume it is trivially defeated by the spambots. SPF was fashionable, but seems to be dying, few people were ever prepared to absolutely reject on the basis of a failure. Whilst lots of people were prepared to advertise an SPF record. However it definitely fits my criteria for a useful test, and I may look at it again. - The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html