[Mailman-Users] Spam to list-owner

[Lindsay Haisley]

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