[Mailman-Developers] New SpamAssassin handler on sf.

[Jeff Warnica]

On Mon, 2003-11-17 at 20:17, J C Lawrence wrote:
> On Mon, 17 Nov 2003 19:22:22 -0400 
> Jeff Warnica <jeffw at chebucto.ns.ca> wrote:
> > Uh, because ISPs cant be deleting mail, ever? 
> Actually they can and do, constantly, now, today and for many
> yesterdays.

The default score for SA to decalre something as Spam is 5. Personaly I
dont _ever_ check my spam folder which gets things in it based on that
default, though I only ever do a puge by hand... 5 is a very low number
to use for automaticly silently deleting mail however. At the ISP level,
we delete mail silently for messages with a score above 15 (usualy),
unless there seems to be a spam storm, in which case that is lowered to
10, but never below that for silent deletion. I dont monitor the tech
support people too carefully, so I dont have a handle on how many people
have chosen the 'delete' vs 'drop in different folder' filter options we
have. But there is a non-zero value of paranoid people who would be very
unhappy if we started deleting mail that moderatly scored.

> > Tag everything and leave it up to something else to deal
> > with. 
> This is quite possible with SpamAssassin installed at the MTA level.

"Something else", in the case of my patch, is my patch :) And the same
logic applies; mail above a very high score is silently deleted, mail
above some other score (5 by default) is held for moderation, <5 passes
through. While I dont personaly (ever) check my spam folder, if I was
moderating a list I would be checking things flaged as spam, especially
if it is ie. a tech support list where people would be sending in
reports of mail taged as spam for analysis by live people. Idealy
whatever patch becomes the standard should be updated to allow per-list
filtering options. Some moderators may be willing to live with
silent-deletion on what other moderators consiter a very low score. But
the generic patch is better then nothing; I dont think there would be a
significant burden on the core Mailman developers to update it with any
internal changes to Mailman.

> or whatever.  Additionally there are side-benefits from scanning all
> mail, or at least scanning at a layer higher in the protocol stack: it
> requires less customisation, grants greater overview of cross-spool mail
> behaviours (esp statistical), and is less invasive to the mail system in
> general (not every tool then needs to be SpamAssassin or other-scanner
> aware).

Yes, there is a definite advantage to having scanning done in one place;
my patch/plugin deals with pre-taged mail. But I dont want to leave it
up to the scanner to delete mail (well, it deletes very high scored
mail..). Deleting moderatly scored mail is up to something else.
Something else being..... Mailman! Or at least a list moderator using
Mailman.