Post-subscription processing
What's the sanest way to export a list of current subscribers everytime there is a new subscriber? I want to maintain a table of current list members (for postfix to reject if to:list != from:subscriber)
Tia,
-Jim P.
On 08/15/2013 07:17 PM, Jim Popovitch wrote:
What's the sanest way to export a list of current subscribers everytime there is a new subscriber? I want to maintain a table of current list members (for postfix to reject if to:list != from:subscriber)
How about unsubscribes? Changes of address? I would suggest that the most reliable way is to put hooks in the Mailman/OldStyleMemberships.py member adaptor routines addNewMember and removeMember. This will get changes of address too because that is done by a remove and add.
Another is to create something that would parse the subscribe log and get those list names that have entries with time stamps later than the last run and do bin/list_members for those lists, and run it frequently via cron. This has the advantage of not modifying Mailman, but has the drawback that address changes aren't logged (unless you are running https://code.launchpad.net/~mailman-coders/mailman/2.2), and there may be log rotation issues to deal with.
If you have lots of excess resources, you could just run bin/list_members for all lists at frequent intervals via cron. e.g.
#!/bin/bash
for list in /path/to/bin/list_lists --bare
; do
/path/to/bin/list_members $list > /path/to/${list}_member_list
done
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
----- Original Message -----
From: "Mark Sapiro" mark@msapiro.net
On 08/15/2013 07:17 PM, Jim Popovitch wrote:
What's the sanest way to export a list of current subscribers everytime there is a new subscriber? I want to maintain a table of current list members (for postfix to reject if to:list != from:subscriber)
How about unsubscribes? Changes of address? I would suggest that the most reliable way is to put hooks in the Mailman/OldStyleMemberships.py member adaptor routines addNewMember and removeMember. This will get changes of address too because that is done by a remove and add.
Perhaps I'm missing something, but doesn't Mailman already have "only allow members to post to the list"?
NANOG had to make special provisions, but that was because they wanted to have a read-only status to put people in when they needed a timeout.
Cheers, -- jra
Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Thu, Aug 15, 2013 at 11:46 PM, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "Mark Sapiro" mark@msapiro.net
On 08/15/2013 07:17 PM, Jim Popovitch wrote:
What's the sanest way to export a list of current subscribers everytime there is a new subscriber? I want to maintain a table of current list members (for postfix to reject if to:list != from:subscriber)
How about unsubscribes? Changes of address? I would suggest that the most reliable way is to put hooks in the Mailman/OldStyleMemberships.py member adaptor routines addNewMember and removeMember. This will get changes of address too because that is done by a remove and add.
Perhaps I'm missing something, but doesn't Mailman already have "only allow members to post to the list"?
NANOG had to make special provisions, but that was because they wanted to have a read-only status to put people in when they needed a timeout.
The SDLU list is whitelist'ed from spamassassin processing, so a fair amout of spam from non-members gets into the moderator queue. The goal is to reject at the MTA where sender is not in a sender_access restriction table (which will be maintained by this modification to Mailman).
Mark, thanks for the ideas and input. I want to avoid the cron solution, in order to prevent racing issues with folks who subscribe and immediately post.
-Jim P.
----- Original Message -----
From: "Jim Popovitch" jimpop@gmail.com
The SDLU list is whitelist'ed from spamassassin processing, so a fair amout of spam from non-members gets into the moderator queue. The goal is to reject at the MTA where sender is not in a sender_access restriction table (which will be maintained by this modification to Mailman).
Got it. That sounds generally useful; in implementing patches you might want to keep in mind my personal favorite programming maxim:
Figure out what general case your problem is a specific case of... and then solve the general case.
:-)
Cheers, -- jra
Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
participants (3)
-
Jay Ashworth
-
Jim Popovitch
-
Mark Sapiro