> 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(a)list.org composing of a symphony with the writing of |
|http://list.org/~viega/ its score." |
|University of Virginia -- Edsger Dijkstra |
----------------------------------------------------------------------------
In a prior round of email, Ken mentioned that we would need to key the
mail list entries to something other than the person's actual email
address in order to implement the flexible user information editing
capability of the web (changing one's sendto address, etc.). I agree
that this is needed, sooner or later. Since I haven't seen the code yet,
how difficult is it to just make a unique key for each subscriber and
key the database off that with address as just one value?
I hope I'm not using this list too soon.
--
Robin K. Friedrich Houston, Texas
Python Professional Services, Inc.
friedrich(a)pythonpros.com
http://www.pythonpros.com
For anyone that's interested, i've packaged up my current version of
mailman as three files in
ftp://www.python.org/pub/python/contrib/Networking/mailman
(Note that the klm.p1 patches *supercede* any prior patch packages i
sent out - lots of developments today and yesterday. I will try to
stick with incremental patches for incremental releases from this
point forward.)
mailman-1.0b1.tar.gz - The most recent surviving version (since his
server crash and data loss) of john viegas mailman distribution that i
could find, and
klm.p1 - patches i've assembled over three or four days of hacking, to
bring the revision to 1.0b1.1 (from 1.0b1). They implement a bunch of
features, some of which i found imperative. There's a synopsis of the
new features in...
klm.notes1 - notes about the first set of patches. Here's the major
highlights:
- optional anti-spam filter, imposing the constraint that postings
with the 'require_explicit_destination' option set must have the
name of the list among the explicit recipients ('to' or 'cc') addrs
in the message. This measure has been working *quite* nicely on the
majordomo lists that i hacked it onto.
- rmlist now does *not* get nasty and delete all the lists,
templates, and archive hierarchies if you invoke it without any
arguments. !
- All the list configuration defaults are collected in
modules/mm_cfg.py, so ideally the installer compiles the wrappers,
puts the files in place, and then applies their settings to this
file to configure all the defaults for all the lists.
- monthly password reminders are sent out collecting together each
users passwords in a single message, rather than sending a message
per password.
- Prevent cascading subject-line list prefix (which effect many of
you on the meta-sig may have noticed in the initial postings -
i hadn't tried using the subject-line prefix in my test lists!-)
There's more - read klm.notes1 for details. And these fixes are
really not so big compared to the very nice features mailman offers in
the first place. I won't go into that here, just suggest you try it
out if you're looking for a good maillist mechanism...
Note that i'll be away most of tomorrow and this weekend (in the grand
python tradition of being unreachable just after a release). Barring
any catastrophic behaviors of the setup in my absence, i'll probably
be announcing this on the python newsgroup early next week, and
switching over the rest of the python.org mailing lists at that point.
(I will probably work with andrew kuchling to integrate with the newer
pipermail, first.)
Ken Manheimer klm(a)python.org 703 620-8990 x268
(orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #
