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