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. > 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. > so that I can get a lot more fine-grained control and set > meaningful parameters on a per-list basis. The further forward I > shove it, the harder it is to exercise this kind of control. 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 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 be configured in one place. ------------------------------------------------------ Mailman-Users mailing list [email protected] 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
