New SpamAssassin handler on sf.
ID 840426
This is different from the 'other' SA handler as it deals with pre-taged messages. IMHO this is far more likely to be the case in an ISP enviroment. The general concensious on my MTA's mailing list being that all mail should be tagged, flagged, and passed on leaving it up to 'something else' to decide what to do with spam (user agents could drop, or filter it, Mailman qualifies as a UA in this scheme :)
The MailScanner install here might be using non-standard headers, but it shouldnt be too hard to figgure out what to change.. Thinking about it now I shold have put the header name and get-the-score RE as options, but oh well.
On Tue, Nov 11, 2003 at 10:07:52PM -0400, Jeff Warnica wrote:
ID 840426
This is different from the 'other' SA handler as it deals with pre-taged messages. IMHO this is far more likely to be the case in an ISP enviroment. ...
Concerning: http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=840426
I noticed there are currently 3 patches concerning SpamAssassin integration with Mailman: 534577 Add SpamAssassin filter to mail pipeline jhenstridge 2002-03-25 Open 640518 SpamAssassin handler jparise 2002-11-18 Open 840426 SpamAssassin handler for pre-tagged mail jeffwarnica 2003-11-11 Open
I constructed a similar handler for SpamAssassin which can be used both for systems that pre-tag the messages and for systems that want to use python's to tag the message using spamd/spamc.
It's behavioure can be controlled by the mm_cfg parameter SPAMASSASSIN_USE_HEADERS. It parsers both the score and the symbols (tests) from the SpamAssassin-header.
It's based on http://www.daa.com.au/~james/articles/mailman-spamassassin/ and should be able to handle both kinds of mailman/spamassassin integration.
My version of the patch can be found at
http://gewis.nl/~pieterb/python/SpamAssassin.py.txt
It would be great if a SpamAssassin.py will be integrated in Mailman 2.1.4! Can anybody commit this SpamAssassin.py and James his spamd.py to the Mailman CVS?
Feedback is welcome, Regards,
Pieter (pieterb@sf.net)
-- You will remember that you forgot to take out the trash when the garbage truck is two doors away.
I am definitly prepared to burn the field, plow salt into it, and claim that my creation never existed if this SA module, which from its description sounds like it does what I want, becomes a standard module.. But there definitly should be one of them included as standard.
On Sun, 2003-11-16 at 12:02, PieterB wrote:
On Tue, Nov 11, 2003 at 10:07:52PM -0400, Jeff Warnica wrote:
ID 840426
This is different from the 'other' SA handler as it deals with pre-taged messages. IMHO this is far more likely to be the case in an ISP enviroment. ...
Concerning: http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=840426
I noticed there are currently 3 patches concerning SpamAssassin integration with Mailman: 534577 Add SpamAssassin filter to mail pipeline jhenstridge 2002-03-25 Open 640518 SpamAssassin handler jparise 2002-11-18 Open 840426 SpamAssassin handler for pre-tagged mail jeffwarnica 2003-11-11 Open
I constructed a similar handler for SpamAssassin which can be used both for systems that pre-tag the messages and for systems that want to use python's to tag the message using spamd/spamc.
It's behavioure can be controlled by the mm_cfg parameter SPAMASSASSIN_USE_HEADERS. It parsers both the score and the symbols (tests) from the SpamAssassin-header.
It's based on http://www.daa.com.au/~james/articles/mailman-spamassassin/ and should be able to handle both kinds of mailman/spamassassin integration.
My version of the patch can be found at
http://gewis.nl/~pieterb/python/SpamAssassin.py.txt
It would be great if a SpamAssassin.py will be integrated in Mailman 2.1.4! Can anybody commit this SpamAssassin.py and James his spamd.py to the Mailman CVS?
Feedback is welcome, Regards,
Pieter (pieterb@sf.net)
On Mon, Nov 17, 2003 at 01:09:30PM -0400, Jeff Warnica wrote:
I am definitly prepared to burn the field, plow salt into it, and claim that my creation never existed if this SA module, which from its description sounds like it does what I want, becomes a standard module.. But there definitly should be one of them included as standard.
I agree with Jeff. I don't plan on maintaining my SpamAssassin patch passed its current incarnation. I welcome a standard implementation.
-- Jon Parise (jon@csh.rit.edu) :: http://www.csh.rit.edu/~jon/
On Monday, November 17, 2003, at 07:49 pm, Jon Parise wrote:
On Mon, Nov 17, 2003 at 01:09:30PM -0400, Jeff Warnica wrote:
I am definitly prepared to burn the field, plow salt into it, and claim that my creation never existed if this SA module, which from its description sounds like it does what I want, becomes a standard module.. But there definitly should be one of them included as standard.
I agree with Jeff. I don't plan on maintaining my SpamAssassin patch passed its current incarnation. I welcome a standard implementation.
Might I ask why enthusiasts for integration SpamAssassin with Mailman do not care about delivery of spam to other mail aliases in their domain. And if they do so care, why do they not concentrate on stopping spam reaching all of their mail aliases.
I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
Or did I miss something important along the way.
-- Jon Parise (jon@csh.rit.edu) :: http://www.csh.rit.edu/~jon/
Uh, because ISPs cant be deleting mail, ever? Or at least deleting messages with an extreemly high score. Tag everything and leave it up to something else to deal with. Something else being procmail, seive, mailman, or the end user agent. Even if you want resonably scored spam not to reach Mailman by silently deleting it, it would be more trouble to scan everything except that destin for Mailman then to just scan everything.
On Mon, 2003-11-17 at 18:52, Richard Barrett wrote:
I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
On Monday, November 17, 2003, at 02:52 PM, Richard Barrett wrote:
Might I ask why enthusiasts for integration SpamAssassin with Mailman do not care about delivery of spam to other mail aliases in their domain. And if they do so care, why do they not concentrate on stopping spam reaching all of their mail aliases.
I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
I can't speak for the others, but in my case, I am the administrator for Mailman, but not for the main mailserver, nor even for the mailserver that MailMan runs on. I can install the spamassassin software in the Mailman account; I can even install the spamassassin server software on another server that I run; but I cannot integrate spamassassin with the main mailserver in any way. Our current mail system was designed to discourage server-side spam blocking.
Jerry jerry@sandiego.edu http://www.sandiego.edu/~jerry/ Serra 188B/x8773
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair."--Douglas Adams (Mostly Harmless)
On Mon, Nov 17, 2003 at 10:52:44PM +0000, Richard Barrett wrote:
I agree with Jeff. I don't plan on maintaining my SpamAssassin patch passed its current incarnation. I welcome a standard implementation.
Might I ask why enthusiasts for integration SpamAssassin with Mailman do not care about delivery of spam to other mail aliases in their domain. And if they do so care, why do they not concentrate on stopping spam reaching all of their mail aliases.
I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
That's actually the reason why I'm no longer maintaining my patch; I've moved to an amavisd / SpamAssassin system that hangs off of Postfix's delivery chain.
Because of this, I'd still like to see a standard SpamAssassin-aware handler in Mailman that could react to the tagged messages.
-- Jon Parise (jon@csh.rit.edu) :: http://www.csh.rit.edu/~jon/
On Monday 17 November 2003 23:52, Richard Barrett wrote:
Might I ask why enthusiasts for integration SpamAssassin with Mailman do not care about delivery of spam to other mail aliases in their domain. And if they do so care, why do they not concentrate on stopping spam reaching all of their mail aliases. I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman. Or did I miss something important along the way.
Yes, you miss that a bayesian filter works better when the non-spam traffic is focused on a given argument. If you train on many lists talking on very different topics, maybe even in different languages, a bayesian classifier is less effective. For this reason it's much better to have a separate spam database for each list. Not to mention how cool can be the Mailman UI as a management interface for your filter (e.g. by training on messages held for moderation). This applies to all bayesian filter, not only to SpamAssassin.
-- Adde parvum parvo magnus acervus erit -- Ovidio
On Mon, Nov 17, 2003 at 10:52:44PM +0000, Richard Barrett wrote:
Might I ask why enthusiasts for integration SpamAssassin with Mailman do not care about delivery of spam to other mail aliases in their domain. And if they do so care, why do they not concentrate on stopping spam reaching all of their mail aliases.
I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
Or did I miss something important along the way.
I would like spamassassin integration with mailman because, there are some messages that tend to be tagged as spam and in fact are not. Messages that are scored between about 4 and 10 should be moderated by the list administrators. Ideally the moderation range should be configurable per-list. The current implementation is systemwide, but that works well enough for me.
I don't use bayes-filters per list, but use one bayes filter for all messages processed by mailman (most of my lists are low traffic, so I assume bayes filtering doesn't do very much in that case).
The SpamAssassin filter at http://gewis.nl/~pieterb/python/SpamAssassin.py.txt handles both cases of integration and I wonder what's needed to get something like this in the default mailman's distribution.
The things that should be done:
- make it i18n-aware (i haven't looked into that yet)
- improve documentation / faq entry
- ... (anything else?)
Regards,
Pieter
-- Just because your doctor has a name for your condition doesn't mean he knows what it is.
On Mon, 2003-11-17 at 23:52, Richard Barrett wrote:
I guess I cannot understand why you are messing around integrating SpamAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
Or did I miss something important along the way.
Figuring out what to send and what to throw away is not up to the incoming mail server to decide. The list administrators should make that decision.
Mailman gives each list admin a lot of influence over the specific list configurations. Providing a default action for tagged mail, as well as a chance for the list admin to override the server admin for the list that admin is responsible for saves a lot of work for the application or server administrators.
If you use mailman for your abuse, virus, news-abuse and postmaster lists, you need to provide a method for those lists to accept or deny spam on an individual basis without fiddling with the general mail scanning server. These things are best left to the specific list admins. For the other lists, a default setting should be sufficient.
-- SSM - Stig Sandbeck Mathisen Trust the Computer, the Computer is your Friend.
On Mon, 2003-11-17 at 17:52, Richard Barrett wrote:
Might I ask why enthusiasts for integration SpamAssassin with Mailman do not care about delivery of spam to other mail aliases in their domain. And if they do so care, why do they not concentrate on stopping spam reaching all of their mail aliases.
I guess I cannot understand why you are messing around integrating SpammAssassin with Mailman when you should be integrating it with your MTA so that the spam never gets anywhere near Mailman.
Or did I miss something important along the way.
We do this on python.org, although we use Spambayes instead of SpamAssassin. Still, anything that scores as very high spam gets rejected at SMTP time, which is nice because then the spammer has to spend a little bit of effort to deal with it. I'm not aware of any false positives in quite a long time.
However, message that score Unsure will get tagged and forwarded. It's useful for Mailman to have some regexp checks on spam headers so individual list owners can decide whether they'll accept a lower threshold for spam (at the expense of higher false positives).
-Barry
On Sat, 2003-11-29 at 09:23, Barry Warsaw wrote:
It would be great if a SpamAssassin.py will be integrated in Mailman 2.1.4! Can anybody commit this SpamAssassin.py and James his spamd.py to the Mailman CVS?
2.1.4 has to be a pure(r) bug fix release.
Let me amend that: I could support an improved regexp filter of pre-tagged messages for 2.1.4. It would be up to some upstream process to tag the messages. The idea would be to improve Privacy->Spam Filters so that you could have multiple regexp rules, with a selectable disposition for each rule. You'd need an up/down button and a delete button for each rule. I'm betting you could adapt the topic filter widget to get this done.
-Barry
On Sat, 2003-11-29 at 09:36, Barry Warsaw wrote:
On Sat, 2003-11-29 at 09:23, Barry Warsaw wrote:
It would be great if a SpamAssassin.py will be integrated in Mailman 2.1.4! Can anybody commit this SpamAssassin.py and James his spamd.py to the Mailman CVS?
2.1.4 has to be a pure(r) bug fix release.
Let me amend that: I could support an improved regexp filter of pre-tagged messages for 2.1.4. It would be up to some upstream process to tag the messages. The idea would be to improve Privacy->Spam Filters so that you could have multiple regexp rules, with a selectable disposition for each rule. You'd need an up/down button and a delete button for each rule. I'm betting you could adapt the topic filter widget to get this done.
Heh, okay I've done this. As soon as everything's checked in (I'm off-line as I'm writing this), please checkout the Release_2_1-maint branch of cvs and see if you like what I've done.
-Barry
participants (8)
-
Barry Warsaw
-
Jeff Warnica
-
Jerold Stratton
-
Jon Parise
-
PieterB
-
Richard Barrett
-
Simone Piunno
-
Stig Sandbeck Mathisen