[Mailman-Users] Spam to list-owner

[Lindsay Haisley]

On Sat, 2008-12-20 at 14:49 +0900, Stephen J. Turnbull wrote:
> Lindsay Haisley writes:
> 
>  > So if I can't refuse potential spam at the SMTP front door, what
>  > difference does it make whether it gets detected in Mailman or the MTA?
> 
> None.  But one still wonders why anybody would consider *running
> SpamAssassin* anywhere but in the MTA (or in the pipe to the delivery
> agent, if milters aren't supported as is apparently true for Courier)
> an advantage.

Courier doesn't need milters.  Maildrop can be run in what's called
"embedded mode" which is effectively the same thing.  I chose to accept
spam (the 20% or so that makes it past RBL filtering) onto the system
and give users the option to mark it and segregate it according to their
preferences.  Courier could easily be configured to keep reject
identified spam in SMTP, but as it is, people are more comfortable
having the option to examine it and adjust their filtering levels
accordingly.

This is beside the issue, since I have SA and RBL filtering working
well, and exactly the way I want them to, for user mailboxes.  I may
need to do some work to get filtering for lists to work as I want them
to.

>  > What I'd really like is a way to hook SpamAssassin, or a similarly
>  > effective tool, into Mailman
> 
> You can do that with Henstridge's code, but IMO it's an ugly kludge
> compared to running SpamAssassin early and configuring it to report
> special features for use by the SpamDetect Handler in Mailman, etc.
> They could be given default scores of 0.0 if they can't reliably be
> used for scoring except for certain addressees, but they'd still be
> reported if their rules are triggered.

This is an iteresting idea.  I'm not real happy with Henstridge's
solution so I'll give this some thought.

> In your case you'd be running it in maildrop, which presumably means
> you know which addressee(s) is (are) being delivered.  It should be
> possible to give that information to SpamAssassin (SpamAssassin knows
> on which user's behalf it's being run, although I forget the details)
> and configure rules conditional on that information.

I'm doing pretty much exactly this already for user mailboxes.  Lists
are a slightly different matter, for reasons explained elsewhere.

>   I don't see why
> this would be enormously harder than than if SpamAssassin were running
> in Mailman, and it would have the advantage that rule dispatch would

Because I'm feeding Mailman through the forwarding/redirection system in
courier (rather than the delivery agent), mail to lists isn't subject to
SA filtering.  This is by choice, for a variety of reasons.  So if I
want to use SA with Mailman I either have to configure it to run as per
something like Henstridge's code, or I have to re-introduce SA filtering
on a per-domain level for lists in the MTA.  There may be some good
reasons to do this, the main one being that Henstridge's code is
apparently unmaintained and currently broken as posted on his website.

I gotta go fix some supper for my lady and I before I get into trouble.
Thanks for an interesting discussion.

-- 
Lindsay Haisley       |"Fighting against human |     PGP public key
FMP Computer Services |   creativity is like   |      available at
512-259-1190          |   trying to eradicate  |<http://pubkeys.fmp.com>
http://www.fmp.com    |       dandelions"      |
                      |     (Pamela Jones)     |