Mailman 3 January 2002 - Mailman-Developers

Thread support
by Ellen Spertus Jan. 6, 2002

Jan. 6, 2002

My students and I have built a prototype system, Javamlm, supporting user subscriptions on a per-thread basis using standard MUAs. I approached Barry about adding threads to Mailman, and he kindly encouraged me to do so. I'm now trying to figure out the best way to add the functionality and welcome any suggestions. You can get the full description of our system at http://www.mills.edu/ACAD_INFO/MCS/SPERTUS/Papers/lisa2001.pdf. I'll summarize important features here in the hope of getting feedback on the best way to fold them into Mailman. FUNCTIONALITY A user of mailing list foo creates a new thread with a base name of bar by sending email to foo-new-bar@host. The system appends an integer to bar to generate a unique thread name, e.g., bar1. All subscribers to mailing list foo receive the first message of any thread. The message headers are: To: foo-bar1@host From: original-sender@wherever If a user chooses reply, the new message goes to the original sender (assuming a decent MUA). It a user chooses reply-all, the new message becomes part of the thread bar1. When subscribing (or subsequently), each user specifies whether they want to be subscribed to new threads by default. If so, the user gets all messages in a new thread (unless they explicitly unsubscribe). If a user chooses NOT to be subscribed to new threads by default, they only get the initial message unless they explicitly subscribe. Each message contains (un)subscribe information both as a URL and mailto to make the operations as lightweight as possible; e.g., To unsubscribe from this conversation, send email to foo-bar1-unsubscribe(a)javamlm.mills.edu or visit http://javamlm.mills.edu/scripts/override?listname=foo&conversation=14&pref…. To unsubscribe from foo, send email to foo-unsubscribe(a)javamlm.mills.edu. Note that thread membership is determined solely by the address to which a message is sent, not the message's subject, references, or other headers. IMPLEMENTATION We implemented threads by including a threadID in each message's metadata, which was stored in a relational database, as was information about each thread, subscription, etc. The following SQL query determines to whom to send a message in thread 37: SELECT email FROM Subscriber WHERE deleted = FALSE AND ((Subscriber.preference = 1 AND NOT EXISTS (SELECT * FROM Override WHERE Override.subscriber_id = Subscriber.subscriber_id AND Override.thread_id = 37 AND Override.preference = 0)) OR (Subscriber.preference = 0 AND EXISTS (SELECT * FROM Override WHERE Override.subscriber_id = Subscriber.subscriber_id AND Override.thread_id = 37 AND Override.preference = 1))) The full schema is in the paper. I'm including the query here to give you an idea of the complexity and to show that list membership is calculated on the fly. The biggest implementation question in my mind is whether I should store subscription information in a relational database (so I can make the above efficient query) or build on top of the exiting pickles. I welcome any comments and pointers. Ellen

2 1

Foiling automated subscriptions by spammers
by George F. Nemeyer Jan. 6, 2002

Jan. 6, 2002

Discussions on another list bring up something to consider: ---------- Forwarded message ---------- Date: Sat, 5 Jan 2002 11:19:24 -0500 (EST) From: "George F. Nemeyer" <tigerwolf(a)tigerden.com> To: spam(a)zorch.sf-bay.org Subject: Re: bulk email explosion this spring? On Sat, 5 Jan 2002, Tim Pierce wrote: > Has anyone heard rumors that big spamhauses are planning to deploy new > technology to attack mailing lists, or for that matter are planning > anything specific for this spring? I've not heard rumors, but the way I read the ominous forecast was that spammers plan to automate the subscription/confirmation process to get into lists initially with the hope of getting at least one spam flood through. If that's true, it seems the next logical step is to create lists that are 'semi-moderated'. That is, for any new subscriber, a human reviews and manually approves the first N postings, until the user can be tagged as 'trusted' and their subsequent posts are then allowed onto the list automatically. If any early posts are spam, the user is summarily booted. N can even be zero if the list owner knows and trusts the user when they approve the subscription to the list initially. I can't see large volume spam houses bothering to actually create on-topic posts long enough to become tagged trusted since doing so by automated means would be nearly impossible for large numbers of lists with widely varying subjects. This scheme should work at least for lists where the rate of new subscriptions is managable. Other schemes might involve requiring posting domain to be the same as subscription domain, or other 'source' comparisons which would flag suspicious posts for approval before letting them onto the list. It will take some list server software changes, so I'm going to copy this to the Mailman developer's list for consideration. George Nemeyer Tigerden Internet Services

2 2

Re: [Mailman-Developers] Feature Request - Plain Text Only
by J C Lawrence Jan. 5, 2002

Jan. 5, 2002

