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

Barry A. Warsaw barry@digicool.com
Thu, 10 May 2001 14:37:40 -0400

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> That's in the cf file.  You can specify more than one alias
    RJ> file.  Which is probably the cleanest way to do it; you'll
    RJ> still need something, if only a cronjob that runs newaliases -
    RJ> I shudder at the the thought of manipulating the sendmail
    RJ> alias db file directly, particularly since my python 2.0 will
    RJ> flatly not compile with the version of DB that sendmail is
    RJ> using; I suspect it's too new for the DB routines shipped with
    RJ> python.

Ah.  Python 2.1 should have a much better story here.  It doesn't
statically link against the db library, and you can install the latest
Sleepycat version of BerkeleyDB, and use Robin Dunn's PyBSDDB3 wrapper
(pybsddb.sourceforge.net).  Yup, that's more work, and it's not ideal,
but it ought to work.

    RJ> Note that eric said a while ago that he's deprecating the
    RJ> "auto rebuild alias file" for security reasons, so at some
    RJ> point that functionality will likely go away.

Another nail in the coffin for maintaining the aliases in the plain
text file.  But it looks like David Champion got the right solution
for Sendmail.

    RJ> Until the first time something goes wrong... Then you'll need
    RJ> a tool to regenerate all the aliases again from scratch.  I
    RJ> really don't like the fact that I won't have a text DB source
    RJ> file around...


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

    RJ> Yes.  I currently manually go in and fix some things that just
    RJ> can't be set from defaults easily before letting the admin
    RJ> know.  Ideally I'd like a button for "(re)send list creation
    RJ> message now", because what I do is run newlist, hit ctl-z, go
    RJ> off and make my changes, fg it, and let it send the list
    RJ> message...

I think the easiest thing to do right now is to restore the prompt
before notification is sent for the command line script.  It's not
immediately clear how I should handle this for the create cgi...