[Mailman-Developers] Creation/deletion of lists through-the-web

[Barry A. Warsaw]

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.