On Fri, 4 Jan 2002 17:57:39 -0800 Dan Wilder <dan(a)ssc.com> wrote: > Wondering if you're also testing SpamCop, http://www.spamcop.com. Nope. I was rather steered off it by being on the annoying receiving end of its alerts and bounces (some of the users of the local Linux UG use it). That pretty well nixed any further interest from me. > I haven't evaluated it, but I'm afraid I've a bit of a bone to > pick with it. False positives are not unknown. Worse, it sends > automatic anonymous complaints to upstream providers of anybody > even mentioned in the putative spam. Sounds astonishingly familiar. > Yet another. "Forgot my password" on our Mailman lists apparently > trips at some SpamCop content filter; I've fielded at least one > spam auto-complaint thus generated. Aye. One of the razor problems is people registering Mailman password reminders as SPAM, tho the best I saw was a comp.risks digest getting Razored.... > The SpamCop site has verbiage implying that a mailing list had > better be able to prove it is double-opt-in, and had better > maintain proof of opt-in for each individual subscriber, or else. > The "or else" isn't specified, but apparently Mr. Haight has had > some record of success in arranging loss of internet connectivity. > No doubt some of those affected have been actual spammers, but > with one man serving as judge, jury, and executioner, I'm afraid I > don't see much about this effort to reassure the rest of us. <shrug> They're short lived phenomena. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

On IRC this weekend
by barry＠zope.com Jan. 5, 2002

Jan. 5, 2002

Hey all, I'll try to hang out on irc.openprojects.net #mailman this weekend, off an on as time permits. -Barry

1 0

Feature Request - Plain Text Only
by Marc Perkel Jan. 4, 2002

Jan. 4, 2002

I'd like a flag to disallow mime/html messages as an anti-spam feature. Most spam has pictures - html - java - etc - and prohibiting these messages could be an effective tool in reducing spam.

3 2

simple feature
by Bill Bradford Jan. 4, 2002

Jan. 4, 2002

Will 2.1 have the ability to just completey *drop* posts matching a pattern, instead of holding them for moderation? I've got a couple of lists where Re: posts (replies back to the list) arent allowed; only initial problem messages and then a summary/solution posting. It would be nice if I could have Mailman just *drop* the Re: posts instead of holding them for moderation; I'd like to avoid having to use Procmail for this... Bill -- Bill Bradford mrbill(a)mrbill.net Austin, TX

4 4

[patch] A few typos
by Daniel Buchmann Jan. 4, 2002

Jan. 4, 2002

I found a few typos in current CVS. Patch attached. Details: 1. Mailman/Cgi/admindb.py:193, messages/mailman.pot:640 Wrong variable name. "esender" should be "sender" 2. templates/en/admindbpreamble.html:2 "...held for you approval..." should be "...held for your approval..." 3. cron/crontab.in.in:8 Missing '@' in the entry for cron/disabled Every morning at 9:00 cron would mail this error: "/usr/bin/python: can't open file '@prefix/cron/disabled'" -Daniel diff -r -N --unified=3 mailman-cvs/Mailman/Cgi/admindb.py mailman/Mailman/Cgi/admindb.py --- mailman-cvs/Mailman/Cgi/admindb.py Thu Jan 3 06:06:24 2002 +++ mailman/Mailman/Cgi/admindb.py Fri Jan 4 13:54:42 2002 @@ -192,7 +192,7 @@ 'filterurl' : adminurl + '/privacy/sender', } if sender: - d['description'] = _("all the %(esender)s's held messages.") + d['description'] = _("all the %(sender)s's held messages.") doc.AddItem(Utils.maketext('admindbpreamble.html', d, raw=1, mlist=mlist)) show_sender_requests(mlist, form, sender) diff -r -N --unified=3 mailman-cvs/cron/crontab.in.in mailman/cron/crontab.in.in --- mailman-cvs/cron/crontab.in.in Thu Dec 27 08:09:29 2001 +++ mailman/cron/crontab.in.in Fri Jan 4 13:55:17 2002 @@ -5,7 +5,7 @@ # # At 9AM, send notifications to disabled members that are due to be # reminded to re-enable their accounts. -0 9 * * * @PYTHON@ -S @prefix/cron/disabled +0 9 * * * @PYTHON@ -S @prefix@/cron/disabled # # Noon, mail digests for lists that do periodic as well as threshhold delivery. 0 12 * * * @PYTHON@ -S @prefix@/cron/senddigests diff -r -N --unified=3 mailman-cvs/messages/mailman.pot mailman/messages/mailman.pot --- mailman-cvs/messages/mailman.pot Mon Dec 31 23:15:01 2001 +++ mailman/messages/mailman.pot Fri Jan 4 13:55:36 2002 @@ -637,7 +637,7 @@ msgstr "" #: Mailman/Cgi/admindb.py:193 -msgid "all the %(esender)s's held messages." +msgid "all the %(sender)s's held messages." msgstr "" #: Mailman/Cgi/admindb.py:198 diff -r -N --unified=3 mailman-cvs/templates/en/admindbpreamble.html mailman/templates/en/admindbpreamble.html --- mailman-cvs/templates/en/admindbpreamble.html Sat Dec 29 08:36:13 2001 +++ mailman/templates/en/admindbpreamble.html Fri Jan 4 13:55:56 2002 @@ -1,5 +1,5 @@ This page contains a subset of the <em>%(listname)s</em> mailing list -postings that are being held for you approval. It currently shows +postings that are being held for your approval. It currently shows %(description)s <p>For each administrative request, please select the action to take,

