Mailman 3 March 2000 - Mailman-Developers

Re: [Mailman-Developers] Mailman password and administrative reminders
by Dan Mick Aug. 14, 2003

Aug. 14, 2003

? This very message came to me with the following header: Errors-To: mailman-developers-admin(a)python.org All my bounces come to the list admin address, set in the admin webpage, in the second field of General Options. Do you have that set to something, and bounces still come to root? > 2. Bounces are sent to the poor postmaster instead of a -admin address. > I'm not entirely certain, but I think an Errors-To: header or something > like that in all Mailman messages might allow one to distribute that load > somewhat.

8 11

Membership management chunking requires two authentications..
by Ted Cabeen July 19, 2000

July 19, 2000

Mailman: 1.1 Python: 1.5.2 OS: Solaris 5.7 I don't know if this has been fixed in the CVS version, but I thought I'd submit it anyways. There seems to be a small authentication bug with the chunking in the membership management page. The page will load up correctly the first time it is accessed with the first chunk size shown. However, when you request a different chunk, it requires a reauthentication and then gives the chunk=0 page instead of the requested chunk. If you then click on the alternate chunk it loads fine. However, the additional click and authentication is annoying. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen(a)pobox.com Check Website or finger for PGP Public Key secabeen(a)midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen(a)aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626(a)compuserve.com

3 4

Re-tries for failed SMTPDirect deliveries
by Barry A. Warsaw June 1, 2000

June 1, 2000

Last night, I added some code to queue messages that fail delivery when using SMTPDirect. What happens is this: If a message either totally fails delivery (e.g. the smtp socket connect fails) or partial delivery fails for some, but not all, recipients, then the message is stored on the file system for a re-try later. For every failed message, two files are created. The base name of these files is the SHA hexdigest dump of the message text. This should be nearly guaranteed unique. A new directory contains these files, called `qfiles'. The first file created is the complete plain text of the failed message. The second file is a marshal of useful information related to the failed delivery. This contains the listname and the failed recip list along with a few other moderately useful bits of info. There's a new cron script called `qrunner' which cruise the files in qfiles. It claims a lock (to prevent multiple qrunner processes) and then goes through each file it finds, attempting redelivery. If there are any problems reading a qfile file, it skips it for next time (assumes it's a transient problem with the file, but logs a message). When qrunner notices that the message has been handed off the the smtp daemon for all outstanding recipients, it deletes the two message files. I've moderately tested this stuff with total delivery failure by shutting off my smtp daemon, attempting some deliveries, turning it back on and running qrunner. I don't have the time right now to test partial delivery failures, but I still claim that without DSN support, these will be unlikely. Hopefully some of you can help look at this. I'm about to check all this stuff in. Let me know what you think. -Barry

3 9

pipermail/hypermail mbox-archive
by Thomas Wouters June 1, 2000

June 1, 2000

There was a short discussion a month or so ago about the hyperarch 'mbox' archives having the wrong kind of date in the 'From ' lines... 'unixfrom' lines should have a very specific dateformat, namely that which 'time.ctime' returns. The following patch fixes Archiver/HyperArch.py. However, I'm not entirely sure if it will work correctly in other locales... can anyone test that, and propose a locale-independant way of producing this format ? Grtz, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 3

Re: [Mailman-Developers] race condition in locking ?
by Harald Meland May 2, 2000

May 2, 2000

[Thomas Wouters] > On Mon, Feb 07, 2000 at 09:31:44PM +0100, Ricardo Kustner wrote: > > > I wonder though what happens if some impatient moderator decides not to > > wait before the page finnishes loading, switches to a differen webpage and > > therefor breaks the python cgi process... will some approved posts stay in > > the queue instead? > > Try it out ! ;) It depends on the exact behaviour of both the > webbrowser and the webserver. Yup. This might produce a SIGPIPE, and/or the corresponding IOError EPIPE, and I've experienced that these didn't always get caught -- an attempt at a fix is near the end of run_main in <URL: http://www.uio.no/~hmeland/tmp/mailman-userdb/scripts/driver>, but I'm by no means positive that it's the Right fix. -- Harald

2 1

Bouncers/Exim.py
by Jim Tittsler April 10, 2000

April 10, 2000

Exim adds a header to bounce messages that might be used to catch the bounced addresses, rather than trying to parse the message text. I've been using this trivial bouncer for a while with my 1.2CVS installation and it seems to be doing the right thing. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/

2 1

Re: [Mailman-Developers] race condition in locking ?
by Harald Meland April 7, 2000

April 7, 2000

