>Right, more features I'd like. :)
OK, since we're doing this :-) I would also like the following:
1. the built-in pipermail archive stuff to handle MIME multipart better.
e.g. in the web pages, store non-text MIME parts in separate files,
preferably in a sub-directory. These files can then be excluded from
any indexing for a search facility.
2. a nicer web interface to the web archive e.g. a frames based approach
so that you can keep the index in one frame and display the messages in
another (makes navigating the archive easier)
3. a built-in search function for the web archive
For an example of what I'd like, see:
(hopefully I got the permissions correct - also, the neighbourhood stuff in
webglimpse doesn't work). To do this, I had to ditch the pipermail stuff and
use mhonarc, with a contributed mhonarc frames config. The webglimpse stuff
could be used with pipermail, but I don't like webglimpse's licencing model.
I think it is too restrictive for something that is relatively simple (and
could be implemented in pipermail fairly easily). Cheers!
Murray Jensen, CSIRO Manufacturing Sci & Tech, Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen(a)cmst.csiro.au (old address was mjj(a)mlb.dmt.csiro.au)
Any estimate of release date? I'll probably be setting up another
server this weekend, and I'd like to do it with the latest stuff,
but slightly less volatile than CVS if possible.
Also, Barry or whoever, I think you should include Bernhard
Reiter's patch for the missing From line in the archives
ASAP; that's a high-visibility bug that I'm glad I haven't
installed 2.0beta yet to experience.
Right, more features I'd like. :)
1. A bounced status, in addition to nomail. On my Majordomo install I
have a list called bounces, and a script to automagically unsub
people from a list and resub them to bounces. Every address on the
bounces list gets a daily reminder that they have been unsubscribed
due to mail bouncing.
In addition we would then need a new cron job to mail all addresses
set to bounced status with a notice, and to automatically dun out any
addresses that have remained as bounced for a period that is
configurable on a per-list basis. Then it could also be added as an
option to the auto bounce handling to have addresses switched to
bounced instead of just disabled.
2. I've also modified my bounce script to by default switch users from
the main list to the digest first, if one exists. This would also be
a nice option for bouncing mail, so that users with shorter term
problems, such as quota, could get for example five days grace, then
bounced to the digest for a further five days, then set to bounced
state for a week then unsubscribed. Moving them to digest state can
keep them on the list but reduce server load for busy lists.
3. When handling submissions that are held for admin approval it would
be handy to have another option to MIME encapsulate the message and
mail it to the list admin. That way I could make simple formatting
changes or add admin comments to the occasional message and remail it
myself instead of simply having to reject it.
4. Are the web pages setting no-cache appropriately? It could just be a
bad interaction with my proxy or Netscape cache settings, but the
admin pages are being cached which means I have to hit reload quite
often to make sure I'm getting the latest list settings, or I end up
submitting old data. Having the archives be cacheable makes sense,
and people can reload as needed, but the admin and subscriber config
pages should definitely be no-cache.
I hope this sparks some discussion, and some creative juices in the
developers. :) I'd start submitting patches of my own, but I'm a perl
programmer, not python, so I've got a bit of a learning curve to get
Jim Hebert <jhebert(a)compu-aid.com> writes:
> On 23 Apr 2000, Owen Taylor wrote:
> > The other password related modification I was thinking of doing
> > locally here is a little bit more radical - making it so that all
> > passwords for a given email address are interchangable. Quite a few
> [I am not a mailman developer. If I shouldn't be posting my .02, someone
> please thwap me with the clue paddle...]
Its fine with me. Of course, I'm not a mailman developer either. ;-)
> This change has the effect of reducing the strength of the passwords: if I
> am on 15 lists with 15 different passwords, a dictionary attack against
> any of them is 15 times more likely to succeed and brings me 15 times more
> access for having broken it.
> OTOH, if you keep all your list passwords the same, the success
> probability is unchanged versus one list membership, but the latter
> observation that you get 15x the access is still true, so it's somewhat of
> a red herring.
Exactly. It significantly weakens the strength if the user is using
the randomly chosen Mailman passwords, but not otherwise. Unfortunately,
the passwords Mailman chooses are weak enough that this might
(4 randomly chosen upper or lower case letters - so the mean time for
brute forcing one password is about 3.5 million tries. Weakening this
by a factor of 10 would make it conceivable that someone could try
it. On the other hand, if someone posts the form 350,000 times in a
row, it probably will create a lot of other problems for a server.)
> Also, I don't know how much of a threat scenario this is, but if I can
> subscribe otaylor(a)redhat.com to some other list on the machine with a
> password of my choosing, I have the equivalent access of having otaylor's
> actual password(s) for the other lists. There are at least some sites
> where there isn't mutual trust among the list-owners.
Well, if you have list owners who are being actively malicious to that
extent... but yes, I could see where some people might consider it a
> That said, admittedly, the security of ones list subscriptions aren't
> exactly the crown jewels. And people probably aren't exactly
> seeing massive dictionary attacks against their mailman
> installations... If this was a configurable thing for the paranoid (me?)
> defaulting to the current behavior I guess it couldn't hurt, eh?
My basic feeling about this change is that it is pretty hacky,
and does weaken security a little bit. But many mailing lists
get along without any password protection system at all ... and
the tradeoff for users is:
- the inconvenience of someone, just possibly, doing something
bad to their list subscriptions.
- the inconvenience of juggling a big pile of passwords.
So, I'll probably try implementing sometime when I have some time
(hah!) and see how it works out. I wouldn't suggest this as the
default, certainly. Though I would hope that people are thinking about
how Mailman could be migrated to one-password-for-user.
I'm a longtime Majordomo admin, and just installed Mailman. It looks
good enough that I'm in the process of migrating most/all of my lists to
it, but there are still some features I'd like to see:
1. In addition to digesting by size and daily, digesting by delay. I've
hacked my Majordomo install to send daily digests, but only if more
than 24 hours had elapsed since the first post that would be in the
digest. This way busy lists that digest through the day based on
size never get a stubby daily digest (or no digest for long periods
if they suddenly go low traffic and are on size digesting only). Low
volume lists typically digest every other day. The delay time should
be configurable on a per-list basis, of course.
2. Taboo body matches. The taboo headers are nice, but I also like to
check if the list's .sig is included in the message as a heuristic
3. When handling non-member submission bounces for subscribers sending
from alternate addresses it would be very nice to have a checkbox
that in addition to approving the message will subscribe the address
with the nomail option set.
It would also be nice if the subscription could somehow include a
comment that this is an alternate address, and even better if an
unsubscribe of the primary address would unsub the alternates. And
an appropriate comment in the monthly password reminder for records
of this sort (or perhaps not mailing them for alternates, just
mentioning the alternate addresses in the main mailing).
Adding alternate addresses to subscriber records would be an even
better way to implement the feature, but may be harder, and the
automated nomail subscription would be nice in the near term if
alternate addresses would be a long-term feature.
I'm sure there will be more, but those are the main ones that have come
up so far.
Any suggestions on what I should look at for this: apparently all of our
lists that have archiving on and are private have not had the archives
updated since February. (?) I just upgraded to 2.0b2 2-3 weeks ago.
Corbett J. Klempay
Trilogy Software, Inc.
512.532.5176 (W) | 512.750.1372 (C)
> About a year ago I sent out a proposal to the list about this that I
> think might still have some merit. Rather than doing regular
> expression matching, why not do regex plus substitution?
I think this would complicate the interface quite a lot, while still
not buying us much more functionality.
If we're going to complicate this interface further, why not go
straight for some full-fledged ACL-like stuff?
We recently switched over the GNOME mailing lists to
Mailman, and it was a quite easy transition. So far,
everything is working nicely.
The most common problem problem that people seem to have
is password management. Quite a few people try to
unsubscribe without a password, and when they get an
error message back, resort to mailing the mail admin
address and asking the owner to do it.
And in fact, none of the mail help text makes any reference
about how one can find out ones password. I could
add a pointer to the how to do it via the web in the
help text, but it seems simpler to simply mail out
a password reminder when a users command fails
a) didn't include a password
b) included the wrong password
(The password could even be put directly into the response
if the address that the request comes from is the same
as the address the command pertained to.)
However, since this idea seems pretty obvious to me, and
yet it isn't already, I thought I would ask if there
is any reason I'm missing why it should not be done,
before I went off and did it.
The other password related modification I was thinking of doing
locally here is a little bit more radical - making it so that all
passwords for a given email address are interchangable. Quite a few
people are subscribed to 10-15 different gnome.org mailing lists, and
when they were moved over, they were assigned a different password for
(If I had planned it better, I would have written a custom
add_members script so that people, at least initially,
would have the same password for each list.)
Of course, IMO, the best thing would be to have just a single
password per user, but making the passwords for each list
interchangeable is a good step in the right direction.
Again, I'd like opinions about whether this is just a bad
idea or not.
A couple of months ago I posted about a few bugs in the Mailman locking
mechanism, most notably that it was using the link() lock method the wrong
way 'round ;) but also some symtomps of this problem: failed locks, broken
locks, very long pauses between locks and unlocks, and a generally high load
on the machine while multiple mailmans were trying to get the lock. I could
trigger this behaviour by sending 10+ messages at the same time to the same
I wrote a slightly better version, and Harald came up and showed me his ;)
Harald's LockFile.py (from his CVS tree) had the link() call the right way
'round, but had some other strange quirks that I disagreed with. So I kept
my version around, and rewrote it some more, using ideas from Haralds'
version, to make it more robust. The result is attached ;)
The 'textbook' example of NFS-compatible locking uses the link() call to
create a (hard) link between the lockfile and a private file (private to the
locking process) and determines wether or not the lock succeeded by
stat()ing the private file and checking that the number of links to the file
is 2. It's done this way because a lot of operations are not atomic, on NFS
filesystems, but the link()/stat() method is (or is supposed to be.)
The current mailman implementation is reversed, somehow. It makes a link
from the lockfile to a private file, and checks the number of links to the
lockfile. If the number of links is not 2, it assumes the lock failed, and
tries to read the contents. If the contents are invalid, or timed out (and
the pid hasn't changed since last time it was checked) the lock gets broken.
If a lock succeeds, the locker writes it's pid, it's private lockfile and
the release time into the file.
The problem is that if many mailmans are locking at the same time, the time
between the link() call, the stat() call and the unlink() call, can easily
be enough for several other processes to execute the link(), thus ending
with a lot of links. Worse, all locking processes use the exact same
sleep_interval, so this condition is likely to continue. Also, there is
enough delay between locking the file and filling it with data, for another
process to discover the file is empty, and remove it. Lastly, the cycle of
lock & test is fairly intensive, and the sleep time not high enough to give
other processes the chance to relinquish the lock.
Though I describe it in nasty terms, it isn't readily apparent in normal
situations :-) I have to stress the list quite a bit to detect these issues,
but the machine I run mailman on can be pretty loaded, and i did see these
effects in the occasional burst of natural traffic.
Harald's LockFile, from his CVS tree, is a lot better -- the locking works
fine, but there are other issues that are not that pretty: refresh() is
tricky, can lose the lock in fact. The same goes for steal(). And the
__try_steal() method is especially nasty: it rename()s its private lockfile
to the lockfile, overwriting any lockfile there, waits for 3*sleep_interval,
and checks to see if anyone else overwrote the lock.
My LockFile jumps through some hoops to do some things as safely as
possible, and it still fails a bit in some places, but it looks a lot safer
than the other two lockfiles. It's also a bit more load-friendly, in that it
only examines the lockfile every 10th (or thereabouts) iteration. This
should be more than enough for normal purposes, and it allows the lock-loop
to be as light as possible, allowing more time for the actual locking
process (if any) to finish its work and unlock ;) And the time the lock()
process sleeps is slightly randomized, to prevent perfectly in-stride
behaviour. (+/- .32 seconds)
I kept the old 'contents of lockfile' trick in place, eventhough I'm not
sure if it's really that useful: the whole problem with locking over NFS is
that you *can't* rely on the contents of a file. So I'm not convinced the
current behaviour (remove the lock if the contents is invalid) is the
correct one. I see how the contents are convenient, especially the timeout
time, but I'm thinking that when a file is empty or invalid, the timeout
should be taken as the MTIME of the file + the default locktime. This should
catch most stale files right away, and prevent a lot of race conditions in
locking/refreshing/stealing/breaking locks. I haven't implemented that yet,
Attached is LockFile.py. I'm using it in production currently, and it seems
to work fine. I dont have code that actually uses steal(), but i tested it
by hand, and it seems to work ok too. There is only one issue with steal:
should it return NotLockedError some such when stealing fails, or return 0,
or keep on trying ?
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!