On Sat, 2008-12-20 at 13:54 +0900, Stephen J. Turnbull wrote: > Brad Knowles writes: > > Lindsay Haisley wrote: > > > > The problem with this is that no spam detection method is 100% > > > effective, and with SpamAssassin there's some overlap between setting > > > the rejection level low enough to be effective and getting false > > > positive identification of spam. > > You're missing the point. If you're going to run SpamAssassin or > anything else that is able to tag messages as well as simply reject/ > quarantine/accept them, it's really a good idea to do it for *all* > messages.
The devil is in the details here. I explicitly exempt email destined for forwarding/redirection from examination by SpamAssassin. I do this for two reasons. 1. User-settable options for SpamAssassin enable the segregation of identified spam into separate mailboxes, accessible via IMAP. Forwarded email has on mailboxes on the system so this can't be done, and I make the assumption that if people are setting up mail forwarding directives for their accounts then filtration for spam will be done on the system that actually accepts the mail for delivery. After the RBL filter in courier rejects about 80% of the incoming spam, redirected email is simply sent on to the receiving system, spam or no. It ain't FMP's responsibility! I don't run a spam filtering service. I love my CPU cycles :-) 2. The minimum class of email service FMP offers is mail forwarding only, no mailboxes, and hence no spam filtering other than front door RBL filtering. People get what they pay for. Mailman, and mailing lists at FMP just happen to work using the redirection/forwarding mechanism in courier, so Mailman doesn't benefit at all from SpamAssassin in the MTA, and must handle filtering in some other way. I really don't see a problem here. I just wish that SpamAssassin could be integrated more flexibly into Mailman. > You can run SpamAssassin in the MTA, reject some of the > spam there based on fairly complex (and therefore precise) formulae, > and then do further filtering later based on the tags that > SpamAssassin will insert for you as headers. Arrgh! This feels ugly, or at least un-elegant. There's no such thing as "precise formulae" when it comes to SpamAssassin, so this is difficult. And consider this problem: An email comes in to user A and user B - two recipients, two RCPT TO exchanges in the SMTP dialog. The MTA doesn't know what's in the message yet, but let's say it says "250 Ok." for both recipients. Then follows the DATA exchange and the message body is sent. And let's say SpamAssassin looks at the message body and determines that, based on the body content, the email is spam according to user A's settings in the SA database, but isn't spam according to user B's settings. What is the MTA to do? It has already passed the point of no return in accepting the recipients, and the only choice it has is to reject the email for both or reject it for neither. At this point it can't issue a split decision and return a reply consistent with RFCs. > > > This solution isn't perfect, but it does help cut down on complaints > > > from list owners about too much moderator spam. > > If it's not going to get to the moderators/owners, there's no good > reason not to reject at the MTA stage, using a milter to do so before > accepting delivery, and so reducing spammer deliverability scores. > (It's not just your host you're protecting when you do this; you're > undermining the whole spammer enterprise! Fight back -- you may not > have a snowball's chance (etc) of winning, but you'll feel good!) For years I reported every spam I got to my personal account - looked up the serving systems, or the systems hosting contact websites, and sent bucu letters to sysadmins all over the world. This was effective when a good portion of spam came from the US, and I know I got a lot of spammers' resources knocked offline. I found out later that my email address was on at least one undercover do-not-spam list used by some spammers. So I've done my time in the trenches, and at this point it's a no-nevermind to me whether I refuse a spam at the SMTP level or dump it in the cosmic bit bucket at a later stage. > Here's Brad: > > > There's nothing you can do with SpamAssassin integrated into Mailman that > > you couldn't do with SpamAssassin integrated into the MTA, > > Not entirely true. Many installations refuse to permit per-user rules. > (If you run SA yourself, you can specify the config file, and therefore > your own rules.) All FMP customers who have mailboxes on the system can set the SpamAssasin level at which mail will be identified as spam, what the tag in the subject line is identifying spam, and whether or not to segregate said spam into a separate IMAP folder. They can furthermore provide both a whitelist and a blacklist of addresses. So customers can't exactly write their own SA rules, but they have some control over the system. > If we let Brad be Brad :-), he'll probably reply that in his book that's > a firing offense and you should be shopping for a new host. But YMMV. > > > The only thing that implementing anti-spam rules in Mailman would get you > > (beyond the anti-spam features that Mailman has today), is if the > anti-spam > > processing system that was integrated was *different* from the one that > was > > integrated into your MTA, > > But if that buys *you* something, why not share the costs and benefits > with all users on that system? I don't think this is actually a > reason to do it at the Mailman level, *unless* you've got host-level > constraints. Putting SA processing into Mailman allows one to differentiate between moderator messages, subscriber messages, list control messages, etc. and handle them differently with regard to spam. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
