[Mailman-Users] Spam to list-owner

[Stephen J. Turnbull]

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.)