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. 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. > > 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!) 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.) 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. Any spam analysis (other than human moderation) done at the Mailman level should be considered a thumb-in-dike technology, to be replaced with analysis and (at least some) filtering at the MTA level, with filtering at post-MTA levels to be moved to the MTA level as soon as accurate discrimination is possible. (Obviously this "ASAP" recommendation depends on admin talent and time availability, but note that a lot of it is done simply by upgrading your filters' rule databases regularly.) ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org 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
