I would definitely like to see a user-centric view of the world, as opposed to a list-centric view, especially when we're talking about users managing their presence via the Web. I want to be able to pull up one Web page that gives me a form by which I can change my email address in one fell swoop, perhaps have different email addresses per list, change my visibility per list, etc. If I had to visit a list-centric page for every list I'm a member of, that would be a huge pain. (But list-centric Web pages still have their uses, so the same database could drive both views).

Maybe the code isn't set up for this now, but it should be a goal of future development. In that case, while I agree with Ken that the email account is critical as the user's identity, having some other unique key to identify the user is helpful when email addresses change, as is inevitable. Requiring or using a public key system seems excessive, but I don't see how to keep the user id from being given to the user. I might not remember what address I'm subscribed with on which list (I see this happen a lot with Majordomo users actually).

Okay, sorry I'm late in jumping into these discussions, but I've been away. A little bit of background for anyone who doesn't know: I had been developing mailman off and on, until I lost several months worth of changes in a disk crash (blame Greg Stein for not doing backups :). I'm slightly uncomfortable seeing people use the version that is now getting passed around, but I am certainly happy people are using it.

The above problem was once changed. I kept a centralized user database. The way you could change your email address was with your password... there was no need for any sort of public key, etc.

Some other stuff that was lost (some of this might actually be there, but I don't think so):

• going to the listinfo CGI script w/o an argument should give a list of

lists, except for the ones that are configured to be "hidden".

• If a user appears in the TO or CC lines, and we can determine that he

is on our mailing list, don't send him mail, because he already got it. Don't count such addresses towards the "this is probably spam" threshhold.

• If a list admin gets lazy, and doesn't handle approvals for a long

time, automatically send back rejections.

• A site config page, including a password for the site manager, which

works on any list.

• A change to the way prefixes are handled, which it looks like Ken

reimplemented already.

• Talk to port 25 instead of calling sendmail, to make portability to

other MTAs easier.

There might have been a few more things. Those are the important things I can remember.

However, Mailman was never 100% of the way to where I'd like it to be. One of the big problems is that I started out with a lot of majordomo experience, so a lot of the model is the same. What I'd most like to change, is to make mailman a daemon process that is always running, and use threads effectively. This would reduce the overhead of always having to start up a python interpreter and init mailman whenever a request comes in. It could also improve the grainularity of the locking mechanism, which is something that I feel really needs to be done.

Anyway, my situation is that I don't have too much spare time to be coding until I finish the thesis I'm writing (though maybe a little bit). That shouldn't be any later than June 1. However, I'd be more than happy to accept changes from other people, and go back to actually releasing this software, if there is an interested development community this time around. All of the things mentioned above, I'd like to see happen, but anything that improves mailman, I'd like to incorporate.

John

|John Viega "The public at large tends to confuse the | |viega@list.org composing of a symphony with the writing of | |http://list.org/~viega/ its score." | |University of Virginia -- Edsger Dijkstra |