Another issue with mailman locking - i think it's coarse grained, and
needs to be refined. For example, this morning someone noticed that
the umbrella listinfo page on python.org was hanging, because, it
turns out, one of the lists was left in a locked state. (Not sure how
that happened - it usually doesn't.) Well, the umbrella listinfo (and
admin) pages open the lists only for the sake of determining which are
public ones - no writing is actually required, so a lock isn't really
It might be sufficient to offer a way to open a list "read-only", such
that no locking is done. I think it would be better, however, to
refine the locking system such that lists are not locked until they
enter an operation that changes the list data in a way that will
eventually need to be written. This would probably take a more effort
than a "read-only" kluge, but may not be too bad.
I guess this is one for the todo list. (Wish i had gobs of time to
continue to hack on a these sorts of things - they're not very big or
hard, but there is a bunch of them, and they need to be done right.)
Has anyone modified pipermail's hypermail emulation to work using only
modules that are compiled in the default Python distribution? There's
one dependency I have in mind: pipermail currently uses bsddb, which
is not compiled into Python 1.5. I think gdbm is compiled in by
default, but the two interfaces aren't compatible.
My biggest goal w/ Mailman has always been to have everything people
would ever want to do be easy to do. That's why I'm pretty reluctant
to distribute without built-in archiving - one thing I hated about
Majordomo was having to go out and download extras and then figure out
how to integrate them to get useful functionality.
I also believe that many people who will want to use Mailman will be
using Python for the first time. The default Python installation is
really easy to build. But as soon as you tell people, "Hey, now you
have to recompile, and install crypt. Oh, and now you have to go
download pipermail. And before you use that, you have to find bsddbm
on the net somewhere, and install it", that's going to send people
running back to the comfort of Perl and Majordomo, even though they'll
be doing the same sorts of things.
To that end, I've put in provisions for passwords to use md5 if crypt
is not found. BTW, do you guys think md5 should be the default, and
crypt an option for those who add it to their config? The only real
advantage of crypt is that it is less space intensive. Also, the way
I have things set up at the moment, if someone starts w/ the default
distribution and later recompiles Python to include crypt, all the old
passwords won't work, since they'll be in the md5 digest format.
Some of the other people here at cnri are using mailman, and they've
hit up against one small change needed. I thought i'd mention it
here, in case anyone gets the chance and inclination to address it. I
also have one other item which i would really like to do, but the
eventuality of actually doing it may be less near than i'd like
(especially since i'm going away for a week, and there's all that
catch-up time on return).
The first item is the ability to edit the new-member welcome message.
We offer list managers the ability to edit the html pages, and they
get to see the way the magic refs (eg, <MM-List-Name>) are used on the
template to see how they could use them for their own versions. Well,
there is a number of standard mail messages, including particularly
the welcome message, that they may want to edit. (IN FACT, two
different groups, separately, came to me today with the need to edit
the welcome message - for different reasons! A sure sign...)
I think we would have to change the format substitutions, currently
all the "%s" order dependent style, to be "%(real_name)s" dictionary
substitutions, and otherwise do the same kind of thing we do for the
html templates. (Ah, i see barry's done that in some recent
checkins.) There is a bunch of messages, some which may benefit from
this treatment, other might just clutter the list admins choices.
Along these lines, there's something much more encompassing i'd like
to do or see done. I'd like to extend the handling of list admin
options and html templates so list-specific versions are only
squirreled away in list-specific space if and when the list admin
changes them from the default. This way, the central administrator
could change the template or default values, and the new value would
show for all the lists that haven't tailored their own versions. This
would certainly be suitable for something like the html pages, where
site style changes need propagation, and also for stuff like the
forbidden posters. It may not be suitable for some others.
This should be easy for the template files - just don't stash
list-specific copies until an edit is made (and the edited copy
differs), and use the default template if no list-specific one
exists. It'd also be good to offer a way in the edit interface to
revert to the default version, wiping out the list-specific copy.
For the list admin options, we'd need a new field in the options data
structure specifying the *name* of the default value, and likewise
some way for the gui option for the list admin to explicitly revert to
the default. Maybe there should be some way to have a locked-in
list-specific setting, even if it doesn't differ from the _current_
site default. And then all the routines that use the list admin
options will have to mediate through a routine (or options mediator
object) that takes the name of the option and gets the default value
Well, i hope this is at least slightly understandable, if quick - i
gotta run. C ya later!
there is a bug in the admin cgi changes that i posted. the block of
code making general list changes fires from some brownsers when you
log on and press enter to submit the data instead of clicking the
the reason is that the code knows to process the login when the
button is pressed because of it's name. that data is not submitted
from some browsers when you submit the form by pressing enter instead
of clicking on the button.
since not much data is submitted, it wipes out a lot of
the list information. bad bad bad!
anyway, the fix is simple enough (against the previous patch and the
substituted isAuthenticted function).
chronis 3:01pm $ cvs diff -r1.4 admin
RCS file: /usr/local/cvsroot/mailman/cgi/admin,v
retrieving revision 1.4
diff -r1.4 admin
< if category != 'members' and not cgi_info.has_key("request_login"):
> if category != 'members' and \
> not cgi_info.has_key("request_login") and \
> len(cgi_info.keys()) > 1:
I installed Scott's patches for confirmation and admin logins (thank
god for ediff-buffers). I have a couple of questions mainly for
Scott, but I think other people might be interested in discussing
First, I don't know what the expiration time for cookies is, but the
cookie didn't go away when I shut down my browser. Do you think
that's good behavior? I'd like to not be implicitly logged in if
someone else starts up my browser. Also, I've seen some sites that
log people off automatically after 15 mins of inactivity on that site.
Do you think that's a good idea?
Second, if you don't have cookies on, changes don't get made. You get
sent back to the login screen, and when you log back in, everything is
the same. Should cookies really be required? Something that could be
done to offer similar functionality yet not require cookies would be
to have an "enter your password" box after the initial login, and put
the password in the proper field as default text. While that may not
be incredibly secure, it's not much worse than sending a plaintext
password via httpd the first time only (although the password will be
in the page source).
Also, perhaps there should be a way to explicitly log out?
I can't get logged out, even by turning off cookies!
I noticed the message about direct smtp delivery being needed for
As I mentioned before, I have a version on mailman 1.0b1 that I am
running that already does this. I am going to give a good shot at
integrating that feature into the current (1.0b3?) source this weekend.
(I want to anyway, as I want to upgrade my server. )
BTW, I also mentioned some user database changes in my variant of
mailman... I'm dropping those, as I don't like the way I implemented them.
I'll just try to incorporate the other features I added to 1.0b1 (smtp
delivery being the biggie) into the current tree, and go from there.
-The Dragon De Monsyne
"John Viega" <viega(a)list.org> wrote:
> It's more efficient than Majordomo, especially when doing bulk mailing.
This may be a naive question, but how can that be?
Majordomo doesn't actually get involved in mail delivery (at least the
versions I've used). It just maintains an address file which is read by
sendmail (or whatever MTA you're using) to do the actual delivery. So what
does it mean to say that majordomo isn't efficient at bulk mailing?
On Thu, May 28, 1998 at 10:29:17PM -0400, Corbett Klempay wrote:
> Does anyone have any quantitative (or maybe even non-quantitative) idea of
> Mailman's performance, especially compared to direct competitors such as
It's more efficient than Majordomo, especially when doing bulk mailing.
> Do we know of any very high volume lists being run on Mailman
How high volume? I know of some lists with 5000+ users, they don't
seem to have any problems. The biggest one I run has been over 2000
> (or is this even a good idea?). I imagine that something like ezmlm would
> probably obliterate both Majordomo as well as Mailman as far as
> performance, but I don't see the average list needing the kind of fiendish
> performance ezmlm provides (don't me wrong; ezmlm has a lot to recommend
> it); most people could (and would) trade ezmlm's speed for Mailman's slick
> web interface. But what I'm wondering is do we know how big this
> performance tradeoff is?
You'd do a lot better performance wise trading sendmail for qmail than
Mailman for ezmlm. Also, within a few months we're going to have an
option to keep mailman as a persistant server, to avoid the costs
involved of always starting up.
> Also, I saw that there was a mention on the TODO list about adding support
> for other MTAs (such as qmail). Has anyone implemented this on their own
> yet? Would providing support for qmail affect (enhance) performance much?
I'm working on this feature as we speak. Like I said, the underlying
mail transport is more important than the MLM software in terms of how
many messages you can push through a machine.
> I'm trying to (seeing how smooth Mailman is) see what kind of potential
> user base there will be; I'm wondering at what point the list becomes too
> speed-critical to allow use of Mailman. Any comments?
Well, I think that the current way the locking is done might cause
some problems on lists that have large, large numbers of users AND get
tons of users. I don't know how large those numbers are yet, but the
big list I run has gotten 100 posts in an hour before, without
The locking is going to eventually become more fine-grained, so even
for the largest lists, I don't think it'll be a problem.
One more small suggestion i got today - list managers should be able
to override the monthly password reminder for their list members.
Some lists are infrequent, announcement only lists, and there can be
enough info in the header/footer about where to find the place to get
their passwords that the password reminder is gratuitous. At least,
that's the opinion of someone who's running such a list...
It looks like having mailman do smtp directly is going to resolve the
problem i was having getting mailman to do "virtual hosting". And
that increases the priority of getting the direct smtp connection in -
i have some people here at cnri who need the capability, not urgently,
but it'd be nice sooner rather than later...
The problem i'm referring to is that mailman does the right thing
sending out messages as if they come from the domain for which the
maillist is configured, but sendmail by default rewrites the addresses
so the maillist address looks like the primary domain for which
sendmail is configured. The consensus was that reconfiguring sendmail
to avoid that would be dirty - it entails rewriting one of the
rulesets, which is fairly-to-very intrusive.
Well, it turns out that this problem does not apply to mail relayed by
direct smtp connections, hooray. That means no special instructions
will be necessary for sendmail (or other mda) configuration, hooray.
Oh, and incidentally, i'm going to be away for the next week and a day
- no new releases, though barry and john may have some nice stuff to
spring on you in the interim.
I'm gone! (Hooray.)