1 0

One more wish
by Lawrence Weeks Jan. 4, 2002

Jan. 4, 2002

Another wish... probation. I had a system with Majordomo, daily cron rotation of subscriber files, that I liked, hackish as it was. New subscribers were unable to send mail to a particular large and active list for a period of time (five days in my case) after subscribing. This was to force new subscribers to read the list traffic and figure out, as much as they could in five days, list culture and what is acceptable. That list has lots of "juvenile" subscribers, and the probation period is (was) useful to temper their behavior. And how about the oft-requested rotating footers? I looked in an alpha release of 2.1 and didn't see it in Decorate.py. I'd like this functionality, so I'll make these changes myself if necessary. I'll happily contribute patches, but I'm not an experienced Python coder nor am I too familiar with the MM structure, so it'll likely be an ugly hack. :-) Larry -- Lawrence Weeks "Audaces fortuna juvat." dev(a)anabasis.net

5 7

Re: [Mailman-Developers] Marc Perkel's Feature Wish List
by Dan Mick Jan. 3, 2002

Jan. 3, 2002

> > I'd like a setting so that if non-members post to the list that their > > messages are automatically dropped (bounced) without list owner > > intervention. The bounce message should be able to be customized giving > > the user information to join the list - or just go to hell. > > > I've got a patch to do that against 2.0.8 which works for new lists. If > someone could tell me what the right way is to add an entry into an existing > database I'd have a complete patch. I think Mailman/versions.py::NewVars() is the one that does all that sort of stuff. It's invoked when the version change is detected in MailList.py::CheckVersion(), though, and that version number is owned by Barry/the official distro. I think it's probably difficult to do in a patch so that it doesn't interfere with future releases.

3 3

Re: [Mailman-Developers] Marc Perkel's Feature Wish List
by J C Lawrence Jan. 3, 2002

Jan. 3, 2002

On Wed, 02 Jan 2002 14:11:59 -0800 Marc Perkel <marc(a)perkel.com> wrote: > I'd like to be able to enter (and/or allow the user to enter) > other email addresses that if they sens email from the other > address they have the same membership privileges as the original > member email address. Thus if gnu(a)eff.org is in the list but the > email comes from gnu(a)toad.com then it is treated the same. Ideally > - the user could make these aliases and it would apply to all > lists the user is a member of. This has been long requested. An early motion in that direction is in 2.1, but its only fractional. Down the pipe the intention is to have user accounts which subscribed to lists, with each account having one or more email addresses, each of which may have a mail status in regard to each list the account is a member of. > Right now the url http://domain.com/mailman/admin goes to a page > that just shows public lists. I'd like to see a link there that > goes to a master admin page - where you first have to enter the > master password - and then you get several master admin options - > including: > 1) A list of all lists - links to the admin pages of each list > whether public or not. 2) Menu to create a new list - avoiding > the need to go to the command line. 3) Change master Password. > 4) All other master maintenance stuff - checking the database > integrity - that sort of thing. 5) Delete a list. 6) Options for > list owners - that would allow/not allow list owners to delete a > list. 7) Control of other list manager privileges - virtual > domain owners - etc. 8) Menu to set defaults for new list > creation - or defaults for new lists on a per virtual domain > basis. Again, functionally some of this is already in 2.1 (eg new list creation). More generally: Yup, needed, wanted, should be done. > If I set my password - that should be my password for all > lists. Yup, part of the above coming-some-day-soon user account system. > This also applies to my real name... Already in 2.1. > I'd like a setting so that if non-members post to the list that > their messages are automatically dropped (bounced) without list > owner intervention. In 2.1. > The bounce message should be able to be customized giving the user > information to join the list - or just go to hell. <nod> 2.1 is much better in this regard, but I'll have to see if it went that far. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1