From mrbill@mrbill.net Mon Apr 1 04:56:15 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Sun, 31 Mar 2002 22:56:15 -0600 Subject: [Mailman-Developers] Changing URLs in 2.1? Message-ID: <20020401045615.GN24171@mrbill.net> Anybody know how to change a 2.1 setup so that all the URLs on the admin/user web pages point to, say, /mailman2/ instead of /mailman? I'm trying to run a 2.1 install alongside a 2.0.8 install (to do testing), and all the URLs keep pointing back to stuff that doesent *exist* under /mailman. I've got the web aliases setup to go to /mailman2... Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From barry@zope.com Mon Apr 1 18:03:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 1 Apr 2002 13:03:23 -0500 Subject: [Mailman-Developers] Changing URLs in 2.1? References: <20020401045615.GN24171@mrbill.net> Message-ID: <15528.41195.590306.404010@anthem.wooz.org> >>>>> "BB" == Bill Bradford writes: BB> Anybody know how to change a 2.1 setup so that all the URLs on BB> the admin/user web pages point to, say, /mailman2/ instead of BB> /mailman? I'm trying to run a 2.1 install alongside a 2.0.8 BB> install (to do testing), and all the URLs keep pointing back BB> to stuff that doesent *exist* under /mailman. bin/fix_url.py -Barry From barry@zope.com Mon Apr 1 19:08:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 1 Apr 2002 14:08:19 -0500 Subject: [Mailman-Developers] admindb References: <5.1.0.14.2.20020329230006.00a0a9b0@mail.vt.edu> Message-ID: <15528.45091.34181.399517@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> When selecting the "forward to" option (and leaving it RJ> otherwise deferred) I get this: Should be fixed now, thanks. -Barry From chuqui@plaidworks.com Tue Apr 2 21:39:06 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 02 Apr 2002 13:39:06 -0800 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) Message-ID: I've just identified a pretty bad bug in mailman 2.0.x qrunner. It can cause messages to get lost, so, I almost hate to say this, Barry, but it might be time for a quick 2.0.9 patch. Given the changes to queuing in 2.1, I think this bug isn't relevant to the 2.1 tree. If you're hit by the bug, you'll see occasional reports in the error log like: Apr 02 06:48:03 2002 qrunner(12168): Traceback (most recent call last): Apr 02 06:48:03 2002 qrunner(12168): File "/export/home/mailman/cron/qrunner", line 282, in ? Apr 02 06:48:03 2002 qrunner(12168): kids = main(lock) Apr 02 06:48:03 2002 qrunner(12168): File "/export/home/mailman/cron/qrunner", line 202, in main Apr 02 06:48:03 2002 qrunner(12168): os.unlink(root+'.db') Apr 02 06:48:03 2002 qrunner(12168): OSError : [Errno 2] No such file or direct ory: '/export/home/mailman/qfiles/74a651f8eba5fce7ca800968bcd105b0bddb0c96.db' Apr 02 06:48:24 2002 admin(12193): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Here's the failure scenario. It can happen to any mailman system, because it's a timing hole, but a busy system will be more susceptible because of the number of files being created in qfiles. Qrunner, as it processes, opens the qfiles directory inode and walks it until it runs out of files (or times out) and exits. It starts at the top and simply goes to the end. That's why 2.0.x isn't FIFO through the queue, processing is based on location within the directory inode. The problem is when "wrapper post" is writing into qfile at the same time qrunner is processing and deleting. If qrunner hits a message AS IT IS BEING WRITTEN by "wrapper post", bad things can start happening. Scripts/post writes the .db file, then the message file. IF it happens to write the .db file into qfiles, and then qrunner tries to process it, qrunner will see no .msg, declare it orphaned, and delete it. Post then writes the .msg file, closes the .db file, and since qrunner unlinked it, the .db file then gets removed. You then get left with an orphaned .msg file. Unfortunately, qrunner and post don't lock each other off files, and sort of by definition, you can't have one lock the other out of the directory during processing. But that leaves this tiny window where they can get really confused, and bad things happen. You end up with messages that are accepted by post, and then disappear forever. I'm seeing this about once a day on my big server now, simply because of the message volumes. There are a couple of ways to fix this in the source. The "right" way would be to put file locking into post and qrunner, so qrunner can tell that post has the file open and skip it. Given that the queueing is being completely redone in 2.1, I'd suggest a second fix. In cron/qrunner, about 200 where the check for the missing file is, put in a quick check of the creation time for the file. If it's less than 5 minutes old, simply leave it alone and don't unlink it. Because it'll go and check again next trip through, it'll unlink real orphans, but it protects you from this tiny window of oopsie. Normally, I'd say "on to 2.1", but since this is a fairly serious "silent data loss" bug AND the fix is trivial, I think it might make sense to patch this and roll 2.0.9. At the least, I think a patch needs to be approved by Barry and released and made visible on the lists.org website. Please don't ask me how I found this. I'd have to kill you. But this is one of the more obscure bugs I've ever found... (grin) The window of opportunity to trigger it is immensely small. You need two programs to be simultaneously updating the same directory inode, and processing the same slot IN that inode, at the exact same time. We're talking about a latency of, as far as I can tell, 5-15 milliseconds every time post writes a message into qfile, but only if qrunner is actively processing. It looks like Barry took care (from reading the source) to avoid this kind of situation -- but didn't quite lock the window closed. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From db@bibsys.no Tue Apr 2 22:01:52 2002 From: db@bibsys.no (Daniel Buchmann) Date: Wed, 03 Apr 2002 00:01:52 +0200 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: Message-ID: <3CAA2A50.474B2F6A@bibsys.no> Chuq Von Rospach wrote: > > I've just identified a pretty bad bug in mailman 2.0.x qrunner. It can Just wanted to confirm this bug. My server is not exactly high-volume, but I now discovered I have gotten this error ONCE on ONE list since August 2001. :) January 13th, the following happened: logs/error: Jan 13 23:46:02 2002 qrunner(23874): Traceback (most recent call last): Jan 13 23:46:02 2002 qrunner(23874): File "/home/mailman/cron/qrunner", line 282, in ? Jan 13 23:46:02 2002 qrunner(23874): kids = main(lock) Jan 13 23:46:02 2002 qrunner(23874): File "/home/mailman/cron/qrunner", line 202, in main Jan 13 23:46:03 2002 qrunner(23874): os.unlink(root+'.db') Jan 13 23:46:03 2002 qrunner(23874): OSError : [Errno 2] No such file or directory: '/home/mailman/qfiles/9fbaa916ea7f515e789a4928559e872f65b54d1f.db' logs/qrunner: Jan 13 23:46:02 2002 (23874) Unlinking orphaned .db file: /home/mailman/qfiles/9fbaa916ea7f515e789a4928559e872f65b54d1f.db logs/smtp: smtp:Jan 13 23:46:01 2002 (23874) smtp for 1 recips, completed in 0.724 seconds smtp:Jan 13 23:46:02 2002 (23874) smtp for 1 recips, completed in 0.513 seconds smtp:Jan 13 23:46:02 2002 (23874) smtp for 1 recips, completed in 0.709 seconds ---- Daniel, the norwegian dude. :D From rob@web.ca Tue Apr 2 22:23:35 2002 From: rob@web.ca (Rob Ellis) Date: Tue, 2 Apr 2002 17:23:35 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: References: Message-ID: <20020402222335.GD541@web.ca> > Apr 02 06:48:03 2002 qrunner(12168): os.unlink(root+'.db') > Apr 02 06:48:03 2002 qrunner(12168): OSError : [Errno 2] No such file or See Barry's recent response to my posting about 'qrunner on solaris' -- he's got a patch, was looking for testers... - Rob -- Rob Ellis System Administrator, Web Networks From marc_news@vasoftware.com Tue Apr 2 22:27:45 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 2 Apr 2002 14:27:45 -0800 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: References: Message-ID: <20020402222745.GJ21237@merlins.org> On Tue, Apr 02, 2002 at 01:39:06PM -0800, Chuq Von Rospach wrote: > > I've just identified a pretty bad bug in mailman 2.0.x qrunner. It can cause > messages to get lost, so, I almost hate to say this, Barry, but it might be > time for a quick 2.0.9 patch. Given the changes to queuing in 2.1, I think > this bug isn't relevant to the 2.1 tree. > > If you're hit by the bug, you'll see occasional reports in the error log > like: Just to confirm that you're not crazy, I've seen this on sf.net too. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Tue Apr 2 22:45:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Apr 2002 17:45:19 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: Message-ID: <15530.13439.157474.132996@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> I've just identified a pretty bad bug in mailman 2.0.x CVR> qrunner. It can cause messages to get lost, so, I almost hate CVR> to say this, Barry, but it might be time for a quick 2.0.9 CVR> patch. Given the changes to queuing in 2.1, I think this bug CVR> isn't relevant to the 2.1 tree. You know, I think I just fixed this on Friday, although I didn't get a chance to check everything into cvs before the holiday weekend. I definitely didn't get a chance to test it. It is a valid bug, and it does warrant a 2.0.9 patch. The basic bug is caused by a disagreement on the order of .db and .msg file writing between qrunner and Message.Enqueue(), as Chuq rightly observes. I think the fix is simpler than what Chuq outlines, though. Message.Enqueue() breaks the race by writing the .db file before it writes the .msg file, but qrunner's logic is backwards! It ignores the .msg files but it should be ignoring the .db files, since they're written first. The fix is to qrunner, which should ignore .db files, triggering only on .msg files. If it finds a .msg file without a corresponding .db file, then it should unlink the orphaned .msg file. The final piece of the puzzle is that Message.Enqueue() should write the .msg file atomically, meaning, write it to a tmp file and use rename() to move it into place atomically. CVR> Normally, I'd say "on to 2.1", but since this is a fairly CVR> serious "silent data loss" bug AND the fix is trivial, I CVR> think it might make sense to patch this and roll 2.0.9. At CVR> the least, I think a patch needs to be approved by Barry and CVR> released and made visible on the lists.org website. Everything's checked into cvs now, and I'm about to do some testing. The more eyeballs on this code, the better, since it is so integral to the proper operation of the system. After some off-line stress testing, I'll foist this patch on python.org, watch the logs for a day or two, and then do the 2.0.9 release. CVR> Please don't ask me how I found this. I'd have to kill CVR> you. But this is one of the more obscure bugs I've ever CVR> found... (grin) Indeed. While I've seen the occasional reports of this for a while, it's nearly impossible to reproduce, and even with the traffic we see on python.org/zope.org, I've /never/ seen it there. CVR> The window of opportunity to trigger it is immensely CVR> small. You need two programs to be simultaneously updating CVR> the same directory inode, and processing the same slot IN CVR> that inode, at the exact same time. We're talking about a CVR> latency of, as far as I can tell, 5-15 milliseconds every CVR> time post writes a message into qfile, but only if qrunner is CVR> actively processing. It looks like Barry took care (from CVR> reading the source) to avoid this kind of situation -- but CVR> didn't quite lock the window closed. Unless I still haven't recovered from Maryland's glorious and long-awaited victory last night[*], I'm surprised this one snuck past us for so long. It jumped right out at me when I reviewed the code again. Sigh. Fearing-the-turtle-ly y'rs, -Barry [*] NCAA (college) men's basketball national champs. From bob@nleaudio.com Tue Apr 2 23:12:30 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Tue, 02 Apr 2002 18:12:30 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: Message-ID: <3CAA3ADE.E9C2600B@nleaudio.com> Actually, I think I've seen two of these on my system as well, which I'm sure isn't nearly as busy as yours, Chuq, but I've been known on occasion to have quite a pileup! Bob > I've just identified a pretty bad bug in mailman 2.0.x qrunner. It can cause > messages to get lost, so, I almost hate to say this, Barry, but it might be > time for a quick 2.0.9 patch. Given the changes to queuing in 2.1, I think > this bug isn't relevant to the 2.1 tree. > From nb@thinkcoach.com Tue Apr 2 22:05:28 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Wed, 3 Apr 2002 00:05:28 +0200 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: (message from Chuq Von Rospach on Tue, 02 Apr 2002 13:39:06 -0800) References: Message-ID: <200204022205.g32M5So03066@quill.local> Chuq Von Rospach wrote: > The problem is when "wrapper post" is writing into qfile at the same time > qrunner is processing and deleting. [..] > Normally, I'd say "on to 2.1", but since this is a fairly serious "silent > data loss" bug AND the fix is trivial, I think it might make sense to patch > this and roll 2.0.9. I think that like security bugs, potential data loss bugs also justify a bugfix maintenance release. At the same time, if 2.0.9 is rolled out anyway, I'd suggest to put in that little patch to insert a Date: header. (You see the missing Date: header bug only if you run a MTA like Qmail which doesn't add missing Date: headers on its own.) Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From chuqui@plaidworks.com Tue Apr 2 23:22:08 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 02 Apr 2002 15:22:08 -0800 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <200204022205.g32M5So03066@quill.local> Message-ID: On 4/2/02 2:05 PM, "Norbert Bollow" wrote: > At the same time, if 2.0.9 is rolled out anyway, I'd suggest > to put in that little patch to insert a Date: header. The other thing I've noticed about qrunner is it doesn't reap it's children reliably (or at all, I'm not sure). So if you have a busy mailman system, it tends to collect zombie processes. This could create resource issues for some sites that are living a bit on the edge. And once qrunner exits, they all magically disappear... If we're rolling changes into 2.0.9, here's another one that ought to be considered, although again, it's mostly a big/b usy system issue. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From barry@zope.com Tue Apr 2 23:46:53 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Apr 2002 18:46:53 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <200204022205.g32M5So03066@quill.local> Message-ID: <15530.17133.234375.563306@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> The other thing I've noticed about qrunner is it doesn't reap CVR> it's children reliably (or at all, I'm not sure). So if you CVR> have a busy mailman system, it tends to collect zombie CVR> processes. This could create resource issues for some sites CVR> that are living a bit on the edge. And once qrunner exits, CVR> they all magically disappear... If we're rolling changes into CVR> 2.0.9, here's another one that ought to be considered, CVR> although again, it's mostly a big/b usy system issue. But there shouldn't /be/ any children. The only code that calls fork() in 2.0.x is the mail->news gateway (ignore the test code in LockFile.py). Are you running any gated lists Chuq? -Barry From barry@zope.com Wed Apr 3 02:26:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Apr 2002 21:26:39 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <200204022205.g32M5So03066@quill.local> Message-ID: <15530.26719.774924.373177@anthem.wooz.org> >>>>> "NB" == Norbert Bollow writes: NB> At the same time, if 2.0.9 is rolled out anyway, I'd suggest NB> to put in that little patch to insert a Date: header. (You NB> see the missing Date: header bug only if you run a MTA like NB> Qmail which doesn't add missing Date: headers on its own.) Hmm, can't Qmail be taught to add the Date: header if it's missing, like every other MTA I'm aware of? -Barry From mrbill@mrbill.net Wed Apr 3 03:30:24 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Tue, 2 Apr 2002 21:30:24 -0600 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <3CAA2A50.474B2F6A@bibsys.no> References: <3CAA2A50.474B2F6A@bibsys.no> Message-ID: <20020403033024.GW24171@mrbill.net> On Wed, Apr 03, 2002 at 12:01:52AM +0200, Daniel Buchmann wrote: > Chuq Von Rospach wrote: > > I've just identified a pretty bad bug in mailman 2.0.x qrunner. It can > Just wanted to confirm this bug. My server is not exactly high-volume, but > I now > discovered I have gotten this error ONCE on ONE list since August 2001. :) Since Dec. 5th, on my machine (about 500-900meg of outgoing mail/day): bash-2.03$ grep os.unlink error |wc -l 82 Solaris 8/mailman 2.0.8/Postfix here. Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From jarrell@vt.edu Wed Apr 3 03:32:44 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 02 Apr 2002 22:32:44 -0500 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> References: <15522.8527.761356.749127@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020402223136.024d8a90@lennier.cc.vt.edu> At 01:04 AM 3/29/02 -0500, Ron Jarrell wrote: >At 02:45 PM 3/27/02 -0500, Barry A. Warsaw wrote: > >>>>>>> "RJ" == Ron Jarrell writes: >> >> RJ> Now, I'd believe there was something wrong with the header >> RJ> (although mm ought to catch this more elegantly), except the >> RJ> user had just sent it to list1@myserver,list2@myserver, and it >> RJ> made it to *list2*, it just won't go through to list1. I >> RJ> unshunted it, and it failed again the same way. >> >> RJ> So how in heck did it get to list2? >> >> RJ> Barry, I saved the copy I got (I'm on both lists), and the >> RJ> shunt files, if you want them; there's nothing private in the >> RJ> message. >> >>Yes, please do send them to me! >>-Barry > > >Hey, Barry? It's the topic processor causing it. I got a second message to that >same list that generated the same error. I'd tried turning off topics before, since >that was one of the two differences between the working, and non working, list. >But when I did that, I didn't *delete* the topic, I just disabled it. (Although, if >topics are disabled, that really should skip all the topic header scanning... Apparently >it doesn't.) Barry, did any of your recent fixes address this one? I've been avoiding putting back topics for now. From che@debian.org Wed Apr 3 09:17:31 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 03 Apr 2002 18:17:31 +0900 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15530.26719.774924.373177@anthem.wooz.org> (barry@zope.com's message of "Tue, 2 Apr 2002 21:26:39 -0500") References: <200204022205.g32M5So03066@quill.local> <15530.26719.774924.373177@anthem.wooz.org> Message-ID: <87lmc55efo.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "NB" == Norbert Bollow writes: NB> At the same time, if 2.0.9 is rolled out anyway, I'd suggest NB> to put in that little patch to insert a Date: header. (You NB> see the missing Date: header bug only if you run a MTA like NB> Qmail which doesn't add missing Date: headers on its own.) BAW> Hmm, can't Qmail be taught to add the Date: header if it's BAW> missing, like every other MTA I'm aware of? When you call qmail, if you want to add the date header, call the "predate" program with the path to qmail's sendmail as an argument: predate /path/to/sendmail (arguments) Ben -- Brought to you by the letters S and C and the number 2. "I don't want the world.. I just want your half." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From nb@thinkcoach.com Wed Apr 3 10:35:49 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Wed, 3 Apr 2002 12:35:49 +0200 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <87lmc55efo.fsf@nausicaa.interq.or.jp> (message from Ben Gertzfield on Wed, 03 Apr 2002 18:17:31 +0900) References: <200204022205.g32M5So03066@quill.local> <15530.26719.774924.373177@anthem.wooz.org> <87lmc55efo.fsf@nausicaa.interq.or.jp> Message-ID: <200204031035.g33AZna01616@quill.local> Ben Gertzfield wrote: > >>>>> "BAW" == Barry A Warsaw writes: > [..] > BAW> Hmm, can't Qmail be taught to add the Date: header if it's > BAW> missing, like every other MTA I'm aware of? I think that DJB's "no message munging" approach is the correct one. (There's nothing wrong with some kinds of munging if you know what you're doing and make sure that this munging happens only to messages that originate from your system. But "teaching" an MTA to munge messages in general, without such a restriction, is a bad idea IMO.) > When you call qmail, if you want to add the date header, call the > "predate" program with the path to qmail's sendmail as an argument: > > predate /path/to/sendmail (arguments) This approach is not available when we pass the message to Qmail by talking SMTP, like SMTPDirect.py does. Let's just apply that tiny little patch and give the MTA an RFC-compliant message, and consider the issue closed. Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From midnight@the-oasis.net Wed Apr 3 14:13:20 2002 From: midnight@the-oasis.net (Phil Barnett) Date: Wed, 3 Apr 2002 09:13:20 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <200204031035.g33AZna01616@quill.local> References: <87lmc55efo.fsf@nausicaa.interq.or.jp> <200204031035.g33AZna01616@quill.local> Message-ID: On Wednesday 03 April 2002 05:35 am, you wrote: > Ben Gertzfield wrote: > > >>>>> "BAW" == Barry A Warsaw writes: > > > > [..] > > BAW> Hmm, can't Qmail be taught to add the Date: header if it's > > BAW> missing, like every other MTA I'm aware of? > > I think that DJB's "no message munging" approach is the correct one. > > (There's nothing wrong with some kinds of munging if you know what > you're doing and make sure that this munging happens only to > messages that originate from your system. But "teaching" an MTA > to munge messages in general, without such a restriction, is a > bad idea IMO.) > > > When you call qmail, if you want to add the date header, call the > > "predate" program with the path to qmail's sendmail as an argument: > > > > predate /path/to/sendmail (arguments) > > This approach is not available when we pass the message to Qmail > by talking SMTP, like SMTPDirect.py does. > > Let's just apply that tiny little patch and give the MTA an > RFC-compliant message, and consider the issue closed. This was discussed a couple of months ago on this list and it was decided that it would be ok to put a date in to make it rfc compliant. From chuqui@plaidworks.com Wed Apr 3 19:23:03 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 03 Apr 2002 11:23:03 -0800 Subject: [Mailman-Developers] More on the zombie brigade: Message-ID: Here's what I'm seeing. After qrunner is running for a while, I see: mailman 7303 7269 0 0:00 mailman 7672 7269 0 0:00 mailman 8008 7269 0 0:00 mailman 8285 7269 0 0:00 mailman 8412 7269 0 0:00 mailman 8746 7269 0 0:00 mailman 8833 7269 0 0:00 mailman 8992 7269 0 0:00 mailman 9139 7269 0 0:00 mailman 9223 7269 0 0:00 mailman 9361 7269 0 0:00 mailman 7269 7268 3 11:08:00 ? 1:22 /usr/local/bin/python -S /export/home/mailman/cron/qrunner So these are dead, unreaped children owned by qrunner, barry. I'm wondering if it is the mail -> news stuff. I think I see one per message posted to a list, and pretty much all of my lists are gatewayed on that machine. But some sub-process is exiting and not being reaped. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From barry@zope.com Wed Apr 3 20:45:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 15:45:01 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <200204022205.g32M5So03066@quill.local> <15530.26719.774924.373177@anthem.wooz.org> <87lmc55efo.fsf@nausicaa.interq.or.jp> <200204031035.g33AZna01616@quill.local> Message-ID: <15531.27085.74896.479290@anthem.wooz.org> >>>>> "NB" == Norbert Bollow writes: NB> Let's just apply that tiny little patch and give the MTA an NB> RFC-compliant message, and consider the issue closed. I'm convinced. -Barry From peter.bengtson@musikelit.nu Tue Apr 2 09:00:09 2002 From: peter.bengtson@musikelit.nu (Peter Bengtson) Date: Tue, 02 Apr 2002 11:00:09 +0200 Subject: [Mailman-Developers] Module search path in Python/Mailman Message-ID: <3CA97319.C89BA466@musikelit.nu> What is the recommended way to extend Python's module search path when using Mailman? When compiling Mailman (MacOS X), the following warning appears: > warning: install: modules installed to '/Users/mailman/pythonlib/', > which is not in Python's module search path (sys.path) -- you'll have > to change the search path yourself And when Mailman is run, a posting to the moderated "Mailman" list results in a message which keeps coming back hundreds of times: > Traceback (most recent call last): > File "/Users/mailman/cron/qrunner", line 89, in ? > from Mailman.Handlers import HandlerAPI > File "../Mailman/Handlers/HandlerAPI.py", line 26, in ? > ImportError: No module named pythonlib.StringIO So: should i use $PYTHONPATH dynamically? Or should i set up a symbolic link in site-packages plus a .pth file? Does this file need to contain all the subdirectories (email + japanese and further down?) Do I need to recompile or is this a dynamic process? Should I add the /Users/mailman/pythonlib directory somewhere in the ./configure invocation. There is absolutely no documentation about this in the 2.1 Mailman beta distribution. Searching the Python site reveals several strategies, but it is difficult to know the optimal one to use with Mailman. Grateful for any help. / Peter Bengtson From chuq@apple.com Wed Apr 3 20:59:32 2002 From: chuq@apple.com (Chuq Von Rospach) Date: Wed, 03 Apr 2002 12:59:32 -0800 Subject: [Mailman-Developers] Some data on 2.0.x bounce processing. Message-ID: For various reasons, I had to run an address probe on one of my lists today to find a misbehaving but well-closed address. One thing I wanted to track was what percentage of the list comes back in some way. Of the 2000ish on the list, I ended up getting 38 bounces back (so far). Of those bounces, about 1/3 were being processed by the bounce system but not terminated. The other 2/3 were unprocessable for various reasons. I was able to manually deal with all of them, FWIW. Overall, that means that about 2% of the mail list was bouncing but not removed from the list. To me, with a fully automated system, that's not bad. It indicates it probably makes sense to do subscription validation probing on a manual basiis once in a while, and why we need to look at VERP and processing password reminders and the like, but I think it shows the bounce system works pretty well. I'll be curious what happens when I get 2.1 live and in production... Just FYI. Chuq From bob@nleaudio.com Wed Apr 3 21:58:34 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Wed, 03 Apr 2002 16:58:34 -0500 Subject: [Mailman-Developers] Some data on 2.0.x bounce processing. References: Message-ID: <3CAB7B0A.711B4A4B@nleaudio.com> HI Chuq, FWIW, I have been modifying the bounce processing code, adding "incompatible" responses over the past couple years. In the past 3 months, I think I've received 3 different mail server messages that weren't parseable. Not too bad for a list of 2000, with probably the same bounce rate as you measured on yours. I think it would be nice to incorporate these added ones in a new release. I wiill post them if Barry desires. Bob From barry@zope.com Wed Apr 3 22:03:18 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 17:03:18 -0500 Subject: [Mailman-Developers] Some data on 2.0.x bounce processing. References: <3CAB7B0A.711B4A4B@nleaudio.com> Message-ID: <15531.31782.6726.740867@anthem.wooz.org> >>>>> "B" == Bob writes: B> FWIW, I have been modifying the bounce processing code, adding B> "incompatible" responses over the past couple years. In the B> past 3 months, I think I've received 3 different mail server B> messages that weren't parseable. Not too bad for a list of B> 2000, with probably the same bounce rate as you measured on B> yours. B> I think it would be nice to incorporate these added ones in a B> new release. I wiill post them if Barry desires. Please add them to the SF patch manager (but only if they've been ported to MM2.1). Thanks! -Barry From barry@zope.com Wed Apr 3 22:54:25 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 17:54:25 -0500 Subject: [Mailman-Developers] More on the zombie brigade: References: Message-ID: <15531.34849.814981.53009@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> So these are dead, unreaped children owned by qrunner, CVR> barry. I'm wondering if it is the mail -> news stuff. I think CVR> I see one per message posted to a list, and pretty much all CVR> of my lists are gatewayed on that machine. But some CVR> sub-process is exiting and not being reaped. I'm sure it's the mail->news gateway, since that's the only bit that calls fork() in MM2.0.x. Looking at the code, I believe that what's going on is that qrunner doesn't wait on it's children until just before it's about to exit. This may not be optimal, but it's inconvenient to change given the goal to get MM2.0.9 out today. Since everything eventually gets cleaned up, can you live with it? -Barry From chuqui@plaidworks.com Wed Apr 3 23:07:24 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 03 Apr 2002 15:07:24 -0800 Subject: [Mailman-Developers] More on the zombie brigade: In-Reply-To: <15531.34849.814981.53009@anthem.wooz.org> Message-ID: On 4/3/02 2:54 PM, "Barry A. Warsaw" wrote: > > This may not be optimal, but it's > inconvenient to change given the goal to get MM2.0.9 out today. Since > everything eventually gets cleaned up, can you live with it? I consider it one step above cosmetic. The only people who'll even notice it are people with really marginal resources compared to their system load, and anal rententive mail list hackers. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From barry@zope.com Wed Apr 3 23:14:14 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 18:14:14 -0500 Subject: [Mailman-Developers] More on the zombie brigade: References: <15531.34849.814981.53009@anthem.wooz.org> Message-ID: <15531.36038.861744.719293@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> This may not be optimal, but it's inconvenient to change given >> the goal to get MM2.0.9 out today. Since everything eventually >> gets cleaned up, can you live with it? CVR> I consider it one step above cosmetic. Cool. I'm pulling the trigger then. python.org seems to be going well with the current 2.0.9 code. -Barry From jason-list-mailman-developers@mastaler.com Thu Apr 4 00:19:56 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 17:19:56 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <200204031035.g33AZna01616@quill.local> (Norbert Bollow's message of "Wed, 3 Apr 2002 12:35:49 +0200") References: <200204022205.g32M5So03066@quill.local> <15530.26719.774924.373177@anthem.wooz.org> <87lmc55efo.fsf@nausicaa.interq.or.jp> <200204031035.g33AZna01616@quill.local> Message-ID: Norbert Bollow writes: > This approach is not available when we pass the message to Qmail by > talking SMTP, like SMTPDirect.py does. > > Let's just apply that tiny little patch and give the MTA an > RFC-compliant message, and consider the issue closed. Then shouldn't you also have Mailman add a Message-ID header as well? SMTP on qmail doesn't add that either. Of course, both of these headers are now added in Mailman 2.1. Perhaps just wait for that to be released instead? -- (http://tmda.sourceforge.net/) From barry@zope.com Thu Apr 4 02:39:21 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 21:39:21 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <200204022205.g32M5So03066@quill.local> <15530.26719.774924.373177@anthem.wooz.org> <87lmc55efo.fsf@nausicaa.interq.or.jp> <200204031035.g33AZna01616@quill.local> Message-ID: <15531.48345.3701.22028@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> Then shouldn't you also have Mailman add a Message-ID header JRM> as well? SMTP on qmail doesn't add that either. I thought about the same thing, and /almost/ added it, but then I checked RFC 2822. While it requires one Date: header, Message-ID: is actually /not/ required, although it "SHOULD be present". I took that as license to be as conservative as possible. :) -Barry From chuqui@plaidworks.com Thu Apr 4 02:58:09 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 03 Apr 2002 18:58:09 -0800 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15531.48345.3701.22028@anthem.wooz.org> Message-ID: On 4/3/02 6:39 PM, "Barry A. Warsaw" wrote: > I thought about the same thing, and /almost/ added it, but then I > checked RFC 2822. While it requires one Date: header, Message-ID: is > actually /not/ required, although it "SHOULD be present". I took that > as license to be as conservative as possible. :) I'm curious, and in honesty, haven't looked. Is qmail RFC compliant here? Or is it a case of doing what the authors feel is right, not what the standards tell them to? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From jason-list-mailman-developers@mastaler.com Thu Apr 4 04:11:53 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 21:11:53 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15531.48345.3701.22028@anthem.wooz.org> (barry@zope.com's message of "Wed, 3 Apr 2002 21:39:21 -0500") References: <200204022205.g32M5So03066@quill.local> <15530.26719.774924.373177@anthem.wooz.org> <87lmc55efo.fsf@nausicaa.interq.or.jp> <200204031035.g33AZna01616@quill.local> <15531.48345.3701.22028@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > I thought about the same thing, and /almost/ added it, but then I > checked RFC 2822. While it requires one Date: header, Message-ID: > is actually /not/ required, although it "SHOULD be present". I took > that as license to be as conservative as possible. :) Works for me. I plan to upgrade to 2.1 as soon as it's released anyway. -- (http://tmda.sourceforge.net/) From barry@zope.com Thu Apr 4 04:22:18 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 23:22:18 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <15531.48345.3701.22028@anthem.wooz.org> Message-ID: <15531.54522.390316.53704@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> I thought about the same thing, and /almost/ added it, but then >> I checked RFC 2822. While it requires one Date: header, >> Message-ID: is actually /not/ required, although it "SHOULD be >> present". I took that as license to be as conservative as >> possible. :) CVR> I'm curious, and in honesty, haven't looked. Is qmail RFC CVR> compliant here? Or is it a case of doing what the authors CVR> feel is right, not what the standards tell them to? I think Qmail is probably within its rights to reject a message without a From: field or a Date: field, as RFC 2822, section 3.6.1 says: 3.6.1. The origination date field [...] In any case, it is specifically not intended to convey the time that the message is actually transported, but rather the time at which the human or other creator of the message has put the message into its final form, ready for transport. It's probably RFC 2821, though that specifies what the SMTP server is allowed to do in the face of invalid message content. Scanning both RFCs, I really can't find the connection, but it's probably valid for Qmail to return a 50x error after the DATA command. (I tested the one Qmail server I know about, starship.python.net, and it didn't seem to complain.) Personally, though, I think it's thickheaded for Qmail to reject messages from localhost that are missing any headers it's perfectly capable of supplying. Every other MTA does it, so I think Qmail's just being obstinate. I'd also appreciate if any RFC-lawyers can point to specific text to back up Qmail's opinion. -Barry From jason-list-mailman-developers@mastaler.com Thu Apr 4 04:24:14 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 21:24:14 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: (Chuq Von Rospach's message of "Wed, 03 Apr 2002 18:58:09 -0800") References: Message-ID: Chuq Von Rospach writes: > I'm curious, and in honesty, haven't looked. Is qmail RFC compliant > here? Yes. > Or is it a case of doing what the authors feel is right, not what > the standards tell them to? qmail has only one author, D. J. Bernstein, and all his software is extremely standards conscious. In fact, this explains why qmail doesn't add a missing Date header for messages coming in via SMTP. qmail didn't create the message, Mailman did, and therefore it's Mailman's job as originator to add a Date line. Other MTAs which add missing required headers are essentially just covering for non-compliant programs. djb isn't that kind I guess . -- (http://tmda.sourceforge.net/) From jason-list-mailman-developers@mastaler.com Thu Apr 4 04:29:22 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 21:29:22 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15531.54522.390316.53704@anthem.wooz.org> (barry@zope.com's message of "Wed, 3 Apr 2002 23:22:18 -0500") References: <15531.48345.3701.22028@anthem.wooz.org> <15531.54522.390316.53704@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > I think Qmail is probably within its rights to reject a message > without a From: field or a Date: field, as RFC 2822, section 3.6.1 qmail doesn't reject such messages, it simply passes them on without the headers. This means the receiving MTA usually ends up adding them which might be confusing for the recipient. -- (http://tmda.sourceforge.net/) From barry@zope.com Thu Apr 4 04:44:28 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 23:44:28 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: Message-ID: <15531.55852.341934.552849@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> Other MTAs which add missing required headers are essentially JRM> just covering for non-compliant programs. djb isn't that JRM> kind I guess . The only argument I'd make is that the standards are really geared toward cooperation of alien systems, i.e. two unrelated processes that need to exchange mail messages. In Mailman's case, an argument can be made that it and its MTA are working in tandem to perform a function. They know a lot about each other, communicate over a semi-private channel (i.e. localhost:25) are controlled and configured by the same entities, etc. So again, I have no problem with Qmail rejecting messages from the big bad world that are ill-formed, but it could be more cooperative with Mailman. I guess Qmail rejects ill-formed messages posted from local MUAs too. OTOH, I can't and won't really argue this point much, because I also feel that Mailman should comply with the appropriate standards, so adding the Date: header for internally generated messages is really the right thing to do anyway. -Barry From barry@zope.com Thu Apr 4 04:46:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Apr 2002 23:46:24 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <15531.48345.3701.22028@anthem.wooz.org> <15531.54522.390316.53704@anthem.wooz.org> Message-ID: <15531.55968.101953.974108@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: >> I think Qmail is probably within its rights to reject a message >> without a From: field or a Date: field, as RFC 2822, section >> 3.6.1 JRM> qmail doesn't reject such messages, it simply passes them on JRM> without the headers. This means the receiving MTA usually JRM> ends up adding them which might be confusing for the JRM> recipient. But isn't that different? Doesn't this mean Qmail is violating the standards too? -Barry From jason-list-mailman-developers@mastaler.com Thu Apr 4 04:56:20 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 21:56:20 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15531.55968.101953.974108@anthem.wooz.org> (barry@zope.com's message of "Wed, 3 Apr 2002 23:46:24 -0500") References: <15531.48345.3701.22028@anthem.wooz.org> <15531.54522.390316.53704@anthem.wooz.org> <15531.55968.101953.974108@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > But isn't that different? Doesn't this mean Qmail is violating the > standards too? How would it be in violation? qmail-smtpd, the program which receives mail SMTP didn't originate the message. On the other hand, qmail-inject (/usr/sbin/sendmail equivalent) *does* add a missing Date, From, etc. to messages. -- (http://tmda.sourceforge.net/) From jason-list-mailman-developers@mastaler.com Thu Apr 4 04:59:11 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 21:59:11 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15531.55852.341934.552849@anthem.wooz.org> (barry@zope.com's message of "Wed, 3 Apr 2002 23:44:28 -0500") References: <15531.55852.341934.552849@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > The only argument I'd make is that the standards are really geared > toward cooperation of alien systems, i.e. two unrelated processes > that need to exchange mail messages. In Mailman's case, an argument > can be made that it and its MTA are working in tandem to perform a > function. That would be a practical and reasonable argument. Some criticize djb for interpreting the RFCs too literally. > OTOH, I can't and won't really argue this point much, because I also > feel that Mailman should comply with the appropriate standards, so > adding the Date: header for internally generated messages is really > the right thing to do anyway. Indeed. -- (http://tmda.sourceforge.net/) From barry@zope.com Thu Apr 4 05:06:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 00:06:42 -0500 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) References: <15531.48345.3701.22028@anthem.wooz.org> <15531.54522.390316.53704@anthem.wooz.org> <15531.55968.101953.974108@anthem.wooz.org> Message-ID: <15531.57186.631876.576310@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: >> But isn't that different? Doesn't this mean Qmail is violating >> the standards too? JRM> How would it be in violation? qmail-smtpd, the program which JRM> receives mail SMTP didn't originate the message. On the JRM> other hand, qmail-inject (/usr/sbin/sendmail equivalent) JRM> *does* add a missing Date, From, etc. to messages. So if a process handed qmail-smtpd a message without a Date: header, and it sends the message on to some remote smtpd without adding the Date: header, is that legal? I guess you'd say because Qmail wasn't the originator of the message, it would be, but the remote smtpd would be within its rights to reject it. Or am I being dense? -Barry From jason-list-mailman-developers@mastaler.com Thu Apr 4 05:21:41 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 03 Apr 2002 22:21:41 -0700 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: <15531.57186.631876.576310@anthem.wooz.org> (barry@zope.com's message of "Thu, 4 Apr 2002 00:06:42 -0500") References: <15531.48345.3701.22028@anthem.wooz.org> <15531.54522.390316.53704@anthem.wooz.org> <15531.55968.101953.974108@anthem.wooz.org> <15531.57186.631876.576310@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > So if a process handed qmail-smtpd a message without a Date: header, > and it sends the message on to some remote smtpd without adding the > Date: header, is that legal? I guess you'd say because Qmail wasn't > the originator of the message, it would be Playing the qmail advocate, I'd probably say this, yes. > but the remote smtpd would be within its rights to reject it. Perhaps, but I still don't think this makes qmail's behavior illegal. Given a rejected message, the trail of guilt would lead back to the originating program, where the problem should be corrected. -- (http://tmda.sourceforge.net/) From nb@thinkcoach.com Thu Apr 4 08:10:38 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Thu, 4 Apr 2002 10:10:38 +0200 Subject: [Mailman-Developers] 2.0.x qrunner bug (bad one) In-Reply-To: (jason-list-mailman-developers@mastaler.com) References: <15531.48345.3701.22028@anthem.wooz.org> <15531.54522.390316.53704@anthem.wooz.org> <15531.55968.101953.974108@anthem.wooz.org> <15531.57186.631876.576310@anthem.wooz.org> Message-ID: <200204040810.g348AcC02729@quill.local> Jason R. Mastaler wrote: > Perhaps, but I still don't think this makes qmail's behavior illegal. > Given a rejected message, the trail of guilt would lead back to the > originating program, where the problem should be corrected. Yes, precisely. And that's why I think it's wrong of MTAs to try to fix malformatted messages: This obscures such message formatting problems in potentially-hard-to-debug ways. Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From nb@thinkcoach.com Thu Apr 4 08:50:52 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Thu, 4 Apr 2002 10:50:52 +0200 Subject: [Mailman-Developers] RFC 2822 complicance (was Re: 2.0.x qrunner bug (bad one)) In-Reply-To: (jason-list-mailman-developers@mastaler.com) References: <15531.55852.341934.552849@anthem.wooz.org> Message-ID: <200204040850.g348oqA02959@quill.local> Jason R. Mastaler wrote: > barry@zope.com (Barry A. Warsaw) writes: > > > The only argument I'd make is that the standards are really geared > > toward cooperation of alien systems, i.e. two unrelated processes > > that need to exchange mail messages. In Mailman's case, an argument > > can be made that it and its MTA are working in tandem to perform a > > function. > > That would be a practical and reasonable argument. Yes. This means that if you're maintaining both the MTA and a MLM (mailing list manager) program which gives messages to it, then you can set things up so that the MLM expects the MTA to munge the messages in some ways that are not specified in the RFCs. However, given that the GNU Mailman project maintains only an MLM and no MTA, and this MLM communicates with the MTA through an interface that is specified in an internet standard, there is IMO no doubt that it's Mailman's responsibility to comply with this standard. Barry A. Warsaw wrote: > >>>>> "JRM" == Jason R Mastaler > >>>>> writes: > > JRM> Then shouldn't you also have Mailman add a Message-ID header > JRM> as well? SMTP on qmail doesn't add that either. > > I thought about the same thing, and /almost/ added it, but then I > checked RFC 2822. While it requires one Date: header, Message-ID: is > actually /not/ required, although it "SHOULD be present". I took that > as license to be as conservative as possible. :) The term "SHOULD" has a well-defined meaning in RFCs... RFC2822 explicitly invokes RFC2119, where this, and related terms are defined as follows: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. [..] With other words, given that the Message-ID: header is a SHOULD, if you want to choose a diffferent course, you (as maintainer of Mailman) have a responsibility to understand and carefully consider the full implications of not adding a Message-ID: header to messages that are _originated_ by Mailman. There are several such implications, in areas like automated filtering of duplicate messages, debugging mail problems (some MTAs log the contents of the Message-ID: header), and spam filters (I know of at least one ISP where all messages without Message-ID: are considered to be probably spam). I think it's probably much less work to just add the header than to "understand" and "carefully weigh" all these implications. Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From jason-list-mailman-developers@mastaler.com Thu Apr 4 17:29:53 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Thu, 04 Apr 2002 10:29:53 -0700 Subject: [Mailman-Developers] MM 2.0.9 not announced? Message-ID: I noticed MM 2.0.9 available for download on sourceforge, but I never saw an announcement for it. Checking the mailman-announce archives confirms this. Was this intentional? -- (http://tmda.sourceforge.net/) From jason-list-mailman-developers@mastaler.com Thu Apr 4 18:10:51 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Thu, 04 Apr 2002 11:10:51 -0700 Subject: [Mailman-Developers] RFC 2822 complicance (was Re: 2.0.x qrunner bug (bad one)) In-Reply-To: <200204040850.g348oqA02959@quill.local> (Norbert Bollow's message of "Thu, 4 Apr 2002 10:50:52 +0200") References: <15531.55852.341934.552849@anthem.wooz.org> <200204040850.g348oqA02959@quill.local> Message-ID: --=-=-= Norbert Bollow writes: > With other words, given that the Message-ID: header is a SHOULD, if > you want to choose a diffferent course, you (as maintainer of > Mailman) have a responsibility to understand and carefully consider > the full implications of not adding a Message-ID: header to messages > that are _originated_ by Mailman. [...] > I think it's probably much less work to just add the header than to > "understand" and "carefully weigh" all these implications. The attached patch (for MM 2.0.x) adds a Message-ID header to messages which lack one. Utils.make_msgid() is just a Python 1.x compatible rendition of the same function that is part of the latest email package. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=mm209.diff Index: Mailman/Message.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Message.py,v retrieving revision 1.40.2.2 diff -u -u -r1.40.2.2 Message.py --- Mailman/Message.py 3 Apr 2002 22:40:41 -0000 1.40.2.2 +++ Mailman/Message.py 4 Apr 2002 18:05:34 -0000 @@ -196,10 +196,14 @@ # make sure that the first line does NOT contain a colon! Message.__init__(self, StringIO(text)) # RFC 2822 requires a Date: header, and while most MTAs add one if - # it's missing, Qmail does not. + # it's missing, qmail does not. if not self.get('date'): self['Date'] = Utils.formatdate(localtime=1) - + # RFC 2822 recommends a Message-ID: header, and while most + # MTAs add one if it's missing, qmail does not. + if not self.get('message-id'): + self['Message-ID'] = Utils.make_msgid(idstring='Mailman') + class UserNotification(OutgoingMessage): Index: Mailman/Utils.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Utils.py,v retrieving revision 1.104.2.5 diff -u -u -r1.104.2.5 Utils.py --- Mailman/Utils.py 3 Apr 2002 22:47:12 -0000 1.104.2.5 +++ Mailman/Utils.py 4 Apr 2002 18:05:34 -0000 @@ -28,6 +28,8 @@ import string import re import time +import socket +import random from UserDict import UserDict from types import StringType import random @@ -737,3 +739,28 @@ 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'][now[1] - 1], now[0], now[3], now[4], now[5], zone) + + + +def make_msgid(idstring=None): + """Returns a string suitable for RFC 2822 compliant Message-ID:, e.g: + + <20020201195627.33539.96671@nightshade.la.mastaler.com> + + Optional idstring if given is a string used to strengthen the + uniqueness of the Message-ID, otherwise an empty string is used. + """ + timeval = time.time() + utcdate = time.strftime('%Y%m%d%H%M%S', time.gmtime(timeval)) + pid = os.getpid() + randint = random.randrange(100000) + if idstring is None: + idstring = '' + else: + idstring = '.' + idstring + try: + idhost = socket.getfqdn() + except AttributeError: + idhost = socket.gethostbyaddr(socket.gethostname())[0] + msgid = '<%s.%s.%s%s@%s>' % (utcdate, pid, randint, idstring, idhost) + return msgid --=-=-=-- From barry@zope.com Thu Apr 4 18:58:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 13:58:32 -0500 Subject: [Mailman-Developers] MM 2.0.9 not announced? References: Message-ID: <15532.41560.541253.389195@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> I noticed MM 2.0.9 available for download on sourceforge, but JRM> I never saw an announcement for it. Checking the JRM> mailman-announce archives confirms this. Was this JRM> intentional? I've had a bunch of other bookkeeping issues I need to take care of first. The announcement will go out today. -Barry From chuqui@plaidworks.com Thu Apr 4 19:07:30 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 04 Apr 2002 11:07:30 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... Message-ID: Oh, man. This is my week for weird stuff. I've just finished tracking down and nuking a subscriber with a really noxious mailbot. The situation was that anyone posting to one of my lists would get a reply back from acknowledging the email. Needless, this was rather irritating to people. I finally had to address probe the entire list, because the mailbot was coming back from a domain that wasn't subscribed to the list (of course), and the mailbot successfully removed every piece of identifying information from the email except the subject line. It finally turned out to be a person's alumni email address (why are these things always problems?) at forwarding to his account at . I deleted it, banned the address, and sent him mail announcing him as the winner of the "you're the stupid mailbot winner!" message explaining why he was a dead man. (he responded this morning. It started with "why didn't you contact me?" and went downhill from there....) But another list user brought up an interesting point, and I want to throw it out here to see if it's a problem we should worry about. Since the mailbot responds to the given address with the subject line more or less intact, it seems to me like we have a hole in the mail-back validation system in this specific situation. Imagine this scenario: - I get mad at . - I notice they have a braindead mailbot saying "thank you for e-mailing . We want you to know we got your message regarding 'foo'". - I decide to mailbomb - I forge a bunch of subscribe requests to a lists on a mailman server, all coming from , asking to subscribe. I start with root, abuse, ftp, admin, ceo, all -- have fun, it's cheap and easy. - All of these go to mailman, which sends back the confirmation message with the confirmation token in it. - this mailbot gets a copy and sends back it's "thanks for mailing us..." -- and includes the subject line, which includes the token. - which, AFAIKT, confirms the subscription, making the attack successful. Now you have a bunch of folks who got the confirmation message out of nowhere, but the confirmation message says to reply or nothing will happen. They odn't reply, but they'll find themselves subscribed anyway, because the mailbot confirmed the subscription FOR them. And now they're pissed at us, the list server owners. Now, part of me wants to respond "your own damn fault for running such a braindead mailbot in such a stupid way", but at the same time, I don't think mailman should allow for attacks even if it requires braindeadness on the part of the IS people on the other domain (in this case, I'm not sure the IS people are to blame, I think it's the corporate lawyers). The question I'm bringing up is, I guess, is this something mailman needs to worry about? Should it require that the returned token come from the address being subscribed? (or does it already? In this case, it came from a generic mailbot address @ that domain. An address which, fwiw, bounces if you mail to it. Grimace.). I realize that the "reply to confirm" is easy for users, but does it leave us open to abuse in other ways? Should we make some cahnge to the process that requires a person to do something? I don't have a good answer for any of this. I'm not even sure we should consider it a problem. But since I've identified it as a possible security flaw, I want to throw it out and let everyone chew on it. What do folks think about this? I'm worried about setting up mailman to allow for attacks on people or sites, even if it's a limited set of sites set up a specific way (shades of ORBZ and the Lotus Notes domino bug...). On the other hand, IS it their fault for building a stupid tool? Or is that no excuse to not protect ourselves from stupidity? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From bjf@samurai.com Thu Apr 4 19:11:12 2002 From: bjf@samurai.com (Bryan Fullerton) Date: Thu, 4 Apr 2002 14:11:12 -0500 Subject: [Mailman-Developers] MM 2.0.9 not announced? In-Reply-To: Message-ID: On Thursday, April 4, 2002, at 12:29 PM, Jason R. Mastaler wrote: > I noticed MM 2.0.9 available for download on sourceforge, but I never > saw an announcement for it. Checking the mailman-announce archives > confirms this. Was this intentional? It's also not on ftp.gnu.org yet, which combined with the lack of announcement made me wonder if it was officially released yet. But I'm running it anyways. ;) Bryan From jason-list-mailman-developers@mastaler.com Thu Apr 4 19:27:49 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Thu, 04 Apr 2002 12:27:49 -0700 Subject: [Mailman-Developers] MM 2.0.9 not announced? In-Reply-To: <15532.41560.541253.389195@anthem.wooz.org> (barry@zope.com's message of "Thu, 4 Apr 2002 13:58:32 -0500") References: <15532.41560.541253.389195@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > I've had a bunch of other bookkeeping issues I need to take care of > first. The announcement will go out today. Or, if you want to incorporate my Message-ID patch, perhaps release/announce 2.0.10 instead? -- (http://tmda.sourceforge.net/) From chuqui@plaidworks.com Thu Apr 4 19:36:44 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 04 Apr 2002 11:36:44 -0800 Subject: [Mailman-Developers] MM 2.0.9 not announced? In-Reply-To: Message-ID: On 4/4/02 11:27 AM, "Jason R. Mastaler" wrote: > barry@zope.com (Barry A. Warsaw) writes: > >> I've had a bunch of other bookkeeping issues I need to take care of >> first. The announcement will go out today. > > Or, if you want to incorporate my Message-ID patch, perhaps > release/announce 2.0.10 instead? Just MHO, but I wouldn't roll a release just for the message-id patch. I'd put it in the 2.1 tree, and if something else makes a 2.0.10 worthwhile, roll it then. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From jason-list-mailman-developers@mastaler.com Thu Apr 4 19:43:20 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Thu, 04 Apr 2002 12:43:20 -0700 Subject: [Mailman-Developers] MM 2.0.9 not announced? In-Reply-To: (Chuq Von Rospach's message of "Thu, 04 Apr 2002 11:36:44 -0800") References: Message-ID: Chuq Von Rospach writes: > Just MHO, but I wouldn't roll a release just for the message-id > patch. I'd put it in the 2.1 tree, and if something else makes a > 2.0.10 worthwhile, roll it then. Do you mean the 2.0 tree? 2.1 already adds a Message-ID (with different code). It's up to Barry I guess, but I was thinking that a 2.0.10 would be easy because 2.0.9 was never formally announced. Release numbers are cheap. -- (http://tmda.sourceforge.net/) From chuqui@plaidworks.com Thu Apr 4 19:48:39 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 04 Apr 2002 11:48:39 -0800 Subject: [Mailman-Developers] Buglet in list_members (and others?) Message-ID: Oh, this is so obscure I'm embarrassed. % list_members typo_a_list_name > foo % % cat foo No such list "typo_a_list_name" List_members returns errors to STDOUT, not STDERR. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From barry@zope.com Thu Apr 4 19:55:47 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 14:55:47 -0500 Subject: [Mailman-Developers] MM 2.0.9 not announced? References: <15532.41560.541253.389195@anthem.wooz.org> Message-ID: <15532.44995.477959.345049@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: >> I've had a bunch of other bookkeeping issues I need to take >> care of first. The announcement will go out today. JRM> Or, if you want to incorporate my Message-ID patch, perhaps JRM> release/announce 2.0.10 instead? I don't think the Message-ID patch is important enough to warrant another release, but I'll commit it to the code base in case there /is/ a 2.0.10. -Barry From barry@zope.com Thu Apr 4 19:57:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 14:57:27 -0500 Subject: [Mailman-Developers] MM 2.0.9 not announced? References: Message-ID: <15532.45095.654001.834881@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Just MHO, but I wouldn't roll a release just for the CVR> message-id patch. I'd put it in the 2.1 tree, and if CVR> something else makes a 2.0.10 worthwhile, roll it then. Boy Chuq, I think you're as good at channeling me as Tim Peters is at channeling Guido. Be afraid. BTW, this -- and the Date: header -- are already in MM2.1. :) -Barry From barry@zope.com Thu Apr 4 20:00:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 15:00:11 -0500 Subject: [Mailman-Developers] MM 2.0.9 not announced? References: Message-ID: <15532.45259.939558.320126@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> It's up to Barry I guess, but I was thinking that a 2.0.10 JRM> would be easy because 2.0.9 was never formally announced. JRM> Release numbers are cheap. Bumping the rev numbers is just the smallest tip of the release iceberg. It takes /much/ more time and effort to do the SF dance, get all the web pages and tarballs pushed out, writing the announcement, etc. Trust me, doing a release is /not/ a trivial affair. -Barry From barry@zope.com Thu Apr 4 20:29:44 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 15:29:44 -0500 Subject: [Mailman-Developers] RELEASED Mailman 2.0.9 Message-ID: <15532.47032.741659.783660@anthem.wooz.org> This message is to announce the release of GNU Mailman 2.0.9 which fixes a race condition that can cause mail to occasionally be lost, among other useful fixes. I recommend anybody running any version of Mailman 2.0.x to upgrade to 2.0.9, the latest stable release. Details of what's changed is included below. Note that this problem does not affect the Mailman 2.1 betas. As usual, I've made both full source tarballs and patches available. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarball. If you decide to install the patches, please do read the release notes first: http://sourceforge.net/project/shownotes.php?release_id=63042 See also: http://www.gnu.org/software/mailman http://www.list.org http://mailman.sf.net Cheers, -Barry 2.0.9 (02-Apr-2002) - Closed a race condition which could, under rare circumstances, cause the occasional message to get lost. - HTML escape message excerpts and headers on the admindb page so JavaScript and other evil tags can't mess up the display. - Some additional Python 2.2 compatibility fixes. - Unlink the footer logos so as not to bug the python.org and gnu.org maintainers as much. :( - Fix a crash in the DSN bounce detection module, which could cause some bounce messages to remain in the queue. - Add the RFC-2822 mandated Date: header on internally generated outgoing messages. Not all MTAs add this field if missing (read: Qmail). From gorg@sun31.imbi.uni-freiburg.de Thu Apr 4 08:35:09 2002 From: gorg@sun31.imbi.uni-freiburg.de (Georg Koch) Date: Thu, 04 Apr 2002 10:35:09 +0200 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 Message-ID: <200204040835.g348Z9010575@sun31.imbi.uni-freiburg.de> Hi, I am trying to update from 2.1a2 to 2.1b1 (on a SUN Sparc Solaris7 machine), unfortunately with some hundreds of users waiting. When I updated python from 1.5.2 to 2.2.1c1, mailman 2.1a2 broke immediately with "ImportError: No module named mimelib.Parser". The installation of 2.1b1 abended in the Makefile of the bin subdirectory with a syntax error on for f in $(NONSCRIPTS); \ do \ $(INSTALL) -m $(FILEMODE) $$f $(SCRIPTSDIR); \ done; \ fi because "NONSCRIPTS= ". After I commented these lines out the installation continued but stopped in bin/update with the line OSError: [Errno 2] No such file or directory: '/h/mailman/lists/test/config.pck' because the configuration is stored as config.db. How do I convert the config.db to config.pck ? Best wishes Georg ---------------- output of bin/updated --------------- Upgrading from version 0x20100a2 to 0x20100b1 getting rid of old source files removing /h/mailman/Mailman/Cookie.py removing /h/mailman/scripts/mailcmd removing /h/mailman/scripts/mailowner removing /h/mailman/mail/wrapper removing directory /h/mailman/Mailman/pythonlib and everything underneath removing /h/mailman/cgi-bin/archives Updating mailing list: test Traceback (most recent call last): File "bin/update", line 542, in ? errors = main() File "bin/update", line 424, in main errors = errors + dolist(listname) File "bin/update", line 184, in dolist mlist = MailList.MailList(listname, lock=0) File "/h/mailman/Mailman/MailList.py", line 102, in __init__ self.Load() File "/h/mailman/Mailman/MailList.py", line 534, in Load dict, e = self.__load(file) File "/h/mailman/Mailman/MailList.py", line 496, in __load mtime = os.path.getmtime(dbfile) File "/usr/local/lib/python2.2/posixpath.py", line 144, in getmtime st = os.stat(filename) OSError: [Errno 2] No such file or directory: '/h/mailman/lists/test/config.pck' ---------------------------------- -------------- output of http://ourhost/mailman/listinfo -------- Traceback (most recent call last): File "/h/mailman/scripts/driver", line 82, in run_main main() File "/h/mailman/Mailman/Cgi/listinfo.py", line 42, in main listinfo_overview() File "/h/mailman/Mailman/Cgi/listinfo.py", line 85, in listinfo_overview mlist = MailList.MailList(name, lock=0) File "/h/mailman/Mailman/MailList.py", line 102, in __init__ self.Load() File "/h/mailman/Mailman/MailList.py", line 534, in Load dict, e = self.__load(file) File "/h/mailman/Mailman/MailList.py", line 496, in __load mtime = os.path.getmtime(dbfile) File "/usr/local/lib/python2.2/posixpath.py", line 144, in getmtime st = os.stat(filename) OSError: [Errno 2] No such file or directory: '/h/mailman/lists/accstaff/config.pck' --------------------------------------- -- -- Georg Koch (koch@cochrane.de) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany "All you need in this life is ignorance and confidence, and then success is sure." (Mark Twain) From barry@zope.com Thu Apr 4 21:09:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 4 Apr 2002 16:09:50 -0500 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 References: <200204040835.g348Z9010575@sun31.imbi.uni-freiburg.de> Message-ID: <15532.49438.250712.852479@anthem.wooz.org> >>>>> "GK" == Georg Koch writes: GK> I am trying to update from 2.1a2 to 2.1b1 (on a SUN Sparc GK> Solaris7 machine), unfortunately with some hundreds of users GK> waiting. When I updated python from 1.5.2 to 2.2.1c1, mailman GK> 2.1a2 broke immediately with "ImportError: No module named GK> mimelib.Parser". Not surprising. Until recently, the email package was installed in your Python's site-library, which changes with each Python version. MM2.1b1 fixes this. GK> The installation of 2.1b1 abended in the GK> Makefile of the bin subdirectory with a syntax error on | for f in $(NONSCRIPTS); \ | do \ | $(INSTALL) -m $(FILEMODE) $$f $(SCRIPTSDIR); \ | done; \ | fi GK> because "NONSCRIPTS= ". After I commented these lines out the GK> installation continued but stopped in bin/update with the line Fixed in CVS. GK> OSError: [Errno 2] No such file or directory: GK> '/h/mailman/lists/test/config.pck' GK> because the configuration is stored as config.db. GK> How do I convert the config.db to config.pck ? You don't. While the error message is misleading, your config.db file will be automatically updated to config.pck the first time you load your list (via web, qrunner, or command line script). -Barry From claw@kanga.nu Fri Apr 5 03:58:48 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 04 Apr 2002 19:58:48 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: Message from Chuq Von Rospach of "Thu, 04 Apr 2002 11:07:30 PST." References: Message-ID: <28464.1017979128@kanga.nu> On Thu, 04 Apr 2002 11:07:30 -0800 Chuq Von Rospach wrote: > Oh, man. This is my week for weird stuff. Yea and verily. > The question I'm bringing up is, I guess, is this something mailman > needs to worry about? Should it require that the returned token come > from the address being subscribed? (or does it already? In this case, > it came from a generic mailbot address @ that domain. An address > which, fwiw, bounces if you mail to it. Grimace.). I realize that the > "reply to confirm" is easy for users, but does it leave us open to > abuse in other ways? Should we make some cahnge to the process that > requires a person to do something? Mailman is becoming ubiquitous enough that I expect we'd do better to paranoid in advance than retroactively. > I don't have a good answer for any of this. I'm not even sure we > should consider it a problem. But since I've identified it as a > possible security flaw, I want to throw it out and let everyone chew > on it. Majordomo attempts to work around this by embedding a confirm token in the body of the message. To confirm the subscription you have to send that line back, unedited, to the list server. Happily, MD is fairly generous about line wrapping, quote prefixes etc. > On the other hand, IS it their fault for building a stupid tool? Or is > that no excuse to not protect ourselves from stupidity? There's no simple blanket answer as regards blame here: It is their fault for both installing and running a stupid auto-responder. Mailman Death Penalties are too good for them. It is our fault for writing and advocating a list server that is so trivially abused by stupid systems. At some point you have to drop back and say enough is enough and give up trying to stop stupid people I think thi Subject: business comes before that point however. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Fri Apr 5 05:13:44 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 00:13:44 -0500 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... References: Message-ID: <15533.12936.337697.857925@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> I've just finished tracking down and nuking a subscriber with CVR> a really noxious mailbot. The situation was that anyone CVR> posting to one of my lists would get a reply back from new york financial company name deleted> acknowledging the CVR> email. Needless, this was rather irritating to people. CVR> I finally had to address probe the entire list, because the CVR> mailbot was coming back from a domain that wasn't subscribed Won't the VERP-ish support in MM2.1 make your life so much easier? (Coming as someone who's had to do the same thing on occasion.) CVR> But another list user brought up an interesting point, and I CVR> want to throw it out here to see if it's a problem we should CVR> worry about. It's a real issue, and as I see it there is no right answer, there are only trade-offs. If we make it easy for users who want to use an email interface to confirm subscriptions, we also make it easier for stupid replybots to get nailed. We can protect dumb replybots by making it less convenient for our users, essentially by forcing them to perform an action that is unlikely (though not impossible, Mr. Turing), to be doable by anything other than a human. E.g. we could shut off email confirms altogether and force only web confirmations. Or we could be more Majordomo-ish as JC describes. Note that MM2.1 has the opportunity to embed the confirmation cookie in the envelope sender, so that a human meaningful Subject: could be used on the confirmation message. This is only currently used in the invitation confirmation (if you can't trust your admins... yikes!), but it sounds like this may not be a good idea to add to subscription confirmations. So I don't know. I'm inclined to favor user convenience for now, but I've no doubt that we'll have to re-debate this decision as time goes by. -Barry From Dale@Newfield.org Fri Apr 5 05:37:23 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 5 Apr 2002 00:37:23 -0500 (EST) Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <15533.12936.337697.857925@anthem.wooz.org> Message-ID: On Fri, 5 Apr 2002, Barry A. Warsaw wrote: > We can protect dumb replybots by making it less convenient for our > users, essentially by forcing them to perform an action that is unlikely > (though not impossible, Mr. Turing), to be doable by anything other than > a human. What if we make the required response not responding to the message, but rather following either an http link to a webpage with a "Yes" button, or following a mailto link that specifies the special reply token in the thus composed email message? So instead of sending the token in the Subject: line of the message, it's sent in the subject line in a mailto link. (like so: ) I still use pine, and even it is able to "do the right thing"(tm) with that... -Dale From barry@zope.com Fri Apr 5 06:01:44 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 01:01:44 -0500 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... References: <15533.12936.337697.857925@anthem.wooz.org> Message-ID: <15533.15816.2855.262192@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> On Fri, 5 Apr 2002, Barry A. Warsaw wrote: >> We can protect dumb replybots by making it less convenient for >> our users, essentially by forcing them to perform an action >> that is unlikely (though not impossible, Mr. Turing), to be >> doable by anything other than a human. DN> What if we make the required response not responding to the DN> message, but rather following either an http link to a webpage DN> with a "Yes" button, or following a mailto link that specifies DN> the special reply token in the thus composed email message? The former is already implemented in MM2.1; it's just optional not mandatory. The latter is an interesting idea, but I don't how burdensome that would be on people with today's MUA's (XEmacs/VM handles it, and is that really the only one that matters :). I'd be interested in other people's thoughts. -Barry From jwblist@olympus.net Fri Apr 5 06:16:07 2002 From: jwblist@olympus.net (John W Baxter) Date: Thu, 4 Apr 2002 22:16:07 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: References: Message-ID: At 0:37 -0500 4/5/2002, Dale Newfield wrote: >So instead of sending the token in the Subject: line of the message, >it's sent in the subject line in a mailto link. >(like so: ) > >I still use pine, and even it is able to "do the right thing"(tm) with >that... It's probably too early to rely on the ?subject=blah extension to mailto. I believe all the mail clients that I have "attached" to mailto understand about the ?subject=... extension to mailto. (It's hard to be sure...more often than not, I don't use the mailto link but copy the address, instead, and paste it into the mail program which has the account I want to send from.) But what about all those people who haven't upgraded anything since they took the machine out of the box in 1997? Does that era Outlook Express understand (if they haven't upgraded anything, they're using Outlook Express)? (A 1997 Mac would be using Claris Emailer, which I don't think does understand the subject extension to mailto. But the number of those is small.) These are the people most likely to be troubled by following the instructions ("click this thing") and having it not work. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From claw@kanga.nu Fri Apr 5 06:49:18 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 04 Apr 2002 22:49:18 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 05 Apr 2002 00:13:44 EST." <15533.12936.337697.857925@anthem.wooz.org> References: <15533.12936.337697.857925@anthem.wooz.org> Message-ID: <30550.1017989358@kanga.nu> On Fri, 5 Apr 2002 00:13:44 -0500 Barry A Warsaw wrote: > E.g. we could shut off email confirms altogether and force only web > confirmations. Or we could be more Majordomo-ish as JC describes. A base problem is barrier to entry: Barrier to entry for stupid software and barrier to entry for users who are uncomfortable with email systems (or who just don't understand them). While I don't want to target Mailman at 96yr old charming wee grandmothers who are still not quite sure about anything since Truman, it doesn't hurt to be friendly to them and the current JUST-REPLY-TO-THIS-MESSAGE confirmation is pretty grandmother friendly if you are going to retain a double-opt-in. Moving to the MD-like model I described gives significant extra opportunities for the non-technical grandmothers of the world to be confused, make errors, and in general not get the service they would like from Mailman. No, its not that the MD approach is terribly complex at the UI level, its that its at least an order of magnitude more complex than the current JUST-REPLY model. Think about it in terms of number of stupid/silly/dumb/oh-my-gawds-how-did-they-do-that things that a user could do in editing his reply down to the token versus the current just-hit-reply-and-send. I like grandmothers. I'd like them to like Mailman. I'd also like them not to be pissed off at Mailman because it throws stupid auto-responder messages at them. Suggest: Keep the just-hit-reply model, Accomplish this as follows: Put the token both in the Subject: and the beginning of the message. Search the reply message for the token in Subject: and the first N (N<10) lines of the message. The token has to exist in BOTH for the conformation to be successful. This puts an extra onus on the confirm message writers and translators: The token must be restated very close to the beginning of the message (probably within the first 4 lines). I think that's a fairly acceptable constraint. The 10 line limit should be enough padding to allow the translators some slack, to adapt to grody MIME/HTML wrapping, but to not pick up stupid auto responders which bounce messages back with a leading prefix/vacation/comment. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Fri Apr 5 06:51:03 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 04 Apr 2002 22:51:03 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 05 Apr 2002 01:01:44 EST." <15533.15816.2855.262192@anthem.wooz.org> References: <15533.12936.337697.857925@anthem.wooz.org> <15533.15816.2855.262192@anthem.wooz.org> Message-ID: <30572.1017989463@kanga.nu> On Fri, 5 Apr 2002 01:01:44 -0500 Barry A Warsaw wrote: > The former is already implemented in MM2.1; it's just optional not > mandatory. The latter is an interesting idea, but I don't how > burdensome that would be on people with today's MUA's (XEmacs/VM > handles it, and is that really the only one that matters :). It seems reasonable as another possible approach, but I sure as heck wouldn't make it the only approach, or the only email-based approach. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Fri Apr 5 07:07:25 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 04 Apr 2002 23:07:25 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <15533.12936.337697.857925@anthem.wooz.org> Message-ID: On 4/4/02 9:13 PM, "Barry A. Warsaw" wrote: > CVR> I finally had to address probe the entire list, because the > CVR> mailbot was coming back from a domain that wasn't subscribed > > Won't the VERP-ish support in MM2.1 make your life so much easier? > (Coming as someone who's had to do the same thing on occasion.) Yes, although in this case, they're sending back a new message to the "from" address, throwing out everything but the subject, which they insert into their subject line. So I think this mailbot through a forwarded address would evade even VERP. > It's a real issue, and as I see it there is no right answer, there are > only trade-offs. Yeah. My feelings exactly. And I'm not the one to draw lines in the sand here. > So I don't know. I'm inclined to favor user convenience for now, but > I've no doubt that we'll have to re-debate this decision as time goes > by. Unless someone comes with with an idea that turns this from a minor problem into a less-minor one, I agree. Examples of these problems really happening would help sway me... I'd be a lot more worried if it didn't require braindamage on the part of the other side, but we can't blame stupid users for stupid IS departments, either... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From chuqui@plaidworks.com Fri Apr 5 07:09:32 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 04 Apr 2002 23:09:32 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <30550.1017989358@kanga.nu> Message-ID: On 4/4/02 10:49 PM, "J C Lawrence" wrote: > Suggest: > > Keep the just-hit-reply model, How about keeping the reply model, but requiring the reply come from the address being subscribed? That'd throw out corporate-braindamage-mailbots unless they're amazingly braindamaged and forge email AS the user. It wouldn't protect someone from a broken procmail mailbot, but if they write their own, caveat emptor anyway. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From stephen@xemacs.org Fri Apr 5 08:14:42 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 05 Apr 2002 17:14:42 +0900 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: References: Message-ID: <877knmv9xp.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Chuq" == Chuq Von Rospach writes: Chuq> we can't blame stupid users for stupid IS departments, Chuq> either... Unfortunately, stupid IS departments can blame anybody else and make it stick, too. If the U Legal (worse, U Purchasing) autoresponder gets mailbombed from my Mailman server, guess who gets shut down? If they can take away all ICMP, they sure can take away tcp/25. :-( I'm definitely in favor of some preventive paranoia. Not too much (probably this thread is enough for now), but I'm glad you brought it up. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From jeske@chat.net Fri Apr 5 09:12:58 2002 From: jeske@chat.net (David Jeske) Date: Fri, 5 Apr 2002 01:12:58 -0800 Subject: [Mailman-Developers] templating, search, and stuff... Message-ID: <20020405011258.A9109@mozart.chat.net> I've manually dug through one too many pipermail archives, so I've decided it's time to help fix the problem by connecting a search index to mailman/pipermail. I'm probably going to use mifluz (after I swig a python wrapper for it). If anyone has this in progress or wants to coordinate on it, drop me a note. Also, in fishing through the TODO list, I notice that adding some kind of templating system is still on there. I want to point [whomever] at a really easy to use and fast templating system called Clearsilver. It's a open-source cousin to the template system we used at eGroups.com and is still used for Yahoo Groups, and it's 'really great'. I'd love to convert Mailman over myself, but I'm quite sure I won't find the time. If someone wants to put work into this, I'm happy to help with some tech support and examples. Of course it already has a Python wrapper, as much of eGroups.com (and some of Yahoo Groups) is written in Python. http://www.clearsilver.net/ -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From barry@zope.com Fri Apr 5 14:43:53 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 09:43:53 -0500 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 References: <15532.49438.250712.852479@anthem.wooz.org> <200204050812.g358Cr015296@sun31.imbi.uni-freiburg.de> Message-ID: <15533.47145.449745.498365@anthem.wooz.org> >>>>> "GK" == Georg Koch writes: GK> but I cannot, because MailList.py stops with an uncatched GK> exception first. __load is called from load like this: | for file in (pfile, plast, dfile, dlast): | dict, e = self.__load(file) GK> so in __load the mtime of non-existing config.pck is asked and GK> yields the exception which is not handled. Feh, I'm a big dummy. Please try the attached patch. -Barry Index: MailList.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v retrieving revision 2.67 retrieving revision 2.68 diff -u -r2.67 -r2.68 --- MailList.py 1 Apr 2002 16:31:25 -0000 2.67 +++ MailList.py 5 Apr 2002 14:43:28 -0000 2.68 @@ -493,14 +493,21 @@ loadfunc = cPickle.load else: assert 0, 'Bad database file name' - mtime = os.path.getmtime(dbfile) - if mtime <= self.__timestamp: - # File is not newer - return None, None try: + # Check the mod time of the file first. If it matches our + # timestamp, then the state hasn't change since the last time we + # loaded it. Otherwise open the file for loading, below. If the + # file doesn't exist, we'll get an EnvironmentError with errno set + # to ENOENT (EnvironmentError is the base class of IOError and + # OSError). + mtime = os.path.getmtime(dbfile) + if mtime <= self.__timestamp: + # File is not newer + return None, None fp = open(dbfile) - except IOError, e: + except EnvironmentError, e: if e.errno <> errno.ENOENT: raise + # The file doesn't exist yet return None, e try: try: From barry@zope.com Fri Apr 5 14:56:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 09:56:31 -0500 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... References: <30550.1017989358@kanga.nu> Message-ID: <15533.47903.872131.497390@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> How about keeping the reply model, but requiring the reply CVR> come from the address being subscribed? It was, at one point, a requirement. Say I subscribe to a list via the web, typing in my work address. But my work address forwards to my home address, so I see the confirmation at home. Now I reply but I don't know how to fiddle with my From: header to make it look like the reply came from my work address. I can't subscribe. So you ask, why would I have subscribed my work address if I'm going to be reading (and replying to) it from home? Maybe it's a list related to my technical responsibilities at work and I've been "asked" by management to advertise my work address. But the same management doesn't really care where I read my email as long as I get my job done. It never mattered in the world of wide-open posting rules. In a predominantly members-only world it probably makes less sense for me to play these games. But in a (future) world where I can attach several email addresses to my account, maybe it matters more. Regardless, it's too late in the game to change this for MM2.1. Let's see where the world is for the next version -- maybe it makes sense to change (or make configurable) this policy. -Barry From barry@zope.com Fri Apr 5 15:19:09 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 10:19:09 -0500 Subject: [Mailman-Developers] templating, search, and stuff... References: <20020405011258.A9109@mozart.chat.net> Message-ID: <15533.49261.981759.102450@anthem.wooz.org> >>>>> "DJ" == David Jeske writes: DJ> Also, in fishing through the TODO list, I notice that adding DJ> some kind of templating system is still on there. Improving the templating system (for MM3) is more than just picking one and going with it. The real issue is that folks want to put all kinds of web skins on Mailman, to integrate them into their own way of managing their sites. Some people don't care about the integration, and for them we can pick a Good One and use that as the default. But they've got to be able to chuck it, design their own web interface, and integrate it easily into Mailman. For that we need APIs, a clean architecture, and component-like system. -Barry From nb@thinkcoach.com Fri Apr 5 15:25:48 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Fri, 5 Apr 2002 17:25:48 +0200 Subject: [Mailman-Developers] templating, search, and stuff... In-Reply-To: <15533.49261.981759.102450@anthem.wooz.org> (barry@zope.com) References: <20020405011258.A9109@mozart.chat.net> <15533.49261.981759.102450@anthem.wooz.org> Message-ID: <200204051525.g35FPmT01666@quill.local> > Improving the templating system (for MM3) is more than just picking > one and going with it. The real issue is that folks want to put all > kinds of web skins on Mailman, to integrate them into their own way of > managing their sites. Some people don't care about the integration, > and for them we can pick a Good One and use that as the default. But > they've got to be able to chuck it, design their own web interface, > and integrate it easily into Mailman. For that we need APIs, a clean > architecture, and component-like system. I'd suggest to look at what phpGroupWare is doing and be as compatible with that as possible. Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From jra@baylink.com Fri Apr 5 17:11:25 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 5 Apr 2002 12:11:25 -0500 Subject: [Mailman-Developers] Silly mailman question In-Reply-To: <3C9F324F.5070906@daa.com.au>; from James Henstridge on Mon, Mar 25, 2002 at 10:21:03PM +0800 References: <3C9F324F.5070906@daa.com.au> Message-ID: <20020405121125.08339@scfn.thpl.lib.fl.us> I have a client who wishes to send a bunch of mail. They're good little boys and girls; the address are all opt-in, to my personal knowledge. The problem is that they're already in a database (filePro for Unix on SCO 5, on a machine behind a Linux 7.1 firewall), and they want to be able to selectwhom to mail on an adhoc basis. This seems to suggest to *me* that I need to be able to either 1) set up and strike lists on the mailman side with some dispatch, or better 2) wire mailman atop the extant database... which I would prefer to do because I *don't* want to lose the web-based signoff stuff, etc. I know this is a pretty kettle of fish; anyone have any suggestions? I'm willing to take a swing at writing a Python module to encompass filePro if I have to do that, but I'm not sure that's enough here: the user data isn't *in* a 'database' yet, is it? This is, of course, a paying gig... and it's not impossible I might sub out the "interface the back of Mailman to my database" part, particularly if it can be done generally enough to make accessing filePro data from Python easy, since that's something I'd find generically useful. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From barry@zope.com Fri Apr 5 17:24:38 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 12:24:38 -0500 Subject: [Mailman-Developers] Silly mailman question References: <3C9F324F.5070906@daa.com.au> <20020405121125.08339@scfn.thpl.lib.fl.us> Message-ID: <15533.56790.878771.227412@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> The problem is that they're already in a database (filePro JRA> for Unix on SCO 5, on a machine behind a Linux 7.1 firewall), JRA> and they want to be able to selectwhom to mail on an adhoc JRA> basis. JRA> This seems to suggest to *me* that I need to be able to JRA> either 1) set up and strike lists on the mailman side with JRA> some dispatch, or better 2) wire mailman atop the extant JRA> database... which I would prefer to do because I *don't* want JRA> to lose the web-based signoff stuff, etc. Can you use MM2.1? If so, then your options are many. If the membership list needs to change on the fly, then use the new "virtual list" feature. I.e. create a list that all the message will appear to come from but build the recipient list on-the-fly. The easiest way to do this is, use a Python program to suck the data out of filePro (I've no idea how to do that), and build a Python list of recipients addresses. Then, make sure the installed Mailman package is in your sys.path (so your driver script can import Mailman modules). Assuming you've got the listname, the list of recipients, and the message as plain text, it might be as simple as: from Mailman.Post import inject inject(listname, msgtext, recipients) Note that Mailman/Post.py can also be run as a command line script. Alternatively, you might want to use the new extend.py interface to hook into the MailList instance for your list. If there's a file called extend.py in your lists/listname directory, it will be execfile()'d and a function extend() will be called, passing in the MailList instance. Your extend() function can do something like, overload the Load() and Save() method so that membership data is funneled to your database. You probably just need to re-implement the MemberAdaptor.py interface and set the mlist._memberadaptor attribute to your customized version. Then everything else should Just Work. If you're stuck on MM2.0.x, then you've got your work cut out for you . JRA> This is, of course, a paying gig... and it's not impossible I JRA> might sub out the "interface the back of Mailman to my JRA> database" part, particularly if it can be done generally JRA> enough to make accessing filePro data from Python easy, since JRA> that's something I'd find generically useful. It would be nice if this was spec'd as being releasable under the Python license, so it could be donated back to Python. HTH, -Barry From chuqui@plaidworks.com Fri Apr 5 17:24:48 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 05 Apr 2002 09:24:48 -0800 Subject: [Mailman-Developers] Silly mailman question In-Reply-To: <20020405121125.08339@scfn.thpl.lib.fl.us> Message-ID: On 4/5/02 9:11 AM, "Jay R. Ashworth" wrote: > I know this is a pretty kettle of fish; anyone have any suggestions? > > I'm willing to take a swing at writing a Python module to encompass > filePro if I have to do that, but I'm not sure that's enough here: the > user data isn't *in* a 'database' yet, is it? Sounds like a job for 2.1's external database API... Before anything else, at least, I'd look into it and see how close it comes to your needs. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From jra@baylink.com Fri Apr 5 17:53:23 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 5 Apr 2002 12:53:23 -0500 Subject: [Mailman-Developers] Silly mailman question In-Reply-To: <15533.56790.878771.227412@anthem.wooz.org>; from "Barry A. Warsaw" on Fri, Apr 05, 2002 at 12:24:38PM -0500 References: <3C9F324F.5070906@daa.com.au> <20020405121125.08339@scfn.thpl.lib.fl.us> <15533.56790.878771.227412@anthem.wooz.org> Message-ID: <20020405125323.04534@scfn.thpl.lib.fl.us> On Fri, Apr 05, 2002 at 12:24:38PM -0500, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> The problem is that they're already in a database (filePro > JRA> for Unix on SCO 5, on a machine behind a Linux 7.1 firewall), > JRA> and they want to be able to selectwhom to mail on an adhoc > JRA> basis. > > JRA> This seems to suggest to *me* that I need to be able to > JRA> either 1) set up and strike lists on the mailman side with > JRA> some dispatch, or better 2) wire mailman atop the extant > JRA> database... which I would prefer to do because I *don't* want > JRA> to lose the web-based signoff stuff, etc. > > Can you use MM2.1? If so, then your options are many. Ghod I love the net. At the moment, the only requirement is that it *work* when I'm done. :-) Is the Member Adaptor stuff *in* 2.1? Cool; I thought that was 3.0 stuff. > If the membership list needs to change on the fly, then use the new > "virtual list" feature. I.e. create a list that all the message will > appear to come from but build the recipient list on-the-fly. The > easiest way to do this is, use a Python program to suck the data out > of filePro (I've no idea how to do that), and build a Python list of > recipients addresses. Then, make sure the installed Mailman package > is in your sys.path (so your driver script can import Mailman > modules). This is precisely what I needed; with one exception. > Assuming you've got the listname, the list of recipients, and the > message as plain text, it might be as simple as: > > from Mailman.Post import inject > inject(listname, msgtext, recipients) > > Note that Mailman/Post.py can also be run as a command line script. Noted. :-) > Alternatively, you might want to use the new extend.py interface to > hook into the MailList instance for your list. If there's a file > called extend.py in your lists/listname directory, it will be > execfile()'d and a function extend() will be called, passing in the > MailList instance. > > Your extend() function can do something like, overload the Load() and > Save() method so that membership data is funneled to your database. > You probably just need to re-implement the MemberAdaptor.py interface > and set the mlist._memberadaptor attribute to your customized > version. Then everything else should Just Work. Oh yeah; like it's gonna be that easy. This is what I really need, assuming as I do that it will allow the "unsubscribe" web page to link back into my live data... But I'm not sure how to get there from here. > JRA> This is, of course, a paying gig... and it's not impossible I > JRA> might sub out the "interface the back of Mailman to my > JRA> database" part, particularly if it can be done generally > JRA> enough to make accessing filePro data from Python easy, since > JRA> that's something I'd find generically useful. > > It would be nice if this was spec'd as being releasable under the > Python license, so it could be donated back to Python. Lvoe to go there if I can. If it gets someone a discount, that will make it easier. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From bwagner@potpie.org Fri Apr 5 17:53:40 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 09:53:40 -0800 (PST) Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py Message-ID: localhost.localdomain Good morning, First off, I'm sorry if this isn't the appropriate forum, but I felt it more appropriate than mailman-users. I'm running a Mandrake 8.0 box with qmail and have 2.0.9 running fine but am testing 2.1b1 and have run into a problem. When passing mail through qmail-to-mailman.py, lines 87 and 88 point to $prefix/mail/wrapper. I've done plenty of test installs of 2.1b1, but in none ofthem is there ever a $prefix/mail/wrapper. There's a mail/mailman, but that'snot what qmail-to-mailman.py looks for. I did a test and modified it to point tomail/mailman, but that results in a deferral like: Apr 5 09:46:25 oscar qmail: 1018028785.696995 delivery 1125: deferral: Illegal_command:_mailcmd/ So I was wondering if this is a known issue and if anyone might have an idea of a quick workaround. Is mail/wrapper now obsolete? Thanks, Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From jeske@chat.net Fri Apr 5 18:10:53 2002 From: jeske@chat.net (David Jeske) Date: Fri, 5 Apr 2002 10:10:53 -0800 Subject: [Mailman-Developers] templating, search, and stuff... In-Reply-To: <15533.49261.981759.102450@anthem.wooz.org> References: <20020405011258.A9109@mozart.chat.net> <15533.49261.981759.102450@anthem.wooz.org> Message-ID: <20020405101053.B9109@mozart.chat.net> On Fri, Apr 05, 2002 at 10:19:09AM -0500, Barry A. Warsaw wrote: > >>>>> "DJ" == David Jeske writes: > > DJ> Also, in fishing through the TODO list, I notice that adding > DJ> some kind of templating system is still on there. > > Improving the templating system (for MM3) is more than just picking > one and going with it. The real issue is that folks want to put all > kinds of web skins on Mailman, to integrate them into their own way of > managing their sites. First off, it's no skin off my back, I don't run or administer mailman, I just interact with them on several mailing lists so I'm happy to help out. However, if you look at Clearsilver, you'll find that it was designed to handle exactly this kind of skinning. We used it for cobranding and OEM deals back at eGroups. While integrating into Yahoo, we ran the old eGroups version of the UI in Japanese for six months while running every other language in the new "Yahoo UI", on the same codebase. It really excels at this. The majority of the "skinning" of the UI to the Yahoo look and feel took one engineer less than 10 days. > Some people don't care about the integration, and for them we can > pick a Good One and use that as the default. But they've got to be > able to chuck it, design their own web interface, and integrate it > easily into Mailman. For that we need APIs, a clean architecture, > and component-like system. If you read my paper on "dataset driven templating", you'll find that this is exactly what Clearsilver provides, in an extremely fast and easy to use package. There are other template systems that do this also, but for integrating with Python, Clearsilver is the fastest and most mature way to go. http://www.clearsilver.net/docs/apples_to_oranges.hdf http://www.clearsilver.net/docs/man_templates.hdf The "dataset" (like a simpler form of XML) is your API. It sits between the application logic and the page template, and allows you to easily skin the application. There are some advantages to using XML/XSLT instead, namely because you can write an XML schema and typecheck the XML output. However, considering Mailman is written in Python, I figure you all understand the development ease gained by using an untyped system over a typed one for small-ish projects like this. Anyhow, I'm not here to get into an off-topic templating thread. I just saw that Mailman still didn't have templates and I figured I'd offer up some assistance. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From jon@csh.rit.edu Fri Apr 5 18:34:31 2002 From: jon@csh.rit.edu (Jon Parise) Date: Fri, 5 Apr 2002 13:34:31 -0500 Subject: [Mailman-Developers] README.POSTFIX patch Message-ID: <20020405183430.GA4653@csh.rit.edu> --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It looks like README.POSTFIX is missing a word in here. See the attached patch. -- Jon Parise (jon@csh.rit.edu) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="README.POSTFIX.patch" Index: README.POSTFIX =================================================================== RCS file: /cvsroot/mailman/mailman/README.POSTFIX,v retrieving revision 2.8 diff -u -r2.8 README.POSTFIX --- README.POSTFIX 16 Mar 2002 06:02:41 -0000 2.8 +++ README.POSTFIX 5 Apr 2002 18:31:08 -0000 @@ -109,7 +109,7 @@ With Postfix-style virtual domains, things are a little trickier, although Mailman should work well with it. First, you'll need to - a path to Postfix's virtual_maps variable: + add a path to Postfix's virtual_maps variable: virtual_maps = , hash:/usr/local/mailman/data/virtual-mailman --YZ5djTAD1cGYuMQK-- From barry@zope.com Fri Apr 5 18:44:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 13:44:08 -0500 Subject: [Mailman-Developers] README.POSTFIX patch References: <20020405183430.GA4653@csh.rit.edu> Message-ID: <15533.61560.936189.576505@anthem.wooz.org> >>>>> "JP" == Jon Parise writes: JP> It looks like README.POSTFIX is missing a word in here. See JP> the attached patch. Fixed, thanks. -Barry From barry@zope.com Fri Apr 5 18:53:26 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 13:53:26 -0500 Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py Message-ID: <15533.62118.54237.246735@anthem.wooz.org> >>>>> "BW" == Bill Wagner writes: BW> First off, I'm sorry if this isn't the appropriate forum, but BW> I felt it more appropriate than mailman-users. This one's fine! BW> I'm running a Mandrake 8.0 box with qmail and have 2.0.9 BW> running fine but am testing 2.1b1 and have run into a problem. BW> When passing mail through qmail-to-mailman.py, lines 87 and 88 BW> point to $prefix/mail/wrapper. I've done plenty of test BW> installs of 2.1b1, but in none ofthem is there ever a BW> $prefix/mail/wrapper. There's a mail/mailman, but that'snot BW> what qmail-to-mailman.py looks for. I did a test and modified BW> it to point tomail/mailman, but that results in a deferral BW> like: I don't use qmail so it's up to the community to keep the qmail documentation and contribs up-to-date. BW> So I was wondering if this is a known issue and if anyone BW> might have an idea of a quick workaround. Is mail/wrapper now BW> obsolete? Yes, mail/wrapper is obsolete; it's been renamed mail/mailman to avoid unnecessary conflicts with MD's wrapper program. A dumb replace yields the following patch (committed to cvs, though if the whole file needs updating, please send contributions). -Barry Index: qmail-to-mailman.py =================================================================== RCS file: /cvsroot/mailman/mailman/contrib/qmail-to-mailman.py,v retrieving revision 2.1 retrieving revision 2.2 diff -u -r2.1 -r2.2 --- qmail-to-mailman.py 7 Sep 2001 23:18:47 -0000 2.1 +++ qmail-to-mailman.py 5 Apr 2002 18:53:01 -0000 2.2 @@ -84,8 +84,8 @@ local = re.sub(i[0],"",local) if os.path.exists(local): - os.execv(MailmanHome + "/mail/wrapper", - (MailmanHome + "/mail/wrapper", type, local)) + os.execv(MailmanHome + "/mail/mailman", + (MailmanHome + "/mail/mailman", type, local)) else: bounce() sys.exit(111) From bwagner@potpie.org Fri Apr 5 19:18:23 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 11:18:23 -0800 (PST) Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py Message-ID: localhost.localdomain Thanks for the reply, Barry. That patch basically just changes it to point to mail/mailman now, right? >From what I can tell, it's still not going to work. I know you said that qmailsupport's basically left up to the community, so I just want to get as much info out there as I can (as I don't know a damn thing about python) so maybe someone who does and uses qmail can try and fix this. At any rate, when changed to point to mail/mailman, the deferral message says that mailcmd is an illegal command. Is this something that's been left over from 2.0.x and has been depreciated for another equivalent in 2.1? I might not know any python, but I'm not afraid to hack code :) And on a similar line of questioning, in 2.0.x, there was an option available called MTA_ALIASES_STYLE which I'd typically set to 'qmail' in my Mailman/mm_cfg.py. It'd tell you what to do in order to create the .qmail-* files for the list but it doesn't seem to exist in 2.1 either? Am I right in this orjust smoking crack? Thanks again, Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From barry@zope.com Fri Apr 5 19:27:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 14:27:20 -0500 Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py Message-ID: <15533.64152.551886.118804@anthem.wooz.org> >>>>> "BW" == Bill Wagner writes: BW> That patch basically just changes it to point to mail/mailman BW> now, right? Check cvs because I also just caught up on a few changes that Ben Gertzfield contributed. >> From what I can tell, it's still not going to work. I know you >> said that BW> qmailsupport's basically left up to the community, so I just BW> want to get as much info out there as I can (as I don't know a BW> damn thing about python) so maybe someone who does and uses BW> qmail can try and fix this. BW> At any rate, when changed to point to mail/mailman, the BW> deferral message says that mailcmd is an illegal command. Is BW> this something that's been left over from 2.0.x and has been BW> depreciated for another equivalent in 2.1? I might not know BW> any python, but I'm not afraid to hack code :) It would help to see the exact error message. If mailcmd is exiting with an error code 2, it's probably the classic wrong-gid problem: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.004.htp If it's something else, then check cvs and see if the latest updates fix the problem. BW> And on a similar line of questioning, in 2.0.x, there was an BW> option available called MTA_ALIASES_STYLE which I'd typically BW> set to 'qmail' in my Mailman/mm_cfg.py. It'd tell you what to BW> do in order to create the .qmail-* files for the list but it BW> doesn't seem to exist in 2.1 either? Am I right in this BW> orjust smoking crack? Correct, this isn't useful anymore. For someone who is knowledgeable about qmail, the thing to do is to take Mailman/MTA/Manual.py and port the output to qmail and wrap it all in a file appropriate for Mailman/MTA/Qmail.py. This would allow you to set this in your mm_cfg.py file: MTA = 'Qmail' Then again, it'd be better if qmail could just be taught to automatically recognize Mailman lists, but again, I don't know enough about qmail to write the appropriate recipes. -Barry From barry@zope.com Fri Apr 5 19:41:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 14:41:27 -0500 Subject: [Mailman-Developers] mm-handler redux References: <200203291233.g2TCXAm16595@babylon5.cc.vt.edu> Message-ID: <15533.64999.701676.595348@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Ok. Diff against cvs again. Handles the VERP tokens just RJ> fine. If I wasn't *still* here fiddling at 7am it'd probably RJ> be a tad more elegant, but it work. Thanks, I've just committed this to cvs. -Barry From bwagner@potpie.org Fri Apr 5 19:50:35 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 11:50:35 -0800 (PST) Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py In-Reply-To: <15533.64152.551886.118804@anthem.wooz.org> References: <15533.64152.551886.118804@anthem.wooz.org> Message-ID: localhost.localdomain Barry A. Warsaw said: > Check cvs because I also just caught up on a few changes that Ben > Gertzfield contributed. Right arm. Sorry to be a complete wanker, but how does one do a CVS check on the MM source? > It would help to see the exact error message. If mailcmd is exiting > with an error code 2, it's probably the classic wrong-gid problem: I actually had it in the original post, but this is the error message: Apr 5 09:06:06 oscar qmail: 1018026366.050684 delivery 1083: deferral: Illegal_command:_mailcmd/ I don't think this is a gid problem as the same compile time options were passwd w/ 2.0.x and that works fine. And when changed back to look for mail/wrapper, it fails with the "no such file or directory" error. I didn't know ifthere were something in the mail/mailman > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.004.htp > > If it's something else, then check cvs and see if the latest updates > fix the problem. Will do. (Just need to know how to do a CVS check out) :/ > Correct, this isn't useful anymore. > > For someone who is knowledgeable about qmail, the thing to do is to > take Mailman/MTA/Manual.py and port the output to qmail and wrap it all > in a file appropriate for Mailman/MTA/Qmail.py. This would allow you > to set this in your mm_cfg.py file: > > MTA = 'Qmail' > > Then again, it'd be better if qmail could just be taught to > automatically recognize Mailman lists, but again, I don't know enough > about qmail to write the appropriate recipes. Are there no developers running qmail? I know most run postfix, but I figured that qmail's a large enough player that someone would be working on it. Thanks again, Barry, Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From bwagner@potpie.org Fri Apr 5 20:05:58 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 12:05:58 -0800 (PST) Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py In-Reply-To: localhost.localdomain References: localhost.localdomain Message-ID: localhost.localdomain Bill Wagner said: > Barry A. Warsaw said: >> Check cvs because I also just caught up on a few changes that Ben >> Gertzfield contributed. > > Right arm. Sorry to be a complete wanker, but how does one do a CVS > check on the MM source? Scratch that. I've got it. Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From bwagner@potpie.org Fri Apr 5 21:08:06 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 13:08:06 -0800 (PST) Subject: [Mailman-Developers] Almost there (was Problem in 2.1b1's contrib/qmail-to-mailman.py) In-Reply-To: localhost.localdomain References: localhost.localdomain Message-ID: localhost.localdomain Ok, I apologise for my barrage of posts today, but I've almost got it going. I've got the new CVS going and everything's working -- almost. New lists have been created, I've subscribed, and posted to the new test list, but for some reason, they're just chillin in the queue. I've grepped for my email address in ~mailman and have found: # egrep -r bwagner ./* Binary file ./lists/testlist/config.pck.last matches Binary file ./lists/testlist/config.pck matches ./logs/subscribe:Apr 05 12:37:40 2002 (16207) testlist: new bwagner@potpie.org () ./qfiles/shunt/1018039960.229399+8efa8570c2cee99ba7839981b7374cc53646daad.pck:Message-IDUlocalhost.localdomaint(UDateU$Fri,5 Apr 2002 12:52:39 -0800 (PST)t(USubjectUasdft(UFromU""Bill Wagner" t(UToUtestlist@lists.potpie.org>t(U mailmanctl is running and the cronjob's in place so I don't know the next step. I'm presuming that all messages go into the shunt dir first before being delivered, (is this incorrect?) but what would cause them to not be flushed? Thanks again, Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From barry@zope.com Fri Apr 5 21:31:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 16:31:08 -0500 Subject: [Mailman-Developers] Almost there (was Problem in 2.1b1's contrib/qmail-to-mailman.py) Message-ID: <15534.6044.444085.592264@anthem.wooz.org> >>>>> "BW" == Bill Wagner writes: BW> mailmanctl is running and the cronjob's in place so I don't BW> know the next step. I'm presuming that all messages go into BW> the shunt dir first before being delivered, (is this BW> incorrect?) but what would cause them to not be flushed? qfiles/shunt is where messages go when Mailman is behaving snooty, i.e. there are bugs. You'll always get tracebacks in logs/error when this happens. Messages never get unshunted automatically, the standard rhythm is you fix the bugs and then run bin/unshunt to throw them back into whatever queue they were in when the bugs occurred. What's in logs/error? -Barry From bwagner@potpie.org Fri Apr 5 21:39:20 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 13:39:20 -0800 (PST) Subject: [Mailman-Developers] Almost there (was Problem in 2.1b1's contrib/qmail-to-mailman.py) In-Reply-To: <15534.6044.444085.592264@anthem.wooz.org> References: <15534.6044.444085.592264@anthem.wooz.org> Message-ID: localhost.localdomain Barry A. Warsaw said: > qfiles/shunt is where messages go when Mailman is behaving snooty, i.e. > there are bugs. You'll always get tracebacks in logs/error when this > happens. Messages never get unshunted automatically, the > standard rhythm is you fix the bugs and then run bin/unshunt to > throw them back into whatever queue they were in when the bugs > occurred. > > What's in logs/error? Makes sense. Here's what's in logs/error (sorry for the formatting): --- Apr 05 12:52:40 2002 (16208) Uncaught runner exception: 'NoneType' object has no attribute 'split' Apr 05 12:52:40 2002 (16208) Traceback (most recent call last): File "/home/vpopmail/mailman.cvs/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/vpopmail/mailman.cvs/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/vpopmail/mailman.cvs/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/vpopmail/mailman.cvs/Mailman/Queue/IncomingRunner.py", line 152, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/vpopmail/mailman.cvs/Mailman/Handlers/Moderate.py", line 43, in process for sender in msg.get_senders(): File "/home/vpopmail/mailman.cvs/Mailman/Message.py", line 131, in get_senders pairs.append(fieldval.split()[1]) AttributeError: 'NoneType' object has no attribute 'split' --- Thanks again, Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From barry@zope.com Fri Apr 5 22:02:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 17:02:48 -0500 Subject: [Mailman-Developers] Almost there (was Problem in 2.1b1's contrib/qmail-to-mailman.py) References: <15534.6044.444085.592264@anthem.wooz.org> Message-ID: <15534.7944.843739.720556@anthem.wooz.org> >>>>> "BW" == Bill Wagner writes: BW> Makes sense. Here's what's in logs/error (sorry for the BW> formatting): Hmm, this means your messages aren't getting unix-from headers from your MTA. Can you send me a .db/.pck pair from your shunt directory? And which MTA are you using again? Message.get_unixfrom() returns None if there's no envelope, and obviously None has no split() method. The attached patch should do the trick. Apply it, re-install, "mailmanctl restart", and then bin/unshunt. Everything should go through now. Thanks, -Barry Index: Message.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Message.py,v retrieving revision 2.16 diff -u -r2.16 Message.py --- Message.py 12 Mar 2002 07:35:48 -0000 2.16 +++ Message.py 5 Apr 2002 22:01:41 -0000 @@ -126,7 +126,8 @@ pairs = [] for h in headers: if h is None: - fieldval = self.get_unixfrom() + # get_unixfrom() returns None if there's no envelope + fieldval = self.get_unixfrom() or '' try: pairs.append(fieldval.split()[1]) except IndexError: From bwagner@potpie.org Fri Apr 5 22:44:29 2002 From: bwagner@potpie.org (Bill Wagner) Date: Fri, 5 Apr 2002 14:44:29 -0800 (PST) Subject: [Mailman-Developers] Almost there (was Problem in 2.1b1's contrib/qmail-to-mailman.py) In-Reply-To: <15534.7944.843739.720556@anthem.wooz.org> References: <15534.7944.843739.720556@anthem.wooz.org> Message-ID: localhost.localdomain Thanks Barry! That did the trick! (BTW, I'm sure it's near the bottom of your TODO list, you might want to eventually update $MailmanHome in contrib/qmail-to-mailman.py to reflect MM's new $HOME of /usr/local/mailman). Barry A. Warsaw said: > Hmm, this means your messages aren't getting unix-from headers from > your MTA. Can you send me a .db/.pck pair from your shunt directory? > And which MTA are you using again? I'm using qmail. Did you still want the .db/.pck files? Thanks again, Bill -- Did you hear that, Marge? She called me a baboon! The stupidest, ugliest, smelliest ape of them all! -- Homer Simpson Lisa's Substitute From barry@zope.com Fri Apr 5 22:51:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 17:51:19 -0500 Subject: [Mailman-Developers] Almost there (was Problem in 2.1b1's contrib/qmail-to-mailman.py) References: <15534.7944.843739.720556@anthem.wooz.org> Message-ID: <15534.10855.551712.675847@anthem.wooz.org> >>>>> "BW" == Bill Wagner writes: BW> That did the trick! (BTW, I'm sure it's near the bottom of BW> your TODO list, you might want to eventually update BW> $MailmanHome in contrib/qmail-to-mailman.py to reflect MM's BW> new $HOME of /usr/local/mailman). Done. BW> I'm using qmail. Did you still want the .db/.pck files? Naw, I don't think I need them. Thanks, -Barry From barry@zope.com Sat Apr 6 02:17:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 5 Apr 2002 21:17:50 -0500 Subject: [Mailman-Developers] SF bug report #223533 Message-ID: <15534.23246.975895.526224@anthem.wooz.org> I'm in a mad quest to reduce the number of open Mailman bugs to under 50 so it fits on one page. I'm nearly there. I'd like to get some feedback on bug #223533: http://sourceforge.net/tracker/index.php?func=detail&aid=223533&group_id=103&atid=100103 It's fairly old but it's complaining that there is no way to tell the difference between a list posting and an administrative message via the List-* headers. I think it's actually recommending to add another header(!) only to list postings. I'm basing my opinion on RFCs 2919 and 2369: http://www.faqs.org/rfcs/rfc2919.html http://www.faqs.org/rfcs/rfc2369.html The former outlines the List-ID: header and the latter outlines all the other List-* headers. Both of them describe when to add the headers to an outgoing message: [language taken from RFC 2369, but 2919 is the same -BAW] 3. The List Header Fields This document presents header fields which will provide the command syntax description for the 'core' and key secondary functions of most email distribution lists. The fields implemented on a given list SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to one distinct list. There MUST be no more than one of each field present in any given message. These fields MUST only be generated by mailing lists, not end users. My interpretation of this paragraph says that Mailman is doing the right thing by adding all those headers to all outgoing messages. The complaint is that you can't reliably set up something like a procmail filter to distinguish between admin messages and postings, but I think we're being standards compliant here and I'm inclined to close this bug report as Won't Fix. I'm open to other opinions. -Barry From marc_news@vasoftware.com Sat Apr 6 03:14:56 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 5 Apr 2002 19:14:56 -0800 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15534.23246.975895.526224@anthem.wooz.org> References: <15534.23246.975895.526224@anthem.wooz.org> Message-ID: <20020406031456.GJ21237@merlins.org> On Fri, Apr 05, 2002 at 09:17:50PM -0500, Barry A. Warsaw wrote: > I'm in a mad quest to reduce the number of open Mailman bugs to under > 50 so it fits on one page. I'm nearly there. I'll get someone to increase the page length to 100 bugs. No, don't thank me, I'm just glad I could help :-))) > I'd like to get some feedback on bug #223533: > > http://sourceforge.net/tracker/index.php?func=detail&aid=223533&group_id=103&atid=100103 > > It's fairly old but it's complaining that there is no way to > tell the difference between a list posting and an administrative > message via the List-* headers. I think it's actually recommending to > add another header(!) only to list postings. (...) > My interpretation of this paragraph says that Mailman is doing the > right thing by adding all those headers to all outgoing messages. The > complaint is that you can't reliably set up something like a procmail > filter to distinguish between admin messages and postings, but I think > we're being standards compliant here and I'm inclined to close this > bug report as Won't Fix. Actually I've found this annoying too, to be honest. I guess one way to remain really compliant would be to add, yes, yet another header to admin messages, something like X-Mailman-Administrativa: Yes Marc PS: Should I continue to bug you about my two patches, one being the bugfix for SMTP_MAX_SESSIONS_PER_CONNECTION ? -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From Dan Mick Sat Apr 6 03:26:09 2002 From: Dan Mick (Dan Mick) Date: Fri, 5 Apr 2002 19:26:09 -0800 (PST) Subject: [Mailman-Developers] SF bug report #223533 Message-ID: <200204060326.g363QHWk023817@utopia.West.Sun.COM> > I'd like to get some feedback on bug #223533: > > http://sourceforge.net/tracker/index.php?func=detail&aid=223533&group_id=103&ati d=100103 > > It's fairly old but it's complaining that there is no way to > tell the difference between a list posting and an administrative > message via the List-* headers. What's an "administrative message"? From chuqui@plaidworks.com Sat Apr 6 03:39:54 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 05 Apr 2002 19:39:54 -0800 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15534.23246.975895.526224@anthem.wooz.org> Message-ID: On 4/5/02 6:17 PM, "Barry A. Warsaw" wrote: > It's fairly old but it's complaining that there is no way to > tell the difference between a list posting and an administrative > message via the List-* headers. I think it's actually recommending to > add another header(!) only to list postings. I've felt that including list-id on administrative messages is a bug. If you read 2919, it says this: This header SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to this particular distinct list. It clearly isn't being distributed by the list. Does an admin message apply to a particular distinct list? Yesbut. These messages aren't coming from the mailing list, but the list server. I think it's appropriate that any message from list foobar@domain.org going to an end user be flagged with a list-id of foobar.domain.org. But messages sent to an admin aren't coming from foobar. They're coming from mailman. I feel that flagging them with a list-id of foobar.domain.org is incorrect, because the source is the server, not the list. It's about the list, but not from the list. I think that's an important distinction. I would argue that administrative messages be flagged with a list-id identifying the server, not any specific list. In other words, I'm suggesting: List-ID: mailman.domain.org I think that's appropriate for the situation, and acceptable within the rules. Whether you agree depends on how you interpret that clause in 2919, which I argue is ambiguous, because I think the INTENT is to include specific to the list, and it doesn't handle the situation we're talking about. These are messages about a list, but not from the list, so I'm arguing that you shouldn't flag them with the list's list-id. I think you could also argue that since they aren't coming from the list, there should be NO list-id. I could live with that, too, but I think it's useful to flag these as messages from the daemon for filtering purposes, and I think I'm extending the RFC a bit but in a reasonable way. I just think flagging admin messages with the list's list-id is wrong. It should either be a server-id, or not there. Chuq -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From jarrell@vt.edu Sat Apr 6 04:28:10 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 05 Apr 2002 23:28:10 -0500 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 In-Reply-To: <15532.49438.250712.852479@anthem.wooz.org> References: <200204040835.g348Z9010575@sun31.imbi.uni-freiburg.de> Message-ID: <5.1.0.14.2.20020405232737.00a3ac50@lennier.cc.vt.edu> At 04:09 PM 4/4/02 -0500, Barry A. Warsaw wrote: > GK> OSError: [Errno 2] No such file or directory: > GK> '/h/mailman/lists/test/config.pck' > > GK> because the configuration is stored as config.db. > > GK> How do I convert the config.db to config.pck ? > >You don't. While the error message is misleading, your config.db file >will be automatically updated to config.pck the first time you load >your list (via web, qrunner, or command line script). Ah hah. And you didn't believe me when I posted the comment a while back that it really shouldn't do that... From jarrell@vt.edu Sat Apr 6 04:41:35 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 05 Apr 2002 23:41:35 -0500 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <15533.12936.337697.857925@anthem.wooz.org> References: Message-ID: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> At 12:13 AM 4/5/02 -0500, Barry A. Warsaw wrote: >E.g. we could shut off email confirms altogether and force only web >confirmations. Or we could be more Majordomo-ish as JC describes. I think all potential subscribers to *any* mailman list should be required to trek in person to a lonely abandoned silo in Montana where they will descend, following the directions in the confirm note, knock three times on the control room door, and be greeted by a grumpy gnome of a man named Melvin, who'll shriek "What! What! Why do you all keep bothering me? Don't you have enough to do without being on *another* mailinglist??" At which point he'll refuse to confirm your subscription unless you can bring him a shrubbery. From marc_news@vasoftware.com Sat Apr 6 04:42:35 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 5 Apr 2002 20:42:35 -0800 Subject: [Mailman-Developers] Problem in 2.1b1's contrib/qmail-to-mailman.py Message-ID: <20020406044234.GL21237@merlins.org> On Fri, Apr 05, 2002 at 11:50:35AM -0800, Bill Wagner wrote: > > Then again, it'd be better if qmail could just be taught to > > automatically recognize Mailman lists, but again, I don't know enough > > about qmail to write the appropriate recipes. > > Are there no developers running qmail? I know most run postfix, but I > figured that qmail's a large enough player that someone would be working > on it. I think one contributed factor is that at least some of us do not bear much love for DJB, his stupid license (or lack thereof) and his general thickheadedness. http://www.linuxmafia.com/~rick/faq/#djb if you're curious. Since you had postfix and exim, life is too short to have to bother with qmail or DJB software if there are reasonable alternatives out there IMO If you're going to flame me, do it in private please :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Sat Apr 6 04:46:04 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 5 Apr 2002 20:46:04 -0800 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <200204060326.g363QHWk023817@utopia.West.Sun.COM> References: <15534.23246.975895.526224@anthem.wooz.org> <200204060326.g363QHWk023817@utopia.West.Sun.COM> Message-ID: <20020406044604.GM21237@merlins.org> On Fri, Apr 05, 2002 at 07:26:09PM -0800, Dan Mick wrote: > > It's fairly old but it's complaining that there is no way to > > tell the difference between a list posting and an administrative > > message via the List-* headers. > > What's an "administrative message"? message foo needs moderation user bar joined the list On Fri, Apr 05, 2002 at 07:39:54PM -0800, Chuq Von Rospach wrote: > On 4/5/02 6:17 PM, "Barry A. Warsaw" wrote: > > > It's fairly old but it's complaining that there is no way to > > tell the difference between a list posting and an administrative > > message via the List-* headers. I think it's actually recommending to > > add another header(!) only to list postings. > > I've felt that including list-id on administrative messages is a bug. BTW, that works for me too. Either removing List-Id or adding another header, I don't really care which one. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Sat Apr 6 04:48:55 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 5 Apr 2002 20:48:55 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> References: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> Message-ID: <20020406044853.GN21237@merlins.org> On Fri, Apr 05, 2002 at 11:41:35PM -0500, Ron Jarrell wrote: > At 12:13 AM 4/5/02 -0500, Barry A. Warsaw wrote: > >E.g. we could shut off email confirms altogether and force only web > >confirmations. Or we could be more Majordomo-ish as JC describes. > > I think all potential subscribers to *any* mailman list should be required > to trek in person to a lonely abandoned silo in Montana where they will > descend, following the directions in the confirm note, knock three times on > the control room door, and be greeted by a grumpy gnome of a man named > Melvin, who'll shriek "What! What! Why do you all keep bothering me? Don't > you have enough to do without being on *another* mailinglist??" > > At which point he'll refuse to confirm your subscription unless you can > bring him a shrubbery. I like that, maybe it also means that I won't have to deal with this anymore ---------------------------------------------------------------------------- > You guys are pain. > > Pl unsubscribe my email address from your list with imm effect > failingwhich I will be contrained to initiate appropriate legal action as > may be advised. Right... You got instructions on how to unsubscribe when you subscribed (you should have read and saved the Email) and you get a reminder every month, with again, instructions on how to unsubscribe. If you cannot get this to work _after_ reading the instructions and trying them out, open a support request on the sf.net web site explaining what you did and what the error was. (we cannot offer support by mail, so you need to get a support request for further help should you need any) ---------------------------------------------------------------------------- > Mr. Marc, > I say that your team is taking undue advantages. You subscribed to the list yourself, so you know who to blame. > You are aware that no one save unimportant emails for a long time. Actually 1) they are important 2) other people save them 3) this is irrelevant, you replied to a monthly Email that had all the instructions and that you still ignored and didn't read. > I request you to unsubscribe me from the mailing list with immediate > effect and further request you to do the needful procedure. and I'll repeat: > If you cannot get this to work _after_ reading the instructions and trying > them out, open a support request on the sf.net web site explaining what > you did and what the error was. > (we cannot offer support by mail, so you need to get a support request for > further help should you need any) More Emails on this subject will be ignored as a result. ---------------------------------------------------------------------------- I can't wait for the mailman 2.1 upgrade and have all this people talk to a script instead of me. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From chuqui@plaidworks.com Sat Apr 6 04:48:53 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 05 Apr 2002 20:48:53 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> Message-ID: On 4/5/02 8:41 PM, "Ron Jarrell" wrote: > At which point he'll refuse to confirm your subscription unless you can > bring him a shrubbery. Almost makes me sorry I brought this up. Was just trying to help. I sure didn't expect the bloody spanish inquisition... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From chuqui@plaidworks.com Sat Apr 6 05:12:56 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 05 Apr 2002 21:12:56 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <20020406044853.GN21237@merlins.org> Message-ID: On 4/5/02 8:48 PM, "Marc MERLIN" wrote: >> Pl unsubscribe my email address from your list with imm effect >> failingwhich I will be contrained to initiate appropriate legal action as >> may be advised. > > Right... Heh. I finally changed the standard footer on all of my list messages. It now says: Do not post administrative requests to the list. They will be ignored. This goes on every message. It's dropped the number of these damn things to about two a month. Even better, I've only had one guy repeat the request (IMHO, the other subscribers of the list are more than happy to point this out to the people. I, as list mom, overtly ignore them. Except for the occasional grimace or grin) And believe it or nor, I agonized over the wording for days. Was I getting in the face of the "good" users to try to reach the others? Should it be stern and firm? Or more friendly? Should we use the word "please"? One of the things I've gotten real sensitive to the last couple of years is the issue of how things are seen by the "regular" users. You sometimes get so focussed on "solving a problem" that you can piss off the people who aren't causing the problem in the first place; sort of like spam blocking. Some folks get so gung ho about blocking spam they forget that they need to let the REAL stuff through, and don't think about the obverse problem of false positives (the ultimate spam blocker: turn off your mail system. But even the most rabid whitelister won't go that far...) I finally decided that saying "please do not..." made it sound too much like an optional request. I decided to risk irritating a few users by being brusque in return for removing the ambiguity. It turns out my users have accepted it with effectively no complaints (and a few accolades, since they're tired of it, too). I just decided that we'd hit a point where you couldn't assume users knew better (actually, we hit that point long ago, I finally hit a point where I was tired of explaining it). And it's clearly helped. There's always going to be a small percentage of people who can't/won't follow instructions. I always boggle at how ahrd people will work to avoid doing the easy thing (like follow the instructions). With legal threats, I like to respond with "I'd rather solve the problem, but since you've made a legal threat, I must request all further correspondence be done by your lawyer to our lawyer. This will make removing you from the list very slow, since our lawyers don't have access to the subscriber lists, but if that's what you want, that's how we'll do it". The responses are usually amusing. I've yet to have one get to a lawyer, either. Although someday, I'ms ure I'll find one. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From gorg@sun31.imbi.uni-freiburg.de Fri Apr 5 08:12:53 2002 From: gorg@sun31.imbi.uni-freiburg.de (Georg Koch) Date: Fri, 05 Apr 2002 10:12:53 +0200 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 In-Reply-To: Your message of "Thu, 04 Apr 2002 16:09:50 CDT." <15532.49438.250712.852479@anthem.wooz.org> Message-ID: <200204050812.g358Cr015296@sun31.imbi.uni-freiburg.de> > GK> OSError: [Errno 2] No such file or directory: > GK> '/h/mailman/lists/test/config.pck' > > GK> because the configuration is stored as config.db. > > GK> How do I convert the config.db to config.pck ? > > You don't. While the error message is misleading, your config.db file > will be automatically updated to config.pck the first time you load > your list (via web, qrunner, or command line script). > Hi Barry, but I cannot, because MailList.py stops with an uncatched exception first. __load is called from load like this: for file in (pfile, plast, dfile, dlast): dict, e = self.__load(file) so in __load the mtime of non-existing config.pck is asked and yields the exception which is not handled. I am in no way a python developer, so I moved some lines in the definition of __load in MailList.py (see below) and could see the web page http://ourhost/mailman/listinfo without an error - but it was empty! (The right thing would probably be to catch the exception). Georg if dbfile.endswith('.db') or dbfile.endswith('.db.last'): loadfunc = marshal.load elif dbfile.endswith('.pck') or dbfile.endswith('.pck.last'): loadfunc = cPickle.load else: assert 0, 'Bad database file name' # moved lines # mtime = os.path.getmtime(dbfile) # if mtime <= self.__timestamp: # # File is not newer # return None, None try: fp = open(dbfile) except IOError, e: if e.errno <> errno.ENOENT: raise return None, e # moved to here mtime = os.path.getmtime(dbfile) if mtime <= self.__timestamp: # File is not newer return None, None -- -- Georg Koch (koch@cochrane.de) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany "All you need in this life is ignorance and confidence, and then success is sure." (Mark Twain) -- -- Georg Koch (koch@cochrane.de) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany "All you need in this life is ignorance and confidence, and then success is sure." (Mark Twain) From ota-7@andrew.pimlott.net Sat Apr 6 03:35:44 2002 From: ota-7@andrew.pimlott.net (Andrew Pimlott) Date: Fri, 5 Apr 2002 22:35:44 -0500 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15534.23246.975895.526224@anthem.wooz.org> References: <15534.23246.975895.526224@anthem.wooz.org> Message-ID: <20020406033544.GA5979@pimlott.net> On Fri, Apr 05, 2002 at 09:17:50PM -0500, Barry A. Warsaw wrote: > I'm in a mad quest to reduce the number of open Mailman bugs to under > 50 so it fits on one page. (If someone's smart, he'll ask sourceforge to shorten the page length every time Barry closes a bug.) > It's fairly old but it's complaining that there is no way to > tell the difference between a list posting and an administrative > message via the List-* headers. I think it's actually recommending to > add another header(!) only to list postings. > I think > we're being standards compliant here and I'm inclined to close this > bug report as Won't Fix. I think you're focusing too much on the standards issue. This bug is not really about standards. This bug is about a clear failing in Mailman, that causes users much annoyance. I would be disappointed if it were not addressed. Mailman already adds around ten headers to each list message, so I wouldn't think that one more, to fulfill a clear need, would be a problem. But if an additional header on list messages is really not acceptible, perhaps as a compromise you could add a header to the admin messages? This would be a little confusing, but at least users would only have to learn the trick once. It should be clearly documented, to minimize bewilderment. Another possibility would be to propose a revision to the RFC's that adds a header just for list messages. Then, at least you would have the force of an RFC behind you if people complain about another header. As a bonus, you would save other list software from making this mistake. Just a poor subscriber, Andrew From jarrell@vt.edu Sat Apr 6 05:40:39 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sat, 06 Apr 2002 00:40:39 -0500 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <20020406044853.GN21237@merlins.org> References: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020406003939.00a29010@lennier.cc.vt.edu> At 08:48 PM 4/5/02 -0800, Marc MERLIN wrote: >Right... > >You got instructions on how to unsubscribe when you subscribed (you should >have read and saved the Email) and you get a reminder every month, with >again, instructions on how to unsubscribe. I like the ones who reply to a message posted to the list with an unsubscribe request, *quoting* all the "list-" headers, including the one that basically says "click here to unsubscribe." From barry@zope.com Sat Apr 6 05:45:49 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 6 Apr 2002 00:45:49 -0500 Subject: [Mailman-Developers] SF bug report #223533 References: <15534.23246.975895.526224@anthem.wooz.org> <20020406031456.GJ21237@merlins.org> Message-ID: <15534.35725.77176.905911@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I'll get someone to increase the page length to 100 bugs. MM> No, don't thank me, I'm just glad I could help :-))) Beauty. Okay, I'm done! :) MM> Actually I've found this annoying too, to be honest. MM> I guess one way to remain really compliant would be to add, MM> yes, yet another header to admin messages, something like MM> X-Mailman-Administrativa: Yes MM> PS: Should I continue to bug you about my two patches, one MM> being the bugfix for SMTP_MAX_SESSIONS_PER_CONNECTION ? Yes. The sick irony is that it's all a zero sum game. The more I catch up on bugs the farther behind I fall on email. The more email I answer, the farther behind I fall on coding. I can't wait for cloning to become legal. I'd have my eat/shit clones take care of body maintenance, while my sleep clones would take care of the hallucinations, and my exercise clones would drop those last ugly 20 lbs. Then I could let my hack/rant clones take care of the email and the coding while my army-of-burger-flipping-monkey-clones bring in fistfuls of $$$s. I'd be free to relieve any of my other clones when, for kicks, I want to do their job, like my rockstar/naked/hi-meg-ryan-i-hear-your-single clone or my yum-ribs! clone. Gawd, I need some sleep. Shut up, Nancy. -Barry From barry@zope.com Sat Apr 6 05:56:00 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 6 Apr 2002 00:56:00 -0500 Subject: [Mailman-Developers] SF bug report #223533 References: <15534.23246.975895.526224@anthem.wooz.org> Message-ID: <15534.36336.896267.651169@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> I feel that flagging them with a list-id of foobar.domain.org CVR> is incorrect, because the source is the server, not the CVR> list. It's about the list, but not from the list. I think CVR> that's an important distinction. I agree that it's an important distinction to make, and further I'll agree that the RFC clause /could/ be interpreted that way. The problem I have is that what seems more intuitive to me, is that List-Id: would be included in admin messages, /and/ they would have the listname in them, but admin messages wouldn't have the the other List-* headers. I don't see where the other List-* headers make much sense for an admin message, but the List-ID header /does/ make sense for such a posting. IOW, List-ID: identifies the list, and admin messages are definitely tied to a particularly list, not (currently) the list server. Would you agree that we wouldn't be breaking the RFCs if we implemented that policy? Do you agree that this is a useful interpretation? It makes sense to me. If I were writing some filter on messages, I'd look for the List-ID to figure out which list this message pertains to, then I'd look for List-Post to see if this were a list posting or an admin message (it's absence would mean "admin message"). Could you live with that? -Barry From barry@zope.com Sat Apr 6 05:58:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 6 Apr 2002 00:58:50 -0500 Subject: [Mailman-Developers] SF bug report #223533 References: <15534.23246.975895.526224@anthem.wooz.org> <20020406033544.GA5979@pimlott.net> Message-ID: <15534.36506.138986.835619@anthem.wooz.org> >>>>> "AP" == Andrew Pimlott writes: AP> Another possibility would be to propose a revision to the AP> RFC's that adds a header just for list messages. Then, at AP> least you would have the force of an RFC behind you if people AP> complain about another header. As a bonus, you would save AP> other list software from making this mistake. Perhaps, but I see getting an RFC revised or written as a long-term project. What are we going to do for MM2.1? And by thinking it through and er, creatively interpreting the existing RFCs, I believe we can establish some useful standard practice, that may eventually end up in a revised RFC. So, to summarize, my proposal is: - List-Id: is included in all messages pertaining to a list, including both postings and admin messages. - List-Help:, List-Subscribe:, List-Unsubscribe:, and List-Post: are added only to postings. (Oh, and optionally List-Archive:). -Barry From chuqui@plaidworks.com Sat Apr 6 06:08:04 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 05 Apr 2002 22:08:04 -0800 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15534.36336.896267.651169@anthem.wooz.org> Message-ID: On 4/5/02 9:56 PM, "Barry A. Warsaw" wrote: > List-* headers. I don't see where the other List-* headers make much > sense for an admin message, but the List-ID header /does/ make sense > for such a posting. I agree the other headers shouldn't be there -- but most mail clients can't filter on the LACK of a mail header. So if the purpose is to differentiate admin messages at the client level, this might be RFC compliant but doesn't solve the problem. > It makes sense to me. If I were writing some filter on messages, I'd > look for the List-ID to figure out which list this message pertains > to, then I'd look for List-Post to see if this were a list posting or > an admin message (it's absence would mean "admin message"). That's easy in procmail. In most gui clients, it's impossible. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From barry@zope.com Sat Apr 6 06:12:29 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 6 Apr 2002 01:12:29 -0500 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 References: <200204040835.g348Z9010575@sun31.imbi.uni-freiburg.de> <5.1.0.14.2.20020405232737.00a3ac50@lennier.cc.vt.edu> Message-ID: <15534.37325.741848.477955@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: >> You don't. While the error message is misleading, your >> config.db file will be automatically updated to config.pck the >> first time you load your list (via web, qrunner, or command >> line script). RJ> Ah hah. And you didn't believe me when I posted the comment a RJ> while back that it really shouldn't do that... I apologize, because I don't remember that conversation. But I don't see it as being much different than writing the config.db file when we (used to) save. We're just doing it in a more robust data file format (marshal == bad, pickle == good). -Barry From barry@zope.com Sat Apr 6 06:18:28 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 6 Apr 2002 01:18:28 -0500 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... References: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> Message-ID: <15534.37684.931801.129392@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> and be greeted by a grumpy gnome of a man named Melvin, who'll RJ> shriek "What! What! Why do you all keep bothering me? Don't RJ> you have enough to do without being on *another* RJ> mailinglist??" Check out Melvin! http://www.cravindogs.com/cool/lyrics/lyrics2.html#0001 -B From claw@kanga.nu Sat Apr 6 07:57:28 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 05 Apr 2002 23:57:28 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: Message from Chuq Von Rospach of "Thu, 04 Apr 2002 23:09:32 PST." References: Message-ID: <17021.1018079848@kanga.nu> On Thu, 04 Apr 2002 23:09:32 -0800 Chuq Von Rospach wrote: > On 4/4/02 10:49 PM, "J C Lawrence" wrote: >> Keep the just-hit-reply model, > How about keeping the reply model, but requiring the reply come from > the address being subscribed? Problem: That breaks across forwarders. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Sat Apr 6 08:00:56 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 06 Apr 2002 00:00:56 -0800 Subject: [Mailman-Developers] templating, search, and stuff... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 05 Apr 2002 10:19:09 EST." <15533.49261.981759.102450@anthem.wooz.org> References: <20020405011258.A9109@mozart.chat.net> <15533.49261.981759.102450@anthem.wooz.org> Message-ID: <17094.1018080056@kanga.nu> On Fri, 5 Apr 2002 10:19:09 -0500 Barry A Warsaw wrote: >>>>>> "DJ" == David Jeske writes: DJ> Also, in fishing through the TODO list, I notice that adding some DJ> kind of templating system is still on there. > Improving the templating system (for MM3) is more than just picking > one and going with it. The real issue is that folks want to put all > kinds of web skins on Mailman, to integrate them into their own way of > managing their sites. More simply: Many of us want to integrate Mailman as a dynamic component into other dynamically generated web pages. just adding template support is good, but doesn't solve the base problem of enabling mailman to be a well behaved component in a web page that's otherwise assembled. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Sat Apr 6 08:02:57 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 06 Apr 2002 00:02:57 -0800 Subject: [Mailman-Developers] templating, search, and stuff... In-Reply-To: Message from Norbert Bollow of "Fri, 05 Apr 2002 17:25:48 +0200." <200204051525.g35FPmT01666@quill.local> References: <20020405011258.A9109@mozart.chat.net> <15533.49261.981759.102450@anthem.wooz.org> <200204051525.g35FPmT01666@quill.local> Message-ID: <17137.1018080177@kanga.nu> On Fri, 5 Apr 2002 17:25:48 +0200 Norbert Bollow wrote: >> Improving the templating system (for MM3) is more than just picking >> one and going with it. The real issue is that folks want to put all >> kinds of web skins on Mailman, to integrate them into their own way >> of managing their sites. Some people don't care about the >> integration, and for them we can pick a Good One and use that as the >> default. But they've got to be able to chuck it, design their own >> web interface, and integrate it easily into Mailman. For that we >> need APIs, a clean architecture, and component-like system. > I'd suggest to look at what phpGroupWare is doing and be as compatible > with that as possible. phpGroupWare, Zope/ZPT, PhpLib -- there are literally dozens of commonly used templating systems. Choice of templating system is not the question or the problem. Much like making Mailman specific to one specific MTA would be silly, making it specific to one particular templating system would equally be stupid. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Sat Apr 6 08:04:01 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 06 Apr 2002 00:04:01 -0800 Subject: [Mailman-Developers] Silly mailman question In-Reply-To: Message from "Jay R. Ashworth" of "Fri, 05 Apr 2002 12:11:25 EST." <20020405121125.08339@scfn.thpl.lib.fl.us> References: <3C9F324F.5070906@daa.com.au> <20020405121125.08339@scfn.thpl.lib.fl.us> Message-ID: <17164.1018080241@kanga.nu> On Fri, 5 Apr 2002 12:11:25 -0500 Jay R Ashworth wrote: > The problem is that they're already in a database (filePro for Unix on > SCO 5, on a machine behind a Linux 7.1 firewall), and they want to be > able to selectwhom to mail on an adhoc basis. Sounds like a job for 2.1 and the new membership roster abstraction model. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Sat Apr 6 08:14:15 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 06 Apr 2002 00:14:15 -0800 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 05 Apr 2002 21:17:50 EST." <15534.23246.975895.526224@anthem.wooz.org> References: <15534.23246.975895.526224@anthem.wooz.org> Message-ID: <17277.1018080855@kanga.nu> On Fri, 5 Apr 2002 21:17:50 -0500 Barry A Warsaw wrote: > I'd like to get some feedback on bug #223533: > http://sourceforge.net/tracker/index.php?func=detail&aid=223533&group_id=103&atid=100103 > It's fairly old but it's complaining that there is no way to > tell the difference between a list posting and an administrative > message via the List-* headers. I think it's actually recommending to > add another header(!) only to list postings. I'd rather do something to the command/ack messages instead to make them easier to filter. Ease of filtering is a definite value. > My interpretation of this paragraph says that Mailman is doing the > right thing by adding all those headers to all outgoing messages. Agreed. > The complaint is that you can't reliably set up something like a > procmail filter to distinguish between admin messages and postings ... Currently list messages have a Sender: header of listname-admin and command messages have a Sender: header of mud-dev-owner. This is good and useful except for the fact that some MTAs (eg exim), will rewrite the Sender header to match who they actually received the message from (if not using SMTP delivery). > ... but I think we're being standards compliant here and I'm inclined > to close this bug report as Won't Fix. I'd be more tempted to vary the value of the X-Been-There: header between list and admin messages. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Sat Apr 6 08:16:26 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 06 Apr 2002 00:16:26 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: Message from Chuq Von Rospach of "Fri, 05 Apr 2002 20:48:53 PST." References: Message-ID: <17295.1018080986@kanga.nu> On Fri, 05 Apr 2002 20:48:53 -0800 Chuq Von Rospach wrote: > On 4/5/02 8:41 PM, "Ron Jarrell" wrote: >> At which point he'll refuse to confirm your subscription unless you >> can bring him a shrubbery. > Almost makes me sorry I brought this up. Was just trying to help. I > sure didn't expect the bloody spanish inquisition... Ni! -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From nb@thinkcoach.com Sat Apr 6 09:02:20 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Sat, 6 Apr 2002 11:02:20 +0200 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15534.36506.138986.835619@anthem.wooz.org> (barry@zope.com) References: <15534.23246.975895.526224@anthem.wooz.org> <20020406033544.GA5979@pimlott.net> <15534.36506.138986.835619@anthem.wooz.org> Message-ID: <200204060902.g3692Kf02340@quill.local> Barry A. Warsaw wrote: > So, to summarize, my proposal is: > > - List-Id: is included in all messages pertaining to a list, including > both postings and admin messages. > > - List-Help:, List-Subscribe:, List-Unsubscribe:, and List-Post: are > added only to postings. (Oh, and optionally List-Archive:). Yup. Makes sense. Chuq Von Rospach wrote: > > It makes sense to me. If I were writing some filter on messages, I'd > > look for the List-ID to figure out which list this message pertains > > to, then I'd look for List-Post to see if this were a list posting or > > an admin message (it's absence would mean "admin message"). > > That's easy in procmail. In most gui clients, it's impossible. This can be addressed by filtering on the Sender: header. My reading of the RFC is that we should add a well-defined Sender: header to admin messages that we create, e.g. Sender: mailman-owner@example.com while we shouldn't add such a header for outgoing list mail. Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From nb@thinkcoach.com Sat Apr 6 09:15:10 2002 From: nb@thinkcoach.com (Norbert Bollow) Date: Sat, 6 Apr 2002 11:15:10 +0200 Subject: [Mailman-Developers] templating, search, and stuff... In-Reply-To: <17137.1018080177@kanga.nu> (message from J C Lawrence on Sat, 06 Apr 2002 00:02:57 -0800) References: <20020405011258.A9109@mozart.chat.net> <15533.49261.981759.102450@anthem.wooz.org> <200204051525.g35FPmT01666@quill.local> <17137.1018080177@kanga.nu> Message-ID: <200204060915.g369FAZ02615@quill.local> > >> Improving the templating system (for MM3) is more than just picking > >> one and going with it. The real issue is that folks want to put all > >> kinds of web skins on Mailman, to integrate them into their own way > >> of managing their sites. Some people don't care about the > >> integration, and for them we can pick a Good One and use that as the > >> default. But they've got to be able to chuck it, design their own > >> web interface, and integrate it easily into Mailman. For that we > >> need APIs, a clean architecture, and component-like system. > > > I'd suggest to look at what phpGroupWare is doing and be as compatible > > with that as possible. J C Lawrence replied: > phpGroupWare, Zope/ZPT, PhpLib -- there are literally dozens of commonly > used templating systems. Choice of templating system is not the > question or the problem. Much like making Mailman specific to one > specific MTA would be silly, making it specific to one particular > templating system would equally be stupid. Agreed, but since both Mailman and phpGroupWare are GNU projects, their templating systems should be made as similar and as compatible as reasonably possible. Greetings, Norbert. -- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com From david@midrange.com Sat Apr 6 13:01:15 2002 From: david@midrange.com (David Gibbs) Date: Sat, 06 Apr 2002 07:01:15 -0600 Subject: [Mailman-Developers] Upgrade to beta 1? In-Reply-To: References: <20020406044853.GN21237@merlins.org> Message-ID: <5.1.0.14.2.20020406064934.01f95618@linux.midrange.com> Ok, sorry if this question falls in the 'well duh' category, but I couldn't find anything obvious in the docs. Since this relates to the beta, I figured this would be the right place to post it. I was planning on experimenting with MM 2.1b1, including converting one of my lists over to for experimentation (it's an internal list, so the subscribers can deal with some instability). I copied the files from the <2.0.9_install>/lists/ directory into the <2.1.b1_install>/lists/ directory and ran update. The update program said there was nothing to do. I then tried to access the admin page for the list in the MM2.1b1 web I setup, and got the following ... Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 82, in run_main main() File "/usr/local/mailman/Mailman/Cgi/admin.py", line 170, in main change_options(mlist, category, subcat, cgidata, doc) File "/usr/local/mailman/Mailman/Cgi/admin.py", line 1211, in change_options gui.handleForm(mlist, category, subcat, cgidata, doc) File "/usr/local/mailman/Mailman/Gui/GUIBase.py", line 114, in handleForm for item in self.GetConfigInfo(mlist, category, subcat): File "/usr/local/mailman/Mailman/Gui/General.py", line 58, in GetConfigInfo optvals = [mlist.new_member_options & bitfields[o] for o in OPTIONS] File "/usr/local/mailman/Mailman/MailList.py", line 129, in __getattr__ raise AttributeError, name AttributeError: new_member_options Any ideas? Thanks! david -- | Internet: david@midrange.com | WWW: http://david.fallingrock.net | AIM: MidrangeMan | | If you can't fly, run; if you can't run, walk; | if you can't walk, crawl. | -mlk From chuqui@plaidworks.com Sat Apr 6 15:30:16 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sat, 06 Apr 2002 07:30:16 -0800 Subject: [Mailman-Developers] Yet another weird-a$$ potential attack problem... In-Reply-To: <17021.1018079848@kanga.nu> Message-ID: On 4/5/02 11:57 PM, "J C Lawrence" wrote: >>> Keep the just-hit-reply model, > >> How about keeping the reply model, but requiring the reply come from >> the address being subscribed? > > Problem: That breaks across forwarders. And in all honesty, I consider that a feature. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From barry@zope.com Sat Apr 6 15:52:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 6 Apr 2002 10:52:55 -0500 Subject: [Mailman-Developers] templating, search, and stuff... References: <20020405011258.A9109@mozart.chat.net> <15533.49261.981759.102450@anthem.wooz.org> <17094.1018080056@kanga.nu> Message-ID: <15535.6615.911785.527134@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> More simply: Many of us want to integrate Mailman as a JCL> dynamic component into other dynamically generated web pages. JCL> just adding template support is good, but doesn't solve the JCL> base problem of enabling mailman to be a well behaved JCL> component in a web page that's otherwise assembled. Nicely said. -Barry From chuqui@plaidworks.com Sat Apr 6 17:21:40 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sat, 06 Apr 2002 09:21:40 -0800 Subject: [Mailman-Developers] templating, search, and stuff... In-Reply-To: <15535.6615.911785.527134@anthem.wooz.org> Message-ID: On 4/6/02 7:52 AM, "Barry A. Warsaw" wrote: > JCL> just adding template support is good, but doesn't solve the > JCL> base problem of enabling mailman to be a well behaved > JCL> component in a web page that's otherwise assembled. >=20 > Nicely said. Thinking about it, here's how I'd do this (at first glance) Define two new variables: MAILMAN_HEADER MAILMAN_FOOTER You can point these two one of two things: a file, or a function. If defined, the header replaces what Mailman normally spits out from to . The footer replaces through inclusive. This allows you to "box" the mailman content inside your site's interface (and FWIW, if you look at what I've done on www.lists.apple.com, that's exactly what I have done, only using mod_layout to do the boxing. It's also the way pages like applenews.lists.apple.com/unsubscribe work, since marketing controls the content and I control the cgi aspects, we built the pages to allow each side to manage their part independently. As long as we both behave, of course...) If you have a simple interface, that's all you need. But if you have a more complex one, that=B9s' where the function comes in. If you define these as functions, then those functions need to be in the python include path, but once you do that, you can do literally anything (suck the html out of a database, write it on the fly, whatever). The function is called with a single parameter that is one of a pre-defined set of constants that define which page is being rendered, so those functions have the ability to adapt the output to each page. The functions return a glop of text that is the HTML to be output. This would allow mailman to adapt easily to ANY templating system, while being tied to none. Even the most complex interface system comes down to writing two python functions to interface to mailman. In most cases, the template files will be enough, but for big, complex sites the functionality is there as well. And even better -- it's quite easy to implement inside mailman. It's a pretty trivial setup. And if you don't define those variables, mailman continues to work as it does now, so there are no upgrade/compatibility issues, either.=20 I'd guess this is 100 lines of python code, maybe less. Thoughts?=20 --=20 Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From Dale@Newfield.org Sat Apr 6 17:36:03 2002 From: Dale@Newfield.org (Dale Newfield) Date: Sat, 6 Apr 2002 12:36:03 -0500 (EST) Subject: [Mailman-Developers] Small annoyance with easy solution In-Reply-To: Message-ID: I've done enough custom hacking in my most important live 2.0.X install that I always wind up having to install patches by hand to ensure that nothing bad happens. This is fine, and I've no complaints (hey--what other software this great lets you modify it so thoroughly and easily?). My complaint is that as often as not, during this manual patch process I wind up screwing up the indentation levels (which we all know in python effects the block structure) strictly because tabs are invisible. (Then cron barfs on me once a minute until I get it fixed--I realize there's no cron in 2.1, but that's not the issue--the fact that I broke it at all is the issue.) I think the reason I had so many such troubles this past update was due to vim for some reason deciding to use tab=4 instead of tab=8 when displaying stuff to me. I was hoping it would be a reasonable request to replace all tabs in the 2.1 code base with spaces to avoid this problem in the future? What do y'all think? (I hope I didn't just start a religious war...) -Dale From jarrell@vt.edu Sat Apr 6 21:53:37 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sat, 06 Apr 2002 16:53:37 -0500 Subject: [Mailman-Developers] no such file config.pck updating to 2.1b1 In-Reply-To: <15534.37325.741848.477955@anthem.wooz.org> References: <200204040835.g348Z9010575@sun31.imbi.uni-freiburg.de> <5.1.0.14.2.20020405232737.00a3ac50@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020406165202.00a5b780@lennier.cc.vt.edu> At 01:12 AM 4/6/02 -0500, Barry A. Warsaw wrote: > >>>>> "RJ" == Ron Jarrell writes: > > >> You don't. While the error message is misleading, your > >> config.db file will be automatically updated to config.pck the > >> first time you load your list (via web, qrunner, or command > >> line script). > > RJ> Ah hah. And you didn't believe me when I posted the comment a > RJ> while back that it really shouldn't do that... > >I apologize, because I don't remember that conversation. > >But I don't see it as being much different than writing the config.db >file when we (used to) save. We're just doing it in a more robust >data file format (marshal == bad, pickle == good). Not that using the pickle file was bad, the fact that during the upgrade your error log fills with dire warnings about your db files being bad. The other thing I mentioned, which I'll mention again, since you haven't been in email mode is that dropping the placeholder page into the archives for lists that already *had* working archives was a really bad move... From fil@rezo.net Sun Apr 7 16:44:25 2002 From: fil@rezo.net (Fil) Date: Sun, 7 Apr 2002 17:44:25 +0200 Subject: [Mailman-Developers] iso_xxx subjects not processed? Message-ID: <20020407154425.GC7808@rezo.net> Hello, we had discussed a while ago of mailman decoding the iso_xxx subject lines in order not to add x times the subject_prefix ; I don't remember if there was a patch and if it was to be included in the official Mailman. Anyone knows? (In any case, it's not working on my installation, done from cvs one or twoo weeks ago). -- Fil From che@debian.org Sun Apr 7 16:53:59 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 8 Apr 2002 00:53:59 +0900 Subject: [Mailman-Developers] iso_xxx subjects not processed? In-Reply-To: <20020407154425.GC7808@rezo.net> Message-ID: On Monday, April 8, 2002, at 12:44 , Fil wrote: > we had discussed a while ago of mailman decoding the iso_xxx subject > lines > in order not to add x times the subject_prefix ; I don't remember if > there > was a patch and if it was to be included in the official Mailman. Anyone > knows? (In any case, it's not working on my installation, done from cvs > one > or twoo weeks ago). Mailman does now decode the subject lines from Base 64 or Q-P before searching for the prefix, when deciding to add it or not. I have tested this with several encoded messages, and it works; I'm not sure what problem you're running into. Can you show me an example message that exhibits the problem? Ben From fil@rezo.net Sun Apr 7 17:05:27 2002 From: fil@rezo.net (Fil) Date: Sun, 7 Apr 2002 18:05:27 +0200 Subject: [Mailman-Developers] iso_xxx subjects not processed? In-Reply-To: References: <20020407154425.GC7808@rezo.net> Message-ID: <20020407160527.GA9440@rezo.net> @ Ben Gertzfield : > On Monday, April 8, 2002, at 12:44 , Fil wrote: > > >we had discussed a while ago of mailman decoding the iso_xxx subject > >lines in order not to add x times the subject_prefix ; I don't remember > >if there was a patch and if it was to be included in the official > >Mailman. Anyone knows? (In any case, it's not working on my installation, > >done from cvs one or twoo weeks ago). > > Mailman does now decode the subject lines from Base 64 or Q-P before > searching for the prefix, when deciding to add it or not. I have tested > this with several encoded messages, and it works; I'm not sure what > problem you're running into. > > Can you show me an example message that exhibits the problem? This is a two-prefix subject line (taken from the mailman .mbox file, in order to be sure) Subject: [Spip] =?iso-8859-1?Q?Re:_=5BSpip=5D_exclusion_mot_cl=E9s?= Preceding messages had these lines : first message in thread Subject: [Spip] =?iso-8859-1?Q?exclusion_mot_cl=E9s?= X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 my answer (I use 'mutt', if it has any importance) Subject: Re: [Spip] exclusion mot =?iso-8859-1?Q?cl?= =?iso-8859-1?Q?=E9s?= answer to my answer, by the thread originator, yielded the two-prefix line above. the subject line decoded is: exclusion mot clés the subject_prefix is "[Spip] " -- Fil From che@debian.org Sun Apr 7 17:51:00 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 8 Apr 2002 01:51:00 +0900 Subject: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: <20020407160527.GA9440@rezo.net> Message-ID: --Apple-Mail-1--911129101 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Monday, April 8, 2002, at 01:05 , Fil wrote: > This is a two-prefix subject line (taken from the mailman .mbox file, in > order to be sure) > > Subject: [Spip] =?iso-8859-1?Q?Re:_=5BSpip=5D_exclusion_mot_cl=E9s?= > Fil, I just checked CVS and you are indeed right. I thought I had sent this patch in ages ago, but I can't find it in the archives. Barry, this patch to CookHeaders.py fixes this issue of endless prefix string adding if the Subject line gets encoded, by decoding the Subject line before searching for the prefix. It encodes the new prefix if needed as a separate chunk in the new Subject header. This will allow for Japanese, French, whatever prefix strings. I really apologize, I thought it was sent in and applied many moons ago. I need a better brain. :) I'm attaching the patch, but this is the crazy Mac OS X Mail.app, so who knows if it will be readable or not. In case it's not, here is a URL for the patch: http://people.debian.org/~che/mailman/patches/cook-headers.patch Ben --Apple-Mail-1--911129101 Content-Disposition: attachment; filename=cook-headers.patch Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0644; name="cook-headers.patch" Index:=20CookHeaders.py=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0ARCS=20file:=20= /cvsroot/mailman/mailman/Mailman/Handlers/CookHeaders.py,v=0Aretrieving=20= revision=202.9=0Adiff=20-u=20-r2.9=20CookHeaders.py=0A---=20= CookHeaders.py=092001/12/19=2007:01:49=092.9=0A+++=20CookHeaders.py=09= 2002/02/04=2007:07:38=0A@@=20-19,6=20+19,8=20@@=0A=20=0A=20import=20re=0A= =20=0A+from=20email.Charset=20import=20Charset=0A+from=20email.Header=20= import=20Header,=20decode_header=0A=20import=20email.Utils=0A=20=0A=20= from=20Mailman=20import=20mm_cfg=0A@@=20-28,8=20+30,8=20@@=0A=20=0A=20= CONTINUATION=20=3D=20',\n\t'=0A=20COMMASPACE=20=3D=20',=20'=0A= +MAXLINELEN=20=3D=2078=0A=20=0A-=0A=20=0C=0A=20def=20process(mlist,=20= msg,=20msgdata):=0A=20=20=20=20=20#=20Set=20the=20"X-Ack:=20no"=20header=20= if=20noack=20flag=20is=20set.=0A@@=20-51,13=20+53,37=20@@=0A=20=20=20=20=20= =20=20=20=20#=20such=20as=20the=20list=20admin).=20=20We=20assume=20all=20= digests=20have=20an=20appropriate=0A=20=20=20=20=20=20=20=20=20#=20= subject=20header=20added=20by=20the=20ToDigest=20module.=0A=20=20=20=20=20= =20=20=20=20prefix=20=3D=20mlist.subject_prefix=0A+=20=20=20=20=20=20=20=20= #=20The=20header=20may=20be=20multilingual;=20decode=20it=20from=20= base64/quopri=20and=0A+=20=20=20=20=20=20=20=20#=20search=20each=20chunk=20= for=20the=20prefix.=0A+=20=20=20=20=20=20=20=20has_prefix=20=3D=200=0A+=20= =20=20=20=20=20=20=20if=20prefix=20and=20subject:=0A+=20=20=20=20=20=20=20= =20=20=20=20=20for=20s,=20e=20in=20decode_header(msg['subject']):=0A+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20if=20= re.search(re.escape(prefix.strip()),=20s,=20re.I):=0A+=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20has_prefix=20=3D=201=0A+=20=20=20=20= =20=20=20=20cset=20=3D=20= Charset(Utils.GetCharSet(mlist.preferred_language))=0A=20=20=20=20=20=20=20= =20=20#=20We=20purposefully=20leave=20no=20space=20b/w=20prefix=20and=20= subject!=0A=20=20=20=20=20=20=20=20=20if=20not=20subject:=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20del=20msg['subject']=0A-=20=20=20=20=20=20=20=20=20= =20=20=20msg['Subject']=20=3D=20prefix=20+=20_('(no=20subject)')=0A-=20=20= =20=20=20=20=20=20elif=20prefix=20and=20not=20= re.search(re.escape(prefix),=20subject,=20re.I):=0A+=20=20=20=20=20=20=20= =20=20=20=20=20new_subject=20=3D=20Header(prefix=20+=20_('(no=20= subject)'),=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20cset,=20header_name=3D"Subject")=0A= +=20=20=20=20=20=20=20=20=20=20=20=20msg['Subject']=20=3D=20= new_subject.encode()=0A+=20=20=20=20=20=20=20=20elif=20prefix=20and=20= not=20has_prefix:=0A=20=20=20=20=20=20=20=20=20=20=20=20=20del=20= msg['subject']=0A-=20=20=20=20=20=20=20=20=20=20=20=20msg['Subject']=20=3D= =20prefix=20+=20subject=0A+=20=20=20=20=20=20=20=20=20=20=20=20#=20We'll=20= encode=20the=20new=20prefix=20(just=20in=20case)=20but=20leave=20the=20= old=0A+=20=20=20=20=20=20=20=20=20=20=20=20#=20subject=20alone,=20in=20= case=20it=20was=20already=20encoded.=0A+=20=20=20=20=20=20=20=20=20=20=20= =20new_subject=20=3D=20Header(prefix,=20cset,=20= header_name=3D"Subject").encode()=0A+=20=20=20=20=20=20=20=20=20=20=20=20= #=20If=20we=20go=20over=2076=20characters=20with=20the=20prefix,=20just=20= put=20the=0A+=20=20=20=20=20=20=20=20=20=20=20=20#=20old=20subject=20on=20= its=20own=20line.=0A+=20=20=20=20=20=20=20=20=20=20=20=20first=20=3D=20= subject.split("\n")[0]=0A+=20=20=20=20=20=20=20=20=20=20=20=20if=20= len(new_subject=20+=20first)=20+=201=20>=3D=20MAXLINELEN=20-=20= len("Subject:=20"):=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= new_subject=20+=3D=20'\n=20'=0A+=20=20=20=20=20=20=20=20=20=20=20=20#=20= We=20might=20have=20to=20add=20a=20space=20because=20the=20prefix=20and=20= old=0A+=20=20=20=20=20=20=20=20=20=20=20=20#=20subject=20may=20both=20be=20= MIME-encoded,=20losing=20the=20space=20at=0A+=20=20=20=20=20=20=20=20=20=20= =20=20#=20the=20end=20of=20the=20prefix.=0A+=20=20=20=20=20=20=20=20=20=20= =20=20elif=20new_subject[-1]=20<>=20'=20':=0A+=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20new_subject=20+=3D=20'=20'=0A+=20=20=20=20=20=20=20=20= =20=20=20=20new_subject=20+=3D=20subject=0A+=20=20=20=20=20=20=20=20=20=20= =20=20msg['Subject']=20=3D=20new_subject=0A=20=20=20=20=20#=20get=20rid=20= of=20duplicate=20headers=0A=20=20=20=20=20del=20msg['sender']=0A=20=20=20= =20=20del=20msg['errors-to']=0A= --Apple-Mail-1--911129101-- From jon@csh.rit.edu Sun Apr 7 21:53:09 2002 From: jon@csh.rit.edu (Jon Parise) Date: Sun, 7 Apr 2002 16:53:09 -0400 Subject: [Mailman-Developers] Another typo Message-ID: <20020407205309.GA22160@csh.rit.edu> --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached patch fixes another small typo. -- Jon Parise (jon@csh.rit.edu) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Defaults.py.in.patch" Index: Defaults.py.in =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Defaults.py.in,v retrieving revision 2.79 diff -u -r2.79 Defaults.py.in --- Defaults.py.in 29 Mar 2002 19:23:04 -0000 2.79 +++ Defaults.py.in 7 Apr 2002 20:50:00 -0000 @@ -561,7 +561,7 @@ # VERP_CONFIRM_FORMAT. VERP_CONFIRM_REGEXP = r'^(?P[^+]+?)\+(?P[^@]+)@.*$' -# Set this to true to enable VERP-like (more use friendly) confirmations +# Set this to true to enable VERP-like (more user friendly) confirmations VERP_CONFIRMATIONS = 0 --BXVAT5kNtrzKuDFl-- From mrbill@mrbill.net Sun Apr 7 22:03:34 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Sun, 7 Apr 2002 16:03:34 -0500 Subject: [Mailman-Developers] Error after moving list? Message-ID: <20020407210334.GU10038@mrbill.net> I'm attempting to move a mailing list from one machine to the other. I've installed Mailman on the second machine, created the list, mirrored the contents of ~mailman/list/, mirror the archived files, fixed the aliases, etc, but when I try to post to the new list: Apr 07 17:01:08 2002 qrunner(18476): Traceback (most recent call last): Apr 07 17:01:08 2002 qrunner(18476): File "/usr/local/mailman/cron/qrunner", l ine 282, in ? Apr 07 17:01:08 2002 qrunner(18476): kids = main(lock) Apr 07 17:01:08 2002 qrunner(18476): File "/usr/local/mailman/cron/qrunner", l ine 247, in main Apr 07 17:01:08 2002 qrunner(18476): mlist.Lock(timeout=mm_cfg.LIST_LOCK_TI MEOUT) Apr 07 17:01:08 2002 qrunner(18476): File "/usr/local/mailman/Mailman/MailList .py", line 1339, in Lock Apr 07 17:01:08 2002 qrunner(18476): self.__lock.lock(timeout) Apr 07 17:01:08 2002 qrunner(18476): File "/usr/local/mailman/Mailman/LockFile .py", line 272, in lock Apr 07 17:01:08 2002 qrunner(18476): os.unlink(self.__tmpfname) Apr 07 17:01:08 2002 qrunner(18476): OSError : [Errno 2] No such file or direct ory: '/usr/local/mailman/locks/sunmanagers.lock.sunmgrs.cs.toronto.edu.18476' This is 2.0.9 on Solaris 8/Postfix. Suggestions? Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From jon@csh.rit.edu Sun Apr 7 22:05:02 2002 From: jon@csh.rit.edu (Jon Parise) Date: Sun, 7 Apr 2002 17:05:02 -0400 Subject: [Mailman-Developers] One more typo Message-ID: <20020407210502.GB22160@csh.rit.edu> --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Any hopefully the last typo fix for a while. =) -- Jon Parise (jon@csh.rit.edu) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="README.POSTFIX.patch" Index: README.POSTFIX =================================================================== RCS file: /cvsroot/mailman/mailman/README.POSTFIX,v retrieving revision 2.9 diff -u -r2.9 README.POSTFIX --- README.POSTFIX 5 Apr 2002 18:42:39 -0000 2.9 +++ README.POSTFIX 7 Apr 2002 21:03:34 -0000 @@ -70,7 +70,7 @@ % chown mailman.mailman data/aliases* - Hack your Postfix's main.cf file to include the following path - in your alias_map variable: + in your alias_maps variable: /usr/local/mailman/data/aliases --WYTEVAkct0FjGQmd-- From brett@twobikes.ottawa.on.ca Sun Apr 7 23:05:55 2002 From: brett@twobikes.ottawa.on.ca (Brett Delmage) Date: Sun, 7 Apr 2002 18:05:55 -0400 (EDT) Subject: [Mailman-Developers] qrunner still broken In-Reply-To: Message-ID: I'm still getting the same errors as below, with the latest CVS (as of today) and a clean build/compile/install. I would sure appreciate any hints -- even the right questions to get me checking the right things. On Mon, 18 Mar 2002, Brett Delmage wrote: > I updated from 2.1a4 to 2.1b1 this weekend. SuSE 7.3, python 2.1.1 > > A problem showed up during make install, where paths.py was not copied > into the bin, scripts, cron directories. I copied it in manually and that > cleared the initial problems: the Cgi parts seemed to work (without > exhaustive testing). > > Now I'm running into the followuing problems with qrunner but I am not > sure where to look. Suggestions? It looks like it might still be related > to paths.py? > > Brett > > > > # bin/mailmanctl start > Starting Mailman's master qrunner. > Cannot import runner module Mailman.Queue.VirginRunner > Cannot import runner module Mailman.Queue.CommandRunner > Cannot import runner module Mailman.Queue.IncomingRunner > Cannot import runner module Mailman.Queue.ArchRunner > Cannot import runner module Mailman.Queue.BounceRunner > Cannot import runner module Mailman.Queue.NewsRunner > Cannot import runner module Mailman.Queue.OutgoingRunner > > > in logs/error: > > Mar 18 00:41:58 2002 mailmanctl(4463): > Mar 18 00:42:06 2002 qrunner(4472): Cannot import runner module Mailman.Queue.VirginRunner > Mar 18 00:42:06 2002 qrunner(4468): Cannot import runner module Mailman.Queue.CommandRunner > Mar 18 00:42:06 2002 qrunner(4469): Cannot import runner module Mailman.Queue.IncomingRunner > Mar 18 00:42:07 2002 qrunner(4466): Cannot import runner module Mailman.Queue.ArchRunner > Mar 18 00:42:08 2002 qrunner(4467): Cannot import runner module Mailman.Queue.BounceRunner > Mar 18 00:42:08 2002 qrunner(4470): Cannot import runner module Mailman.Queue.NewsRunner > Mar 18 00:42:08 2002 qrunner(4471): Cannot import runner module Mailman.Queue.OutgoingRunner > > in logs/qrunner: > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > (pid: 4472, sig: 0, sts: 15, class: VirginRunner, slice: 1/1) > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > (pid: 4468, sig: 0, sts: 15, class: CommandRunner, slice: 1/1) > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > (pid: 4469, sig: 0, sts: 15, class: IncomingRunner, slice: 1/1) > Mar 18 00:42:07 2002 (4465) Master qrunner detected subprocess exit > (pid: 4466, sig: 0, sts: 15, class: ArchRunner, slice: 1/1) > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > (pid: 4467, sig: 0, sts: 15, class: BounceRunner, slice: 1/1) > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > (pid: 4470, sig: 0, sts: 15, class: NewsRunner, slice: 1/1) > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > (pid: 4471, sig: 0, sts: 15, class: OutgoingRunner, slice: 1/1) > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From marc_news@vasoftware.com Mon Apr 8 04:10:38 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 7 Apr 2002 20:10:38 -0700 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15534.36506.138986.835619@anthem.wooz.org> References: <15534.23246.975895.526224@anthem.wooz.org> <20020406033544.GA5979@pimlott.net> <15534.36506.138986.835619@anthem.wooz.org> Message-ID: <20020408031038.GU29934@merlins.org> On Sat, Apr 06, 2002 at 12:58:50AM -0500, Barry A. Warsaw wrote: > - List-Id: is included in all messages pertaining to a list, including > both postings and admin messages. > > - List-Help:, List-Subscribe:, List-Unsubscribe:, and List-Post: are > added only to postings. (Oh, and optionally List-Archive:). Actually this is probably the best solution that I've read so far (including the one I wrote) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From eric@aquameta.com Mon Apr 8 04:33:53 2002 From: eric@aquameta.com (Eric Hanson) Date: Mon, 8 Apr 2002 03:33:53 +0000 Subject: [Mailman-Developers] pipermail replacement Message-ID: <20020408033353.A30300@aquameta.com> First post. Hello all. There have been several mentions of the need for a mailing list with a web interface, something that allows mailing list functionality and a web interface that allows posting, user accounts, threading etc. I've been thinking about such a thing using the XML server 4suite server (4suite.org) and mailman, essentially replacing pipermail. Here's my question. What about abandoning mbox format and storing emails in the XML repository? Are there a lot of mbox specific things in Mailman? Is this a sane thing to do? Regards, Eric From che@debian.org Mon Apr 8 04:44:08 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 8 Apr 2002 12:44:08 +0900 Subject: [Mailman-Developers] pipermail replacement In-Reply-To: <20020408033353.A30300@aquameta.com> Message-ID: On Monday, April 8, 2002, at 12:33 , Eric Hanson wrote: > What about abandoning mbox format and storing emails in the XML > repository? Are there a lot of mbox specific things in Mailman? Is > this a sane thing to do? It's only for Pipermail that Mailman stores mails in mbox format. Since Pipermail is completely optional, you can use whatever backend you want for mail archiving, and Mailman can be configured to send each mail as it arrives to whatever program you want. You could, for example, configure Mailman to pass incoming mails to the program "my-xml-repository.py" or whatever. The rest of the things you mentioned (posting, threading, etc) can all be handled by your program as an external archiver -- it would just send posts via email to the real mailman address. Ben From barry@zope.com Mon Apr 8 05:22:38 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Apr 2002 00:22:38 -0400 Subject: [Mailman-Developers] SF bug report #223533 References: <15534.23246.975895.526224@anthem.wooz.org> <20020406033544.GA5979@pimlott.net> <15534.36506.138986.835619@anthem.wooz.org> <20020408031038.GU29934@merlins.org> Message-ID: <15537.6926.884565.125954@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: >> - List-Id: is included in all messages pertaining to a list, >> including both postings and admin messages. >> - List-Help:, >> List-Subscribe:, List-Unsubscribe:, and List-Post: are added >> only to postings. (Oh, and optionally List-Archive:). MM> Actually this is probably the best solution that I've read so MM> far (including the one I wrote) Cool. I'll do one other thing. For administrivia messages, I'll add an "X-List-Administrivia: yes" header. -Barry From barry@zope.com Mon Apr 8 05:58:22 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Apr 2002 00:58:22 -0400 Subject: [Mailman-Developers] Re: [PATCH] Fix endless prefix adding with q-p/base64 Subject lines References: <20020407160527.GA9440@rezo.net> Message-ID: <15537.9070.19429.891204@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Barry, this patch to CookHeaders.py fixes this issue of BG> endless prefix string adding if the Subject line gets encoded, BG> by decoding the Subject line before searching for the prefix. BG> It encodes the new prefix if needed as a separate chunk in the BG> new Subject header. This will allow for Japanese, French, BG> whatever prefix strings. Ok, but there's a bug in email.Header.decode_header when the here string has no encoded parts. It returns the original header (str-ified), but it should still return a list of tuples. I'll fix that. -Barry From barry@zope.com Mon Apr 8 06:12:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Apr 2002 01:12:32 -0400 Subject: [Mailman-Developers] Re: [PATCH] Fix endless prefix adding with q-p/base64 Subject lines References: <20020407160527.GA9440@rezo.net> Message-ID: <15537.9920.383330.382271@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> I'm attaching the patch, but this is the crazy Mac OS X BG> Mail.app, so who knows if it will be readable or not. In case BG> it's not, here is a URL for the patch: They'll be some refactoring, so please check out cvs in a few minutes. -Barry From che@debian.org Mon Apr 8 06:20:33 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 8 Apr 2002 14:20:33 +0900 Subject: [Mailman-Developers] Re: [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: <15537.9070.19429.891204@anthem.wooz.org> Message-ID: <59AB4AC6-4AB0-11D6-A918-0003931E4DBC@debian.org> On Monday, April 8, 2002, at 01:58 , Barry A. Warsaw wrote: > Ok, but there's a bug in email.Header.decode_header when the here > string has no encoded parts. It returns the original header > (str-ified), but it should still return a list of tuples. Oops! I should have caught that one a long time ago. Thanks, Barry. Ben From barry@zope.com Mon Apr 8 06:21:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Apr 2002 01:21:50 -0400 Subject: [Mailman-Developers] Re: [PATCH] Fix endless prefix adding with q-p/base64 Subject lines References: <15537.9070.19429.891204@anthem.wooz.org> <59AB4AC6-4AB0-11D6-A918-0003931E4DBC@debian.org> Message-ID: <15537.10478.753364.299015@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Oops! I should have caught that one a long time ago. Thanks, BG> Barry. Now there's a unittest. :) -Barry From brett@twobikes.ottawa.on.ca Mon Apr 8 06:28:21 2002 From: brett@twobikes.ottawa.on.ca (Brett Delmage) Date: Mon, 8 Apr 2002 01:28:21 -0400 (EDT) Subject: [Mailman-Developers] qrunner still broken In-Reply-To: Message-ID: In case anyone is interested, my problem was that /usr/lib/python2.1/lib-dynload/_weakref.so was missing. weakref.py[c] was present in the parent lib drectory. This was a problem on SusE 7.3 with Python 2.1.1 (#1, Sep 24 2001, 05:28:47). Does anyone know if this file is not part of python 2.1.1 or did SusE miss something? I verified the python rpm and nothing was missing off the disk. Should the minimum, as opposed to recommended, requirements for mailman be changed to 2.1.2+ ? cheers, Brett On Sun, 7 Apr 2002, Brett Delmage wrote: > I'm still getting the same errors as below, with the latest CVS (as of > today) and a clean build/compile/install. > > I would sure appreciate any hints -- even the right questions to get me > checking the right things. > > > On Mon, 18 Mar 2002, Brett Delmage wrote: > > > I updated from 2.1a4 to 2.1b1 this weekend. SuSE 7.3, python 2.1.1 > > > > A problem showed up during make install, where paths.py was not copied > > into the bin, scripts, cron directories. I copied it in manually and that > > cleared the initial problems: the Cgi parts seemed to work (without > > exhaustive testing). > > > > Now I'm running into the followuing problems with qrunner but I am not > > sure where to look. Suggestions? It looks like it might still be related > > to paths.py? > > > > Brett > > > > > > > > # bin/mailmanctl start > > Starting Mailman's master qrunner. > > Cannot import runner module Mailman.Queue.VirginRunner > > Cannot import runner module Mailman.Queue.CommandRunner > > Cannot import runner module Mailman.Queue.IncomingRunner > > Cannot import runner module Mailman.Queue.ArchRunner > > Cannot import runner module Mailman.Queue.BounceRunner > > Cannot import runner module Mailman.Queue.NewsRunner > > Cannot import runner module Mailman.Queue.OutgoingRunner > > > > > > in logs/error: > > > > Mar 18 00:41:58 2002 mailmanctl(4463): > > Mar 18 00:42:06 2002 qrunner(4472): Cannot import runner module Mailman.Queue.VirginRunner > > Mar 18 00:42:06 2002 qrunner(4468): Cannot import runner module Mailman.Queue.CommandRunner > > Mar 18 00:42:06 2002 qrunner(4469): Cannot import runner module Mailman.Queue.IncomingRunner > > Mar 18 00:42:07 2002 qrunner(4466): Cannot import runner module Mailman.Queue.ArchRunner > > Mar 18 00:42:08 2002 qrunner(4467): Cannot import runner module Mailman.Queue.BounceRunner > > Mar 18 00:42:08 2002 qrunner(4470): Cannot import runner module Mailman.Queue.NewsRunner > > Mar 18 00:42:08 2002 qrunner(4471): Cannot import runner module Mailman.Queue.OutgoingRunner > > > > in logs/qrunner: > > > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4472, sig: 0, sts: 15, class: VirginRunner, slice: 1/1) > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4468, sig: 0, sts: 15, class: CommandRunner, slice: 1/1) > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4469, sig: 0, sts: 15, class: IncomingRunner, slice: 1/1) > > Mar 18 00:42:07 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4466, sig: 0, sts: 15, class: ArchRunner, slice: 1/1) > > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4467, sig: 0, sts: 15, class: BounceRunner, slice: 1/1) > > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4470, sig: 0, sts: 15, class: NewsRunner, slice: 1/1) > > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4471, sig: 0, sts: 15, class: OutgoingRunner, slice: 1/1) > > > > > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers@python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From barry@zope.com Mon Apr 8 07:23:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Apr 2002 02:23:55 -0400 Subject: [Mailman-Developers] qrunner still broken References: Message-ID: <15537.14203.272830.266429@anthem.wooz.org> >>>>> "BD" == Brett Delmage writes: BD> In case anyone is interested, my problem was that BD> /usr/lib/python2.1/lib-dynload/_weakref.so BD> was missing. weakref.py[c] was present in the parent lib BD> drectory. Nasty. | This was a problem on SusE 7.3 with Python 2.1.1 | (#1, Sep 24 2001, 05:28:47). BD> Does anyone know if this file is not part of python 2.1.1 or BD> did SusE miss something? I verified the python rpm and nothing BD> was missing off the disk. BD> Should the minimum, as opposed to recommended, requirements BD> for mailman be changed to 2.1.2+ ? That file definitely gets build and installed when you use the Python source distro. Maybe the SuSE distribution is broken? Try building Python from source (it's easy!) and see if that fixes your problem. You're experience wasn't for naught though. I think the log message should have included the exception that occurred, and I've fixed qrunner to do that. -Barry From mjaw@ipartners.pl Mon Apr 8 08:44:41 2002 From: mjaw@ipartners.pl (Miroslaw Jaworski) Date: Mon, 8 Apr 2002 09:44:41 +0200 Subject: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: ; from che@debian.org on Mon, Apr 08, 2002 at 01:51:00AM +0900 References: <20020407160527.GA9440@rezo.net> Message-ID: <20020408094441.C59749@quad.ikp.pl> * Ben Gertzfield (che@debian.org) [020408 08:59] wrote: > On Monday, April 8, 2002, at 01:05 , Fil wrote: > > > This is a two-prefix subject line (taken from the mailman .mbox file, in > > order to be sure) > > > > Subject: [Spip] =?iso-8859-1?Q?Re:_=5BSpip=5D_exclusion_mot_cl=E9s?= > > > > Fil, > > I just checked CVS and you are indeed right. I thought I had sent this > patch in ages ago, but I can't find it in the archives. > > Barry, this patch to CookHeaders.py fixes this issue of endless prefix > string adding if the Subject line gets encoded, by decoding the Subject > line before searching for the prefix. It encodes the new prefix if > needed as a separate chunk in the new Subject header. This will allow > for Japanese, French, whatever prefix strings. > > I really apologize, I thought it was sent in and applied many moons > ago. I need a better brain. :) > > I'm attaching the patch, but this is the crazy Mac OS X Mail.app, so who > knows if it will be readable or not. In case it's not, here is a URL > for the patch: > > http://people.debian.org/~che/mailman/patches/cook-headers.patch The same problem appeared when whole body was encoded - textual Mailman signature was appended to the post; MUA recognizes and decodes the message - textual Mailman signature becomes a visible trash. Problem was already addressed, and is solved in MM2.1 MJ. -- Miroslaw.Jaworski@ipartners.pl ( Psyborg ) MJ102-RIPE Internet Partners Server Administration Department Manager From mhz@alt-linux.org Mon Apr 8 09:42:41 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Mon, 8 Apr 2002 12:42:41 +0400 Subject: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: References: <20020407160527.GA9440@rezo.net> Message-ID: <20020408084241.GA6416@mhz.mikhail.zabaluev.name> Hello Ben, On Mon, Apr 08, 2002 at 01:51:00AM +0900, Ben Gertzfield wrote: > > On Monday, April 8, 2002, at 01:05 , Fil wrote: > > >This is a two-prefix subject line (taken from the mailman .mbox file, in > >order to be sure) > > > > Subject: [Spip] =?iso-8859-1?Q?Re:_=5BSpip=5D_exclusion_mot_cl=E9s?= > > > > Fil, > > I just checked CVS and you are indeed right. I thought I had sent this > patch in ages ago, but I can't find it in the archives. > > Barry, this patch to CookHeaders.py fixes this issue of endless prefix > string adding if the Subject line gets encoded, by decoding the Subject > line before searching for the prefix. It encodes the new prefix if > needed as a separate chunk in the new Subject header. This will allow > for Japanese, French, whatever prefix strings. > > I really apologize, I thought it was sent in and applied many moons > ago. I need a better brain. :) > > I'm attaching the patch, but this is the crazy Mac OS X Mail.app, so who > knows if it will be readable or not. In case it's not, here is a URL > for the patch: > > http://people.debian.org/~che/mailman/patches/cook-headers.patch Finally it's getting fixed. Still though, there is a possibility of the prefix being scattered between encoded/ASCII chunks; this code will not find it then. I haven't seen yet if this case is realistic or not. You can take a look at two more patches that address this problem, at SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=498766&group_id=103&atid=300103 http://sourceforge.net/tracker/index.php?func=detail&aid=528031&group_id=103&atid=300103 -- Stay tuned, MhZ JID: mookid@jabber.org ___________ Five is a sufficiently close approximation to infinity. -- Robert Firth "One, two, five." -- Monty Python and the Holy Grail From mhz@alt-linux.org Mon Apr 8 10:41:48 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Mon, 8 Apr 2002 13:41:48 +0400 Subject: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: <73C2F2C0-4AD0-11D6-A918-0003931E4DBC@debian.org> References: <20020408084241.GA6416@mhz.mikhail.zabaluev.name> <73C2F2C0-4AD0-11D6-A918-0003931E4DBC@debian.org> Message-ID: <20020408094148.GA8993@mhz.mikhail.zabaluev.name> Hello Ben, On Mon, Apr 08, 2002 at 06:10:20PM +0900, Ben Gertzfield wrote: > > On Monday, April 8, 2002, at 05:42 , Mikhail Zabaluev wrote: > > >Finally it's getting fixed. Still though, there is a possibility of > >the prefix being scattered between encoded/ASCII chunks; this code > >will not find it then. I haven't seen yet if this case is realistic or > >not. > > We might be able to fix this by making email.Header.decode_header() take > an optional flag to merge un-encoded (us-ascii) header chunks with the > next adjacent chunk, since we assume that all charsets have us-ascii as > a strict subset. Broad assumptions stink :) Why not Unicode, however? It would be nice if email.Header.Header objects would dump themselves into Unicode strings, so that we can match regex there without hassle. See my feature request at SF for mimelib. > I do not think this case is particularly realistic, though. I've > certainly never seen any mailer that would split in the middle of the > prefix and encode half of it, but who knows. Indeed. And anyone can set prefixes with spaces, mixed languages and so on. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ Fun Facts, #14: In table tennis, whoever gets 21 points first wins. That's how it once was in baseball -- whoever got 21 runs first won. From che@debian.org Mon Apr 8 10:44:40 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 8 Apr 2002 18:44:40 +0900 Subject: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: <20020408094148.GA8993@mhz.mikhail.zabaluev.name> Message-ID: <3FA00A2C-4AD5-11D6-A918-0003931E4DBC@debian.org> On Monday, April 8, 2002, at 06:41 , Mikhail Zabaluev wrote: > Broad assumptions stink :) > Why not Unicode, however? It would be nice if email.Header.Header > objects would dump themselves into Unicode strings, so that we > can match regex there without hassle. See my feature request > at SF for mimelib. That will work for encodings that Python happens to have a Unicode codec installed for, but certainly not for all encodings. Also, we will lose information if we try to take the Unicode header and make a non-Unicode header out of it again (if that's even possible!).. not all mail clients support UTF-8 headers yet, especially Unix ones. I think I need to do a thorough revamping of the email.Charset and email.Header modules to be a bit more Unicode-friendly (they are Unicode-friendly now, but don't really spit out Unicode too easily). Ben From mhz@alt-linux.org Mon Apr 8 11:22:12 2002 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Mon, 8 Apr 2002 14:22:12 +0400 Subject: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines In-Reply-To: <3FA00A2C-4AD5-11D6-A918-0003931E4DBC@debian.org> References: <20020408094148.GA8993@mhz.mikhail.zabaluev.name> <3FA00A2C-4AD5-11D6-A918-0003931E4DBC@debian.org> Message-ID: <20020408102212.GA10085@mhz.mikhail.zabaluev.name> Hello Ben, On Mon, Apr 08, 2002 at 06:44:40PM +0900, Ben Gertzfield wrote: > > On Monday, April 8, 2002, at 06:41 , Mikhail Zabaluev wrote: > > >Broad assumptions stink :) > >Why not Unicode, however? It would be nice if email.Header.Header > >objects would dump themselves into Unicode strings, so that we > >can match regex there without hassle. See my feature request > >at SF for mimelib. > > That will work for encodings that Python happens to have a Unicode codec > installed for, but certainly not for all encodings. Also, we will lose > information if we try to take the Unicode header and make a non-Unicode > header out of it again (if that's even possible!).. not all mail clients > support UTF-8 headers yet, especially Unix ones. In our case, there is no need to re-encode text back from Unicode. We: 1) get the Subject: value in Unicode; 2) search for the prefix; 3) append the prefix (probably as an encoded word) to the _original_ encoded value, in case the prefix is not found. > I think I need to do a thorough revamping of the email.Charset and > email.Header modules to be a bit more Unicode-friendly (they are > Unicode-friendly now, but don't really spit out Unicode too easily). I noticed that the last two optional parameters to the email.Header.Header constructor are in fact mutually exclusive. Wouldn't it be better to have them as named parameters? Another named parameter, 'encoded', would hint that the string parameter needs to be parsed as a MIME-encoded header (no charset can be specified in this case). -- Stay tuned, MhZ JID: mookid@jabber.org ___________ There is no royal road to geometry. -- Euclid From lrosa@mail.hypertrek.info Mon Apr 8 16:46:59 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Mon, 08 Apr 2002 17:46:59 +0200 Subject: [Mailman-Developers] Apache 2.0.x Message-ID: <5.1.0.14.2.20020408174606.0239b6a8@mail.venus.it> Are there any problems or caveat relating to Mailman about upgrading Apache to V2.0? Thanks. Ciao, luigi From claw@kanga.nu Mon Apr 8 18:42:24 2002 From: claw@kanga.nu (J C Lawrence) Date: Mon, 08 Apr 2002 10:42:24 -0700 Subject: [Mailman-Developers] pipermail replacement In-Reply-To: Message from Eric Hanson of "Mon, 08 Apr 2002 03:33:53 -0000." <20020408033353.A30300@aquameta.com> References: <20020408033353.A30300@aquameta.com> Message-ID: <19353.1018287744@kanga.nu> On Mon, 8 Apr 2002 03:33:53 +0000 Eric Hanson wrote: > There have been several mentions of the need for a mailing list with a > web interface, something that allows mailing list functionality and a > web interface that allows posting, user accounts, threading etc. I've > been thinking about such a thing using the XML server 4suite server > (4suite.org) and mailman, essentially replacing pipermail. You might like to look at what I've done under MHonArc and PHP here at Kanga.Nu. I specifically don't handle accounts, but I do handle posting, MIME, and the rest. http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.004.htp -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From terri@zone12.com Mon Apr 8 20:21:20 2002 From: terri@zone12.com (Terri Oda) Date: Mon, 08 Apr 2002 15:21:20 -0400 Subject: [Mailman-Developers] Unsubscribing and legal action. :) In-Reply-To: <20020406044853.GN21237@merlins.org> References: <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> <5.1.0.14.2.20020405233927.00a29250@lennier.cc.vt.edu> Message-ID: <5.1.0.14.0.20020408150208.0329e8a0@pop.ncf.carleton.ca> At 08:48 PM 05/04/02 -0800, you wrote: >I like that, maybe it also means that I won't have to deal with this anymore >---------------------------------------------------------------------------- > > You guys are pain. > > > > Pl unsubscribe my email address from your list with imm effect > > failingwhich I will be contrained to initiate appropriate legal action as > > may be advised. I know, it's horrible, but I had to laugh at the messages you get, Marc. :) I haven't had any legal threats, but I do notice that even when people go to the listinfo page, they read the headers for each section and miss that "unsubscribe" is under ".* Subscribers". I don't get the impression that people are really thinking of themselves as subscribers when they want "off-this-list-NOW!!!", so it's a bit non-intuitive for an apparently common mindset. I'm glad to see the "Unsubscribe or edit options" button in 2.1, but I think maybe putting "Unsubscribe" in the title-thing might be a good idea (eg: .* Subscribers [Unsubscribe, Edit Options]) or making a separate "Unsubscribing from *" section with just a simple address/pw pair of boxes and a "send me my password" button. (hm, I should patch this myself. It would save me some grief, I think.) Actually, the latter is probably a *lot* better usability-wise, if I recall the last lecture on usability I attended. As programmers, we tend to want to avoid repetition, but as a user, you generally want to find something in the first place you look. It's not like it really makes a huge difference to have such a commonly required form duplicated, will it? Apologies if this has already been debated to death! Terri From jarrell@vt.edu Mon Apr 8 21:45:08 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 8 Apr 2002 16:45:08 -0400 (EDT) Subject: [Mailman-Developers] 2.1b1 new bug Message-ID: <200204082045.g38Kj8229884@babylon5.cc.vt.edu> I'm starting to get these periodically: Apr 08 06:33:16 2002 (527) Uncaught runner exception: local variable 'addr' refe renced before assignment Apr 08 06:33:16 2002 (527) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/BounceRunner.py", line 95, in _dispose if xlist.isMember(addr): UnboundLocalError: local variable 'addr' referenced before assignment I'm not quite current on cvs (haven't updated in a week) but none of the recent checkins looked like they'd cover this. From barry@zope.com Mon Apr 8 21:52:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Apr 2002 16:52:50 -0400 Subject: [Mailman-Developers] 2.1b1 new bug References: <200204082045.g38Kj8229884@babylon5.cc.vt.edu> Message-ID: <15538.802.340788.727480@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> I'm not quite current on cvs (haven't updated in a week) but RJ> none of the recent checkins looked like they'd cover this. BounceRunner.py 2.14 has the fix. From jarrell@vt.edu Mon Apr 8 21:54:39 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 08 Apr 2002 16:54:39 -0400 Subject: [Mailman-Developers] 2.1b1 new bug In-Reply-To: <15538.802.340788.727480@anthem.wooz.org> References: <200204082045.g38Kj8229884@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020408165406.03582930@lennier.cc.vt.edu> At 04:52 PM 4/8/02 -0400, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell writes: > > RJ> I'm not quite current on cvs (haven't updated in a week) but > RJ> none of the recent checkins looked like they'd cover this. > >BounceRunner.py 2.14 has the fix. Ok, must have missed a message or two during my trip, I didn't even see the checkin message *for* bouncerunner! From jarrell@vt.edu Mon Apr 8 23:09:34 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 8 Apr 2002 18:09:34 -0400 (EDT) Subject: [Mailman-Developers] year out of range in arch runner? Message-ID: <200204082209.g38M9YO07697@babylon5.cc.vt.edu> Well, this was fascinating... I unshunted a couple of hundred messages that were there because of the bounce runner problem. Didn't get the previous error, but got *1* of these: Apr 08 17:59:32 2002 (17641) Uncaught runner exception: year out of range Apr 08 17:59:32 2002 (17641) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/ArchRunner.py", line 54, in _dispose elif abs(now - mktime_tz(tup)) > \ File "/usr/local/lib/python2.2/rfc822.py", line 955, in mktime_tz t = time.mktime(data[:8] + (0,)) ValueError: year out of range Turns out it's one of my users who's using an old unix mail client that's not Y2K compatible... So his mail is arriving in the year 102. Date: Thu, 4 Apr 102 19:36:28 -0500 (EST) From jarrell@vt.edu Tue Apr 9 15:19:05 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 9 Apr 2002 10:19:05 -0400 (EDT) Subject: [Mailman-Developers] todigest.py Message-ID: <200204091419.g39EJ5i28730@babylon5.cc.vt.edu> Interesting... Started up the latest cvs before going home last night (yes, I let it run for a while before abandoning it :-)) When I came home my terminal window had a stream of these on it.. Looks like python was dropping the errors to stdout. /home/mailman/Mailman/Handlers/ToDigest.py:172: DeprecationWarning: add_payload() is deprecated, use attach() instead. mimemsg.add_payload(masthead) /home/mailman/Mailman/Handlers/ToDigest.py:262: DeprecationWarning: add_payload() is deprecated, use attach() instead. mimemsg.add_payload(tocpart) /home/mailman/Mailman/Handlers/ToDigest.py:272: DeprecationWarning: add_payload() is deprecated, use attach() instead. mimemsg.add_payload(mimedigest) /home/mailman/Mailman/Handlers/ToDigest.py:276: DeprecationWarning: add_payload() is deprecated, use attach() instead. mimedigest.add_payload(msg) /home/mailman/Mailman/Handlers/ToDigest.py:291: DeprecationWarning: add_payload() is deprecated, use attach() instead. mimemsg.add_payload(footer) /home/mailman/Mailman/Handlers/ToDigest.py:339: DeprecationWarning: add_payload() is deprecated, use attach() instead. rfc1153msg.add_payload(plainmsg.getvalue()) From jarrell@vt.edu Tue Apr 9 15:48:31 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 9 Apr 2002 10:48:31 -0400 (EDT) Subject: [Mailman-Developers] 2.1b1 bug still in topic processor... Message-ID: <200204091448.g39EmVv01339@babylon5.cc.vt.edu> Barry, the topic processor bug is still there... I did some more testing with the latest (ok, last nights) cvs. Turned topics back on one the list they were on before (the one I sent you the shunt pickles from) and let it run all night. Sure enough, caught a message that was otherwise fine, but died. Turned topics back off and deleted the topics I had, and unshunted it, and it went back in fine. return self.parse(StringIO(text)) File "/home/mailman/pythonlib/email/Parser.py", line 40, in parse self._parseheaders(root, fp) File "/home/mailman/pythonlib/email/Parser.py", line 69, in _parseheaders raise Errors.HeaderParseError( HeaderParseError: Continuation line seen before first header From marc_news@vasoftware.com Tue Apr 9 18:08:16 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 9 Apr 2002 10:08:16 -0700 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 Message-ID: <20020409170815.GB9327@merlins.org> This happened twice on sf.net about 12H after the upgrade to 2.0.9 Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): Traceback (most recent call las t): Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): File "/var/local/mailman/cron /qrunner", line 282, in ? Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): kids = main(lock) Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): File "/var/local/mailman/cron /qrunner", line 204, in main Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): os.unlink(root+'.msg') Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): OSError : [Errno 2] No such fi le or directory: '/var/local/mailman/qfiles/c0cd07c04a0599fb40d2251f364aa2d187fc af43.msg.msg' Note the ".msg.msg" (I am not claiming it's new to 2.0.9, I have to admit that my old error log file was getting too big for me to read it) There are also fun ones like: Apr 09 08:48:47 2002 usw-sf-list1 (517) Exception while calculating message head er: unsupported format character '^M' (0xd) at index 87 or Apr 09 06:35:04 2002 usw-sf-list1 (17060) NNTP gateway improperly configured: no newsgroup, no NNTP host (there aren't new mind you, and I think Barry said that mm2.1 was better about telling you which list these errors happened in) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Tue Apr 9 21:44:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 9 Apr 2002 16:44:48 -0400 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 References: <20020409170815.GB9327@merlins.org> Message-ID: <15539.21184.900827.591435@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> This happened twice on sf.net about 12H after the upgrade to MM> 2.0.9 MM> Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): Traceback MM> (most recent call las t): Apr 09 02:28:06 2002 usw-sf-list1 MM> qrunner(9416): File "/var/local/mailman/cron /qrunner", line MM> 282, in ? Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): MM> kids = main(lock) Apr 09 02:28:06 2002 usw-sf-list1 MM> qrunner(9416): File "/var/local/mailman/cron /qrunner", line MM> 204, in main Apr 09 02:28:06 2002 usw-sf-list1 qrunner(9416): MM> os.unlink(root+'.msg') Apr 09 02:28:06 2002 usw-sf-list1 MM> qrunner(9416): OSError : [Errno 2] No such fi le or directory: MM> '/var/local/mailman/qfiles/c0cd07c04a0599fb40d2251f364aa2d187fc MM> af43.msg.msg' MM> Note the ".msg.msg" (I am not claiming it's new to 2.0.9, I MM> have to admit that my old error log file was getting too big MM> for me to read it) Arrgghh! Can you say MM2.0.10? :( Message.Enqueue() writes a .msg.tmp file and there's a small window of opportunity for qrunner to see that file before it's flipped over to just .msg. qrunner's main needs to be taught to ignore .tmp files. See attached patch. MM> There are also fun ones like: Apr 09 08:48:47 2002 MM> usw-sf-list1 (517) Exception while calculating message head MM> er: unsupported format character '^M' (0xd) at index 87 MM> or Apr 09 06:35:04 2002 usw-sf-list1 (17060) NNTP gateway MM> improperly configured: no newsgroup, no NNTP host MM> (there aren't new mind you, and I think Barry said that mm2.1 MM> was better about telling you which list these errors happened MM> in) It should be. The first one is because somebody's got something bogus in their message header, the second because they've enabled gatewaying but the never set up an NNTP host. -Barry Index: qrunner =================================================================== RCS file: /cvsroot/mailman/mailman/cron/Attic/qrunner,v retrieving revision 1.18.2.4 diff -u -r1.18.2.4 qrunner --- qrunner 2 Apr 2002 22:38:50 -0000 1.18.2.4 +++ qrunner 9 Apr 2002 20:44:27 -0000 @@ -194,10 +194,11 @@ # Keep the qrunner lock alive for a while longer lock.refresh() root, ext = os.path.splitext(os.path.join(mm_cfg.QUEUE_DIR, file)) - if ext == '.db': + if ext == '.db' or ext == '.tmp': # Just trigger off the .msg files. This may leave stale .db files # in qfiles, but these can't be cleaned up without storing a - # timestamp and watching out for race conditions. + # timestamp and watching out for race conditions. .tmp files are + # created by Message.Enqueue() and are fleeting. continue if not os.path.exists(root+'.db'): syslog('qrunner', 'Unlinking orphaned .msg file: %s.msg' % root) From marc_news@vasoftware.com Tue Apr 9 21:53:18 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 9 Apr 2002 13:53:18 -0700 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 In-Reply-To: <15539.21184.900827.591435@anthem.wooz.org> References: <20020409170815.GB9327@merlins.org> <15539.21184.900827.591435@anthem.wooz.org> Message-ID: <20020409205318.GH9327@merlins.org> On Tue, Apr 09, 2002 at 04:44:48PM -0400, Barry A. Warsaw wrote: > Arrgghh! Can you say MM2.0.10? :( Sorry. > See attached patch. Applied, thanks. > It should be. The first one is because somebody's got something bogus > in their message header, the second because they've enabled gatewaying > but the never set up an NNTP host. Oh, I know, the messages make sense, I'll just have to patch the code to find out which list they actually occur in :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Tue Apr 9 22:03:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 9 Apr 2002 17:03:48 -0400 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 References: <20020409170815.GB9327@merlins.org> <15539.21184.900827.591435@anthem.wooz.org> <20020409205318.GH9327@merlins.org> Message-ID: <15539.22324.908423.861827@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: >> Arrgghh! Can you say MM2.0.10? :( MM> Sorry. Yeah, you'll get yours, one of these days. :) >> See attached patch. MM> Applied, thanks. Can you keep an eye on the log files for a few days? I'm going to apply the same patch on python.org and watch it there too. If all looks good for a few days I'll release an update. Sigh. -Barry From marc_news@vasoftware.com Tue Apr 9 22:14:07 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 9 Apr 2002 14:14:07 -0700 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 In-Reply-To: <15539.22324.908423.861827@anthem.wooz.org> References: <20020409170815.GB9327@merlins.org> <15539.21184.900827.591435@anthem.wooz.org> <20020409205318.GH9327@merlins.org> <15539.22324.908423.861827@anthem.wooz.org> Message-ID: <20020409211406.GI9327@merlins.org> On Tue, Apr 09, 2002 at 05:03:48PM -0400, Barry A. Warsaw wrote: > >> See attached patch. > > MM> Applied, thanks. > > Can you keep an eye on the log files for a few days? I'm going to > apply the same patch on python.org and watch it there too. If all > looks good for a few days I'll release an update. Will do. So we are now running X-Mailman-Version: 2.0.9-sf.net Since I'm working on sf.net mailman anyway, I also wipped up the following (very very dirty) quick patch: diff -urN mailman-2.0.9.sf/Mailman/Handlers/Decorate.py mailman-2.0.9.sf.new/Mailman/Handlers/Decorate.py --- mailman-2.0.9.sf/Mailman/Handlers/Decorate.py Wed Aug 29 11:38:17 2001 +++ mailman-2.0.9.sf.new/Mailman/Handlers/Decorate.py Tue Apr 9 14:01:42 2002 @@ -38,12 +38,12 @@ try: header = string.replace(mlist.msg_header % d, '\r\n', '\n') except (ValueError, TypeError), e: - syslog('error', 'Exception while calculating message header:\n%s' % e) + syslog('error', 'Exception while calculating message header in list '+mlist.internal_name()+':\n%s' % e) header = '[INVALID HEADER]' try: footer = string.replace(mlist.msg_footer % d, '\r\n', '\n') except (ValueError, TypeError), e: - syslog('error', 'Exception while calculating message footer:\n%s' % e) + syslog('error', 'Exception while calculating message footer in list '+mlist.internal_name()+':\n%s' % e) footer = '[INVALID FOOTER]' msg.body = header + msg.body + footer # Mark the message as dirty so that its text will be forced to disk next diff -urN mailman-2.0.9.sf/Mailman/Handlers/ToUsenet.py mailman-2.0.9.sf.new/Mailman/Handlers/ToUsenet.py --- mailman-2.0.9.sf/Mailman/Handlers/ToUsenet.py Mon Nov 5 20:31:47 2001 +++ mailman-2.0.9.sf.new/Mailman/Handlers/ToUsenet.py Tue Apr 9 13:57:12 2002 @@ -44,8 +44,7 @@ if not mlist.nntp_host: error.append('no NNTP host') if error: - syslog('error', 'NNTP gateway improperly configured: ' + - string.join(error, ', ')) + syslog('error', 'NNTP gateway in list '+mlist.internal_name()+' improperly configured: ' + string.join(error, ', ')) return # Fork in case the nntp connection hangs. pid = os.fork() -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Tue Apr 9 22:15:42 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 9 Apr 2002 17:15:42 -0400 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 References: <20020409170815.GB9327@merlins.org> <15539.21184.900827.591435@anthem.wooz.org> <20020409205318.GH9327@merlins.org> <15539.22324.908423.861827@anthem.wooz.org> <20020409211406.GI9327@merlins.org> Message-ID: <15539.23038.700834.865827@anthem.wooz.org> Looks good. -Barry From barry@zope.com Wed Apr 10 06:02:16 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 10 Apr 2002 01:02:16 -0400 Subject: [Mailman-Developers] todigest.py References: <200204091419.g39EJ5i28730@babylon5.cc.vt.edu> Message-ID: <15539.51032.331613.381692@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Interesting... Started up the latest cvs before going home RJ> last night (yes, I let it run for a while before abandoning it RJ> :-)) RJ> When I came home my terminal window had a stream of these on RJ> it.. Looks like python was dropping the errors to stdout. Yup, email 2.0 deprecated some methods that ToDigest.py was still using. Fixed in cvs. -Barry From hellozappy2k@yahoo.com Wed Apr 10 10:37:16 2002 From: hellozappy2k@yahoo.com (sunny) Date: Wed, 10 Apr 2002 02:37:16 -0700 (PDT) Subject: [Mailman-Developers] Blocking few features for listadmin Message-ID: <20020410093716.14374.qmail@web13508.mail.yahoo.com> I am running mailman ver 2.08 on Solaris 8 with multiple listadmins the problem some listadmin's are changing The list admin's email address and also "Maximum length in Kb of a message body" to 0 which is choking the servers. Can i customize the mailman so that these fileds will not be available for the list admin to change. Regards DK __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From jarrell@vt.edu Wed Apr 10 14:18:41 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 10 Apr 2002 09:18:41 -0400 (EDT) Subject: [Mailman-Developers] Well, here's an interesting one Message-ID: <200204101318.g3ADIfQ23578@babylon5.cc.vt.edu> Apr 10 03:19:57 2002 (12285) message is unparsable: 1018423196.419311+a81685d7af 1f6631ce6392a83aff01fde476543f Apr 10 03:19:57 2002 (12285) lost data files for filebase: 1018423196.419311+a81 685d7af1f6631ce6392a83aff01fde476543f I don't mind the unparseability so much as the fact that it lost the files, so now I can't see *why* it was unparseable... Based on the syslog, I see which one it must have been. Looks like it was spam anyway, so hopefully it was just their spamming package mangling the message. From mrbill@mrbill.net Wed Apr 10 15:33:10 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Wed, 10 Apr 2002 09:33:10 -0500 Subject: [Mailman-Developers] Pre-list filtering? Message-ID: <20020410143310.GE26665@mrbill.net> Any suggestions on filtering messages *before* they get to the list? I've got a list that doesent allow directly replies back to the list, so I want to block all messages with a subject starting "Re:", "RE:", etc. Getting real tired of moderating/deleting 40-50 posts/day. 8-( The only way I can think to do this would be by changing the list submission alias to point to a "fake user", who would have a .procmailrc to dump the appropriate messages, then re-inject the messages back into mailman. However, this seems very hackish. Suggestions? Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From jarrell@vt.edu Wed Apr 10 16:19:14 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 10 Apr 2002 11:19:14 -0400 (EDT) Subject: [Mailman-Developers] more deprecation Message-ID: <200204101519.g3AFJEs03457@babylon5.cc.vt.edu> Apr 10 11:10:32 2002 admin(5085): /home/mailman/Mailman/MailList.py:839: Depreca tionWarning: Use email.Utils.formataddr() instead {"listname" : self.real_name, Apr 10 11:13:46 2002 qrunner(2873): /home/mailman/Mailman/Handlers/CookHeaders.p y:109: DeprecationWarning: Use email.Utils.formataddr() instead [email.Utils.dump_address_pair(pair) for pair in d.values()]) From marc_news@vasoftware.com Wed Apr 10 22:13:12 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 10 Apr 2002 14:13:12 -0700 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 In-Reply-To: <15539.22324.908423.861827@anthem.wooz.org> References: <20020409170815.GB9327@merlins.org> <15539.21184.900827.591435@anthem.wooz.org> <20020409205318.GH9327@merlins.org> <15539.22324.908423.861827@anthem.wooz.org> Message-ID: <20020410211311.GP9327@merlins.org> On Tue, Apr 09, 2002 at 05:03:48PM -0400, Barry A. Warsaw wrote: > MM> Applied, thanks. > > Can you keep an eye on the log files for a few days? I'm going to > apply the same patch on python.org and watch it there too. If all > looks good for a few days I'll release an update. No errors so far, it looks good. I'll be off (racing) tomorrow so if you want to wait that long, I can give you another update friday, but right now it definitely looks better. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Wed Apr 10 22:21:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 10 Apr 2002 17:21:45 -0400 Subject: [Mailman-Developers] os.unlink error with mm 2.0.9 References: <20020409170815.GB9327@merlins.org> <15539.21184.900827.591435@anthem.wooz.org> <20020409205318.GH9327@merlins.org> <15539.22324.908423.861827@anthem.wooz.org> <20020410211311.GP9327@merlins.org> Message-ID: <15540.44265.851913.112788@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> No errors so far, it looks good. I'll be off (racing) MM> tomorrow so if you want to wait that long, I can give you MM> another update friday, but right now it definitely looks MM> better. Cool, thanks! I probably won't get to the release until Friday anyway. Have fun, -Barry From barry@zope.com Thu Apr 11 05:50:51 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Apr 2002 00:50:51 -0400 Subject: [Mailman-Developers] Buglet in list_members (and others?) References: Message-ID: <15541.5675.662403.922506@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Oh, this is so obscure I'm embarrassed. Not at all, this makes a wonderful 1am catchup on email kind of bug. | % list_members typo_a_list_name > foo | % | % cat foo | No such list "typo_a_list_name" CVR> List_members returns errors to STDOUT, not STDERR. Fixed in cvs (for MM2.1 'natch). -Barry From barry@zope.com Thu Apr 11 06:57:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Apr 2002 01:57:43 -0400 Subject: [Mailman-Developers] Ok, this is weird... References: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> Message-ID: <15541.9687.24872.917187@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Hey, Barry? It's the topic processor causing it. I got a RJ> second message to that same list that generated the same RJ> error. I'd tried turning off topics before, since that was RJ> one of the two differences between the working, and non RJ> working, list. But when I did that, I didn't *delete* the RJ> topic, I just disabled it. (Although, if topics are disabled, RJ> that really should skip all the topic header RJ> scanning... Apparently it doesn't.) RJ> I tried disabling topics, *and* deleting my one trial topic. RJ> Suddenly the two messages (the one I sent you, and the latest RJ> one) would unshunt. RJ> The only trial topic I had was, for fooling around purposes, RJ> on that list was (from config_list): RJ> topics_enabled = 1 topics_bodylines_limit = 5 topics = RJ> [('Illuminati', '[fF]nord', 'Illuminated Messages', 0)] I've been trying to reproduce this with current cvs and am unable to. I'm not sure that the topic processor's logic is totally correct, but I also can't provoke the bugs you describe. Can you please do two things: try to update to current cvs, do a "./config.status ; make install ; cd $prefix ; bin/mailmanctl restart" If you still get the bugs, please step me through the recipe you're using to cause the bug. In the meantime, I'll try to convince myself about the logic of the topic processor. -Barry From gorg@sun1.imbi.uni-freiburg.de Thu Apr 11 11:11:15 2002 From: gorg@sun1.imbi.uni-freiburg.de (Georg Koch) Date: Thu, 11 Apr 2002 12:11:15 +0200 Subject: [Mailman-Developers] after processing a confirm in the subject line, the body should be ignored (v2.1b1) Message-ID: <200204111011.g3BABFO01698@sun31.imbi.uni-freiburg.de> Hi all, = if you send a "subscribe" or "unsubscribe" command via email to list-request@mailmanhost you get a confirmation message in reply which says "To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact.". = If you do so, but include the body of the confirm message, you get TWO messages back: a success message and a long error message stating "There were problems with the email commands you sent". = I find this confusing and think you cannot expect everyone to understand "reply" as "reply with an empty body". I would therefore propose the following behaviour change: After a confirm command from the Subject: header field of a message is processed successfully, the body of this message is ignored (not = processed). -- = -- Georg Koch (koch@cochrane.de) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany "All you need in this life is ignorance and confidence, and then = success is sure." (Mark Twain) From jarrell@vt.edu Thu Apr 11 11:30:02 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 06:30:02 -0400 Subject: [Mailman-Developers] New bug... Message-ID: <5.1.0.14.2.20020411062520.00a066b0@mail.vt.edu> Ok, here's the top of a message I got yesterday evening. Please note, this is *not* the header. This is everything from the first blank line in the note after the header, until the next blank line in the note. <5.1.0.14.2.20020410133754.02508db0@lennier.cc.vt.edu><1877.131.187.110.224.1018464240.squirrel@www.dnaco.net> <3CB48A42.2B3B5698@elfie.org> Subject: Re: [VTSFFC-L] What the bands want... Date: Wed, 10 Apr 2002 15:11:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-BeenThere: vtsffc-l@lists.vtsffc.org X-Mailman-Version: 2.1b1 Precedence: bulk Reply-To: vtsffc-l@lists.vtsffc.org List-Id: VTSFFC Mailing List List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: http://lists.vtsffc.org/mailman/private/vtsffc-l/ List-Help: Sender: vtsffc-l-bounces+jarrell=vt.edu@lists.vtsffc.org Errors-To: vtsffc-l-bounces+jarrell=vt.edu@lists.vtsffc.org Looks like a header, huh? But mailman put it in the *note* body. The header itself has *no* mailman headers in it. Also no subject in the real header, although it did have a *second* date and a from. Note the first couple of lines - I suspect that this might be related to the continuation header bug I've been running into - although topics are off now, and this is a different symptoms.. Before they just wouldn't post until I turned topics back off, but looked fine. From fil@rezo.net Thu Apr 11 11:32:34 2002 From: fil@rezo.net (Fil) Date: Thu, 11 Apr 2002 12:32:34 +0200 Subject: [Mailman-Developers] after processing a confirm in the subject line, the body should be ignored (v2.1b1) In-Reply-To: <200204111011.g3BABFO01698@sun31.imbi.uni-freiburg.de> References: <200204111011.g3BABFO01698@sun31.imbi.uni-freiburg.de> Message-ID: <20020411103234.GB5185@rezo.net> Oh yes! So much confusion... this is very much needed. If you want to be a bit more subtle, you could decide not to report errors if the first command was successful and no error was detected between two successful commands. Examples : command one (success) cottand two (failure : typo) command three (success) this should report an error, because it's usually coming from someone "who knows" command one (success) whatever (failure) whatever else (failure) ... this should reply "correct" @ Georg Koch : > Hi all, > > if you send a "subscribe" or "unsubscribe" command via email to > list-request@mailmanhost you get a confirmation message in reply which > says "To confirm that you want to be removed from this mailing list, > simply reply to this message, keeping the Subject: header intact.". -- Fil From jarrell@vt.edu Thu Apr 11 11:51:20 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 06:51:20 -0400 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <15541.9687.24872.917187@anthem.wooz.org> References: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020411064651.00a1b850@lennier.cc.vt.edu> At 01:57 AM 4/11/02 -0400, Barry A. Warsaw wrote: > >>>>> "RJ" == Ron Jarrell writes: > > RJ> Hey, Barry? It's the topic processor causing it. I got a > RJ> second message to that same list that generated the same > RJ> error. I'd tried turning off topics before, since that was > RJ> one of the two differences between the working, and non > RJ> working, list. But when I did that, I didn't *delete* the > RJ> topic, I just disabled it. (Although, if topics are disabled, > RJ> that really should skip all the topic header > RJ> scanning... Apparently it doesn't.) > > RJ> I tried disabling topics, *and* deleting my one trial topic. > RJ> Suddenly the two messages (the one I sent you, and the latest > RJ> one) would unshunt. > > RJ> The only trial topic I had was, for fooling around purposes, > RJ> on that list was (from config_list): > > RJ> topics_enabled = 1 topics_bodylines_limit = 5 topics = > RJ> [('Illuminati', '[fF]nord', 'Illuminated Messages', 0)] > >I've been trying to reproduce this with current cvs and am unable to. >I'm not sure that the topic processor's logic is totally correct, but >I also can't provoke the bugs you describe. > >Can you please do two things: try to update to current cvs, do a >"./config.status ; make install ; cd $prefix ; bin/mailmanctl restart" > >If you still get the bugs, please step me through the recipe you're >using to cause the bug. > >In the meantime, I'll try to convince myself about the logic of the >topic processor. I rebuild like that regularly... As I reported, it happened again a couple of days ago. That shut pickle set I sent you contains a message that triggers it every time. If I turn topics back on and install a topic (I used the one above, again), *eventually* a message will trigger the problem. Not every message does, just some. If I unshunt it, i'll just get repeated continuation before header errors. If I delete the topic, and turn off topics (just turning off topics wasn't enough the last time, I had to also delete the topic list) it'll unshunt just fine. Hence why I'm blaming the topic processor! From jarrell@vt.edu Thu Apr 11 14:13:28 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 09:13:28 -0400 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <15541.9687.24872.917187@anthem.wooz.org> References: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020411090703.05d0a250@lennier.cc.vt.edu> At 01:57 AM 4/11/02 -0400, Barry A. Warsaw wrote: >If you still get the bugs, please step me through the recipe you're >using to cause the bug. Ok. I updated cvs. I configed again, did a make, a make install. All the mailman daemons were stopped before, and started after. All the .pyc files properly generated. I'm about as current as it's possible to get. I turned topics back on. I put back my test topic. I used my archived copy of the shunt files that I sent you some time ago, and unshunted them back into the queue. They failed again with the same error... Apr 11 09:04:44 2002 (11160) Uncaught runner exception: Continuation line seen before first header Apr 11 09:04:44 2002 (11160) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Tagger.py", line 47, in process matchlines.extend(scanbody(msg, mlist.topics_bodylines_limit)) File "/home/mailman/Mailman/Handlers/Tagger.py", line 101, in scanbody msg = email.message_from_string(EMPTYSTRING.join(lines)) File "/home/mailman/pythonlib/email/__init__.py", line 36, in message_from_string return _Parser(_class).parsestr(s) File "/home/mailman/pythonlib/email/Parser.py", line 45, in parsestr return self.parse(StringIO(text)) File "/home/mailman/pythonlib/email/Parser.py", line 40, in parse self._parseheaders(root, fp) File "/home/mailman/pythonlib/email/Parser.py", line 76, in _parseheaders raise Errors.HeaderParseError( HeaderParseError: Continuation line seen before first header As a reminder - this is a message that went to list1,list2, made it to list1, but kept bouncing to list2. The only real difference in the two list configs is one had topics enabled, and one didn't. If I delete the topic and turn off topic processing, this note will unshunt and post to list2 as well. Here's the relevant section from config_list for list2: topics_enabled = 1 topics_bodylines_limit = 5 topics = [('Iluminatti', '[F][f]nord', 'Illuminated Messages', 0)] I'm guessing that there's something wrong in the way Tagger calls Parser in this case... I'll eyeball the code again myself; maybe a fresh pair of eyes will catch something you're missing cause you've been staring at it too long. From jarrell@vt.edu Thu Apr 11 14:24:49 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 09:24:49 -0400 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <15541.9687.24872.917187@anthem.wooz.org> References: <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020411091513.084c9210@lennier.cc.vt.edu> Ok, well, one thing I see... Tagger.py:33 Shouldn't if not mlist.topics: be if not mlist.topics_enabled: ? Because this is why I'm seeing the "must delete topics" to fix the problem. If you disable topics, but have topic defined, you still end up scanning for them. If they're not enabled, we shouldn't bother doing the work, even if there are some defined. From jarrell@vt.edu Thu Apr 11 14:38:54 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 09:38:54 -0400 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <5.1.0.14.2.20020411090703.05d0a250@lennier.cc.vt.edu> References: <15541.9687.24872.917187@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020411092818.06262d70@lennier.cc.vt.edu> At 09:13 AM 4/11/02 -0400, Ron Jarrell wrote: >I'm guessing that there's something wrong in the way Tagger calls >Parser in this case... I'll eyeball the code again myself; maybe a >fresh pair of eyes will catch something you're missing cause you've >been staring at it too long. Hah! This is my morning for epiphanies. I suppose that it helps that this turns out to be very similar to a problem the mirapoint scanners were having this morning, and I already had the brainstorm that figured out their continuation header processing was broken. You've got a logic flaw. Let me guess, you don't indent much when you write prose, do you :-)? You allow through lines that start with a whitespace into the new message object that you're building to parse the headers out of, since they're likely a continuation header. But they're likely not a continuation header *in the body of the message*! Send a message to a list with topics defined. (See my previous note about the bug in topics_enabled - only the gui uses it, Tagger keys on topics defined. Indent the first line. Like: Hi there You should get the error when Parser hits it before it hits anything else in the new "header". Tagger.py:96 says: if line[0] not in ' \t' and line.find(':') < 0: So any line that starts with a whitespace gets bundled into the test, even if the *previous* line wasn't a possible header line. If you want to support continuation lines on pseudo-headers in the body, you either need to maintain state like Parser does, to decide whether it's really a continuation, or just an indented line, or just bag that test all together, and only accept lines with a ":", and not support continuation lines in the pseudo-headers. From jarrell@vt.edu Thu Apr 11 14:56:00 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 09:56:00 -0400 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <5.1.0.14.2.20020411092818.06262d70@lennier.cc.vt.edu> References: <5.1.0.14.2.20020411090703.05d0a250@lennier.cc.vt.edu> <15541.9687.24872.917187@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020411094510.06234160@lennier.cc.vt.edu> At 09:38 AM 4/11/02 -0400, Ron Jarrell wrote: >if line[0] not in ' \t' and line.find(':') < 0: Ok. My patch (because I'm lazy enough to decide that supporting pseudo continuations is not nearly important enough to worry about) is: Index: Tagger.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Tagger.py,v retrieving revision 2.3 diff -r2.3 Tagger.py 33c33 < if not mlist.topics: --- > if not mlist.topics_enabled: 96c96 < if line[0] not in ' \t' and line.find(':') < 0: --- > if line[0] in ' \t' or line.find(':') < 0: This does work, and the messages now unshunt just hunky-dory. From barry@zope.com Thu Apr 11 19:05:29 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Apr 2002 14:05:29 -0400 Subject: [Mailman-Developers] Ok, this is weird... References: <15541.9687.24872.917187@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> <5.1.0.14.2.20020411092818.06262d70@lennier.cc.vt.edu> Message-ID: <15541.53353.121851.768960@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> This is my morning for epiphanies. Yay! I'm glad somebody's getting them. ;) RJ> You've got a logic flaw. Let me guess, you don't indent much RJ> when you write prose, do you :-)? Heh, no. I think you've nailed the problem right on the head, thanks! Of course, I just have to have a more elaborate fix, which sweater-threaded a few other bugs, but I think I now have this working. CVS commits to take place momentarily. Thanks Ron! -Barry From jarrell@vt.edu Thu Apr 11 20:15:30 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Apr 2002 15:15:30 -0400 Subject: [Mailman-Developers] Ok, this is weird... In-Reply-To: <15541.53353.121851.768960@anthem.wooz.org> References: <15541.9687.24872.917187@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> <5.1.0.14.2.20020411092818.06262d70@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020411151451.041cce00@lennier.cc.vt.edu> At 02:05 PM 4/11/02 -0400, Barry A. Warsaw wrote: >working. CVS commits to take place momentarily. Did you mean to leave the syslog('debug',foo) lines in Tagger files in cvs? From barry@zope.com Thu Apr 11 20:42:38 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Apr 2002 15:42:38 -0400 Subject: [Mailman-Developers] Ok, this is weird... References: <15541.9687.24872.917187@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> <5.1.0.14.2.20020411092818.06262d70@lennier.cc.vt.edu> <5.1.0.14.2.20020411151451.041cce00@lennier.cc.vt.edu> Message-ID: <15541.59182.475375.988483@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: >> working. CVS commits to take place momentarily. RJ> Did you mean to leave the syslog('debug',foo) lines in Tagger RJ> files in cvs? Of course! I always do everythign on purpose. Oh alright, I'll remove them. SIGH. :) -Barry From barry@zope.com Thu Apr 11 20:48:47 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Apr 2002 15:48:47 -0400 Subject: [Mailman-Developers] Ok, this is weird... References: <15541.9687.24872.917187@anthem.wooz.org> <200203270416.g2R4GLH23032@babylon5.cc.vt.edu> <5.1.0.14.2.20020329005847.0553eec0@lennier.cc.vt.edu> <5.1.0.14.2.20020411092818.06262d70@lennier.cc.vt.edu> <5.1.0.14.2.20020411151451.041cce00@lennier.cc.vt.edu> <15541.59182.475375.988483@anthem.wooz.org> Message-ID: <15541.59551.426482.78255@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> Of course! I always do everythign on purpose. Oh alright, ----------------------------------------^^^ includign that -Barry From eric@aquameta.com Fri Apr 12 00:32:53 2002 From: eric@aquameta.com (Eric Hanson) Date: Thu, 11 Apr 2002 23:32:53 +0000 Subject: [Mailman-Developers] pipermail replacement In-Reply-To: <19353.1018287744@kanga.nu>; from claw@kanga.nu on Mon, Apr 08, 2002 at 10:42:24AM -0700 References: <20020408033353.A30300@aquameta.com> <19353.1018287744@kanga.nu> Message-ID: <20020411233253.A56234@aquameta.com> J C Lawrence (claw@kanga.nu) wrote: > On Mon, 8 Apr 2002 03:33:53 +0000 > Eric Hanson wrote: > > > There have been several mentions of the need for a mailing list with a > > web interface, something that allows mailing list functionality and a > > web interface that allows posting, user accounts, threading etc. I've > > been thinking about such a thing using the XML server 4suite server > > (4suite.org) and mailman, essentially replacing pipermail. > > You might like to look at what I've done under MHonArc and PHP here at > Kanga.Nu. I specifically don't handle accounts, but I do handle > posting, MIME, and the rest. > > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.004.htp Interesting. I've got some MIME questions but I'll post them on the project mailing list. The project is called archetype, and it's on sourceforge: http://sourceforge.net/projects/archetype The mailing list has been created and Sourceforge should activate it in 6-24 hours. Regards, Eric From chuqui@plaidworks.com Fri Apr 12 20:21:42 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 12 Apr 2002 12:21:42 -0700 Subject: [Mailman-Developers] From the mhonarc list Message-ID: For those who don't track mhonarc, from the mhonarc list. Looks very interesting... > > One thing that may be of interest to users is I have developed > a mail archiving system that using Procmail, MHonArc, and Namazu > to easily manage mail archives for multiple lists. Features will > include automatic generation of monthly or yearly archives, searching > (via Namazu), raw mail archives, and archive rebuilding. I consider > the software experimental, but it appears to run well on Unix-type > systems (like Linux) only. The current name of the package is "mharc". > -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From fil@rezo.net Fri Apr 12 20:52:02 2002 From: fil@rezo.net (Fil) Date: Fri, 12 Apr 2002 21:52:02 +0200 Subject: [Mailman-Developers] two spaces in subject lines Message-ID: <20020412195202.GA3849@rezo.net> Since I upgraded to have iso_xxx compliant subjects, I notice that most emails go through with TWO spaces after the usual subject_prefix, on all lists. I don't really mind, but just wanted to mention it. -- Fil From fil@rezo.net Fri Apr 12 22:13:01 2002 From: fil@rezo.net (Fil) Date: Fri, 12 Apr 2002 23:13:01 +0200 Subject: [Mailman-Developers] two spaces in subject lines In-Reply-To: <20020412195202.GA3849@rezo.net> References: <20020412195202.GA3849@rezo.net> Message-ID: <20020412211301.GA9838@rezo.net> > Since I upgraded to have iso_xxx compliant subjects, I notice that most > emails go through with TWO spaces after the usual subject_prefix, on all > lists. I don't really mind, but just wanted to mention it. Precisely, here's how it happens : "Subject: =?iso-8859-1?q?=5Bspip-dev=5D_?=" " petite mise a jour =?iso-8859-1?Q?s=E9curi?=" " =?iso-8859-1?Q?t=E9?= inc_auth_cookie" (I've enclosed the lines with "" so there are no surprises) -- Fil From che@debian.org Sat Apr 13 03:50:50 2002 From: che@debian.org (Ben Gertzfield) Date: Sat, 13 Apr 2002 11:50:50 +0900 Subject: [Mailman-Developers] two spaces in subject lines In-Reply-To: <20020412211301.GA9838@rezo.net> Message-ID: <43A3C3A4-4E89-11D6-9307-0003931E4DBC@debian.org> On Saturday, April 13, 2002, at 06:13 , Fil wrote: >> Since I upgraded to have iso_xxx compliant subjects, I notice that most >> emails go through with TWO spaces after the usual subject_prefix, on >> all >> lists. I don't really mind, but just wanted to mention it. > > Precisely, here's how it happens : > > "Subject: =?iso-8859-1?q?=5Bspip-dev=5D_?=" > " petite mise a jour =?iso-8859-1?Q?s=E9curi?=" > " =?iso-8859-1?Q?t=E9?= inc_auth_cookie" This is an interesting side case. RFC 2047 says that between encoded words, whitespace is to be ignored; however, here, we have encoded words with US-ASCII in between them. I think the email.Header package I wrote is doing the wrong thing here. Either we need represent the whole thing as one or more encoded-words, or we need to be super anal about whitespace between encoded-words and non- encoded-words. I am currently moving from Tokyo to California, but when I get back and settled I will take a long hard look at this issue. I agree that it's pretty important, and that email.Header is doing the wrong thing with respect to whitespace between encoded-words and non- encoded-words: >>> from email.Header import Header, decode_header >>> from email.Charset import Charset >>> f = Charset("iso-8859-1") >>> z = Header("Zout alours!", f) >>> z >>> print z =?iso-8859-1?q?Zout_alours!?= >>> z.append(" Hello?") >>> print z =?iso-8859-1?q?Zout_alours!?= Hello? >>> decode_header(z) [('Zout alours!', 'iso-8859-1'), ('Hello?', None)] Here, the whitespace should *not* be disappearing in decode_header, and in fact there should only be one space between the encoded-word and "Hello?" in the printed-out header. It's certainly a thinko in email.Header. I will work on this in a week or so.. Ben From stephen@xemacs.org Sat Apr 13 06:59:48 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 13 Apr 2002 14:59:48 +0900 Subject: [Mailman-Developers] two spaces in subject lines In-Reply-To: <43A3C3A4-4E89-11D6-9307-0003931E4DBC@debian.org> References: <43A3C3A4-4E89-11D6-9307-0003931E4DBC@debian.org> Message-ID: <87ads85eaz.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Ben" == Ben Gertzfield writes: Ben> I think the email.Header package I wrote is doing the wrong Ben> thing here. Yup. Ben> Either we need represent the whole thing as one or more Ben> encoded-words, or we need to be super anal about whitespace Ben> between encoded-words and non- encoded-words. The latter. What are you going to do with encodings you know nothing about, eg, if I send a message with Subject: =?sjt-1?q?=49=74=27=73=20=6A=75=73=74=20=41=53=43=49=49=21?= in it? Ben> It's certainly a thinko in email.Header. RFC-2822-parsing is a dirty job. dewa, matane. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From che@debian.org Sat Apr 13 07:07:04 2002 From: che@debian.org (Ben Gertzfield) Date: Sat, 13 Apr 2002 15:07:04 +0900 Subject: [Mailman-Developers] two spaces in subject lines In-Reply-To: <87ads85eaz.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: On Saturday, April 13, 2002, at 02:59 , Stephen J. Turnbull wrote: > Ben> Either we need represent the whole thing as one or more > Ben> encoded-words, or we need to be super anal about whitespace > Ben> between encoded-words and non- encoded-words. > > The latter. What are you going to do with encodings you know nothing > about, eg, if I send a message with > > Subject: =?sjt-1?q?=49=74=27=73=20=6A=75=73=74=20=41=53=43=49=49=21?= > > in it? Of course, we wouldn't do anything at all with that, regarding whitespace. I'm talking about when encoded-words and non- encoded-words are mixed together. But I totally agree that we need to be anal; it's just hard to know ahead of time whether to encode the next space as part of an encoded-word, or as the space between an encoded-word and a non- encoded-word. But we certainly must not do both! Ben From marc_news@vasoftware.com Sat Apr 13 08:32:51 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 13 Apr 2002 00:32:51 -0700 Subject: [Mailman-Developers] Changing web_page_url in mm 2.1 Message-ID: <20020413073250.GF8415@merlins.org> I have web_page_url set to the wrong value for a list I just created. Outside of using config_list, is there any easier way to change the domain the list is in? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From Dan Mick Sat Apr 13 08:38:00 2002 From: Dan Mick (Dan Mick) Date: Sat, 13 Apr 2002 00:38:00 -0700 (PDT) Subject: [Mailman-Developers] Changing web_page_url in mm 2.1 Message-ID: <200204130738.g3D7cCWk007112@utopia.West.Sun.COM> > I have web_page_url set to the wrong value for a list I just created. > Outside of using config_list, is there any easier way to change the domain > the list is in? I believe config_list won't do it. withlist. Go with God. From marc_news@vasoftware.com Sat Apr 13 23:22:36 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 13 Apr 2002 15:22:36 -0700 Subject: [Mailman-Developers] Changing web_page_url in mm 2.1 In-Reply-To: <200204130738.g3D7cCWk007112@utopia.West.Sun.COM> References: <200204130738.g3D7cCWk007112@utopia.West.Sun.COM> Message-ID: <20020413222235.GH8415@merlins.org> On Sat, Apr 13, 2002 at 12:38:00AM -0700, Dan Mick wrote: > > > I have web_page_url set to the wrong value for a list I just created. > > Outside of using config_list, is there any easier way to change the domain > > the list is in? > > I believe config_list won't do it. withlist. Indeed, you're right (I also apparently found a bug in config_list): moremagic.m.o:/var/local/mailman/bin# ./dumpdb ../lists/bamo/config.pck | grep web_page_url 'digest_footer': '_______________________________________________\n%(real_name)s mailing list\n%(real_name)s@%(host_name)s\n%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s\n', 'msg_footer': '_______________________________________________\n%(real_name)s mailing list\n%(real_name)s@%(host_name)s\n%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s\n', 'web_page_url': 'http://www.merlins.org/lists/', moremagic.m.o:/var/local/mailman/bin# echo "web_page_url = http://lists.merlins.org/lists/" | ./config_list -i - bamo Traceback (most recent call last): File "./config_list", line 270, in ? main() File "./config_list", line 264, in main do_input(listname, infile, checkonly, verbose) File "./config_list", line 207, in do_input execfile(infile, globals) IOError: [Errno 2] No such file or directory moremagic.m.o:/var/local/mailman/bin# cat >/tmp/setting web_page_url = http://lists.merlins.org/lists/ moremagic.m.o:/var/local/mailman/bin# ./config_list -i /tmp/list bamo moremagic.m.o:/var/local/mailman/bin# ./dumpdb ../lists/bamo/config.pck | grep web_page_url 'digest_footer': '_______________________________________________\n%(real_name)s mailing list\n%(real_name)s@%(host_name)s\n%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s\n', 'msg_footer': '_______________________________________________\n%(real_name)s mailing list\n%(real_name)s@%(host_name)s\n%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s\n', 'web_page_url': 'http://www.merlins.org/lists/', We probably need a quick script to change this value for a list Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From chk@pobox.com Sat Apr 13 23:52:40 2002 From: chk@pobox.com (Harald Koch) Date: Sat, 13 Apr 2002 18:52:40 -0400 Subject: [Mailman-Developers] Re: Changing web_page_url in mm 2.1 In-Reply-To: marc_news's message of "Sat, 13 Apr 2002 15:22:36 -0700". <20020413222235.GH8415@merlins.org> References: <200204130738.g3D7cCWk007112@utopia.West.Sun.COM> <20020413222235.GH8415@merlins.org> Message-ID: <26011.1018738360@elisabeth.cfrq.net> > We probably need a quick script to change this value for a list There is, it's called fix_url, as in: bin/withlist -l -r fix_url which will rebuild the value of web_page_url based on the defaults in Defaults.py and mm_cfg.py. (I asked this question before, which is the only reason I know the answer; perhaps an entry in the FAQ is in order? :-) -- Harald Koch From spertus@mills.edu Sat Apr 13 23:54:23 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sat, 13 Apr 2002 15:54:23 -0700 Subject: [Mailman-Developers] Supporting multiple incoming email addresses Message-ID: <5.1.0.14.0.20020413155009.044fcf48@ella.mills.edu> --=====================_15606070==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Is anyone working on allowing users to specify multiple incoming mail addresses so they can, for example, post from their home and work addresses even if they are only subscribed at their work address? I am assuming member_posting_only has been set. Ellen --=====================_15606070==_.ALT Content-Type: text/html; charset="us-ascii" Is anyone working on allowing users to specify multiple incoming mail addresses so they can, for example, post from their home and work addresses even if they are only subscribed at their work address?  I am assuming member_posting_only has been set.

Ellen

--=====================_15606070==_.ALT-- From claw@kanga.nu Sun Apr 14 04:47:03 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 13 Apr 2002 20:47:03 -0700 Subject: [Mailman-Developers] Supporting multiple incoming email addresses In-Reply-To: Message from Ellen Spertus of "Sat, 13 Apr 2002 15:54:23 PDT." <5.1.0.14.0.20020413155009.044fcf48@ella.mills.edu> References: <5.1.0.14.0.20020413155009.044fcf48@ella.mills.edu> Message-ID: <20853.1018756023@kanga.nu> On Sat, 13 Apr 2002 15:54:23 -0700 Ellen Spertus wrote: > Is anyone working on allowing users to specify multiple incoming mail > addresses so they can, for example, post from their home and work > addresses even if they are only subscribed at their work address? I > am assuming member_posting_only has been set. Oft requested, currently not supported, please see FAQ for solution: http://www.python.org/cgi-bin/faqw-mm.py -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From spertus@mills.edu Sun Apr 14 05:16:50 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sat, 13 Apr 2002 21:16:50 -0700 Subject: [Mailman-Developers] Supporting multiple incoming email addresses In-Reply-To: <20853.1018756023@kanga.nu> References: <5.1.0.14.0.20020413155009.044fcf48@ella.mills.edu> <5.1.0.14.0.20020413155009.044fcf48@ella.mills.edu> Message-ID: <5.1.0.14.0.20020413211634.043b7d70@ella.mills.edu> Thanks. I hadn't even known about that FAQ. Ellen At 08:47 PM 4/13/2002 -0700, J C Lawrence wrote: >On Sat, 13 Apr 2002 15:54:23 -0700 >Ellen Spertus wrote: > > > Is anyone working on allowing users to specify multiple incoming mail > > addresses so they can, for example, post from their home and work > > addresses even if they are only subscribed at their work address? I > > am assuming member_posting_only has been set. > >Oft requested, currently not supported, please see FAQ for solution: > > http://www.python.org/cgi-bin/faqw-mm.py > >-- >J C Lawrence >---------(*) Satan, oscillate my metallic sonatas. >claw@kanga.nu He lived as a devil, eh? >http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From spertus@mills.edu Mon Apr 15 00:36:27 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sun, 14 Apr 2002 16:36:27 -0700 Subject: [Mailman-Developers] Number of Mailman users? Message-ID: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> Any ballpark estimates on the number of Mailman subscribers globally? Given that the FAQ mentions a list with 147,000 users, it seems safe to say that there are millions of Mailman users. What do you think? I'd like a number for a grant report I'm writing. Ellen From marc_news@vasoftware.com Mon Apr 15 00:43:38 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 14 Apr 2002 16:43:38 -0700 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> Message-ID: <20020414234338.GM347@merlins.org> On Sun, Apr 14, 2002 at 04:36:27PM -0700, Ellen Spertus wrote: > Any ballpark estimates on the number of Mailman subscribers > globally? Given that the FAQ mentions a list with 147,000 users, it seems > safe to say that there are millions of Mailman users. What do you think? Yes, there are several millions. Sourceforge.net probably has 3/400k (it would take a while to get the exact number), and a few other big sites have similar numbers too > I'd like a number for a grant report I'm writing. I think you'llhave to stick to "several millions", this is open source software, and Barry doesn't receive per user license fees, so he can't count them either :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From spertus@mills.edu Mon Apr 15 00:47:31 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sun, 14 Apr 2002 16:47:31 -0700 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: <20020414234338.GM347@merlins.org> References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> Message-ID: <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> Do we know what the most popular open-source mlm is? My guess would be Mailman, but that's just off the top of my head. I already got a flame for working on Mailman, rather than ezmlm, because of the perceived restrictiveness of the GPL. Ellen From marc_news@vasoftware.com Mon Apr 15 00:58:28 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 14 Apr 2002 16:58:28 -0700 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> Message-ID: <20020414235828.GN347@merlins.org> On Sun, Apr 14, 2002 at 04:47:31PM -0700, Ellen Spertus wrote: > Do we know what the most popular open-source mlm is? My guess would be > Mailman, but that's just off the top of my head. Either mailman or majordomo, hard to say. Majordomo had a big installed base, but it's losing grounds quickly (it was far from being the best, but it was the most popular) > I already got a flame for working on Mailman, rather than ezmlm, because of > the perceived restrictiveness of the GPL. You can point those people to the restrictions in qmail (which you more or less need to run ezmlm). http://www.linuxmafia.com/~rick/faq/#djb After that, you notice that you have ezmlm and ezmlm-idx maintained by different people than the author (DJB), and the strange absence of license on the ezmlm.org web site (I didn't download it to check further). Of course, qmail itself isn't open source. I'd *much* rather be working with Barry than DJB, thank you :-) Marc PS: ezmlm isn't crap though, it has some nice features that mailman doesn't quite match yet. -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From spacey-mailman@lenin.nu Mon Apr 15 04:30:53 2002 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Sun, 14 Apr 2002 20:30:53 -0700 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: <20020414235828.GN347@merlins.org> References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> <20020414235828.GN347@merlins.org> Message-ID: <20020415033053.GD5495@lenin.nu> On Sun, Apr 14, 2002 at 04:58:28PM -0700, Marc MERLIN wrote: > Either mailman or majordomo, hard to say. > Majordomo had a big installed base, but it's losing grounds quickly > (it was far from being the best, but it was the most popular) For a long time it was the top of the heap among a large variety of really, really, actually crappy mlm's. > > I already got a flame for working on Mailman, rather than ezmlm, because of > > the perceived restrictiveness of the GPL. > > You can point those people to the restrictions in qmail (which you more or > less need to run ezmlm). Less. Since postfix and courier both implement sub-addresses, you can use them to manage ezmlm. Since sendmail can be made to do that as well, you can probably make ezmlm work with sendmail these days, too. > http://www.linuxmafia.com/~rick/faq/#djb This is better then some of the silly things that I've read in the past on Rick's crackmonkey pages. But what it comes down to is 2 things: 1) Rick thinks he knows more about programming then djb 2) Rick doesn't like the license. However I haven't seen Rick produce or distribute very much software, and his presentations of his "reasons" for why he belittles djb (rather then, say writing his own, better, MTA) has made me unlikely to take his software/solutions recommendations seriously. > After that, you notice that you have ezmlm and ezmlm-idx maintained by > different people than the author (DJB), and the strange absence of license > on the ezmlm.org web site (I didn't download it to check further). > Of course, qmail itself isn't open source. > > I'd *much* rather be working with Barry than DJB, thank you :-) Agreed, but the Freds who maintain ezmlm-idx are competant and knowledgeable, too. I like the fact that unlike when I was wondering, years ago if it was better to use /etc/aliases instead of majordomo/smartlist/whatever oddball list server, that now there are at least 2 good mlm's out there. > PS: ezmlm isn't crap though, it has some nice features that mailman doesn't > quite match yet. And its faster then oatmeal through an incontinent intestine. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From marc_news@vasoftware.com Mon Apr 15 04:50:42 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 14 Apr 2002 20:50:42 -0700 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: <20020415033053.GD5495@lenin.nu> References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> <20020414235828.GN347@merlins.org> <20020415033053.GD5495@lenin.nu> Message-ID: <20020415035042.GT347@merlins.org> On Sun, Apr 14, 2002 at 08:30:53PM -0700, Peter C. Norton wrote: > On Sun, Apr 14, 2002 at 04:58:28PM -0700, Marc MERLIN wrote: > > Either mailman or majordomo, hard to say. > > Majordomo had a big installed base, but it's losing grounds quickly > > (it was far from being the best, but it was the most popular) > > For a long time it was the top of the heap among a large variety of > really, really, actually crappy mlm's. You are correct, majordomo isn't all that bad, it's just rather inefficient. > > You can point those people to the restrictions in qmail (which you more or > > less need to run ezmlm). > > Less. Since postfix and courier both implement sub-addresses, you can > use them to manage ezmlm. Since sendmail can be made to do that as > well, you can probably make ezmlm work with sendmail these days, too. hence "more or less" You are correct, but I don't know anyone who has done this yet. > > http://www.linuxmafia.com/~rick/faq/#djb > > 2) Rick doesn't like the license. or lack thereof, which causes implied issues (outlined by Rick) That's my point too. As far as I can tell, this is accurate: ---------------------------------------------------------------------------- They are thus definitively proprietary software -- with limited rights of gratis use if you acquire the package from Bernstein or someone he's specifically authorised to distribute it. Therefore, if you repair his bizarre design decisions, you may not share your work (except as patches, add-ons, or reconfiguration recommendations), and must re-do that repair work with each new version. You also may not put up even unmodified versions for public access (of many of his packages) without special permission. ---------------------------------------------------------------------------- > However I haven't seen Rick produce or distribute very much software, Rick is, like me, a sysadmin. He has proabably donated more of his time to the linux community than you and me. But we are not talking about him, are we? > (rather then, say writing his own, better, MTA) has made me unlikely Why? Exim and postfix are fine choices. There are others I'm sure. Why write yet another MTA? > Agreed, but the Freds who maintain ezmlm-idx are competant and > knowledgeable, too. I like the fact that unlike when I was wondering I don't dispute this. In the meantime however: moremagic:/tmp/ezmlm-0.53# grep -i license * moremagic:/tmp/ezmlm-0.53# ezmlm-idx-0.40 includes the GPL license file, but doesn't state anywhere that's it's licensed under the GPL, nor do I know if it can since it's based on ezmlm, which itself is not (as far as I know, GPL compliant, or even open source software) The original point being that criticizing MM for being GPL in favor of ezmlm is probably not the smartest thing one can do IMO, considering the license issues around ezmlm... I'll stop my contributions to this thread here, though. This is getting off topic. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From bob@nleaudio.com Mon Apr 15 06:35:17 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Mon, 15 Apr 2002 01:35:17 -0400 Subject: [Mailman-Developers] throttling back MTA Message-ID: <3CBA6695.AA34270@nleaudio.com> Hello, I posted some messages on the Postfix users list, but only received replies about restricting bandwidth. I'm noticing more and more "connection timed out" message in my mail log from when Mailman is sending out thousands of messages at once. What is the best way to deal with this, assuming you don't have a really fat pipe to the internet? Bob From stephen@xemacs.org Mon Apr 15 16:53:54 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 16 Apr 2002 00:53:54 +0900 Subject: [Mailman-Developers] two spaces in subject lines In-Reply-To: References: Message-ID: <87bsclx8j1.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Ben" == Ben Gertzfield writes: Ben> On Saturday, April 13, 2002, at 02:59 , Stephen J. Turnbull Ben> wrote: Ben> Either we need represent the whole thing as one or more Ben> encoded-words, or we need to be super anal about whitespace Ben> between encoded-words and non- encoded-words. >> The latter. What are you going to do with encodings you know >> nothing about, eg, if I send a message with >> >> Subject: >> =?sjt-1?q?=49=74=27=73=20=6A=75=73=74=20=41=53=43=49=49=21?= >> >> in it? Ben> Of course, we wouldn't do anything at all with that, Ben> regarding whitespace. I'm talking about when encoded-words Ben> and non- encoded-words are mixed together. On this list it should end up looking like this: Subject: [Mailman-Developers] =?sjt-1?q?=49=74=27=73=20=6A=75=73=74=20=41=53=43=49=49=21?= or so, no? Urk, folded at the whitespace and all.... -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From claw@kanga.nu Mon Apr 15 18:01:13 2002 From: claw@kanga.nu (J C Lawrence) Date: Mon, 15 Apr 2002 10:01:13 -0700 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: Message from Marc MERLIN of "Sun, 14 Apr 2002 16:43:38 PDT." <20020414234338.GM347@merlins.org> References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <20020414234338.GM347@merlins.org> Message-ID: <11514.1018890073@kanga.nu> On Sun, 14 Apr 2002 16:43:38 -0700 Marc MERLIN wrote: > I think you'llhave to stick to "several millions", this is open source > software, and Barry doesn't receive per user license fees, so he can't > count them either :-) There's also a high collision rate between lists and among address->human mappings. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From adi@adiraj.org Mon Apr 15 18:39:37 2002 From: adi@adiraj.org (Adi Fairbank) Date: Mon, 15 Apr 2002 10:39:37 -0700 Subject: [Mailman-Developers] [PATCH] logo disabling, and extra " This is a multi-part message in MIME format. --------------B069478256E84581F1B5DB14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are two quick patches I made (both against version 2.0.8): First one is a new feature which makes it easy to disable display of sponsor logos (I don't know if you wanted this to be so easy or not, but here it is). Second one is a minor bugfix which removes an extra "%s' % (tab, self.title)) output.append('%s' % tab) - output.append('%s; from Marc MERLIN on Sun, Apr 14, 2002 at 04:58:28PM -0700 References: <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> <20020414235828.GN347@merlins.org> Message-ID: <20020415134137.64815@scfn.thpl.lib.fl.us> On Sun, Apr 14, 2002 at 04:58:28PM -0700, Marc MERLIN wrote: > I'd *much* rather be working with Barry than DJB, thank you :-) I'd like to second, third, and *fourth* this. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From terri@zone12.com Mon Apr 15 19:33:18 2002 From: terri@zone12.com (Terri Oda) Date: Mon, 15 Apr 2002 14:33:18 -0400 Subject: [Mailman-Developers] Number of Mailman users? In-Reply-To: <20020415035042.GT347@merlins.org> References: <20020415033053.GD5495@lenin.nu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414163331.045f6830@ella.mills.edu> <5.1.0.14.0.20020414164602.04720728@ella.mills.edu> <20020414235828.GN347@merlins.org> <20020415033053.GD5495@lenin.nu> Message-ID: <5.1.0.14.0.20020415135428.031e9410@pop.ncf.carleton.ca> At 08:50 PM 14/04/02 -0700, you wrote: > You are correct, majordomo isn't all that bad, it's just rather inefficient. It wasn't bad at all... except that time when one of my list admins went and subscribed majordomo to one of its own reply-to-list lists. So someone sent somethign to the list, and majordomo responded with the entire help text. Then it got the help text it had sent out and responded with the entire help text... After 200 messages or so, it aborted. :P I haven't tried subscribing a mailman-request address to a list to see if that can happen with mailman. :) Terri From chuqui@plaidworks.com Mon Apr 15 19:58:23 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 15 Apr 2002 11:58:23 -0700 Subject: [Mailman-Developers] Rah, Barry! In-Reply-To: <20020415134137.64815@scfn.thpl.lib.fl.us> Message-ID: >> I'd *much* rather be working with Barry than DJB, thank you :-) > > I'd like to second, third, and *fourth* this. Definitely. On the other hand, I won't work with djb. That doesn't mean I'm right and he's wrong. It just means I won't work with him.... And I'm sure knowing that makes his day, too. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From marc_news@vasoftware.com Mon Apr 15 22:09:56 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 15 Apr 2002 14:09:56 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: Editability of messages In-Reply-To: <1598000234.1018857301@tom-9k5kaocfpin> References: <20020415033446.29700.82480.Mailman@mail.python.org> <1598000234.1018857301@tom-9k5kaocfpin> Message-ID: <20020415210955.GM25045@merlins.org> On Mon, Apr 15, 2002 at 07:55:01AM -0400, Tom Neff wrote: > "Billie R. McNamara" wrote: > >We are using version 2.0.8 for a moderated list. But, we aren't able to > >edit messages before approving them (for example, to delete just one > >inappropriate word). > > > >How can we do this? > > There is a FAQ entry that wants you to hand edit various spool files, but > you can patch 2.0.8 to allow message editing. I think the patch will be necessary for mailman 2.1, it unfortunately stores the message on disk in a database format, making hand editing on the mm server not that easy. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From che@debian.org Tue Apr 16 01:01:23 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 16 Apr 2002 09:01:23 +0900 Subject: [Mailman-Developers] two spaces in subject lines In-Reply-To: <87bsclx8j1.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <169BAFF9-50CD-11D6-AE99-0003931E4DBC@debian.org> On Tuesday, April 16, 2002, at 12:53 , Stephen J. Turnbull wrote: > On this list it should end up looking like this: > > Subject: [Mailman-Developers] > =?sjt-1?q?=49=74=27=73=20=6A=75=73=74=20=41=53=43=49=49=21?= > > or so, no? Urk, folded at the whitespace and all.... Ah, I see what you're getting at. Yes, thanks. Another edge case.. Ben From marc_news@vasoftware.com Tue Apr 16 02:34:48 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 15 Apr 2002 18:34:48 -0700 Subject: [Mailman-Developers] message posting in a loop with mailman 2.1b1 Message-ID: <20020416013448.GP25045@merlins.org> I just upgraded one of my servers to exim 4 and mailman choked badly on having exim refuse a message because exim did this: DNS lookup of scruznet.com (MX) gave TRY_AGAIN scruznet.com in dns_again_means_nonexist? no (option unset) returning DNS_AGAIN lookuphost router: defer for champney@scruznet.com message: host lookup did not complete ----------- end verify ------------ accept: condition test deferred SMTP>> 451 Temporary local problem - please try later The problem is that mailman decided that the whole post failed, and started to resend it in a loop. Apr 15 08:13:56 2002 (17389) post to keskydee from jean-luc@maisiere.com, size=3527, 9 failures Apr 15 08:17:54 2002 (17389) post to keskydee from jean-luc@maisiere.com, size=3527, 7 failures Apr 15 08:22:08 2002 (17389) post to keskydee from jean-luc@maisiere.com, size=3527, 8 failures (...) This also caused bounce scores against all the users and angered the membership obviously. I'm not sure how mailman could deal better with that, granted, it can be fixed on the exim side, but the problem is not obvious and the looping post is nasty. Since mailman doesn't know who many receipients it delivered to when it gets an error from the MTA (4xx or 5xx), I recommend that mailman moves the message in a separate queue dir, logs an error (possibly Emailing the list owner in the process) and gives up on the message. Resending it is only going to piss off the users that are getting the message each time mm tries. BTW, on the exim 4 side, I had: accept hosts = +localadds:+relay_from_hosts verify = recipient I solved the problem by adding this at the beginning of my rcpt ACL: accept hosts = 127.0.0.1 Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From ml+mm-dev@riyescott.com Tue Apr 16 04:55:07 2002 From: ml+mm-dev@riyescott.com (ml+mm-dev@riyescott.com) Date: Mon, 15 Apr 2002 20:55:07 -0700 Subject: [Mailman-Developers] Changing web_page_url in mm 2.1 Message-ID: <20020415205507.A26397@cupro.opengvs.com> On 13 Apr 2002 00:32:51 -0700, Marc MERLIN wrote: > I have web_page_url set to the wrong value for a list I just created. > Outside of using config_list, is there any easier way to change the domain > the list is in? I also noticed this wasn't in config_list. After an interesting learning experience, I wrote the script below, which I used with withlist. It would be better if it took the new domain name from the command line. HTH. Invocation to change *all* lists: bin/withlist -l -r urllist.urlfix -a File urllist.py ---------------------------------------------------------------- # List web_page_url # To invoke: bin/withlist [-q] -r urllist -a def urllist(mlist): print 'List: ', mlist.internal_name() print ' web_page_url: ', mlist.web_page_url # Update web_page_url, which doesn't seem to be covered in bin/config_list. # To invoke: bin/withlist [-q] -l -r urllist.urlfix -a def urlfix(mlist): print 'List: ', mlist.internal_name() print ' web_page_url before: ', mlist.web_page_url mlist.web_page_url = "http://newname.com/mailman/" print ' web_page_url after: ', mlist.web_page_url mlist.Save() ---------------------------------------------------------------- -- Dale From hellozappy2k@yahoo.com Wed Apr 10 15:33:45 2002 From: hellozappy2k@yahoo.com (sunny) Date: Wed, 10 Apr 2002 07:33:45 -0700 (PDT) Subject: [Mailman-Developers] Blocking few features for listadmin In-Reply-To: <20020410093716.14374.qmail@web13508.mail.yahoo.com> Message-ID: <20020410143345.55183.qmail@web13504.mail.yahoo.com> I am running mailman ver 2.08 on Solaris 8 with multiple listadmins the problem some listadmin's are changing The list admin's email address and also "Maximum length in Kb of a message body" to 0 which is choking the servers. Can i customize the mailman so that these fileds will not be available for the list admin to change. Regards DK > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From fbaroni@axoadi.it Tue Apr 16 09:18:23 2002 From: fbaroni@axoadi.it (Gian Franco Baroni) Date: Tue, 16 Apr 2002 10:18:23 +0200 Subject: [Mailman-Developers] Stripping binaries attachments Message-ID: Hi, I didn't find a way to filter out binary attachments from the mails sent = to a Mailman server. Anyone has a clue? Thanks GFB From claw@kanga.nu Tue Apr 16 18:28:35 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Apr 2002 10:28:35 -0700 Subject: [Mailman-Developers] Stripping binaries attachments In-Reply-To: Message from "Gian Franco Baroni" of "Tue, 16 Apr 2002 10:18:23 +0200." References: Message-ID: <32153.1018978115@kanga.nu> On Tue, 16 Apr 2002 10:18:23 +0200 Gian Franco Baroni wrote: > I didn't find a way to filter out binary attachments from the > mails sent to a Mailman server. Anyone has a clue? Please see the FAQ: http://www.python.org/cgi-bin/faqw-mm.py -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From dmick@utopia.West.Sun.COM Tue Apr 16 18:31:31 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Tue, 16 Apr 2002 10:31:31 -0700 Subject: [Mailman-Developers] Stripping binaries attachments References: Message-ID: <3CBC5FF3.2D6C39B8@utopia.west.sun.com> Yes, first, ask on mailman-users. Second, see FAQ entry 1.8. http://www.python.org/cgi-bin/faqw-mm.py Gian Franco Baroni wrote: > > Hi, > I didn't find a way to filter out binary attachments from the mails sent to a Mailman server. > Anyone has a clue? > > Thanks > > GFB > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From barry@zope.com Tue Apr 16 19:53:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Apr 2002 14:53:55 -0400 Subject: [Mailman-Developers] Stripping binaries attachments References: Message-ID: <15548.29507.775190.773151@anthem.wooz.org> >>>>> "GFB" == Gian Franco Baroni writes: GFB> Hi, I didn't find a way to filter out binary attachments from GFB> the mails sent to a Mailman server. Anyone has a clue? Mailman 2.1 beta 2 (when it's out :). -BArry From barry@zope.com Tue Apr 16 23:33:59 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Apr 2002 18:33:59 -0400 Subject: [Mailman-Developers] message posting in a loop with mailman 2.1b1 References: <20020416013448.GP25045@merlins.org> Message-ID: <15548.42711.772021.656873@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I just upgraded one of my servers to exim 4 and mailman choked MM> badly on having exim refuse a message because exim did this: SMTP> 451 Temporary local problem - please try later MM> The problem is that mailman decided that the whole post MM> failed, and started to resend it in a loop. If I'm reading RFC 2821 correctly, this is the right thing for Mailman to do. A 451 error code means: "The command was not accepted, and the requested action did not occur. However, the error condition is temporary and the action may be requested again. The sender should return to the beginning of the command sequence (if any)." So it looks to me like we're correct in assuming that none of the recipients of that chunk got the message. If Exim is doing partial deliveries and still returning 451, that doesn't seem right. MM> This also caused bounce scores against all the users and MM> angered the membership obviously. We could debate whether it's right to increment bounce scores to recipients in a 451'd message. Maybe we should soft-bounce them (increment by 1.0 > score > 0). I could see an argument about just ignoring 451 responses w.r.t. the bounce processor. MM> Since mailman doesn't know who many receipients it delivered MM> to when it gets an error from the MTA (4xx or 5xx), I Mailman shouldn't have to know. If it gets a 4xx or 5xx response for a batch of recipients, it has to assume that none of those recipients will get the message. I think this is mandated by the RFC. MM> recommend that mailman moves the message in a separate queue MM> dir, logs an error (possibly Emailing the list owner in the MM> process) and gives up on the message. Resending it is only MM> going to piss off the users that are getting the message each MM> time mm tries. Unless I'm misreading the RFC, you have to blame Exim for this. -Barry From marc_news@vasoftware.com Wed Apr 17 00:28:17 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 16 Apr 2002 16:28:17 -0700 Subject: [Mailman-Developers] message posting in a loop with mailman 2.1b1 In-Reply-To: <15548.42711.772021.656873@anthem.wooz.org> References: <20020416013448.GP25045@merlins.org> <15548.42711.772021.656873@anthem.wooz.org> Message-ID: <20020416232817.GC18961@merlins.org> On Tue, Apr 16, 2002 at 06:33:59PM -0400, Barry A. Warsaw wrote: > SMTP> 451 Temporary local problem - please try later > > MM> The problem is that mailman decided that the whole post > MM> failed, and started to resend it in a loop. > > If I'm reading RFC 2821 correctly, this is the right thing for Mailman > to do. A 451 error code means: I'm not saying that mailman is incorrect on the interpretation of the RFC, I'm saying that if mailman feeds an incorrect Email address or something that causes the MTA to reject the mail, it will endlessly spam all the subscribers that are being delivered to every time mailman tries. This can't be the desired behaviour... What if mailman gets a 5xx? Does it give up on the message and drop it on the floor? My point is that in both cases it should log a clear error of what happened, and save the message that triggered the problem somewhere. But you are right that in theory mailman should know who the message was delivered to, and who didn't get it. > "The command was not accepted, and the requested action did not > occur. However, the error condition is temporary and the action > may be requested again. The sender should return to the beginning > of the command sequence (if any)." > > So it looks to me like we're correct in assuming that none of the > recipients of that chunk got the message. If Exim is doing partial > deliveries and still returning 451, that doesn't seem right. Here's what exim does: 220 mail2.merlins.org ESMTP Exim 4.01 #1 Tue, 16 Apr 2002 16:03:46 -0700 - mm1 helo foo 250 mail2.merlins.org Hello root at moremagic.merlins.org [204.80.101.251] mail from: nobody@merlins.org 250 OK rcpt to: nobody@uu.net 250 Accepted rcpt to: champney@scruznet.com 451 Temporary local problem - please try later Indeed this *shouldn't* have caused mailman to loop, but it sure did. Then I'm afraid the only explanation that comes to mind is that it delivered one block, got a 451 on the next one, and the previous block didn't get marked as delivered, and mailman delivers it again to people who already got it (I know, I got 12 copies in my mailbox before I was able to stop it) Actually I checked closer, and my system is setup to use VERP, so mailman would only have issued one RCPT per message, or blocks of 1 receipient. Ok, so my exim logs show: 2002-04-15 05:43:31 16x5pS-0004XH-00 => keskydee F= R=mm21_main_director T=mm21_transport S=2850 2002-04-15 05:43:34 16x5pW-0004RZ-00 <= keskydee-bounces+jean-luc=maisiere.com@m erlins.org H=localhost (moremagic.merlins.org) [127.0.0.1]:49371 I=[127.0.0.1]:2 5 U=mailman P=esmtp S=1350 id=mailman.9.1018874612.25713.keskydee@lists.merlins. org T="Your message to Keskydee awaits moderator approval" from for jean-luc@maisiere.com (I'm still sleeping, wake up, approve the message, and it starts gettting sent) 2002-04-15 08:06:03 16x83P-0001tW-00 <= keskydee-bounces+sylvie=stanfordalumni.o rg@merlins.org H=localhost (moremagic.merlins.org) [127.0.0.1]:46865 I=[127.0.0. 1]:25 U=mailman P=esmtp S=3893 id=200204151259.OAA09104@serv5.sc3m.net T="[Kesky dee] recherche collaboration" from for sylvie@stanfordalumni.org 2002-04-15 08:06:05 16x83P-0001tW-00 => sylvie@stanfordalumni.org F= R=lookuphost T=remote_smtp S=4009 H =mx.usa.net [165.212.65.113] C="250 Mail accepted (240gDoPFv0045M01)" 2002-04-15 08:06:05 16x83P-0001tW-00 Completed 2002-04-15 08:06:09 H=localhost (moremagic.merlins.org) [127.0.0.1]:46865 (mailm an) F= temporarily rejecte d RCPT : host lookup did not complete Ahah, first 4xx 2002-04-15 08:06:09 SMTP connection from localhost (moremagic.merlins.org) [127. 0.0.1]:46865 closed by QUIT mailman bails right after that. 2002-04-15 08:06:10 SMTP connection from localhost [127.0.0.1]:41158 (TCP/IP con nection count = 1) and comes back delivers some other messages and gets another 4xx 2002-04-15 08:06:29 H=localhost (moremagic.merlins.org) [127.0.0.1]:41158 (mailm an) F= temporarily rejected RCPT : host lookup did not complete 2002-04-15 08:06:29 SMTP connection from localhost (moremagic.merlins.org) [127. 0.0.1]:41158 closed by QUIT 2002-04-15 08:06:29 SMTP connection from localhost [127.0.0.1]:60022 (TCP/IP con nection count = 1) delivers to more people, and then to me 2002-04-15 08:07:56 16x85E-00058R-00 <= keskydee-bounces+marc=merlins.org@merlins.org H=localhost (moremagic.merlins.org) [127.0.0.1]:42096 I=[127.0.0.1]:25 U=mailman P=esmtp S=3866 id=200204151259.OAA09104@serv5.sc3m.net T="[Keskydee] recherche collaboration" from for marcmerlins.org Unfortunately, since there are 200+ members, I can't give you a sweet 10 lines of logs with the obvious problem, but I can show you this: 2002-04-15 08:14:27 16x8BX-0005WU-00 <= keskydee-bounces+marc=merlins.org@merlins.org H=localhost (moremagic.merlins.org) [127.0.0.1]:57729 I=[127.0.0.1]:25 U=mailman P=esmtp S=3866 id=200204151259.OAA09104@serv5.sc3m.net T="[Keskydee] recherche collaboration" from for marcmerlins.org The same message gets sent back to me again, and again every 10-15mn until I manually yanked the message from the spool. I know you'd rather have the line of code that does the bad thing, or even a patch, but I can at least tell you that something is amiss. My first report just wasn't good because I didn't research the failure deeply enough. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From techgrrl@beeze.com Wed Apr 17 00:56:55 2002 From: techgrrl@beeze.com (Sarah K. Miller) Date: Tue, 16 Apr 2002 16:56:55 -0700 Subject: [Mailman-Developers] 2.1b1 "bad character range" error Message-ID: <05cd01c1e5a2$77d4c520$7941a8c0@home.beeze.com> I'm seeing quite a few of these in my 2.1b1 logs. Any idea what might be = causing them? Apr 16 16:00:26 2002 (27714) Uncaught runner exception: bad character = range Apr 16 16:00:26 2002 (27714) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 103, in = __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 153, in = __onefile keepqueued =3D self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 111, = in _dispose status =3D self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 134, = in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/Tagger.py", line 54, in = process cre =3D re.compile(pattern, re.IGNORECASE | re.VERBOSE) File "/usr/local/lib/python2.2/sre.py", line 178, in compile return _compile(pattern, flags) File "/usr/local/lib/python2.2/sre.py", line 228, in _compile raise error, v # invalid expression error: bad character range -- Sarah Plus =E7a change, plus c'est la m=EAme chose From techgrrl@beeze.com Wed Apr 17 01:14:37 2002 From: techgrrl@beeze.com (Sarah K. Miller) Date: Tue, 16 Apr 2002 17:14:37 -0700 Subject: [Mailman-Developers] 2.1b1 AttributeError message Message-ID: <05f401c1e5a4$dd413540$7941a8c0@home.beeze.com> Another recurring error from my log. I can't find anything similar in = the developers or users archives. Any insights? Apr 16 17:06:17 2002 admin(21330): = @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@=20 admin(21330): [----- Mailman Version: 2.1b1 -----]=20 admin(21330): [----- Traceback ------]=20 admin(21330): Traceback (most recent call last): admin(21330): File "/usr/local/mailman/scripts/driver", line 82, in = run_main admin(21330): main() admin(21330): File "/usr/local/mailman/Mailman/Cgi/admindb.py", line = 160, in main admin(21330): process_form(mlist, doc, cgidata) admin(21330): File "/usr/local/mailman/Mailman/Cgi/admindb.py", line = 718, in process_form admin(21330): preserve, forward, forwardaddr) admin(21330): File "/usr/local/mailman/Mailman/ListAdmin.py", line = 175, in HandleRequest admin(21330): forward, addr) admin(21330): File "/usr/local/mailman/Mailman/ListAdmin.py", line = 311, in __handlepost admin(21330): copy, lang) admin(21330): File "/usr/local/mailman/Mailman/Message.py", line 158, = in __init__ admin(21330): self.set_payload(text, charset) admin(21330): File "/usr/local/mailman/pythonlib/email/Message.py", = line 160, in set_payload admin(21330): self.set_charset(charset) admin(21330): File "/usr/local/mailman/pythonlib/email/Message.py", = line 198, in set_charset admin(21330): cte(self) admin(21330): File "/usr/local/mailman/pythonlib/email/Encoders.py", = line 75, in encode_7or8bit admin(21330): orig.encode('ascii') admin(21330): AttributeError: Message instance has no attribute 'encode' -- Sarah Plus =E7a change, plus c'est la m=EAme chose From barry@zope.com Wed Apr 17 05:10:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Apr 2002 00:10:50 -0400 Subject: [Mailman-Developers] message posting in a loop with mailman 2.1b1 References: <20020416013448.GP25045@merlins.org> <15548.42711.772021.656873@anthem.wooz.org> <20020416232817.GC18961@merlins.org> Message-ID: <15548.62922.573770.678554@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I'm not saying that mailman is incorrect on the interpretation MM> of the RFC, I'm saying that if mailman feeds an incorrect MM> Email address or something that causes the MTA to reject the MM> mail, it will endlessly spam all the subscribers that are MM> being delivered to every time mailman tries. Ah, now I understand. MM> This can't be the desired behaviour... What? You mean you don't like mailbombing your innocent list members? That's a marketing gimmick I use on people until they come out to see the band and buy at least 3 CDs! You've discovered my backdoor, so now I guess I have to rip it out. MM> What if mailman gets a 5xx? Does it give up on the message and MM> drop it on the floor? When MM gets a 5xx, it records that chunk's recipients as permfailures. For 4xx's it records them as tempfailures. Once delivery has been attempted to all the chunks, it will then process the two types of failures. For permanent fail recipients, it will periodically lock the affected mailing list and do bounce registration on them. For temporary fail recipients, it will attempt redelivery until 1) it makes no progress (i.e. the number of undelivered recips from the last attempt is the same as the number from this attempt), and 2) until mm_cfg.DELIVERY_RETRY_PERIOD is elapsed. If these conditions are met, it discards the message (this may not be the right thing to do). However, in eyeballing the code to write this response, I think I see the bug! The list of all recipients for this message is kept in the metadata dict, under the key `recips'. When we requeue a message with tempfailures for retry later, I failed to reset the `recips' value to just the list of tempfailed recipients. This would indeed cause the message to be later redelivered to everybody. I believe the fix is simple. Attached below is an untested patch. I'm way too tired to test this tonight, but I'll try to craft a test for this tomorrow to make sure it's correct, and if so I'll commit it for 2.1b2, perhaps also to be releaed tomorrow (I also need to get 2.0.10 out the door). Thanks, this was a real bug. -Barry -------------------- snip snip -------------------- Index: OutgoingRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v retrieving revision 2.14 diff -u -r2.14 OutgoingRunner.py --- OutgoingRunner.py 10 Apr 2002 04:48:01 -0000 2.14 +++ OutgoingRunner.py 17 Apr 2002 04:09:30 -0000 @@ -101,15 +101,16 @@ last_recip_count = msgdata.get('last_recip_count', 0) deliver_until = msgdata.get('deliver_until', now) if len(recips) == last_recip_count: - # We didn't make any progress. + # We didn't make any progress, so don't attempt delivery any + # longer. BAW: is this the best disposition? if now > deliver_until: - # We won't attempt delivery any longer. return 0 else: # Keep trying to delivery this for 3 days deliver_until = now + mm_cfg.DELIVERY_RETRY_PERIOD msgdata['last_recip_count'] = len(recips) msgdata['deliver_until'] = deliver_until + msgdata['recips'] = recips # Requeue return 1 # We've successfully completed handling of this message From fbaroni@axoadi.it Wed Apr 17 09:35:58 2002 From: fbaroni@axoadi.it (Gian Franco Baroni) Date: Wed, 17 Apr 2002 10:35:58 +0200 Subject: [Mailman-Developers] Stripping binaries attachments Message-ID: >>> Dan Mick 16/04/02 19.31.31 >>> >>Yes, first, ask on mailman-users. Sorry, I sent the mail to wrong list... Shame on me :( >>Second, see FAQ entry 1.8. Read, but I'm using 2.1a4 and I'm not sure if all the hints cover that = version. Thanks GFB From jwblist@olympus.net Wed Apr 17 18:44:16 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 17 Apr 2002 10:44:16 -0700 Subject: [Mailman-Developers] message posting in a loop with mailman 2.1b1 In-Reply-To: <20020416232817.GC18961@merlins.org> References: <20020416013448.GP25045@merlins.org> <15548.42711.772021.656873@anthem.wooz.org> <20020416232817.GC18961@merlins.org> Message-ID: At 16:28 -0700 4/16/2002, Marc MERLIN wrote: >I'm not saying that mailman is incorrect on the interpretation of the RFC, >I'm saying that if mailman feeds an incorrect Email address or something >that causes the MTA to reject the mail, it will endlessly spam all the >subscribers that are being delivered to every time mailman tries. > >This can't be the desired behaviour... Nor is it what I see running Mailman with Exim. But I haven't ventured into 2.1b1 yet. How does Mailman deliver the messages to Exim? --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From barry@zope.com Thu Apr 18 05:32:37 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Apr 2002 00:32:37 -0400 Subject: [Mailman-Developers] RELEASED Mailman 2.0.10 Message-ID: <15550.19557.941487.978294@anthem.wooz.org> Hot on the heels of the last release, I'm announcing Mailman 2.0.10 which fixes a few minor problems. See the NEWS file entries below. This is not a critical fix, although it will eliminate a confusing (but harmless) error message, and could provide better support for sites which use the qmail MTA. As usual, I've made both full source tarballs and patches available. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarball. If you decide to install the patches, please do read the release notes first: http://sourceforge.net/project/shownotes.php?release_id=63042 See also: http://www.gnu.org/software/mailman http://www.list.org http://mailman.sf.net Cheers, -Barry 2.0.10 (09-Apr-2002) - Closed another small race condition. - Add the RFC-2822 recommended Message-ID: header on internally generated outgoing messages. Not all MTAs add this field if missing (read: Qmail). From barry@zope.com Thu Apr 18 23:02:30 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Apr 2002 18:02:30 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: Editability of messages References: <20020415033446.29700.82480.Mailman@mail.python.org> <1598000234.1018857301@tom-9k5kaocfpin> <20020415210955.GM25045@merlins.org> Message-ID: <15551.17014.271050.657394@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: >> There is a FAQ entry that wants you to hand edit various spool >> files, but you can patch 2.0.8 to allow message editing. MM> I think the patch will be necessary for mailman 2.1, it MM> unfortunately stores the message on disk in a database format, MM> making hand editing on the mm server not that easy. I've updated the FAQ entry with some useful information for MM2.1. -Barry From techgrrl@beeze.com Thu Apr 18 23:17:50 2002 From: techgrrl@beeze.com (Sarah K. Miller) Date: Thu, 18 Apr 2002 15:17:50 -0700 Subject: Fw: [Mailman-Developers] 2.1b1 "bad character range" error Message-ID: <00d701c1e726$e0a35aa0$7941a8c0@home.beeze.com> I discovered that this error is caused when there is a dash (-) entered = in the Regexp for the topic keywords. Remove the dash, end of error. > ----- Original Message -----=20 > From: "Sarah K. Miller" > To: > Sent: Tuesday, April 16, 2002 4:56 PM > Subject: [Mailman-Developers] 2.1b1 "bad character range" error >=20 >=20 > > I'm seeing quite a few of these in my 2.1b1 logs. Any idea what = might be causing them? > >=20 > > Apr 16 16:00:26 2002 (27714) Uncaught runner exception: bad = character range > > Apr 16 16:00:26 2002 (27714) Traceback (most recent call last): > > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 103, in = __oneloop > > self.__onefile(msg, msgdata) > > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 153, in = __onefile > > keepqueued =3D self._dispose(mlist, msg, msgdata) > > File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line = 111, in _dispose > > status =3D self._dopipeline(mlist, msg, msgdata, pipeline) > > File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line = 134, in _dopipeline > > sys.modules[modname].process(mlist, msg, msgdata) > > File "/usr/local/mailman/Mailman/Handlers/Tagger.py", line 54, in = process > > cre =3D re.compile(pattern, re.IGNORECASE | re.VERBOSE) > > File "/usr/local/lib/python2.2/sre.py", line 178, in compile > > return _compile(pattern, flags) > > File "/usr/local/lib/python2.2/sre.py", line 228, in _compile > > raise error, v # invalid expression > > error: bad character range From barry@zope.com Thu Apr 18 23:28:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Apr 2002 18:28:19 -0400 Subject: [Mailman-Developers] 2.1b1 "bad character range" error References: <05cd01c1e5a2$77d4c520$7941a8c0@home.beeze.com> Message-ID: <15551.18563.989432.503806@anthem.wooz.org> >>>>> "SKM" =3D=3D Sarah K Miller writes: SKM> I'm seeing quite a few of these in my 2.1b1 logs. Any idea SKM> what might be causing them? SKM> error: bad character range Yes, you've got a topic with an illegal regular expression. I've just added some code to cvs that will prevent illegal regexps from making their way into a topic definition. Thanks. | -- Sarah | Plus =E7a change, plus c'est la m=EAme chose Circumstances! :) -Barry From barry@zope.com Thu Apr 18 23:29:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Apr 2002 18:29:45 -0400 Subject: [Mailman-Developers] 2.1b1 AttributeError message References: <05f401c1e5a4$dd413540$7941a8c0@home.beeze.com> Message-ID: <15551.18649.371654.433782@anthem.wooz.org> >>>>> "SKM" == Sarah K Miller writes: SKM> Another recurring error from my log. I can't find anything SKM> similar in the developers or users archives. Any insights? This one's got me stumped. Can you give me some more information? Are there messages in your qfiles/shunt directory? -Barry From jarrell@vt.edu Fri Apr 19 03:45:38 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 18 Apr 2002 22:45:38 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/Mailman/Gui Topics.py,2.4,2.5 In-Reply-To: Message-ID: <5.1.0.14.2.20020418224432.00a70070@lennier.cc.vt.edu> At 03:24 PM 4/18/02 -0700, you wrote: >+ # Make sure the pattern was a legal regular expression >+ try: >+ syslog('error', 'pattern: %s', pattern) >+ re.compile(pattern) >+ except (re.error, TypeError): Hey, Barry, this change to Topics? Did you really want to syslog every possible pattern to the error log, or did you perchance leave a debugging syslog in there again :-) From barry@zope.com Fri Apr 19 04:38:52 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Apr 2002 23:38:52 -0400 Subject: Fw: [Mailman-Developers] 2.1b1 "bad character range" error References: <00d701c1e726$e0a35aa0$7941a8c0@home.beeze.com> Message-ID: <15551.37196.71662.133026@anthem.wooz.org> >>>>> "SKM" == Sarah K Miller writes: SKM> I discovered that this error is caused when there is a dash SKM> (-) entered in the Regexp for the topic keywords. Remove the SKM> dash, end of error. Probably depends on where the dash is. Can you show me the exact regexp you entered? Also, note that Python's regexp syntax is described here: http://www.python.org/doc/current/lib/re-syntax.html -Barry From barry@zope.com Fri Apr 19 04:46:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Apr 2002 23:46:08 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/Mailman/Gui Topics.py,2.4,2.5 References: <5.1.0.14.2.20020418224432.00a70070@lennier.cc.vt.edu> Message-ID: <15551.37632.761866.834555@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Hey, Barry, this change to Topics? Did you really want to RJ> syslog every possible pattern to the error log, or did you RJ> perchance leave a debugging syslog in there again :-) Urp, thanks! I do love open source. :) Gone now. -Barry From Dale@Newfield.org Fri Apr 19 16:51:43 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 19 Apr 2002 11:51:43 -0400 (EDT) Subject: [Mailman-Developers] Buglet (in 2.0, dunno about 2.1) In-Reply-To: <15550.19557.941487.978294@anthem.wooz.org> Message-ID: A list had subscriptions set to require both confirmation and approval. Someone initiates the subscription process through the web interface. I modified the list to only require approval. The person sent back their address confirmation, and Mailman subscribed them (without requiring approval). I don't know if this portion of mailman has been gutted/replaced in the 2.1 development, but if it hasn't, this buglet is likely still there... -Dale From barry@zope.com Fri Apr 19 17:00:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 12:00:27 -0400 Subject: [Mailman-Developers] Buglet (in 2.0, dunno about 2.1) References: <15550.19557.941487.978294@anthem.wooz.org> Message-ID: <15552.16155.632739.40659@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> A list had subscriptions set to require both confirmation and DN> approval. Someone initiates the subscription process through DN> the web interface. I modified the list to only require DN> approval. The person sent back their address confirmation, DN> and Mailman subscribed them (without requiring approval). DN> I don't know if this portion of mailman has been DN> gutted/replaced in the 2.1 development, but if it hasn't, this DN> buglet is likely still there... I doubt this has been changed in MM2.1, but I'm not sure how easy it would be to fix. A subscription request is going to be guided by the policy in place at the time the process is set in motion. Changing that policy in the middle isn't going to affect requests that have already started. -Barry From Dale@Newfield.org Fri Apr 19 17:03:47 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 19 Apr 2002 12:03:47 -0400 (EDT) Subject: [Mailman-Developers] Buglet (in 2.0, dunno about 2.1) In-Reply-To: <15552.16155.632739.40659@anthem.wooz.org> Message-ID: On Fri, 19 Apr 2002, Barry A. Warsaw wrote: > A subscription request is going to be guided by the policy in place at > the time the process is set in motion. Changing that policy in the > middle isn't going to affect requests that have already started. Approval was "required" both when the process started and when it completed, but it skipped asking for it. (Before Confirmation&Approval, then just Approval). -Dale From barry@zope.com Fri Apr 19 18:01:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 13:01:27 -0400 Subject: [Mailman-Developers] Buglet (in 2.0, dunno about 2.1) References: <15552.16155.632739.40659@anthem.wooz.org> Message-ID: <15552.19815.240364.569810@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> On Fri, 19 Apr 2002, Barry A. Warsaw wrote: >> A subscription request is going to be guided by the policy in >> place at the time the process is set in motion. Changing that >> policy in the middle isn't going to affect requests that have >> already started. DN> Approval was "required" both when the process started and when DN> it completed, but it skipped asking for it. (Before DN> Confirmation&Approval, then just Approval). Ah yes, happens for me to. -Barry From barry@zope.com Fri Apr 19 18:08:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 13:08:03 -0400 Subject: [Mailman-Developers] Buglet (in 2.0, dunno about 2.1) References: <15552.16155.632739.40659@anthem.wooz.org> Message-ID: <15552.20211.21450.185100@anthem.wooz.org> Ah if only all bugs were so eaily fixed. Fixed in cvs. -Barry From dmick@utopia.west.sun.com Fri Apr 19 21:21:45 2002 From: dmick@utopia.west.sun.com (Dan Mick) Date: Fri, 19 Apr 2002 13:21:45 -0700 Subject: [Mailman-Developers] Stripping binaries attachments References: Message-ID: <3CC07C59.5F99B16B@utopia.west.sun.com> Gian Franco Baroni wrote: > > >>> Dan Mick 16/04/02 19.31.31 >>> > >>Yes, first, ask on mailman-users. > Sorry, I sent the mail to wrong list... > Shame on me :( Well, probably not, if you're using 2.1a4. I should have asked. > >>Second, see FAQ entry 1.8. > Read, but I'm using 2.1a4 and I'm not sure if all the hints cover that version. Except for 2.1-latest's penchant for saving messages as pickles, rather than plain text. But you can turn that off with a switch inside the module, whose name I forget right at the moment. Barry, given that people seem to often want to edit these messages, is it really a good idea to save them as non-plain-text? From dmick@utopia.west.sun.com Fri Apr 19 21:29:09 2002 From: dmick@utopia.west.sun.com (Dan Mick) Date: Fri, 19 Apr 2002 13:29:09 -0700 Subject: [Mailman-Developers] Stripping binaries attachments References: <3CC07C59.5F99B16B@utopia.west.sun.com> Message-ID: <3CC07E15.F5461B23@utopia.west.sun.com> Dan Mick wrote: > > Gian Franco Baroni wrote: > > > > >>> Dan Mick 16/04/02 19.31.31 >>> > > >>Yes, first, ask on mailman-users. > > Sorry, I sent the mail to wrong list... > > Shame on me :( > > Well, probably not, if you're using 2.1a4. I should have asked. > > > >>Second, see FAQ entry 1.8. > > Read, but I'm using 2.1a4 and I'm not sure if all the hints cover that version. > > Except for 2.1-latest's penchant for saving messages as pickles, rather than plain > text. But you can turn that off with a switch inside the module, whose name > I forget right at the moment. Barry, given that people seem to often want to > edit these messages, is it really a good idea to save them as non-plain-text? Argh. This had nothing to do with Gian Franco's question, but it's still a valid concern. For the question of HTML stripping, I think Mailman 2.1 only provides "archive stripping" by default. I use, and am happy with, demime. From barry@zope.com Fri Apr 19 22:12:06 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 17:12:06 -0400 Subject: [Mailman-Developers] Stripping binaries attachments References: <3CC07C59.5F99B16B@utopia.west.sun.com> Message-ID: <15552.34854.559109.977259@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Except for 2.1-latest's penchant for saving messages as DM> pickles, rather than plain text. But you can turn that off DM> with a switch inside the module, whose name I forget right at DM> the moment. Barry, given that people seem to often want to DM> edit these messages, is it really a good idea to save them as DM> non-plain-text? It may not be. Then again, maybe I should promote the variable up into Defaults.py.in, regardless of the default value. It would be easier to modify through mm_cfg.py than to hack on ListAdmin.py and potentially lose your changes when you upgrade. -Barry From jarrell@vt.edu Fri Apr 19 22:10:23 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 19 Apr 2002 17:10:23 -0400 Subject: [Mailman-Developers] Stripping binaries attachments In-Reply-To: <3CC07C59.5F99B16B@utopia.west.sun.com> References: Message-ID: <5.1.0.14.2.20020419170746.048a5640@lennier.cc.vt.edu> At 01:21 PM 4/19/02 -0700, Dan Mick wrote: >Except for 2.1-latest's penchant for saving messages as pickles, rather than plain >text. But you can turn that off with a switch inside the module, whose name >I forget right at the moment. Barry, given that people seem to often want to >edit these messages, is it really a good idea to save them as non-plain-text? I had the same thought when debugging the topic parser problem - that it'd be nice to be able to pick through the message without having to decode the pickle's wrappings. Although rather than saving them as plaintext, I'd be just as happy with an unpickle/repickle util for when I want to monkey with a message. (if only to let me read it without swearing at it...) From barry@zope.com Fri Apr 19 22:23:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 17:23:11 -0400 Subject: [Mailman-Developers] Stripping binaries attachments References: <3CC07C59.5F99B16B@utopia.west.sun.com> <3CC07E15.F5461B23@utopia.west.sun.com> Message-ID: <15552.35519.455136.400225@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> For the question of HTML stripping, I think Mailman 2.1 only DM> provides "archive stripping" by default. I use, and am happy DM> with, demime. Heh, I guess this was a stealth checkin. MM2.1b2 will support "content filtering", essentially what I think demime does as an add-on. Les Niles supplied the basic code, which I modified. It filters on specified MIME type, optionally converts text/html to text/plain, etc. -Barry From barry@zope.com Fri Apr 19 22:28:30 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 17:28:30 -0400 Subject: [Mailman-Developers] Stripping binaries attachments References: <5.1.0.14.2.20020419170746.048a5640@lennier.cc.vt.edu> Message-ID: <15552.35838.554048.750513@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> I had the same thought when debugging the topic parser problem RJ> - that it'd be nice to be able to pick through the message RJ> without having to decode the pickle's wrappings. RJ> Although rather than saving them as plaintext, I'd be just as RJ> happy with an unpickle/repickle util for when I want to monkey RJ> with a message. (if only to let me read it without swearing RJ> at it...) bin/dumpdb knows how to print out the plaintext representation of a .pck message file, so % bin/dumpdb qfiles/in/...pck > msg.txt ought to do the trick. The other direction is fairly easy if you don't mind not saving the message metadata file (.db). Use bin/inject, possibly with the -q option. -Barry From jarrell@vt.edu Fri Apr 19 22:37:56 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 19 Apr 2002 17:37:56 -0400 Subject: [Mailman-Developers] Stripping binaries attachments In-Reply-To: <15552.35838.554048.750513@anthem.wooz.org> References: <5.1.0.14.2.20020419170746.048a5640@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020419173632.0263e020@lennier.cc.vt.edu> At 05:28 PM 4/19/02 -0400, Barry A. Warsaw wrote: >bin/dumpdb knows how to print out the plaintext representation of a >.pck message file, so > > % bin/dumpdb qfiles/in/...pck > msg.txt > >ought to do the trick. The other direction is fairly easy if you >don't mind not saving the message metadata file (.db). Use >bin/inject, possibly with the -q option. And, you know, I actually knew that at the time, and now that you've mentioned it again, realize I actually did that eventually... Although I hadn't thought about using inject to shove it back in. From barry@zope.com Fri Apr 19 22:52:36 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 17:52:36 -0400 Subject: [Mailman-Developers] Stripping binaries attachments References: <5.1.0.14.2.20020419170746.048a5640@lennier.cc.vt.edu> <5.1.0.14.2.20020419173632.0263e020@lennier.cc.vt.edu> Message-ID: <15552.37284.164092.237133@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> And, you know, I actually knew that at the time, and now that RJ> you've mentioned it again, realize I actually did that RJ> eventually... RJ> Although I hadn't thought about using inject to shove it back RJ> in. I'm getting good at driving Guido's time machine. :) -Barry From marc_news@vasoftware.com Fri Apr 19 22:57:57 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 19 Apr 2002 14:57:57 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: Editability of messages In-Reply-To: <15551.17014.271050.657394@anthem.wooz.org> References: <20020415033446.29700.82480.Mailman@mail.python.org> <1598000234.1018857301@tom-9k5kaocfpin> <20020415210955.GM25045@merlins.org> <15551.17014.271050.657394@anthem.wooz.org> Message-ID: <20020419215756.GC9044@merlins.org> On Thu, Apr 18, 2002 at 06:02:30PM -0400, Barry A. Warsaw wrote: > I've updated the FAQ entry with some useful information for MM2.1. Cool, thanks. BTW, I *very* seldom edit messages that are held for moderation. I think twice it was because I forgot to change my posting address from my private one (the one I shouldn't have posted with in the first place :-D) (yes, I know my scheme is flawed) Once I think I fixed the spelling of someone's name with the poster's approval. It is however good to see that you allowed to disable the mm2.1 behavior by setting HOLD_MESSAGES_AS_PICKLES to 0. Ideally it'd be in Defaults.py so that it doesn't get blown away on upgrade, but that's already a good thing. I think one use for having held message in plaintext (mostly in a corporate environment) would be to edit headers automatically and/or add a disclaimer or some other info in *some* posts (i.e. a P* script would look at that queue twice a minute and process messages if applicable) Out of curiosity, is it really faster to have the whole mesage in a pickle instead of plaintext? Another titbit (sp?) of info: On sf.net, I stat files held for moderation and delete everything that's been there for more than a month. You'd be surprised how many spams held for moderation and never moderated we had before that :-) I'll probably also contribute a small script that watches the number of messages in the mailman queue, and sends a warning if there are more than X (meaning that you have some serious backlog, or some other problem) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Fri Apr 19 23:00:18 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 19 Apr 2002 15:00:18 -0700 Subject: [Mailman-Developers] message posting in a loop with mailman 2.1b1 In-Reply-To: References: <20020416013448.GP25045@merlins.org> <15548.42711.772021.656873@anthem.wooz.org> <20020416232817.GC18961@merlins.org> Message-ID: <20020419220017.GD9044@merlins.org> On Wed, Apr 17, 2002 at 10:44:16AM -0700, John W Baxter wrote: > Nor is it what I see running Mailman with Exim. But I haven't ventured > into 2.1b1 yet. > > How does Mailman deliver the messages to Exim? Err, over port 25. I'm not sure I understand the question you probably meant to ask though :) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Fri Apr 19 23:04:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 18:04:03 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: Editability of messages References: <20020415033446.29700.82480.Mailman@mail.python.org> <1598000234.1018857301@tom-9k5kaocfpin> <20020415210955.GM25045@merlins.org> <15551.17014.271050.657394@anthem.wooz.org> <20020419215756.GC9044@merlins.org> Message-ID: <15552.37971.201825.842594@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Ideally it'd be in Defaults.py so that it doesn't get blown MM> away on upgrade, but that's already a good thing. See my recent checkin. :) MM> Out of curiosity, is it really faster to have the whole mesage MM> in a pickle instead of plaintext? I actually don't remember if I timed it or not, but I suspect it has to be faster to do a binary unpickle than to re-parse and re-generate for each queue move. It probably matters little for held messages. MM> Another titbit (sp?) of info: On sf.net, I stat files held for MM> moderation and delete everything that's been there for more MM> than a month. You'd be surprised how many spams held for MM> moderation and never moderated we had before that :-) Now that would be a cool script to add, although with SpamAssassin, we've been able to /vastly/ reduce the amount of spam coming through python.org. The right tool for the job, etc... MM> I'll probably also contribute a small script that watches the MM> number of messages in the mailman queue, and sends a warning MM> if there are more than X (meaning that you have some serious MM> backlog, or some other problem) Which reminds me, how's your performance been with Exim4? We're seeing a lot of weird stuff happen that wasn't happening with Exim3, specifically, we seem to exhaust our open file limit about every 3rd or 4th day. It's so bad that Mailman will throw a traceback indicating it couldn't import a module (which is presumably because Python couldn't open the module file to read from). I've seen this wedge Mailman and I've also seen Mailman recover, and I haven't been able to totally correlate this with peak traffic. It's disturbing and we'll have to do something about it, although hopefully not as drastic as reverting to Exim3. I'm just wondering if any other Exim4 users are seeing similar problems. -Barry From techgrrl@beeze.com Fri Apr 19 23:08:23 2002 From: techgrrl@beeze.com (Sarah K. Miller) Date: Fri, 19 Apr 2002 15:08:23 -0700 Subject: [Mailman-Developers] 2.1b1 AttributeError message References: <05f401c1e5a4$dd413540$7941a8c0@home.beeze.com> <15551.18649.371654.433782@anthem.wooz.org> Message-ID: <00f701c1e7ee$b91469c0$7941a8c0@home.beeze.com> ----- Original Message -----=20 From: "Barry A. Warsaw" > >>>>> "SKM" =3D=3D Sarah K Miller writes: > admin(21330): AttributeError: Message instance has no attribute = 'encode' > SKM> Another recurring error from my log. I can't find anything > SKM> similar in the developers or users archives. Any insights? >=20 > This one's got me stumped. Can you give me some more information? > Are there messages in your qfiles/shunt directory? I waded through the shunt file. Everything in there was related to bad = expressions in topics, which was resolved. There was nothing in there = that coincided with any of the AttributeError ...'encode' messages. On = the other hand, I haven't seen another one since the topics were cleaned = up. Maybe the two were related somehow ... -- Sarah Plus =E7a change, plus c'est la m=EAme chose From techgrrl@beeze.com Fri Apr 19 23:29:25 2002 From: techgrrl@beeze.com (Sarah K. Miller) Date: Fri, 19 Apr 2002 15:29:25 -0700 Subject: [Mailman-Developers] 2.1b1 AttributeError message References: <05f401c1e5a4$dd413540$7941a8c0@home.beeze.com> <15551.18649.371654.433782@anthem.wooz.org> <00f701c1e7ee$b91469c0$7941a8c0@home.beeze.com> Message-ID: <011d01c1e7f1$a91ab940$7941a8c0@home.beeze.com> > > admin(21330): AttributeError: Message instance has no attribute = 'encode' > > SKM> Another recurring error from my log. I can't find anything > > SKM> similar in the developers or users archives. Any insights? > >=20 > > This one's got me stumped. Can you give me some more information? > > Are there messages in your qfiles/shunt directory? No sooner did I send that message about not being able to find the = error, then I crashed headlong into it. It occurs from the admindb pages = when you attempt to Defer/Accept/Reject/Discard a message AND "Forward = messages (individually) to" any address. -- Sarah From barry@zope.com Fri Apr 19 23:40:21 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Apr 2002 18:40:21 -0400 Subject: [Mailman-Developers] 2.1b1 AttributeError message References: <05f401c1e5a4$dd413540$7941a8c0@home.beeze.com> <15551.18649.371654.433782@anthem.wooz.org> <00f701c1e7ee$b91469c0$7941a8c0@home.beeze.com> <011d01c1e7f1$a91ab940$7941a8c0@home.beeze.com> Message-ID: <15552.40149.949551.847492@anthem.wooz.org> >>>>> "SKM" == Sarah K Miller writes: SKM> No sooner did I send that message about not being able to SKM> find the error, then I crashed headlong into it. It occurs SKM> from the admindb pages when you attempt to SKM> Defer/Accept/Reject/Discard a message AND "Forward messages SKM> (individually) to" any address. This sounds like a bug I think I fixed in cvs, which will be part of MM2.1b2. Are you using b1? Can you upgrade to the current cvs version? If not, wait for MM2.1b2 and see if that fixes your problem. -Barry From Dan Mick Fri Apr 19 23:55:28 2002 From: Dan Mick (Dan Mick) Date: Fri, 19 Apr 2002 15:55:28 -0700 (PDT) Subject: [Mailman-Developers] Stripping binaries attachments Message-ID: <200204192255.g3JMtlbH018662@utopia.West.Sun.COM> > At 05:28 PM 4/19/02 -0400, Barry A. Warsaw wrote: > >bin/dumpdb knows how to print out the plaintext representation of a > >.pck message file, so > > > > % bin/dumpdb qfiles/in/...pck > msg.txt > > > >ought to do the trick. The other direction is fairly easy if you > >don't mind not saving the message metadata file (.db). Use > >bin/inject, possibly with the -q option. > > And, you know, I actually knew that at the time, and now that you've > mentioned it again, realize I actually did that eventually... > > Although I hadn't thought about using inject to shove it back in. Inject has given me problems, unless I go and remove some magic header manually (well, with sed); IIRC, it was X-BeenThere. Here are a couple of scripts I find useful for manually investigating bad or shunt messages: Create symlinks to all the shunted messages' .pck and .db files, in ~mailman, for investigation with debugshunt.py $ cat ~/bin/linkshunt #!/bin/ksh i=0 for f in $(ls qfiles/shunt/*pck); do ip=$(printf %03s $i) base=$(basename $f .pck) ln -s qfiles/shunt/${base}.pck shunt${ip}.pck ln -s qfiles/shunt/${base}.db shunt${ip}.db ((i=i+1)) done Set up some gunge to poke around shunted messages by hand (particularly when they won't parse, so dumpdb is no help). Create a msg object from argv[1], and have a pp function around for pretty-printing various things as you poke, then start an interactive console: $ cat debugshunt.py #!/usr/local/bin/python import sys sys.path.insert(0, './bin') import paths import cPickle import pprint import code f=open(sys.argv[1]) msg=cPickle.load(f) pp=pprint.PrettyPrinter().pprint try: import readline except ImportError: pass namespace = globals().copy() namespace.update(locals()) code.InteractiveConsole(namespace).interact("got console?") From Dan Mick Sat Apr 20 00:16:23 2002 From: Dan Mick (Dan Mick) Date: Fri, 19 Apr 2002 16:16:23 -0700 (PDT) Subject: [Mailman-Developers] Stripping binaries attachments Message-ID: <200204192316.g3JNGfbH019836@utopia.West.Sun.COM> > >>>>> "DM" == Dan Mick writes: > > DM> For the question of HTML stripping, I think Mailman 2.1 only > DM> provides "archive stripping" by default. I use, and am happy > DM> with, demime. > > Heh, I guess this was a stealth checkin. MM2.1b2 will support > "content filtering", essentially what I think demime does as an > add-on. Les Niles supplied the basic code, which I modified. It > filters on specified MIME type, optionally converts text/html to > text/plain, etc. I thought I remembered this, but a casual glance didn't find the code. Now I see it, in MimeDel.py. And now I must try it. If only I could find a list of every possible MIME type except 'text'.... :) (I'll probably want to hack up another field there, that is "Pass sections that have MIME types matching this...", for bastards like me who want *nothing but text*, thank you...) From jwblist@olympus.net Sat Apr 20 00:44:58 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 19 Apr 2002 16:44:58 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: Editability of messages In-Reply-To: <15552.37971.201825.842594@anthem.wooz.org> References: <20020415033446.29700.82480.Mailman@mail.python.org> <1598000234.1018857301@tom-9k5kaocfpin> <20020415210955.GM25045@merlins.org> <15551.17014.271050.657394@anthem.wooz.org> <20020419215756.GC9044@merlins.org> <15552.37971.201825.842594@anthem.wooz.org> Message-ID: At 18:04 -0400 4/19/2002, Barry A. Warsaw wrote: >... >specifically, we seem to exhaust our open file limit about every 3rd >or 4th day. >... >It's disturbing and >we'll have to do something about it, although hopefully not as drastic >as reverting to Exim3. I'm just wondering if any other Exim4 users >are seeing similar problems. We haven't moved to either Mailman 2.1 or Exim 4 (on the Mailman machine) yet. But...we are seeing a Python-based web dynamic page server (not Zope...in-house) leaving open files behind with a fairly new Python. We've temporized by having a monitor which does a suitable lsof and counts the relevant open files...killing and restarting that server when the count reaches 1000. I'll pass along to the (really sharp) guy who is working on that problem that you're seeing something at least vaguely similar. We've been operating on the theory that the problem is in our code, but...perhaps not? --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jarrell@vt.edu Sat Apr 20 04:10:43 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 19 Apr 2002 23:10:43 -0400 Subject: [Mailman-Developers] 2.1b1 AttributeError message In-Reply-To: <15552.40149.949551.847492@anthem.wooz.org> References: <05f401c1e5a4$dd413540$7941a8c0@home.beeze.com> <15551.18649.371654.433782@anthem.wooz.org> <00f701c1e7ee$b91469c0$7941a8c0@home.beeze.com> <011d01c1e7f1$a91ab940$7941a8c0@home.beeze.com> Message-ID: <5.1.0.14.2.20020419230823.00a65aa0@lennier.cc.vt.edu> At 06:40 PM 4/19/02 -0400, Barry A. Warsaw wrote: > >>>>> "SKM" == Sarah K Miller writes: > > SKM> No sooner did I send that message about not being able to > SKM> find the error, then I crashed headlong into it. It occurs > SKM> from the admindb pages when you attempt to > SKM> Defer/Accept/Reject/Discard a message AND "Forward messages > SKM> (individually) to" any address. > >This sounds like a bug I think I fixed in cvs, which will be part of >MM2.1b2. Are you using b1? Can you upgrade to the current cvs >version? If not, wait for MM2.1b2 and see if that fixes your problem. That's exactly the scenario I had, and yea, you patched it in cvs... Probably worth pointing out to those in the peanut gallery that haven't been here long that it's wonderful if you test the beta, but ideally you need to commit to testing the beta *and* regularly syncing it to cvs, cause a *lot* of crap gets fixed quickly after a beta comes out; there's some significant differences now between b1, and cvs-current... I end up rebuilding mailman sometimes daily. From claw@kanga.nu Sat Apr 20 06:34:29 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 19 Apr 2002 22:34:29 -0700 Subject: [Mailman-Developers] Stripping binaries attachments In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 19 Apr 2002 17:12:06 EDT." <15552.34854.559109.977259@anthem.wooz.org> References: <3CC07C59.5F99B16B@utopia.west.sun.com> <15552.34854.559109.977259@anthem.wooz.org> Message-ID: <5346.1019280869@kanga.nu> On Fri, 19 Apr 2002 17:12:06 -0400 Barry A Warsaw wrote: >>>>>> "DM" == Dan Mick writes: DM> Except for 2.1-latest's penchant for saving messages as pickles, DM> rather than plain text. But you can turn that off with a switch DM> inside the module, whose name I forget right at the moment. Barry, DM> given that people seem to often want to edit these messages, is it DM> really a good idea to save them as non-plain-text? > It may not be. Then again, maybe I should promote the variable up > into Defaults.py.in, regardless of the default value. It would be > easier to modify through mm_cfg.py than to hack on ListAdmin.py and > potentially lose your changes when you upgrade. Please! Please, please please, please Please PLEASE! Please sir, may I have another configuration option? <> -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From marc_news@vasoftware.com Sat Apr 20 18:07:57 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 20 Apr 2002 10:07:57 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Re: Editability of messages In-Reply-To: <15552.37971.201825.842594@anthem.wooz.org> References: <20020415033446.29700.82480.Mailman@mail.python.org> <1598000234.1018857301@tom-9k5kaocfpin> <20020415210955.GM25045@merlins.org> <15551.17014.271050.657394@anthem.wooz.org> <20020419215756.GC9044@merlins.org> <15552.37971.201825.842594@anthem.wooz.org> Message-ID: <20020420170755.GB15387@merlins.org> On Fri, Apr 19, 2002 at 06:04:03PM -0400, Barry A. Warsaw wrote: > MM> I'll probably also contribute a small script that watches the > MM> number of messages in the mailman queue, and sends a warning > MM> if there are more than X (meaning that you have some serious > MM> backlog, or some other problem) > > Which reminds me, how's your performance been with Exim4? We're > seeing a lot of weird stuff happen that wasn't happening with Exim3, > specifically, we seem to exhaust our open file limit about every 3rd > or 4th day. It's so bad that Mailman will throw a traceback > indicating it couldn't import a module (which is presumably because > Python couldn't open the module file to read from). I've seen this I haven't yet switched any of my major sites to exim 4 because I had a rather hacked up exim 3 (improved error messages and logs to deal with all the crap and misconfigured servers out there), and this came in too late for Philip to put it in exim 3, so I have to redo it for exim 4 and haven't had the time to, yet. See the two diffs here if you're curious: ftp://ftp.vasoftware.com/pub/people/merlin/exim-3.31-woody-99.1/ Being on the exim list (also I sometimes have to scan it due to the traffic), I don't remember reading anything like this. I did experience problems with exim eating all the filehandles on some linux servers (exim 3), but that was due to a bug with the solar designer secure linux kernel patch for linux 2.2.x If you're not running that buggy linux kernel (which was in linux mandrake), I don't know why you're having this problem. This should probably be asked on the exim list (exim-users@exim.org) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From spertus@mills.edu Sat Apr 20 18:21:53 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sat, 20 Apr 2002 10:21:53 -0700 Subject: [Mailman-Developers] I/O error in Runner.py when archiving under 2.1a3 Message-ID: <5.1.0.14.0.20020420102114.02ee0f88@ella.mills.edu> A mailing list of mine works except for archiving. Whenever a message is processed, the following error shows up in Mailman's error log: Apr 17 09:29:47 2002 (1253) Uncaught runner exception: [Errno 5] Input/output error Apr 17 09:29:47 2002 (1253) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/ArchRunner.py", line 70, in _dispose mlist.ArchiveMail(msg) File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 187, in ArchiveMail traceback.print_exc() File "/usr/local/lib/python2.2/traceback.py", line 210, in print_exc print_exception(etype, value, tb, limit, file) File "/usr/local/lib/python2.2/traceback.py", line 122, in print_exception _print(file, 'Traceback (most recent call last):') File "/usr/local/lib/python2.2/traceback.py", line 13, in _print file.write(str+terminator) IOError: [Errno 5] Input/output error I am using 2.1a3 on Redhat. As far as I can tell, the permissions under /usr/local/mailman/archives/private are correct. Root and mailman have r/w access to everything. When I manually run "./arch sys /usr/local/mailman/archives/private/sys.mbox/sys.mbox" as either root or mailman, the archives are correctly generated. Any suggestions? Thank you. Ellen From jon@csh.rit.edu Sat Apr 20 21:12:19 2002 From: jon@csh.rit.edu (Jon Parise) Date: Sat, 20 Apr 2002 16:12:19 -0400 Subject: [Mailman-Developers] Request mail time zone Message-ID: <20020420201219.GC26493@csh.rit.edu> Is there a reason why the timezone for request messages is always +0000? It seems reasonable to honor the time zone of machine. -- Jon Parise (jon@csh.rit.edu) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member From spertus@mills.edu Sat Apr 20 21:22:31 2002 From: spertus@mills.edu (Ellen Spertus) Date: Sat, 20 Apr 2002 13:22:31 -0700 (PDT) Subject: [Mailman-Developers] I/O error in Runner.py when archiving under 2.1a3 In-Reply-To: <5.1.0.14.0.20020420102114.02ee0f88@ella.mills.edu> Message-ID: Actually, the problem went away when I restarted Mailman. Unless it comes back, never mind. On Sat, 20 Apr 2002, Ellen Spertus wrote: > A mailing list of mine works except for archiving. > > Whenever a message is processed, the following error shows up in Mailman's > error log: > > Apr 17 09:29:47 2002 (1253) Uncaught runner exception: [Errno 5] > Input/output error > Apr 17 09:29:47 2002 (1253) Traceback (most recent call last): > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop > self.__onefile(msg, msgdata) > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 152, in __onefile > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/local/mailman/Mailman/Queue/ArchRunner.py", line 70, in _dispose > mlist.ArchiveMail(msg) > File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 187, in > ArchiveMail > traceback.print_exc() > File "/usr/local/lib/python2.2/traceback.py", line 210, in print_exc > print_exception(etype, value, tb, limit, file) > File "/usr/local/lib/python2.2/traceback.py", line 122, in print_exception > _print(file, 'Traceback (most recent call last):') > File "/usr/local/lib/python2.2/traceback.py", line 13, in _print > file.write(str+terminator) > IOError: [Errno 5] Input/output error > > I am using 2.1a3 on Redhat. > > As far as I can tell, the permissions under > /usr/local/mailman/archives/private are correct. Root and mailman have r/w > access to everything. > > When I manually run "./arch sys > /usr/local/mailman/archives/private/sys.mbox/sys.mbox" as either root or > mailman, the archives are correctly generated. > > Any suggestions? > > Thank you. > > Ellen > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From jarrell@vt.edu Sun Apr 21 05:56:07 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sun, 21 Apr 2002 00:56:07 -0400 Subject: [Mailman-Developers] messed up headers Message-ID: <5.1.0.14.2.20020421005340.00a6e010@mail.vt.edu> Ok, the second occurence of this just happened. Mailman stuffed the entire header into the body of the message, and the message started with a glob of text that looked like: <3CC18918.AFF46174@pointecom.net><007f01c1e889$52607020$d9ea79a5@VirginiaGrafton> <012b01c1e88c$6bd6f6c0$8900a8c0@carolina.rr.com> Now, those look like message ids that were probably on the list before (at least, they're all from systems that would have posted to that list.) Does outlook express have a habit of doing a news-like "References" style header, like an in-reply-to or something, that collects messageid after message id? Because both times this happened, the message started with a blob of message ids. I wonder if the parser is blowing up on too many continuation headers? From marc_news@vasoftware.com Sun Apr 21 17:50:02 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 21 Apr 2002 09:50:02 -0700 Subject: [Mailman-Developers] Re: CVS branches? In-Reply-To: References: <20020421001450.GH9494@merlins.org> Message-ID: <20020421165001.GN24880@merlins.org> [moved to mailman-developers] On Sat, Apr 20, 2002 at 05:52:30PM -0700, Ellen Spertus wrote: > I could use some advice here. I took a snapshot because I'm making a lot > of my own changes to the code, i.e., adding dynamic sublists. My Yeah, I know about that problem :-) > short-term goal is to do a user test real soon. My long term goal is for > the changes to be incorporated into Mailman. Barry and I had a discussion by mail about this recently. Basically he has his day job, his real life [tm] and he pretty much maintains mailman by himself, which in other words means he sometimes/often has limited bandwidth. On one side, reviewing other people's code for correctness, and to check whether they really merge right with his grand scheme of things wrt where the code is going to go, takes time. On the other side, he's trying hard to get mm 2.1 out, which obviously should be a higher priority than adding code at this time. Either way, some people will get a bit disappointed, you can't fully win :-) Once 2.1 gets out, we can all release our own patches against it, but I'm hoping it's not going to be like the linux kernel where people now have to deal with applying multiple patches from outside the main distro, possibly with conflicts, or with bugs that they may report as bugs in mailman when the bug is really a bug with the patch Ideally patches that would be of interest to many would go in the main distribution, but I don't think that much more new code is going to hit mailman before the 2.2 cvs branch opens. I've however asked Barry if he would consider code that is reasonably confined (either in the code, or because it can be globally enabled/disabled in Defaults.py). To be fair my mail was much longer than that and probably requires some heavier thinking, making a policy decision, and setting a precedent, so he's still thinking about it :-) My guess is that really specific code that wouldn't get used by many people should probably remain as patches, which won't be as big a problem since less people will have to apply that code, and you're also lesss likely to have to apply two patches like that and work out the conflicts. What makes a patch fit for inclusion in mainstream, or too specific, that's left for the maintainer to decide :-) > It seems my choices are: > - working from a snapshot (what I've been doing) > - getting my own CVS branch I've been working from CVS and moving my patches from time to time, even though it's time consuming, because many bugs got fixed in CVS > Would you be willing to create a CVS branch for me (call it "mills") that > I can write my changes to, merging in fixes from the main branch? (I am > NOT asking for write permission to the main branch.) Or perhaps you could > suggest a better mechanism. That's a call for Barry to make, I'm just a user and contributer, but I have no CVS access (well, none that I'm supposed to have at least :-D) I don't know how much branches help if they diverge, but if it's a temoparary branch that merges eventually, that could work. Again, Barry's call, and remember that most of his energy is into getting mm 2.1 out :-) Cheers, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From R.Barrett@ftel.co.uk Mon Apr 22 17:30:14 2002 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Mon, 22 Apr 2002 17:30:14 +0100 Subject: [Mailman-Developers] Is MM cookie auth 'secure' thru HTTP proxy servers? Message-ID: <5.1.0.14.2.20020422164315.03f4cbe0@pop.ftel.co.uk> Can someone out there sanity check my thinking on a possible hole in Mailman's cookie based authentication. The scenario I'm concerned with is when Mailman's web GUI is being accessed by a browser via a caching HTTP proxy server such as Squid, hardly an uncommon situation these days. If my understanding is correct, then Squid (legitimately and like probably any other HTTP proxy) has no qualms about caching a page merely because of the existence of Cookies or Set-Cookie headers in the response or request. This is justified by RFC 2616. The Squid FAQ says: The presence of Cookies headers in requests does not affect whether or not an HTTP reply can be cached. Similarly, the presence of Set-Cookie headers in replies does not affect whether the reply can be cached. It appears to me that in the absence of a Cache-Control header with a value of private, no-cache or no-store a caching proxy server is free to cache the response to an HTTP request purportedly protected by MM's cookie based authentication AND to again serve that response to any other requesting client WITHOUT consulting the server delivering the Mailman web GUI. I am hoping one of you kind readers will tell me I have missed the obvious in my examination of the problem and the MM source, or that the scenario above is invalid for any reason. In the meantime I'm working up a patch to block this possible security hole by adding Cache-Control headers in the HHTP responses generated by MM's web GUI. From wheakory@isu.edu Mon Apr 22 17:55:14 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Mon, 22 Apr 2002 10:55:14 -0600 Subject: [Mailman-Developers] Web_page_url change Message-ID: <3CC44058.79A2563D@isu.edu> We are going to be changing the name of our Host Name on our Red Hat Linux box that Mailman 2.0.8 is running on. I would like to change all the lists and configuration for mailman over to this new Host Name. I don't want to setup a CNAME in DNS to keep the old Host Name accessible. What steps are involved in accomplishing this task. I know you use the "withlist" with the command below. python -i bin/withlist -l mylist >>>m.web_page_url 'http://newname.com' >>>m.Save() >>>^D -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From jarrell@vt.edu Mon Apr 22 18:46:18 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 22 Apr 2002 13:46:18 -0400 Subject: [Mailman-Developers] I/O error in Runner.py when archiving under 2.1a3 In-Reply-To: References: <5.1.0.14.0.20020420102114.02ee0f88@ella.mills.edu> Message-ID: <5.1.0.14.2.20020422134513.04185da0@lennier.cc.vt.edu> At 01:22 PM 4/20/02 -0700, Ellen Spertus wrote: >Actually, the problem went away when I restarted Mailman. Unless it comes >back, never mind. Did you happen to make any code change, like drop in a new cvs build, or patch something? With 2.1, after you do that, you really need to do a "mailmanctl restart", so that the queue runners start actually running the new code. In fact, unless you have a dead slow set of lists, you really ought to "mailmanctl stop" the queues, do the install, then start them again. From jarrell@vt.edu Mon Apr 22 18:50:17 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 22 Apr 2002 13:50:17 -0400 Subject: [Mailman-Developers] Web_page_url change In-Reply-To: <3CC44058.79A2563D@isu.edu> Message-ID: <5.1.0.14.2.20020422134848.059f56e0@lennier.cc.vt.edu> At 10:55 AM 4/22/02 -0600, you wrote: >We are going to be changing the name of our Host Name on our Red Hat >Linux box that Mailman 2.0.8 is running on. I would like to change all >the lists and configuration for mailman over to this new Host Name. I >don't want to setup a CNAME in DNS to keep the old Host Name accessible. > >What steps are involved in accomplishing this task. I know you use the >"withlist" with the command below. > >python -i bin/withlist -l mylist >>>>m.web_page_url 'http://newname.com' >>>>m.Save() >>>> If they're all changing to the defaults, then after changing the host on the system, rerun configure and install again, so that Defaults.py picks up the new DEFAULT_URL_PATTERN and DEFAULT_URL_HOST and such. Then just use fix_url.py in the bin directory. (Which essentially does what you're doing above, but computes everything for you). And if it applies to all lists, you can save time by using the -a option to iterate through all lists.. From h.huelsebusch@nwn.de Tue Apr 23 09:26:11 2002 From: h.huelsebusch@nwn.de (Henning =?iso-8859-1?q?H=FClsebusch?=) Date: Tue, 23 Apr 2002 10:26:11 +0200 Subject: [Mailman-Developers] MailMan-Traffic Message-ID: <200204230826.g3N8QB510772@router.intern.huelsebusch.net> Hi ! Is it possible that you insert Traffic-Accounting in Mailman ? Don't know, but I think it's not so difficult, Mailman has to do something like "(MailSize) * (actually members of the list)", stored in a PLAIN-textfile, so it will also be possible to parse the total traffic, monthly oder daily traffic. So it will be possible, that the MailMan-big-boss-guru can have a look on Mailman-Traffic.... later on it could also be Moderator-Role. Is it possible to insert something like this ? Henning From R.Barrett@ftel.co.uk Tue Apr 23 11:03:19 2002 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Tue, 23 Apr 2002 11:03:19 +0100 Subject: [Mailman-Developers] Re: Is MM cookie auth 'secure' thru HTTP proxy servers? Message-ID: <5.1.0.14.2.20020423103409.03e00c38@pop.ftel.co.uk> Further to what I said before (see below), I now enclose a patch to correct the problem. The patch is to the WebAuthenticate function in Mailman.SecurityManager. It adopts the simple hypothesis that if you are setting or checking a cookie then the response about to be made shouldn't be cached. >Date: Mon, 22 Apr 2002 17:30:14 +0100 >To: mailman-developers@python.org >From: Richard Barrett >Subject: Is MM cookie auth 'secure' thru HTTP proxy servers? > >Can someone out there sanity check my thinking on a possible hole in >Mailman's cookie based authentication. > >The scenario I'm concerned with is when Mailman's web GUI is being >accessed by a browser via a caching HTTP proxy server such as Squid, >hardly an uncommon situation these days. > >If my understanding is correct, then Squid (legitimately and like probably >any other HTTP proxy) has no qualms about caching a page merely because of >the existence of Cookies or Set-Cookie headers in the response or request. >This is justified by RFC 2616. The Squid FAQ says: > > >The presence of Cookies headers in requests does not affect whether or not >an HTTP reply can be cached. Similarly, the presence of Set-Cookie headers >in replies does not affect whether the reply can be cached. > > >It appears to me that in the absence of a Cache-Control header with a >value of private, no-cache or no-store a caching proxy server is free to >cache the response to an HTTP request purportedly protected by MM's cookie >based authentication AND to again serve that response to any other >requesting client WITHOUT consulting the server delivering the Mailman web GUI. > >I am hoping one of you kind readers will tell me I have missed the obvious >in my examination of the problem and the MM source, or that the scenario >above is invalid for any reason. > >In the meantime I'm working up a patch to block this possible security >hole by adding Cache-Control headers in the HHTP responses generated by >MM's web GUI. patch file: cut here -------------------------------------------------------------------------- --- mailman-2.0.10/Mailman/SecurityManager.py Tue Nov 6 04:25:26 2001 +++ mailman-2.0.10-cache/Mailman/SecurityManager.py Tue Apr 23 09:44:22 2002 @@ -31,7 +31,7 @@ from Mailman import Cookie from Mailman import mm_cfg - +nocache = "Cache-Control: private" class SecurityManager: def InitVars(self, crypted_password): @@ -66,10 +66,14 @@ self.ConfirmUserPassword(user, password) else: self.ConfirmAdminPassword(password) + print nocache print self.MakeCookie(key) return 1 else: - return self.CheckCookie(key) + res = self.CheckCookie(key) + if res: + print nocache + return res def MakeCookie(self, key): # Ingredients for our cookie: our `secret' which is the list's admin cut here -------------------------------------------------------------------------- From chk@pobox.com Tue Apr 23 17:52:54 2002 From: chk@pobox.com (Harald Koch) Date: Tue, 23 Apr 2002 12:52:54 -0400 Subject: [Mailman-Developers] 2.1b1: web-based create and DEFAULT_EMAIL_HOST? Message-ID: <2312.1019580774@elisabeth.cfrq.net> I just created a new list via the web interface, and the 'host_name' parameter for the list was "www.cfrq.net" (the value of DEFAULT_URL_HOST) instead of "cfrq.net" (the value of DEFAULT_EMAIL_HOST). This surprised me... Mailman/Cgi/create.py uses the VIRTUAL_HOSTS stuff to get the correct value for host_name, but I don't have any VIRTUAL_HOSTS defined (other than the default, which should correctly map DEFAULT_URL_HOST to DEFAULT_EMAIL_HOST). Any suggestions as to where to look would be appreciated... -- Harald Koch From chuqui@plaidworks.com Tue Apr 23 18:07:31 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 23 Apr 2002 10:07:31 -0700 Subject: [Mailman-Developers] New emerging virus/worm. Grr. Message-ID: Passing this along, because this has implications to list owners. A new emerging worm is out there in windows land. That's bad enough, but this one has the hack that instead of repropogating via email using the owners email address, it repropogates using a random address in the infected machine's address book as the From, while sending to other random addresses in the book. Last night, I started getting email from a friend (who happens to be a top computer security guy in the country) from an address he hasn't used in three years, and he doesn't use windows. Other people started getting email from ME that was infected. This morning, the complaints started coming in that my mailman system was sending out infected emails, or that it was sending people admin messages because some infected machine was sending TO my mailman system as someone else, so they were getting the return notice. Here's what I'm currently sending out to people that complain about these bogus mailman messages.... --- Someone out there has both your address and our address in their address book, and is infected with this virus: One of the side effects is that when it tries to reinfect, it takes an address from the address book at random, and uses it as the "from" in sending to someone else. So there's some third party that's hijacked your email address and using it to forward infected messages. And there's not a thing either of us can do about it, because neither of us are infected (or at least, we aren't) or control the machine doing it. This is an emerging worm, and it looks pretty ugly. It has hit Hong Kong and Great Britain worst so far, but it's spreading rapidly accordind to people I've talked to. --- This one has the possibility to get really ugly and nasty, folks, because it's hijacking addresses. Users can't depend on being yelled at by friends for being infected, because this new worm hides behind random return addresses. Which means the only thing you know is that the "person" sending you the email isn't the one infected, but someone who knows both of you is... At least, as far as I can tell so far. The experts still seem to be trying to get a handle on it... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From terri@zone12.com Tue Apr 23 18:25:53 2002 From: terri@zone12.com (Terri Oda) Date: Tue, 23 Apr 2002 13:25:53 -0400 Subject: [Mailman-Developers] New emerging virus/worm. Grr. In-Reply-To: Message-ID: <5.1.0.14.0.20020423131708.00a8fcb0@pop.ncf.carleton.ca> At 10:07 AM 23/04/02 -0700, Chuq Von Rospach wrote: >This is an emerging worm, and it looks pretty ugly. It has hit Hong Kong and >Great Britain worst so far, but it's spreading rapidly accordind to people >I've talked to. I have to say, I've seen it already quite a bit on some of the linuxchix mailing lists. Mostly it's getting caught by our "posters-only" rules, but we're also getting sent "You have a virus" auto-messages to the lists, the admins, and probably random posters as well. I haven't seen any make it through to the lists I'm on yet, but it's probably only a matter of time before someone's copy chooses a valid From: address. I hadn't gone to look up the details on it yet, but I figured it was forging From:'s when I saw a mail purportedly from an older address belonging to our coordinator, who lives in Australia, coming from an ISP which is local to me, halfway around the world in Canada. I haven't been tracing ISPs, but I'm guessing it's spread over the US by now. Thanks for the extra info, Chuq. I should probably make a similar notice available before I start getting complaints. Terri From claw@kanga.nu Tue Apr 23 19:22:03 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 23 Apr 2002 11:22:03 -0700 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: Message from Henning =?iso-8859-1?q?H=FClsebusch?= of "Tue, 23 Apr 2002 10:26:11 +0200." <200204230826.g3N8QB510772@router.intern.huelsebusch.net> References: <200204230826.g3N8QB510772@router.intern.huelsebusch.net> Message-ID: <32091.1019586123@kanga.nu> On Tue, 23 Apr 2002 10:26:11 +0200 h huelsebusch wrote: > Hi ! Is it possible that you insert Traffic-Accounting in Mailman ? > Don't know, but I think it's not so difficult, Mailman has to do > something like "(MailSize) * (actually members of the list)", stored > in a PLAIN-textfile, so it will also be possible to parse the total > traffic, monthly oder daily traffic. Several points: Mailman does not store the membership list in a text file. Further, under 2.1 Mailman may not store the membership list at all, but depending on local configuration may only have the ability to query (LDAP, SQL, whatever) an external service for the membership to apply to a specific message. Outbound traffic in a bandwidth sense is not a product of number of list members times size of message. That ignores bounces, RCPT TO bundling, and remote exploders (many companies subscribe a central account to popular lists and then explode that account to all internal interested parties and/or gate it to an internal newsgroup). All the data you seem to want is currently available from both the Mailman logs and your MTA logs. You just have to take it out and parse it. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Tue Apr 23 19:23:50 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 23 Apr 2002 11:23:50 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] mailman loops because of & in an address In-Reply-To: Message from Antenna Support of "Tue, 23 Apr 2002 14:49:37 +0200." References: Message-ID: <32139.1019586230@kanga.nu> On Tue, 23 Apr 2002 14:49:37 +0200 (CEST) Antenna Support wrote: > Dear people, We just experienced a loop: a message was sent many times > because it wasn't deleted in the /home/mailman/qfiles directory The > error mailed was: > /usr/bin/python -S /home/mailman/cron/qrunner > sh: c.lovell@xtra.co.nz: command not found c... User unknown > It appeared that there was an address added to the list: > m&c.lovell@xtra.co.nz > The loop could only be stopped by removing the .msg and .db file in > the qfiles directory. I also removed this address from the > subscribers. Aiiieee! We should really sanitise inbound email addresses. "&" is not a legal char in a LHS. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Tue Apr 23 19:29:19 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 23 Apr 2002 11:29:19 -0700 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: <32091.1019586123@kanga.nu> Message-ID: On 4/23/02 11:22 AM, "J C Lawrence" wrote: > Mailman does not store the membership list in a text file. Further, > under 2.1 Mailman may not store the membership list at all, but > depending on local configuration may only have the ability to query > (LDAP, SQL, whatever) an external service for the membership to apply > to a specific message. This, FWIW, is turning into a crucial issue for me. We've come ot realize the subscriber lists are a corporate asset that needs protecting, so a big To Do item for me now is to get them into a system inside the firewall and off the mail list machine in the border zone, so if there's a break-in, the data is cloistered. Those of you who run corporate list servers ought to stop and think about what the loss or leakage of your subscriber lists might do to you. I sat down with my security guys last week to go over issues, and that was THE top issue in their mind... (it started out as a "how do we protect our archives better" meeting, actually). -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From chuqui@plaidworks.com Tue Apr 23 22:35:55 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 23 Apr 2002 14:35:55 -0700 Subject: [Mailman-Developers] Warning: nasty variant of this new virus. Message-ID: I just got sent a new copy of the Klez.E virus. The text it sends to the user is this: -- Klez.E is the most common world-wide spreading worm.It's very dangerous by corrupting your files. Because of its very smart stealth and anti-anti-virus technic,most common AV software can't detect or clean it. We developed this free immunity tool to defeat the malicious virus. You only need to run this tool once,and then Klez will never come into your PC. NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV monitor maybe cry when you run it. If so,Ignore the warning,and select 'continue'. If you have any question,please mail to me . -- If you follow these instructions, you'll be infected by the worm. Don't run ANYTHING from anyone you don't explicitly can guarantee as a valid source of help. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From jarrell@vt.edu Tue Apr 23 22:43:19 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 23 Apr 2002 17:43:19 -0400 Subject: [Mailman-Developers] New emerging virus/worm. Grr. In-Reply-To: Message-ID: <5.1.0.14.2.20020423173932.00a83ec0@lennier.cc.vt.edu> At 10:07 AM 4/23/02 -0700, Chuq Von Rospach wrote: >Passing this along, because this has implications to list owners. > >A new emerging worm is out there in windows land. That's bad enough, but Jeez, chuq, where have you been? I've been dealing with klez for *months*. Our central scanners nail about 1,400 of them *a day*. A spam generating company's mailer got infected recently, and started spamming people all over the world with the addresses on their "to spam" list. The only new development in klez, which in itself is a variant of sircam (which I get about 2400 a day of) is that a new variant came out with a new message, and slipped past a lot of virus scanners for a day, (re)infecting a lot of people who *still* don't know not to click things. I swear, I could send them a mail messages that said "Click here to destroy your hard drive totally!" and they would. From chuqui@plaidworks.com Tue Apr 23 23:02:18 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 23 Apr 2002 15:02:18 -0700 Subject: [Mailman-Developers] New emerging virus/worm. Grr. In-Reply-To: <5.1.0.14.2.20020423173932.00a83ec0@lennier.cc.vt.edu> Message-ID: >> A new emerging worm is out there in windows land. That's bad enough, but > > Jeez, chuq, where have you been? I've been dealing with klez for > *months*. Our central scanners nail about 1,400 of them *a day*. This is a new variant, not the old Klez. And it's getting worse. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From jarrell@vt.edu Tue Apr 23 23:18:13 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 23 Apr 2002 18:18:13 -0400 Subject: [Mailman-Developers] Warning: nasty variant of this new virus. In-Reply-To: Message-ID: <5.1.0.14.2.20020423181628.00a95ec0@lennier.cc.vt.edu> At 02:35 PM 4/23/02 -0700, Chuq Von Rospach wrote: >I just got sent a new copy of the Klez.E virus. The text it sends to the >user is this: plus, as i recall, there's a *second* virus in the payload as well. A two-fer if you will. The sad this is, if you read the various klez codes, it's some guy bemoaning that he only makes $5k a year and has to support his parents, and is wondering if anyone will hire him now that he's demonstrated how good he is. From jarrell@vt.edu Tue Apr 23 23:22:05 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 23 Apr 2002 18:22:05 -0400 Subject: [Mailman-Developers] New emerging virus/worm. Grr. In-Reply-To: References: <5.1.0.14.2.20020423173932.00a83ec0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020423181951.00a95c60@lennier.cc.vt.edu> At 03:02 PM 4/23/02 -0700, Chuq Von Rospach wrote: > >> A new emerging worm is out there in windows land. That's bad enough, but > > > > Jeez, chuq, where have you been? I've been dealing with klez for > > *months*. Our central scanners nail about 1,400 of them *a day*. > >This is a new variant, not the old Klez. And it's getting worse. Yea, I know; that's total across the variant. About 900 of them are the new one. But still, it's been out for a while to. Of course, given that I manged the cluster of virus scanners that strip all our incoming mail, and get the nightly report, maybe I'm just sensitive to it. But our postmaster team has been backtracking origins of these things for a while now, and getting them fixed when we can. Some sites are really helpful and appreciative, and some sites are real pricks. Strangely, it seems to match the "will help stop spam" vs. "Go screw yourself" camps almost perfectly :-). From jwblist@olympus.net Wed Apr 24 01:16:20 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 23 Apr 2002 17:16:20 -0700 Subject: [Mailman-Developers] Warning: nasty variant of this new virus. In-Reply-To: References: Message-ID: At 14:35 -0700 4/23/2002, Chuq Von Rospach wrote: >I just got sent a new copy of the Klez.E virus. The text it sends to the >user is this: > >-- >Klez.E is the most common world-wide spreading worm.It's very dangerous by >corrupting your files. Ah...there's one now. It came in a text/html part, with quoted-printable encoding. The clever HTML which precedes the above material is (in its entirety) (I stuck the spaces into the first tag to try to avoid confusing some dumb mail client or overly-smart scanner). Klez.E... The social engineering in the English translation of the message isn't badly done. File name in this sample is "Fy.bat" (which I suspect I'm interpreting correctly). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From midnight@the-oasis.net Wed Apr 24 02:10:19 2002 From: midnight@the-oasis.net (Phil Barnett) Date: Tue, 23 Apr 2002 21:10:19 -0400 Subject: [Mailman-Developers] New emerging virus/worm. Grr. In-Reply-To: References: Message-ID: On Tuesday 23 April 2002 06:02 pm, you wrote: > >> A new emerging worm is out there in windows land. That's bad > >> enough, but > > > > Jeez, chuq, where have you been? I've been dealing with klez for > > *months*. Our central scanners nail about 1,400 of them *a day*. > > This is a new variant, not the old Klez. And it's getting worse. This is what I have in my "Hold posts with header value matching a specified regexp" field. I decided about a month ago that I will no longer tolerate attachments going through automatically. It does require me to be more vigilant, but it has stopped everything so far. As you can see, some of these are quite specific from repeat offenders that spam in plain text. But the generic ones are great for stopping virus attachments from going anywhere. I got two of my list regulars, one from Europe and one from the Far East to help me admin the list to let legitimate attachments through in a reasonable period of time. Generally, the delay is less than 30 minutes from the time one is posted until it is released. I stopped four viruses these from going out today, which means that 300 list members were spared virus attacks 4 times. So, I stopped Klez 1200 times today by having to moderate 4 messages. Pretty good trade, if you ask me. # Lines that *start* with a '#' are comments. to: friend@public.com message-id: relay.comanche.denmark.eu from: list@listme.com from: .*@uplinkpro.com from: .*@lithesoft.com from: .*@paid4survey.net from: .*@freegift4u.com.* subject: .*@Podtal.* from: .*etoyshop.* from: .*bdavisa.* subject: .*new photos from my party.* Content-type: text/html Content-type: text/enriched Content-type: text/x-vcard Content-type: multipart/alternative Content-type: multipart/related Content-type: multipart/mixed Content-type: application/octet-stream Content-Disposition: attachment from: .*@lehugo.com.br.* From tneff@bigfoot.com Wed Apr 24 17:31:38 2002 From: tneff@bigfoot.com (Tom Neff) Date: Wed, 24 Apr 2002 12:31:38 -0400 Subject: [Mailman-Developers] Re: the klez thing In-Reply-To: <20020424160005.24275.5050.Mailman@mail.python.org> References: <20020424160005.24275.5050.Mailman@mail.python.org> Message-ID: <686879843.1019651498@tom-9k5kaocfpin> This is only peripherally a mailman development issue. :) I use all three steps, in this order: - virus scan+block (inflex/uvscan) - demime - members-only posting As a result, the worst I have ever had is a short, stripped text component appearing mysteriously on a list. And that happened because some PREVIOUS virus scanner out in the wild had caught the virus, removed it and PASSED THE REST ON. Thanks ever so much, whoever you were :) From carson@taltos.org Thu Apr 25 11:11:10 2002 From: carson@taltos.org (Carson Gaspar) Date: Thu, 25 Apr 2002 06:11:10 -0400 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: References: Message-ID: <788303203.1019715070@[192.168.0.1]> --On Tuesday, April 23, 2002 11:29 AM -0700 Chuq Von Rospach wrote: > This, FWIW, is turning into a crucial issue for me. We've come ot realize > the subscriber lists are a corporate asset that needs protecting, so a big > To Do item for me now is to get them into a system inside the firewall and > off the mail list machine in the border zone, so if there's a break-in, > the data is cloistered. Speaking as someone who has just a few years of computer security experience, the above proposal accomplishes just about nothing, security-wise. If the mail list system in the DMZ can get the subscriber data from the system inside your firewall, then so can any attacker that compromises the mail list system. If you have some sort of read-only access to the datastore, then you may be protected from corruption, but not disclosure. -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From jarrell@vt.edu Thu Apr 25 12:04:11 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 25 Apr 2002 07:04:11 -0400 (EDT) Subject: [Mailman-Developers] japanesecodes-1.4.5 install prob Message-ID: <200204251104.g3PB4BK20821@babylon5.cc.vt.edu> When I try to install mailman now I'm getting: for p in email-2.0.1 JapaneseCodecs-1.4.5 KoreanCodecs-1.0.0; \ do \ gunzip -c $p.tar.gz | tar xf -; \ (cd $p ; PYTHONPATH=/home/mailman/pythonlib /usr/local/bin/python setup.py --quiet install --install-lib /home/mailman/pythonlib); \ done error: /usr/local/lib/python2.2/site-packages/japanese.pth: Permission denied *** Error code 1 make: Fatal error: Command failed for target `install-packages' Current working directory /usr/local/src/mailman-dev/mailman/misc *** Error code 1 make: Fatal error: Command failed for target `doinstall' Which of course, is correct, since as a non root users I can't write to site-packages... But which is shouldn't be trying to write *to*.. From chuqui@PLAIDWORKS.COM Thu Apr 25 15:33:18 2002 From: chuqui@PLAIDWORKS.COM (Chuq Von Rospach) Date: Thu, 25 Apr 2002 07:33:18 -0700 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: <788303203.1019715070@[192.168.0.1]> Message-ID: On 4/25/02 3:11 AM, "Carson Gaspar" wrote: > Speaking as someone who has just a few years of computer security > experience, the above proposal accomplishes just about nothing, > security-wise. Speaking as someone who also does, who lives with someone who did it for a living for a while, and went over this with some really sharp security folks, you're not correct. To start, you've forgotten the issue of multi-pronged attacks. The more services a single box supports, the more chances you have that a cracker can find a multi-service attack mode. But by moving the data from the list machine in the border zone inside the main firewall, it also makes that data less prone to attack from cracked machines elsewhere in the DMZ. If the data is on the box, a cracker could potentially get it by cracking into the DMZ anywhere and then cracking the database. By moving it and configuring the firewalls properly, they'd have to crack ONTO the list machine and then crack the data connection through the firewall. So it does far from nothing. It significantly limits the ability to get at that data, both by simplifying the services on the DMZ box, limiting attack angles, and by requiring they crack ONTO that box to have possible access to it, not just cracking ANY box on the DMZ (most of which I don't control). Huge improvements in security, because it removes a lot of variables, especially in areas where you don't have control Chuq -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From claw@kanga.nu Thu Apr 25 17:09:30 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 25 Apr 2002 09:09:30 -0700 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: Message from Carson Gaspar of "Thu, 25 Apr 2002 06:11:10 EDT." <788303203.1019715070@[192.168.0.1]> References: <788303203.1019715070@[192.168.0.1]> Message-ID: <7179.1019750970@kanga.nu> On Thu, 25 Apr 2002 06:11:10 -0400 Carson Gaspar wrote: > Speaking as someone who has just a few years of computer security > experience, the above proposal accomplishes just about nothing, > security-wise. If the mail list system in the DMZ can get the > subscriber data from the system inside your firewall, then so can any > attacker that compromises the mail list system. If you have some sort > of read-only access to the datastore, then you may be protected from > corruption, but not disclosure. You have to think about in terms of threat vectors and risk containment. With Mailman storing the membership roster locally, the only thing required to expose the roster is compromise of the Mailman box (it can then be copied off at leisure). With the membership roster stored remotely, exposure of the membership roster requires compromise both of the Mailman box and of the authentication/access controls for the membership roster (assuming a reasonably constrained ACL/capability system). That need not be a trivial second step. Further, Chuq's rosters are likely approaching large enough that he needs to keep them under an external DB. In such case, moving that DB off the Mailman box gives various advantages and disadvantages, primary among which are reduced complexity on the mailman box, no need for external access/export of the DB to other systems (eg marketing), better segmentation of risks, and reduced exposure to same-network-segment (as the mailman server) system compromise. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From totschnig.michael@uqam.ca Thu Apr 25 17:19:47 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Thu, 25 Apr 2002 12:19:47 -0400 Subject: [Mailman-Developers] problem in email Message-ID: <86k7qv4uos.fsf@cmo.uqam.ca> hello, i updated cvs today, and now I get the following errors, when I post to a list: Apr 25 11:54:54 2002 (20362) Uncaught runner exception: isinstance() arg 2 must be a class or type Apr 25 11:54:54 2002 (20362) Traceback (most recent call last): File "/var/Mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/var/Mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/Mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/var/Mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/var/Mailman/Mailman/Handlers/Hold.py", line 132, in process if mlist.administrivia and Utils.is_administrivia(msg): File "/var/Mailman/Mailman/Utils.py", line 541, in is_administrivia for line in email.Iterators.body_line_iterator(msg): File "/var/Mailman/pythonlib/email/Iterators.py", line 23, in body_line_iterator if isinstance(payload, StringTypes): TypeError: isinstance() arg 2 must be a class or type when I test the email package as explained in the README with PYTHONPATH=.; python2 tests/test_email.py I see the same error .........................................................................................E.................tests/test_email.py:1638: RuntimeWarning: test_japanese_codecs() skipped warnings.warn('test_japanese_codecs() skipped', RuntimeWarning, 1) ..... ====================================================================== ERROR: test_body_line_iterator (__main__.TestIterators) ---------------------------------------------------------------------- Traceback (most recent call last): File "tests/test_email.py", line 1253, in test_body_line_iterator it = Iterators.body_line_iterator(msg) File "/usr/lib/python2.1/site-packages/email/Iterators.py", line 23, in body_line_iterator if isinstance(payload, StringTypes): TypeError: isinstance() arg 2 must be a class or type ---------------------------------------------------------------------- Ran 112 tests in 0.694s FAILED (errors=1) Is this a bug or is there something wrong with my setup. thanks, Michael From lovelace@wayfarer.org Thu Apr 25 18:23:16 2002 From: lovelace@wayfarer.org (Tanner Lovelace) Date: 25 Apr 2002 13:23:16 -0400 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: References: Message-ID: <1019755398.1766.50.camel@linux-lovelace.internal.opennms.org> On Thu, 2002-04-25 at 10:33, Chuq Von Rospach wrote: > On 4/25/02 3:11 AM, "Carson Gaspar" wrote: > But by moving the data from the list machine in the border zone inside the > main firewall, it also makes that data less prone to attack from cracked > machines elsewhere in the DMZ. If the data is on the box, a cracker could > potentially get it by cracking into the DMZ anywhere and then cracking the > database. By moving it and configuring the firewalls properly, they'd have > to crack ONTO the list machine and then crack the data connection through > the firewall. Don't forget, however, that since the list machine must get at the data somehow, you now have one more opening through your main firewall that must be secured/monitored/etc... So, basically, it's a trade off. Tanner -- Tanner Lovelace | lovelace@wayfarer.org | http://wtl.wayfarer.org/ --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-- GPG Fingerprint = A66C 8660 924F 5F8C 71DA BDD0 CE09 4F8E DE76 39D4 GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-- He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. -- Thomas Jefferson From chuqui@plaidworks.com Thu Apr 25 19:01:33 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 25 Apr 2002 11:01:33 -0700 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: <1019755398.1766.50.camel@linux-lovelace.internal.opennms.org> Message-ID: On 4/25/02 10:23 AM, "Tanner Lovelace" wrote: > Don't forget, however, that since the list machine must get > at the data somehow, you now have one more opening through > your main firewall that must be secured/monitored/etc... > So, basically, it's a trade off. I'll take one extra port over leaving the data open to multi-layer attacks from elsewhere in the border zone any day. You go from having to make sure the DBMS isn't cracked to having to monitor what traffic goes out of the database. Either way, you're monitoring, and it's a lot easier to monitor this way. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From bethe@neuekraft.org Thu Apr 25 20:58:15 2002 From: bethe@neuekraft.org (bethe@neuekraft.org) Date: Thu, 25 Apr 2002 21:58:15 +0200 Subject: [Mailman-Developers] Bug in email confirmation of subscription? Message-ID: <001201c1ec93$8a2431a0$0300a8c0@client> hi developers! according to the question of Colin Mackinlay on Sun, 3 Mar 2002 --------------------------------------------------------------------- Bug in email confirmation of subscription? --------------------------------------------------------------------- i like to ask aswell, if there is any known problem concerning the subscription-procedure via e-mail. We are running MM 2.1b1 and Python 2.2.1 and we have the same problem ... Thanks very much! Thomas Bethe -- bethe@neuekraft.org http://neuekraft.org/kontakt/ From totschnig.michael@uqam.ca Thu Apr 25 22:21:27 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Thu, 25 Apr 2002 17:21:27 -0400 Subject: [Mailman-Developers] Re: problem in email In-Reply-To: <86k7qv4uos.fsf@cmo.uqam.ca> (totschnig.michael@uqam.ca's message of "Thu, 25 Apr 2002 12:19:47 -0400") References: <86k7qv4uos.fsf@cmo.uqam.ca> Message-ID: <86d6wnlbjc.fsf@cmo.uqam.ca> totschnig.michael@uqam.ca wrote: > Apr 25 11:54:54 2002 (20362) Uncaught runner exception: isinstance() arg 2 must be a class or type [...] the problem went away after I updated Python from 2.1.1 to 2.2.1. I did not take care about fact that mailman now requires at least 2.1.2. Sorry for the noise. Michael From claw@kanga.nu Thu Apr 25 23:27:45 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 25 Apr 2002 15:27:45 -0700 Subject: [Mailman-Developers] MailMan-Traffic In-Reply-To: Message from Tanner Lovelace of "25 Apr 2002 13:23:16 EDT." <1019755398.1766.50.camel@linux-lovelace.internal.opennms.org> References: <1019755398.1766.50.camel@linux-lovelace.internal.opennms.org> Message-ID: <14404.1019773665@kanga.nu> On 25 Apr 2002 13:23:16 -0400 Tanner Lovelace wrote: > On Thu, 2002-04-25 at 10:33, Chuq Von Rospach wrote: >> On 4/25/02 3:11 AM, "Carson Gaspar" wrote: >> But by moving the data from the list machine in the border zone >> inside the main firewall, it also makes that data less prone to >> attack from cracked machines elsewhere in the DMZ. If the data is on >> the box, a cracker could potentially get it by cracking into the DMZ >> anywhere and then cracking the database. By moving it and configuring >> the firewalls properly, they'd have to crack ONTO the list machine >> and then crack the data connection through the firewall. > Don't forget, however, that since the list machine must get at the > data somehow, you now have one more opening through your main firewall > that must be secured/monitored/etc... So, basically, it's a trade > off. Not necessarily. Just put in an additional DMZ layer so that you have a different network segment used for data servers than for public servers. (I'm running exactly this setup with my home network: public net, public DMZ net, private DMZ net, in-house net (desktops etc), 802.11b net -- each a physically distinct network segment). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From Dan Mick Thu Apr 25 23:34:54 2002 From: Dan Mick (Dan Mick) Date: Thu, 25 Apr 2002 15:34:54 -0700 (PDT) Subject: [Mailman-Developers] [scr] Worm Klez.E immunity Message-ID: <200204252235.g3PMZHbH010344@utopia.West.Sun.COM> Fabulous. This goes to my mailing list, apparently from Barry. F***ing virus writers. I want them strung up by and with their privates. ------------- Begin Forwarded Message ------------- From: barry To: scr@socal-raves.org Date: Thu, 25 Apr 2002 16:47:02 -0500 X-Converted-To-Plain-Text: from multipart/alternative by demime 0.98e X-Converted-To-Plain-Text: Alternative section used was text/html Subject: [scr] Worm Klez.E immunity X-Spam-Status: No, hits=-100.0 required=4.5 tests=A_FROM_IN_AUTO_WLIST version=2.0 Klez.E is the most common world-wide spreading worm.It's very dangerous by corrupting your files. Because of its very smart stealth and anti-anti-virus technic,most common AV software can't detect or clean it. We developed this free immunity tool to defeat the malicious virus. You only need to run this tool once,and then Klez will never come into your PC. NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV monitor maybe cry when you run it. If so,Ignore the warning,and select 'continue'. If you have any question,please mail to me. _______________________________________________ For event info, list questions, or to unsubscribe, see http://www.socal-raves.org/ ------------- End Forwarded Message ------------- From barry@wooz.org Thu Apr 25 23:47:00 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Thu, 25 Apr 2002 18:47:00 -0400 Subject: [Mailman-Developers] Re: [scr] Worm Klez.E immunity References: <200204252235.g3PMZHbH010344@utopia.West.Sun.COM> Message-ID: <15560.34660.921627.936985@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Fabulous. This goes to my mailing list, apparently from DM> Barry. DM> F***ing virus writers. I want them strung up by and with DM> their privates. I'd like similar measures taken against those software vendors who allow this kind of disgrace to continue. -Barry From Dan Mick Fri Apr 26 00:46:22 2002 From: Dan Mick (Dan Mick) Date: Thu, 25 Apr 2002 16:46:22 -0700 (PDT) Subject: [Mailman-Developers] [scr] Worm Klez.E immunity Message-ID: <200204252346.g3PNkkbH014804@utopia.West.Sun.COM> Oh, and, btw, it's not *my* address book. I don't use that crap. > Fabulous. This goes to my mailing list, apparently from Barry. > > F***ing virus writers. I want them strung up by and with their privates. > > ------------- Begin Forwarded Message ------------- > > From: barry > To: scr@socal-raves.org > Date: Thu, 25 Apr 2002 16:47:02 -0500 > X-Converted-To-Plain-Text: from multipart/alternative by demime 0.98e > X-Converted-To-Plain-Text: Alternative section used was text/html > Subject: [scr] Worm Klez.E immunity > X-Spam-Status: No, hits=-100.0 required=4.5 tests=A_FROM_IN_AUTO_WLIST > version=2.0 > > Klez.E is the most common world-wide spreading worm.It's very dangerous > by corrupting your files. > Because of its very smart stealth and anti-anti-virus technic,most common > AV software can't detect or clean it. > We developed this free immunity tool to defeat the malicious virus. > You only need to run this tool once,and then Klez will never come into > your PC. > NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV > monitor maybe cry when you run it. > If so,Ignore the warning,and select 'continue'. > If you have any question,please mail to me. > _______________________________________________ > For event info, list questions, or to unsubscribe, see > http://www.socal-raves.org/ > > ------------- End Forwarded Message ------------- > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From jarrell@vt.edu Fri Apr 26 08:32:43 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 26 Apr 2002 03:32:43 -0400 Subject: [Mailman-Developers] [scr] Worm Klez.E immunity In-Reply-To: <200204252235.g3PMZHbH010344@utopia.West.Sun.COM> Message-ID: <5.1.0.14.2.20020426031743.00a0a7f0@lennier.cc.vt.edu> At 03:34 PM 4/25/02 -0700, you wrote: >Fabulous. This goes to my mailing list, apparently from Barry. > >F***ing virus writers. I want them strung up by and with their privates. We ended up spending upwards of $150K to build a redundant, and fast, central email virus scanning solution to solve the problem. About 1300 nodes worth of email gets fed through a pair of redundant load balancers into one of four duplicated dedicated scanning/routing engines. The vast majority of it gets "intercepted" and handed off to a central mail server (so mail to schmuck@schmuckssmtplesspc gets properly rerouted to schmuck@arealmailserver). The rest then gets redistributed to end client machines based on some ldap-based routing rules. (Such as mail to our listserv machine, or mail going through the mailman machine.) We also scan outbound from the central servers, and anyone else who uses our outbound relay. It was expensive as hell (although a lot of fun, in retrospect, after all the screaming at "You're *how* busy?" vendors whose stuff tended to fall apart under our loads) but well worth it. Combining the hardware, with efforts by our support staff to contact, and delouse, nodes confirmed as sending high quantities of virus email, etc, has paid off. We went from an average of 30,000 virus detections a day when the school year (and the production project) began, to now we're seeing about 3,000. Based on historical call records to our central group, and support cost analyses, and that fact that we've now intercepted about 1.8 million viruses, we estimate we've over a million dollars in staff time. That translates into what our group calls M$ (Management Dollars). So, basically, everyone agrees that we've paid out the purchase price of the complex... Now if we could just get more vendors to understand that a big university is not at all comparable to even huge isps. We're, effectively, bigger than they are. We get vendors telling us "Oh, look at the benchmark numbers on our product; we can handle 150,000 users on one box." Yes. They can. If only 5% of them call in at any time, use 33.6K modems, check their mail on the average of twice a day, send at most 2 1K or less notes a day, and generally receive no more than 3 <1K notes, the stuff works fine. Then they come here, where out of 86,000 user accounts I'll have 35,000 active in any given day, and about 70,000 active in a seven day period, with some of them checking email about every 4 seconds (2.1 million pop checks a day on average), and about 12,000 of them plugged into a switched 10meg port that backs onto our gig backbone, and their box bursts into flame... From stephen@xemacs.org Fri Apr 26 13:45:45 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 26 Apr 2002 21:45:45 +0900 Subject: [Mailman-Developers] [scr] Worm Klez.E immunity In-Reply-To: <200204252235.g3PMZHbH010344@utopia.West.Sun.COM> References: <200204252235.g3PMZHbH010344@utopia.West.Sun.COM> Message-ID: <87sn5i7hmu.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Dan" == Dan Mick writes: Dan> Fabulous. This goes to my mailing list, apparently from Dan> Barry. Dan> F***ing virus writers. I want them strung up by and with Dan> their privates. Well, in the last 48 hours on the xemacs lists, spam "from" rms@gnu.org, clerik@naggum.no, acs@xemacs.org (XEmacs Review Board member), ben@666.com (ditto), and me has arrived at xemacs.org ... and been sent to the bit bucket by procmail: # Use of $ to match newline is a special procmail extension. # The idiom (.*$[ ])* should match across RFC 822 folded lines. # Note that the character class is {SPC,TAB}, procmail doesn't grok \t? :0 * ^content-type:.*multipart * B ?? ^content-(type|disposition|description):(.*$[ ])*\ .*name=.*(\.(exe|pif|bat|scr|doc|asp|wab|xls|mpe?g|mp3|rtf)\ |\[[0-9][0-9]*\].*\.htm?l[^"]) xemacs-spam/executable-included No false positives, and once I got the folded lines part right no Klez to the lists, either. (Boy, procmail is painful.) Other stuff still gets through occasionally, though. Of course Ron Jarrell's $150,000 was well-spent IMO, but for my purposes this is effective enough to be very satisfying. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py From db@bibsys.no Fri Apr 26 15:45:29 2002 From: db@bibsys.no (Daniel Buchmann) Date: Fri, 26 Apr 2002 16:45:29 +0200 Subject: [Mailman-Developers] Archive trouble Message-ID: <3CC96809.13F11DB4@bibsys.no> [CVS Mailman, python 2.2] I'm having serious problems generating the archive of one of my mailing lists. The mbox for the list has 401 messages, but bin/arch stops at message #311. No error or traceback occurs. If I try "bin/arch -s 312 ", nothing happens. (I only get the "Pickling archive state ..." message.) The same happens if I start at e.g. message #350. Anyone else seen this? Barry: you should probably update the INSTALL and README files asap; they say python 2.1 is required, and 2.1.2 or 2.2 is recommended. Should probably be "requires at least python 2.1.2, but 2.2 is recommended" ? (I got a lot of messages in qfiles/shunt because of this, just like Michael (http://mail.python.org/pipermail/mailman-developers/2002-April/011654.html) did. Upgraded python to 2.2 and ran unshunt, now it works fine. :) -Daniel From barry@zope.com Fri Apr 26 18:00:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Apr 2002 13:00:27 -0400 Subject: [Mailman-Developers] Archive trouble References: <3CC96809.13F11DB4@bibsys.no> Message-ID: <15561.34731.951803.26212@anthem.wooz.org> >>>>> "DB" == Daniel Buchmann writes: DB> I'm having serious problems generating the archive of one of DB> my mailing lists. The mbox for the list has 401 messages, but DB> bin/arch stops at message #311. No error or traceback DB> occurs. If I try "bin/arch -s 312 ", nothing DB> happens. (I only get the "Pickling archive state ..." DB> message.) The same happens if I start at e.g. message #350. DB> Anyone else seen this? Was this a list created in an earlier version of Mailman? If so, it's possible that you've got un-escaped From_ lines in the body of your messages that's messing things up. Try "bin/cleanarch -h" for more information. DB> Barry: you should probably update the INSTALL and README files DB> asap; they say python 2.1 is required, and 2.1.2 or 2.2 is DB> recommended. Should probably be "requires at least python DB> 2.1.2, but 2.2 is recommended" ? (I got a lot of messages in DB> qfiles/shunt because of this, just like Michael DB> (http://mail.python.org/pipermail/mailman-developers/2002-April/011654.html) DB> did. Upgraded python to 2.2 and ran unshunt, now it works DB> fine. :) I will update these files. Thanks, -Barry From barry@zope.com Fri Apr 26 18:18:18 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Apr 2002 13:18:18 -0400 Subject: [Mailman-Developers] problem in email References: <86k7qv4uos.fsf@cmo.uqam.ca> Message-ID: <15561.35802.443977.724409@anthem.wooz.org> >>>>> "tm" == totschnig michael writes: tm> i updated cvs today, and now I get the following errors, when tm> I post to a list: tm> TypeError: isinstance() arg 2 must be a class or type This should be fixed in (Mailman's) cvs now. It should be usable with either Python 2.1.3 or Python 2.2.1. Thanks, -Barry From barry@zope.com Fri Apr 26 18:42:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Apr 2002 13:42:39 -0400 Subject: [Mailman-Developers] japanesecodes-1.4.5 install prob References: <200204251104.g3PB4BK20821@babylon5.cc.vt.edu> Message-ID: <15561.37263.288307.47155@anthem.wooz.org> [I'm Cc'ing the distutils wizard and the JapaneseCodecs author, since I believe this is a bug in one of those two systems -BAW] >>>>> "RJ" == Ron Jarrell writes: RJ> When I try to install mailman now I'm getting: RJ> for p in email-2.0.1 JapaneseCodecs-1.4.5 KoreanCodecs-1.0.0; RJ> \ do \ RJ> gunzip -c $p.tar.gz | tar xf -; \ (cd $p ; RJ> PYTHONPATH=/home/mailman/pythonlib /usr/local/bin/python setup.py RJ> --quiet install --install-lib /home/mailman/pythonlib); \ RJ> done error: RJ> /usr/local/lib/python2.2/site-packages/japanese.pth: RJ> Permission denied *** Error code 1 make: Fatal error: Command RJ> failed for target `install-packages' Current working directory RJ> /usr/local/src/mailman-dev/mailman/misc *** Error code 1 make: RJ> Fatal error: Command failed for target `doinstall' RJ> Which of course, is correct, since as a non root users I can't RJ> write to site-packages... But which is shouldn't be trying to RJ> write *to*.. The problem I believe is in either distutils, or the way the Japanese codec package setup.py file is written. "python setup.py --help install" says: Options for 'Install' command: [...] --install-base base installation directory (instead of --prefix or -- home) --install-platbase base installation directory for platform-specific files (instead of --exec-prefix or --home) --root install everything relative to this alternate root directory --install-purelib installation directory for pure Python module distributions --install-platlib installation directory for non-pure module distributions --install-lib installation directory for all module distributions (overrides --install-purelib and --install-platlib) --install-headers installation directory for C/C++ headers --install-scripts installation directory for Python scripts --install-data installation directory for data files So I've been using --install-lib to put the JapaneseCodecs package (as well as the email and KoreanCodecs packages) in $(PYTHONLIBDIR), which by default is /usr/local/mailman/pythonlib. The problem comes because the japanese.pth file doesn't honor --install-lib. Trial and error shows that if I include --install-purelib $(PYTHONLIBDIR) then japanese.pth goes in the right place, e.g. /usr/local/mailman/pythonlib. So as a workaround, I've made this change. >From the JapaneseCodecs setup.py file: -------------------- snip snip -------------------- class Install(install): def finalize_options (self): install.finalize_options(self) self.distribution.data_files = [ (self.install_purelib, ["japanese.pth"])] -------------------- snip snip -------------------- and according to the help text above, shouldn't self.install_purelib be coming from my --install-lib option? Is this a bug in distutils? Or does the setup.py file need to be fixed? Note: Python 2.2.1 being used. -Barry From jarrell@vt.edu Fri Apr 26 23:07:19 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 26 Apr 2002 18:07:19 -0400 Subject: [Mailman-Developers] japanesecodes-1.4.5 install prob In-Reply-To: <200204262051.FAA10092@nat-dhcp100.grad.sccs.chukyo-u.ac.jp > References: <15561.37263.288307.47155@anthem.wooz.org> <15561.37263.288307.47155@anthem.wooz.org> Message-ID: <5.1.0.14.2.20020426180430.00a124b0@lennier.cc.vt.edu> At 05:51 AM 4/27/02 +0900, Tamito KAJIYAMA wrote: >I got reports that bdist_wininst and bdist_rpm posed similar >problems. Attached below are the patches the reporters sent >to me. Honestly speaking I cannot figure out a right way that >fixes problems on all platforms with any distutils options. > >Any comments and suggestions are very appreciated. > >Regards, > >-- >KAJIYAMA, Tamito > > >For bdist_wininst: >--- setup.py.orig Thu Apr 18 01:20:38 2002 >+++ setup.py Thu Apr 18 01:20:16 2002 >@@ -27,7 +27,7 @@ > def finalize_options (self): > install.finalize_options(self) > self.distribution.data_files = [ >- (self.install_purelib, ["japanese.pth"])] >+ ("lib/site-packages", ["japanese.pth"])] > > setup (name = "JapaneseCodecs", > version = "1.4.5", > > >For bdist_rpm: >--- setup.py.orig Wed Apr 17 16:42:13 2002 >+++ setup.py Thu Apr 18 19:50:49 2002 >@@ -2,6 +2,7 @@ > # Tamito KAJIYAMA <30 November 2000> > # $Id: setup.py,v 1.7 2002/04/17 03:53:31 kajiyama Exp $ > >+import sys, os > from distutils.core import setup, Extension > from distutils.command.build_py import build_py > from distutils.command.install import install >@@ -27,7 +28,8 @@ > def finalize_options (self): > install.finalize_options(self) > self.distribution.data_files = [ >- (self.install_purelib, ["japanese.pth"])] >+ (os.path.join(sys.prefix, 'lib', 'python'+sys.version[:3], >'site-packages'), >+ ["japanese.pth"])] > > setup (name = "JapaneseCodecs", > version = "1.4.5", Uhh, I would think this would make the problem worse. These patches would *force* the .pth file into the system site-packages directory, even if the user has specified install options to force them into a private directory. In this case mailman's install is trying to install the codecs into a private library that mailman uses. mailman's install is specifically designed so as to *not* be installed as root, which makes it generally impossible for it to install the codecs if they *have* to go into site-packages... From Dan Mick Fri Apr 26 23:10:17 2002 From: Dan Mick (Dan Mick) Date: Fri, 26 Apr 2002 15:10:17 -0700 (PDT) Subject: [Mailman-Developers] [scr] Worm Klez.E immunity Message-ID: <200204262210.g3QMAhbH006927@utopia.West.Sun.COM> > >>>>> "Dan" == Dan Mick writes: > > Dan> Fabulous. This goes to my mailing list, apparently from > Dan> Barry. > > Dan> F***ing virus writers. I want them strung up by and with > Dan> their privates. > > Well, in the last 48 hours on the xemacs lists, spam "from" > rms@gnu.org, clerik@naggum.no, acs@xemacs.org (XEmacs Review Board > member), ben@666.com (ditto), and me has arrived at xemacs.org ... and > been sent to the bit bucket by procmail: > > # Use of $ to match newline is a special procmail extension. > # The idiom (.*$[ ])* should match across RFC 822 folded lines. > # Note that the character class is {SPC,TAB}, procmail doesn't grok \t? > :0 > * ^content-type:.*multipart > * B ?? ^content-(type|disposition|description):(.*$[ ])*\ > .*name=.*(\.(exe|pif|bat|scr|doc|asp|wab|xls|mpe?g|mp3|rtf)\ > |\[[0-9][0-9]*\].*\.htm?l[^"]) > xemacs-spam/executable-included > > No false positives, and once I got the folded lines part right no Klez > to the lists, either. (Boy, procmail is painful.) amen. Thanks for the tip, although I still say if we strung more of 'em up by their privates, we'd have less innocent-punishing like this. But of course having a solution is much more pragmatic. From barry@zope.com Sat Apr 27 17:04:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 27 Apr 2002 12:04:23 -0400 Subject: [Mailman-Developers] Is MM cookie auth 'secure' thru HTTP proxy servers? References: <5.1.0.14.2.20020422164315.03f4cbe0@pop.ftel.co.uk> Message-ID: <15562.52231.524822.418499@geddy.wooz.org> >>>>> "RB" == Richard Barrett writes: RB> Can someone out there sanity check my thinking on a possible RB> hole in Mailman's cookie based authentication. RB> The scenario I'm concerned with is when Mailman's web GUI is RB> being accessed by a browser via a caching HTTP proxy server RB> such as Squid, hardly an uncommon situation these days. RB> If my understanding is correct, then Squid (legitimately and RB> like probably any other HTTP proxy) has no qualms about RB> caching a page merely because of the existence of Cookies or RB> Set-Cookie headers in the response or request. This is RB> justified by RFC 2616. The Squid FAQ says: Now that I'm back online, I doubled checked the RFC. Section 9.5 POST says: Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. I think we're safe and probably don't need to change anything. All Mailman interactions are done through POSTs, except for public archiver hits, and those /can/ be cached. So unless I'm off-base, I think we're fine as-is. -Barry From barry@zope.com Sat Apr 27 17:34:51 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 27 Apr 2002 12:34:51 -0400 Subject: [Mailman-Developers] japanesecodes-1.4.5 install prob References: <15561.37263.288307.47155@anthem.wooz.org> <5.1.0.14.2.20020426180430.00a124b0@lennier.cc.vt.edu> Message-ID: <15562.54059.341804.448043@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Uhh, I would think this would make the problem worse. These RJ> patches would *force* the .pth file into the system RJ> site-packages directory, even if the user has specified RJ> install options to force them into a private directory. Ron's right; this would make things worse! -Barry From barry@zope.com Sat Apr 27 01:30:58 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Apr 2002 20:30:58 -0400 Subject: [Mailman-Developers] 2.1b1: web-based create and DEFAULT_EMAIL_HOST? References: <2312.1019580774@elisabeth.cfrq.net> Message-ID: <15561.61762.192331.658870@geddy.wooz.org> >>>>> "HK" == Harald Koch writes: HK> I just created a new list via the web interface, and the HK> 'host_name' parameter for the list was "www.cfrq.net" (the HK> value of DEFAULT_URL_HOST) instead of "cfrq.net" (the value of HK> DEFAULT_EMAIL_HOST). HK> This surprised me... Me too. HK> Mailman/Cgi/create.py uses the VIRTUAL_HOSTS stuff to get the HK> correct value for host_name, but I don't have any HK> VIRTUAL_HOSTS defined (other than the default, which should HK> correctly map DEFAULT_URL_HOST to DEFAULT_EMAIL_HOST). HK> Any suggestions as to where to look would be appreciated... As you probably saw, if you don't make any calls to add_virtualhost(), the default is to add an entry mapping DEFAULT_URL_HOST -> DEFAULT_EMAIL_HOST. Even if it doesn't find the hostname returned by Utils.get_domain() in VIRTUAL_HOSTS, it should still use DEFAULT_EMAIL_HOST. So I'm at a loss too. -Barry From barry@zope.com Sat Apr 27 02:06:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Apr 2002 21:06:12 -0400 Subject: [Mailman-Developers] Re: Is MM cookie auth 'secure' thru HTTP proxy servers? References: <5.1.0.14.2.20020423103409.03e00c38@pop.ftel.co.uk> Message-ID: <15561.63876.670970.922275@geddy.wooz.org> >>>>> "RB" == Richard Barrett writes: RB> Further to what I said before (see below), I now enclose a RB> patch to correct the problem. The patch is to the RB> WebAuthenticate function in Mailman.SecurityManager. It adopts RB> the simple hypothesis that if you are setting or checking a RB> cookie then the response about to be made shouldn't be cached. Thanks Richard. I don't think the patch is quite right but it's close. I can't produce a diff right now (I'm replying to this while off-line) but I'll generate patches against MM2.0.10 and MM2.1cvs when I get a chance. What do folks think, does this warrant a 2.0.11 release? -Barry From marc_news@vasoftware.com Sat Apr 27 22:52:14 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sat, 27 Apr 2002 14:52:14 -0700 Subject: [Mailman-Developers] Traceback on double rename Message-ID: <20020427215214.GJ12548@merlins.org> I have a user who says he got this on mailman 2.1b1cvs He explains below how he did it. ----- Forwarded message from David T-G ----- Subject: Mailman results for Empeg-faq From: empeg-faq-request@merlins.org To: davidtg-empeg@justpickone.org X-List-Administrivia: yes This is an automated response. There were problems with the email commands you sent to Mailman via the administrative address empeg-faq-request@empeg.merlins.org. To obtain instructions on valid Mailman email commands, send email to empeg-faq-request@empeg.merlins.org with the word "help" in the subject line or in the body of the message. If you want to reach the human being that manages this mailing list, please send your message to empeg-faq-owner@empeg.merlins.org. The following is a detailed description of the problems. ***** confirm 97bbfd70939538b155776d5e652af14bc6032c36 >>>>> An unexpected Mailman error has occurred. >>>>> >>>>> Please forward your request to the human list administrator in charge >>>>> of this list at . The traceback is >>>>> attached below and will be forwarded to the list administrator >>>>> automatically. Traceback (most recent call last): File "/var/local/mailman/Mailman/MailCommandHandler.py", line 273, in ParseMailCommands self.__dispatch[cmd](args, line, msg) File "/var/local/mailman/Mailman/MailCommandHandler.py", line 727, in ProcessConfirmCmd results = self.ProcessConfirmation(args[0], msg) File "/var/local/mailman/Mailman/MailList.py", line 1041, in ProcessConfirmation self.ApprovedChangeMemberAddress(oldaddr, newaddr, globally) File "/var/local/mailman/Mailman/MailList.py", line 976, in ApprovedChangeMemberAddress self.changeMemberAddress(oldaddr, newaddr) File "/var/local/mailman/Mailman/OldStyleMemberships.py", line 234, in changeMemberAddress self.__assertIsMember(member) File "/var/local/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member NotAMemberError: davidtg@bigfoot.com ----- End forwarded message ----- ----- Forwarded message from David T-G ----- % Were you trying to change your subscription from davidtg@bigfoot.com to % davidtg-empeg@justpickone.org via the mail interface? No; I did it thru the web interface. % If so, do you mind sending me a copy of the mails you sent to the list % manager (I run a devel version of the upcoming mailman, and I try to help Sorry; any sort of subscribe and confirm messages I just toss in the bit bucket. In addition, once the subscriptions were confirmed, I tossed the list server messages as well. Sorry! % out with small bugs. This one seems to be minor, but we should probably look % into it anyway) Sorry :-) It should be easy to duplicate, though; subscribe to two lists (like empeg-faq and empeg-announce), open two web browsers, go to the two list control pages and log in on each, and then send a change from one and a change from the other. Remember to hit "global" at some point along the way. When replying to the confirmation messages, reply to the first before doing the global change but the second, which might confusingly arrive after said global change, later after the web is done. ----- End forwarded message ----- -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From chk@pobox.com Sun Apr 28 05:59:28 2002 From: chk@pobox.com (Harald Koch) Date: Sun, 28 Apr 2002 00:59:28 -0400 Subject: [Mailman-Developers] 2.1b1: web-based create and DEFAULT_EMAIL_HOST? In-Reply-To: Your message of "Fri, 26 Apr 2002 20:30:58 -0400". <15561.61762.192331.658870@geddy.wooz.org> References: <2312.1019580774@elisabeth.cfrq.net> <15561.61762.192331.658870@geddy.wooz.org> Message-ID: <13172.1019969968@elisabeth.cfrq.net> > So I'm at a loss too. My bad; I'm confused about how the two configuration files get loaded. I left out a tiny piece of information, which is that the values for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST in my Defaults.py file are incorrect. Faithfully following the directions, I change them in mm_cfg.py. Apparently, I then need to call add_virtualhost again in that file; when I do so, I get the expected result. (I'm so embarrassed :-) -- Harald Koch "It takes a child to raze a village." -Michael T. Fry From barry@zope.com Sun Apr 28 18:37:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 28 Apr 2002 13:37:23 -0400 Subject: [Mailman-Developers] 2.1b1: web-based create and DEFAULT_EMAIL_HOST? References: <2312.1019580774@elisabeth.cfrq.net> <15561.61762.192331.658870@geddy.wooz.org> <13172.1019969968@elisabeth.cfrq.net> Message-ID: <15564.13139.472008.612254@anthem.wooz.org> >>>>> "HK" == Harald Koch writes: HK> My bad; I'm confused about how the two configuration files get HK> loaded. HK> I left out a tiny piece of information, which is that the HK> values for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST in my HK> Defaults.py file are incorrect. Faithfully following the HK> directions, I change them in mm_cfg.py. Apparently, I then HK> need to call add_virtualhost again in that file; when I do so, HK> I get the expected result. HK> (I'm so embarrassed :-) Not your fault. I've improved documentation in Defaults.py to give more background and explanations. -Barry From barry@zope.com Mon Apr 29 00:46:57 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 28 Apr 2002 19:46:57 -0400 Subject: [Mailman-Developers] Notifications for bug reports and patches Message-ID: <15564.35313.731498.27226@anthem.wooz.org> Currently the SourceForge bug and patch trackers for the Mailman project are set to send messages to mailman-cabal@python.org, which reaches just the core developers (of which I think I'm the only person currently not .forwarding to /dev/null ;). I'm wondering if it would be useful to redirect those messages to mailman-developers. It would certainly be helpful for me, because it would give you guys a chance to be notified of new bugs or patches, and comment on them via the trackers. This works well in the Python community, and I could certainly use other opinions on a number of bugs and patches. I don't think it would innundate you all with too much traffic. Thoughts? I'd probably turn this on after I finish my current bug triage pass. -Barry From stephen@xemacs.org Mon Apr 29 04:04:13 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 29 Apr 2002 12:04:13 +0900 Subject: [Mailman-Developers] Notifications for bug reports and patches In-Reply-To: <15564.35313.731498.27226@anthem.wooz.org> References: <15564.35313.731498.27226@anthem.wooz.org> Message-ID: <87u1pv2ok2.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> Currently the SourceForge bug and patch trackers for the BAW> Mailman project are set to send messages to BAW> mailman-cabal@python.org BAW> I'm wondering if it would be useful to redirect those BAW> messages to mailman-developers. XEmacs did this when we realized (wea maxima culpa) that _everybody_ had the bugtrack messages redirected to /dev/null. It's not really optimal, but we didn't get any complaints that I can remember. The non-developer beta testers don't seem to mind either, the few comments I've seen seem to agree that hearing about bugs and crashes, even for "ancient" versions, is preferable to missing even a few current or possibly still current bugs. I wasn't postmaster then so I can't say whether we got any unsubs. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py From pioppo@ferrara.linux.it Mon Apr 29 23:19:43 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Tue, 30 Apr 2002 00:19:43 +0200 Subject: [Mailman-Developers] a bug? Message-ID: <20020429221943.GC2799@abulafia.casa> The site language of my installation is 'it'. Creating a new list with the only permitted language as 'en' I have a list with ['en','it'] (which makes sense) and the preferred language marked as 'it', (which is wrong) Cheers From totschnig.michael@uqam.ca Tue Apr 30 06:33:14 2002 From: totschnig.michael@uqam.ca (totschnig.michael@uqam.ca) Date: Tue, 30 Apr 2002 01:33:14 -0400 Subject: [Mailman-Developers] Uncaught runner exception: 'NoneType' object Message-ID: Hello an error related to NoneType objects having no attributes has already been reported on this list. I get such an error only when I create a new list, only the mail sent to mailman-owner enumerating the new aliases to add seems to get caught in this. Should I test the patch Barry sent in message <15534.7944.843739.720556@anthem.wooz.org> to solve this problem? My MTA is sendmail. Thanks, Michael Apr 30 00:41:51 2002 (602) Uncaught runner exception: 'NoneType' object has no attribute 'Load' Apr 30 00:41:51 2002 (602) Traceback (most recent call last): File "/var/Mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/var/Mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/Mailman/Mailman/Queue/OutgoingRunner.py", line 58, in _dispose mlist.Load() AttributeError: 'NoneType' object has no attribute 'Load' From forrie@forrie.com Sun Apr 7 19:26:10 2002 From: forrie@forrie.com (Forrest Aldrich) Date: Sun, 07 Apr 2002 14:26:10 -0400 Subject: [Mailman-Developers] Re-use of private archive cookies Message-ID: <5.1.0.14.2.20020407142327.019432d8@192.168.1.1> For one of the lists I manage, I would like to provide an accompanying "file repository" archive. Instead of putting up a separate directory with an .htaccess/.htpasswd combination, I thought it might be reasonable to add a radio button to the authentication page (where the user enters his email address and password) to optionally access that repository. The goal being that once someone authenticated there, the same cookie could be used. And thus it would expire similarly. It's otherwise cumbersome to dig the config.db to get passwords and then enter them into .htpasswd. This might require some scripting for the document repository, I'm not sure. Anyhow, I wondered if someone had considered this as a feature or had otherwise implemented it. Yes, someone could just "post" documents to the list, but that could be cumbersome when there are many threads to consider. Thanks alot, Forrest From ota-7@andrew.pimlott.net Mon Apr 8 06:20:00 2002 From: ota-7@andrew.pimlott.net (Andrew Pimlott) Date: Mon, 8 Apr 2002 01:20:00 -0400 Subject: [Mailman-Developers] SF bug report #223533 In-Reply-To: <15537.6926.884565.125954@anthem.wooz.org> References: <15534.23246.975895.526224@anthem.wooz.org> <20020406033544.GA5979@pimlott.net> <15534.36506.138986.835619@anthem.wooz.org> <20020408031038.GU29934@merlins.org> <15537.6926.884565.125954@anthem.wooz.org> Message-ID: <20020408052000.GA16145@pimlott.net> On Mon, Apr 08, 2002 at 12:22:38AM -0400, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN writes: > > >> - List-Id: is included in all messages pertaining to a list, > >> including both postings and admin messages. > >> - List-Help:, > >> List-Subscribe:, List-Unsubscribe:, and List-Post: are added > >> only to postings. (Oh, and optionally List-Archive:). > > MM> Actually this is probably the best solution that I've read so > MM> far (including the one I wrote) > > Cool. I'll do one other thing. For administrivia messages, I'll add > an "X-List-Administrivia: yes" header. Great, thanks! Can I just suggest that you document this fairly prominently, so that people are more likely to figure out the right header for their filters? I would go so far as to put it in the default subscription-confirmation message. Andrew From adi@adiraj.org Mon Apr 15 05:25:25 2002 From: adi@adiraj.org (Adi Fairbank) Date: Sun, 14 Apr 2002 21:25:25 -0700 Subject: [Mailman-Developers] [PATCH] logo disabling, and extra " This is a multi-part message in MIME format. --------------7DEEFCB53E2C4EFDB71AE69F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are two quick patches I made (both against version 2.0.8): First one is a new feature which makes it easy to disable display of sponsor logos (I don't know if you wanted this to be so easy or not, but here it is). Second one is a minor bugfix which removes an extra "%s' % (tab, self.title)) output.append('%s' % tab) - output.append('%s hello ! i'd like to ask for a removal of the web_page_url field in the admin web interface. i don't see why a list admin would want or should even be allowed to change this. maybe i'm overlooking something ? (yeah, i filled something in, read the details, wanted to discard the changes, and on the next submit, i got screwed over by my browser's form cache :((( ) best regards, and thanks for putting mailman together, jörn -- Watch out where the huskies go and don't you eat the yellow snow ! - Frank Zappa From t.bethe@media-net.de Thu Apr 25 20:56:16 2002 From: t.bethe@media-net.de (Thomas Bethe) Date: Thu, 25 Apr 2002 21:56:16 +0200 Subject: [Mailman-Developers] Bug in email confirmation of subscription? Message-ID: <001001c1ec93$4343d0b0$0300a8c0@client> hi developers! according to the question of Colin Mackinlay on Sun, 3 Mar 2002 --------------------------------------------------------------------- Bug in email confirmation of subscription? --------------------------------------------------------------------- i like to ask aswell, if there is any known problem concerning the subscription-procedure via e-mail. We are running MM 2.1b1 and Python 2.2.1 and we have the same problem ... Thanks very much! Thomas Bethe -- bethe@neuekraft.org http://neuekraft.org/kontakt/ From info@nakawe.se Fri Apr 19 20:23:21 2002 From: info@nakawe.se (Veronica Loell) Date: Fri, 19 Apr 2002 21:23:21 +0200 (W. Europe Daylight Time) Subject: [Mailman-Developers] problem with digest mode Message-ID: Sorry for the format, but I thought it was easiest to send it like this. We have encountered a problem that only appears in the digest-mode. Regular mode and the archives work fine. This is a sourceforge list I think it's mailman version 2.0.9-sf.net. Since this only appears in digest and not in archiving etc, it does seem like a bug. Please note that this is not about the header-subject-line. This is the text in the body of the message. I know that I occasionally have come across this, that is the chars being reported as unknown with their hex-code, but I'm not all that knowledgable about why it happens. - Veronica Loell mindtrader@users.sourceforge.net -------------------------------- Following is a copy of the bug-thread: -------------------------------- Bugs item #545956, was opened at 2002-04-19 01:25 You can respond by visiting: http://sourceforge.net/tracker/?func=3Ddetail&atid=3D100103&aid=3D545956&gr= oup_id=3D103 Category: None Group: None >Status: Open Resolution: Out of Date Priority: 5 Submitted By: Veronica Loell (mindtrader) Assigned to: Nobody/Anonymous (nobody) Summary: digest mode dont recognize latin-1 Initial Comment: We just started a list where we commicate in swedish and hence use =E5=E4= =F6 from Latin-1. One of the members have choosen digest-mode and we have discovered a problem. All our mails use latin-1, and in the non-digest form and also in the archives all charachters are displayed correctly. In digest form however, the letters =E4=E5=F6 are marked as unknown, with their hex-numbers given. I have tested this by having both digest and non-digest delivered to me, using the same mailer etc. --------- Digest --------- Date: Thu, 18 Apr 2002 07:55:22 +0200 (W. Europe Daylight Time) From: Veronica Loell To: Subject: [cvs] =3D?ISO-8859- 1?Q?test_med_=3DE5=3DE4=3DF6?=3D Detta =3DE4r bara ett test f=3DF6r att utreda problemet med latin-1 i digestversionen. =3DC5=3DC4=3DD6 =3DE5=3DE4=3DF6 --------- Non-digest --------- Date: Thu, 18 Apr 2002 07:55:22 +0200 (W. Europe Daylight Time) From: Veronica Loell To: ag-cling- cvs@lists.sourceforge.net Subject: [cvs] test med =E5=E4=F6 Detta =E4r bara ett test f=F6r att utreda problemet med latin-1 i digestversionen. =C5=C4=D6 =E5=E4=F6 ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2002-04-19 14:40 Message: Logged In: YES user_id=3D12800 Well, now I'm not positive. Can you send a message to mailman-developers and see what other people think? ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-19 14:04 Message: Logged In: YES user_id=3D156789 Actually mailman does handle it perfectly, it only happens in the digest mode. And it is also not the header that is the problem it's the body of the email. But if this has been corrected I'll report it to sourceforge because they apperantly are using an old version. I do get plenty of email where the header is messed up, but the rest of the message is not. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-04-19 13:53 Message: Logged In: YES user_id=3D12800 Mailman 2.1 will correctly handle non-ascii characters in headers. The problem is (probably) that the addition of the prefix breaks rfc2047 encoding of the non-ascii characters in the Subject: header. ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-19 01:28 Message: Logged In: YES user_id=3D156789 I forgot to say. This is the listmanager managed by Sourceforge. ---------------------------------------------------------------------- From webmaster@isu.edu Sat Apr 20 00:14:23 2002 From: webmaster@isu.edu (Webmaster) Date: Fri, 19 Apr 2002 17:14:23 -0600 Subject: [Mailman-Developers] Web_page_url change Message-ID: <3CC0A4CF.B8215914@isu.edu> We are going to be changing the name of our Host Name on the Red Hat Linux box that Mailman 2.0.8 is running at. I would like to change all the lists and configuration for mailman over to this new Hostname. I don't want to setup a CNAME in DNS to keep the old hostname accessible. What steps are involved in accomplishing this task. I know you use the "withlist" with the command below. python -i bin/withlist -l mylist >>>m.web_page_url 'http://newname.com' >>>m.Save() >>>^D -- ################################################## Webmaster Idaho State University Computing & Communications webmaster@isu.edu ################################################## From jtraub@dragoncat.net Tue Apr 23 18:58:12 2002 From: jtraub@dragoncat.net (JT) Date: Tue, 23 Apr 2002 10:58:12 -0700 (PDT) Subject: [Mailman-Developers] Re: New emerging virus/worm. Grr. In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 23 Apr 2002, Chuq Von Rospach wrote: > This one has the possibility to get really ugly and nasty, folks, > because it's hijacking addresses. Users can't depend on being yelled at > by friends for being infected, because this new worm hides behind random > return addresses. Which means the only thing you know is that the > "person" sending you the email isn't the one infected, but someone who > knows both of you is... The return-path header however seems to be 'correct'. I was able to use that to track back the actual infected user, even when it masqueraded as being from one of the lists I am on. Hopefully this helps other people track this back as well and at least inform the correct person that they are infected. - --JT - -- [-------------------------------------------------------------------------] [ Practice random kindness and senseless acts of beauty. ] [ It's hard to seize the day when you must first grapple with the morning ] [-------------------------------------------------------------------------] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8xaC1lZQYYI16LJQRAvoDAJ9OJXJR6CO/PhaZ/QJuv/r0zUuxJwCfYVbh ld7T9CZ90dShV4JNHzyPxQ4= =Y/i2 -----END PGP SIGNATURE----- From sarwani@agrakom.com Thu Apr 25 23:22:45 2002 From: sarwani@agrakom.com (sarwani@agrakom.com) Date: Fri, 26 Apr 2002 05:22:45 +0700 (JAVT) Subject: [Mailman-Developers] Millist + mysql + postfix Message-ID: <2805.192.168.21.201.1019773365.squirrel@merpati> Is there anybody who can make millist which uusing database mysql + postfix? From kajiyama@grad.sccs.chukyo-u.ac.jp Fri Apr 26 21:51:04 2002 From: kajiyama@grad.sccs.chukyo-u.ac.jp (Tamito KAJIYAMA) Date: Sat, 27 Apr 2002 05:51:04 +0900 Subject: [Mailman-Developers] japanesecodes-1.4.5 install prob In-Reply-To: <15561.37263.288307.47155@anthem.wooz.org> (barry@zope.com) References: <15561.37263.288307.47155@anthem.wooz.org> Message-ID: <200204262051.FAA10092@nat-dhcp100.grad.sccs.chukyo-u.ac.jp> barry@zope.com (Barry A. Warsaw) writes: | | [I'm Cc'ing the distutils wizard and the JapaneseCodecs author, since | I believe this is a bug in one of those two systems -BAW] | | >>>>> "RJ" == Ron Jarrell writes: | | RJ> When I try to install mailman now I'm getting: | | RJ> for p in email-2.0.1 JapaneseCodecs-1.4.5 KoreanCodecs-1.0.0; | RJ> \ do \ | RJ> gunzip -c $p.tar.gz | tar xf -; \ (cd $p ; | RJ> PYTHONPATH=/home/mailman/pythonlib /usr/local/bin/python setup.py | RJ> --quiet install --install-lib /home/mailman/pythonlib); \ | RJ> done error: | RJ> /usr/local/lib/python2.2/site-packages/japanese.pth: | RJ> Permission denied *** Error code 1 make: Fatal error: Command | RJ> failed for target `install-packages' Current working directory | RJ> /usr/local/src/mailman-dev/mailman/misc *** Error code 1 make: | RJ> Fatal error: Command failed for target `doinstall' | | RJ> Which of course, is correct, since as a non root users I can't | RJ> write to site-packages... But which is shouldn't be trying to | RJ> write *to*.. | | The problem I believe is in either distutils, or the way the Japanese | codec package setup.py file is written. | | "python setup.py --help install" says: | | Options for 'Install' command: | [...] | --install-base base installation directory (instead of --prefix or -- | home) | --install-platbase base installation directory for platform-specific files | (instead of --exec-prefix or --home) | --root install everything relative to this alternate root | directory | --install-purelib installation directory for pure Python module | distributions | --install-platlib installation directory for non-pure module distributions | --install-lib installation directory for all module distributions | (overrides --install-purelib and --install-platlib) | --install-headers installation directory for C/C++ headers | --install-scripts installation directory for Python scripts | --install-data installation directory for data files | | So I've been using --install-lib to put the JapaneseCodecs package | (as well as the email and KoreanCodecs packages) in $(PYTHONLIBDIR), | which by default is /usr/local/mailman/pythonlib. | | The problem comes because the japanese.pth file doesn't honor | --install-lib. Trial and error shows that if I include | --install-purelib $(PYTHONLIBDIR) then japanese.pth goes in the right | place, e.g. /usr/local/mailman/pythonlib. So as a workaround, I've | made this change. | | >From the JapaneseCodecs setup.py file: | | -------------------- snip snip -------------------- | class Install(install): | def finalize_options (self): | install.finalize_options(self) | self.distribution.data_files = [ | (self.install_purelib, ["japanese.pth"])] | -------------------- snip snip -------------------- | | and according to the help text above, shouldn't self.install_purelib | be coming from my --install-lib option? Is this a bug in distutils? | Or does the setup.py file need to be fixed? | | Note: Python 2.2.1 being used. Barry, thanks you for the feedback. I got reports that bdist_wininst and bdist_rpm posed similar problems. Attached below are the patches the reporters sent to me. Honestly speaking I cannot figure out a right way that fixes problems on all platforms with any distutils options. Any comments and suggestions are very appreciated. Regards, -- KAJIYAMA, Tamito For bdist_wininst: --- setup.py.orig Thu Apr 18 01:20:38 2002 +++ setup.py Thu Apr 18 01:20:16 2002 @@ -27,7 +27,7 @@ def finalize_options (self): install.finalize_options(self) self.distribution.data_files = [ - (self.install_purelib, ["japanese.pth"])] + ("lib/site-packages", ["japanese.pth"])] setup (name = "JapaneseCodecs", version = "1.4.5", For bdist_rpm: --- setup.py.orig Wed Apr 17 16:42:13 2002 +++ setup.py Thu Apr 18 19:50:49 2002 @@ -2,6 +2,7 @@ # Tamito KAJIYAMA <30 November 2000> # $Id: setup.py,v 1.7 2002/04/17 03:53:31 kajiyama Exp $ +import sys, os from distutils.core import setup, Extension from distutils.command.build_py import build_py from distutils.command.install import install @@ -27,7 +28,8 @@ def finalize_options (self): install.finalize_options(self) self.distribution.data_files = [ - (self.install_purelib, ["japanese.pth"])] + (os.path.join(sys.prefix, 'lib', 'python'+sys.version[:3], 'site-packages'), + ["japanese.pth"])] setup (name = "JapaneseCodecs", version = "1.4.5", From philb@philb.us Mon Apr 29 01:28:38 2002 From: philb@philb.us (Phil Barnett) Date: Sun, 28 Apr 2002 20:28:38 -0400 Subject: [Mailman-Developers] Prompt Enhancement Request. Message-ID: What would be the chance of enhancing the following text in the membership modificiation page? I find a lot of people using this option to 'unsubscribe' from the list. I think this would happen less often if there was a better description with a pointer that this is not an unsubscribe function. ------------------- Disable mail delivery Turn this on if you want mail to not be delivered to you for a little while. From noreply@sourceforge.net Mon Apr 29 19:48:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Apr 2002 11:48:29 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-550314 ] Sending to multiple lists chooses one. Message-ID: Bugs item #550314, was opened at 2002-04-29 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550314&group_id=103 Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jeff Posner (jposnersails) Assigned to: Nobody/Anonymous (nobody) Summary: Sending to multiple lists chooses one. Initial Comment: When I send a single message addressed as multiple lists on to 'TO:' line, each recipient receives exactly one copy. If a single user is a memeber of more than one list, he receives the copy to a "seemingly" random list. I am new to this version (just upgraded from 1.x) and have not seen this problem before. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550314&group_id=103 From noreply@sourceforge.net Mon Apr 29 23:21:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Apr 2002 15:21:48 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-517192 ] 2.0.8 borks on dot in local part of addr Message-ID: Bugs item #517192, was opened at 2002-02-13 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=517192&group_id=103 Category: mail delivery Group: 2.0.x >Status: Open Resolution: Out of Date Priority: 5 Submitted By: CrackMonkey (monkeymaster) Assigned to: Nobody/Anonymous (nobody) Summary: 2.0.8 borks on dot in local part of addr Initial Comment: In a mail address's local part (the part to the left of the at sign), it is perfectly valid to have periods. However, mailman stops reading the address right at the @, so that "mr.bad@pigdog.org" is shown as "mr.bad". this is disastrous for lists where only subscribers are allowed to post, since the system doesn't allow for exceptions that lack an @ and a FQDN. Either allowing exceptions to be of a more forgiving format, or fixing the broken regex that truncates the mail addresses would solve my problem. I'm getting tired of moderating a legitimate user's posts, especially since the system won't even send the warnings to the correct address. ---------------------------------------------------------------------- >Comment By: CrackMonkey (monkeymaster) Date: 2002-04-29 15:21 Message: Logged In: YES user_id=76237 This happens even when I use python 2.2 ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-04-27 09:34 Message: Logged In: YES user_id=12800 This is really a bug with earlier versions of Python, I believe. MM2.0.x uses the standard library function rfc822.parseaddr() to break and address into its realname + email constituent parts. Here are some examples: % python Python 2.2.1 (#1, Apr 22 2002, 17:14:12) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from rfc822 import parseaddr >>> parseaddr('Mr. Bad ') ('Mr. Bad', 'mr.bad@pigdog.org') % python2.1 Python 2.1.3 (#1, Apr 22 2002, 18:17:38) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from rfc822 import parseaddr >>> parseaddr('Mr. Bad ') ('', 'Mr.Bad') So this is clearly broken in Python 2.1.3, and works in Python 2.2.1. I'll look at backporting the fix to Python 2.1 in case there's ever a 2.1.4. But if you're using an earlier version of Python, this will still be broken. Consider upgrading to Python 2.2.1. ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-04-26 12:54 Message: Logged In: YES user_id=76237 The bug turns out not to be when there is a period in the address, but in the plain text name. The mail address in question is: Mr. Bad I realized this when I saw people who had different text names from their e-mail addresses, as in: Jr. Pickle This would show up as the mythical address "jr.pickle" in mailman, and things would b0rk. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-03-14 11:18 Message: Logged In: YES user_id=12800 Either I need more information, or this problem is fixed in MM2.1. Quite often I uses test addresses like "barry.warsaw@" and I've had no problems with it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=517192&group_id=103 From noreply@sourceforge.net Tue Apr 30 08:58:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Apr 2002 00:58:17 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-550524 ] archiving with invalid dates Message-ID: Bugs item #550524, was opened at 2002-04-30 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550524&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Kallas (valshaq) Assigned to: Nobody/Anonymous (nobody) Summary: archiving with invalid dates Initial Comment: If you look at http://mail.gnu.org/mailman/listinfo/help-hurd you'll notice there are mails archived into future archives (because of faked timestamps). I think this should not happen, either deleting it instead (SPAM) or archiving it into the current archive. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550524&group_id=103 From noreply@sourceforge.net Tue Apr 30 02:53:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Apr 2002 18:53:53 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-550462 ] New feature: Automoderate microsoft user Message-ID: Bugs item #550462, was opened at 2002-04-29 21:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550462&group_id=103 Category: (un)subscribing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Mark Whitis (whitis) Assigned to: Nobody/Anonymous (nobody) Summary: New feature: Automoderate microsoft user Initial Comment: I am not using mailman at the moment but I was looking at its feature list and planned upgrades and found this missing. And it could be added in a very general form that could support many other uses. Reason for suggesting: everytime I post a message on a Linux list, I get a bunch of virus messages from bozos who have subscribed to those lists from a windows box. And I am certainly not alone in that respect. Usually these messages do not arrive via the list but are sent to anyone who posts to the list (often by lurkers). Users of real operating systems who subscribe to lists related to those should not be inconvinienced by those who use microsoft products, there of all places. I would like to suggest that future versions of Mailman include a feature (selected by the moderator) which automatically takes certain actions based on the subscibers email client. This feature could be activated based on the message headers in the replies to subscription confirmation messages. Actions could include: - Placing the user in moderated status (prevents sending virus to the list directly but doesn't prevent the virus from getting addresses from the user). - Cancelling the subscription - Sending a warning message to the user - Requiring the user to send a control message agreeing that their virus software will be kept up to date. - hide or mung all email addresses in copies of messages delivered to this user so email worms/viruses cannot harvest them. The email client status could be updated when the user sends a new control message. Optionally, it could also detect microsoft platforms via the browser ID when people sign on via the web site. Detection could be controlled by a configuration file listing with four fields: action, mail/web, field, and regex: ACCEPT MAIL X-Mailer .*Microsoft Sucks.* REJECT MAIL X-Mailer .*Microsoft Outlook.* REJECT MAIL X-Mimeole .*Microsoft Exchange.* REJECT WEB Browser-ID .*Internet Explorer.* (note: this would be triggered by opera in identify as Internet Explorer mode, but the user can switch to identify as opera). REJECT WEB Browser-ID .*Windows 95.* REJECT WEB Browser-ID .*Windows 98.* REJECT WEB Browser-ID .*Windows NT.* REJECT WEB Browser-ID .*Windows ME.* REJECT WEB Browser-ID .*Windows 2000.* REJECT WEB Browser-ID .*Win16.* REJECT WEB Browser-ID .*Win32.* REJECT WEB Browser-ID .*MSIE.* If you place someone on moderated status based on their mail client or web browser, the reason for moderation should be noted so that they can be automatically un-moderated (if otherwise consistent with policy) when they use a real computer to access the list. This feature could also be used to protect some protection against other problems, as well. Spam, REJECT MAIL From .*hotmail.com.* REJECT MAIL Subject: .*casino.* REJECT ATTACH Content-Type: application/octet-stream REJECT ATTACH Content-Type: audio/x-wav REJECT ATTACH Content-Type: audio/x-midi REJECT BODY "insurance" MODERATE-MSG BODY "profaneword" The config file could be XMLized: Possible Extensions: action: make "actions" instead and allow a comma separated list (or even nested XML action tags) moderate-msg moderate-user unmoderate-user strip-attachments strip-attachment bounce-message append-boilerplate source: comma separated list WEB_POST, WEB_CONTROL, MAIL_POST, MAIL_CONTROL, POST_BODY, POST_ATTACHMENT_HDR, POST_ATTACHMENT_BODY. blacklist: added field. .rss.mail-abuse.org .dul-mail-abuse.org Note that for the Dial Up list, this should only be applied to the first Received line added by the mail server itself. user-status: the users existing status (normal, moderated, moderated-newbie, moderated-badsoftware, trusted, moderator, list_owner, etc.) could be considered in applying filters. XML structure could be much more complicated, as well. One could also allow a user so detected to subscribe only after they had pledged to keep their virus checker up to date by sending a special control message or visiting a special web page. This could also be used to filter certain types of spam that have consistent patterns. I have seen the same websites repeately spammed to the same list (until I blew those websites away) from different aliases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=550462&group_id=103