[Thomas Wouters] > On Mon, Feb 07, 2000 at 10:01:36PM +0100, Harald Meland wrote: > > > My current CVS checkout is available ("live" :) under <URL: > > http://www.uio.no/~hmeland/tmp/mailman-userdb/>, with <URL: > > http://www.uio.no/~hmeland/tmp/mailman-userdb/Mailman/LockFile.py> > > being of special interest in this discussion... > > Ah, very cool. You'll find my current version of LockFile.py > attached, for reference, as you asked. Thanks, I've skimmed through most of it now. > I think the link() solutions, as opposed to the rename() solution, > is a better one, if you'll premit me. Sure :) > For one, you can check on lock ownership by statting your own > lockfile, which should only be touched by you, instead of reading a > possibly highly volatile lockfile. You can also doublecheck the > lockfile inode, see if it is equal to your own lockfiles' inode, to > confirm that you have the lock. ... the downside being that if, e.g., anyone tries to read the info in the lockfile in the middle of a refresh(), they'll get a ValueError -- which your module seems to take care of, but it all looks a bit convoluted to my eyes. I especially dislike that lock() has to call locked() _after_ the check on ST_NLINK, because further down in lock() there's code that might break a lock it really shouldn't (if it weren't for the nonatomic-write-of-lock-contents issue). I also see some bugs that are fixed in my module but still present in yours, but those are rather irrelevant to this discussion (as they can easily be ported to your module if that's the one we'll go for). Does anyone but Thomas and me have any opinions on which locking scheme is preferrable? I guess I don't have any very strong feelings about the issue ;), so any sagely advise on the matter would be welcome. [ I've tried to model my version of the module as closely as possible after the way Exim does its lockfile locking, the idea being that Exim really should have been around long enough to have solved these things correctly. Reading the longish comment from ca. line 1206 and onwards in src/transports/appendfile.c of the Exim distribution proved very helpful to me. Of course, when it comes to lock stealing and other ugly (but needed, I guess) stuff, Exim couldn't provide much help. ] > Ah, well, I couldn't find any parts of Mailman in the CVS tree that > acually _called_ steal, so I couldn't figure out what it should do > in borderline cases. The only place I know of is cron/gate_news. > However, reading your LockFile.py made me realise how to steal the > lock. LockFile.steal() now does its utmost best to steal the lock, > only failing if someone else is busy stealing the lock from us. It > returns 1 for success, 0 for failure, mostly because I wanted it to > signify that in some way. ... but the caller should note that steal() returning 1 does not necessarily imply that it is the owner of the lock (anymore). The steal() stuff is bound to be full of race conditions, AFAICT -- so whether it returns anything doesn't really matter (IMHO), as the return code truly can't be trusted anyway. Cheers, -- Harald

2 1

Re: [Mailman-Developers] cron/gate_news watermark == 0
by Harald Meland April 7, 2000

April 7, 2000

[Jim Tittsler] > A watermark value of 0 is used for two different purposes in cron/gate_news: > 1. the group has never been gatewayed, so "catch up" to the highest article > number > 2. the highest article number seen for the group is 0 (which can be a valid > "high article number" before the first posting in a newly created > newsgroup) > The result of this is the first article posted to the newly created newsgroup > fails to get gatewayed to the mailing list because the watermark for that > group is (still) 0 which is used as a flag to "catch up" so all that happens > is the watermark gets set to 1. > > I believe I have fixed that in my copy by using the value None for the first > time a group is gatewayed, allowing proper processing when the watermark is > truly article number 0. Hmmmm... When checking the contents of my "data/gate_watermarks" marshal, I find several old mailing lists with an entry stating that their watermark is 0 -- even though these lists aren't actually gating any newsgroups. As all these lists are rather old, I guess this could be how things were stored in some early Mailman version -- back when gate_news were forking processes to gate _all_ lists, regardless of whether the list in question had requested that any gating should be done, and the watermark file was written to by each and every child... On checking this with CVS, it appears that revision 1.7 of gate_news indeed has the behaviour I suspected, while 1.8, which was checked in 1998/12/18 00:22:23, seems to do it "right". The upshot of this is that any list touch by rev. 1.7 (and maybe earlier) which do not do any gating would possibly get *all* the messages present in the group it's gating from posted to it if it started gating after your patch was applied. A possible way to approach all this would be to have "make update" replace those 0 values in gate_watermarks with None values iff there are no other None values (i.e. only change things on the first time "make update" is run). Or, even better, move the per-list watermark info from gate_watermarks into the list's config.db, replacing any 0 values in gate_watermarks with None values in config.db. This has the advantage of reducing the number of different files that would have to be changed when cloning/renaming a list. -- Harald

3 2

check_perms bug?...
by Dan Mick April 5, 2000

April 5, 2000

Somehow, my /home/mailman/lists directory managed to get set with permissions check_perms didn't check for; it was set to d-wx-ws--x/mailman/mailman, which caused mailcmd to be unable to list the directory (no read perms). I fixed it once I figured it out, but I had a lot of check_perms runs in there before I finally figured it out...mostly because I was confused about what 'x' really means on a directory. But check_perms could have saved me time if it had checked for 'owner-and-group-read'; I think it should.

2 1

suggestion
by Ricardo Kustner March 31, 2000

March 31, 2000

Hi, How about moving things like the list welcome message, headers, footers and other multiple line texts out of the database and into seperate text files? And treat/edit them in the same way as the html templates... this would it also make it easier to edit them directly. I remember having a lot of difficulties (when I started using mailman about a year ago) with creating the welcome message because the textarea was too small and strange things happened when i cut/pasted it into the textarea with Netscape on Linux (I had to boot windows just to be able to enter the welcome message properly ;) ) Ricardo. --

3 3