Mailman 3 April 2000 - Mailman-Developers

Re: [Mailman-Developers] features I would like to see
by Murray Jensen 25 Apr '00

25 Apr '00

>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: http://www.msa.cmst.csiro.au/mailman-archives/robot-toolbox/ (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... -- 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)

1 0

2.0beta3
by Dan Mick 25 Apr '00

25 Apr '00

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.

3 2

Re: [Mailman-Developers] features I would like to see
by Brian Edmonds 25 Apr '00

25 Apr '00

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 over first. Brian.

1 0

Fwd: Bug in Mailman version 2.0beta2
by Christopher Kolar 25 Apr '00

25 Apr '00

>Date: Sat, 22 Apr 2000 08:43:23 -0300 >From: Daniel Neto <dneto(a)zaz.com.br> >X-Mailer: The Bat! (v1.41) Educational >Reply-To: Daniel Neto <dneto(a)zaz.com.br> >Organization: Terra Networks - Vitoria (ES) >To: ckolar(a)admin.aurora.edu >Subject: Bug in Mailman version 2.0beta2 >X-Status: > >Hi!, > >Bug in Mailman version 2.0beta2 > >We're sorry, we hit a bug! > >If you would like to help us identify the problem, please email a copy >of this page to the webmaster for this site with a description >of what happened. Thanks! > >Traceback: > >Traceback (innermost last): > File "/home/mailman/scripts/driver", line 89, in run_main > main() > File "../Mailman/Cgi/admin.py", line 68, in main > mlist = MailList.MailList(listname) > File "/home/mailman/Mailman/MailList.py", line 69, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 881, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 912, in CheckVersion > Update(self, stored_state) > File "../Mailman/versions.py", line 52, in Update > NewRequestsDatabase(l) > File "../Mailman/versions.py", line 217, in NewRequestsDatabase > r = getattr(l, 'requests', {}) >TypeError: getattr requires exactly 2 arguments; 3 given > > > > > >Python information: > > Variable Value > sys.version 1.5.1 (#1, Sep 3 1998, 22:51:17) [GCC 2.7.2.3] > sys.executable /usr/bin/python > sys.prefix /usr > sys.exec_prefix /usr > sys.path /usr > sys.platform linux-i386 > >Environment variables: > > Variable Value > DOCUMENT_ROOT /usr/local/etc/httpd/htdocs/ > SERVER_ADDR 200.241.14.12 > HTTP_ACCEPT_ENCODING gzip > REMOTE_HOST operacao01.vix.zaz.com.br > SERVER_PORT 80 > PATH_TRANSLATED /usr/local/etc/httpd/htdocs/operacao > REMOTE_ADDR 200.241.14.132 > SERVER_SOFTWARE Apache/1.3.11 (Unix) PHP/3.0.14 > GATEWAY_INTERFACE CGI/1.1 > HTTP_ACCEPT_LANGUAGE en > REMOTE_PORT 2086 > SERVER_NAME listas.vix.zaz.com.br > HTTP_CONNECTION Keep-Alive > HTTP_USER_AGENT Mozilla/4.72 [en] (Win98; I) > HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 > HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, > image/pjpeg, image/png, */* > REQUEST_URI /mailman/admin > PATH /sbin:/usr/sbin:/bin:/usr/bin > QUERY_STRING > SERVER_PROTOCOL HTTP/1.0 > PATH_INFO / > HTTP_HOST 200.241.14.12 > REQUEST_METHOD GET > SERVER_SIGNATURE Apache/1.3.11 Server at listas.vix.zaz.com.br Port 80 > SCRIPT_NAME /mailman/admin > SERVER_ADMIN sysadm(a)vix.zaz.com.br > SCRIPT_FILENAME /home/mailman/cgi-bin/admin > PYTHONPATH /home/mailman > >=== >Thanks in advance, > > Daniel - dneto(a)zaz.com.br > SysOp / Network Administrator > Terra Networks of Brazil - Vitória/ES > +55-27-334-1475 / 334-1476 / 315-2650 >

3 2

Re: [Mailman-Developers] Making passwords easier for users
by Owen Taylor 24 Apr '00

24 Apr '00

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 actually matter. (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 problem. > 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. Regards, Owen

2 1

features I would like to see
by Brian Edmonds 24 Apr '00

24 Apr '00

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 for overquoting. 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. Brian.

1 0

b2 archiving off?
by Corbett J. Klempay 24 Apr '00

24 Apr '00

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) corbett.klempay(a)trilogy.com

1 0

Re: [Mailman-Developers] Change to acceptable_aliases
by Harald Meland 24 Apr '00

24 Apr '00

[Christopher Lindsey] > 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? -- Harald

2 1

Making passwords easier for users
by Owen Taylor 23 Apr '00

23 Apr '00

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 because they 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 each list. (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. Regards, Owen

2 1

LockFile.py
by Thomas Wouters 22 Apr '00

22 Apr '00

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 list. 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, though. 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!

2 1