mailman filter for SpamAssassin support
![](https://secure.gravatar.com/avatar/0dc12f7d8dc7b9b4dd95e5544d765d51.jpg?s=120&d=mm&r=g)
I uploaded a patch to the SF bug tracker today that adds support for doing SpamAssassin (http://spamassassin.taint.org/) checks to the mailman message pipeline:
http://sourceforge.net/tracker/?func=detail&aid=534577&group_id=103&atid=300103
This will contact the spamd daemon to score the message. If the message gets scored above one threshold, it gets discarded (this defaults to 10, but can be customised in the mm_cfg.py file). If the message scores above another lower threshold, it gets held for moderation (this defaults to 5).
I wrote this to try and reduce the number of messages held for moderation. I wrote it for mailman 2.0.x (as that is what I am using at the moment), but it should be fairly easy to update for 2.1.
It might be worth using on the python.org mailing lists ...
James.
(I am not on the mailing list, so please don't remove me from the CC list on replies).
-- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/
![](https://secure.gravatar.com/avatar/817c7c4c02e4ce175b1d06543263afc1.jpg?s=120&d=mm&r=g)
I have a client who wishes to send a bunch of mail.
They're good little boys and girls; the address are all opt-in, to my personal knowledge.
The problem is that they're already in a database (filePro for Unix on SCO 5, on a machine behind a Linux 7.1 firewall), and they want to be able to selectwhom to mail on an adhoc basis.
This seems to suggest to *me* that I need to be able to either 1) set up and strike lists on the mailman side with some dispatch, or better 2) wire mailman atop the extant database... which I would prefer to do because I *don't* want to lose the web-based signoff stuff, etc.
I know this is a pretty kettle of fish; anyone have any suggestions?
I'm willing to take a swing at writing a Python module to encompass filePro if I have to do that, but I'm not sure that's enough here: the user data isn't *in* a 'database' yet, is it?
This is, of course, a paying gig... and it's not impossible I might sub out the "interface the back of Mailman to my database" part, particularly if it can be done generally enough to make accessing filePro data from Python easy, since that's something I'd find generically useful.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
![](https://secure.gravatar.com/avatar/a930430c7f9705b71a65f341c4191a2b.jpg?s=120&d=mm&r=g)
"JRA" == Jay R Ashworth <jra@baylink.com> writes:
JRA> The problem is that they're already in a database (filePro
JRA> for Unix on SCO 5, on a machine behind a Linux 7.1 firewall),
JRA> and they want to be able to selectwhom to mail on an adhoc
JRA> basis.
JRA> This seems to suggest to *me* that I need to be able to
JRA> either 1) set up and strike lists on the mailman side with
JRA> some dispatch, or better 2) wire mailman atop the extant
JRA> database... which I would prefer to do because I *don't* want
JRA> to lose the web-based signoff stuff, etc.
Can you use MM2.1? If so, then your options are many.
If the membership list needs to change on the fly, then use the new "virtual list" feature. I.e. create a list that all the message will appear to come from but build the recipient list on-the-fly. The easiest way to do this is, use a Python program to suck the data out of filePro (I've no idea how to do that), and build a Python list of recipients addresses. Then, make sure the installed Mailman package is in your sys.path (so your driver script can import Mailman modules).
Assuming you've got the listname, the list of recipients, and the message as plain text, it might be as simple as:
from Mailman.Post import inject
inject(listname, msgtext, recipients)
Note that Mailman/Post.py can also be run as a command line script.
Alternatively, you might want to use the new extend.py interface to hook into the MailList instance for your list. If there's a file called extend.py in your lists/listname directory, it will be execfile()'d and a function extend() will be called, passing in the MailList instance.
Your extend() function can do something like, overload the Load() and Save() method so that membership data is funneled to your database. You probably just need to re-implement the MemberAdaptor.py interface and set the mlist._memberadaptor attribute to your customized version. Then everything else should Just Work.
If you're stuck on MM2.0.x, then you've got your work cut out for you <wink>.
JRA> This is, of course, a paying gig... and it's not impossible I
JRA> might sub out the "interface the back of Mailman to my
JRA> database" part, particularly if it can be done generally
JRA> enough to make accessing filePro data from Python easy, since
JRA> that's something I'd find generically useful.
It would be nice if this was spec'd as being releasable under the Python license, so it could be donated back to Python.
HTH, -Barry
![](https://secure.gravatar.com/avatar/817c7c4c02e4ce175b1d06543263afc1.jpg?s=120&d=mm&r=g)
On Fri, Apr 05, 2002 at 12:24:38PM -0500, Barry A. Warsaw wrote:
"JRA" == Jay R Ashworth <jra@baylink.com> writes: JRA> The problem is that they're already in a database (filePro JRA> for Unix on SCO 5, on a machine behind a Linux 7.1 firewall), JRA> and they want to be able to selectwhom to mail on an adhoc JRA> basis.
JRA> This seems to suggest to *me* that I need to be able to JRA> either 1) set up and strike lists on the mailman side with JRA> some dispatch, or better 2) wire mailman atop the extant JRA> database... which I would prefer to do because I *don't* want JRA> to lose the web-based signoff stuff, etc.
Can you use MM2.1? If so, then your options are many.
Ghod I love the net.
At the moment, the only requirement is that it *work* when I'm done. :-)
Is the Member Adaptor stuff *in* 2.1? Cool; I thought that was 3.0 stuff.
If the membership list needs to change on the fly, then use the new "virtual list" feature. I.e. create a list that all the message will appear to come from but build the recipient list on-the-fly. The easiest way to do this is, use a Python program to suck the data out of filePro (I've no idea how to do that), and build a Python list of recipients addresses. Then, make sure the installed Mailman package is in your sys.path (so your driver script can import Mailman modules).
This is precisely what I needed; with one exception.
Assuming you've got the listname, the list of recipients, and the message as plain text, it might be as simple as:
from Mailman.Post import inject inject(listname, msgtext, recipients)
Note that Mailman/Post.py can also be run as a command line script.
Noted. :-)
Alternatively, you might want to use the new extend.py interface to hook into the MailList instance for your list. If there's a file called extend.py in your lists/listname directory, it will be execfile()'d and a function extend() will be called, passing in the MailList instance.
Your extend() function can do something like, overload the Load() and Save() method so that membership data is funneled to your database. You probably just need to re-implement the MemberAdaptor.py interface and set the mlist._memberadaptor attribute to your customized version. Then everything else should Just Work.
Oh yeah; like it's gonna be that easy.
This is what I really need, assuming as I do that it will allow the "unsubscribe" web page to link back into my live data...
But I'm not sure how to get there from here.
JRA> This is, of course, a paying gig... and it's not impossible I JRA> might sub out the "interface the back of Mailman to my JRA> database" part, particularly if it can be done generally JRA> enough to make accessing filePro data from Python easy, since JRA> that's something I'd find generically useful.
It would be nice if this was spec'd as being releasable under the Python license, so it could be donated back to Python.
Lvoe to go there if I can. If it gets someone a discount, that will make it easier. :-)
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
![](https://secure.gravatar.com/avatar/2206e8a0d58563f815a7568ea6675313.jpg?s=120&d=mm&r=g)
On 4/5/02 9:11 AM, "Jay R. Ashworth" <jra@baylink.com> wrote:
I know this is a pretty kettle of fish; anyone have any suggestions?
I'm willing to take a swing at writing a Python module to encompass filePro if I have to do that, but I'm not sure that's enough here: the user data isn't *in* a 'database' yet, is it?
Sounds like a job for 2.1's external database API... Before anything else, at least, I'd look into it and see how close it comes to your needs.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
participants (4)
-
barry@zope.com
-
Chuq Von Rospach
-
James Henstridge
-
Jay R. Ashworth