Mailman 3 May 2001 - Mailman-Developers

Creation/deletion of lists through-the-web
by barry＠digicool.com 12 May '01

12 May '01

Last night I got inspired to add back the through-the-web creation and deletion of mailing lists. I've now got this working for Postfix and can work with other MTAs with a little help from y'all. I will soon be checking all this code into the 2.1 codebase, so watch mailman-checkins shortly. (And hey, it only took 24 hours from inception to completion! :). Apologies in advance for the length of this message. First, there is a new pseudo-role[1] called `list creator'. There is a separate, global list creator password, similar to but different than the site admin password. This is because list creation is a site-wide operation, but I don't want to have to give out the site admin password to someone who may only have list creation duties. Needless to say, the site admin can create lists through the web too. You set the list creator's password by using mmsitepass with the -c option. Let's say Mailman is installed at http://yoursite.com/mailman, then the list creation page is at http://yoursite.com/mailman/create which is linked to from the admin overview page (but not the listinfo overview page). The create page requires you to enter the name of your list, the email address of the initial list owner, the initial list password (with confirmation), and the list creator's password. There is then a "Create" button to submit the form. Assuming everything checks out, the new list is created, and the results page gives you three links to follow from there (go to the list's info page, the list's admin page, or create another list). Deleting a list is done from the list's admin page. There is now another link under "Other Administrative Activities" that says "Delete this list (requires confirmation)". Click on that and you're brought to a page for confirmation of the list deletion operation. You have a radio button to choose whether the archives should be deleted or not (the default is not), and you're prompted for the list admin password[2]. There's a link to cancel the deletion and return to the list's admin page, and a button to actually do the list deletion. For bonus, the site administrator can inhibit the ability for individual list owners to delete their lists through the web by setting OWNERS_CAN_DELETE_THEIR_OWN_LISTS = 0 in mm_cfg.py. Do this, and the link is not shown in the "Other Administrative Activities" list, and the rmlist cgi will error out every time. The current default for OWNERS_CAN_DELETE_THEIR_OWN_LISTS is 0, but that may change to 1 before the final release. The disadvantage is that with this variable set to 0, list deletion must be done via the command line script. Now, how to integrate this with MTAs? One reason why ttw list creation and deletion hasn't been (re-)added to Mailman until now is that you typically have to do some manual and difficult crud like edit an /etc/aliases file and run `newaliases' (as root!). I've figured a way around this with Postfix, and of course Exim can be configured to automatically recognize new mailing lists, so I figured it was time to do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst yourselves will contribute the code to glue this together for other mailers. Here's how I solved it for Postfix; this is outlined in a new README.POSTFIX file. Postfix has a configuration variable called `alias_maps' which tells it where to look for local delivery address associations. It has another variable called `alias_databases' which tells it which files to rebuild when invoked as newaliases. For each of these you can specify the type of map database the file is kept as. One of these choices is `hash', which is really a BSD dbhash file. Python has a dbhash module which nicely handles reading and writing dbhash files (and it should be enabled by default in Python 2.x, if your system has Berkeley DB installed, as most Linux distros ought to). It's moderately well-published what Postfix expects as entries in the dbhash (and it's easy to figure out by dumping a newaliases generated .db file) so, when creating a new list, Mailman can add the necessary keys and values to make Postfix happy. Let's say Mailman is installed as /home/mailman and writes its new list alias entries to the dbhash file at /home/mailman/data/aliases.db. By adding "hash:/home/mailman/data/aliases" to your Postfix's alias_maps variable, Postfix will automatically deliver to your new list. Deleting is as simple as removing the keys from the dbhash. Note that you do /not/ want to add this file to alias_databases since newaliases won't be touching it. So this works great, but there's a catch! Postfix will invoke the filter programs under the uid of the owner of the aliases.db file, unless that's root, in which case it'll invoke it as the user defined in the default_privs variable (by default `nobody'). And of course the gid has to match what you specify in --with-mail-gid or Mailman's mail wrapper will complain. The trick is to touch the alias.db file as root, set the group owner to mailman, and make sure the file is user and group writable. Now, when Mailman adds new keys to aliases.db, the user ownership will remain as root, so Postfix invokes it correctly as nobody. But because aliases.db is group-owned by mailman, the cgi processes can write to the file. And no setuid-root script in sight. I've tested this and it works like a charm. (Of course, all this is described in cookbook form without the gory details in README.POSTFIX. Also, I like this approach much better than the luser_relay hack I posted about a while ago.) There's one last bit of glue, and here's where you come in (I'm speaking to the one of you who is still reading this. :). There's a new variable in Defaults.py.in called MTA which must point to a module in the Mailman/MTA directory. This implements the MTA-specific operations needed when creating or deleting a list. The API is that this module should provide two functions: create() and remove() both of which take a MailList object. They should do whatever is necessary to inform the MTA that it's alias database has changed. For Postfix it's really not a lot of code[3]. For Exim, I predict "MTA = None" in mm_cfg.py will Do The Right Thing, since nothing special has to be done. I've no idea at this time what Sendmail, Qmail, or any other MTA will require, and I'm hoping those of you who use those mailers will be able to donate a module. Phew, that's it. I need sleep. I'm very interested in getting some feedback, especially for those hearty souls who can check out the current codebase, and give it a whirl. I'm no doubt forgetting some important details, but it sure has been fun. :) Enjoy, -Barry [1] I call it a pseudo-role because eventually this will be a role that can be given to specific users (once there's a Real User Database). [2] Because list deletion is not handled by the admin.py cgi script, it isn't protected by the normal admin login screen. I could (and may) add this extra authentication step, but I'll probably still keep the list password requirement on the deletion page as a strong confirmation of the list owner's intention. [3] There's one caveat: because I don't want to have to include a setuid-root script, the Postfix.py module doesn't call `postfix reload'. This command has to be done as root. The tradeoff is that Postfix will take about a minute to recognize its alias database has changed. To me that's an acceptable limitation.

10 28

Porting "NetiquetteEnforcer" to mailman
by Lars Marowsky-Bree 12 May '01

12 May '01

Good morning, I have switched my mailing lists from ezmlm to mailman (mostly because I wanted to use postfix) a few months ago. Under ezmlm, I wrote a cute little script called "NetiquetteEnforcer.pl", which did a rather good job at rejecting "annoying" (incorrectly formatted etc) mails. (If you are interested, you can look at http://lars.marowsky-bree.de/dl/NetiquetteEnforcer.pl ) Now, I meant to port this ages ago, but you know how "I will do it in my copious spare time" works out in practice... I am looking at how to integrate this properly with mailman. What I would probably have to do is to hook in HandlerAPI much like the "Hold" Handler and either hold the message, reject it immediately or let it pass through. However, I am unclear about how to do get the configuration information done properly - I would rather like an additional screen for the Content Filtering scheme in the Web management tools, and it isn't immediately obvious to me how I would go about this. Any insight would be appreciated. Sincerely, Lars Marowsky-Brée <lmb(a)suse.de> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl

2 1

Qrunner error
by Webmaster 11 May '01

11 May '01

Does anyone know what this error means and how to fix it. Traceback (innermost last): File "/home/mailman/cron/qrunner", line 78, in ? import time ImportError: /usr/lib/python1.5/lib-dynload/timemodule.so: undefined symbol: PyErr_Format -- ############################### Webmaster webmaster(a)isu.edu Computing & Communications ################################

2 1

http headers?
by Chuq Von Rospach 11 May '01

11 May '01

I can't find these offhand in the source -- anyone know what the MIME type the python returns itself as for the pages it generates? I'm experimenting with a new (non-intrusive) way to skin a UI on Python, but they aren't quite cooperating...

2 1

Re: Re: [Mailman-Developers] Creation/deletion of liststhrough-the-web
by Ben Burnett 11 May '01

11 May '01

My apologies for the missing attachement. -Ben

1 0

RFE: check_perms: ignore archives
by Dan Mick 10 May '01

10 May '01

Allow check_perms to bypass the archives subdirs. When they get large, check_perms can take *forever*, and so people won't run it, which is bad. I hacked something quickly that should be an option instead: $ diff check_perms check_perms2 80a81,86 > > if 'archives' in names: > print 'removing archives from names array' > names.remove('archives') > return >

1 0

Re: Re: [Mailman-Developers] Creation/deletion of liststhrough-the-web
by Ben Burnett 10 May '01

10 May '01

------- Original Copy ------- >Subject: Re: [Mailman-Developers] Creation/deletion of liststhrough-the-web >Date: 05/09/2001 3:23 PM >From: Ron Jarrell <jarrell(a)vt.edu> >To: barry(a)digicool.com (Barry A. Warsaw), "Jay R. Ashworth" <jra(a)baylink.com> >Cc: mailman-developers(a)python.org >>The list creation message is always sent currently. Does it make >>sense to be able to inhibit that? > >Yes. I currently manually go in and fix some things that just can't be set >from defaults easily before letting the admin know. Ideally I'd like a button >for "(re)send list creation message now", because what I do is run newlist, >hit ctl-z, go off and make my changes, fg it, and let it send the list message... FWIW I do sort of the same thing. I have hacked newlist to accept another option as described below. [mailman@mail riders_connection]$ ./bin/newlist --help Create a new, unpopulated mailing list. Usage: %(PROGRAM)s [options] listname listadmin-addr admin-password Options: -q --quiet Normally the administrator is notified by email (after a prompt) that their list has been created. This option suppresses that notification and the prompting. -s file --saveemail=file Append the email that is sent to the administrator of the new list to file. This is in addition to sending the email to the administrator unless -q is used. -o file --output=file Append the alias setting recommendations to file, in addition to printing them to standard output. -h/--help Print this help text and exit. You can specify as many of the arguments as you want on the command line: you will be prompted for the missing ones. Note that listnames are forced to lowercase. [mailman@mail riders_connection]$ a patch for this against 2.0.3 is attached if anyone is interested. -Ben

1 0

Re: [Mailman-Developers] Creation/deletion of lists through-the-web
by Richard Ellerbrock 09 May '01

09 May '01

>On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: >> For Exim, I predict "MTA = None" in mm_cfg.py will Do The Right Thing, >> since nothing special has to be done. I've no idea at this time what >> Sendmail, Qmail, or any other MTA will require, and I'm hoping those >> of you who use those mailers will be able to donate a module. > >Sendmail can work in the same way as Postfix, I believe. I'm not sure >if you can tell it to use more than one aliases.db file, but if it >can, the only difference is the permissions with which the commands >are executed. As far as I know, Sendmail also uses dbhash (hash or >btree, depending on how you make them) so no problem there. Yes sendmail can have multiple aliases files, just comma seperate them in the sendmail.cf file. This is for 8.11.1 which I am running - do not know for older versions. The only problem is that newaliases needs to be run as root, or else modify the sendmail.cf file to automagically rebuild the aliases files from time to time (you can specify the time out). I don't know what happens though when broken alias files are fed in though - does it just ignore the new file? -- Richard Ellerbrock richarde(a)eskom.co.za

1 0

Hi
by joker＠aol.com 09 May '01

09 May '01

Hi

1 0

Hi
by joker＠aol.com 09 May '01

09 May '01

Hi

1 0