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

[Barry A. Warsaw]

>>>>> "JRA" == Jay R Ashworth <jra@baylink.com> writes:

    JRA> Ain't Python great?

(ssshhh!  they'll discover our secret weapon. :)

    JRA> IMHO, the proper solution for sendmail is for the admin to
    JRA> put an :include: in /etc/aliases pointing to
    JRA> /home/mailman/data/aliases, and rebuild that from scratch
    JRA> against the current list of lists every time that list
    JRA> changes.

I'm really trying to avoid having to write the sendmail code myself.
I just have too many scary flashbacks when I even think about mucking
with sendmail. ;}

Now that everything's checked in, folks can see how I'm doing it with
Postfix, so I hope eventually someone will contribute a
Mailman/MTA/Sendmail.py module.  Until then, I'll work it so it does
something simple.

    >> 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.

    JRA> You're working at the 'compiled' level there, right?

If I understand what you're asking, yes.  IOW, I don't muck about in
the plain text aliases file, but I write directly to the file that
newaliases would produce.

    >> 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].

    JRA> I suspect you'll need one more: how to get the aliases
    JRA> database rebuilt when it's been changed.

That's the beauty of the Postfix approach: I'm modifying the database
directly so it doesn't need to be rebuilt (i.e. no need to run
newaliases).  I don't even have to notify Postfix since it'll notice
the change after one minute.

>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes:

    TW> What about a 'send list creation message' ? And a
    TW> 'auto-generate password' button ? In my eyes, typically, the
    TW> person creating the list won't be the list owner him/herself,
    TW> so those things make sense to me.

The list creation message is always sent currently.  Does it make
sense to be able to inhibit that?

The auto-generate password button is a good idea, I'll add that.
    
    TW> And what about the domain the list should be created on ?

The domain in the url to the `create' script!  Note that bin/newlist
does need a domain switch, since the context can't be determined when
run from the command line, but the create cgi doesn't have that
problem.  E.g. if I want to create a new list on python.org, I'd visit
http://mail.python.org/mailman/create but if I wanted to create a new
list on zope.org (a virtual host of a shared Mailman installation),
I'd visit http://mail.zope.org/mailman/create.

    TW> Why not have the 'delete a list' option be on the list
    TW> creation page as well (make it the 'site administration page'
    TW> or something.)

I thought about that, but it makes things too complicated.  E.g. now
that global page has to have some pull down menu or other way to
specify which list you want to delete.  List deletion is list-centric,
so it's okay to have it hang off the list admin page (really, it's
that the rmlist cgi script requires a list name in the url).
    
    TW> Again, this won't make sense everywhere, but I'd *love* to be
    TW> able to give our Sales dept. the list creator password to have
    TW> them create and destroy lists, without giving them the site
    TW> password.

That's a great idea, and I'll make the change so that list deletion
follows this password chain: list-owner, global list-creator, site
admin.

    >> Here's how I solved it for Postfix; this is outlined in a new
    >> README.POSTFIX file.

    TW> You'll want to add checks for the permissios of this file to
    TW> bin/check_perms, just to be sure. If not run as root, it can't
    TW> fix it automatically, but it can whine incessantly.

Good point!  This should probably be done in the Mailman/MTA/Foo.py
module so MTA-specific adaptors can do whatever additional checks are
necessary.

    >> 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. :).

    TW> Hi, Barry ! =)

Hi Thomas! :)

    TW> There's another dimension to it, though. At XS4ALL we use a
    TW> central database (currently MySQL, soon to be PostgresSQL) for
    TW> all email aliases, and the list creation mechanism should
    TW> insert the appropriate aliases into that as well as into the
    TW> local database -- and they have to differ slightly. (local
    TW> alias is, say, 'list@listXX.xs4all.nl', where XX is a growing
    TW> number, but the global alias should be either list@xs4all.nl
    TW> or list@domain.com, pointing to list@listXX.xs4all.nl).  I
    TW> could do this fairly easily by adapting the Sendmail (or
    TW> Postfix) MTA module and placing it in the MTA directory under
    TW> a different name.

I think that's the right approach.

    >> [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.

    TW> A minute ? Heh. I doubt that's ever going to be a problem,
    TW> most humans take a minute to read the resulting webpage, let
    TW> alone that they compose and send a message inside that minute.

My thinking exactly!
-Barry