From claw@kanga.nu Tue May 1 00:59:14 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 30 Apr 2001 16:59:14 -0700 Subject: [Mailman-Developers] Delivering messages to scripts/post In-Reply-To: Message from Jesper Jensen of "Tue, 01 May 2001 00:54:39 +0200." <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <2079.988675154@kanga.nu> On Tue, 01 May 2001 00:54:39 +0200 Jesper Jensen wrote: > I fully understand and respect that this is a Linux project... Actually its a GNU project, which is not at all Linux specific. Mailman in its current incarnation is Unix-centric in a number of ways (which subtley different from Linux-centric), but that is mainly due to the majority of the developers (and thus the users) having Unix as their preferred (server) platform. > We chaned to Mailman because we needed some things LISTSERV didn't > have. Like what? (might as well pump up our strengths) -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From barry@digicool.com Tue May 1 04:42:27 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 30 Apr 2001 23:42:27 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> Message-ID: <15086.12451.92841.383891@anthem.wooz.org> >>>>> "F" == Fil writes: F> "When sent" is the default. How do you change the default to F> "When Resent"? Shouldn't it be changed in the mailman's F> Defaults.py ? >>>>> "MM" == Marc MERLIN writes: MM> I very firmly believe this, and so do all the people who have MM> archives showing messages with dates of 2004 or 1990. MM> http://lists.svlug.org/pipermail/svlug/ MM> I've asked the same thing in the past, but it didn't go MM> through. We've talked in the past of adding an option to clobber_date to only munge dates when they're outrageous. This turns out to be easy to do, and I'm willing to add it for 2.1 (I'm hacking the code right now). However, it seems to me that this really ought to be a site-wide configuration instead of a list-specific configuration. I don't see a whole lot of value in allowing lists to individually clobber the dates. I see this as going hand-in-hand with external archiving; e.g. you may not want to clober the date if you're using an external archiver, because perhaps it performs its /own/ sanity checks on the Date: header. So my proposal is to - get rid of clobber_date as a list-specific variable - add a site variable ARCHIVER_CLOBBER_DATE_POLICY which takes one of three values: 0 (never override the original message's Date: header); 1 (always override the original message's Date: header with the `processed' date); 2 (only override the header if the date is outrageous). - add a site variable ARCHIVER_ALLOWABLE_SANE_DATE_SKEW which specifies a time in seconds outside of which the Date will be considered outrageous (i.e if its either too early or too late). Comments? -Barry From barry@digicool.com Tue May 1 04:46:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 30 Apr 2001 23:46:16 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> Message-ID: <15086.12680.151445.182210@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> So my proposal is to BAW> - get rid of clobber_date as a list-specific variable BAW> - add a site variable ARCHIVER_CLOBBER_DATE_POLICY which BAW> - add a site variable ARCHIVER_ALLOWABLE_SANE_DATE_SKEW which Oh yeah, the defaults would be ARCHIVER_CLOBBER_DATE_POLICY = 2 ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) so if the message had a Date: header earlier or later than 90 days from now, it would get the header overridden. Note that this munging happens before the message is handed to the archiver, and it occurs regardless of whether Pipermail or an external archiver handles it. The original Date: header will be put on X-Original-Date (does that need to be configurable?) -Barry From wilane@MINT.SN Tue May 1 05:14:40 2001 From: wilane@MINT.SN (Ousmane Wilane) Date: Tue, 1 May 2001 04:14:40 +0000 (GMT) Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.12680.151445.182210@anthem.wooz.org> Message-ID: On Mon, 30 Apr 2001, Barry A. Warsaw wrote: So far so good as usual! BAW>ARCHIVER_CLOBBER_DATE_POLICY = 2 BAW>ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) IMHO 90 It's too long as default! Why? O. W. Kind regards. From jra@baylink.com Tue May 1 05:19:54 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 00:19:54 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <20010430154146.C32211@magic.merlins.org>; from Marc MERLIN on Mon, Apr 30, 2001 at 03:41:46PM -0700 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> Message-ID: <20010501001954.24484@scfn.thpl.lib.fl.us> On Mon, Apr 30, 2001 at 03:41:46PM -0700, Marc MERLIN wrote: > > "When sent" is the default. How do you change the default to "When Resent"? > > Shouldn't it be changed in the mailman's Defaults.py ? > > I very firmly believe this, and so do all the people who have archives > showing messages with dates of 2004 or 1990. > http://lists.svlug.org/pipermail/svlug/ > > I've asked the same thing in the past, but it didn't go through. > Please? :-) Concur, FWIW. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 05:20:38 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:20:38 -0400 Subject: [Mailman-Developers] Delivering messages to scripts/post References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <15086.14742.421568.853743@anthem.wooz.org> >>>>> "JJ" == Jesper Jensen writes: JJ> We have been running Mailman on Windows for about two weeks JJ> now and most things seem to work very well. Very cool! JJ> To make it run I had to make some changes - all of them minor JJ> - and most of them related to opening files ('b'). Ah yes. That and pre-unlinking (i.e. unlinking a file you have open because you know it will go away when the file is closed) are two Unixisms that often bite me when porting Python code to Windows. I try to be good, but old habits die hard. ;) JJ> Mailmanwin (as I have named it) is probably not useful for JJ> anyone but me (and my company) right now; some things do not JJ> work at all (web interface, e-mail archive, usenet gateway, JJ> all the bin scripts) and some things are changed to make them JJ> better fit my needs. What version of Mailman are you running? I'd be interested in looking at any patches that help port Mailman to Windows (or any other platform for that matter). I develop on Linux these days, and before leaving CNRI, primarily Solaris. I'm fairly confident Mailman runs on any (sane :) Unix-like OS, and I have nothing philosophical against porting Mailman to any platform that Python runs on -- and that's a lot of platforms. But I don't have much time to do that work myself, so such porting necessarily relies on contributions from others. JJ> I have made an "install" script doing all the work and JJ> describing all the changes, so it's fairly easy getting JJ> started. I hope to get a webpage up with these things soon. When you're ready to submit patches, please upload them to SourceForge. I've created a new patch category called "cross platform". JJ> I don't expect the mailman developers to take account of any JJ> of these changes. I fully understand and respect that this is JJ> a Linux project and would hate if cross platform issues in any JJ> way affected the future direction of Mailman. Having said JJ> that, it would be nice if no module names conflicted with JJ> modules in the standard Python distribution (mailbox) ;) This should actually be better for Python 2.1 since the case-sensitivity on imports for case-preserving case-insensitive file systems (e.g. Windows) has been greatly improved (I've been told). I thought about renaming Mailbox.py, but that's a PITA because I don't want to lose the CVS history and renaming-retaining-history can't be done without access to the CVS repository. I'll probably just require MacOSX and Cygwin (and Windows :) users to use to Python 2.1. Everyone else should be fine with Python 2.0 or 2.1. JJ> 1. Delivering messages to scripts/post I could not find any JJ> MTA for Windows (I didn't look much, though) that was able to JJ> get the toaddr and deliver the message to scripts/post. JJ> Instead we are using L-soft LSMTP (we used L-soft LISTSERV JJ> before changing to Mailman). LSMTP is told to save all JJ> messages (complete with all envelope header information) and I JJ> have made a Python script that parses each message and calls JJ> Enqueu with the correct parameters. JJ> This works well, except that we have had a couple of mail JJ> loops because of auto-responders replying directly to the JJ> list. So my question is, what information does a MTA look for JJ> before passing the message to post? In the usual Unix MTA world, nothing, it's a dumb pipe. Mailman itself looks at the incoming message for X-BeenThere headers and raises a LoopError if it finds one that matches the list address. There's no guarantee that'll be preserved during the loop though, and in that case there isn't much that can be done. JJ> I found out that filtering out all messages with daemon and/or JJ> postmaster in the fromaddr is a good idea. Are there any JJ> other "keywords" that i should know of? You might look at LIKELY_BOUNCE_SENDERS in Defaults.py, which includes mailer-daemon, orphanage, and postoffice though I can't personally remember ever seeing bounce message originate from the latter two. JJ> 2. Empty envelope fromaddr In some messages the envelope JJ> fromaddr is empty. Is it safe to never deliver a message with JJ> an empty envelope fromaddr to a list? I've no idea, since I don't know why for you the From_ header is missing sometimes. JJ> 3. Using the envelope fromaddr or the message fromaddr I can JJ> see that this is a Mailman setting. What are the consequences JJ> of using only the envelope fromaddr? In practice, you'll get a lot more holds if you limit postings to members only. While the From: header is easily spoofable, it turns out to be a much greater PITA to use the From_ header (which itself isn't that hard to spoof). JJ> Just for the record. L-soft LISTSERV is a great product - the JJ> most solid/stable I have ever used. We chaned to Mailman JJ> because we needed some things LISTSERV didn't have. Cool! If you have the time, perhaps you can post a list of things you like about LISTSERV that Mailman doesn't have, and vice versa. -Barry From jra@baylink.com Tue May 1 05:21:20 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 00:21:20 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.12680.151445.182210@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Apr 30, 2001 at 11:46:16PM -0400 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> Message-ID: <20010501002120.33084@scfn.thpl.lib.fl.us> On Mon, Apr 30, 2001 at 11:46:16PM -0400, Barry A. Warsaw wrote: > >>>>> "BAW" == Barry A Warsaw writes: > BAW> So my proposal is to > BAW> - get rid of clobber_date as a list-specific variable > BAW> - add a site variable ARCHIVER_CLOBBER_DATE_POLICY which > BAW> - add a site variable ARCHIVER_ALLOWABLE_SANE_DATE_SKEW which > Oh yeah, the defaults would be > ARCHIVER_CLOBBER_DATE_POLICY = 2 > ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) > so if the message had a Date: header earlier or later than 90 days > from now, it would get the header overridden. Note that this munging > happens before the message is handed to the archiver, and it occurs > regardless of whether Pipermail or an external archiver handles it. > The original Date: header will be put on X-Original-Date (does that > need to be configurable?) That sounds good to me, although, as someone noted, perhaps 90 days is a bit long. Did you pull that number out of your butt, or was there a specific motivation for it? Cheers. - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 05:24:55 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:24:55 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <15086.12680.151445.182210@anthem.wooz.org> Message-ID: <15086.14999.492269.256070@anthem.wooz.org> >>>>> "OW" == Ousmane Wilane writes: OW> So far so good as usual! Thanks! BAW> ARCHIVER_CLOBBER_DATE_POLICY = 2 BAW> ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) OW> IMHO 90 It's too long as default! Why? I figure most of the outrageous headers are something on the order of /years/ away, and I just picked 90 days out of a hat. I think it ought to be greater than the average retry interval in case a Mailman site is unavailable for a few days. So, suggest something more reasonable in between 5 and 90 days! :) -Barry From barry@digicool.com Tue May 1 05:27:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:27:16 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> Message-ID: <15086.15140.661323.198609@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> That sounds good to me, although, as someone noted, perhaps JRA> 90 days is a bit long. Did you pull that number out of your JRA> butt, or was there a specific motivation for it? See my other message. Although I'd like to think that my brain's located a little higher up in my anatomy , you're not far off. -Barry From otaylor@redhat.com Tue May 1 05:32:23 2001 From: otaylor@redhat.com (Owen Taylor) Date: 01 May 2001 00:32:23 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: Marc MERLIN's message of "Mon, 30 Apr 2001 15:41:46 -0700" References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> Message-ID: Marc MERLIN writes: > On Mon, Apr 30, 2001 at 09:28:51PM +0200, Fil wrote: > > @ Darrell Fuhriman (darrell@grumblesmurf.net) : > > > That's why under "archival options" you'll find: > > > > > > "Set date in archive to when the mail is claimed to have been > > > sent, or to the time we resend it?" > > > > > > If you leave it on 'when sent', you deserve the mess you'll get > > > in your archives. > > > > "When sent" is the default. How do you change the default to "When Resent"? > > Shouldn't it be changed in the mailman's Defaults.py ? > > I very firmly believe this, and so do all the people who have archives > showing messages with dates of 2004 or 1990. > http://lists.svlug.org/pipermail/svlug/ > > I've asked the same thing in the past, but it didn't go through. What I did for the gnome.org archives (using mhonarc plus custom perl) is to used the Received: header for the date. Which is, almost always, quite close to the time the person actually sent it, and assuming that your local server's time isn't screwed up (which is a much bigger problem...) does not have the 2004 problem. And it has the advantage over clobber_date of: - Not munging the mail - Not being skewed by moderation delays - Being independent of the archiving process, so if you import a bunch of old mail with incorrect Date: lines into the archiving process you still get the 2004 protection. I haven't looked at the clobber_date implementation recently, so I don't know if these problems have been otherwise addressed. This approach has, anyways, worked well for the 140k messages on mail.gnome.org. I wouldn't be suprised if it has defects though. Regards, Owen From jra@baylink.com Tue May 1 05:52:00 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 00:52:00 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.15140.661323.198609@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 12:27:16AM -0400 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> Message-ID: <20010501005200.43574@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 12:27:16AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> That sounds good to me, although, as someone noted, perhaps > JRA> 90 days is a bit long. Did you pull that number out of your > JRA> butt, or was there a specific motivation for it? > > See my other message. Although I'd like to think that my brain's > located a little higher up in my anatomy , you're not far off. Well, the implication was that your brain wasn't involved in the thing. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 05:57:45 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:57:45 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> Message-ID: <15086.16969.185480.230418@anthem.wooz.org> >>>>> "OT" == Owen Taylor writes: OT> What I did for the gnome.org archives (using mhonarc plus OT> custom perl) is to used the Received: header for the date. Ah, but which one? :) There's going to have a Received: header for each hop that message takes. By the time your message got to me, it had 7 Received: headers, and 3 (I think) by the time it reached Mailman. OT> Which is, almost always, quite close to the time the person OT> actually sent it, and assuming that your local server's time OT> isn't screwed up (which is a much bigger problem...) does OT> not have the 2004 problem. OT> And it has the advantage over clobber_date of: | - Not munging the mail True, with the disadvantage that if you use an external archiver, it'll have to handle checking for outrageous dates. clobber_date munges the message before it hits either archiver (Pipermail or external). If I was smart, I'd also count as a major disadvantage the fact that I'll have to track down all the places where the Date: header is used in Pipermail, and I /hate/ diving in that code. ;( | - Not being skewed by moderation delays Dang, yep, but fixable. | - Being independent of the archiving process, so if you | import a bunch of old mail with incorrect Date: lines | into the archiving process you still get the 2004 | protection. True, with the caveat above. This would be a reasonable option, however if you use the most recent Received: header, won't you still be subject to local server clock skew? And if you use the earliest Received: you'll be subject to the same bogosity in the Date: header. Or do you just start parsing the Received:'s back from the most recent and take the first sane one you find? -Barry From barry@digicool.com Tue May 1 06:00:14 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 01:00:14 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> Message-ID: <15086.17118.430487.160237@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Well, the implication was that your brain wasn't involved in JRA> the thing. Ah some new entries for my X-Oblique-Strategy file: Trust the Butt The Butt Knows Best When in Doubt, ButtThink ? :) -Barry From jra@baylink.com Tue May 1 06:01:45 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 01:01:45 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.17118.430487.160237@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 01:00:14AM -0400 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> Message-ID: <20010501010145.48432@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 01:00:14AM -0400, Barry A. Warsaw wrote: > Ah some new entries for my X-Oblique-Strategy file: > Trust the Butt > The Butt Knows Best > When in Doubt, ButtThink Use the farts, Luke. or, alternatively: Luke... *I* am your farter. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 06:04:34 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 01:04:34 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> Message-ID: <15086.17378.261384.350847@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Use the farts, Luke. JRA> or, alternatively: JRA> Luke... *I* am your farter. Ah, that's the spirit! Mailman's new motto: The Better Smelling List Server -Barry From thomas@xs4all.net Tue May 1 09:35:26 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 1 May 2001 10:35:26 +0200 Subject: [Mailman-Developers] Small nntp server? In-Reply-To: ; from din5w@cs.virginia.edu on Fri, Apr 27, 2001 at 10:03:05AM -0400 References: <15080.56527.608668.936637@anthem.wooz.org> Message-ID: <20010501103526.N16486@xs4all.nl> On Fri, Apr 27, 2001 at 10:03:05AM -0400, Dale Newfield wrote: > Does anyone have a (free?) unix based nntp server they'd suggest that can > be configured to be stand-alone (no pushing upstream or downstream), and > would handle 10's of local newsgroups and ~1000 subscribers reasonably > well? You can try both INN (http://www.isc.org/inn.html) and Diablo (http://www.openusenet.org/diablo/), though I'd suggest using Diablo. Both are free, but they aren't terribly easy to configure. You can definately tell them not to feed up/downstream, though. Diablo has a very active userbase, but INN's older and probably still larger. You're likely to find good FAQs and HOWTO's for both. > We're running a FreeBSD box if that matters. Well, at XS4ALL we run a news setup of 10+ machines, all running Diablo on FreeBSD, and they do it very, very well. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Tue May 1 09:39:56 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 1 May 2001 10:39:56 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010428123324.A1102@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 28, 2001 at 12:33:24PM +0200 References: <20010428123324.A1102@rix.rixhq.nu> Message-ID: <20010501103956.O16486@xs4all.nl> On Sat, Apr 28, 2001 at 12:33:24PM +0200, Ricardo Kustner wrote: > Anyway my point is that now I'm getting some complaints from members about > receiving empty digests (it only says the number of posts which should be in > there) I'm not sure yet what they are missing but I was wondering if I > could have messed things about by interrupting the process w/o a m.Save()? > When I look up the subscription options for one of the members who > complained I don't see anything weird in there... Did you exit the withlist between the two tries ? You might have screwed up one (1) of the subscribers, but definately not more of them. If you exited the withlist without doing m.Save(), nothing happened because of it. If you didn't exit, but re-did the for loop, the changes you'd made would have been saved by the m.Save() at the end, but most of those people would've been set to digest. Only the one that was being processed when you pressed ^C *might* be screwed up. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Tue May 1 09:41:21 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 1 May 2001 10:41:21 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010428132341.C1102@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 28, 2001 at 01:23:41PM +0200 References: <20010428123324.A1102@rix.rixhq.nu> <20010428132341.C1102@rix.rixhq.nu> Message-ID: <20010501104121.P16486@xs4all.nl> On Sat, Apr 28, 2001 at 01:23:41PM +0200, Ricardo Kustner wrote: > On Sat, Apr 28, 2001 at 12:33:24PM +0200, Ricardo Kustner wrote: > > Anyway my point is that now I'm getting some complaints from members about > > receiving empty digests (it only says the number of posts which should be in > > there) I'm not sure yet what they are missing but I was wondering if I > > could have messed things about by interrupting the process w/o a m.Save()? > uh oh please don't tell me that when mailman sends out digests, they travel through the > /etc/aliases addresses cause that would mean a neat little perl script I > use filters out the MIME digests... :( [I really need this script to keep > the digests clean from garbage)... hmm on the other hand it could also be > that the digests are handled directly by qrunner so they won't go through > the filter so that wouldn't explain the problems... It depends on the delivery method you chose. If you use the Sendmail module, it'll probably pass it through /etc/aliases. If you use the SMTP module and the localhost as delivery point, it'll pass through /etc/aliases too. It's damned easy to test, though: disable the filter, make a new digest list, subscribe yourself to it, and mail ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@digicool.com Tue May 1 10:13:05 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 05:13:05 -0400 Subject: [Mailman-Developers] empty digests References: <20010428123324.A1102@rix.rixhq.nu> Message-ID: <15086.32289.681349.341063@anthem.wooz.org> >>>>> "RK" == Ricardo Kustner writes: RK> This took a really long time (1635 regular subscribers) and RK> after about 20 minutes I decided to press Ctrl-C cause I was RK> afraid it hung somewhow... this means I wasn't able to do a RK> m.Save() but after checking the number of subscriber was RK> reduced to about 60 so appearantly it did work out... The reason why it took so long, /and/ the reason why most of your subscribers actually got digestered is the same: SetUserDigest() does a self.Save() after each call. As Thomas says, the worst that you could have done would be to mess up one subscriber (the one you ^C'd), but even there, you likely would have only reverted the change in that subscriber's option. I don't see how that could cause empty digests though. Now, one question is whether SetUserDigest() should do a Save() after each call. I think in all normal usage, SetUserDigest() will be wrapped in a try/finally to ensure that the list is saved. OTOH, there probably isn't any CGI way to set more than about 30 subscribers options, and even then, I'll bet the typical case sets only one or a small few, so the extra writes don't hurt too badly. That's not the case in withlist. First, you're using it to mass configure lots of users so the extra writes are killing you. But then again, it made most of your changes go through. I'm inclined to ditch the Save() at the end of SetUserDigest() at the expense of losing your changes if you quit withlist with unsaved changes. >>>>> "RK" == Ricardo Kustner writes: RK> uh oh please don't tell me that when mailman sends out RK> digests, they travel through the /etc/aliases addresses cause RK> that would mean a neat little perl script I use filters out RK> the MIME digests... :( [I really need this script to keep the RK> digests clean from garbage)... This would be my first suspicion (and not just 'cause it's perl )! The empty digests, are they MIME digests? If plain text, maybe they're still tripping up your script. Thomas outlines a good plan of first attack! -Barry From tollef@add.no Tue May 1 11:21:53 2001 From: tollef@add.no (Tollef Fog Heen) Date: 01 May 2001 12:21:53 +0200 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.14999.492269.256070@anthem.wooz.org> References: <15086.12680.151445.182210@anthem.wooz.org> <15086.14999.492269.256070@anthem.wooz.org> Message-ID: <87d79t2wu6.fsf@arabella.intern.opera.no> * (Barry A. Warsaw) | So, suggest something more reasonable in between 5 and 90 days! :) A week, or maximum 30 days. IMHO. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. (and please stop using the DUL, it's broken) From otaylor@redhat.com Tue May 1 14:00:06 2001 From: otaylor@redhat.com (Owen Taylor) Date: 01 May 2001 09:00:06 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: barry@digicool.com's message of "Tue, 1 May 2001 00:57:45 -0400" References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> <15086.16969.185480.230418@anthem.wooz.org> Message-ID: barry@digicool.com (Barry A. Warsaw) writes: > >>>>> "OT" == Owen Taylor writes: > > OT> What I did for the gnome.org archives (using mhonarc plus > OT> custom perl) is to used the Received: header for the date. > > Ah, but which one? :) There's going to have a Received: header for > each hop that message takes. By the time your message got to me, it > had 7 Received: headers, and 3 (I think) by the time it reached > Mailman. The most recent. So you'll only get the wrong date if clobber_data would also get it wrong; people will tell you pretty quickly if your mail server has an incorrect clock. > OT> Which is, almost always, quite close to the time the person > OT> actually sent it, and assuming that your local server's time > OT> isn't screwed up (which is a much bigger problem...) does > OT> not have the 2004 problem. > > OT> And it has the advantage over clobber_date of: > > | - Not munging the mail > > True, with the disadvantage that if you use an external archiver, > it'll have to handle checking for outrageous dates. clobber_date > munges the message before it hits either archiver (Pipermail or > external). I guess I'd consider getting the date right to be the concern of the archiver, not of the system feeding to the archiver - after all, its pretty common to also want to feed a chunk of old pre-mailman archives into an archiver along with the mailman ones. > If I was smart, I'd also count as a major disadvantage the > fact that I'll have to track down all the places where the Date: > header is used in Pipermail, and I /hate/ diving in that code. ;( Yeah, there are always practical concerns ;-) > | - Not being skewed by moderation delays > > Dang, yep, but fixable. > > | - Being independent of the archiving process, so if you > | import a bunch of old mail with incorrect Date: lines > | into the archiving process you still get the 2004 > | protection. > > True, with the caveat above. > > This would be a reasonable option, however if you use the most recent > Received: header, won't you still be subject to local server clock > skew? And if you use the earliest Received: you'll be subject to the > same bogosity in the Date: header. Or do you just start parsing the > Received:'s back from the most recent and take the first sane one you > find? As mentioned above, local server clock breakage isn't really something I worry about; my concern with the clobber_date method wasn't that the local clock could be wrong, but rather, that it was discarding information from the message headers and replacing it with the current time, which, in some circumstances could be significantly different. Also, I did actually have a lot of old mail with bogus Date: fields that I was importing... Regards, Owen From jra@baylink.com Tue May 1 15:04:44 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 10:04:44 -0400 Subject: [Mailman-Developers] empty digests In-Reply-To: <15086.32289.681349.341063@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 05:13:05AM -0400 References: <20010428123324.A1102@rix.rixhq.nu> <15086.32289.681349.341063@anthem.wooz.org> Message-ID: <20010501100444.25644@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 05:13:05AM -0400, Barry A. Warsaw wrote: > That's not the case in withlist. First, you're using it to mass > configure lots of users so the extra writes are killing you. But then > again, it made most of your changes go through. I'm inclined to ditch > the Save() at the end of SetUserDigest() at the expense of losing your > changes if you quit withlist with unsaved changes. I contend that that is a feature, not a bug. How would you 'undo', otherwise? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jarrell@vt.edu Tue May 1 15:35:37 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 01 May 2001 10:35:37 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.17378.261384.350847@anthem.wooz.org> References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010501103457.030d3b70@vtserf.cc.vt.edu> At 01:04 AM 5/1/01 -0400, Barry A. Warsaw wrote: >>>>>> "JRA" == Jay R Ashworth writes: > > JRA> Use the farts, Luke. > > JRA> or, alternatively: > > JRA> Luke... *I* am your farter. > >Ah, that's the spirit! > >Mailman's new motto: The Better Smelling List Server Barry Warsaw: The Man Who's Thoughts You Can Light.... (ducking and running very, very fast...) From barry@digicool.com Tue May 1 17:49:59 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 12:49:59 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> <5.1.0.14.2.20010501103457.030d3b70@vtserf.cc.vt.edu> Message-ID: <15086.59703.811837.444953@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Barry Warsaw: The Man Who's Thoughts You Can Light.... LOL! From jarrell@vt.edu Tue May 1 17:50:30 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 01 May 2001 12:50:30 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <5.1.0.14.2.20010501103457.030d3b70@vtserf.cc.vt.edu> References: <15086.17378.261384.350847@anthem.wooz.org> <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010501124910.03412e20@vtserf.cc.vt.edu> At 10:35 AM 5/1/01 -0400, Ron Jarrell wrote: >Barry Warsaw: The Man Who's Thoughts You Can Light.... > >(ducking and running very, very fast...) (Also using grammar very, very poorly... The things that come out of your fingers when you actually do know better. Sheesh.) From dan.mick@west.sun.com Tue May 1 20:23:01 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 12:23:01 -0700 Subject: [Mailman-Developers] Dates Message-ID: <3AEF0D15.1258875E@west.sun.com> Personally, I want the date in the Date header to be the one that shows up. I don't care when it got to the list server, finally; I care when it was sent. If the sender is too stupid to set up his machine, I want to know that, too. From jra@baylink.com Tue May 1 20:27:11 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 15:27:11 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF0D15.1258875E@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 12:23:01PM -0700 References: <3AEF0D15.1258875E@west.sun.com> Message-ID: <20010501152711.58471@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 12:23:01PM -0700, Dan Mick wrote: > Personally, I want the date in the Date header to be the one that > shows up. I don't care when it got to the list server, finally; I care > when it was sent. If the sender is too stupid to set up his machine, I > want to know that, too. It's possible, Dan, that you might have missed the fact that what's being discussed (unless *I* missed something big :-) is *what date the message is _archived_ as*... and that the original sent date is preserved in the archive. I don't think -- Barry will no doubt forrect me if my short term memory has gone completely to hell -- that he was rewriting dates on *mailed* messages... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 21:40:42 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 16:40:42 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <009c01c0cf5b$3165c2a0$01000001@sgergo.hu> <01042715193211.08359@graham.localdomain> Message-ID: <15087.8010.821127.647320@anthem.wooz.org> I'm CC'ing Mailman developers because I want to get some feedback from the Unix hackers amonst us; apologies for duplicates... >> We also experienced similar problems in the past with large >> lists. We found that if the admin is accessing the long and >> slow-loading members admin pages, and does not wait for the >> page to complete (e.g. clicks one of the admin links or hits >> refresh or stop) the lock will remain. As a temporary solution >> we have instructed our admins to wait for all pages to >> completely load, no stale locks since then. This is on a Cobalt >> RaQ4i (Redhat) with Apache 1.3x. Hope this helps, >>>>> "GT" == Graham TerMarsch writes: GT> Is probably related to what we're experiencing, but I'm GT> finding that even just due to the volume of hits on the GT> "subscribe" page, that we're having this problem. While GT> testing, I made sure that we had _no_ accesses to admin pages, GT> and that all of the "subscribe" hits that were coming through GT> waited for the complete response and didn't time out or have GT> the "stop" button pressed. Even in this scenario, I still GT> ended up with stale locks lingering around. [...] GT> Would it be correct to say that if the CGI process dies for GT> some unforseen reason (e.g. Apache kills it off because the GT> user pressed the "stop" button or the HTTP connection timed GT> out), that the lock from that process gets left around as a GT> lingering lock? After an all night hacking jag, lots of google searches, a re-read of Stevens Ch.10, and a short conversation with Guido, I believe I know what's going on. That's the good news. The bad news is that I don't think there's a perfect solution, but there probably is a better solution. FTR, here's my development environment: Apache 1.3.19, Python 2.1, RH6.2-ish, kernel 2.2.18, NS 4.74, and the current Mailman 2.1 CVS snapshot. Here's what I did: I loaded up a list with 60000 subscribers, then went to the members page. It did indeed take a long time, and if I let it run to completion, I get the page as expected and no locks. However, if I hit the stop button before the page is finished loading, I can see that the CGI process continues to run for a while and then it may or may not clear the locks. The page is not complete. Since sometimes the locks are cleared and sometimes they're left, it's pretty clear there are race conditions involved. I did a bit of web searching and here's what I think a stock Apache mod_cgi is supposed to do in this situation: - The user hits the stop button on the browser. The client will close the socket, which is usually eventually recognized by the server. - The cgi script meanwhile is merrily doing some long calculations, and eventually it will try to write output. It's at this point that it may be possible to detect that the socket has gone away. What's interesting is that it appears that the cgi script actually writes output to the parent Apache process, which perhaps buffers the output before sending to the client. In any event, it's the Apache parent process that gets a SIGPIPE indicating the socket it's writing to is closed. - Apache catches the SIGPIPE, turns around and sends a SIGTERM to the cgi process. Apache waits three seconds and if the cgi hasn't exited yet, it sends a SIGKILL. The default behavior for SIGTERM is to terminate the process, so whether it's the SIGTERM or SIGKILL that does the dirty work, in the end, the naive cgi script can get summarily killed without a chance at clean up. Enter Python. Python installs a few of its own signal handlers, most notably for SIGINT which it maps to the KeyboardInterrupt exception. Normally though, SIGTERM isn't caught by Python, so again, the naive Python cgi script will summarily die when receiving a SIGTERM. Under mod_cgi, even catching SIGTERM may not help if more than 3 seconds of processing occurs (I don't know if this is clock time or cpu time). Again, that's because Apache turns around and SIGKILLs the cgi, and that signal can't be caught (remember, this is what bit us a while back w.r.t. Postfix filter programs). So maybe the answer is to install a Python-level SIGTERM handler that will release the lock. To understand this, you need to know how Python handles signals. When you set a signal handler in Python, at the C level, Python installs its own signal handler, which simply sets a flag and returns. That's because Python will only run Python-level signal handlers in between bytecode boundaries. So your Python signal handler can get run at some arbitrary point in the future, and likely /not/ when the signal actually occurred. All this is very dodgy in the face of try/finally clauses, which is how cgi's like admin.py ensure that the mailing list is saved and unlocked when an exception occurs. For example, my initial solution was to install a signal handler that raised an exception, thinking that this would trigger the finally clause and do the normal save & unlock. But because of race conditions and interactions with the Python interpreter loop, I often saw that while the exception was getting raised, the finally clause wasn't always getting executed. Guido confirmed that this isn't a safe approach. So my next approach is to write a very minimal signal handler that only unlocks the list, and install this on SIGTERM. The trick is to make the signal handler, e.g. a nested function of main() in admin.py, and pass the MailList object into it using the default argument trick. This seems to work, in that the locks appear to be cleared in the cases where they were left laying around before. But because of all the race conditions, I can't be 100% sure. If you've read this far, the implication is that if the user hits the stop button, Mailman will in essence abort any changes to list configuration that this invocation may have made. Alternatively, we could try to save & unlock in the signal handler, but that raises the possibility of race conditions again. Also, it makes sense to move the save of the list data into the try: part of the clause and only do the unlocking in the finally. That way, the finally clause and the SIGTERM handler have the same semantics, and the list will get unlocked in the face of either an exception or a signal. But the list database will only get saved on sucessful completion of the task. I can live with those semantics (I think ;). So the code in admin.py looks something like: def main(): ... mlist = MailList.MailList(listname, lock=0) ... def sigterm_handler(signum, frame, mlist=mlist): mlist.Unlock() mlist.Lock() try: signal.signal(signal.SIGTERM, sigterm_handler) ... mlist.Save() finally: mlist.Unlock() I think there are still opportunities to get nailed, but I think this works as well as is possible. In my testing I've been able to clear the locks when the stop button is pushed. In the rare event that the list's config.db file gets corrupted (i.e. the handler gets called in the middle of mlist.Save()), we've always got the config.db.last file to fall back on. The other good news is that I think only admindb.py, admin.py, and confirm.py, need to be modified, since those are the only scripts that write to list attributes. I've been pretty diligent in Mailman 2.1 to only lock the mailing lists when necessary, so if the scripts are read-only, they don't acquire the lock (and get the state of the database as of the time of the initial Load()). Phew! -Barry From dan.mick@west.sun.com Tue May 1 22:27:46 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 14:27:46 -0700 Subject: [Mailman-Developers] Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> Message-ID: <3AEF2A52.A4C564B9@west.sun.com> "Jay R. Ashworth" wrote: > > On Tue, May 01, 2001 at 12:23:01PM -0700, Dan Mick wrote: > > Personally, I want the date in the Date header to be the one that > > shows up. I don't care when it got to the list server, finally; I care > > when it was sent. If the sender is too stupid to set up his machine, I > > want to know that, too. > > It's possible, Dan, that you might have missed the fact that what's > being discussed (unless *I* missed something big :-) is *what date the > message is _archived_ as*... and that the original sent date is > preserved in the archive. Right. But if it's archived as "today" when it was sent "yesterday", that's not the bahavior I would ever want, even if the Date: header is correct in the archive. > I don't think -- Barry will no doubt forrect > me if my short term memory has gone completely to hell -- that he was > rewriting dates on *mailed* messages... Right. I'm talking about the archiver too. I just wanted to point out that opinions differ. From jra@baylink.com Tue May 1 22:31:53 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 17:31:53 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF2A52.A4C564B9@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 02:27:46PM -0700 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> Message-ID: <20010501173153.19119@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 02:27:46PM -0700, Dan Mick wrote: > "Jay R. Ashworth" wrote: > > On Tue, May 01, 2001 at 12:23:01PM -0700, Dan Mick wrote: > > > Personally, I want the date in the Date header to be the one that > > > shows up. I don't care when it got to the list server, finally; I care > > > when it was sent. If the sender is too stupid to set up his machine, I > > > want to know that, too. > > > > It's possible, Dan, that you might have missed the fact that what's > > being discussed (unless *I* missed something big :-) is *what date the > > message is _archived_ as*... and that the original sent date is > > preserved in the archive. > > Right. But if it's archived as "today" when it was sent "yesterday", > that's not the bahavior I would ever want, even if the Date: header is > correct in the archive. Ok, but the situation we're discussing here is when it was sent yesterday, and received yesterday, but *dated* some time in 1982. Since the message will not contain *any* authoritative sent dates at that point, what protocol would you *suggest*, for having it archived as being sent yesterday, the way you'd like? > > I don't think -- Barry will no doubt forrect > > me if my short term memory has gone completely to hell -- that he was > > rewriting dates on *mailed* messages... > > Right. I'm talking about the archiver too. > I just wanted to point out that opinions differ. Certainly... but I don't necessarily see that you've posited a *solution*, just an opinion. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From dan.mick@west.sun.com Tue May 1 22:59:06 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 14:59:06 -0700 Subject: [Mailman-Developers] Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> Message-ID: <3AEF31AA.22A4CCBE@west.sun.com> > > Right. But if it's archived as "today" when it was sent "yesterday", > > that's not the bahavior I would ever want, even if the Date: header is > > correct in the archive. > > Ok, but the situation we're discussing here is when it was sent > yesterday, and received yesterday, but *dated* some time in 1982. > > Since the message will not contain *any* authoritative sent dates at > that point, I disagree. The authoritative date is the Date header which says 1982. That's what the sending mail program said, and I believe it. Just because its human is an ass doesn't change that. The human needs to be notified, sure. > what protocol would you *suggest*, for having it archived > as being sent yesterday, the way you'd like? That's my point: it's *not* the way I'd like. I'm not suggesting any protocol. The problem doesn't need any solution, for me. I'd suggest that the only two meaningful dates are: 1) Date: header 2) date/time of arrival at the archiver All else is sophistry. > > Right. I'm talking about the archiver too. > > I just wanted to point out that opinions differ. > > Certainly... but I don't necessarily see that you've posited a > *solution*, just an opinion. Who said anything about a solution? I started this thread, I think, by stating an opinion about the behavior I'd like. From jra@baylink.com Tue May 1 23:04:54 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 18:04:54 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF31AA.22A4CCBE@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 02:59:06PM -0700 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> Message-ID: <20010501180454.13332@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 02:59:06PM -0700, Dan Mick wrote: > > > Right. But if it's archived as "today" when it was sent "yesterday", > > > that's not the bahavior I would ever want, even if the Date: header is > > > correct in the archive. > > > > Ok, but the situation we're discussing here is when it was sent > > yesterday, and received yesterday, but *dated* some time in 1982. > > > > Since the message will not contain *any* authoritative sent dates at > > that point, > > I disagree. The authoritative date is the Date header which says 1982. > That's what the sending mail program said, and I believe it. Just > because its human is an ass doesn't change that. The human needs to be > notified, sure. I guess we'll have to agree to disagree, then. If that date is *wrong*, it's *wrong*. That it was applied by the sending MUA does *not* make it automatically authoritative; timestamps are an absolute -- there *is* a standard. > > what protocol would you *suggest*, for having it archived > > as being sent yesterday, the way you'd like? > > That's my point: it's *not* the way I'd like. I'm not suggesting > any protocol. The problem doesn't need any solution, for me. Fine. Then turn those switches off. You're in a minority, many other people hate having *incorrect* (and they are incorrect -- those messages were *not* sent in 1982) archives. > I'd suggest that the only two meaningful dates are: > > 1) Date: header > 2) date/time of arrival at the archiver > > All else is sophistry. Hmmm... isn't that what we said? And no, "time sent by the sender" is a meaningful date as well... *even if* it's not correctly represented by the header. > > > Right. I'm talking about the archiver too. > > > I just wanted to point out that opinions differ. > > > > Certainly... but I don't necessarily see that you've posited a > > *solution*, just an opinion. > > Who said anything about a solution? I started this thread, I think, by > stating an opinion about the behavior I'd like. Funny... I thought Barry'd started it. I'll have to go back and look. But regardless, I concur with Barry and the other people who called it a problem, and I think a solution is in order. Barry's solution has an on-off switch. If you think that this is not a problem *to the people for whom you maintain an archive*, then shut that switch off. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jj-list@mail.dk Tue May 1 22:30:49 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Tue, 01 May 2001 23:30:49 +0200 Subject: [Mailman-Developers] Delivering messages to scripts/post In-Reply-To: <2079.988675154@kanga.nu> References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <5.1.0.14.0.20010501232421.00bb7fa0@pop3.mail.dk> I wrote: > > We chaned to Mailman because we needed some things LISTSERV didn't > > have. J C Lawrence asked: >Like what? (might as well pump up our strengths) LISTSERV probably has the most features, but what I meant was that we now have the option of changing whatever we want to. Some messages/responses are still hard-coded into LISTSERV. The same is true for Mailman, but in Mailman I can choose to modify the source - you cannot beat that ;) Jesper. From jj-list@mail.dk Tue May 1 23:01:01 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Wed, 02 May 2001 00:01:01 +0200 Subject: [Mailman-Developers] Delivering messages to scripts/post In-Reply-To: <15086.14742.421568.853743@anthem.wooz.org> References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <5.1.0.14.0.20010501233124.03aab010@pop3.mail.dk> Barry A. Warsaw wrote: >What version of Mailman are you running? I'd be interested in looking >at any patches that help port Mailman to Windows (or any other >platform for that matter). I develop on Linux these days, and before >leaving CNRI, primarily Solaris. I'm fairly confident Mailman runs on >any (sane :) Unix-like OS, and I have nothing philosophical against >porting Mailman to any platform that Python runs on -- and that's a >lot of platforms. But I don't have much time to do that work myself, >so such porting necessarily relies on contributions from others. Mailman 2.0.3, but it will work with 2.0.4 if only changes to qrunner was made there. I am completely new to the world of sourceforge and cvs and patches and other joys it may bring. Right now my only weapon is a python script that modies Mailman to run on Windows. But using the cvs patch system is probably a good idea and I will try to go that way instead. Barry A. Warsaw wrote: >This should actually be better for Python 2.1 since the >case-sensitivity on imports for case-preserving case-insensitive file >systems (e.g. Windows) has been greatly improved (I've been told). I >thought about renaming Mailbox.py, but that's a PITA because I don't >want to lose the CVS history and renaming-retaining-history can't be >done without access to the CVS repository. I'll probably just require >MacOSX and Cygwin (and Windows :) users to use to Python 2.1. >Everyone else should be fine with Python 2.0 or 2.1. That sounds great, time for another upgrade then ;) Barry A. Warsaw wrote: >In the usual Unix MTA world, nothing, it's a dumb pipe. Mailman >itself looks at the incoming message for X-BeenThere headers and >raises a LoopError if it finds one that matches the list address. >There's no guarantee that'll be preserved during the loop though, and >in that case there isn't much that can be done. I know LISTSERV would refuse two messages with similar text sent to the same list. Or that is, the first message is sent to the list and all following messages with similar text are rejected. I don't know if this was a word by word comparison or a message size comparison. Has something similar been discussed for Mailman? Or maybe I am making a bigger issue out of this than it is. I am just terrified, that one morning I will find out, that one of the lists has been talking with some auto-reply system all night long. Jesper. From dan.mick@west.sun.com Tue May 1 23:16:27 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 15:16:27 -0700 Subject: [Mailman-Developers] Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> Message-ID: <3AEF35BB.314D0EB6@west.sun.com> > > I disagree. The authoritative date is the Date header which says 1982. > > That's what the sending mail program said, and I believe it. Just > > because its human is an ass doesn't change that. The human needs to be > > notified, sure. > > I guess we'll have to agree to disagree, then. Jay, that was the point of my original post. Why are you worrying me like a dog with rawhide on this one? I'm not something you have to topple, I'm just stating my opinion. > > I'd suggest that the only two meaningful dates are: > > > > 1) Date: header > > 2) date/time of arrival at the archiver > > > > All else is sophistry. > > Hmmm... isn't that what we said? I don't know. There was a hell of a lot of discussion about Received headers and moderation delays, and I think it's wasted effort. I was mostly ignoring that conversation, but I stopped to offer an opinion-on-the-way-to-what-I'd-do-as-solution, since you seemed to be haranguing me for one. > And no, "time sent by the sender" is a meaningful date as well... *even > if* it's not correctly represented by the header. But there's no way to measure that with any accuracy at all except the Date: header, which can be wrong, but shouldn't be. All else is sophistry. > > Who said anything about a solution? I started this thread, I think, by > > stating an opinion about the behavior I'd like. > > Funny... I thought Barry'd started it. I'll have to go back and look. I started the thread titled Dates, today. > But regardless, I concur with Barry and the other people who called it > a problem, and I think a solution is in order. Barry's solution has an > on-off switch. If you think that this is not a problem *to the people > for whom you maintain an archive*, then shut that switch off. Well, duh, Jay. Again, I don't know why you think I don't understand that, or that I'm recommending any behavior for you or anyone else. I'm merely offering an opinion. Stop being so threatened by that. From dgc@uchicago.edu Tue May 1 23:21:29 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 1 May 2001 17:21:29 -0500 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501180454.13332@scfn.thpl.lib.fl.us>; from jra@baylink.com on Tue, May 01, 2001 at 06:04:54PM -0400 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> Message-ID: <20010501172129.P29821@smack.uchicago.edu> On 2001.05.01, in <20010501180454.13332@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > If that date is *wrong*, it's *wrong*. That it was applied by the > sending MUA does *not* make it automatically authoritative; timestamps > are an absolute -- there *is* a standard. But it's not the MLM's business to judge whether a Date: header is correct. How would it possibly know? You're discussing ways to make a correct guess in most cases, but not a way to ensure correct information in all cases. > Fine. Then turn those switches off. You're in a minority, many other > people hate having *incorrect* (and they are incorrect -- those messages I don't think the discussion thus far is sufficient to say who's a minority, and I don't think that's relevant. What matters is that Barry seems to agree with you, and that not one has proposed a way to make everyone happy. > people hate having *incorrect* (and they are incorrect -- those messages > were *not* sent in 1982) archives. Suppose I send a message on May 12, 2001, and my mail system goes down before it gets out. My mail system isn't back up for 10 days, but they my message hits the list with its old, but correct, Date: header. My outbound mail was still sent on May 12, no matter that it's not within 7 days of May 12 anymore. This approach to the hypothetical problem doesn't cover all cases, just the majority of cases where there's damage due to misconfiguration. Maybe that's good enough, maybe not; but I agree with Dan that varying opinions and wishes may be pointed out. -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Tue May 1 23:24:41 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 18:24:41 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF35BB.314D0EB6@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 03:16:27PM -0700 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <3AEF35BB.314D0EB6@west.sun.com> Message-ID: <20010501182441.38183@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 03:16:27PM -0700, Dan Mick wrote: > > I guess we'll have to agree to disagree, then. > > Jay, that was the point of my original post. Why are you worrying me like > a dog with rawhide on this one? I'm not something you have to topple, > I'm just stating my opinion. Hmmm... I guess, Dan, that I'll have to go re-read the thread. It seemed to me like you were popping up in the middle of a "how should we fix this" thread with "don't". > > Hmmm... isn't that what we said? > > I don't know. There was a hell of a lot of discussion about Received headers > and moderation delays, and I think it's wasted effort. I was mostly ignoring > that conversation, but I stopped to offer an > opinion-on-the-way-to-what-I'd-do-as-solution, since you seemed to be > haranguing me for one. Hmmm... > > And no, "time sent by the sender" is a meaningful date as well... *even > > if* it's not correctly represented by the header. > > But there's no way to measure that with any accuracy at all except the > Date: header, which can be wrong, but shouldn't be. All else is sophistry. That it can't accurately be measured does not make it immaterial; to so assert is also sophistry. :-) > > Funny... I thought Barry'd started it. I'll have to go back and look. > > I started the thread titled Dates, today. Congratulations. But that wasn't the thread that started the discussion of the topic; that one was "2006 Messages in Archives". And it wasn't Barry, as it happens, it was Ousmane Wilane. > > But regardless, I concur with Barry and the other people who called it > > a problem, and I think a solution is in order. Barry's solution has an > > on-off switch. If you think that this is not a problem *to the people > > for whom you maintain an archive*, then shut that switch off. > > Well, duh, Jay. Again, I don't know why you think I don't understand that, > or that I'm recommending any behavior for you or anyone else. I'm merely > offering an opinion. Stop being so threatened by that. I sounded threatened? I thought you didn't understand that because your postings made it sound like you didn't understand that. The *real* problem, as I mentioned above, is that you started a new thread for no particularly apparent reason; we were *already talking about this*, in a thread that, as my memory had led me to expect, *started the day before your posting*. So quit snarking at me, especially since you're having to invent reasons to do so. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Tue May 1 23:35:41 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 18:35:41 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501172129.P29821@smack.uchicago.edu>; from David Champion on Tue, May 01, 2001 at 05:21:29PM -0500 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> Message-ID: <20010501183541.06693@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 05:21:29PM -0500, David Champion wrote: > On 2001.05.01, in <20010501180454.13332@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > If that date is *wrong*, it's *wrong*. That it was applied by the > > sending MUA does *not* make it automatically authoritative; timestamps > > are an absolute -- there *is* a standard. > > But it's not the MLM's business to judge whether a Date: header is > correct. How would it possibly know? You're discussing ways to make a > correct guess in most cases, but not a way to ensure correct > information in all cases. Stipulated. But we're not rewriting for retransmission, only to keep the archives clean; right, Barry? > > Fine. Then turn those switches off. You're in a minority, many other > > people hate having *incorrect* (and they are incorrect -- those messages > > I don't think the discussion thus far is sufficient to say who's a > minority, and I don't think that's relevant. What matters is that > Barry seems to agree with you, and that not one has proposed a way to > make everyone happy. Well, it's a matter of personal taste, to some degree... but we could always dig up Einar Stefferud and Marshall Rose, and see what they think. But as it happens, I agree with Barry, not the other way round. > > people hate having *incorrect* (and they are incorrect -- those messages > > were *not* sent in 1982) archives. > > Suppose I send a message on May 12, 2001, and my mail system goes down > before it gets out. My mail system isn't back up for 10 days, but they > my message hits the list with its old, but correct, Date: header. My > outbound mail was still sent on May 12, no matter that it's not within > 7 days of May 12 anymore. Hmmm... to my annoyance (:-), RFC 2822 agrees with you. Date: is the time that the message was "approved for transmission" by the writer, not the time it was actually injected. Now, while I don't think the standard actually *says* (section 3.3 certainly doesn't), *I* would personally assert that that field is invalid if the clock it was generated from isn't within *some* reasonable percentage of accurate (for a machine which is continuously connected to the Internet, I'd call that a second or so; for a machine *regularly* connected, probably 30-45 seconds). > This approach to the hypothetical problem doesn't cover all cases, just > the majority of cases where there's damage due to misconfiguration. Where damage can be interpreted as "people getting annoyed about the behaviours of others based on messages with incorrect time stamps"? > Maybe that's good enough, maybe not; but I agree with Dan that varying > opinions and wishes may be pointed out. I wasn't trying to suggest otherwise. What I *can* be construed as trying to suggest is that, since the proposed solution can be switched on and off at will, popping up with "Well, *I* don't think it needs to be fixed cause I don't think it's a problem" seems, at best, not especially productive. Particularly in light of the fact that *it's already done*. (I was going to apologize for the phrasing of that, but given Dan's tone in his last posting to me, it doesn't seem worth the effort.) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From dgc@uchicago.edu Tue May 1 23:52:08 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 1 May 2001 17:52:08 -0500 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501183541.06693@scfn.thpl.lib.fl.us>; from jra@baylink.com on Tue, May 01, 2001 at 06:35:41PM -0400 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> Message-ID: <20010501175208.T29821@smack.uchicago.edu> On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > correct. How would it possibly know? You're discussing ways to make a > > correct guess in most cases, but not a way to ensure correct > > information in all cases. > > Stipulated. But we're not rewriting for retransmission, only to keep > the archives clean; right, Barry? That's what I understand, too. My personal taste is that an archive reflect with complete accuracy and fidelity what was received from the transmitter -- not the recipient's interpretation thereof. This is only relevant to particulars of implementation, though, not to whether the general solution is applied at all. For example, I think it's more appropriate to leave the default at "don't munge incoming mail at all". > > > Fine. Then turn those switches off. You're in a minority, many other > > > people hate having *incorrect* (and they are incorrect -- those messages > > > > I don't think the discussion thus far is sufficient to say who's a > > minority, and I don't think that's relevant. What matters is that > > Barry seems to agree with you, and that not one has proposed a way to > > make everyone happy. > > Well, it's a matter of personal taste, to some degree... but we could > always dig up Einar Stefferud and Marshall Rose, and see what they > think. > > But as it happens, I agree with Barry, not the other way round. Fine. I suppose I used "agree" in the sense of having equivalent opinion, not of changing one's mind to match another's. I tend to think of this commutatively. Since I was speaking to you, and my emphasis was on what Barry thinks rather than on what you think.... > not the time it was actually injected. Now, while I don't think the > standard actually *says* (section 3.3 certainly doesn't), *I* would > personally assert that that field is invalid if the clock it was > generated from isn't within *some* reasonable percentage of accurate > (for a machine which is continuously connected to the Internet, I'd > call that a second or so; for a machine *regularly* connected, probably > 30-45 seconds). Without looking, I would wager cash that the *standard-track* RFC doesn't specify expected transmission time. I think you perhaps expect too much of the Internet. > > This approach to the hypothetical problem doesn't cover all cases, just > > the majority of cases where there's damage due to misconfiguration. > > Where damage can be interpreted as "people getting annoyed about the > behaviours of others based on messages with incorrect time stamps"? Where "damage" means "undesired harm or inconvenience". > I wasn't trying to suggest otherwise. What I *can* be construed as > trying to suggest is that, since the proposed solution can be switched > on and off at will, popping up with "Well, *I* don't think it needs to > be fixed cause I don't think it's a problem" seems, at best, not > especially productive. Particularly in light of the fact that *it's > already done*. I disagree, but we can each choose our crusades. -- -D. dgc@uchicago.edu NSIT University of Chicago From otaylor@redhat.com Wed May 2 02:24:59 2001 From: otaylor@redhat.com (Owen Taylor) Date: 01 May 2001 21:24:59 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: David Champion's message of "Tue, 1 May 2001 17:52:08 -0500" References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> Message-ID: David Champion writes: > On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > > correct. How would it possibly know? You're discussing ways to make a > > > correct guess in most cases, but not a way to ensure correct > > > information in all cases. > > > > Stipulated. But we're not rewriting for retransmission, only to keep > > the archives clean; right, Barry? > > That's what I understand, too. My personal taste is that an archive > reflect with complete accuracy and fidelity what was received from the > transmitter -- not the recipient's interpretation thereof. This is > only relevant to particulars of implementation, though, not to whether > the general solution is applied at all. For example, I think it's more > appropriate to leave the default at "don't munge incoming mail at > all". At the risk of prolonging this discussion, it may be worth pointing out that there are two different "dates" here: 1) The date in the Date: field displayed in the archive 2) The date used for sorting and for splitting archives by month/year. I'm of the opinion that 1) should always be the same date as generated by the MUA, but that using that date for 2) is, from experience, a bad idea, because some user's machines will have badly screwed up clocks, and you get archive volumes for ridiculous periods, etc. Currently, Mailman, currently, always uses the same date for both 1) and 2) - either the MUA date, or the date when the mail passed through mailman. From my perspective, arguing about which one of these is superior is somewhat pointless, since as soon as you use the same date for both, you are going to have problems. Regards, Owen From barry@digicool.com Wed May 2 04:02:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 23:02:19 -0400 Subject: [Mailman-Developers] Re: Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> Message-ID: <15087.30907.613868.332848@anthem.wooz.org> Phew! A little thing like dates gets us geeks in an uproar. Whodathunk? :) First, Mailman will not rewrite Date: headers for messages exploded to the list. I'm a firm believer in the least-munging rule. If the message gets sent out dated in 1982, then that's what the recipients will see. So that one's off the table. Second, /all/ we're talking about is placing the article in the archives. Ideally, the original Date: header would be preserved in the archive. But on the other hand, it really doesn't help people find information when a message is placed 8 years into the future. Mailman's current approach is less than ideal, and I think the right thing to do is for the archiver to put some sanity checks on the date for collation purposes. What Mailman and the receiving MTA can do is to mark the message with at least one date it can trust -- the date it received the message (if that server's clock is broken then oh well). So, forgetting about Mailman and Pipermail right now, what do archivers like MHonArc do when handed a message dated way in the future or way in the past? Do they dutifully put the message in the April 2006 bin? I'm not worried about messages that are a few days off, I'm much more concerned about messages that are /years/ off. I think what I will do is leave things the way they are currently, which gives Mailman the opportunity to be tuned to the archiver being used. Pipermail is dumb in the sense that it doesn't sanity check the Date:, and I can live with the fact that the Date: header in the archive won't be the original Date: header. People will still see the original Date: header in the message they receive from the list (via regular or digest delivery). If Pipermail is fixed, we can change the default to not munge Date: for the archiver, but it's not high on my priority list. The site admin can easily change the setting if they use an archiver that has better behavior. -Barry From jra@baylink.com Wed May 2 04:55:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 23:55:15 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: ; from Owen Taylor on Tue, May 01, 2001 at 09:24:59PM -0400 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> Message-ID: <20010501235515.21932@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 09:24:59PM -0400, Owen Taylor wrote: > David Champion writes: > > On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>, > > "Jay R. Ashworth" wrote: > > > > correct. How would it possibly know? You're discussing ways to make a > > > > correct guess in most cases, but not a way to ensure correct > > > > information in all cases. > > > > > > Stipulated. But we're not rewriting for retransmission, only to keep > > > the archives clean; right, Barry? > > > > That's what I understand, too. My personal taste is that an archive > > reflect with complete accuracy and fidelity what was received from the > > transmitter -- not the recipient's interpretation thereof. This is > > only relevant to particulars of implementation, though, not to whether > > the general solution is applied at all. For example, I think it's more > > appropriate to leave the default at "don't munge incoming mail at > > all". > > At the risk of prolonging this discussion, it may be worth pointing > out that there are two different "dates" here: > > 1) The date in the Date: field displayed in the archive > > 2) The date used for sorting and for splitting archives by > month/year. > > I'm of the opinion that 1) should always be the same date as generated > by the MUA, but that using that date for 2) is, from experience, a bad > idea, because some user's machines will have badly screwed up clocks, > and you get archive volumes for ridiculous periods, etc. I think we're all in violent agreement on that point... except maybe Dan; I can't speak for him, obviously. :-} > Currently, Mailman, currently, always uses the same date for both 1) > and 2) - either the MUA date, or the date when the mail passed through > mailman. From my perspective, arguing about which one of these > is superior is somewhat pointless, since as soon as you use the > same date for both, you are going to have problems. Well, and I think that's where we started. IIRC, Barry {was planning, thinking about, suggesting, had already written} code that rewrote 1 as 2 if it was too far out of whack, because it was easier to fix it there codewise than splitting them. [ Checks local archive } If I correctly understand where clobber_date is called in the flow of things, that paragraph is correct. And therefore, not the best approach, by concensus, apparently. Barry? Have I misunderstood you? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 04:57:54 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 23:57:54 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.30907.613868.332848@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 11:02:19PM -0400 References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> Message-ID: <20010501235754.34947@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 11:02:19PM -0400, Barry A. Warsaw wrote: > Phew! A little thing like dates gets us geeks in an uproar. > Whodathunk? :) Timestamps are fun things to fight about. :-) > First, Mailman will not rewrite Date: headers for messages exploded to > the list. I'm a firm believer in the least-munging rule. If the > message gets sent out dated in 1982, then that's what the recipients > will see. So that one's off the table. Outdating the message I *just* sent. Crap. I know better than not to "read everything before doing anything". > Second, /all/ we're talking about is placing the article in the > archives. Ideally, the original Date: header would be preserved in > the archive. But on the other hand, it really doesn't help people > find information when a message is placed 8 years into the future. Rog. Ok. > I'm not worried about messages that are a few days off, I'm much more > concerned about messages that are /years/ off. Indeed... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 04:59:50 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 23:59:50 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501235754.34947@scfn.thpl.lib.fl.us>; from "Jay R. Ashworth" on Tue, May 01, 2001 at 11:57:54PM -0400 References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> Message-ID: <20010501235950.25781@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 11:57:54PM -0400, Jay R. Ashworth wrote: > Timestamps are fun things to fight about. :-) But only pedagogically. My apologies to Dan Mick and anyone else who took my postings earlier today personally. Cheers, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 05:10:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:10:30 -0400 Subject: [Mailman-Developers] Re: Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> Message-ID: <15087.34998.85554.151195@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Well, and I think that's where we started. IIRC, Barry {was JRA> planning, thinking about, suggesting, had already written} JRA> code that rewrote 1 as 2 if it was too far out of whack, JRA> because it was easier to fix it there codewise than splitting JRA> them. JRA> [ Checks local archive } JRA> If I correctly understand where clobber_date is called in the JRA> flow of things, that paragraph is correct. JRA> And therefore, not the best approach, by concensus, JRA> apparently. Barry? Have I misunderstood you? If ARCHIVER_CLOBBER_DATE_POLICY is 1 (or 2, and the date is too far out-of-whack), then yes, the Date: header for the copy of the message being passed to the archiver gets munged. IMO, the archiver ought to be doing any date clobbering, but Pipermail is too painful to fix. Again, what do other external archivers do? I.e. if you passed an outrageously dated message to MHonArc, would it dutifully put the message in the April 2006 slot? The current approach has one hole, which would be easy to fix if it's useful. Mailman could mark the message with an `authoritatively received date' using some X-* header leaving the original Date: header alone. Then the archiver could use that date to slot the message regardless of what the Date: header said. I'm not sure this is worth it though because 1) there's no standard that I'm aware of that would let archivers and list managers/MTAs cooperate; 2) the date Mailman would stamp the message wouldn't be /that/ far off of the date the archiver got handed the message anyway, so the archiver can always do whatever it wants with dates and it'll be close enough; 3) the most recent Received: header is probably close enough so that it could be used as the `authoritatively received date' as has been suggested. I think we're good enough. If you don't like Date: header munging and have an archiver that handles outrageous dates itself, just set ARCHIVER_CLOBBER_DATE_POLICY to 0 and Mailman will pass the copy of the message to the archiver unblemished. -Barry From barry@digicool.com Wed May 2 05:11:53 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:11:53 -0400 Subject: [Mailman-Developers] Re: Dates References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> Message-ID: <15087.35081.828727.683975@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Outdating the message I *just* sent. Crap. I know better JRA> than not to "read everything before doing anything". It's that kind of thinking that got me 2300 messages in my inbox. :) -Barry From jra@baylink.com Wed May 2 05:14:09 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 00:14:09 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.35081.828727.683975@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 12:11:53AM -0400 References: <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> Message-ID: <20010502001409.25022@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 12:11:53AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> Outdating the message I *just* sent. Crap. I know better > JRA> than not to "read everything before doing anything". > > It's that kind of thinking that got me 2300 messages in my inbox. :) How many mailing lists, how many days? I can do 2300 in about a week... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 05:19:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 00:19:15 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.34998.85554.151195@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 12:10:30AM -0400 References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> <15087.34998.85554.151195@anthem.wooz.org> Message-ID: <20010502001915.28176@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 12:10:30AM -0400, Barry A. Warsaw wrote: > JRA> And therefore, not the best approach, by concensus, > JRA> apparently. Barry? Have I misunderstood you? > > If ARCHIVER_CLOBBER_DATE_POLICY is 1 (or 2, and the date is too far > out-of-whack), then yes, the Date: header for the copy of the message > being passed to the archiver gets munged. > > IMO, the archiver ought to be doing any date clobbering, but Pipermail > is too painful to fix. Again, what do other external archivers do? > I.e. if you passed an outrageously dated message to MHonArc, would it > dutifully put the message in the April 2006 slot? Ok; that's what I thought I'd heard. > The current approach has one hole, which would be easy to fix if it's > useful. Mailman could mark the message with an `authoritatively > received date' using some X-* header leaving the original Date: header > alone. Then the archiver could use that date to slot the message > regardless of what the Date: header said. > > I'm not sure this is worth it though because 1) there's no standard > that I'm aware of that would let archivers and list managers/MTAs > cooperate; Rough Concensus; Working Code. (ie: *create* such a header) > 2) the date Mailman would stamp the message wouldn't be > /that/ far off of the date the archiver got handed the message anyway, > so the archiver can always do whatever it wants with dates and it'll > be close enough; 3) the most recent Received: header is probably close > enough so that it could be used as the `authoritatively received date' > as has been suggested. Assuming you can reliably decide which one to use. Can you? > I think we're good enough. If you don't like Date: header munging and > have an archiver that handles outrageous dates itself, just set > ARCHIVER_CLOBBER_DATE_POLICY to 0 and Mailman will pass the copy of > the message to the archiver unblemished. Indeed. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 05:20:51 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:20:51 -0400 Subject: [Mailman-Developers] Re: Dates References: <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> Message-ID: <15087.35619.606174.83682@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> How many mailing lists, how many days? I can do 2300 in JRA> about a week... Oh jeez, that's just the messages I've actually looked at and buried thinking "I'll get back to them". Counts digests as single messages. I'm not claiming I'm unique or even that bad in our world of geeks. I had a boss that had 30k+ messages in his inbox, and simply had his secretary just delete the whole dang thing. There's a lot to be said for "if it's important enough, they'll keep bugging me". :) -Barry From jra@baylink.com Wed May 2 05:23:14 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 00:23:14 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.35619.606174.83682@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 12:20:51AM -0400 References: <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> <15087.35619.606174.83682@anthem.wooz.org> Message-ID: <20010502002314.62121@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 12:20:51AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> How many mailing lists, how many days? I can do 2300 in > JRA> about a week... > > Oh jeez, that's just the messages I've actually looked at and buried > thinking "I'll get back to them". Counts digests as single messages. I used to have a real problem with the standing size of my inbox. I've been managing to keep it down to about 3 to 7 messages, with a little help from =todo, instead of the 30-50 it sometimes got to before. > I'm not claiming I'm unique or even that bad in our world of geeks. I > had a boss that had 30k+ messages in his inbox, and simply had his > secretary just delete the whole dang thing. There's a lot to be said > for "if it's important enough, they'll keep bugging me". :) Assuming you see it. And sometimes, they *won't* keep bugging you cause it's more important to you than it is to them. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 05:22:59 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:22:59 -0400 Subject: [Mailman-Developers] Re: Dates References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> <15087.34998.85554.151195@anthem.wooz.org> <20010502001915.28176@scfn.thpl.lib.fl.us> Message-ID: <15087.35747.197313.310973@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> The current approach has one hole, which would be easy to fix >> if it's useful. Mailman could mark the message with an >> `authoritatively received date' using some X-* header leaving >> the original Date: header alone. Then the archiver could use >> that date to slot the message regardless of what the Date: >> header said. I'm not sure this is worth it though because 1) >> there's no standard that I'm aware of that would let archivers >> and list managers/MTAs cooperate; JRA> Rough Concensus; Working Code. (ie: *create* such a header) Suggestion: X-List-Received-Date ? But, is it even worth it? >> 2) the date Mailman would stamp the message wouldn't be >> /that/ far off of the date the archiver got handed the message >> anyway, so the archiver can always do whatever it wants with >> dates and it'll be close enough; 3) the most recent Received: >> header is probably close enough so that it could be used as the >> `authoritatively received date' as has been suggested. JRA> Assuming you can reliably decide which one to use. Can you? Nope, which is why I rejected this suggestion for Mailman. -Barry From claw@kanga.nu Wed May 2 05:27:41 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 01 May 2001 21:27:41 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from David Champion of "Tue, 01 May 2001 17:21:29 CDT." <20010501172129.P29821@smack.uchicago.edu> References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> Message-ID: <6126.988777661@kanga.nu> On Tue, 1 May 2001 17:21:29 -0500 David Champion wrote: > But it's not the MLM's business to judge whether a Date: header is > correct. How would it possibly know? You're discussing ways to > make a correct guess in most cases, but not a way to ensure > correct information in all cases. There are two interesting facts about a message: 1) The message as the author wrote it. 2) When the message arrived at the list in terms of time and in terms of list sequence. Past that, its all quibbles. Altering either one destroys historical accuracy. Bad idea. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From dgc@uchicago.edu Wed May 2 05:53:49 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 1 May 2001 23:53:49 -0500 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.30907.613868.332848@anthem.wooz.org>; from barry@digicool.com on Tue, May 01, 2001 at 11:02:19PM -0400 References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> Message-ID: <20010501235349.X29821@smack.uchicago.edu> On 2001.05.01, in <15087.30907.613868.332848@anthem.wooz.org>, "Barry A. Warsaw" wrote: > > Phew! A little thing like dates gets us geeks in an uproar. > Whodathunk? :) Well, we're touching on a matter of fidelity of a record, which is what gets me concerned about it. I guess that's a kind of geekiness, but maybe a different kind. :) > First, Mailman will not rewrite Date: headers for messages exploded to > the list. I'm a firm believer in the least-munging rule. If the > message gets sent out dated in 1982, then that's what the recipients > will see. So that one's off the table. Right, and, as a comment on our comments thus far, I think it's safe to say that we all agree on it. > Second, /all/ we're talking about is placing the article in the > archives. Ideally, the original Date: header would be preserved in > the archive. But on the other hand, it really doesn't help people > find information when a message is placed 8 years into the future. > > Mailman's current approach is less than ideal, and I think the right > thing to do is for the archiver to put some sanity checks on the date > for collation purposes. What Mailman and the receiving MTA can do is Here we brush by the unspoken third approach to the problem. Rather than altering the date in the copy of the message fed to the archiver, Mailman can feed the "correct" date out-of-band. The archiver can use this altered date, as you say, for collation, but retain the original Date: header for the archive itself. This is certainly more trouble to implement, and arguably infeasible since it could involve modification of the (external?) archiver, but I think it best meets all interests. I'd also like to offer that although, for example, PGP/MIME (and other, nonstandard, PGP message encodings for e-mail) does not sign the Date: field along with the message itself, this is not an unreasonable thing for some alternative or future signature format to do. That's just another reason that altering the archival contents themselves strikes me as a Bad Thing, even though altering the way the message is collated or indexed is fine. -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Wed May 2 06:02:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 01:02:15 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501235349.X29821@smack.uchicago.edu>; from David Champion on Tue, May 01, 2001 at 11:53:49PM -0500 References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235349.X29821@smack.uchicago.edu> Message-ID: <20010502010215.17217@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 11:53:49PM -0500, David Champion wrote: > On 2001.05.01, in <15087.30907.613868.332848@anthem.wooz.org>, > "Barry A. Warsaw" wrote: > > Phew! A little thing like dates gets us geeks in an uproar. > > Whodathunk? :) > > Well, we're touching on a matter of fidelity of a record, which is what > gets me concerned about it. I guess that's a kind of geekiness, but > maybe a different kind. :) Indeed we are. Both sides, in different ways. > > Second, /all/ we're talking about is placing the article in the > > archives. Ideally, the original Date: header would be preserved in > > the archive. But on the other hand, it really doesn't help people > > find information when a message is placed 8 years into the future. > > > > Mailman's current approach is less than ideal, and I think the right > > thing to do is for the archiver to put some sanity checks on the date > > for collation purposes. What Mailman and the receiving MTA can do is > > Here we brush by the unspoken third approach to the problem. Rather > than altering the date in the copy of the message fed to the archiver, > Mailman can feed the "correct" date out-of-band. The archiver can use > this altered date, as you say, for collation, but retain the original > Date: header for the archive itself. As Barry suggested. > This is certainly more trouble to implement, and arguably infeasible > since it could involve modification of the (external?) archiver, but I > think it best meets all interests. It does that. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Wed May 2 09:39:18 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 01:39:18 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 02 May 2001 00:19:15 EDT." <20010502001915.28176@scfn.thpl.lib.fl.us> References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> <15087.34998.85554.151195@anthem.wooz.org> <20010502001915.28176@scfn.thpl.lib.fl.us> Message-ID: <1446.988792758@kanga.nu> On Wed, 2 May 2001 00:19:15 -0400 Jay R Ashworth wrote: > On Wed, May 02, 2001 at 12:10:30AM -0400, Barry A. Warsaw wrote: JRA> And therefore, not the best approach, by concensus, apparently. JRA> Barry? Have I misunderstood you? >> IMO, the archiver ought to be doing any date clobbering, but >> Pipermail is too painful to fix. Again, what do other external >> archivers do? I.e. if you passed an outrageously dated message >> to MHonArc, would it dutifully put the message in the April 2006 >> slot? > Ok; that's what I thought I'd heard. That is what it does (and what I want). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Wed May 2 09:44:27 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 01:44:27 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 02 May 2001 00:20:51 EDT." <15087.35619.606174.83682@anthem.wooz.org> References: <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> <15087.35619.606174.83682@anthem.wooz.org> Message-ID: <10970.988793067@kanga.nu> On Wed, 2 May 2001 00:20:51 -0400 Barry A Warsaw wrote: >>>>>> "JRA" == Jay R Ashworth writes: JRA> How many mailing lists, how many days? I can do 2300 in about JRA> a week... > Oh jeez, that's just the messages I've actually looked at and > buried thinking "I'll get back to them". Counts digests as single > messages. I average around 2,500 to 3,000 messages a day here (no digests). Tonight I've managed to work my unread counter down from 11,000 and something to 4549. Doing good. > I'm not claiming I'm unique or even that bad in our world of > geeks. I had a boss that had 30k+ messages in his inbox, and > simply had his secretary just delete the whole dang thing. > There's a lot to be said for "if it's important enough, they'll > keep bugging me". :) Procmail is your friend. One of the thing I do occassionally is relegate lists to the background. I then have procmail search the messages it files to their per-list folders for matches to key-word lists, and then files a second copy in my folder. Then, to have procmail auto-file that thread and all future replies into the interesting folder, I have it watch and maintain a timestamped database of MessageIDs which are then scanned for in the In-Reply-To and References: headers. Works quite nicely. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From sillygod@hotmail.com Wed May 2 12:59:20 2001 From: sillygod@hotmail.com (SillyGod) Date: Wed, 2 May 2001 07:59:20 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0D2DD.CB7DAB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, Please, could someone advise me if there is still an issue with using = case-sensitive e-mail addresses with mailman? ie. john.doe@email.com vs. = John.Doe@email.com would both get delivered? Or would the case-incorrect = version bounce? Thanks! *Larry* ------=_NextPart_000_0007_01C0D2DD.CB7DAB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
Please, could someone advise me if = there is still=20 an issue with using case-sensitive e-mail addresses with mailman? ie. john.doe@email.com vs. John.Doe@email.com would both get = delivered? Or would the case-incorrect version bounce?
 
Thanks!
 
*Larry*
------=_NextPart_000_0007_01C0D2DD.CB7DAB70-- From barry@digicool.com Wed May 2 14:48:26 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 09:48:26 -0400 Subject: [Mailman-Developers] Re: Dates References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235349.X29821@smack.uchicago.edu> Message-ID: <15088.4139.451332.213714@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> Here we brush by the unspoken third approach to the problem. DC> Rather than altering the date in the copy of the message fed DC> to the archiver, Mailman can feed the "correct" date DC> out-of-band. The archiver can use this altered date, as you DC> say, for collation, but retain the original Date: header for DC> the archive itself. Read "out-of-band" as "add-a-header" and I can agree. Okay, if the original Date: header isn't clobbered, I'll add the X-List-Received-Date: header to the copy of the message that the archiver gets. So you get the behavior you want by setting ARCHIVER_CLOBBER_DATE_POLICY to 0. -Barry From jra@baylink.com Wed May 2 15:12:08 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 10:12:08 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <10970.988793067@kanga.nu>; from J C Lawrence on Wed, May 02, 2001 at 01:44:27AM -0700 References: <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> <15087.35619.606174.83682@anthem.wooz.org> <10970.988793067@kanga.nu> Message-ID: <20010502101208.60346@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 01:44:27AM -0700, J C Lawrence wrote: > > Oh jeez, that's just the messages I've actually looked at and > > buried thinking "I'll get back to them". Counts digests as single > > messages. > > I average around 2,500 to 3,000 messages a day here (no digests). > Tonight I've managed to work my unread counter down from 11,000 and > something to 4549. Doing good. For you, Carnage, I'm not surprised... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 15:17:37 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 10:17:37 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: Message-ID: <15088.5889.875850.110383@anthem.wooz.org> >>>>> "S" == SillyGod writes: S> Please, could someone advise me if there is still an issue with S> using case-sensitive e-mail addresses with mailman? S> ie. john.doe@email.com vs. John.Doe@email.com would both get S> delivered? Or would the case-incorrect version bounce? Mailman is case-preserving case-insensitive w.r.t. email addresses. What this means is that you cannot subscribe both john.doe@email.com and John.Doe@email.com; they are considered the same address for memebership purposes. However, Mailman will case-preserve the username part of the address, so that if you subscribe John.Doe@email.com, messages will be sent to John.Doe@email.com and not john.doe@email.com. -Barry From jra@baylink.com Wed May 2 15:19:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 10:19:15 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: ; from SillyGod on Wed, May 02, 2001 at 07:59:20AM -0400 References: Message-ID: <20010502101915.39202@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 07:59:20AM -0400, SillyGod wrote: > Please, could someone advise me if there is still an issue with using > case-sensitive e-mail addresses with mailman? ie. john.doe@email.com vs. > John.Doe@email.com would both get delivered? Or would the case-incorrect > version bounce? The *right hand side* of a mailbox name (which is what we're actually talking about here) is case-insensitive because it's a DNS name, and *DNS*, in turn, is case-insensitive. The *left hand side* (the "username"), OTOH, must be treated as case-sensitive, because whether it actually *is*, or not, is system-dependent... and the "system" in question is the final target mail server -- in general, I believe that Unix machines are case-sensitive and Windows ones are not, as is usually the case, but I don't know Exchange, nor non-Sendmail Unix MTA's, well enough to guarantee that. Interestingly, RFC 2822 appears silent on this point, making the *third* thing this week it's been silent on to my surprise. Hmmm... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 15:27:06 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 10:27:06 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.5889.875850.110383@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 10:17:37AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> Message-ID: <20010502102706.41364@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 10:17:37AM -0400, Barry A. Warsaw wrote: > >>>>> "S" == SillyGod writes: > S> Please, could someone advise me if there is still an issue with > S> using case-sensitive e-mail addresses with mailman? > S> ie. john.doe@email.com vs. John.Doe@email.com would both get > S> delivered? Or would the case-incorrect version bounce? > > Mailman is case-preserving case-insensitive w.r.t. email addresses. > > What this means is that you cannot subscribe both john.doe@email.com > and John.Doe@email.com; they are considered the same address for > memebership purposes. Ok... since I know that LHS's are supposed to be treated as if they *might* be case-sensitive, I dug further. The controlling paragraphs are 2.4 and 4.1.2 in RFC 2821, both of which specify that a local-part may be case sensitive. IE: oops. :-} Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 16:02:38 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 11:02:38 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> Message-ID: <15088.8590.513944.540403@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> The controlling paragraphs are 2.4 and 4.1.2 in RFC 2821, JRA> both of which specify that a local-part may be case JRA> sensitive. JRA> IE: oops. :-} No oops on Mailman's part! We case preserve for the benefit of the receiving smtpds, but I think it's perfectly valid for Mailman to case-fold subscription keys. -Barry From jra@baylink.com Wed May 2 16:05:18 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:05:18 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.8590.513944.540403@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 11:02:38AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> Message-ID: <20010502110518.45171@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 11:02:38AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> The controlling paragraphs are 2.4 and 4.1.2 in RFC 2821, > JRA> both of which specify that a local-part may be case > JRA> sensitive. > > JRA> IE: oops. :-} > > No oops on Mailman's part! We case preserve for the benefit of the > receiving smtpds, but I think it's perfectly valid for Mailman to > case-fold subscription keys. I'm afraid I must disagree: that section of 2821 implies that John.Doe@example.com and john.doe@example.com *may be separate mailboxes*. Admittedly, it's a corner case, and very unlikely ever to bite us, but doing it that was *does* violate the standard. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 16:10:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 11:10:31 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> Message-ID: <15088.9063.1167.736985@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> I'm afraid I must disagree: that section of 2821 implies that | John.Doe@example.com | and | john.doe@example.com JRA> *may be separate mailboxes*. I understand that. JRA> Admittedly, it's a corner case, and very unlikely ever to JRA> bite us, but doing it that was *does* violate the standard. Except that Mailman isn't an SMTP server, so it doesn't have to play by those rules. For a list server, I claim that allowing keys to differ only by case is confusing and needless generalization. In practice, I don't remember it ever biting us. -Barry From jra@baylink.com Wed May 2 16:13:25 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:13:25 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.9063.1167.736985@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 11:10:31AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> Message-ID: <20010502111325.45390@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 11:10:31AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> I'm afraid I must disagree: that section of 2821 implies that > > | John.Doe@example.com > | and > | john.doe@example.com > > JRA> *may be separate mailboxes*. > > I understand that. > > JRA> Admittedly, it's a corner case, and very unlikely ever to > JRA> bite us, but doing it that was *does* violate the standard. > > Except that Mailman isn't an SMTP server, so it doesn't have to play > by those rules. For a list server, I claim that allowing keys to > differ only by case is confusing and needless generalization. In > practice, I don't remember it ever biting us. No, but Mailman *is dealing with RFC[2]82{1,2} addresses, and ought to play by their rules. As I noted, it *is* a corner case; anyone who actually *does* that on a machine ought to be shot... and I wouldn't expect us to be bitten by it; being a pedant is just my *job*, damnit. Cheers, -- jr 'actually, it's an adventure' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From chuqui@plaidworks.com Wed May 2 16:26:59 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 08:26:59 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502110518.45171@scfn.thpl.lib.fl.us> Message-ID: On 5/2/01 8:05 AM, "Jay R. Ashworth" wrote: > I'm afraid I must disagree: that section of 2821 implies that > > John.Doe@example.com > and > john.doe@example.com > > *may be separate mailboxes*. Admittedly, it's a corner case, and very > unlikely ever to bite us, but doing it that was *does* violate the > standard. Sorry, I disagree. "may be" means the standard allows you to consider this as optional. That's good, because 821 made case sensistivity mandatory (and the switch shows the clear intent of the standards folks, which is moving to full case insensitivity, but they must have felt completely removing it was too big a step -- but they're telling anyone who might still have a case sensitive mailer it's time to fix it) In practice, Barry's approach is the best one. The only thing that happens if you practice case sensitivity on the user part is that users end up with multiple subscriptions, multiple copies and no clue how to fix it or what's wrong (and it's your fault, your mailer is screwed up). The rewrite of the standard makes it clear this kind of situation (John.Doe and john.doe being different people) is now optional -- and I don't know that any MLM would work cleanly if it happens (and any admin that allows it should be shot...) From jra@baylink.com Wed May 2 16:30:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:30:55 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: ; from Chuq Von Rospach on Wed, May 02, 2001 at 08:26:59AM -0700 References: <20010502110518.45171@scfn.thpl.lib.fl.us> Message-ID: <20010502113055.56791@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 08:26:59AM -0700, Chuq Von Rospach wrote: > On 5/2/01 8:05 AM, "Jay R. Ashworth" wrote: > > I'm afraid I must disagree: that section of 2821 implies that > > > > John.Doe@example.com > > and > > john.doe@example.com > > > > *may be separate mailboxes*. Admittedly, it's a corner case, and very > > unlikely ever to bite us, but doing it that was *does* violate the > > standard. > > Sorry, I disagree. "may be" means the standard allows you to consider this > as optional. That's good, because 821 made case sensistivity mandatory (and > the switch shows the clear intent of the standards folks, which is moving to > full case insensitivity, but they must have felt completely removing it was > too big a step -- but they're telling anyone who might still have a case > sensitive mailer it's time to fix it) Hmmm... Ok. If *you* think that, Chuq, I'll re-evaulate my opinion. I hadn't compared it with 821. I'm wondering why, though, they didn't make that explicit in the rewrite. > In practice, Barry's approach is the best one. The only thing that happens > if you practice case sensitivity on the user part is that users end up with > multiple subscriptions, multiple copies and no clue how to fix it or what's > wrong (and it's your fault, your mailer is screwed up). Got it. > The rewrite of the standard makes it clear this kind of situation (John.Doe > and john.doe being different people) is now optional -- and I don't know > that any MLM would work cleanly if it happens (and any admin that allows it > should be shot...) I believe I *did* evince *that* opinion, at least... :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 16:32:51 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 11:32:51 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> <20010502111325.45390@scfn.thpl.lib.fl.us> Message-ID: <15088.10403.652262.809394@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> No, but Mailman *is dealing with RFC[2]82{1,2} addresses, and JRA> ought to play by their rules. As I noted, it *is* a corner JRA> case; anyone who actually *does* that on a machine ought to JRA> be shot... JRA> and I wouldn't expect us to be bitten by it; being a pedant JRA> is just my *job*, damnit. :) From chuqui@plaidworks.com Wed May 2 16:43:17 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 08:43:17 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502113055.56791@scfn.thpl.lib.fl.us> Message-ID: On 5/2/01 8:30 AM, "Jay R. Ashworth" wrote: > Hmmm... Ok. If *you* think that, Chuq, I'll re-evaulate my opinion. I > hadn't compared it with 821. I'm wondering why, though, they didn't > make that explicit in the rewrite. I can think of two reasons: 1) they're really codifying existing practices -- nobody was paying attention to the case sensitivity issue anyway, but in a nod to the previous standard, they didn't want to throw it out completely. It allows them to get it out of the way while still claiming (for the most part) backwards compatibility. 2) they wanted it in the standard and out the door before the fight started... (grin) In my big muther custom server, I squash everything to LC (and in fact, since my backend data store is mysql, making things case sensitive would require some significant work). I've found no cases (not few -- none) where this has caused a problem, and in fact the only time case issues come up at all is when an AOL user can't find their subscription and emails me for help and says something like "if you can't find juser@aol.com, try Juser..." I probably shouldn't squash case, really, but it simplifies dealing with this stuff somewhat, and I've found from watching the search strings that most users don't try to maintain case in their lookups anyway... Except from AOL, where it's cosmetic... I haven't really pawed through the new standard in detail, but from what I've seen, I think the intent is to say that case sensitivity is optional ("may be", not "must be"), and I think that implies that if you want to write stuff that's case sensitive on your local system, that's fine, but you can no longer assume it'll work once it leaves your control. Which is, in practice, how it's been for many years... From jra@baylink.com Wed May 2 16:47:27 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:47:27 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.10403.652262.809394@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 11:32:51AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> <20010502111325.45390@scfn.thpl.lib.fl.us> <15088.10403.652262.809394@anthem.wooz.org> Message-ID: <20010502114727.57805@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 11:32:51AM -0400, Barry A. Warsaw wrote: > JRA> and I wouldn't expect us to be bitten by it; being a pedant > JRA> is just my *job*, damnit. > > :) That's an excellent attitude, Barry. I think we'll get along just fine... :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 16:50:09 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:50:09 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: ; from Chuq Von Rospach on Wed, May 02, 2001 at 08:43:17AM -0700 References: <20010502113055.56791@scfn.thpl.lib.fl.us> Message-ID: <20010502115009.18635@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 08:43:17AM -0700, Chuq Von Rospach wrote: > > Hmmm... Ok. If *you* think that, Chuq, I'll re-evaulate my opinion. I > > hadn't compared it with 821. I'm wondering why, though, they didn't > > make that explicit in the rewrite. > > I can think of two reasons: > > 1) they're really codifying existing practices -- nobody was paying > attention to the case sensitivity issue anyway, but in a nod to the previous > standard, they didn't want to throw it out completely. It allows them to get > it out of the way while still claiming (for the most part) backwards > compatibility. But is this actually true? I haven't tried it, but I thought sendmail still treated LHS's as case-sensitive... > 2) they wanted it in the standard and out the door before the fight > started... (grin) > In my big muther custom server, I squash everything to LC (and in fact, > since my backend data store is mysql, making things case sensitive would > require some significant work). I've found no cases (not few -- none) where > this has caused a problem, and in fact the only time case issues come up at > all is when an AOL user can't find their subscription and emails me for help > and says something like "if you can't find juser@aol.com, try Juser..." Hmmm... > I probably shouldn't squash case, really, but it simplifies dealing with > this stuff somewhat, and I've found from watching the search strings that > most users don't try to maintain case in their lookups anyway... Except from > AOL, where it's cosmetic... Indeed. > I haven't really pawed through the new standard in detail, but from what > I've seen, I think the intent is to say that case sensitivity is optional > ("may be", not "must be"), and I think that implies that if you want to > write stuff that's case sensitive on your local system, that's fine, but you > can no longer assume it'll work once it leaves your control. Which is, in > practice, how it's been for many years... Hmmm... *I* interpreted it to mean "someone out there might be treating this as case-sensitive, so you ought to be careful not to break their shit." But I can see your interpretation as well.. Cheers, -- jr 'be ye not overly annoying... nor too easily annoyed' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From Nigel.Metheringham@InTechnology.co.uk Wed May 2 17:01:25 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Wed, 02 May 2001 17:01:25 +0100 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 02 May 2001 11:50:09 EDT." <20010502115009.18635@scfn.thpl.lib.fl.us> Message-ID: jra@baylink.com said: > But is this actually true? I haven't tried it, but I thought sendmail > still treated LHS's as case-sensitive... Depending on your rewrite rules, sendmail can be either case sensitive or case insensitive. Exim also has a choice:- > locally_caseless > Type: boolean > Default: true > Domains in mail addresses are specified as being case-independent, but > this it not true of local parts. For most Unix systems, however, it is > desirable that local parts of local mail addresses be treated in a > case-independent manner, since most users expect that mail to OBailey > and obailey, for example, will end up in the same mailbox. By default, > when it is processing an address whose domain is local, Exim > lower-cases the local part at the start of processing, on the > assumption that account names in the password file are in lower-case. > For installations that want to draw case distinctions, this option is > provided. When turned off, local local parts are handled verbatim > during delivery. If there are names containing upper case letters in > the password file, the most convenient way to provide for caseless > mail delivery is to set up a smartuser director as the first director, > and to make it do a lowercased lookup of the local part, in order to > translate it to the correctly cased version, using the new_address > option. There is a special place in hell reserved for those that use mixed case usernames on Unix and also expect caseless operation. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From chuqui@plaidworks.com Wed May 2 17:09:03 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 09:09:03 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502115009.18635@scfn.thpl.lib.fl.us> Message-ID: On 5/2/01 8:50 AM, "Jay R. Ashworth" wrote: > But is this actually true? I haven't tried it, but I thought sendmail > still treated LHS's as case-sensitive... Not to my knowledge, and I just tested it on my system and it's not, and my config should be standard for this. A quick grep of the docs doesn't show me any documentation at all on case sensitivity, so it looks like they removed it completely at some point -- I know at one point there was an option to turn it on; that seems gone. > Hmmm... *I* interpreted it to mean "someone out there might be treating > this as case-sensitive, so you ought to be careful not to break their > shit." Not unreasonable, but compare it to the old definition. It used to be case sensitive, even though we all ignored it. Now, it may be case sensitive. The intent is clearly to make it non-mandatory. That means you can't depend on it being allowed unless you control the e-mail completely. And that means while I shouldn't arbitrarily do weird things to it simply because I can, you can no longer assume I WON'T do weird things to it, because the standard no longer tells me not to... From thomas@xs4all.net Wed May 2 18:05:40 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 2 May 2001 19:05:40 +0200 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502111325.45390@scfn.thpl.lib.fl.us>; from jra@baylink.com on Wed, May 02, 2001 at 11:13:25AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> <20010502111325.45390@scfn.thpl.lib.fl.us> Message-ID: <20010502190540.Q16486@xs4all.nl> On Wed, May 02, 2001 at 11:13:25AM -0400, Jay R. Ashworth wrote: > and I wouldn't expect us to be bitten by it; being a pedant is just my > *job*, damnit. Don't worry, you're not alone. I remember some pretty frustrating pedantic discussions where I had trouble convincing people I really *was* a nice guy, but I still stood by my pedantic point. Some of them were on python-dev, even :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From claw@kanga.nu Wed May 2 19:31:12 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 11:31:12 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 02 May 2001 09:48:26 EDT." <15088.4139.451332.213714@anthem.wooz.org> References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235349.X29821@smack.uchicago.edu> <15088.4139.451332.213714@anthem.wooz.org> Message-ID: <24226.988828272@kanga.nu> On Wed, 2 May 2001 09:48:26 -0400 Barry A Warsaw wrote: > I'll add the X-List-Received-Date: header to the copy of the > message that the archiver gets. Oo00, please! Especially if: -- You also mention the list name/address in the same header -- You don't stomp any previous X-List-Received-Date headers that are alsoready present. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From mailman@howlingfrog.com Wed May 2 19:30:59 2001 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Wed, 2 May 2001 11:30:59 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <15087.8010.821127.647320@anthem.wooz.org> References: <0104271309330S.08359@graham.localdomain> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> Message-ID: <01050211305908.03885@graham.localdomain> On Tuesday 01 May 2001 13:40, you wrote: [.....snip.....] > Here's what I did: I loaded up a list with 60000 subscribers, then > went to the members page. It did indeed take a long time, and if I > let it run to completion, I get the page as expected and no locks. > > However, if I hit the stop button before the page is finished loading, > I can see that the CGI process continues to run for a while and then > it may or may not clear the locks. The page is not complete. Since > sometimes the locks are cleared and sometimes they're left, it's > pretty clear there are race conditions involved. [.....snip.....] > This seems to work, in that the locks appear to be cleared in the > cases where they were left laying around before. But because of all > the race conditions, I can't be 100% sure. > > If you've read this far, the implication is that if the user hits the > stop button, Mailman will in essence abort any changes to list > configuration that this invocation may have made. Alternatively, we > could try to save & unlock in the signal handler, but that raises the > possibility of race conditions again. Also, it makes sense to move > the save of the list data into the try: part of the clause and only do > the unlocking in the finally. That way, the finally clause and the > SIGTERM handler have the same semantics, and the list will get > unlocked in the face of either an exception or a signal. But the list > database will only get saved on sucessful completion of the task. I > can live with those semantics (I think ;). [.....snip.....] Barry, wanted to thank you muchly for the lengthy description of the problem and the patch that you provided. I figured that this was probably what was happening, after having gone through the process of running the CGIs repeatedly myself here. >From the initial testing that I've done, it appears that the patch that you provided does work (near as I can tell so far), and has helped eliminate the dangling/stale lockfile problems that we've been having. As for the semantics of "save the list only if everything was successful", I too believe that those are livable (and likely proper) semantics to live with. Will let you know again if we continue to have this problem, but from what I've seen so far this appears to have fixed the major fire that I've had. Now all I've got to figure out is how to try to speed up the admin CGIs so that they don't take two or three minutes to load when dealing with large lists... Thanks again Barry, -- Graham TerMarsch From claw@kanga.nu Wed May 2 19:43:16 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 11:43:16 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: Message from Chuq Von Rospach of "Wed, 02 May 2001 08:26:59 PDT." References: Message-ID: <14112.988828996@kanga.nu> On Wed, 02 May 2001 08:26:59 -0700 Chuq Von Rospach wrote: > On 5/2/01 8:05 AM, "Jay R. Ashworth" wrote: >> I'm afraid I must disagree: that section of 2821 implies that > Sorry, I disagree. "may be" means the standard allows you to > consider this as optional. That's good, because 821 made case > sensistivity mandatory (and the switch shows the clear intent of > the standards folks, which is moving to full case insensitivity, > but they must have felt completely removing it was too big a step > -- but they're telling anyone who might still have a case > sensitive mailer it's time to fix it) IIRC some of the old BitNet systems mandated case sensitive LHS and were not configurable in that regard. As a result the gateways would upcase everything for portability. Its questionable if any of them are still on the 'net, but that's another question. > In practice, Barry's approach is the best one. The only thing that > happens if you practice case sensitivity on the user part is that > users end up with multiple subscriptions, multiple copies and no > clue how to fix it or what's wrong (and it's your fault, your > mailer is screwed up). The principle of least surprise. People have enough problem with case sensitive passwords. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Wed May 2 19:46:40 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 11:46:40 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 02 May 2001 11:50:09 EDT." <20010502115009.18635@scfn.thpl.lib.fl.us> References: <20010502113055.56791@scfn.thpl.lib.fl.us> <20010502115009.18635@scfn.thpl.lib.fl.us> Message-ID: <20419.988829200@kanga.nu> On Wed, 2 May 2001 11:50:09 -0400 Jay R Ashworth wrote: > On Wed, May 02, 2001 at 08:43:17AM -0700, Chuq Von Rospach wrote: > But is this actually true? I haven't tried it, but I thought > sendmail still treated LHS's as case-sensitive... Its a config option. Ditto for Exim. I haven't looked at Postfix in this regard (and am sitting on a slow 28.8K link right now, so I'll leave that to the reader). <> -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From chuqui@plaidworks.com Wed May 2 20:05:08 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 12:05:08 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <01050211305908.03885@graham.localdomain> Message-ID: On 5/2/01 11:30 AM, "Graham TerMarsch" wrote: > Barry, wanted to thank you muchly for the lengthy description of the > problem and the patch that you provided. I figured that this was probably > what was happening, after having gone through the process of running the > CGIs repeatedly myself here. By the by, I hate to say this, but I think this thing deserves a 2.0.5 subrelease.... From barry@digicool.com Thu May 3 09:08:52 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 04:08:52 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> <01050211305908.03885@graham.localdomain> Message-ID: <15089.4628.281146.976049@anthem.wooz.org> >>>>> "GT" == Graham TerMarsch writes: GT> Barry, wanted to thank you muchly for the lengthy description GT> of the problem and the patch that you provided. I figured GT> that this was probably what was happening, after having gone GT> through the process of running the CGIs repeatedly myself GT> here. You're welcome, and thanks for the feedback. I've committed those changes to CVS so they'll be part of 2.1. GT> As for the semantics of "save the list only if everything was GT> successful", I too believe that those are livable (and likely GT> proper) semantics to live with. I think it's the only sane thing to do. GT> Will let you know again if we continue to have this problem, GT> but from what I've seen so far this appears to have fixed the GT> major fire that I've had. Now all I've got to figure out is GT> how to try to speed up the admin CGIs so that they don't take GT> two or three minutes to load when dealing with large lists... Check to see if it's disk access. Remember you've got to load the entire marshaled dict into memory for each web hit, and that's gotta be expensive. Things will get much better for 2.1 from the email side because there'll be some caching involved (there's a long running qrunner process now), but you'll still pay the penalty on the web side. Really fixing that will be a job for Mailman 3.0. -Barry From barry@digicool.com Thu May 3 09:13:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 04:13:30 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <01050211305908.03885@graham.localdomain> Message-ID: <15089.4906.893381.544950@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> Barry, wanted to thank you muchly for the lengthy description >> of the problem and the patch that you provided. I figured that >> this was probably what was happening, after having gone through >> the process of running the CGIs repeatedly myself here. CVR> By the by, I hate to say this, but I think this thing CVR> deserves a 2.0.5 subrelease.... I was thinking the same thing. :/ I'd like to get more feedback on how important/useful you site guys think it would be. Chuq's vote is counted. :) -Barry From barry@digicool.com Thu May 3 09:14:25 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 04:14:25 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <01050211305908.03885@graham.localdomain> Message-ID: <15089.4961.73484.417761@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> By the by, I hate to say this, but I think this thing CVR> deserves a 2.0.5 subrelease.... Oh, let me add (since it's 4am :), that I also would like to get more feedback on the success of the patch. One thing I don't want to do is have 2.0.5 make things worse! -Barry From wildfire@progsoc.uts.edu.au, mailman-developers@python.org Thu May 3 17:41:04 2001 From: wildfire@progsoc.uts.edu.au, mailman-developers@python.org (Anand Kumria) Date: Fri, 4 May 2001 02:41:04 +1000 Subject: [Mailman-Developers] MHonArc integration Message-ID: <20010504024104.I28298@ftoomsh.progsoc.uts.edu.au> --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, I've just setup another mailman site and once again I wanted to integrate it with MHonArc. Previously I'd been using shell script that played games with symlinks and the the archive files behind Mailman's back. I wanted something simpler to use, so after much judicious cutting and pasting of other code I've put together MHonArc.py which you can use as an almost compatible replacement for HyperArch.py There are a number of things left to do: - generate HTML index pages properly - store text versions of the archive along with each dir. - cleanup the code and document it This is my first real experience with Python, so no laughing (too loud). I think I've also noticed a bug where Mailman uses the udnerlying Pythong rfc822 object when Mailman's is more useful -- see comments in add_article. I've also simplified the date handling (the current archiving stuff hyperarch/pipermail convert a to/from unix epoch lots of times) Doing this also made clear that a nicer interface in Archive.py could be done which should handle, imo: - message date => volume (and thus path) conversions - make the archive date format local to each list e.g. I'd like to have 2001/05/01 instead of 20010501 - generation of HTML index pages - make the HTML template editable via the admin interface - expose some way to allow list-admins to configure any options the archiver might allow (MHonArc allows a lot) Feedback on all of this welcome. Regards, Anand --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="MHonArc.py" # # Archive interface for MHonArc and Mailman # """ This attempts to simulate the HpyerArch python script but using instead MHonArc. By doing this I hope to avoid the need to have 'list rotation' and 'index generation' as external jobs 1. setup archive directory - set ARCHIVE_PERIOD to appropriate value 2. convert mbox into individual messages - figure out location to put message - convert message date to appropriate directory - create directory if needed 3. add message to archive - add message to text file in - interperlate -output and -resource into appropriate directory - execute MHonArc 4. create HTML index pages """ import sys import os import time import string from Mailman import mm_cfg from Mailman import Utils from Mailman.Logging.Syslog import syslog from Mailman.Mailbox import Mailbox from Mailman.Utils import mkdir, open_ex DIRMODE = 0755 # Mode to give to created directories FILEMODE = 0644 # Mode to give to created files INDEX_EXT = ".html" # Extension for indexes VERBOSE = 1 TOC_template='''\ The %(listname)s Archives

The %(listname)s Archives

You can get more information about this list or you can download the full raw archive (%(size)s).

%(noarchive_msg)s %(archive_listing_start)s %(archive_listing)s %(archive_listing_end)s ''' TOC_entry_template = '''\ %(archive)s: [ Thread ] [ Subject ] [ Author ] [ Date ] %(textlink)s ''' def sizeof(filename): size = os.path.getsize(filename) if size < 1000: return ' %d bytes ' % size elif size < 1000000: return ' %d KB ' % (size / 1000) # GB?? :-) return ' %d MB ' % (size / 1000000) class HyperArchive: def __init__(self, maillist): # make mailist available inside this object self.maillist = maillist # setup archive attributes if hasattr(self.maillist,'archive_volume_frequency'): if self.maillist.archive_volume_frequency == 0: self.ARCHIVE_PERIOD='year' elif self.maillist.archive_volume_frequency == 2: self.ARCHIVE_PERIOD='quarter' elif self.maillist.archive_volume_frequency == 3: self.ARCHIVE_PERIOD='week' elif self.maillist.archive_volume_frequency == 4: self.ARCHIVE_PERIOD='day' else: self.ARCHIVE_PERIOD='month' self.html_TOC_tmpl = TOC_template self.TOC_entry_tmpl = TOC_entry_template # def processUnixMailbox(self, input, articleClass = Article): def processUnixMailbox(self, input ): mbox = Mailbox(input) while 1: m = mbox.next() if not m: break self.message("constructed 0 ") self.set_msg_date_tuple(m) self.message(self.msg_date_tuple) self.make_archive(self.get_list_archive_path()) self.add_article(m) self.message("constructed 3 ") def make_archive(self, path): # If the archive directory doesn't exist, create it # recursively try: os.stat(path) except os.error, errdata: errno, errmsg = errdata if errno == 2: mkdir(path, DIRMODE) self.message("created: %s" % path) else: raise os.error, errdata def add_article(self, msg): # Using a mailbox give us (eventually) Python's # rfc822 Message object instead of Mailman's. # Here we simply reach in and do the necessary # but the real fix is to ensure Mailman ships # its own version of mailbox.py instead of # relying on Python's. # convert rfc822 Message object back into text txt = msg.unixfrom + string.join(msg.headers,'') + '\n' + msg.fp.read() self.ExternalArchive(mm_cfg.MHONARC, txt) return def message(self, msg): if VERBOSE: f = sys.stderr f.write(msg) if msg[-1:] != '\n': f.write('\n') f.flush() def ExternalArchive(self, ar, txt): l = Utils.SafeDict({'listname': self.maillist.internal_name()}) a = Utils.SafeDict({'archivedir': self.get_list_archive_path()}) cmd = ar % l cmd = cmd % a self.message("cmd = %s" % cmd) extarch = os.popen(cmd, 'w') extarch.write(txt) status = extarch.close() if status: syslog('error', 'external archiver non-zero exit status: %d\n' % (status & 0xff00) >> 8) # The following two methods should be inverses of each other. -ddm def dateToVolName(self,date): # datetuple=time.localtime(date) datetuple = date if self.ARCHIVE_PERIOD=='year': return time.strftime("%Y",datetuple) elif self.ARCHIVE_PERIOD=='quarter': if datetuple[1] in [1,2,3]: return time.strftime("%Yq1",datetuple) elif datetuple[1] in [4,5,6]: return time.strftime("%Yq2",datetuple) elif datetuple[1] in [7,8,9]: return time.strftime("%Yq3",datetuple) else: return time.strftime("%Yq4",datetuple) elif self.ARCHIVE_PERIOD == 'day': return time.strftime("%Y%m%d", datetuple) elif self.ARCHIVE_PERIOD == 'week': # Reconstruct "seconds since epoch", and subtract weekday # multiplied by the number of seconds in a day. monday = time.mktime(datetuple) - datetuple[6] * 24 * 60 * 60 # Build a new datetuple from this "seconds since epoch" value datetuple = time.localtime(monday) return time.strftime("Week-of-Mon-%Y%m%d", datetuple) # month. -ddm else: return time.strftime("%Y-%B",datetuple) ### my stuff # We convert from string to seconds since # Epoch in order to validate the date. def set_msg_date_tuple(self, message): if message.has_key('Date'): date = message.getdate_tz('Date') date, tzoffset = date[:9], date[-1] or 0 try: date = time.mktime(date) # - tzoffset date = time.localtime(date) except (ValueError, OverflowError): date = time.localtime(time.time()) else: date = time.localtime(time.time()) self.msg_date_tuple = date def get_list_archive_path(self): basedir = self.maillist.archive_dir() arch = self.dateToVolName(self.msg_date_tuple) archivedir = os.path.join(basedir, arch) return archivedir #### def write_TOC(self): # self.sortarchives() basedir = self.maillist.archive_dir() toc=open_ex(os.path.join(basedir, 'index.html'), 'w') toc.write(self.html_TOC()) toc.close() def html_TOC(self): # for know, fudge the fact we have no archives self.archives = None listname = self.maillist.internal_name() mbox = os.path.join(self.maillist.archive_directory+'.mbox', listname+'.mbox') d = {"listname": self.maillist.real_name, "listinfo": self.maillist.GetScriptURL('listinfo', absolute=1), "fullarch": '../%s.mbox/%s.mbox' % (listname, listname), "size": sizeof(mbox), } if not self.archives: d["noarchive_msg"] = '

Currently, there are no archives.

' d["archive_listing_start"] = "" d["archive_listing_end"] = "" d["archive_listing"] = "" else: d["noarchive_msg"] = "" d["archive_listing_start"] = self.arch_listing_start d["archive_listing_end"] = self.arch_listing_end accum = [] for a in self.archives: accum.append(self.html_TOC_entry(a)) d["archive_listing"] = string.join(accum, '') if not d.has_key("encoding"): d["encoding"] = "" return self.html_TOC_tmpl % d def html_TOC_entry(self, arch): # Check to see if the archive is gzip'd or not txtfile = os.path.join(mm_cfg.PRIVATE_ARCHIVE_FILE_DIR, self.maillist.internal_name(), arch + '.txt') gzfile = txtfile + '.gz' templ = '[ %(fmt)sText%(sz)s]' # which exists? .txt.gz first, then .txt if os.path.exists(gzfile): file = gzfile url = arch + '.txt.gz' fmt = "Gzip'd " elif os.path.exists(txtfile): file = txtfile url = arch + '.txt' fmt = '' else: # neither found? file = None # in Python 1.5.2 we have an easy way to get the size if file: textlink = templ % {'url': url, 'fmt': fmt, 'sz' : sizeof(file), } else: # there's no archive file at all... hmmm. textlink = '' return self.TOC_entry_tmpl % { 'archive': arch, 'textlink': textlink } def close(self): # "Close an archive, save its state, and update any changed archives." # self.update_dirty_archives() # self.update_TOC = 0 self.write_TOC() # # Save the collective state # self.message('Pickling archive state into ' \ # + os.path.join(self.basedir, 'pipermail.pck')) # self.database.close() # del self.database # # f = open(os.path.join(self.basedir, 'pipermail.pck'), 'w') # pickle.dump(self.getstate(), f) # f.close() return --m51xatjYGsM+13rf-- From mailman@howlingfrog.com Thu May 3 19:14:09 2001 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Thu, 3 May 2001 11:14:09 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <15089.4906.893381.544950@anthem.wooz.org> References: <01050211305908.03885@graham.localdomain> <15089.4906.893381.544950@anthem.wooz.org> Message-ID: <0105031114090E.07532@graham.localdomain> On Thursday 03 May 2001 01:13, Barry A. Warsaw wrote: > >>>>> "CVR" == Chuq Von Rospach writes: > >> Barry, wanted to thank you muchly for the lengthy description > >> of the problem and the patch that you provided. I figured that > >> this was probably what was happening, after having gone through > >> the process of running the CGIs repeatedly myself here. > > CVR> By the by, I hate to say this, but I think this thing > CVR> deserves a 2.0.5 subrelease.... > > I was thinking the same thing. :/ I'd like to get more feedback on > how important/useful you site guys think it would be. > > Chuq's vote is counted. :) Count my vote in; I'm all for smaller, quicker, more incremental releases (especially when they contain bugfixes). :) -- Graham TerMarsch From mailman@howlingfrog.com Thu May 3 19:17:48 2001 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Thu, 3 May 2001 11:17:48 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <15089.4961.73484.417761@anthem.wooz.org> References: <01050211305908.03885@graham.localdomain> <15089.4961.73484.417761@anthem.wooz.org> Message-ID: <0105031117480F.07532@graham.localdomain> On Thursday 03 May 2001 01:14, Barry A. Warsaw wrote: > >>>>> "CVR" == Chuq Von Rospach writes: > > CVR> By the by, I hate to say this, but I think this thing > CVR> deserves a 2.0.5 subrelease.... > > Oh, let me add (since it's 4am :), that I also would like to get more > feedback on the success of the patch. One thing I don't want to do is > have 2.0.5 make things worse! FWIW Barry, this patch appears to have just about completely solved our lockfile problems and stalled WWW pages that we were having. I used to be able to use "ab" (ApacheBench) to pound on one of the "subscribe" pages, and could just about guarantee stale/dangling lockfiles. Even at 10 requests total, 5 concurrently, this problem would appear. After applying the patch, though, I've been able to crank it up to 100 total requests, 10 concurrent, and not see any dangling/stale locks. Didn't test any further beyond that as it at least identified for me that the problem (if it was still around) wasn't anywhere near as serious or identifiable as it was previously. -- Graham TerMarsch From barry@digicool.com Thu May 3 19:41:09 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 14:41:09 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <01050211305908.03885@graham.localdomain> <15089.4961.73484.417761@anthem.wooz.org> <0105031117480F.07532@graham.localdomain> Message-ID: <15089.42565.24918.848597@anthem.wooz.org> >>>>> "GT" == Graham TerMarsch writes: GT> FWIW Barry, this patch appears to have just about completely GT> solved our lockfile problems and stalled WWW pages that we GT> were having. GT> I used to be able to use "ab" (ApacheBench) to pound on one of GT> the "subscribe" pages, and could just about guarantee GT> stale/dangling lockfiles. Even at 10 requests total, 5 GT> concurrently, this problem would appear. After applying the GT> patch, though, I've been able to crank it up to 100 total GT> requests, 10 concurrent, and not see any dangling/stale locks. GT> Didn't test any further beyond that as it at least identified GT> for me that the problem (if it was still around) wasn't GT> anywhere near as serious or identifiable as it was previously. Excellent. Thanks for the feedback. I'm definitely warming to a 2.0.5 bug fix release. -Barry From barry@digicool.com Thu May 3 20:26:38 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 15:26:38 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <009c01c0cf5b$3165c2a0$01000001@sgergo.hu> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> Message-ID: <15089.45294.645712.975619@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> So the code in admin.py looks something like: | def main(): | ... | mlist = MailList.MailList(listname, lock=0) | ... | | def sigterm_handler(signum, frame, mlist=mlist): | mlist.Unlock() | | mlist.Lock() | try: | signal.signal(signal.SIGTERM, sigterm_handler) | ... | mlist.Save() | finally: | mlist.Unlock() I think this code isn't quite right. I think to be totally safe, you want sigterm_handler() to sys.exit(0) after the call to mlist.Unlock(). Otherwise, depending on race conditions, after unlocking the list you could still enter Save(), which would fail because it would first try to refresh a lock you no longer own. I'll work up a proper patch to Mailman 2.0.4 and post it to SF for you to try. Or you could modify your patched version and test it in the meantime. -Barry From barry@digicool.com Thu May 3 22:24:50 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 17:24:50 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <009c01c0cf5b$3165c2a0$01000001@sgergo.hu> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> <15089.45294.645712.975619@anthem.wooz.org> Message-ID: <15089.52386.871196.668108@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> I think this code isn't quite right. I think to be totally BAW> safe, you want sigterm_handler() to sys.exit(0) after the BAW> call to mlist.Unlock(). Otherwise, depending on race BAW> conditions, after unlocking the list you could still enter BAW> Save(), which would fail because it would first try to BAW> refresh a lock you no longer own. BAW> I'll work up a proper patch to Mailman 2.0.4 and post it to BAW> SF for you to try. Or you could modify your patched version BAW> and test it in the meantime. On second thought, I'm only going to post the patch when I do the 2.0.5 release (which will happen tomorrow). All the changes are in the CVS Release_2_0_1-branch maintenance branch so you can check them out there for a preview. I plan on doing some more testing tomorrow before the release, but so far it looks pretty good. -Barry From benwa@ocentrix.com Fri May 4 03:50:55 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 3 May 2001 19:50:55 -0700 Subject: [Mailman-Developers] Patch to add class Img to htmlformat.py Message-ID: <200105040250.f442otL28067@mail.ocentrix.net> This is a multi-part message in MIME format. ------=_Next20010503-195055-28062-1287737225 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SSBkb24ndCBrbm93IGlmIGFueW9uZSBlbHNlIHdpbGwgZmluZCB0 aGlzIHVzZWZ1bGwsIGJ1dCBoZXJlCmdvZXMuCgotIEJlbgoKUFMg SSB1c2VkIGl0IHRvIGFkZCBhIGxvZ28gdG8gdGhlIHRvcCBvZiBz b21lIG9mIHRoZSB3ZWIKaW50ZXJmYWNlIHBhZ2VzIGZvciBleGFt cGxlIGluIGxpc3RpbmZvLnB5CgotLS08c25pcD4tLS0KZGVmIEZv cm1hdExpc3RpbmZvT3ZlcnZpZXcoZXJyb3I9Tm9uZSk6CiAgICAi UHJlc2VudCBhIGdlbmVyYWwgd2VsY29tZSBhbmQgaXRlbWl6ZSB0 aGUgKHB1YmxpYykKbGlzdHMgZm9yIHRoaXMgaG9zdC4iCiAKICAg ICMgWFhYIFdlIG5lZWQgYSBwb3J0YWJsZSB3YXkgdG8gZGV0ZXJt aW5lIHRoZSBob3N0IGJ5CndoaWNoIHdlIGFyZSBiZWluZwogICAg IyAgICAgdmlzaXRlZCEgIEFuIGFic29sdXRlIFVSTCB3b3VsZCBk by4uLgogICAgaHR0cF9ob3N0ID0gb3MuZW52aXJvbi5nZXQoJ0hU VFBfSE9TVCcsCm9zLmVudmlyb24uZ2V0KCdTRVJWRVJfTkFNRScp KQogICAgcG9ydCA9IG9zLmVudmlyb24uZ2V0KCdTRVJWRVJfUE9S VCcpCiAgICAjIHN0cmlwIG9mZiB0aGUgcG9ydCBpZiB0aGVyZSBp cyBvbmUKICAgIGlmIHBvcnQgYW5kIGh0dHBfaG9zdFstbGVuKHBv cnQpLTE6XSA9PSAnOicrcG9ydDoKICAgICAgICBodHRwX2hvc3Qg PSBodHRwX2hvc3RbOi1sZW4ocG9ydCktMV0KICAgIGlmIG1tX2Nm Zy5WSVJUVUFMX0hPU1RfT1ZFUlZJRVcgYW5kIGh0dHBfaG9zdDoK ICAgICAgICBob3N0X25hbWUgPSBodHRwX2hvc3QKICAgIGVsc2U6 CiAgICAgICAgaG9zdF9uYW1lID0gbW1fY2ZnLkRFRkFVTFRfSE9T VF9OQU1FCiAKICAgIGRvYyA9IERvY3VtZW50KCkKICAgIGxlZ2Vu ZCA9ICIlcyBNYWlsaW5nIExpc3RzIiAlIGhvc3RfbmFtZQogICAg ZG9jLlNldFRpdGxlKGxlZ2VuZCkKIAojIGxldHMgc2VlIGlmIHdl IGNhbiBpbnNlcnQgYW4gaW1hZ2UgYXQgdGhlIHRvcCBvZiB0aGlz IHBhZ2UKICAgIHRvcGxvZ28gPQpJbWcoJy9tYWlsbWFubG9nb3Mv cmlkZXJzX2Nvbm5lY3Rpb25faGVhZGVyLnBuZycsJzc1MCcsJzEx NScsIk9jZW50cml4ClJpZGVycycgQ29ubmVjdGlvbiIsJzAnKQog ICAgZG9jLkFkZEl0ZW0odG9wbG9nbykKIAogICAgdGFibGUgPSBU YWJsZShib3JkZXI9MCwgd2lkdGg9IjEwMCUiKQogCiAgICB0YWJs ZS5BZGRSb3coW0NlbnRlcihIZWFkZXIoMiwgbGVnZW5kKSldKQog CiAgICB0YWJsZS5BZGRDZWxsSW5mbyhtYXgodGFibGUuR2V0Q3Vy cmVudFJvd0luZGV4KCksIDApLCAwLAogICAgICAgICAgICAgICAg ICAgICAgY29sc3Bhbj0yLApiZ2NvbG9yPSIjOTljY2ZmIikgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKLS0tPC9zbmlwPi0t LQ== ------=_Next20010503-195055-28062-1287737225 Content-Type: application/octet-stream; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="htmlformat.py_add_image_class_patch.gz" H4sICCgM8joAA2h0bWxmb3JtYXQucHlfYWRkX2ltYWdlX2NsYXNzX3BhdGNoAI1SXU+DMBR9 Hr/i2mTZQEA+dBriTHxZNHHxYXsnDLpRw1doF52/3tsWCMbFrA/l3sM95/b01rIsKBNWlEnl BK7nhjdrnd3koiz2dVsmwm1Ok3VdwYY24PsQ+JEXROECAs/zDMdx4Dxlmx/xzwkgBP8hCu8i /15SfMP6vWSOoqEd+AtQgNRUQHgLGDsGwEQugJft+m2lOrzvPmgq5pwWe1fQL2EDqzJaCdPE auMa0iLhHF7LQ4SJXBndQxyziok4VjQbeJva8MkykduQU3bIUSUpcNvVbUbbpWdK8kT1wFpY SsaAKCJi6jugWgdhHQw46iKI+4DoJgjqoDvm6LTaaHdW7a47Ur/QeCMVCBmBbA9j/asleMrG mDDrLZIpJzOYjhmytqXi2FYwe2TlQZpWddqpDrU7HaMpHUz5k9San5+Suu1uSLZs8t9Iu6lc Wt5P79J6NeW/xep6TMzxDekHtKorsWHfNDL05RJCeggYhx1l1QGH1bQ0TQTNwIEjp4r1LEQ7 d10XnxkWLwmGxMSeXNAkc1HH+AH+4SJvfAMAAA== ------=_Next20010503-195055-28062-1287737225-- From mpaludo@ottawa.com Fri May 4 07:54:10 2001 From: mpaludo@ottawa.com (Marco Paludo) Date: Fri, 4 May 2001 02:54:10 -0400 (EDT) Subject: [Mailman-Developers] Running Solaris 8 on Intel platform with i810 chipset Message-ID: <200105040654.CAA05056@mail.ottawa.com> Hello to All, Is there a XServer to have Solaris 8 Intel platform edition running properly with the Intel 82810 chipset? As much as know, XFree86 release 4.0.3 only supports the i810 chipset for the Linux operating system. Is there a technical reason, why this hardware is not supported for the Solaris Intel platform? Also, is there any chance that the XServer for i810 will be available for Solaris in the near future? Thank you for your attention and help. Marco Paludo Get your Free email at http://mail.ottawa.com/ From barry@digicool.com Fri May 4 17:58:54 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 4 May 2001 12:58:54 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch Message-ID: <15090.57294.242909.931852@anthem.wooz.org> Hi all, I've uploaded the Mailman 2.0.5 patch and tarball to SourceForge. Please check out http://sourceforge.net/project/showfiles.php?group_id=103 I've tested this on my system and on {python,zope}.org and it seems to work well. Still, I would love to get some feedback on this specific patch before making a wider announcement (won't it be great when I have a unit test suite? :). Please give it a shot and let me know. If there are no showstoppers, I will make the announcement on Monday. Thanks, -Barry From marc_news@valinux.com Fri May 4 20:14:00 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Fri, 4 May 2001 12:14:00 -0700 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15090.57294.242909.931852@anthem.wooz.org>; from barry@digicool.com on Fri, May 04, 2001 at 12:58:54PM -0400 References: <15090.57294.242909.931852@anthem.wooz.org> Message-ID: <20010504121400.Z21233@magic.merlins.org> On Fri, May 04, 2001 at 12:58:54PM -0400, Barry A. Warsaw wrote: > > Hi all, > > I've uploaded the Mailman 2.0.5 patch and tarball to SourceForge. > Please check out > > http://sourceforge.net/project/showfiles.php?group_id=103 lynx -dump http://lists.sourceforge.net/lists/listinfo/test | grep version version 2.0.5 [7]Python Powered [8]GNU's Not Unix [9]Mailman home page The uprade procedure was a bit painful, because once again, update touched all my lists as root, recreated all the config.db files as root, which broke all the lists on my system (admittedly, that's my fault for having restricted hardlinks) This, in the update process, is what is screwing me over: - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me Can't update see that upgrading from 2.0.x to 2.0.y doesn't require that and only run it when it's really really needed? (in my case, with 10,000+ lists, it takes a really long time to run, up to 10-20mn). Would you accept a patch that made update change its uid to mailman (requiring make install to be ran as root or mailman) for everyone? The problem is that securelinux_fix is to be run after make install, and while make install is being run, and update goes through all the lists, all the lists are non functionning on my system Anyway, everything is back up now, I cleared the lock directory, and ran: find lists | grep config.db | grep -v "config.db.last" | grep -v config.db$ | xargs rm I'll try to remember to check it again on sunday night and report back. 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@digicool.com Fri May 4 21:25:52 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 4 May 2001 16:25:52 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> Message-ID: <15091.4176.978177.88211@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> The uprade procedure was a bit painful, because once again, MM> update touched all my lists as root, recreated all the MM> config.db files as root, which broke all the lists on my MM> system (admittedly, that's my fault for having restricted MM> hardlinks) | This, in the update process, is what is screwing me over: | - updating old public mbox file | looks like you have a really recent CVS installation... | you're either one brave soul, or you already ran me Close, but not quite. There's a step in bin/update, function dolist(), which sets some list attributes unconditionally. Of course, to do this, it must lock the list, change the attrs and save the list. There's a similar step in main() where the old gate_watermarks file is transformed into the usenet_watermark attribute, but that step isn't done if the gate_watermarks file isn't found (which it won't be for any 2.0.x upgrade). The problem is that while the dolist() step happens unconditionally, it only needs to be done if it updates the archive_directory or private_archive_file_dir attributes. Below is a patch to skip this step if those attrs don't need to be upgraded. MM> Would you accept a patch that made update change its uid to MM> mailman (requiring make install to be ran as root or mailman) MM> for everyone? I'm not so sure. Say I install Mailman as user `barry', I don't want to be running the upgrade as user `mailman'. Probably a better approach is to refuse to run update if the effective uid doesn't equal mm_cfg.MAILMAN_UID. On the other hand, the attached patch might be enough. On the third hand, maybe bin/update should just be culled of all ability to upgrade from a pre-2.0 revision? In that case, I'll bet bin/update can just go away. -Barry -------------------- snip snip -------------------- Index: update =================================================================== RCS file: /cvsroot/mailman/mailman/bin/update,v retrieving revision 1.24.2.1 diff -u -r1.24.2.1 update --- update 2001/03/02 23:19:33 1.24.2.1 +++ update 2001/05/04 20:25:01 @@ -80,28 +80,25 @@ def dolist(listname): errors = 0 mlist = MailList.MailList(listname, lock=0) - try: - mlist.Lock(0.5) - except TimeOutError: - print 'WARNING: could not acquire lock for list:', listname - return 1 - - mbox_dir = make_varabs('archives/private/%s.mbox' % (listname)) - mbox_file = make_varabs('archives/private/%s.mbox/%s' % (listname, - listname)) + + mbox_dir = make_varabs('archives/private/%s.mbox' % listname) + mbox_file = make_varabs('archives/private/%s.mbox/%s' % + (listname, listname)) - o_pub_mbox_file = make_varabs('archives/public/%s' % (listname)) - o_pri_mbox_file = make_varabs('archives/private/%s' % (listname)) + o_pub_mbox_file = make_varabs('archives/public/%s' % listname) + o_pri_mbox_file = make_varabs('archives/private/%s' % listname) html_dir = o_pri_mbox_file - o_html_dir = makeabs('public_html/archives/%s' % (listname)) + o_html_dir = makeabs('public_html/archives/%s' % listname) # # make the mbox directory if it's not there. # if not os.path.exists(mbox_dir): ou = os.umask(0) - os.mkdir(mbox_dir, 02775) - os.umask(ou) + try: + os.mkdir(mbox_dir, 02775) + finally: + os.umask(ou) else: # this shouldn't happen, but hey, just in case if not os.path.isdir(mbox_dir): @@ -197,10 +194,17 @@ # save the new variables and # let it create public symlinks if necessary # - mlist.archive_directory = make_varabs('archives/private/%s' % (listname)) - mlist.private_archive_file_dir = make_varabs('archives/private/%s.mbox' % - listname) - mlist.Save() + archivedir = make_varabs('archives/private/%s' % listname) + if mlist.archive_directory <> archivedir or \ + mlist.private_archive_file_dir <> mbox_dir: + print " I have to update the list's archive directory attributes" + mlist.Lock() + try: + mlist.archive_directory = archivedir + mlist.private_archive_file_dir = mbox_dir + mlist.Save() + finally: + mlist.Unlock() # # check to see if pre-b4 list-specific templates are around # and move them to the new place if there's not already @@ -222,8 +226,6 @@ else: print "- both %s and %s exist, leaving untouched" \ % (o_tmpl, n_tmpl) - # Avoid eating filehandles with the list lockfiles - mlist.Unlock() return 0 @@ -296,18 +298,14 @@ if listname not in listnames: # this list no longer exists continue - mlist = MailList.MailList(listname, lock=0) + mlist = MailList.MailList(listname) try: - mlist.Lock(0.5) - except TimeOutError: - print 'WARNING: could not acquire lock for list:', listname - errors = errors + 1 - else: # Pre 1.0b7 stored 0 in the gate_watermarks file to indicate # that no gating had been done yet. Without coercing this to # None, the list could now suddenly get flooded. mlist.usenet_watermark = d[listname] or None mlist.Save() + finally: mlist.Unlock() os.unlink(wmfile) print '- usenet watermarks updated and gate_watermarks removed' From marc_news@valinux.com Fri May 4 21:49:38 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Fri, 4 May 2001 13:49:38 -0700 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15091.4176.978177.88211@anthem.wooz.org>; from barry@digicool.com on Fri, May 04, 2001 at 04:25:52PM -0400 References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> <15091.4176.978177.88211@anthem.wooz.org> Message-ID: <20010504134938.C21233@magic.merlins.org> On Fri, May 04, 2001 at 04:25:52PM -0400, Barry A. Warsaw wrote: > The problem is that while the dolist() step happens unconditionally, > it only needs to be done if it updates the archive_directory or > private_archive_file_dir attributes. Below is a patch to skip this > step if those attrs don't need to be upgraded. Great, thanks. > MM> Would you accept a patch that made update change its uid to > MM> mailman (requiring make install to be ran as root or mailman) > MM> for everyone? > > I'm not so sure. Say I install Mailman as user `barry', I don't want > to be running the upgrade as user `mailman'. Yeah, I figured that afterwards. Fair enough. > Probably a better approach is to refuse to run update if the effective > uid doesn't equal mm_cfg.MAILMAN_UID. On the other hand, the attached Mmmh, that will fail for you when you do make install as barry, then. Letme think. How about if euid != mm_cfg.MAILMAN_UID: if euid == 0 setgid (mm_cfg.MAILMAN_GID) setuid (mm_cfg.MAILMAN_UID) This way, when you install as root, it setuids to mailman first, if you install as mailman, everything is fine too, and if you install as barry, that continues to work (although it obviously won't work with restricted hardlinks) > patch might be enough. On the third hand, maybe bin/update should > just be culled of all ability to upgrade from a pre-2.0 revision? In > that case, I'll bet bin/update can just go away. The upgrade code is probably useful to some. I don't mind it myself as long as it doesn't try to run on my machines when I upgrade from 2.0.x to 2.0.y. :-) I'll apply your patch to my tree when I upgrade mailman on my 3 other list servers, and I'll report back. Thanks, 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 tollef@add.no Sat May 5 12:11:19 2001 From: tollef@add.no (Tollef Fog Heen) Date: 05 May 2001 13:11:19 +0200 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15091.4176.978177.88211@anthem.wooz.org> References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> <15091.4176.978177.88211@anthem.wooz.org> Message-ID: <87zocst5ig.fsf@arabella.intern.opera.no> * (Barry A. Warsaw) | On the third hand, maybe bin/update should just be culled of all | ability to upgrade from a pre-2.0 revision? In that case, I'll bet | bin/update can just go away. Please, please, please, please don't do that. It will force me to maintain that code in Debian, because Debian stable has an old version (1.1) and we absolutely need to have a clean upgrade path. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From Chopp@cusquena.com.pe Sat May 5 19:11:28 2001 From: Chopp@cusquena.com.pe (=?iso-8859-1?Q?CLUB_CUSQUE=D1A?=) Date: Sat, 5 May 2001 13:11:28 -0500 Subject: [Mailman-Developers] =?iso-8859-1?Q?Promoci=F3n_Chopp_Cusque=F1a?= Message-ID: <06cc82811180551CMPS1@cmps1.collectivemind.com.pe> This is a multi-part message in MIME format. ------=_NextPart_000_1F3B5_01C0D564.E4F2B0D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ..P=EDdelo=20 AQU=CD =20 =20 =20 =20 Como hacer el pedido?=20 Solo necesitas llenar tus datos en el=20 formulario de pedidos de CHOPP...=20 y LISTO!!!=20 RD: 152-2001-IN-1501=20 Visita el Web site de Cerveza Cusque=F1a en:=20 http://www.cusquena.com.pe=20 Si quieres entrar al Chat Cusque=F1a haz click Aqu=ED =20 Recibes este e-mail porque estas suscrito al CLUB CUSQUE=D1A o un amigo tuyo te ha recomendado. Para cancelar el env=EDo de este email, reenv=EDanos este email con el t=EDtulo: QUITARME DE LA LISTA=20 ------=_NextPart_000_1F3B5_01C0D564.E4F2B0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable www.cusquena.com.pe - Chopp

...P=EDdelo
   AQU=CD

      

Como hacer el pedido?
Solo necesitas llenar tus = datos en el
formulario de pedidos de CHOPP...
y LISTO!!!

RD: 152-2001-IN-1501


Visita el Web site de Cerveza Cusque=F1a en:
http://www.cusquena.com.pe


Si quieres entrar al Chat Cusque=F1a haz click Aqu=ED


Recibes este e-mail porque estas suscrito al CLUB CUSQUE=D1A o un amigo tuyo te ha recomendado.
Para cancelar el env=EDo de este email, reenv=EDanos este email con el t=EDtulo: QUITARME DE LA LISTA ------=_NextPart_000_1F3B5_01C0D564.E4F2B0D0-- From marc_news@valinux.com Mon May 7 02:13:46 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Sun, 6 May 2001 18:13:46 -0700 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <20010504121400.Z21233@magic.merlins.org>; from marc_news@valinux.com on Fri, May 04, 2001 at 12:14:00PM -0700 References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> Message-ID: <20010506181345.G19166@magic.merlins.org> On Fri, May 04, 2001 at 12:14:00PM -0700, Marc MERLIN wrote: > I'll try to remember to check it again on sunday night and report back. Just for info: No stale locks showed up over the weekend with 2.0.5, and messages are still happily flowing. 2.0.5 looks good. Thanks Barry 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@digicool.com Mon May 7 02:44:55 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 6 May 2001 21:44:55 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch References: <15090.57294.242909.931852@anthem.wooz.org> Message-ID: <15093.65047.483993.636622@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> I've uploaded the Mailman 2.0.5 patch and tarball to BAW> SourceForge. Please check out The 2.0.5 tarball had a bug in the admindb.py. Thanks to Phil Barnett who helped discover this. The patch file did not have the bug. I've just uploaded a new 2.0.5 tarball, and will be sending out the announcements tomorrow morning. Cheers, -Barry From barry@digicool.com Mon May 7 02:57:52 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 6 May 2001 21:57:52 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> <20010506181345.G19166@magic.merlins.org> Message-ID: <15094.288.916835.668815@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Just for info: No stale locks showed up over the weekend with MM> 2.0.5, and messages are still happily flowing. MM> 2.0.5 looks good. Yay! MM> Thanks Barry MM> Marc You're very welcome, thanks for the feedback. Announcements go out tomorrow. -Barry From midnight@the-oasis.net Mon May 7 05:20:36 2001 From: midnight@the-oasis.net (Phil Barnett) Date: Mon, 7 May 2001 00:20:36 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15093.65047.483993.636622@anthem.wooz.org> Message-ID: <3AF5EA54.19456.76935707@localhost> On 6 May 2001, at 21:44, Barry A. Warsaw wrote: > >>>>> "BAW" == Barry A Warsaw writes: > > BAW> I've uploaded the Mailman 2.0.5 patch and tarball to > BAW> SourceForge. Please check out > > The 2.0.5 tarball had a bug in the admindb.py. Thanks to Phil Barnett > who helped discover this. The patch file did not have the bug. > > I've just uploaded a new 2.0.5 tarball, and will be sending out the > announcements tomorrow morning. Confiming: The new tarball works great. Thanks. -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net From barry@digicool.com Mon May 7 17:24:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 7 May 2001 12:24:16 -0400 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 Message-ID: <15094.52272.753043.181192@anthem.wooz.org> Folks, I've just released Mailman 2.0.5 which fixes a problem with stale lock files that can occur under certain situations when the user hits the `Stop' button on their browser. These stale lock files can cause mailing lists to be inaccessible for long periods of time (until the stale lock file times out or is manually removed). As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.4. You /must/ update your source to 2.0.4 before applying the 2.0.5 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.5 source tree and apply it like so: % patch -p0 < mailman-2.0.4-2.0.5.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net My thanks to those of you who gave the 2.0.5 pre-release a try! Enjoy, -Barry Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.5 retrieving revision 1.25.2.6 diff -u -r1.25.2.5 -r1.25.2.6 --- NEWS 2001/04/18 10:45:54 1.25.2.5 +++ NEWS 2001/05/03 21:06:56 1.25.2.6 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.5 (04-May-2001) + + Fix a lock stagnation problem that can result when the user hits + the `stop' button on their browser during a write operation that + can take a long time (e.g. hitting the membership management admin + page). + 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.4 retrieving revision 1.20.2.5 diff -u -r1.20.2.4 -r1.20.2.5 --- Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 +++ Mailman/Version.py 2001/05/03 20:58:19 1.20.2.5 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.4" +VERSION = "2.0.5" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 4 +MICRO_REV = 5 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.82.2.2 retrieving revision 1.82.2.3 diff -u -r1.82.2.2 -r1.82.2.3 --- Mailman/Cgi/admin.py 2001/01/03 16:47:47 1.82.2.2 +++ Mailman/Cgi/admin.py 2001/05/03 21:03:48 1.82.2.3 @@ -18,11 +18,13 @@ """ +import sys import os import cgi import string import types import rfc822 +import signal from Mailman import Utils from Mailman import MailList @@ -63,53 +65,86 @@ # get the list object listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: FormatAdminOverview('No such list %s' % listname) syslog('error', 'Someone tried to access the admin interface for a ' 'non-existent list: %s' % listname) return + + if len(parts) == 1: + category = 'general' + category_suffix = '' + else: + category = parts[1] + category_suffix = category + + # If the user is not authenticated, we're done. + cgidata = cgi.FieldStorage(keep_blank_values=1) try: - if len(parts) == 1: - category = 'general' - category_suffix = '' - else: - category = parts[1] - category_suffix = category - - # If the user is not authenticated, we're done. - cgidata = cgi.FieldStorage(keep_blank_values=1) - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admin', e.message) - return - - # Is this a log-out request? - if category == 'logout': - print mlist.ZapCookie('admin') - Auth.loginpage(mlist, 'admin', frontpage=1) - return - - if category not in map(lambda x: x[0], CATEGORIES): - category = 'general' - - # is the request for variable details? - varhelp = None - if cgidata.has_key('VARHELP'): - varhelp = cgidata['VARHELP'].value - elif cgidata.has_key('request_login') and \ - os.environ.get('QUERY_STRING'): - # POST methods, even if their actions have a query string, don't - # get put into FieldStorage's keys :-( - qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') - if qs and type(qs) == types.ListType: - varhelp = qs[0] - if varhelp: - FormatOptionHelp(doc, varhelp, mlist) - print doc.Format(bgcolor="#ffffff") - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admin', e.message) + return + + # Is this a log-out request? + if category == 'logout': + print mlist.ZapCookie('admin') + Auth.loginpage(mlist, 'admin', frontpage=1) + return + + if category not in map(lambda x: x[0], CATEGORIES): + category = 'general' + # is the request for variable details? + varhelp = None + if cgidata.has_key('VARHELP'): + varhelp = cgidata['VARHELP'].value + elif cgidata.has_key('request_login') and \ + os.environ.get('QUERY_STRING'): + # POST methods, even if their actions have a query string, don't + # get put into FieldStorage's keys :-( + qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') + if qs and type(qs) == types.ListType: + varhelp = qs[0] + if varhelp: + FormatOptionHelp(doc, varhelp, mlist) + print doc.Format(bgcolor="#ffffff") + return + + # From this point on, the MailList object must be locked. However, we + # must release the lock no matter how we exit. try/finally isn't + # enough, because of this scenario: user hits the admin page which may + # take a long time to render; user gets bored and hits the browser's + # STOP button; browser shuts down socket; server tries to write to + # broken socket and gets a SIGPIPE. Under Apache 1.3/mod_cgi, Apache + # catches this SIGPIPE (I presume it is buffering output from the cgi + # script), then turns around and SIGTERMs the cgi process. Apache + # waits three seconds and then SIGKILLs the cgi process. We /must/ + # catch the SIGTERM and do the most reasonable thing we can in as + # short a time period as possible. If we get the SIGKILL we're + # screwed (because its uncatchable and we'll have no opportunity to + # clean up after ourselves). + # + # This signal handler catches the SIGTERM and unlocks the list. The + # effect of this is that the changes made to the MailList object will + # be aborted, which seems like the only sensible semantics. + # + # BAW: This may not be portable to other web servers or cgi execution + # models. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + if cgidata.has_key('bounce_matching_headers'): pairs = mlist.parse_matching_header_opt() @@ -135,8 +170,12 @@ FormatConfiguration(doc, mlist, category, category_suffix, cgidata) print doc.Format(bgcolor="#ffffff") - finally: mlist.Save() + finally: + # Now be sure to unlock the list. It's okay if we get a signal here + # because essentially, the signal handler will do the same thing. And + # unlocking is unconditional, so it's not an error if we unlock while + # we're already unlocked. mlist.Unlock() Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.36.2.1 retrieving revision 1.36.2.4 diff -u -r1.36.2.1 -r1.36.2.4 --- Mailman/Cgi/admindb.py 2001/03/03 06:02:01 1.36.2.1 +++ Mailman/Cgi/admindb.py 2001/05/04 15:54:23 1.36.2.4 @@ -16,10 +16,12 @@ """Produce and process the pending-approval items for a list.""" +import sys import os import string import types import cgi +import signal from errno import ENOENT from Mailman import mm_cfg @@ -62,7 +64,7 @@ return # now that we have the list name, create the list object try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: handle_no_list(doc, 'No such list %s

' % listname) syslog('error', 'No such list "%s": %s\n' % (listname, e)) @@ -71,14 +73,34 @@ # now we must authorize the user to view this page, and if they are, to # handle both the printing of the current outstanding requests, and the # selected actions + cgidata = cgi.FieldStorage() try: - cgidata = cgi.FieldStorage() - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admindb', e.message) - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admindb', e.message) + return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + # If this is a form submission, then we'll process the requests and # print the results. otherwise (there are no keys in the form), we'll # print out the list of pending requests @@ -91,8 +113,8 @@ PrintRequests(mlist, doc) text = doc.Format(bgcolor="#ffffff") print text - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/handle_opts.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/handle_opts.py,v retrieving revision 1.30 retrieving revision 1.30.2.2 diff -u -r1.30 -r1.30.2.2 --- Mailman/Cgi/handle_opts.py 2000/11/09 16:19:03 1.30 +++ Mailman/Cgi/handle_opts.py 2001/05/03 21:05:06 1.30.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import mm_cfg from Mailman import Utils @@ -61,7 +62,7 @@ user = parts[1] try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) @@ -69,10 +70,30 @@ syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, user, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/subscribe.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v retrieving revision 1.29 retrieving revision 1.29.2.1 diff -u -r1.29 -r1.29.2.1 --- Mailman/Cgi/subscribe.py 2000/09/29 00:05:05 1.29 +++ Mailman/Cgi/subscribe.py 2001/05/03 21:05:43 1.29.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import Utils from Mailman import MailList @@ -41,18 +42,38 @@ listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) - mlist.IsListInitialized() + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) print doc.Format(bgcolor="#ffffff") syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.5 retrieving revision 1.5.2.6 diff -u -r1.5.2.5 -r1.5.2.6 --- admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 +++ admin/www/download.ht 2001/05/03 21:09:36 1.5.2.6 @@ -65,9 +65,9 @@

Downloading

Version -(2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:

    Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.7 retrieving revision 1.6.2.8 diff -u -r1.6.2.7 -r1.6.2.8 --- admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 +++ admin/www/download.html 2001/05/03 21:09:36 1.6.2.8 @@ -1,6 +1,6 @@ - + 2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:
      From josh@ernestallen.com Mon May 7 19:01:03 2001 From: josh@ernestallen.com (Joshua Erdman) Date: Mon, 7 May 2001 11:01:03 -0700 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <001101c0d71f$af1d60b0$02930440@tron> When you say to CD into our sourcetree, is that the location where I originally compiled mailman or is that where I have the current working copy of the software? Joshua Erdman Ernest & Allen, Inc. CIO/Network Systems Administrator Tel (805) 781-0317 Fax (805) 781-0725 josh@ernestallen.com -----Original Message----- From: mailman-announce-admin@python.org [mailto:mailman-announce-admin@python.org]On Behalf Of Barry A. Warsaw Sent: Monday, May 07, 2001 9:24 AM To: mailman-announce@python.org Cc: mailman-developers@python.org Subject: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 Folks, I've just released Mailman 2.0.5 which fixes a problem with stale lock files that can occur under certain situations when the user hits the `Stop' button on their browser. These stale lock files can cause mailing lists to be inaccessible for long periods of time (until the stale lock file times out or is manually removed). As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.4. You /must/ update your source to 2.0.4 before applying the 2.0.5 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.5 source tree and apply it like so: % patch -p0 < mailman-2.0.4-2.0.5.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net My thanks to those of you who gave the 2.0.5 pre-release a try! Enjoy, -Barry Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.5 retrieving revision 1.25.2.6 diff -u -r1.25.2.5 -r1.25.2.6 --- NEWS 2001/04/18 10:45:54 1.25.2.5 +++ NEWS 2001/05/03 21:06:56 1.25.2.6 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.5 (04-May-2001) + + Fix a lock stagnation problem that can result when the user hits + the `stop' button on their browser during a write operation that + can take a long time (e.g. hitting the membership management admin + page). + 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.4 retrieving revision 1.20.2.5 diff -u -r1.20.2.4 -r1.20.2.5 --- Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 +++ Mailman/Version.py 2001/05/03 20:58:19 1.20.2.5 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.4" +VERSION = "2.0.5" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 4 +MICRO_REV = 5 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.82.2.2 retrieving revision 1.82.2.3 diff -u -r1.82.2.2 -r1.82.2.3 --- Mailman/Cgi/admin.py 2001/01/03 16:47:47 1.82.2.2 +++ Mailman/Cgi/admin.py 2001/05/03 21:03:48 1.82.2.3 @@ -18,11 +18,13 @@ """ +import sys import os import cgi import string import types import rfc822 +import signal from Mailman import Utils from Mailman import MailList @@ -63,53 +65,86 @@ # get the list object listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: FormatAdminOverview('No such list %s' % listname) syslog('error', 'Someone tried to access the admin interface for a ' 'non-existent list: %s' % listname) return + + if len(parts) == 1: + category = 'general' + category_suffix = '' + else: + category = parts[1] + category_suffix = category + + # If the user is not authenticated, we're done. + cgidata = cgi.FieldStorage(keep_blank_values=1) try: - if len(parts) == 1: - category = 'general' - category_suffix = '' - else: - category = parts[1] - category_suffix = category - - # If the user is not authenticated, we're done. - cgidata = cgi.FieldStorage(keep_blank_values=1) - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admin', e.message) - return - - # Is this a log-out request? - if category == 'logout': - print mlist.ZapCookie('admin') - Auth.loginpage(mlist, 'admin', frontpage=1) - return - - if category not in map(lambda x: x[0], CATEGORIES): - category = 'general' - - # is the request for variable details? - varhelp = None - if cgidata.has_key('VARHELP'): - varhelp = cgidata['VARHELP'].value - elif cgidata.has_key('request_login') and \ - os.environ.get('QUERY_STRING'): - # POST methods, even if their actions have a query string, don't - # get put into FieldStorage's keys :-( - qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') - if qs and type(qs) == types.ListType: - varhelp = qs[0] - if varhelp: - FormatOptionHelp(doc, varhelp, mlist) - print doc.Format(bgcolor="#ffffff") - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admin', e.message) + return + + # Is this a log-out request? + if category == 'logout': + print mlist.ZapCookie('admin') + Auth.loginpage(mlist, 'admin', frontpage=1) + return + + if category not in map(lambda x: x[0], CATEGORIES): + category = 'general' + # is the request for variable details? + varhelp = None + if cgidata.has_key('VARHELP'): + varhelp = cgidata['VARHELP'].value + elif cgidata.has_key('request_login') and \ + os.environ.get('QUERY_STRING'): + # POST methods, even if their actions have a query string, don't + # get put into FieldStorage's keys :-( + qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') + if qs and type(qs) == types.ListType: + varhelp = qs[0] + if varhelp: + FormatOptionHelp(doc, varhelp, mlist) + print doc.Format(bgcolor="#ffffff") + return + + # From this point on, the MailList object must be locked. However, we + # must release the lock no matter how we exit. try/finally isn't + # enough, because of this scenario: user hits the admin page which may + # take a long time to render; user gets bored and hits the browser's + # STOP button; browser shuts down socket; server tries to write to + # broken socket and gets a SIGPIPE. Under Apache 1.3/mod_cgi, Apache + # catches this SIGPIPE (I presume it is buffering output from the cgi + # script), then turns around and SIGTERMs the cgi process. Apache + # waits three seconds and then SIGKILLs the cgi process. We /must/ + # catch the SIGTERM and do the most reasonable thing we can in as + # short a time period as possible. If we get the SIGKILL we're + # screwed (because its uncatchable and we'll have no opportunity to + # clean up after ourselves). + # + # This signal handler catches the SIGTERM and unlocks the list. The + # effect of this is that the changes made to the MailList object will + # be aborted, which seems like the only sensible semantics. + # + # BAW: This may not be portable to other web servers or cgi execution + # models. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + if cgidata.has_key('bounce_matching_headers'): pairs = mlist.parse_matching_header_opt() @@ -135,8 +170,12 @@ FormatConfiguration(doc, mlist, category, category_suffix, cgidata) print doc.Format(bgcolor="#ffffff") - finally: mlist.Save() + finally: + # Now be sure to unlock the list. It's okay if we get a signal here + # because essentially, the signal handler will do the same thing. And + # unlocking is unconditional, so it's not an error if we unlock while + # we're already unlocked. mlist.Unlock() Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.36.2.1 retrieving revision 1.36.2.4 diff -u -r1.36.2.1 -r1.36.2.4 --- Mailman/Cgi/admindb.py 2001/03/03 06:02:01 1.36.2.1 +++ Mailman/Cgi/admindb.py 2001/05/04 15:54:23 1.36.2.4 @@ -16,10 +16,12 @@ """Produce and process the pending-approval items for a list.""" +import sys import os import string import types import cgi +import signal from errno import ENOENT from Mailman import mm_cfg @@ -62,7 +64,7 @@ return # now that we have the list name, create the list object try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: handle_no_list(doc, 'No such list %s

      ' % listname) syslog('error', 'No such list "%s": %s\n' % (listname, e)) @@ -71,14 +73,34 @@ # now we must authorize the user to view this page, and if they are, to # handle both the printing of the current outstanding requests, and the # selected actions + cgidata = cgi.FieldStorage() try: - cgidata = cgi.FieldStorage() - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admindb', e.message) - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admindb', e.message) + return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + # If this is a form submission, then we'll process the requests and # print the results. otherwise (there are no keys in the form), we'll # print out the list of pending requests @@ -91,8 +113,8 @@ PrintRequests(mlist, doc) text = doc.Format(bgcolor="#ffffff") print text - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/handle_opts.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/handle_opts.py,v retrieving revision 1.30 retrieving revision 1.30.2.2 diff -u -r1.30 -r1.30.2.2 --- Mailman/Cgi/handle_opts.py 2000/11/09 16:19:03 1.30 +++ Mailman/Cgi/handle_opts.py 2001/05/03 21:05:06 1.30.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import mm_cfg from Mailman import Utils @@ -61,7 +62,7 @@ user = parts[1] try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) @@ -69,10 +70,30 @@ syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, user, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/subscribe.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v retrieving revision 1.29 retrieving revision 1.29.2.1 diff -u -r1.29 -r1.29.2.1 --- Mailman/Cgi/subscribe.py 2000/09/29 00:05:05 1.29 +++ Mailman/Cgi/subscribe.py 2001/05/03 21:05:43 1.29.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import Utils from Mailman import MailList @@ -41,18 +42,38 @@ listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) - mlist.IsListInitialized() + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) print doc.Format(bgcolor="#ffffff") syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.5 retrieving revision 1.5.2.6 diff -u -r1.5.2.5 -r1.5.2.6 --- admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 +++ admin/www/download.ht 2001/05/03 21:09:36 1.5.2.6 @@ -65,9 +65,9 @@

      Downloading

      Version -(2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:

        Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.7 retrieving revision 1.6.2.8 diff -u -r1.6.2.7 -r1.6.2.8 --- admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 +++ admin/www/download.html 2001/05/03 21:09:36 1.6.2.8 @@ -1,6 +1,6 @@ - + 2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:
          _______________________________________________ Mailman-announce mailing list Mailman-announce@python.org http://mail.python.org/mailman/listinfo/mailman-announce From barry@digicool.com Mon May 7 19:05:08 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 7 May 2001 14:05:08 -0400 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 References: <15094.52272.753043.181192@anthem.wooz.org> <001101c0d71f$af1d60b0$02930440@tron> Message-ID: <15094.58324.448018.842017@anthem.wooz.org> >>>>> "JE" == Joshua Erdman writes: JE> When you say to CD into our sourcetree, is that the location JE> where I originally compiled mailman or is that where I have JE> the current working copy of the software? It's the directory where you original did the "configure; make install" I.e. not /home/mailman. -Barry From ricardo@rixhq.nu Mon May 7 22:37:10 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Mon, 7 May 2001 23:37:10 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010501104121.P16486@xs4all.nl>; from thomas@xs4all.net on Tue, May 01, 2001 at 10:41:21AM +0200 References: <20010428123324.A1102@rix.rixhq.nu> <20010428132341.C1102@rix.rixhq.nu> <20010501104121.P16486@xs4all.nl> Message-ID: <20010507233710.I1983@rix.rixhq.nu> I finally got a bit of time to respond to this thread... On Tue, May 01, 2001 at 10:41:21AM +0200, Thomas Wouters wrote: > > > Anyway my point is that now I'm getting some complaints from members about > > > receiving empty digests (it only says the number of posts which should be in > > > there) I'm not sure yet what they are missing but I was wondering if I > > > could have messed things about by interrupting the process w/o a m.Save()? > > uh oh please don't tell me that when mailman sends out digests, they travel through the > > /etc/aliases addresses cause that would mean a neat little perl script I > It depends on the delivery method you chose. If you use the Sendmail module, > it'll probably pass it through /etc/aliases. If you use the SMTP module and > the localhost as delivery point, it'll pass through /etc/aliases too. It's > damned easy to test, though: disable the filter, make a new digest list, > subscribe yourself to it, and mail ;) After a few days I have to conclude that the problem is probably on the client side... I'm using the SMTPDirect/localhost but the MIME digests are NOT filtered out by the perl script (I changed my own subscription from plain to digest and it arrives perfectly in my mailbox)... One of the complaints was from somebody using an Hotmail account but I doubt that hotmail could have any problems with mime digest (I don't really feel like trying it out with hotmail myself... as a list admin you develop a certain hate feeling towards unreliable erm... free email services ;-( ) OTH I was just thinking that some users are not smart enough to notice that the actual messages are at the bottom of the message as a bunch of icons or whatever way their email client displays mime digest... wouldn't surprise me to be honest... Regards, Ricardo -- International Janet Jackson fanclub called MISS JANET. For more information write to: Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands Email: fanclub@miss-janet.com Check out our website: http://miss-janet.com From josh@ernestallen.com Tue May 8 00:56:44 2001 From: josh@ernestallen.com (Joshua Erdman) Date: Mon, 7 May 2001 16:56:44 -0700 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <002801c0d751$5f81f890$02930440@tron> Since installing Mailman I have noticed the size of my backups increasing steadily. I did some investigating and noticed the size of the log file in the mailman/logs directory. By adding a few lines of code to your /etc/logrotate.conf file you can have these log files rotated just like all the log files in /var/logs Some quick info about the /etc/logrotate.conf file At the top are the global settings with a comment for each one Mine had: -- Beginning of lines added to logrotate.conf -- # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # e-mail errors to root errors root # create new (empty) log files after rotating old ones with the same # security settings as the ones already rotated. create "/home/mailman/logs/post" { } "/home/mailman/logs/smtp" { compress } "/home/mailman/logs/smtp-failure" { } "/home/mailman/logs/subscribe" { } "/home/mailman/logs/bounce" { } "/home/mailman/logs/vette" { } "/home/mailman/logs/qrunner" { } "/home/mailman/logs/error" { } "/home/mailman/logs/digest" { } --End logrotate.conf If you have any questions about setting up logrotate or extra features, look at your man pages. Joshua Erdman Ernest & Allen, Inc. CIO/Network Systems Administrator Tel (805) 781-0317 Fax (805) 781-0725 josh@ernestallen.com From trey@anvils.org Tue May 8 05:16:24 2001 From: trey@anvils.org (Trey Valenta) Date: Mon, 7 May 2001 21:16:24 -0700 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: "Joshua Erdman" "[Mailman-Developers] Rotating Logs with Mailman" (May 7, 16:56) Message-ID: <20010508041624.13939.qmail@zipcon.net> On 2001 May 7, 16:56, "Joshua Erdman" wrote: } Subject: [Mailman-Developers] Rotating Logs with Mailman > Since installing Mailman I have noticed the size of my backups increasing > steadily. I did some investigating and noticed the size of the log file in > the mailman/logs directory. By adding a few lines of code to your > /etc/logrotate.conf file you can have these log files rotated just like all > the log files in /var/logs > Ummm..... you're assuming that everyone runs RedHat and has a logrotate.conf. -- trey valenta trey@anvils.org seattle (maybe a) random quote--v Nature always sides with the hidden flaw. From chuqui@plaidworks.com Tue May 8 06:07:21 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 07 May 2001 22:07:21 -0700 Subject: [Mailman-Developers] InSTALL questions... Message-ID: Barry, I'm upgrading to 2.0.5, and a couple of thoughts... In the INSTALL file: You must have the Python interpreter installed somewhere on your system. Currently Python 1.5.2 or later is required (Python 2.0 should work fine). For information about obtaining Python source code, RPM packages, or pre-compiled binaries please see: Do you want to now recommend Python 2.0 over 1.5.2? Or say something more definitive than "should work fine"? Isn't 2.0 the recommended version now? There's a similar comment in README The UPGRADING file stops at 2.0.2. It probably makes sense to add a "if you're upgrading from any 2.0 release...." Looks good so far... From tollef@add.no Tue May 8 07:48:16 2001 From: tollef@add.no (Tollef Fog Heen) Date: 08 May 2001 08:48:16 +0200 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: <20010508041624.13939.qmail@zipcon.net> References: <20010508041624.13939.qmail@zipcon.net> Message-ID: <8766fc2v67.fsf@arabella.intern.opera.no> * Trey Valenta | Ummm..... you're assuming that everyone runs RedHat and has a | logrotate.conf. Debian has logrotate as well. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From richarde@eskom.co.za Tue May 8 08:46:51 2001 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Tue, 08 May 2001 09:46:51 +0200 Subject: [Mailman-Developers] Explanation required after upgrade to 2.0.5 Message-ID: I have just upgraded mailman from 1.1 to 2.0.5 - everything went smoothly, = but I have some minor issues though. 1) When the news gate service tries to connect to a down NNTP server, ugly = messages are logged in the error log. Maybe the fact should rather just be = logged in the fromusenet log? Here is an example: Traceback (innermost last): File "/home/mailman/cron/gate_news", line 222, in ? main() File "/home/mailman/cron/gate_news", line 203, in main process_lists(lock) File "/home/mailman/cron/gate_news", line 148, in process_lists conn, first, last =3D open_newsgroup(mlist) File "/home/mailman/cron/gate_news", line 75, in open_newsgroup password=3Dmm_cfg.NNTP_PASSWORD) File "/home/mailman/Mailman/pythonlib/nntplib.py", line 111, in __init__ self.sock.connect((self.host, self.port)) socket.error: (111, 'Connection refused') 2) I get another funny error also from the news gateway. I cannot explain = it though: Traceback (innermost last): File "/home/mailman/cron/gate_news", line 222, in ? main() File "/home/mailman/cron/gate_news", line 203, in main process_lists(lock) File "/home/mailman/cron/gate_news", line 148, in process_lists conn, first, last =3D open_newsgroup(mlist) File "/home/mailman/cron/gate_news", line 75, in open_newsgroup password=3Dmm_cfg.NNTP_PASSWORD) File "/home/mailman/Mailman/pythonlib/nntplib.py", line 114, in __init__ self.welcome =3D self.getresp() File "/home/mailman/Mailman/pythonlib/nntplib.py", line 180, in getresp resp =3D self.getline() File "/home/mailman/Mailman/pythonlib/nntplib.py", line 172, in getline if not line: raise EOFError EOFError 3) Something is funny with bounce detection. My test list has the = following bounce options: Minimum number of posts to the list since members first bounce before we consider removing them from the list =3D 3 Action when critical or excessive bounces are detected =3D Remove and = notify me The list also requires post approval from the moderator I get this in the log when sending a couple of message to the list with a = bogus address that I added manually: May 07 17:41:00 2001 (8803) Test: kajshd@eskom.co.za - first May 08 09:01:01 2001 (29662) Test: kajshd@eskom.co.za - 1 more allowed = over 376799 secs May 08 09:01:01 2001 (29662) Test: kajshd@eskom.co.za - 1 more allowed = over 376799 secs May 08 09:15:01 2001 (32675) Test: kajshd@eskom.co.za - 0 more allowed = over 375958 secs May 08 09:24:01 2001 (2018) Test: kajshd@eskom.co.za - 0 more allowed over = 375418 secs I don't understand the sequence of numbers - why 0 0 then 1 1? The address = does not get removed after three failures. I have sent more tests and they = all say 0 more allowed - what gives? -- Richard Ellerbrock richarde@eskom.co.za From richarde@eskom.co.za Tue May 8 08:51:51 2001 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Tue, 08 May 2001 09:51:51 +0200 Subject: [Mailman-Developers] Rotating Logs with Mailman Message-ID: I don't think it should be a problem to add it as a contrib to mailman - I = have also written such a script and think it would be most useful if = something was included. There is a better way of doing it though. Rather just drop a dedicated = script in the /etc/logrotate.d directory called mailman. These scripts are = automagically executed when it is time to do logrotation. No need to = modify the main logrotate.conf file. -- Richard Ellerbrock richarde@eskom.co.za >>> Tollef Fog Heen 2001/05/08 08:48:16 >>> * Trey Valenta=20 | Ummm..... you're assuming that everyone runs RedHat and has a | logrotate.conf. Debian has logrotate as well. --=20 Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org=20 http://mail.python.org/mailman/listinfo/mailman-developers From claw@kanga.nu Tue May 8 09:41:03 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 08 May 2001 01:41:03 -0700 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: Message from Tollef Fog Heen of "08 May 2001 08:48:16 +0200." <8766fc2v67.fsf@arabella.intern.opera.no> References: <20010508041624.13939.qmail@zipcon.net> <8766fc2v67.fsf@arabella.intern.opera.no> Message-ID: <4094.989311263@kanga.nu> On 08 May 2001 08:48:16 +0200 Tollef Fog Heen wrote: > * Trey Valenta | Ummm..... you're assuming that everyone runs > RedHat and has a | logrotate.conf. > Debian has logrotate as well. Debian's Mailman package automatically inserts the appropriate logrotate files as part of the package install. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From barry@digicool.com Tue May 8 14:51:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 8 May 2001 09:51:40 -0400 Subject: [Mailman-Developers] InSTALL questions... References: Message-ID: <15095.63980.52400.171288@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Barry, I'm upgrading to 2.0.5, and a couple of thoughts... CVR> In the INSTALL file: CVR> You must have the Python interpreter installed somewhere CVR> on your system. Currently Python 1.5.2 or later is required CVR> (Python 2.0 should work fine). For information about CVR> obtaining Python source code, RPM packages, or pre-compiled CVR> binaries please see: CVR> Do you want to now recommend Python 2.0 over 1.5.2? Or say CVR> something more definitive than "should work fine"? Isn't 2.0 CVR> the recommended version now? I'd /recommend/ Python 2.0 or 2.1, but for the Mailman 2.0.x series only Python 1.5.2 is required. It's getting harder and harder to work with the Mailman 2.0.x codebase, but I still don't want to force people to upgrade their Python just to get the next micro maintenance release of Mailman. Python 2.0 will definitely be required for Mailman 2.1 and there's a slim chance I'll require Python 2.1 (but doubtful). Still, I should clarify this in the INSTALL, README, and UPGRADING. CVR> There's a similar comment in README CVR> The UPGRADING file stops at 2.0.2. It probably makes sense to CVR> add a "if you're upgrading from any 2.0 release...." CVR> Looks good so far... Thanks, -Barry From jra@baylink.com Tue May 8 15:37:01 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 8 May 2001 10:37:01 -0400 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: <20010508041624.13939.qmail@zipcon.net>; from Trey Valenta on Mon, May 07, 2001 at 09:16:24PM -0700 References: <20010508041624.13939.qmail@zipcon.net> Message-ID: <20010508103701.61384@scfn.thpl.lib.fl.us> On Mon, May 07, 2001 at 09:16:24PM -0700, Trey Valenta wrote: > On 2001 May 7, 16:56, "Joshua Erdman" wrote: > } Subject: [Mailman-Developers] Rotating Logs with Mailman > > Since installing Mailman I have noticed the size of my backups increasing > > steadily. I did some investigating and noticed the size of the log file in > > the mailman/logs directory. By adding a few lines of code to your > > /etc/logrotate.conf file you can have these log files rotated just like all > > the log files in /var/logs > > Ummm..... you're assuming that everyone runs RedHat and has a > logrotate.conf. They don't? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From joker@aol.com Wed May 9 04:03:41 2001 From: joker@aol.com (joker@aol.com) Date: Tue, 8 May 2001 23:03:41 -0400 (EDT) Subject: [Mailman-Developers] Hi Message-ID: <200105090303.XAA14655@mclean.mail.mindspring.net> Hi From barry@digicool.com Wed May 9 06:45:36 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 01:45:36 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web Message-ID: <15096.55680.384791.933908@anthem.wooz.org> Last night I got inspired to add back the through-the-web creation and deletion of mailing lists. I've now got this working for Postfix and can work with other MTAs with a little help from y'all. I will soon be checking all this code into the 2.1 codebase, so watch mailman-checkins shortly. (And hey, it only took 24 hours from inception to completion! :). Apologies in advance for the length of this message. First, there is a new pseudo-role[1] called `list creator'. There is a separate, global list creator password, similar to but different than the site admin password. This is because list creation is a site-wide operation, but I don't want to have to give out the site admin password to someone who may only have list creation duties. Needless to say, the site admin can create lists through the web too. You set the list creator's password by using mmsitepass with the -c option. Let's say Mailman is installed at http://yoursite.com/mailman, then the list creation page is at http://yoursite.com/mailman/create which is linked to from the admin overview page (but not the listinfo overview page). The create page requires you to enter the name of your list, the email address of the initial list owner, the initial list password (with confirmation), and the list creator's password. There is then a "Create" button to submit the form. Assuming everything checks out, the new list is created, and the results page gives you three links to follow from there (go to the list's info page, the list's admin page, or create another list). Deleting a list is done from the list's admin page. There is now another link under "Other Administrative Activities" that says "Delete this list (requires confirmation)". Click on that and you're brought to a page for confirmation of the list deletion operation. You have a radio button to choose whether the archives should be deleted or not (the default is not), and you're prompted for the list admin password[2]. There's a link to cancel the deletion and return to the list's admin page, and a button to actually do the list deletion. For bonus, the site administrator can inhibit the ability for individual list owners to delete their lists through the web by setting OWNERS_CAN_DELETE_THEIR_OWN_LISTS = 0 in mm_cfg.py. Do this, and the link is not shown in the "Other Administrative Activities" list, and the rmlist cgi will error out every time. The current default for OWNERS_CAN_DELETE_THEIR_OWN_LISTS is 0, but that may change to 1 before the final release. The disadvantage is that with this variable set to 0, list deletion must be done via the command line script. Now, how to integrate this with MTAs? One reason why ttw list creation and deletion hasn't been (re-)added to Mailman until now is that you typically have to do some manual and difficult crud like edit an /etc/aliases file and run `newaliases' (as root!). I've figured a way around this with Postfix, and of course Exim can be configured to automatically recognize new mailing lists, so I figured it was time to do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst yourselves will contribute the code to glue this together for other mailers. Here's how I solved it for Postfix; this is outlined in a new README.POSTFIX file. Postfix has a configuration variable called `alias_maps' which tells it where to look for local delivery address associations. It has another variable called `alias_databases' which tells it which files to rebuild when invoked as newaliases. For each of these you can specify the type of map database the file is kept as. One of these choices is `hash', which is really a BSD dbhash file. Python has a dbhash module which nicely handles reading and writing dbhash files (and it should be enabled by default in Python 2.x, if your system has Berkeley DB installed, as most Linux distros ought to). It's moderately well-published what Postfix expects as entries in the dbhash (and it's easy to figure out by dumping a newaliases generated .db file) so, when creating a new list, Mailman can add the necessary keys and values to make Postfix happy. Let's say Mailman is installed as /home/mailman and writes its new list alias entries to the dbhash file at /home/mailman/data/aliases.db. By adding "hash:/home/mailman/data/aliases" to your Postfix's alias_maps variable, Postfix will automatically deliver to your new list. Deleting is as simple as removing the keys from the dbhash. Note that you do /not/ want to add this file to alias_databases since newaliases won't be touching it. So this works great, but there's a catch! Postfix will invoke the filter programs under the uid of the owner of the aliases.db file, unless that's root, in which case it'll invoke it as the user defined in the default_privs variable (by default `nobody'). And of course the gid has to match what you specify in --with-mail-gid or Mailman's mail wrapper will complain. The trick is to touch the alias.db file as root, set the group owner to mailman, and make sure the file is user and group writable. Now, when Mailman adds new keys to aliases.db, the user ownership will remain as root, so Postfix invokes it correctly as nobody. But because aliases.db is group-owned by mailman, the cgi processes can write to the file. And no setuid-root script in sight. I've tested this and it works like a charm. (Of course, all this is described in cookbook form without the gory details in README.POSTFIX. Also, I like this approach much better than the luser_relay hack I posted about a while ago.) There's one last bit of glue, and here's where you come in (I'm speaking to the one of you who is still reading this. :). There's a new variable in Defaults.py.in called MTA which must point to a module in the Mailman/MTA directory. This implements the MTA-specific operations needed when creating or deleting a list. The API is that this module should provide two functions: create() and remove() both of which take a MailList object. They should do whatever is necessary to inform the MTA that it's alias database has changed. For Postfix it's really not a lot of code[3]. For Exim, I predict "MTA = None" in mm_cfg.py will Do The Right Thing, since nothing special has to be done. I've no idea at this time what Sendmail, Qmail, or any other MTA will require, and I'm hoping those of you who use those mailers will be able to donate a module. Phew, that's it. I need sleep. I'm very interested in getting some feedback, especially for those hearty souls who can check out the current codebase, and give it a whirl. I'm no doubt forgetting some important details, but it sure has been fun. :) Enjoy, -Barry [1] I call it a pseudo-role because eventually this will be a role that can be given to specific users (once there's a Real User Database). [2] Because list deletion is not handled by the admin.py cgi script, it isn't protected by the normal admin login screen. I could (and may) add this extra authentication step, but I'll probably still keep the list password requirement on the deletion page as a strong confirmation of the list owner's intention. [3] There's one caveat: because I don't want to have to include a setuid-root script, the Postfix.py module doesn't call `postfix reload'. This command has to be done as root. The tradeoff is that Postfix will take about a minute to recognize its alias database has changed. To me that's an acceptable limitation. From barry@digicool.com Wed May 9 07:47:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 02:47:49 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <15096.59413.551202.308904@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> I will soon be checking all this code into the 2.1 codebase, BAW> so watch mailman-checkins shortly. I'm too tired to finish the checkins tonight. The committed trunk is probably unstable at the moment, so even though you're as flush with excitement as I , please wait until tomorrow before doing your cvs update. G'night, -Barry From joker@aol.com Wed May 9 08:55:08 2001 From: joker@aol.com (joker@aol.com) Date: Wed, 9 May 2001 03:55:08 -0400 (EDT) Subject: [Mailman-Developers] Hi Message-ID: <200105090755.DAA14585@smtp6.mindspring.com> Hi From thomas@xs4all.net Wed May 9 12:53:47 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 9 May 2001 13:53:47 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15096.55680.384791.933908@anthem.wooz.org>; from barry@digicool.com on Wed, May 09, 2001 at 01:45:36AM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010509135347.H16486@xs4all.nl> On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: > The create page requires you to enter the name of your list, the email > address of the initial list owner, the initial list password (with > confirmation), and the list creator's password. There is then a > "Create" button to submit the form. What about a 'send list creation message' ? And a 'auto-generate password' button ? In my eyes, typically, the person creating the list won't be the list owner him/herself, so those things make sense to me. And what about the domain the list should be created on ? > Deleting a list is done from the list's admin page. There is now > another link under "Other Administrative Activities" that says "Delete > this list (requires confirmation)". Click on that and you're brought > to a page for confirmation of the list deletion operation. You have a > radio button to choose whether the archives should be deleted or not > (the default is not), and you're prompted for the list admin > password[2]. There's a link to cancel the deletion and return to the > list's admin page, and a button to actually do the list deletion. Why not have the 'delete a list' option be on the list creation page as well (make it the 'site administration page' or something.) Again, this won't make sense everywhere, but I'd *love* to be able to give our Sales dept. the list creator password to have them create and destroy lists, without giving them the site password. > Here's how I solved it for Postfix; this is outlined in a new > README.POSTFIX file. You'll want to add checks for the permissios of this file to bin/check_perms, just to be sure. If not run as root, it can't fix it automatically, but it can whine incessantly. > There's one last bit of glue, and here's where you come in (I'm > speaking to the one of you who is still reading this. :). Hi, Barry ! =) > There's a new variable in Defaults.py.in called MTA which must point > to a module in the Mailman/MTA directory. This implements the > MTA-specific operations needed when creating or deleting a list. > The API is that this module should provide two functions: create() > and remove() both of which take a MailList object. They should do > whatever is necessary to inform the MTA that it's alias database has > changed. For Postfix it's really not a lot of code[3]. > For Exim, I predict "MTA = None" in mm_cfg.py will Do The Right Thing, > since nothing special has to be done. I've no idea at this time what > Sendmail, Qmail, or any other MTA will require, and I'm hoping those > of you who use those mailers will be able to donate a module. Sendmail can work in the same way as Postfix, I believe. I'm not sure if you can tell it to use more than one aliases.db file, but if it can, the only difference is the permissions with which the commands are executed. As far as I know, Sendmail also uses dbhash (hash or btree, depending on how you make them) so no problem there. There's another dimension to it, though. At XS4ALL we use a central database (currently MySQL, soon to be PostgresSQL) for all email aliases, and the list creation mechanism should insert the appropriate aliases into that as well as into the local database -- and they have to differ slightly. (local alias is, say, 'list@listXX.xs4all.nl', where XX is a growing number, but the global alias should be either list@xs4all.nl or list@domain.com, pointing to list@listXX.xs4all.nl). I could do this fairly easily by adapting the Sendmail (or Postfix) MTA module and placing it in the MTA directory under a different name. > [3] There's one caveat: because I don't want to have to include a > setuid-root script, the Postfix.py module doesn't call `postfix > reload'. This command has to be done as root. The tradeoff is that > Postfix will take about a minute to recognize its alias database has > changed. To me that's an acceptable limitation. A minute ? Heh. I doubt that's ever going to be a problem, most humans take a minute to read the resulting webpage, let alone that they compose and send a message inside that minute. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tollef@add.no Wed May 9 13:08:04 2001 From: tollef@add.no (Tollef Fog Heen) Date: 09 May 2001 14:08:04 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <20010509135347.H16486@xs4all.nl> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509135347.H16486@xs4all.nl> Message-ID: <87g0eeu3mj.fsf@arabella.intern.opera.no> * Thomas Wouters | Sendmail can work in the same way as Postfix, I believe. I'm not sure | if you can tell it to use more than one aliases.db file, but if it | can, the only difference is the permissions with which the commands | are executed. As far as I know, Sendmail also uses dbhash (hash or | btree, depending on how you make them) so no problem there. IIRC, Sendmail will whine a lot if the group file or any directory up to it is writeable by anybody else than 'trusted' users. But it is certainly possible to have more than one alias file. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From richarde@eskom.co.za Wed May 9 14:44:44 2001 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Wed, 09 May 2001 15:44:44 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web Message-ID: >On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: >> For Exim, I predict "MTA =3D None" in mm_cfg.py will Do The Right = Thing, >> since nothing special has to be done. I've no idea at this time what >> Sendmail, Qmail, or any other MTA will require, and I'm hoping those >> of you who use those mailers will be able to donate a module. > >Sendmail can work in the same way as Postfix, I believe. I'm not sure >if you can tell it to use more than one aliases.db file, but if it >can, the only difference is the permissions with which the commands >are executed. As far as I know, Sendmail also uses dbhash (hash or >btree, depending on how you make them) so no problem there. Yes sendmail can have multiple aliases files, just comma seperate them in = the sendmail.cf file. This is for 8.11.1 which I am running - do not know = for older versions. The only problem is that newaliases needs to be run as = root, or else modify the sendmail.cf file to automagically rebuild the = aliases files from time to time (you can specify the time out). I don't = know what happens though when broken alias files are fed in though - does = it just ignore the new file? -- Richard Ellerbrock richarde@eskom.co.za From jra@baylink.com Wed May 9 15:13:21 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 9 May 2001 10:13:21 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15096.55680.384791.933908@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 09, 2001 at 01:45:36AM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010509101321.61492@scfn.thpl.lib.fl.us> On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: > Last night I got inspired to add back the through-the-web creation and > deletion of mailing lists. I've now got this working for Postfix and > can work with other MTAs with a little help from y'all. I will soon > be checking all this code into the 2.1 codebase, so watch > mailman-checkins shortly. (And hey, it only took 24 hours from > inception to completion! :). Ain't Python great? > Now, how to integrate this with MTAs? One reason why ttw list > creation and deletion hasn't been (re-)added to Mailman until now is > that you typically have to do some manual and difficult crud like edit > an /etc/aliases file and run `newaliases' (as root!). I've figured a > way around this with Postfix, and of course Exim can be configured to > automatically recognize new mailing lists, so I figured it was time to > do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst > yourselves will contribute the code to glue this together for other > mailers. IMHO, the proper solution for sendmail is for the admin to put an :include: in /etc/aliases pointing to /home/mailman/data/aliases, and rebuild that from scratch against the current list of lists every time that list changes. > It's moderately well-published what Postfix expects as entries in the > dbhash (and it's easy to figure out by dumping a newaliases generated > .db file) so, when creating a new list, Mailman can add the necessary > keys and values to make Postfix happy. Let's say Mailman is installed > as /home/mailman and writes its new list alias entries to the dbhash > file at /home/mailman/data/aliases.db. By adding > "hash:/home/mailman/data/aliases" to your Postfix's alias_maps > variable, Postfix will automatically deliver to your new list. > Deleting is as simple as removing the keys from the dbhash. > > Note that you do /not/ want to add this file to alias_databases since > newaliases won't be touching it. You're working at the 'compiled' level there, right? > There's one last bit of glue, and here's where you come in (I'm > speaking to the one of you who is still reading this. :). There's a > new variable in Defaults.py.in called MTA which must point to a module > in the Mailman/MTA directory. This implements the MTA-specific > operations needed when creating or deleting a list. The API is that > this module should provide two functions: create() and remove() both > of which take a MailList object. They should do whatever is necessary > to inform the MTA that it's alias database has changed. For Postfix > it's really not a lot of code[3]. I suspect you'll need one more: how to get the aliases database rebuilt when it's been changed. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 9 17:27:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 12:27:49 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> Message-ID: <15097.28677.242197.400892@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Ain't Python great? (ssshhh! they'll discover our secret weapon. :) JRA> IMHO, the proper solution for sendmail is for the admin to JRA> put an :include: in /etc/aliases pointing to JRA> /home/mailman/data/aliases, and rebuild that from scratch JRA> against the current list of lists every time that list JRA> changes. I'm really trying to avoid having to write the sendmail code myself. I just have too many scary flashbacks when I even think about mucking with sendmail. ;} Now that everything's checked in, folks can see how I'm doing it with Postfix, so I hope eventually someone will contribute a Mailman/MTA/Sendmail.py module. Until then, I'll work it so it does something simple. >> Deleting is as simple as removing the keys from the dbhash. >> Note that you do /not/ want to add this file to alias_databases >> since newaliases won't be touching it. JRA> You're working at the 'compiled' level there, right? If I understand what you're asking, yes. IOW, I don't muck about in the plain text aliases file, but I write directly to the file that newaliases would produce. >> They should do whatever is necessary to inform the MTA that >> it's alias database has changed. For Postfix it's really not a >> lot of code[3]. JRA> I suspect you'll need one more: how to get the aliases JRA> database rebuilt when it's been changed. That's the beauty of the Postfix approach: I'm modifying the database directly so it doesn't need to be rebuilt (i.e. no need to run newaliases). I don't even have to notify Postfix since it'll notice the change after one minute. >>>>> "TW" == Thomas Wouters writes: TW> What about a 'send list creation message' ? And a TW> 'auto-generate password' button ? In my eyes, typically, the TW> person creating the list won't be the list owner him/herself, TW> so those things make sense to me. The list creation message is always sent currently. Does it make sense to be able to inhibit that? The auto-generate password button is a good idea, I'll add that. TW> And what about the domain the list should be created on ? The domain in the url to the `create' script! Note that bin/newlist does need a domain switch, since the context can't be determined when run from the command line, but the create cgi doesn't have that problem. E.g. if I want to create a new list on python.org, I'd visit http://mail.python.org/mailman/create but if I wanted to create a new list on zope.org (a virtual host of a shared Mailman installation), I'd visit http://mail.zope.org/mailman/create. TW> Why not have the 'delete a list' option be on the list TW> creation page as well (make it the 'site administration page' TW> or something.) I thought about that, but it makes things too complicated. E.g. now that global page has to have some pull down menu or other way to specify which list you want to delete. List deletion is list-centric, so it's okay to have it hang off the list admin page (really, it's that the rmlist cgi script requires a list name in the url). TW> Again, this won't make sense everywhere, but I'd *love* to be TW> able to give our Sales dept. the list creator password to have TW> them create and destroy lists, without giving them the site TW> password. That's a great idea, and I'll make the change so that list deletion follows this password chain: list-owner, global list-creator, site admin. >> Here's how I solved it for Postfix; this is outlined in a new >> README.POSTFIX file. TW> You'll want to add checks for the permissios of this file to TW> bin/check_perms, just to be sure. If not run as root, it can't TW> fix it automatically, but it can whine incessantly. Good point! This should probably be done in the Mailman/MTA/Foo.py module so MTA-specific adaptors can do whatever additional checks are necessary. >> There's one last bit of glue, and here's where you come in (I'm >> speaking to the one of you who is still reading this. :). TW> Hi, Barry ! =) Hi Thomas! :) TW> There's another dimension to it, though. At XS4ALL we use a TW> central database (currently MySQL, soon to be PostgresSQL) for TW> all email aliases, and the list creation mechanism should TW> insert the appropriate aliases into that as well as into the TW> local database -- and they have to differ slightly. (local TW> alias is, say, 'list@listXX.xs4all.nl', where XX is a growing TW> number, but the global alias should be either list@xs4all.nl TW> or list@domain.com, pointing to list@listXX.xs4all.nl). I TW> could do this fairly easily by adapting the Sendmail (or TW> Postfix) MTA module and placing it in the MTA directory under TW> a different name. I think that's the right approach. >> [3] There's one caveat: because I don't want to have to include >> a setuid-root script, the Postfix.py module doesn't call >> `postfix reload'. This command has to be done as root. The >> tradeoff is that Postfix will take about a minute to recognize >> its alias database has changed. To me that's an acceptable >> limitation. TW> A minute ? Heh. I doubt that's ever going to be a problem, TW> most humans take a minute to read the resulting webpage, let TW> alone that they compose and send a message inside that minute. My thinking exactly! -Barry From Nigel.Metheringham@InTechnology.co.uk Wed May 9 17:43:44 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Wed, 09 May 2001 17:43:44 +0100 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 09 May 2001 12:27:49 EDT." <15097.28677.242197.400892@anthem.wooz.org> Message-ID: I hesitate to bring this up since Barry has currently produced a front end for existing mailman functionality rather than rehashing things... but one of the things I keep being asked about is better domain support.... I think that in general people wish to be able to have multiple domains on a machine and have *distinct* lists of the form list-name@domain1 list-name@domain2 Personally I am actually pretty happy with the current behaviour, and it could be very painful if the case where a current list sometimes gets requests on more than one domain was broken to handle this new case... Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry@digicool.com Wed May 9 17:53:58 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 12:53:58 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15097.28677.242197.400892@anthem.wooz.org> Message-ID: <15097.30246.409301.792141@anthem.wooz.org> >>>>> "NM" == Nigel Metheringham >>>>> writes: NM> Personally I am actually pretty happy with the current NM> behaviour, and it could be very painful if the case where a NM> current list sometimes gets requests on more than one domain NM> was broken to handle this new case... I think it would have to be broken. The `quick-fix' approach I've been mulling would involve encoding the domain into the path to the list's config.db file. I think it would be pretty painful to do that and arrange for lists to span multiple domains. But then again, maybe not. If the list's directory lived in $mailman/lists then it would span, but if it lived in $mailman/lists/$domain it would not span. Note, I'm no where near complete in my thinking on this, except to say that I believe the current situation is liveable and I've got other things higher up on my TODO list. -Barry From jra@baylink.com Wed May 9 18:08:24 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 9 May 2001 13:08:24 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15097.28677.242197.400892@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 09, 2001 at 12:27:49PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> Message-ID: <20010509130824.50367@scfn.thpl.lib.fl.us> On Wed, May 09, 2001 at 12:27:49PM -0400, Barry A. Warsaw wrote: > JRA> IMHO, the proper solution for sendmail is for the admin to > JRA> put an :include: in /etc/aliases pointing to > JRA> /home/mailman/data/aliases, and rebuild that from scratch > JRA> against the current list of lists every time that list > JRA> changes. > > I'm really trying to avoid having to write the sendmail code myself. > I just have too many scary flashbacks when I even think about mucking > with sendmail. ;} It seems pretty plain to me. Just expand the "list of lists" though a text filter that explodes the list names into what the doco says the alias entry needs to look like. > Now that everything's checked in, folks can see how I'm doing it with > Postfix, so I hope eventually someone will contribute a > Mailman/MTA/Sendmail.py module. Until then, I'll work it so it does > something simple. See above. :-) I can't code, but I *can* design... > JRA> You're working at the 'compiled' level there, right? > > If I understand what you're asking, yes. IOW, I don't muck about in > the plain text aliases file, but I write directly to the file that > newaliases would produce. Thought so. Forgive me, my revered senior hat, but that's a bad design. You've put yourself at their mercy by going behind their API... > JRA> I suspect you'll need one more: how to get the aliases > JRA> database rebuilt when it's been changed. > > That's the beauty of the Postfix approach: I'm modifying the database > directly so it doesn't need to be rebuilt (i.e. no need to run > newaliases). I don't even have to notify Postfix since it'll notice > the change after one minute. See above. ;-) > TW> And what about the domain the list should be created on ? > > The domain in the url to the `create' script! Note that bin/newlist > does need a domain switch, since the context can't be determined when > run from the command line, but the create cgi doesn't have that > problem. E.g. if I want to create a new list on python.org, I'd visit > http://mail.python.org/mailman/create but if I wanted to create a new > list on zope.org (a virtual host of a shared Mailman installation), > I'd visit http://mail.zope.org/mailman/create. Oh... mailman *does* get that right? Cool; missed that. If it knows that, though, how come my mails go out with the wrong From line? Doesn't it set the from line to the proper virtual domain? Or is my configuration wrong? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From dgc@uchicago.edu Wed May 9 18:10:49 2001 From: dgc@uchicago.edu (David Champion) Date: Wed, 9 May 2001 12:10:49 -0500 Subject: [Mailman-Developers] Re: Creation/deletion of lists through-the-web In-Reply-To: <20010509101321.61492@scfn.thpl.lib.fl.us> Message-ID: <20010509121049.R10115@smack.uchicago.edu> On 2001.05.09, in <20010509101321.61492@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > that you typically have to do some manual and difficult crud like edit > > an /etc/aliases file and run `newaliases' (as root!). I've figured a > > way around this with Postfix, and of course Exim can be configured to > > automatically recognize new mailing lists, so I figured it was time to > > do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst > > yourselves will contribute the code to glue this together for other > > mailers. > > IMHO, the proper solution for sendmail is for the admin to put an > :include: in /etc/aliases pointing to /home/mailman/data/aliases, and > rebuild that from scratch against the current list of lists every time > that list changes. I've written a mailer (in the sendmail sense) for Mailman. You can define a mailertable entry as: server.name.mil mailman:server.name.mil And add the mailer to sendmail.cf: MMailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u ...and it's all automagical. No more aliases, no more recompiling map datbases. You can find it in the archives, or I can mail you the most recent working version. -- -D. dgc@uchicago.edu NSIT University of Chicago From claw@kanga.nu Wed May 9 18:39:02 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 09 May 2001 10:39:02 -0700 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 09 May 2001 12:27:49 EDT." <15097.28677.242197.400892@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> Message-ID: <13617.989429942@kanga.nu> On Wed, 9 May 2001 12:27:49 -0400 Barry A Warsaw wrote: > If I understand what you're asking, yes. IOW, I don't muck about > in the plain text aliases file, but I write directly to the file > that newaliases would produce. Then what happens when I need to manually touch that alias file for some reason (eg I edit the aliases to insert demime in the pipeline) and have postfix rebuild it? You need to touch both the plain text alias file and the DBM. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From barry@digicool.com Wed May 9 18:40:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 13:40:19 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <20010509130824.50367@scfn.thpl.lib.fl.us> Message-ID: <15097.33027.212039.19427@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> I'm really trying to avoid having to write the sendmail code >> myself. I just have too many scary flashbacks when I even >> think about mucking with sendmail. ;} JRA> It seems pretty plain to me. Just expand the "list of lists" JRA> though a text filter that explodes the list names into what JRA> the doco says the alias entry needs to look like. That's not the difficult part. What I'm purposefully avoiding is having to install sendmail, and /test/ the interoperability. There are all kinds of dark corners lurking there that only someone who uses and knows sendmail well enough will be able to solve. As I've done for Postfix. >> JRA> You're working at the 'compiled' level there, right? >> If I understand what you're asking, yes. IOW, I don't muck >> about in the plain text aliases file, but I write directly to >> the file that newaliases would produce. JRA> Thought so. Forgive me, my revered senior hat, but that's a JRA> bad design. You've put yourself at their mercy by going JRA> behind their API... I disagree. Postfix documents all this, so I consider it part of their API. And the fact that they have alias_maps /and/ alias_databases shows that they intend for external applications to create and manage maps that Postfix will consult. >> cgi doesn't have that problem. E.g. if I want to create a new >> list on python.org, I'd visit >> http://mail.python.org/mailman/create but if I wanted to create >> a new list on zope.org (a virtual host of a shared Mailman >> installation), I'd visit http://mail.zope.org/mailman/create. JRA> Oh... mailman *does* get that right? Cool; missed that. JRA> If it knows that, though, how come my mails go out with the JRA> wrong From line? Doesn't it set the from line to the proper JRA> virtual domain? Or is my configuration wrong? That's almost invariably a sending-MTA configuration issue. I know for a fact that Sendmail used to munge From: headers according to its own whims. You could set all the headers properly to your hearts content, and if Sendmail was misconfigured, they'd be broken when the end user gets them. I'll note that python.org and zope.org are a shared Mailman, virtual host arrangement, and it's all worked perfectly with both Postfix, and now Exim. -Barry From marc_news@valinux.com Wed May 9 18:43:04 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Wed, 9 May 2001 10:43:04 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org>; from barry@digicool.com on Mon, May 07, 2001 at 12:24:16PM -0400 References: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <20010509104304.J29713@magic.merlins.org> On Mon, May 07, 2001 at 12:24:16PM -0400, Barry A. Warsaw wrote: > > Folks, > > I've just released Mailman 2.0.5 which fixes a problem with stale lock > files that can occur under certain situations when the user hits the > `Stop' button on their browser. These stale lock files can cause > mailing lists to be inaccessible for long periods of time (until the > stale lock file times out or is manually removed). I just noticed this in my locks directory: usw-sf-list1:/var/local/mailman/bin# l ../locks/ total 24 drwxrwsr-x 2 mailman mailman 16384 May 9 10:40 ./ drwxrwsr-x 21 mailman mailman 4096 Apr 10 15:06 ../ -rw-rw-r-- 1 mailman mailman 59 May 7 05:42 jboss-user.lock.usw-sf-list1.26443 usw-sf-list1:/var/local/mailman/bin# (prcoss 26443 doesn't exist obviously) Note that this is not bad because it doesn't keep the list locked. There is probably a small race in the removal of the temporary lockfile that you link to though. I'll delete this one and see if others pop up over time. 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 jra@baylink.com Wed May 9 18:59:52 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 9 May 2001 13:59:52 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15097.33027.212039.19427@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 09, 2001 at 01:40:19PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <20010509130824.50367@scfn.thpl.lib.fl.us> <15097.33027.212039.19427@anthem.wooz.org> Message-ID: <20010509135952.46012@scfn.thpl.lib.fl.us> On Wed, May 09, 2001 at 01:40:19PM -0400, Barry A. Warsaw wrote: > JRA> It seems pretty plain to me. Just expand the "list of lists" > JRA> though a text filter that explodes the list names into what > JRA> the doco says the alias entry needs to look like. > > That's not the difficult part. What I'm purposefully avoiding is > having to install sendmail, and /test/ the interoperability. There > are all kinds of dark corners lurking there that only someone who uses > and knows sendmail well enough will be able to solve. As I've done > for Postfix. Ah. > JRA> Thought so. Forgive me, my revered senior hat, but that's a > JRA> bad design. You've put yourself at their mercy by going > JRA> behind their API... > > I disagree. Postfix documents all this, so I consider it part of > their API. And the fact that they have alias_maps /and/ > alias_databases shows that they intend for external applications to > create and manage maps that Postfix will consult. Oh. Didn't realize that. As JC notes, though, there's a problem in reverse. > >> cgi doesn't have that problem. E.g. if I want to create a new > >> list on python.org, I'd visit > >> http://mail.python.org/mailman/create but if I wanted to create > >> a new list on zope.org (a virtual host of a shared Mailman > >> installation), I'd visit http://mail.zope.org/mailman/create. > > JRA> Oh... mailman *does* get that right? Cool; missed that. > JRA> If it knows that, though, how come my mails go out with the > JRA> wrong From line? Doesn't it set the from line to the proper > JRA> virtual domain? Or is my configuration wrong? > > That's almost invariably a sending-MTA configuration issue. I know > for a fact that Sendmail used to munge From: headers according to its > own whims. You could set all the headers properly to your hearts > content, and if Sendmail was misconfigured, they'd be broken when the > end user gets them. > > I'll note that python.org and zope.org are a shared Mailman, virtual > host arrangement, and it's all worked perfectly with both Postfix, and > now Exim. Noted. Which do you like better? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jarrell@vt.edu Wed May 9 20:23:19 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 09 May 2001 15:23:19 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15097.28677.242197.400892@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010509151550.02abd380@vtserf.cc.vt.edu> At 12:27 PM 5/9/01 -0400, Barry A. Warsaw wrote: >>>>>> "JRA" == Jay R Ashworth writes: > > JRA> Ain't Python great? > >(ssshhh! they'll discover our secret weapon. :) > > JRA> IMHO, the proper solution for sendmail is for the admin to > JRA> put an :include: in /etc/aliases pointing to > JRA> /home/mailman/data/aliases, and rebuild that from scratch > JRA> against the current list of lists every time that list > JRA> changes. > >I'm really trying to avoid having to write the sendmail code myself. >I just have too many scary flashbacks when I even think about mucking >with sendmail. ;} That's in the cf file. You can specify more than one alias file. Which is probably the cleanest way to do it; you'll still need something, if only a cronjob that runs newaliases - I shudder at the the thought of manipulating the sendmail alias db file directly, particularly since my python 2.0 will flatly not compile with the version of DB that sendmail is using; I suspect it's too new for the DB routines shipped with python. Note that eric said a while ago that he's deprecating the "auto rebuild alias file" for security reasons, so at some point that functionality will likely go away. > JRA> I suspect you'll need one more: how to get the aliases > JRA> database rebuilt when it's been changed. > >That's the beauty of the Postfix approach: I'm modifying the database >directly so it doesn't need to be rebuilt (i.e. no need to run >newaliases). I don't even have to notify Postfix since it'll notice >the change after one minute. Until the first time something goes wrong... Then you'll need a tool to regenerate all the aliases again from scratch. I really don't like the fact that I won't have a text DB source file around... >>>>>> "TW" == Thomas Wouters writes: > > TW> What about a 'send list creation message' ? And a > TW> 'auto-generate password' button ? In my eyes, typically, the > TW> person creating the list won't be the list owner him/herself, > TW> so those things make sense to me. > >The list creation message is always sent currently. Does it make >sense to be able to inhibit that? Yes. I currently manually go in and fix some things that just can't be set from defaults easily before letting the admin know. Ideally I'd like a button for "(re)send list creation message now", because what I do is run newlist, hit ctl-z, go off and make my changes, fg it, and let it send the list message... From fil@rezo.net Wed May 9 22:23:29 2001 From: fil@rezo.net (Fil) Date: Wed, 9 May 2001 23:23:29 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15096.55680.384791.933908@anthem.wooz.org>; from barry@digicool.com on Wed, May 09, 2001 at 01:45:36AM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010509232329.B30678@orwell.bok.net> @ Barry A. Warsaw (barry@digicool.com) : > Last night I got inspired to add back the through-the-web creation and > deletion of mailing lists. I've now got this working for Postfix and Sorry I'm catching this thread late. I've been hacking another way with mailman and postfix, and thought I should share. The idea is outlined below, and the details are on http://listes.rezo.net/comment.php (in French, but there are mostly codes... in code.) So in postfix create a new virtual domain (listes.rezo.net in my case) within the /etc/postfix/virtual file ; **this domain will be totally used by mailman** ; then use some regexp virtual addresses so that (.*)-post is sent to mailman-post+$1@localhost (.*)-subscribe to mailman-subscribe+$1@localhost and so on. If an adress mathces none of the -action filters, send it to $1-post (so that listname@listes.rezo.net is sent to list-post then to the post programme) then in the /etc/aliases file define mailman-post: "|/var/lib/mailman/mail/wrapper post $EXTENSION" and allow the '+' sign as an extension delimiteer in postfix. Then (shazzam!) any mail coming to the listes.rezo.net domain is processed by the right mailman scripts. Of course we intercept required addresses before the regexp ones, so that postmaster@, abuse@ and root@listes.rezo.net go to root@localhost. What gives? When I need to create a list, or to delete one, I don't need root privileges or access to any postfix file. I just do the bin/newlist stuff and the list is ready. Hope this can be helpful. From benwa@ocentrix.com Thu May 10 00:21:53 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Wed, 9 May 2001 16:21:53 -0700 Subject: [Mailman-Developers] Creation/deletion of liststhrough-the-web Message-ID: <200105092321.f49NLrW08277@mail.ocentrix.net> ------- Original Copy ------- >Subject: Re: [Mailman-Developers] Creation/deletion of liststhrough-the-web >Date: 05/09/2001 3:23 PM >From: Ron Jarrell >To: barry@digicool.com (Barry A. Warsaw), "Jay R. Ashworth" >Cc: mailman-developers@python.org >>The list creation message is always sent currently. Does it make >>sense to be able to inhibit that? > >Yes. I currently manually go in and fix some things that just can't be set >from defaults easily before letting the admin know. Ideally I'd like a button >for "(re)send list creation message now", because what I do is run newlist, >hit ctl-z, go off and make my changes, fg it, and let it send the list message... FWIW I do sort of the same thing. I have hacked newlist to accept another option as described below. [mailman@mail riders_connection]$ ./bin/newlist --help Create a new, unpopulated mailing list. Usage: %(PROGRAM)s [options] listname listadmin-addr admin-password Options: -q --quiet Normally the administrator is notified by email (after a prompt) that their list has been created. This option suppresses that notification and the prompting. -s file --saveemail=file Append the email that is sent to the administrator of the new list to file. This is in addition to sending the email to the administrator unless -q is used. -o file --output=file Append the alias setting recommendations to file, in addition to printing them to standard output. -h/--help Print this help text and exit. You can specify as many of the arguments as you want on the command line: you will be prompted for the missing ones. Note that listnames are forced to lowercase. [mailman@mail riders_connection]$ a patch for this against 2.0.3 is attached if anyone is interested. -Ben From Dan Mick Thu May 10 00:51:52 2001 From: Dan Mick (Dan Mick) Date: Wed, 9 May 2001 16:51:52 -0700 (PDT) Subject: [Mailman-Developers] RFE: check_perms: ignore archives Message-ID: <200105092351.QAA07292@utopia.West.Sun.COM> Allow check_perms to bypass the archives subdirs. When they get large, check_perms can take *forever*, and so people won't run it, which is bad. I hacked something quickly that should be an option instead: $ diff check_perms check_perms2 80a81,86 > > if 'archives' in names: > print 'removing archives from names array' > names.remove('archives') > return > From andrewm@connect.com.au Thu May 10 06:15:33 2001 From: andrewm@connect.com.au (Andrew McNamara) Date: Thu, 10 May 2001 15:15:33 +1000 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Your message of "Wed, 09 May 2001 01:45:36 -0400." <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010510051533.C63B2285BF@wawura.off.connect.com.au> >Postfix has a configuration variable called `alias_maps' which tells >it where to look for local delivery address associations. It has >another variable called `alias_databases' which tells it which files >to rebuild when invoked as newaliases. For each of these you can >specify the type of map database the file is kept as. One of these >choices is `hash', which is really a BSD dbhash file. Python has a >dbhash module which nicely handles reading and writing dbhash files >(and it should be enabled by default in Python 2.x, if your system has >Berkeley DB installed, as most Linux distros ought to). It should be mentioned here that postfix and python need to be linked against the same version of libdb as most versions of libdb have incompatible file formats. One other small caveat is file locking - some versions of libdb (certainly 1.96 and prior) are not safe during updates. The postfix tool that builds libdb hashes uses it's own file locking (check source for details). --- Andrew McNamara (System Architect) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9409 2117, Fax: +61 2 9409 2111 From thomas@xs4all.net Thu May 10 10:17:04 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 10 May 2001 11:17:04 +0200 Subject: [Mailman-Developers] Re: Creation/deletion of lists through-the-web In-Reply-To: <20010509121049.R10115@smack.uchicago.edu>; from dgc@uchicago.edu on Wed, May 09, 2001 at 12:10:49PM -0500 References: <20010509101321.61492@scfn.thpl.lib.fl.us> <20010509121049.R10115@smack.uchicago.edu> Message-ID: <20010510111704.I16486@xs4all.nl> On Wed, May 09, 2001 at 12:10:49PM -0500, David Champion wrote: > On 2001.05.09, in <20010509101321.61492@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > > that you typically have to do some manual and difficult crud like edit > > > an /etc/aliases file and run `newaliases' (as root!). I've figured a > > > way around this with Postfix, and of course Exim can be configured to > > > automatically recognize new mailing lists, so I figured it was time to > > > do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst > > > yourselves will contribute the code to glue this together for other > > > mailers. > > > > IMHO, the proper solution for sendmail is for the admin to put an > > :include: in /etc/aliases pointing to /home/mailman/data/aliases, and > > rebuild that from scratch against the current list of lists every time > > that list changes. > > I've written a mailer (in the sendmail sense) for Mailman. You can > define a mailertable entry as: > server.name.mil mailman:server.name.mil > And add the mailer to sendmail.cf: > MMailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, > S=EnvFromL, R=EnvToL/HdrToL, > A=mm-handler $h $u > ...and it's all automagical. No more aliases, no more recompiling map > datbases. > You can find it in the archives, or I can mail you the most recent > working version. I think that would be *perfect*. Mailers is exactly one of Sendmail's fortes, and very useful if you know how to use them (we do, for various uhm, 'creative systems' :) I'd very much like to test this sometime (but not soon, unfortunately my other work stuff is swamping me) on our list servers! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@digicool.com Thu May 10 17:29:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 12:29:19 -0400 Subject: [Mailman-Developers] Re: Creation/deletion of lists through-the-web References: <20010509101321.61492@scfn.thpl.lib.fl.us> <20010509121049.R10115@smack.uchicago.edu> Message-ID: <15098.49631.621295.671358@yyz.digicool.com> >>>>> "DC" == David Champion writes: DC> On 2001.05.09, in <20010509101321.61492@scfn.thpl.lib.fl.us>, DC> I've written a mailer (in the sendmail sense) for Mailman. DC> You can define a mailertable entry as: server.name.mil DC> mailman:server.name.mil DC> And add the mailer to sendmail.cf: MMailman, DC> P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, DC> S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u DC> ...and it's all automagical. No more aliases, no more DC> recompiling map datbases. DC> You can find it in the archives, or I can mail you the most DC> recent working version. David, This is really cool! Please send me the latest version of mm-handler so I can add it to the contrib directory. I've updated README.SENDMAIL with the following text; does it accurately describe the steps one should take to integrate Mailman and Sendmail? If not, please let me know what changes should be made. Thanks, -Barry -------------------- snip snip -------------------- INTEGRATING SENDMAIL AND MAILMAN David Champion has contributed a Sendmail mailer which you can use so that Sendmail will automatically deliver to Mailman mailing lists without manual intervention (i.e. updated an aliases file or running newaliases). He suggests adding the following to your sendmail.cf file: MMailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u The mm-handler script can be found in the contrib directory; copy this script to /etc/mail and in your Mailman/mm_cfg.py file, add the following: MTA = None Now Sendmail should automagically deliver to the standard Mailman aliases for mailing lists. From barry@digicool.com Thu May 10 18:10:46 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 13:10:46 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> Message-ID: <15098.52118.767944.272250@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> If I understand what you're asking, yes. IOW, I don't muck >> about in the plain text aliases file, but I write directly to >> the file that newaliases would produce. JCL> Then what happens when I need to manually touch that alias JCL> file for some reason (eg I edit the aliases to insert demime JCL> in the pipeline) and have postfix rebuild it? You need to JCL> touch both the plain text alias file and the DBM. Two suggestions: - If you want to insert demime in front of the pipeline for all lists, then edit Mailman/MTA/Utils.py to generate whatever expansion of the aliases you want. Currently these expand to mylist: "|/path/to/mailman/mail/wrapper post mylist" mylist-admin: "|/path/to/mailman/mail/wrapper mailowner mylist" mylist-request: "|/path/to/mailman/mail/wrapper mailcmd mylist" mylist-owner: mylist-admin - If you only want to insert demime in front of some lists and not others, then I would suggest writing a custom module for the Mailman/MTA directory and using that instead (i.e. setting MTA = 'MyCustomMTA' in mm_cfg.py). That having been said, I'm adding a command line script (bin/genaliases) that will re-generate both the dbhash alias file and the plain-text alias file based on the list of mailing lists. What I don't want to do is use the plain text file as the canonical database file for integration with the MTA. I fear the grepping and cut-n-paste that would have to be done programmatically would be too fragile. And then you still have to get newaliases run, which poses problems in its own right. Ideally, none of this would be necessary because the MTA would just have a single hook for it to auto-recognize mailing lists. Exim does it well, and it looks like David Champion's got a good solution for Sendmail. I'll follow up on the alternative Postfix solution shortly, in a separate email. -Barry P.S. genaliases and Mailman/MTA/Utils.py will be checked in soon. From barry@digicool.com Thu May 10 18:20:54 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 13:20:54 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <20010509130824.50367@scfn.thpl.lib.fl.us> <15097.33027.212039.19427@anthem.wooz.org> <20010509135952.46012@scfn.thpl.lib.fl.us> Message-ID: <15098.52726.758080.651119@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> I disagree. Postfix documents all this, so I consider it part >> of their API. And the fact that they have alias_maps /and/ >> alias_databases shows that they intend for external >> applications to create and manage maps that Postfix will >> consult. JRA> Oh. Didn't realize that. As JC notes, though, there's a JRA> problem in reverse. Not really, because I submit that you shouldn't have to touch the plain text Mailman-specific aliases file. You shouldn't be mixing non-Mailman aliases into this file (and don't need to since Postfix will happily consult any number of files via alias_maps), and Mailman can be taught to DTRT for the Mailman-related aliases. >> I'll note that python.org and zope.org are a shared Mailman, >> virtual host arrangement, and it's all worked perfectly with >> both Postfix, and now Exim. JRA> Noted. Which do you like better? I'm mostly agnostic here. I chose Postfix years ago for the old CNRI machines when I was just frustrated beyond my breaking point with Sendmail (you don't even want to hear about our even older, internal, and hand-crufted mmdf installation). Once I learned it I had little reason - or really, time - to change. When we (and our lists ;) moved to Digital Creations, and we integrated the python.org and zope.org domains, I was able to pawn^H^H^H^H, er, hand off the specific MTA duties to the zope.org webmaster. He was very comfortable with Exim and since I was load-shedding, I wasn't in a position to argue. Exim's done the job quite admirably since then. And it's very nice that Exim is so easily integrated with Mailman! -Barry From jra@baylink.com Thu May 10 18:37:40 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 10 May 2001 13:37:40 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15098.52118.767944.272250@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, May 10, 2001 at 01:10:46PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> Message-ID: <20010510133740.47780@scfn.thpl.lib.fl.us> On Thu, May 10, 2001 at 01:10:46PM -0400, Barry A. Warsaw wrote: > What I don't want to do is use the plain text file as the canonical > database file for integration with the MTA. I fear the grepping and > cut-n-paste that would have to be done programmatically would be too > fragile. And then you still have to get newaliases run, which poses > problems in its own right. Well, I *had* suggested making the admin do *1* :include: in the alias file that sendmail knows about, to a file tha mailman *owns*... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Thu May 10 18:43:17 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 10 May 2001 10:43:17 -0700 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Thu, 10 May 2001 13:10:46 EDT." <15098.52118.767944.272250@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> Message-ID: <30844.989516597@kanga.nu> On Thu, 10 May 2001 13:10:46 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: >>> If I understand what you're asking, yes. IOW, I don't muck >>> about in the plain text aliases file, but I write directly to >>> the file that newaliases would produce. JCL> Then what happens when I need to manually touch that alias file JCL> for some reason (eg I edit the aliases to insert demime in the JCL> pipeline) and have postfix rebuild it? You need to touch both JCL> the plain text alias file and the DBM. > Two suggestions: > - If you want to insert demime in front of the pipeline for all > lists, then edit Mailman/MTA/Utils.py to generate whatever > expansion of the aliases you want. Currently these expand to ... > - If you only want to insert demime in front of some lists and not > others, then I would suggest writing a custom module for the > Mailman/MTA directory and using that instead (i.e. setting MTA = > 'MyCustomMTA' in mm_cfg.py). That's taking something which is simple and obvious, which every SysAdm out there who has ever touched mail on a *nix system understands editing alias files, and then turning it into something special cased for Mailman. Bad. > That having been said, I'm adding a command line script > (bin/genaliases) that will re-generate both the dbhash alias file > and the plain-text alias file based on the list of mailing lists. Yeesh. No. If you touch the DBM file you need to touch the aliases file, always. Otherwise you're in the position of actively working to deceive admins in regard to the state of their mail system (what they can see says one thing, what they can't see says another, and they have to have specialised knowledge to know that there's likely to be a difference). > What I don't want to do is use the plain text file as the > canonical database file for integration with the MTA. I fear the > grepping and cut-n-paste that would have to be done > programmatically would be too fragile. Hardly. Put a comment block at the top of the file stating that this file is maintained by the CGI at URL . Include a warning that manual editing *might* break supports for this file format. Have newlist and the CGI always use the same formating. As all you are relly interested in are the ^listname:[ \t]*.* lines, they're easy enough to match and edit. > And then you still have to get newaliases run, which poses > problems in its own right. Nope. You do both: touch the text file AND the DBM. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From barry@digicool.com Thu May 10 19:37:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 14:37:40 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <5.1.0.14.2.20010509151550.02abd380@vtserf.cc.vt.edu> Message-ID: <15098.57332.841432.595430@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> That's in the cf file. You can specify more than one alias RJ> file. Which is probably the cleanest way to do it; you'll RJ> still need something, if only a cronjob that runs newaliases - RJ> I shudder at the the thought of manipulating the sendmail RJ> alias db file directly, particularly since my python 2.0 will RJ> flatly not compile with the version of DB that sendmail is RJ> using; I suspect it's too new for the DB routines shipped with RJ> python. Ah. Python 2.1 should have a much better story here. It doesn't statically link against the db library, and you can install the latest Sleepycat version of BerkeleyDB, and use Robin Dunn's PyBSDDB3 wrapper (pybsddb.sourceforge.net). Yup, that's more work, and it's not ideal, but it ought to work. RJ> Note that eric said a while ago that he's deprecating the RJ> "auto rebuild alias file" for security reasons, so at some RJ> point that functionality will likely go away. Another nail in the coffin for maintaining the aliases in the plain text file. But it looks like David Champion got the right solution for Sendmail. RJ> Until the first time something goes wrong... Then you'll need RJ> a tool to regenerate all the aliases again from scratch. I RJ> really don't like the fact that I won't have a text DB source RJ> file around... bin/genaliases >> The list creation message is always sent currently. Does it >> make sense to be able to inhibit that? RJ> Yes. I currently manually go in and fix some things that just RJ> can't be set from defaults easily before letting the admin RJ> know. Ideally I'd like a button for "(re)send list creation RJ> message now", because what I do is run newlist, hit ctl-z, go RJ> off and make my changes, fg it, and let it send the list RJ> message... I think the easiest thing to do right now is to restore the prompt before notification is sent for the command line script. It's not immediately clear how I should handle this for the create cgi... -Barry From barry@digicool.com Thu May 10 19:48:28 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 14:48:28 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <20010510133740.47780@scfn.thpl.lib.fl.us> Message-ID: <15098.57980.802114.12603@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Well, I *had* suggested making the admin do *1* :include: in JRA> the alias file that sendmail knows about, to a file tha JRA> mailman *owns*... Which makes it a little easier to control the contents of the file, but not foolproof. That's not counting getting newaliases to run under the proper permissions (which still has to be done with :include: files right?) I still like David's solution best for Sendmail. Cheers, -Barry From barry@digicool.com Thu May 10 19:59:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 14:59:35 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509232329.B30678@orwell.bok.net> Message-ID: <15098.58647.622157.397405@anthem.wooz.org> Fil> So in postfix create a new virtual domain (listes.rezo.net in Fil> my case) within the /etc/postfix/virtual file ; **this domain Fil> will be totally used by mailman** Hi Fil, If I understand correctly, this means your mailing lists have to be advertised as mylist@virt.mydomain.com, right? I.e. you have to expose the virtual host in the domain part of the address. What if I want to advertise lists as mylist@mydomain.com? Does your approach accomodate that? Thanks, -Barry From barry@digicool.com Thu May 10 20:06:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 15:06:35 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <30844.989516597@kanga.nu> Message-ID: <15098.59067.652111.916123@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> If you touch the DBM file you need to touch the aliases file, JCL> always. Otherwise you're in the position of actively working JCL> to deceive admins in regard to the state of their mail system JCL> (what they can see says one thing, what they can't see says JCL> another, and they have to have specialised knowledge to know JCL> that there's likely to be a difference). >> What I don't want to do is use the plain text file as the >> canonical database file for integration with the MTA. I fear >> the grepping and cut-n-paste that would have to be done >> programmatically would be too fragile. JCL> Hardly. JCL> Put a comment block at the top of the file stating that this JCL> file is maintained by the CGI at URL . Include a JCL> warning that manual editing *might* break supports for this JCL> file format. Have newlist and the CGI always use the same JCL> formating. As all you are relly interested in are the JCL> ^listname:[ \t]*.* lines, they're easy enough to match and JCL> edit. >> And then you still have to get newaliases run, which poses >> problems in its own right. JCL> Nope. You do both: touch the text file AND the DBM. I think I see what you're getting at. Agreed, with the caveat that if the human operator modifies the text file and regens the db file, any f*ckups are outside Mailman's responsibilities to fix (although I'll do my best to fail gracefully). -Barry From fil@rezo.net Thu May 10 20:57:01 2001 From: fil@rezo.net (Fil) Date: Thu, 10 May 2001 21:57:01 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15098.58647.622157.397405@anthem.wooz.org>; from barry@digicool.com on Thu, May 10, 2001 at 02:59:35PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509232329.B30678@orwell.bok.net> <15098.58647.622157.397405@anthem.wooz.org> Message-ID: <20010510215701.A7641@orwell.bok.net> @ Barry A. Warsaw (barry@digicool.com) : > > Fil> So in postfix create a new virtual domain (listes.rezo.net in > Fil> my case) within the /etc/postfix/virtual file ; **this domain > Fil> will be totally used by mailman** > > Hi Fil, > > If I understand correctly, this means your mailing lists have to be > advertised as mylist@virt.mydomain.com, right? I.e. you have to > expose the virtual host in the domain part of the address. > > What if I want to advertise lists as mylist@mydomain.com? Does your > approach accomodate that? Dear Barry, In fact I do expose them as listname@rezo.net (and not listname@listes.rezo.net). On the rezo.net server (which i separate from listes.rezo.net for efficiency purposes: I don't want my personal mail mixed with heavy list sends) there is a fallback mechanism implemented with a virtual domain served as regexp. **This is very convenient, but not necessary, as the following will show.** Let's summarize what I use ************************** on rezo.net you find: ----------- /etc/postfix/main.cf: virtual_maps = hash:/etc/postfix/virtual /etc/postfix/virtual: rezo.net virtual fil@rezo.net fil # localhost delivery .... # any other fixed addresses and aliases @rezo.net @listes.rezo.net on listes.rezo.net: ------------------ /etc/postfix/main.cf virtual_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/virtual-regexp /etc/postfix/virtual: listes.rezo.net virtual postmaster@listes.rezo.net root # intercept the usual stuff root@listes.rezo.net root abuse@listes.rezo.net root /etc/postfix/virtual-regexp: # everything that comes here is served (of refused!) by mailman /^([a-zA-Z0-9\_\-]+)-(post|admin|request|subscribe|unsubscribe)@listes\.rezo\.net$/ mailman-$2+$1 # everything that comes here is for posting to a list, so go back to list-post /^([a-zA-Z0-9\_\-]+)@listes\.rezo\net$/ $1-post@listes.rezo.net # everything that comes here is braindead (addresses like toto%2@listes.rezo.net) /@listes\.rezo\.net$/ abuse@listes.rezo.net How to do it more simply (i.e. no supplementary domain) ************************ Just take the listes.rezo.net part, replace listes.rezo.net by your domain.net, and add the "fixed aliases" after the abuse@domain.net line in /etc/postfix/virtual Hope this helps -- Fil From benwa@ocentrix.com Thu May 10 20:52:40 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 10 May 2001 12:52:40 -0700 Subject: [Mailman-Developers] Creation/deletion of liststhrough-the-web Message-ID: <200105101952.f4AJqeb18762@mail.ocentrix.net> This is a multi-part message in MIME format. ------=_Next20010510-125240-18757-1424770306 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 TXkgYXBvbG9naWVzIGZvciB0aGUgbWlzc2luZyBhdHRhY2hlbWVu dC4KCi1CZW4= ------=_Next20010510-125240-18757-1424770306 Content-Type: application/octet-stream; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="saveemail_patch_for_newlist.txt.gz" H4sICOLL+ToAA25ld2xpc3QAjRn9b5tI9uei/SPeOvKBdTax095H3U1VN3VTS3Gasx1V0V5l ERjHqMCQGYhr7e797ffezICBkLSoqmHmfX/P5OhXOM6lOL4Nk2OWPEC6z7Y8sY6sIzjj6V6E d9sMnLMejF6//ncf/3vdPxkOh/TfCG73kG0ZfBSMwZJvsp0n8IvnSeBlIU/6MEt8V9FabUMJ qeB3wosBXzeEIg3KG9jzHHwvAcGCUGYivM0zBmEGXhIcc4H4MQ/CzZ6WkDgTim3GRCyBb9TH +eU1nLOECS+Cq/w2Cn24CH2WSIbYHvKmNbllwY+EfgMsxH0BD0xI/IYTJGCYGIp94AIcLyOx BfCU0Hoo6x4iLztgoubQovpBwwDCRNHd8hTV2SJFVHAXRhHcMsgl2+RRHykgLHyZrT59vl7B 5PIGvkwWi8nl6uYNwqK3cJc9ME0pjNMoRMKolPCSbI+SI4H5dHH2CTEm72cXs9UNif9xtrqc Lpfw8fMCJnA1WaxmZ9cXkwVcXS+uPi+nLsCSkVBkv6eNCxukFXO0YMAyL4ykUfoGHSpRtCiA rffA0LE+Cx9QMA98DKuf81rEkzulIsIebPgGwg0kPOvDToQYJhlv8SeiN+OwD/94DSuGBmJw FXk+gwEsc6Lw8uWwD++5zAh0PoHhyWg0GoxeDv/Vh+vlxLWsTqdzJhg6F+VP2K6PUZjyNCd3 BxCj3iFKivGVIey19O7YGLrO1eLz+WIy70n4XceI/KpgEi9m6sUL4jAZeEEgQL+mnpQ7LgLL +qwRxpYF+Azu9c/gPg9Zpt7pueQi9qJIx7OiQKHlZegSNBeaKNyEOuAZyYghu6Hw9MiScZr1 VMiV1JBIKJRc6DKJEYgh5SulAwwGFcVaDZB5mgomJZN1Cpqjr2xOqavk0rzQPq7RBZM/jJhR SGJwKOFO1eKLSZoyg6hl1lkhQbIkK1xdV9WEErpFCW+9QCgiVghN/1CcIAiVXLiLtAJyWIVL C2HrRZ5EqCVan2hgOgaFCryqAuZfmmen5Qo9FTW8KPRI/IxsQHnA45iZwJRgZO03RCwJpSJM MiNrrGTP0LCeCECzLSTaHg8GWxalJeIVIeq8oXUslt9VOQX2PSSsG1NxZcp8qqwoY0wVzFjT E3c5iplJ2qDqvMNqAlwXGVKBSGHUs7Gldk3N0s7GmKOyQKBxKCWJzxOGpcG65JkpdEUiIAOh qoiPWKhfxHdM+J5kLiWdZWFB4yIDuZfFKy/fqI4md8VXFsaseL9jGeVS5RNDtySWetlWWhuU FebofdQFzE4cr/3NXesWfV5QfLVtXmdY+lp3pkJw0b41x+DCUlHbcz+hYSPsHwWQ+Z5czepw Z2KfZgWQTx+WZQoOnJK5XHThw+/Dr5a1nF5+mE9mF+vJxWyyXK+m86uLyWqKYLZtW0dHWKoK b/RkrZrRpikBVNAwaAmi62AuiJ60NB6udP7sOjvhYdDjMqRYSWs0OwipUusRKDHjO6z/j+AF u89ZC3HC8OPgEbyicqKkO2wMFFeL1LT+024CCjJMF+ZvOdh/YlmjoIZn1bHh7f9UVh+79yTO oLr5A2LtCj9L0SjxY7pNszxP1Rj4QPdvj5k+oqBEf0Lfn8GvgShihO9vcbyDf756BU9DP7N1 MNDPECoUfw7kh5K12EFVqyMcgzZeHmXSWq4+4Lw2X55Tnk2TTOxVUVRkmO6BY9tS8VgJxydy 1bJktse55dTUPFeVSUeXK3e+mmj46XK9XN1cTHsWjkgaA06RvRLaHqvm0OTYlhcKsKbAiptC QKUlw1Zk9EAVMBgLZr+9BZuaa4WdamDQ+eKJBOX+FWYQ8MQ2Y7xqZkWHJArjTh+eUqpCznZU Y1NdR68UXDUZ13V7mPLWLxa6g6o/FSzyk9PTUhXfqBqXLp57QoHzOgI69vVyurB7NCI3dy4+ n19O5lO7p0joIbSkNC47b9FkdkG5VGGHy0Qt3eVh4CAHEg7fej0q1c/SrRCxf8uTbwkG4Vtb bQskIpISotQ8p/7i+DzAASOWd6e23at6Zb0OuL9eF2wRYlwfPGhJrVA/ocFB0eqV9NHiSWFS DPADNnZb2achQqK0uvu6+scpW9No/LUP9paP7zGK+iXqM8/vNo0yNmKZmYte1UhML4dR0v6q XcS++ywtur/LqBP361pqA43Uak+PUp4a3Sg9UfRLnFvUquKCC0NNmNg0QSi7kY9Sm8Y5skEl Kja0QOuOPeAkbzE5Fj4pnpoASKudxFaTUAZpENBKDXvtiPcaUZutgVloObJe1HCkxiktTHgv moYgUYtQiljikPd78BaGCFseexSYLGKdRZLVd4W3W4cJWsXpYM00B321ZwZTgh1DRytXQazV xbIslwLZ72zSpdhoiQCbhjvNKs7pjZP2fpQHDDrvOmOw4e/wmLCa/FxaX2OCyEwemD/JxIuw lAZ70AhPUa7acIRWUj1nrYqcseKoZsXa/sGO2lEVa+oTjzEnTg8Sp3qRJ0lxIiot3CbIiXHX Ot0VUpxUpSg0PsCYUdw1v05nluApB8/7XRytzHkX2UG3YgKicATKVgWIpNMK+eSWNEizvVVn Y/xPP6ljlmuF2qy1OWVltC6ZNXnZxhixgjotzwJu8eL0HtdAJZaazAt5oG/C5ZxlC+x8PF4y RrW/xDmCu9yjixtmjkl4vKeTLZ7xzRyuBgepL1XM8Rp9SH5URy26dToQM5t3gucpqPiQ2zAt LmZQO9Q3F4c7MS/PuM8TbOc+mjGrUGIJHdF0iBixghAPs3hODqviaFYyC/1ve7gNqTEfyPAI e7T8pptuTq/OcHhy0L5mvtaF0gmuvo4pk60Ph/DvQ+H64tmECd2TPKZVymFEO6CZ3qGPb+58 /t4LpkRcLbTVWwokBNJymCSjqx085OkMPwj4NBeKpYmuDlNVHJ5l97PFRGmqeg2avj7/deGP GnG7QLXHJZX+Ywib3jBru4OTV5Jyt3QEcu+MO70Gjjmo2Ihjd+Vx+dktpr0vi8nV1XSx/jBb NFDNQaLBrtM1Y/+4VjkauGbUtx/jmp1nsfWR0m7hrHaexaWjsjES3UtQXdrQi2N3g0H3dtC9 wZaqdiLue5HaUp/qrddr0qPRztCrjbN1sL8a41s5wjfWdTBU54PD0FEPtk1K2ZpSByghMPI8 u5FgqasuYx1N+YlN+7/JYzw/4hIVsSrFxpw0VOvnWEpYeZ2k6m95OlOPutg6NYU19r4xWnDq 1qMKSkUj+541Js0/DgGvrdse9GAXraEChhW9Dw0wFZPrXEQ6YnWtwnK/VAX1enHhmIDGMfFW 8ijP2Omo94gMoYVYchWldjIFSINSg5CJcypEOgvK0H/XrSdu33DZctSsJaRpVK9ZqgHegP7r 4Gicraln6tsu9xpj97JyUVx3VaWK110Y63svnXrvqMg9y9++oT/N0J1w9T6rXh3rGBQ2GIU0 +JZT7VO5UAI8lwqaYOvWzyWCGVzUUF6XRGex0/mEDZbpwQ7P55xuinOm/2KC05XuRNVLeTwX d9oOWk/WMTqsySwIE5eaDN06OXW5j9TJu5qq5iq9JVPpOVxnuh9YFD4wseIUEY7ypjmHKYM0 W7Z293WC9fIbWekXuuNYK9ev1+qWY01xk6zX5uZBH06t/wMUoqEv4RwAAA== ------=_Next20010510-125240-18757-1424770306-- From marc_news@valinux.com Thu May 10 21:42:57 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Thu, 10 May 2001 13:42:57 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <20010509104304.J29713@magic.merlins.org>; from marc_news@valinux.com on Wed, May 09, 2001 at 10:43:04AM -0700 References: <15094.52272.753043.181192@anthem.wooz.org> <20010509104304.J29713@magic.merlins.org> Message-ID: <20010510134257.Q31816@magic.merlins.org> On Wed, May 09, 2001 at 10:43:04AM -0700, Marc MERLIN wrote: > I just noticed this in my locks directory: > usw-sf-list1:/var/local/mailman/bin# l ../locks/ > total 24 > drwxrwsr-x 2 mailman mailman 16384 May 9 10:40 ./ > drwxrwsr-x 21 mailman mailman 4096 Apr 10 15:06 ../ > -rw-rw-r-- 1 mailman mailman 59 May 7 05:42 jboss-user.lock.usw-sf-list1.26443 > usw-sf-list1:/var/local/mailman/bin# > (prcoss 26443 doesn't exist obviously) > > Note that this is not bad because it doesn't keep the list locked. There is > probably a small race in the removal of the temporary lockfile that you link > to though. > > I'll delete this one and see if others pop up over time. Just got another one (so it's apparently not an isolated case) usw-sf-list1:/var/local/mailman/bin# l ../locks/ total 24 drwxrwsr-x 2 mailman mailman 16384 May 10 13:40 ./ drwxrwsr-x 21 mailman mailman 4096 Apr 10 15:06 ../ -rw-rw-r-- 1 mailman mailman 60 May 10 05:29 madchat-spam.lock.usw-sf-list1.8790 Again, it's not fatal since the list doesn't remain in locked state, but something is apparently still slightly off somewhere :-) 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@digicool.com Thu May 10 22:31:48 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 17:31:48 -0400 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 References: <15094.52272.753043.181192@anthem.wooz.org> <20010509104304.J29713@magic.merlins.org> <20010510134257.Q31816@magic.merlins.org> Message-ID: <15099.2244.184017.746400@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Just got another one (so it's apparently not an isolated case) Dang. MM> usw-sf-list1:/var/local/mailman/bin# l ../locks/ total 24 MM> drwxrwsr-x 2 mailman mailman 16384 May 10 13:40 ./ drwxrwsr-x MM> 21 mailman mailman 4096 Apr 10 15:06 ../ -rw-rw-r-- 1 mailman MM> mailman 60 May 10 05:29 madchat-spam.lock.usw-sf-list1.8790 MM> Again, it's not fatal since the list doesn't remain in locked MM> state, but something is apparently still slightly off MM> somewhere :-) Yeah, that's annoying. :) I haven't got any lock turds on python.org, but then again, you probably have slightly higher traffic than we do . If I get some time, I'll stare at the LockFile.py code again. Any idea what process 8790 was? I wonder if it's the same code that's not cleaning up after itself. Hmm, -Barry From chuqui@plaidworks.com Fri May 11 06:23:30 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 10 May 2001 22:23:30 -0700 Subject: [Mailman-Developers] http headers? Message-ID: I can't find these offhand in the source -- anyone know what the MIME type the python returns itself as for the pages it generates? I'm experimenting with a new (non-intrusive) way to skin a UI on Python, but they aren't quite cooperating... From claw@kanga.nu Fri May 11 06:56:15 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 10 May 2001 22:56:15 -0700 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Thu, 10 May 2001 15:06:35 EDT." <15098.59067.652111.916123@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <30844.989516597@kanga.nu> <15098.59067.652111.916123@anthem.wooz.org> Message-ID: <2127.989560575@kanga.nu> On Thu, 10 May 2001 15:06:35 -0400 Barry A Warsaw wrote: > I think I see what you're getting at. Agreed, with the caveat > that if the human operator modifies the text file and regens the > db file, any f*ckups are outside Mailman's responsibilities to fix > (although I'll do my best to fail gracefully). Precisely. Ultimately its the principle of least surprise. What I don't want to see is: Mailman is so lame and broken! Our admin just touched the alias file and now ___ALL___ of our Mailman lists are gone -- AND HE DIDN"T EVEN CHANGE ANYTHING! Stoopid bloody software. Mailman is just so braindead... Or words to that effect. I think we can handle things a little more gracefully than that, both by adding a commented warning and documentation at the top of the alias file (genned on file create and re-added if file touched by Mailman and comments cound missing (cf IMAP and first message)), and by attempting to be graceful (which also means keeping backups at the filesystem level), about all Mailman-driven alias file operations. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From lmb@suse.de Fri May 11 10:18:42 2001 From: lmb@suse.de (Lars Marowsky-Bree) Date: Fri, 11 May 2001 11:18:42 +0200 Subject: [Mailman-Developers] Porting "NetiquetteEnforcer" to mailman Message-ID: <20010511111842.X639@marowsky-bree.de> Good morning, I have switched my mailing lists from ezmlm to mailman (mostly because I wanted to use postfix) a few months ago. Under ezmlm, I wrote a cute little script called "NetiquetteEnforcer.pl", which did a rather good job at rejecting "annoying" (incorrectly formatted etc) mails. (If you are interested, you can look at http://lars.marowsky-bree.de/dl/NetiquetteEnforcer.pl ) Now, I meant to port this ages ago, but you know how "I will do it in my copious spare time" works out in practice... I am looking at how to integrate this properly with mailman. What I would probably have to do is to hook in HandlerAPI much like the "Hold" Handler and either hold the message, reject it immediately or let it pass through. However, I am unclear about how to do get the configuration information done properly - I would rather like an additional screen for the Content Filtering scheme in the Web management tools, and it isn't immediately obvious to me how I would go about this. Any insight would be appreciated. Sincerely, Lars Marowsky-Brée -- Perfection is our goal, excellence will be tolerated. -- J. Yahl From thomas@xs4all.net Fri May 11 13:28:29 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 11 May 2001 14:28:29 +0200 Subject: [Mailman-Developers] http headers? In-Reply-To: ; from chuqui@plaidworks.com on Thu, May 10, 2001 at 10:23:30PM -0700 References: Message-ID: <20010511142829.N16486@xs4all.nl> On Thu, May 10, 2001 at 10:23:30PM -0700, Chuq Von Rospach wrote: > I can't find these offhand in the source -- anyone know what the MIME type > the python returns itself as for the pages it generates? I'm experimenting > with a new (non-intrusive) way to skin a UI on Python, but they aren't quite > cooperating... I'm not sure I understand the question. You want to know what mimetype CGI scripts written in Python return by default ? Well.... nothing :) CGI scripts have to return the mimetype explicitly. The 'cgi' module only handles the request part of CGI, not the response part. If you use something like HTMLgen, it depends on what Document you generate. So it should be stated, either explicitly or implicitly, somewhere in your code. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From webmaster@isu.edu Fri May 11 14:54:43 2001 From: webmaster@isu.edu (Webmaster) Date: Fri, 11 May 2001 07:54:43 -0600 Subject: [Mailman-Developers] Qrunner error Message-ID: <3AFBEF23.AEF4668B@isu.edu> Does anyone know what this error means and how to fix it. Traceback (innermost last): File "/home/mailman/cron/qrunner", line 78, in ? import time ImportError: /usr/lib/python1.5/lib-dynload/timemodule.so: undefined symbol: PyErr_Format -- ############################### Webmaster webmaster@isu.edu Computing & Communications ################################ From barry@digicool.com Fri May 11 15:53:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 11 May 2001 10:53:49 -0400 Subject: [Mailman-Developers] Qrunner error References: <3AFBEF23.AEF4668B@isu.edu> Message-ID: <15099.64766.425834.892330@anthem.wooz.org> >>>>> "W" == Webmaster writes: W> Does anyone know what this error means and how to fix it. W> Traceback (innermost last): | File "/home/mailman/cron/qrunner", line 78, in ? | import time W> ImportError: /usr/lib/python1.5/lib-dynload/timemodule.so: W> undefined symbol: PyErr_Format It looks to me like your Python installation is pretty broken. What Python version are you using? I'd suggest re-installing Python. -Barry From barry@digicool.com Fri May 11 21:49:47 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 11 May 2001 16:49:47 -0400 Subject: [Mailman-Developers] Porting "NetiquetteEnforcer" to mailman References: <20010511111842.X639@marowsky-bree.de> Message-ID: <15100.20587.961110.136806@anthem.wooz.org> >>>>> "LM" == Lars Marowsky-Bree writes: LM> I have switched my mailing lists from ezmlm to mailman (mostly LM> because I wanted to use postfix) a few months ago. Under LM> ezmlm, I wrote a cute little script called LM> "NetiquetteEnforcer.pl", which did a rather good job at LM> rejecting "annoying" (incorrectly formatted etc) mails. | (If you are interested, you can look at | http://lars.marowsky-bree.de/dl/NetiquetteEnforcer.pl ) LM> Now, I meant to port this ages ago, but you know how "I will LM> do it in my copious spare time" works out in practice... LM> I am looking at how to integrate this properly with LM> mailman. What I would probably have to do is to hook in LM> HandlerAPI much like the "Hold" Handler and either hold the LM> message, reject it immediately or let it pass through. LM> However, I am unclear about how to do get the configuration LM> information done properly - I would rather like an additional LM> screen for the Content Filtering scheme in the Web management LM> tools, and it isn't immediately obvious to me how I would go LM> about this. LM> Any insight would be appreciated. Adding a new admin screen is actually pretty easy. I think a good (modern) example is GatewayManager.py or Autoresponder.py. Essentially you are going to write a mixin class that will be added to the base classes for MailList. Your mixin should include a GetConfigInfo() method which contains all the specifications for the gui widgets on your admin screen. You might also need an InitVars() method. Where the black magic comes in: if you're adding new attributes to the MailList object, you should add code to versions.py so that existing list schemas will be automatically updated when the list is loaded. You also need to do a moderate bit of glue work in the MailList class and in the admin.py script. Adding NetiquetteEnforcer as another hold should be much simpler, and I still have it on my todo list for 2.1 to improve the configurability of the holds (so some matches can automatically discard or reject, etc). -Barry From jarrell@vt.edu Sat May 12 01:41:43 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 11 May 2001 20:41:43 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15098.57980.802114.12603@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <20010510133740.47780@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010511203909.02b2cda0@vtserf.cc.vt.edu> At 02:48 PM 5/10/01 -0400, Barry A. Warsaw wrote: >I still like David's solution best for Sendmail. His solution is slick, but it requires you run mailman lists off of a special hostname. Granted, many of us do, but not everyone. Heck, my mail mailman server has several lists.whoever domains, but also has some orphan lists not claimed by a particular organization that list under the machines own hostname. Which is where mailman insists on creating them by default normally... From chuqui@plaidworks.com Sat May 12 05:47:38 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 11 May 2001 21:47:38 -0700 Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or less...) Message-ID: I've got this running now, so I figured I'd toss out a cookbook recipe on it while it's fresh. I've always hacked Mailman to install a custom interface on it so it matches the rest of my sites (for instance, see www.hockeyfanz.com/mailman/listinfo). The downside to this is that every time a new release comes out, you have to repatch all your changes. This makes it more work to upgrade than it should be, so I've been keeping an eye out for a better way to do this (and it gets worse -- on one of my sites, I also have a web board that needs custom patching, my mhonarc rcfiles that need patching, and the standard files that need tweaking every time the UI or graphics get revamped, and I'm not always in control of when they get redone...) I finally found a tool that takes care of this for me -- it's called mod_layout (www.tangent.org), and it's an apache module, so this is apache specific. If you run your apache with DSO (and if you don't, you're crazy...), installation is trivial. Download the thing, unpack it, then run "make" and "make install". It uses APXS to handle everything. To get it running, I added these lines to the httpd.conf. In my case, they're in the declaration (it supports all fo the apache stuff, so it recognizes and honors virtual hosts, directories, etc... Very flexible beast) # stuff to wire in mod_layout LayoutMerge On LayoutFooter /home/httpd/html/footer.incl LayoutHeader /home/httpd/html/header.incl (I also have some lines causing it to NOT tweak files in directories I want left alone -- it can be configured on a file or directory basis, host basis, or systemwide) Then create the header and footer, and restart apache. What mod_layout does (as configured here) is put itself in the middle of everything, and when it sees the declaration, it inserts the header. And when it sees it inserts the footer before it. For the CGI or html page, it's completely transparent, and you don't have to worry about screwing up CSS or javascript, and it leaves cookies alone. It also doesn't affect your HTML, since it comes after the so it can't interrupt tables or other location sensitive things. Very nice hack, IMHO, and allows you to wrap an interface around mailman quite nicely -- as well as most other CGI-based stuff that doesn't support templating. And even nicer, IMHO, is that if you need to change things, you change the included files -- and it magically propogates, no need to even restart apache. This gives me control over almost all of Mailman (and, hint hint) -- hopefully Barry will add the configuration for the rest down the road. One is that some of the text-box colors are hard-coded (see, for instance, /mailman/admin/listname/general/. It'd be nice (and it seems to be easy to do) to turn those into globals that can be set in mm_cfg.py instead of requiring someone to whack all of the source files they're sprinkled in. The other key one for me are some of the admin messages (Mailman/Handlers/Hold.py). I've modified some of the messages for various reasons, and it'd be nice if I could simply override their definitions in the mm_cfg.py file And the third place I've made custom changes are in some of the list templates (most radically templates/listinfo.html) -- but that's why they're template; you simply keep a copy somewhere and watch out for additions to the updated copy... It took me about three days and a couple of exchanges with the author of mod_layout to get it going the way I wanted (the documentation is still being fleshed out), but it's a nice improvement to the old way of doing things -- and since I know others build custom skins around their installations, I'd thought I'd pass this one along. If you want to see a version of mailman with mod_layout, see www.plaidworks.com. My mailman set up the old way is www.hockeyfanz.com (for now. I'll be working to move this to all my stuff over time...) Chuq From Donal.Hunt2@mail.dcu.ie Sat May 12 18:54:11 2001 From: Donal.Hunt2@mail.dcu.ie (Donal Hunt) Date: Sat, 12 May 2001 18:54:11 +0100 Subject: [Mailman-Developers] Re: Mailman and LDAP integration [was python-ldap and openldap 2.07] References: Message-ID: <3AFD78C3.6138ED36@mail.dcu.ie> Jens Vagelpohl wrote: > > > Have the authentication bit working at the moment. Having a think about > > how to store the mailman subscription information still. Whether to store > > the attributes (subscription type, nomail option, etc) as a sub-object of > > the person object or to have lots of atrributes named in such a way that > > they are unique to their list, but easily searchable and don't add a lot > > of load to the LDAP protocol. Any suggestions or preferences from a > > general POV?? > > i personally would define an object class that has all the mailman-specific > attributes as "MAY"-attributes. then you simply add this object class into > the object class statements for your user records. all mailman-specific > records are then simply stored on your user record along with the rest of > the information. > > you could also create separate records that carry the email address and > mailman-specific stuff (or better, that carry anything needed by mailman), > but then you'd have to make sure that info is in sync with your "normal" > user records in case someone is defined as a normal user record and has a > separate mailman record as well. I'm sure whether to have something like a sub-object with something like: dn: cn=myname, ou=dept, o=company | ---------------------------------------------------- | | dn: maillist=mylist@dom.org, cn=myname, ou=dept, o=company another maillist dn | | |-nomail: yes |-nomail: no |-digest: no |- etc |-etc or dn: cn=myname, ou=dept, o=company | |- some attribute combinations... |- nomail: yes |- digest: yes |- etc the top way of organising things is more scalable and easier to manage (i think). but the second one only allows for one option for all your mailing lists - ie you have digest enabled for all or non e of your mailing list subscriptions. Or maybe i list the mailing list names in the nomail attribute and parse it on the mailman side to see if nomail is set for the particular list. eg: nomail-yes: maillist-1@list.org, maillist-2@list.org nomail-no: maillist-4@list.org, maillist-5@list.org or something along those lines... Hmm... think i should cc this onto Mailman-dev actually... > > As regards code, I'll be releasing it to the Mailman developers and anyone > > who wants it once it's working... > > barry warsaw is working for my company ;) I'm cc-ing this to the Mailman-dev mailing list - I'm subscribed to it, but slightly behind in reading the digests (only by some 75 days!! hehe) - just so they know someone is playing with it. I know it's on the WishList for Mailman 3.x, but no harm in seeing what's involved and exploring the unknown... Regards Donal From claw@kanga.nu Mon May 14 07:21:43 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 13 May 2001 23:21:43 -0700 Subject: [Mailman-Developers] Administrivia: Move to EZMLM (fwd) Message-ID: <2799.989821303@kanga.nu> An message interesting for some of the advantages they see in EZMLM as versus ListServ. While obviously not the driving forces, the comments about Precedence: and Sender: headers caught me by surprise. ------- Forwarded Message Date: Sun, 13 May 2001 23:51:27 -0600 From: aleph1@securityfocus.com To: bugtraq@securityfocus.com Cc: aris-users@securityfocus.com, bugtraq-es@securityfocus.com, bugtraq-jp@securityfocus.com, certification@securityfocus.com, cisspstudy@securityfocus.com, focus-ids@securityfocus.com, focus-linux@securityfocus.com, focus-ms@securityfocus.com, focus-sun@securityfocus.com, focus-virus@securityfocus.com, forensics@securityfocus.com, incidents@securityfocus.com, isn@securityfocus.com, libnet@securityfocus.com, linux-secnews@securityfocus.com, ms-secnews@securityfocus.com, pen-test@securityfocus.com, secevents@securityfocus.com, secpapers@securityfocus.com, secprod@securityfocus.com, secprog@securityfocus.com, sectools@securityfocus.com, security-basics@securityfocus.com, securityjobs@securityfocus.com, sf-news@securityfocus.com, vpn@securityfocus.com, vuln-dev@securityfocus.com, www-mobile-code@securityfocus.com Subject: Administrivia: Move to EZMLM Good day, [ I apologize to those that will receive this message multiple times ] As undoubtedly you will have noticed by now we experienced some problem with our mailing lists this past week. In short, LISTSERV finally croaked. It simply could not handle the load. We hoped to perform the these changes in a couple of months as part of our upgrade strategy but we were forced to accelerate our scheduled plans. We have moved the mailing lists over to ezmlm-idx. This will require a little getting used to but it should not be particularly challenging. ezmlm-idx offers most of the features LISTSERV does and a few of its own. Performance wise it should give LISTSERV a good beating. To familiarize yourself with ezmlm-idx review the ezman manual at http://www.ezmlm.org/ezman-0.32/index.html. If you were using the digest option under LISTSERV you will need to unsubscribe from the list and resubscribe to the digest. This can be easily accomplished by sending messages to the -unsubscribe@securityfocus.com and -digest-subscribe@securityfocus.com addresses. Messages that had been received by LISTSERV but not yet processed, including messages that had become stuck on its queue and appeared to disappear last week, have been re-injected into the mail system. List moderators may, or may not, approve them, as appropriate. Aside from the speed benefits of ezmlm, messages now include a Precedence header which should cut down on the number of out-of-office and similar messages people that post to the list get. This is a feature L-Soft refused to provide. If you ever post to the list this should make you very happy. People that send messages with strange Sender headers should have no more problems either. Another quirk of LISTSERV L-Soft did not believe to be a problem. If you have any questions or comments please feel free to contact me. Cheers. - -- Elias Levy SecurityFocus.com http://www.securityfocus.com/ Si vis pacem, para bellum ------- End of Forwarded Message -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From chuqui@plaidworks.com Mon May 14 07:52:22 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 13 May 2001 23:52:22 -0700 Subject: [Mailman-Developers] Administrivia: Move to EZMLM In-Reply-To: <2799.989821303@kanga.nu> Message-ID: On 5/13/01 11:21 PM, "J C Lawrence" wrote: > While obviously not the driving forces, the > comments about Precedence: and Sender: headers caught me by > surprise. > Aside from the speed benefits of ezmlm, messages now include a > Precedence header which should cut down on the number of out-of-office > and similar messages people that post to the list get. Very true. Precedence: bulk or Precedence: junk helps a lot. Sendmail's vacation program is smart enough to not respond to stuff so flagged. Not everyone does (sigh), but I've tested this, and there's a big improvement. > This is a feature > L-Soft refused to provide. (boggle) > People that send messages with strange Sender headers should have > no more problems either. Another quirk of LISTSERV L-Soft did not > believe to be a problem. The implication being if I insert a Sender line, under some cases LISTSERV does something weird to it? Shouldn't a MLM override this and replace it with the MLM's? From Nigel.Metheringham@InTechnology.co.uk Mon May 14 09:38:41 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Mon, 14 May 2001 09:38:41 +0100 Subject: [Mailman-Developers] Administrivia: Move to EZMLM (fwd) In-Reply-To: Message from J C Lawrence of "Sun, 13 May 2001 23:21:43 PDT." <2799.989821303@kanga.nu> Message-ID: claw@kanga.nu said: > An message interesting for some of the advantages they see in EZMLM as > versus ListServ. While obviously not the driving forces, the comments > about Precedence: and Sender: headers caught me by surprise. Relating this to mailman, it appears to me that we do the right thing (tm) with both those headers. The big advantage with EZMLM is the bounce handling - basically because it uses VERP and mangles the envelope. The downside is the mail-only one address per function (subscriber) control interface (although it is proof against the Outlook user incapable of sending plain unencoded text problem). Those that pay per byte bandwidth charges might also find ezmlm more expensive to run. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From claw@kanga.nu Mon May 14 09:50:21 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 14 May 2001 01:50:21 -0700 Subject: [Mailman-Developers] Administrivia: Move to EZMLM (fwd) In-Reply-To: Message from Nigel Metheringham of "Mon, 14 May 2001 09:38:41 BST." References: Message-ID: <731.989830221@kanga.nu> On Mon, 14 May 2001 09:38:41 +0100 Nigel Metheringham wrote: > The big advantage with EZMLM is the bounce handling - basically > because it uses VERP and mangles the envelope. The downside is > the mail-only one address per function (subscriber) control > interface (although it is proof against the Outlook user incapable > of sending plain unencoded text problem). Those that pay per byte > bandwidth charges might also find ezmlm more expensive to run. It doesn't seem conceptually difficult to setup an Exim filter which could be installed on a smart host such that list mail sent through it is VERPed EZMLM-style. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From jra@baylink.com Mon May 14 14:45:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 14 May 2001 09:45:15 -0400 Subject: [Mailman-Developers] Administrivia: Move to EZMLM In-Reply-To: ; from Chuq Von Rospach on Sun, May 13, 2001 at 11:52:22PM -0700 References: <2799.989821303@kanga.nu> Message-ID: <20010514094515.16447@scfn.thpl.lib.fl.us> On Sun, May 13, 2001 at 11:52:22PM -0700, Chuq Von Rospach wrote: > > This is a feature > > L-Soft refused to provide. > > (boggle) Indeed. > > People that send messages with strange Sender headers should have > > no more problems either. Another quirk of LISTSERV L-Soft did not > > believe to be a problem. > > The implication being if I insert a Sender line, under some cases LISTSERV > does something weird to it? Shouldn't a MLM override this and replace it > with the MLM's? Unless I've *vastly* misunderstood everything I've read: no. It should add Resent- headers, but Sender: carries valid sourcing information, and I don't think it should be replaced. (I'm deriving that from RFC 2822, 3.6.2 and 3.6.6, but I've been known to be wrong before...) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From olk@olk.co.kr Wed May 16 17:50:51 2001 From: olk@olk.co.kr (¿Â¶óÀÎÄÚ¸®¾Æ) Date: Thu, 17 May 2001 01:50:51 +0900 Subject: [Mailman-Developers] mailman-developers´Ô ¾È³çÇϼ¼¿ä? Message-ID: <3W-POP3-AC9EXxt5BBB00000712@3w-pop3-ac.korea.com> PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWljcm9z b2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KPFA+PEZPTlQgY29sb3I9IzAwODAwMCBmYWNlPbG8uLLDvCBzaXplPTI+osQg v8C0w8DHIMCvuNMgosU8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0y PjxGT05UIGNvbG9yPSMwMDAwODA+oeGw+r3Dv+U8L0ZPTlQ+PEJSPkEgZ2lybCBnb3QgYW4g DQplbmdhZ2VtZW50IHJpbmcsIGFuZCB3b3VsZCBzZWl6ZSBldmVyeSBvcHBvcnR1bml0eSBm b3IgPEJSPmNhbGxpbmcgYXR0ZW50aW9uIHRvIA0KaXQuJm5ic3A7IDxCUj5JbiBhIGdyb3Vw IHdpdGggZ2lybCBmcmllbmRzIG5vIG9uZSBub3RpY2VkIGl0LiZuYnNwOyBGaW5hbGx5IHdo ZW4gDQpoZXI8QlI+ZnJpZW5kcyB3ZXJlIHNpdHRpbmcgYXJvdW5kIHRhbGtpbmcsIHNoZSBn b3QgdXAgc3VkZGVubHkgYW5kIHNhaWQsIA0KPEJSPiJJdCdzIGF3ZnVsbHkgaG90IGluIGhl cmUuIEkgdGhpbmsgSSdsbCB0YWtlIG15IHJpbmcgb2ZmLiI8L0ZPTlQ+PC9QPg0KPFA+PEZP TlQgZmFjZT2xvLiyw7wgc2l6ZT0yPqHec2VpemUgZXZlcnkgb3Bwb3J0dW5pdHkgZm9yIH4g aW5nIDogseLIuLi4IMDWwLi46SB+IA0Kx8+02S48QlI+od5jYWxsIGF0dGVudGlvbiB0byA6 IH4gv6EgwdbAx7imIMivseK9w8WwtNkuIDxCUj6h3mF3ZnVsbHkgOiB2ZXJ5IDwvRk9OVD48 L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+vuDIpbndwfa4piC53sC6IL7GsKG+ vrTCILHiyLi4uCDA1sC4uOkgu+e297Xpv6Gw1CCx1yC53cH2uKYguri/qcHWt8Gw7SZuYnNw OyANCjxCUj616b76tNkmbmJzcDsgPEJSPsfRufjAuiC/qcDaxKOxuLXpsPogvu6/77fItMK1 pSC+xrmrtbUgsdcgud3B9rimILSrv6mw3CC6wcHWwfYgvsq+0rTZPEJSPri2xKezuyC+xrCh vr60wiC02bXpILXRt6++yb7GIA0KwMy+37HiuKYgs6q0qbDtIMDWtMIgxse/oSC5+raxIMDP vu68rbjpvK0gPEJSPri7x9+02S48QlI+Ir7uyN4sILT1v/a8rSC4+CCw37XwsNqz1y4gs6og ud3B9rimILupvt8gx9Kx7rrBISImbmJzcDsgDQo8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgY29s b3I9IzAwODAwMCBmYWNlPbG8uLLDvCBzaXplPTI+osQgv8C0w8DHIL+1vu4gx9G4trXwIKLF PC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48Rk9OVCBjb2xvcj0j MDAwMDgwPqLDILCou+fAxyC4u8C7IMfSILanPEJSPjwvRk9OVD6/3LG5wM616cC6ILOyv6Gw 1CC+xsHWIA0KwNvAuiC1tb/ywLsgud6+xrW1ICJUaGFuayB5b3UuKLCou+fH1bTPtNkuKSK2 87DtIDxCUj64u8fYv+QuIMDMsM3AuiC+7rfIwLsgtqe6zsXNILHXt7EgsbPAsMC7ILnewLi4 6bytIMDatvMgv9Sx4iC2p7muv6EguPa/oSANCjxCUj66o77uIMDWvu4gu/O067nmwMcgu+e8 0sfRILW1v/LAzLOqIMSjwP2/obW1ICJUaGFuayB5b3UuIrbzsO0guLvHz7TCIL3AsPw8QlI+ wLsgsK6w1CC1yLDFILCwvsa/5C4gubC30Cwgv+y4rrW1IA0KuLbC+bChwfbB9ri4v+QuPEJS PiJUaGFuayB5b3UuIr+hILTrx9EgwMC05MC6ICLDtbi4v6G/5C4itvO0wiC25sC4t84gIllv dSBhcmUgd2VsY29tZS4gLzxCUj5Eb24ndCANCm1lbnRpb24gaXQuIC9Ob3QgYXQgYWxsLiK1 7sDHIMelx/bAuyC+ssHSLiA8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6 ZT0yPkE6IEl0IHdhcyB2ZXJ5IGtpbmQgb2YgeW91IHRvIGdvIHRvIHRoYXQgdHJvdWJsZSBm b3IgDQptZS48QlI+QjogSXQgd2FzIG5vIHRyb3VibGUgYXQgYWxsLiBJdCB3YXMgbXkgcGxl YXN1cmUuPEJSPkE6IEl0J3MgdmVyeSBraW5kIG9mIA0KeW91IHRvIHNheSBzby48QlI+Jm5i c3A7PEJSPkE6IMD6uKYgwKfH2LytILHXt7EgvPaw7bimIMfYIMHWvcO0zyDBpLi7ILDtuL+9 wLTPtNkuPEJSPkI6ILm5ILz2sO229iCwzcDMIMDWs6q/5C4gDQrBprChIMHBvsa8rSDH0SDA z8DOtaW/5C48QlI+QTogsde3uLDUILi7vrjH2CDB1r3DtM8gwaS4uyCw7bi/vcC0z7TZLjxC Uj4mbmJzcDs8QlI+PEZPTlQgY29sb3I9IzAwMDA4MD6h4bCou+fAxyANCrHiursgx6XH9jxC Uj48L0ZPTlQ+osIgVGhhbmsgeW91LiAvVGhhbmtzLjxCUj4mbmJzcDsmbmJzcDsgormwqLvn x9W0z7TZLjxCUj6iwiBUaGFua3MgYSBsb3QuIA0KL1RoYW5rIHlvdSB2ZXJ5IG11Y2guIC9U aGFuayB5b3Ugc28gbXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5tOu03Mj3ILCou+fH1bTPtNku PEJSPqLCIEknZCANCmFwcHJlY2lhdGUgaXQuPEJSPiZuYnNwOyZuYnNwOyCiubHXt7iw1CDH 2CDB1r3DuOkgsKi758fPsNq9wLTPtNkuPEJSPqLCIEkgYXBwcmVjaWF0ZSBpdCB2ZXJ5IA0K bXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5sdcgwaEgwaS4uyCwqLvnx9W0z7TZLjxCUj6iwiBP biBiZWhhbGYgb2Ygb3VyIGVtcGxveWVlcyBJJ2QgbGlrZSB0byANCnRoYW5rIHlvdS48QlI+ Jm5ic3A7Jm5ic3A7IKK5wPrI8SDIuLvnv/i16cC7ILTrx6XH2LytILTnvcW/obDUILCou+cg teW4rrDtIL3NvcC0z7TZLjxCUj4mbmJzcDs8QlI+PEZPTlQgDQpjb2xvcj0jMDA4MDAwPqLE IMDfuPggvrLAzyC89iDA1rTCIMelx/YgosU8QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBj b2xvcj0jMDAwMDgwPqLDIL+pseK8rSANCjHIo7yxwLi3ziCwpb7Gxbi8xb7fIMfVtM+02Twv Rk9OVD48QlI+Jm5ic3A7PEJSPjxGT05UIGNvbG9yPSNmZjAwMDA+oeFZb3UgaGF2ZSB0byBz aGlmdCB0byANCnRoZSBOby4xIExpbmUuoeuh66Hroeuh66Hroeuh66Hroeuh66HtKFgpPEJS PjwvRk9OVD48Rk9OVCBjb2xvcj0jODAwMDgwPqHhWW91J2xsIGhhdmUgdG8gDQp0cmFuc2Zl ciB0byB0aGUgTm8uMSBMaW5lIGZyb20gaGVyZS6h66Hroeuh7ShPKTxCUj4mbmJzcDs8QlI+ PC9GT05UPqLBc2hpZnS0wiC067CzILDFwdbB9rOqIA0Ku/2wosC7ILnZstu02bTCILbmwMy5 x7fOIL+pseK8rbTCILjCwfYgvsq+xr/kLiA8QlI+Jm5ic3A7ILGzxevG7cC7ILClvsbFuLTC ILDNwLogurjF6yB0cmFuc2ZlcrbzsO0gx9i/5C4gsde4rrDtILPrvLHAuyANCrClvsbFuLTC IDxCUj4mbmJzcDsgyK+9wr+qtbUgdHJhbnNmZXK287DtIMfPtMK1pSwgwMy2p7TCILjtu+fA 1LTPtNkuIDxCUj4mbmJzcDsguvHH4LHiIL+px+Agwd+/oSCwpb7Gxbi0wiCx4sL4wfa0wiAN CnN0b3BvdmVytvOw7SDH2L/kLjxCUj4mbmJzcDs8QlI+od5Ob3cgeW91IGhhdmUgdG8gc3dp dGNoIHRvIHRoZSBOby4xIExpbmUuKL+pseK8rSAxyKO8scC4t84gDQqwpb7Gxbi8vL/kLik8 QlI+od5Zb3UgaGF2ZSB0byBnZXQgb3ZlciB0byB0aGUgTm8uMSBMaW5lLigxyKO8sSDCysC4 t84gsKG8xbytIMW4vLy/5C4pPC9GT05UPjwvUD4NCjxQPjxGT05UIGNvbG9yPSMwMDgwMDAg ZmFjZT2xvLiyw7wgc2l6ZT0yPqLEIL/AtMPAxyDAz77uIMfRuLa18CCixTwvRk9OVD48L1A+ DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+osLAz7q7vu61tSC/tb7uv80gsLDAuiDH /MXCt84gsbi8urXHvu4gwNa9wLTPtNkuPEJSPjxGT05UIA0KY29sb3I9IzAwODA4MD6h66Hr oeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hr oeuh66Hroeuh66HrPC9GT05UPjxCUj5tYWlsbWFuLWRldmVsb3BlcnO01CC+yLPnx8+8vL/k PyANCjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+wPrI8bTCIMD8 yK24piDAzL/rx9i8rSCwrbvnv80gMSA6IDEgt84gv9yxub7uIMfQvcDAuyDH0iC89iDA1rTC IDxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cub2xrLmNvLmtyIj6ixCBPbmxpbmUgS29yZWEg osUgPC9BPrbzsO0gx9W0z7TZLjxCUj65zLiuIMfjtvS53sH2IL7KsO0gxu3B9iC15bfBIA0K wcu828fVtM+02S4gus618CCzyrHXt6+/7L3FIL/rvK24pi4uLi4uLjwvRk9OVD48L1A+DQo8 UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+wPrI8SDIuLvnv6G8rbTCIL/csbm+7ii/tb7u LMDPvu4pv6EgsPy9ySDA1rTCILi5wLogutC16bKyILjFwM8ov/ktsd0pLCA8QlI+v7W+7sCv uNO/zSANCrv9yLC/oSDHyr/kx9EgyLjIrSDH0SC5rsDlvr/AuyC5q7fht84gurizuyC15biu sO0gwNa+7r/kLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+wKe/ zSCwsMC6ILO7v+vAxyC8rbrxvbq4piC53r7Gurix4iC/+MfPvcO46SCh7CA8QSANCmhyZWY9 Im1haWx0bzpvbGtAb2xrLmNvLmtyIj5vbGtAb2xrLmNvLmtyPC9BPiCh7bfOIDxCUj4iPEZP TlQgDQpjb2xvcj0jZmYwMDAwPnllczwvRk9OVD4itvO0wiCzu7/rwMcgtOTA5cC7IMHWvcOx 4iC52bb4tM+02S4gPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj6x 17iusO0sIMD6yPEgwPzIrSC/3LG5vu4gsK3Ax7ChILHDsd3Hz73FILrQtenAuyDAp8fYLCAx yLi/oSDH0cfYvK08QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3Lm9say5jby5rci9pbnN0aV9m cmFtZS5odG0iPqLCILmrt+EgvcO5/LCtwMcgosI8L0E+tbUgvce9w8fYILXluK6w7SDA1sC4 tM8gx9G5+CC16b7uuriw7SANCr3NwLi9w7jpIDxCUj7B9rHdIL3Fw7vH2CDB1ry8v+QuPC9G T05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj65q7fhIL3DufywrcDHIL3F w7sguea5/cC6IDxBIA0KaHJlZj0iaHR0cDovL3d3dy5vbGsuY28ua3IvaW5zdGlfZnJhbWUu aHRtIj6iuiDAzLD3IKK4IDwvQT7AuyDFrLivx8+9xSDIxCCwrcDHIL3Fw7u29b+hIA0KwNa0 wjxCUj69w7n8sK3AxyC9xcO7IMb7wLsgwNu8usfPvMW8rSC6uLO7IMHWvcO46SC1y7TPtNku PEJSPrmwt9AsIMD8yK0gPEZPTlQgY29sb3I9I2ZmMDAwMD4wMi01ODgtMDUxMCANCjwvRk9O VD7AuLfOtbUgvcXDu8fPvccgvPYgwNaxuL/kLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNl PbG8uLLDvCBzaXplPTI+vsa5q8LJt88gwMwgx9C9wLn9wMwgbWFpbG1hbi1kZXZlbG9wZXJz tNTAxyDIuMitIL3Ht8Igx+K787+hIMDbwLogurjFxsDMIDxCUj61x776wLi46SANCsfVtM+0 2S48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPm1haWxtYW4tZGV2 ZWxvcGVyc7TUsrK0wiBodHRwOi8vd3d3LmtyLmdudS5vcmcvZGlyZWN0b3J5L21haWxtYW4u aHRtbL+hIMDWtMIgwda80rimILq4sO0guN7AzyC15bfItMK1pb/kLDxCUj660sfKv+TH0SAN CsGkuri/tLTZuOkgwaS4uyDBy7zbx9W0z7TZLjxCUj6+1cC4t84gx+O29L74tMIguN7Az8C6 ILXluK7B9iC+yrW1t88gx8+w2r3AtM+02S48QlI+sde3sywgvsiz58j3IA0KsOi8vL/kLjwv Rk9OVD48L1A+DQo8L0JPRFk+DQo8L0hUTUw+DQo= From marc_news@valinux.com Tue May 15 02:05:12 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 14 May 2001 18:05:12 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15099.2244.184017.746400@anthem.wooz.org>; from barry@digicool.com on Thu, May 10, 2001 at 05:31:48PM -0400 References: <15094.52272.753043.181192@anthem.wooz.org> <20010509104304.J29713@magic.merlins.org> <20010510134257.Q31816@magic.merlins.org> <15099.2244.184017.746400@anthem.wooz.org> Message-ID: <20010514180512.B4194@moremagic.merlins.org> On Thu, May 10, 2001 at 05:31:48PM -0400, Barry A. Warsaw wrote: > If I get some time, I'll stare at the LockFile.py code again. Any > idea what process 8790 was? I wonder if it's the same code that's > not cleaning up after itself. Sorry for the late answer. I did look in the logfiles, but nothing showed up with pid 8790. Kinda weird... That said, we just got a list with 10,000+ users (nuked since then, see message sent after this one), and loading the admin page up took a while. My locks directory now has 35 desi-os-maps.lock.usw-sf-list1.pid files. Then again, it doesn't block the list, so it's not that bad 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@valinux.com Tue May 15 02:05:27 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 14 May 2001 18:05:27 -0700 Subject: [Mailman-Developers] Feature request Message-ID: <20010514180527.T1487@magic.merlins.org> Looking at it now, it's surprising that this hasn't happened sooner: SF's mailman was abused with someone creating a bogus project with a mailing list which was then used to subscribe about 10,000 people and then spam them into oblivion. The best/worst part is how people made it a lot worse by complaining to the list itself and spamming one another after that: http://www.geocrawler.com/lists/3/SourceForge/10386/0/ Anyway, I patched admin.py to just disallow admin web subscribes altogether. In order of preference, for a future mailman version, it'd be nice if mailman would: - Have a config.db entry: allow web subscribes, that can only be changed by the mailman owner (i.e. master password, not list password) - Easier: have a sitewide mm_cfg.py variable to allow/disallow web subscribes by the list admin Thanks, 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 Tue May 15 02:09:35 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 14 May 2001 18:09:35 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <20010514180512.B4194@moremagic.merlins.org> Message-ID: On 5/14/01 6:05 PM, "Marc MERLIN" wrote: > > Sorry for the late answer. > I did look in the logfiles, but nothing showed up with pid 8790. > Kinda weird... > > That said, we just got a list with 10,000+ users (nuked since then, see > message sent after this one), and loading the admin page up took a while. > My locks directory now has 35 desi-os-maps.lock.usw-sf-list1.pid files. That implies to me that your process has the list locked, and other people are trying to access it, finding it locked and exiting -- but leaving a lockfile dribble behind. From chuqui@plaidworks.com Tue May 15 04:32:17 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 14 May 2001 20:32:17 -0700 Subject: [Mailman-Developers] Feature request In-Reply-To: <20010514180527.T1487@magic.merlins.org> Message-ID: On 5/14/01 6:05 PM, "Marc MERLIN" wrote: > Looking at it now, it's surprising that this hasn't happened sooner: SF's > mailman was abused with someone creating a bogus project with a mailing list > which was then used to subscribe about 10,000 people and then spam them into > oblivion. It was going to happen sooner or later if you have people allowed to create stuff without adult supervision. This has been a continuing discussion in the list-managers area, because of the problem of places like yahoo groups that allow this kind of thing. Unfortunately, fi you have a large population, administratively babysitting them becomes really time intensive, so you have to find 'reasonable' tradeoffs here. > - Have a config.db entry: allow web subscribes, that can only be changed by > the mailman owner (i.e. master password, not list password) This is one of the basic realities -- either disabling or limiting the size of web imports until someone has been 'cleared' as a trusted admin. That would mean some form of vetting procedurel, which means a human body in place to make sure things are legit. Until that happens, web-loads are limited to small values (because, honestly, you don't want to bother with small groups -- at worst, the damage is minimal, and most likely, someone loading in 100 addresses isn't spamming, the larger the number, the less likely it's legit). Unfortunately, while we want to automate stuff, there are places where human bodies have to step in, and having the human body in place solves 90% of the problem, because the idiots won't bother trying -- unless they're really stupid or really arrogant. My idea is that permission is done on a per-admin basis. Once you've vetted a guy on one list, you don't want to have to manually re-vet them on their next list, and the next, and... And without it, you're limited to 150 subscribers via auto-loads of any sort, and to be vetted, you have to request permission, and you have to be findable through a verifiable, non-free e-mail address. That means even if the list is officially run from, say, fred@hotmail.com, you can't be vetted as admin from there -- there has to be a "real" address, not a throwaway one. And places like sourceforge get to define 'real' and "throwaway" as they see fit... From marc_news@valinux.com Tue May 15 04:48:40 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 14 May 2001 20:48:40 -0700 Subject: [Mailman-Developers] Feature request In-Reply-To: ; from chuqui@plaidworks.com on Mon, May 14, 2001 at 08:32:17PM -0700 References: <20010514180527.T1487@magic.merlins.org> Message-ID: <20010514204839.N15537@magic.merlins.org> On Mon, May 14, 2001 at 08:32:17PM -0700, Chuq Von Rospach wrote: > > Looking at it now, it's surprising that this hasn't happened sooner: SF's > > mailman was abused with someone creating a bogus project with a mailing list > > which was then used to subscribe about 10,000 people and then spam them into > > oblivion. > > It was going to happen sooner or later if you have people allowed to create > stuff without adult supervision. Turns out that it actually was a misguided user with a real project who apparently thought a lot of people should know about it. The problem remains though. BTW, there is adult supervision, SF does check and approve projects one per one, but there isn't much you can do about people who lie and set up a phony project that looks real. > > - Have a config.db entry: allow web subscribes, that can only be changed by > > the mailman owner (i.e. master password, not list password) > > This is one of the basic realities -- either disabling or limiting the size > of web imports until someone has been 'cleared' as a trusted admin. That > would mean some form of vetting procedurel, which means a human body in > place to make sure things are legit. Until that happens, web-loads are > limited to small values (because, honestly, you don't want to bother with > small groups -- at worst, the damage is minimal, and most likely, someone > loading in 100 addresses isn't spamming, the larger the number, the less > likely it's legit). Agreed. Note that it introduces the concept of an uber user who gets those admin check Emails and other things to confirm instead of the list admin. > My idea is that permission is done on a per-admin basis. Once you've vetted > a guy on one list, you don't want to have to manually re-vet them on their > next list, and the next, and... That could work for some, but doesn't help that much with a determined spammer who lies to get this access and then does the bad deed. That said, it'd still be a lot better than what we have now. I guess the best would be to have a config option that says what the max number of people who can be added through the web is (0 being a possibility) Having oversized adds go to a site admin for confirmation instead of just failing would be an added bonus. 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 Tue May 15 04:59:21 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 14 May 2001 20:59:21 -0700 Subject: [Mailman-Developers] Feature request In-Reply-To: <20010514204839.N15537@magic.merlins.org> Message-ID: On 5/14/01 8:48 PM, "Marc MERLIN" wrote: > Turns out that it actually was a misguided user with a real project who > apparently thought a lot of people should know about it. > The problem remains though. Zealots are zealots, whether it's their business, product, god or politics... (grin) > BTW, there is adult supervision, SF does check and approve projects one per > one, but there isn't much you can do about people who lie and set up a phony > project that looks real. True -- which puts you a step ahead of yahoogroups, but as you note, it's not all that difficult to fake it enough to look legit. It's really a difficult thing to solve -- especially if you can't "track back" a user past a disposable email address at hotmail or any of the other freebies. If you have a trackable address, you have a chance of having THEIR ISP break a kneecap for you, and at the least, you can ban the user (and if necessary) the ISP to limit future damages.... > Note that it introduces the concept of an uber user who gets those admin > check Emails and other things to confirm instead of the list admin. Well, I use the following concepts in my sites: O site mom: basically, god. O list mom: god for a list. O assistant list mom: does the stuff the list mom can pawn off on them. O content mom: handles mail that hits the admin page for some kind of hold, and monitors/administers the content of the list. You need a site mom to oversee everything and set policy (and vet/train/monitor/break kneecaps on list moms). List moms handle administrative stuff and have access to the subscribe pages; content moms don't -- each list tends to organize as it sees fit around those restrictions. Seems to work okay. It allows the list owner to hand off part or all of the list responsbility (at Apple, no list exists without an internal sponsor; that sponsor may or may not manage the list -- it might be someone in that group, or they may bonk an outside person to handle day to day operations). And responsibility flows upstairs, and memos flow back down.. (snicker) > That could work for some, but doesn't help that much with a determined > spammer who lies to get this access and then does the bad deed. But that's why you have to require a 'verifiable' address -- so if they do it, you have a chance of having an ISP be responsible for it, and if not, at least you can nuke that account and ISP from the 'verifiable' list so they can't pull it twice. > I guess the best would be to have a config option that says what the max > number of people who can be added through the web is (0 being a possibility) > > Having oversized adds go to a site admin for confirmation instead of just > failing would be an added bonus. Agreed and agreed -- it'd give the admin a chance to, say, pull a random subset to verify they'd agreed to this. If the list comes up clean, good. If not, you know you have a problem. From barry@digicool.com Wed May 16 20:04:24 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 16 May 2001 15:04:24 -0400 Subject: [Mailman-Developers] Virtual hosting Message-ID: <15106.53048.622149.841936@anthem.wooz.org> I've started to sketch out some requirements for improving the virtual hosting support for Mailman. It's not finished, but I'm soliciting comments anyway. Please see http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting and please add comments to the Wiki page. I'm not sure whether this stuff will make it into Mailman 2.1 or will have to be postponed. Cheers, -Barry From barry@digicool.com Wed May 16 20:10:05 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 16 May 2001 15:10:05 -0400 Subject: [Mailman-Developers] Feature request References: <20010514180527.T1487@magic.merlins.org> Message-ID: <15106.53389.341765.198492@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> My idea is that permission is done on a per-admin basis. Once CVR> you've vetted a guy on one list, you don't want to have to CVR> manually re-vet them on their next list, and the next, and... I think this is the right approach, but has the disadvantage of being unweildy until we've rearchitected the user database and authentication components. Which will not happen for MM2.1. -Barry From jj-list@mail.dk Thu May 17 00:49:54 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Thu, 17 May 2001 01:49:54 +0200 Subject: [Mailman-Developers] Moderator approval Message-ID: <5.1.0.14.0.20010517012616.04088a10@wheresmymailserver.com> I saw this on the Mailman 2.1 Wiki page: "Provide an email interface to all administrative commands" Does this include the approval of moderated messages? If so, has any work been done on this or do you know how it will work? Will it be (or is it already) possible to have the approval sent to more than one person? Thanks, Jesper. From barry@digicool.com Thu May 17 01:59:23 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 16 May 2001 20:59:23 -0400 Subject: [Mailman-Developers] Moderator approval References: <5.1.0.14.0.20010517012616.04088a10@wheresmymailserver.com> Message-ID: <15107.8811.880968.937449@anthem.wooz.org> >>>>> "JJ" == Jesper Jensen writes: JJ> I saw this on the Mailman 2.1 Wiki page: JJ> "Provide an email interface to all administrative commands" JJ> Does this include the approval of moderated messages? Yes, especially so! This is very high on my personal threshold of pain. :) JJ> If so, has any work been done on this or do you know how it JJ> will work? No work's been done on it yet. I'm not sure exactly how I'm going to do it, other than to probably hook into the new confirmation stuff already in CVS. The problem is that there are two outcomes: reject or approve. Which do you make easiest? (Probably reject since it's much more common.) Maybe there's auto-reject by default or timeout, with approvals being the easy path. Not sure yet. JJ> Will it be (or is it already) possible to have the approval JJ> sent to more than one person? I'm toying with the idea of adding a moderators' role, separate from and with fewer privs than the list owner. Even without that, such confirmations will be sent to the list owners, so yes. -Barry From tkikuchi@is.kochi-u.ac.jp Thu May 17 04:03:50 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu, 17 May 2001 12:03:50 +0900 Subject: [Mailman-Developers] How about Auto Discard Message-ID: <3B033F96.CF44CFB9@is.kochi-u.ac.jp> Hi! Developers, It is cumbersome to click 'Discard' on the admindb page each time a spam message come to the list address or at least every day basis. If we have an automatic discard function which will be ivoked by cron, we can just check the admin notice and do nothing. The held message will disappear two or three days later. Following script will do the job (I hope). Please review it and comment! Would it be better to define the expiration period in mm_cfg.py ? (I omitted the copyright/license notices) Regards, Tokio Kikuchi #!/usr/bin/env python # import sys import paths import time from Mailman import mm_cfg from Mailman import MailList from Mailman import Utils expire = 2 * 24 * 60 * 60 # 2 days now = time.time() def auto_discard(mlist): if not mlist.NumRequestsPending(): return heldmsgs = mlist.GetHeldMessageIds() total = len(heldmsgs) if total: for id in heldmsgs: info = mlist.GetRecord(id) ptime,sender,subject,reason,filename,msgdata = info if now - ptime > expire: print 'DISCARD',id, ptime, sender, subject mlist.HandleRequest(id, mm_cfg.DISCARD) mlist.Save() def main(): confined_to = sys.argv[1:] for listname in Utils.list_names(): if confined_to and listname not in confined_to: continue mlist = MailList.MailList(listname, lock=0) mlist.Lock() auto_discard(mlist) mlist.Unlock() if __name__ == '__main__': main() From wheakory@isu.edu Thu May 17 06:01:25 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Wed, 16 May 2001 23:01:25 -0600 Subject: [Mailman-Developers] Mailman error Bad Marshal Message-ID: <3B035B25.21C076A5@isu.edu> Received this for a hour and then it went away everything worked after that, but is there any solution to this problem. ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/wrapper mailowner ccaussec" (expanded from: ccaussec-admin) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/scripts/mailowner", line 33, in ? from Mailman import MailList ValueError: bad marshal data 554 "|/home/mailman/mail/wrapper mailowner ccaussec"... unknown mailer error 1 From Nigel.Metheringham@InTechnology.co.uk Thu May 17 09:41:07 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Thu, 17 May 2001 09:41:07 +0100 Subject: [Mailman-Developers] Moderator approval In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 16 May 2001 20:59:23 EDT." <15107.8811.880968.937449@anthem.wooz.org> Message-ID: barry@digicool.com said: > The problem is that there are two outcomes: reject or approve. Which > do you make easiest? (Probably reject since it's much more common.) Actually I approve the majority of stuff - since I run all my lists with member posting only, but people either post relevant stuff as non-members, or they have multiple email addresses and use the wrong one. I also discard a lot of items - however thats a peculiarity of how the list is set up in this case. If mail based moderation is available, then there needs to be an option to send more of the original message out with the notification of waiting mail - or a way of getting some header and body data back. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jcrey@uma.es Thu May 17 11:36:13 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Thu, 17 May 2001 12:36:13 +0200 Subject: [Mailman-Developers] Error in bin/config_list Message-ID: <3B03A99D.D9AC7C8@uma.es> I have received a message with the error description: Vizi Szilard > - I found an error: > [root@tatooin bin]# ./config_list -o /root/config test > Traceback (most recent call last): > File "./config_list", line 261, in ? > main() > File "./config_list", line 254, in main > do_output(listname, outfile) > File "./config_list", line 115, in do_output > info =3D config[k] > KeyError: altalanos = > = > altalanos means general in English. What is the problem? I have taken a glance to Mailman code and I have found: in MailList.py.GetConfigInfo: config_info['general'] =3D [_( "Fundamental list characteristics, including descriptive" " info and basic behaviors."), ('real_name', mm_cfg.String, 50, 0, _('The public name of this list (make case-changes only).'), and in config_list.do_output: config =3D mlist.GetConfigInfo() categories =3D (_('general'), _('privacy'), _('nondigest'), _('digest'), _('bounce'), _('archive'), _('gateway'), _('autoreply')) for k in categories: info =3D config[k] So 'k' must be untranslated, that's because that key does not exists in array 'config' -- = ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From barry@digicool.com Thu May 17 15:55:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 17 May 2001 10:55:35 -0400 Subject: [Mailman-Developers] Moderator approval References: <15107.8811.880968.937449@anthem.wooz.org> Message-ID: <15107.58983.480918.413334@anthem.wooz.org> >>>>> "NM" == Nigel Metheringham >>>>> writes: NM> If mail based moderation is available, then there needs to be NM> an option to send more of the original message out with the NM> notification of waiting mail - or a way of getting some header NM> and body data back. Oh absolutely! I think the right solution is to include the entire original message as an attachment (preferrably MIME, but there probably needs to be a non-MIME option). -Barry From barry@digicool.com Fri May 18 19:28:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 18 May 2001 14:28:40 -0400 Subject: [Mailman-Developers] Template file lookup Message-ID: <15109.27096.120852.101214@anthem.wooz.org> I'm about to change the search order for templates -- you know, those pesky .html and .txt files that live in $prefix/templates and $prefix/lists/$mylist. This change is necessary to properly support language templates, and also provides a much requested feature, namely that you will only need to specialize templates that you actually want to change, and that you have multiple levels of specialization. Here's how it works. There are 4 levels of template specialization: list-centric, vhost-centric, site-centric, and default, corresponding to the directories $prefix/lists/$listname $prefix/templates/$host_name $prefix/templates/site $prefix/templates Each of these locations is further organized by language subdirectories. So let's say you were looking for the listinfo.html template for list foobar in language es. You'd actually end up searching 12 directories, with of course, the first hit stopping the search. Let's say further that list foobar is in the www.foobar.com virtual domain, and that it's list-preferred language is fr, while the server's default language is en. Here's the files you'd search for: $prefix/lists/foobar/es/listinfo.html $prefix/templates/www.foobar.com/es/listinfo.html $prefix/templates/site/es/listinfo.html $prefix/templates/es/listinfo.html $prefix/lists/foobar/fr/listinfo.html $prefix/templates/www.foobar.com/fr/listinfo.html $prefix/templates/site/fr/listinfo.html $prefix/templates/fr/listinfo.html $prefix/lists/foobar/en/listinfo.html $prefix/templates/www.foobar.com/en/listinfo.html $prefix/templates/site/en/listinfo.html $prefix/templates/en/listinfo.html Note that the Mailman 2.0.x search directories of $prefix/lists/*.{html,txt} and $prefix/templates/*.{html,txt} are deprecated and no longer searched. The bin/upgrade script will actually md5 checksum all the old files and remove any templates in more-specific locations that exactly match their more-general counterparts. Any template in $prefix/lists or $templates will have to be moved manually. It is highly discouraged that you will ever manually edit a file in $prefix/templates/$lang, and Mailman's install target will have every right to overwrite them on an upgrade. That's what the templates/site subdirectory is for; upgrading will never touch site-centric, domain-centric, or list-centric templates. Of course, that means it's up to site administrators to merge in changes to the default templates. Watch for checkins shortly. Comments? -Barry From scott-brown@home.com Fri May 18 21:39:11 2001 From: scott-brown@home.com (Scott Brown) Date: Fri, 18 May 2001 16:39:11 -0400 Subject: [Mailman-Developers] Template file lookup In-Reply-To: <15109.27096.120852.101214@anthem.wooz.org> Message-ID: <007201c0dfda$991aaa20$0401a8c0@ibmpeers> [majority removed] > It is highly discouraged that you will ever manually edit a file in > $prefix/templates/$lang, and Mailman's install target will have every > right to overwrite them on an upgrade. That's what the templates/site > subdirectory is for; upgrading will never touch site-centric, > domain-centric, or list-centric templates. Of course, that means it's > up to site administrators to merge in changes to the default > templates. > > Watch for checkins shortly. > > Comments? Dont know if you read my comments on the wikki, but as a small (very small :) hosting co owner, I'd like to see some way of maintaining virt domain specific information within the virt domain directory tree... something like: $prefix = master mailman install directory $virtprefix = site specific data file directory (eg /home/somedomain.com/mailman) $virtprefix/lists/{lang}/listinfo.html $virtprefix/templates/{lang}/listinfo.html $prefix/templates/site/{lang}/listinfo.html $prefix/templates/{lang}/listinfo.html Plaster appropriate protection to keep people meddling with them - but dont hide them off somewhere else on the disk - keep them with the virtual domain itself. Gives two benefits (that I see): 1 - all the files associated with that domain are hung under one tree - making backup/restore of individual domains simpler. 2 - those host co's using soft quotas dont have to scour the disk looking for files that should be applied against each virt domain. Could be more - but my mind is elsewhere right now. From bakyh@etri.re.kr Sat May 19 06:32:13 2001 From: bakyh@etri.re.kr (bakyh@etri.re.kr) Date: Sat, 19 May 2001 14:32:13 +0900 Subject: [Mailman-Developers] =?euc-kr?B?W8D8w7zIuL3FXSBbTWFpbG1hbi1pMThuXSBjYW4ndCBkZWNvZGUg?= =?euc-kr?B?aW4gd2ViIHVzaW5nIG1haWxtYW4u?= Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A1BFD1F@cms3.etri.re.kr> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E025.0ED6E4F0 Content-Type: text/plain; charset="euc-kr" I'm a korean. I installed a mailman to Linux 2.2.18. I succeed in sending and receiving msg, but in web failed. In web, I can't read msg in Korean. How can I do it? I think, its reason is that in web browser can't decoding that msg. Shoud I patch about it? What is the patch program and where I can get it? Please, help me. Bak, Yuhyeon. ------_=_NextPart_001_01C0E025.0ED6E4F0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] [Mailman-i18n] can't decode in web = using mailman.

          I'm a korean.

          I installed a mailman to Linux 2.2.18.

          I succeed in sending and receiving msg, but in web = failed.

          In web, I can't read msg in Korean.

          How can I do it?

          I think, its reason is that in web browser can't = decoding that msg.

          Shoud I patch about it?

          What is the patch program and where I can get = it?
           

          Please, help me.

           

          Bak, Yuhyeon.

           

          ------_=_NextPart_001_01C0E025.0ED6E4F0-- From tkikuchi@is.kochi-u.ac.jp Sat May 19 15:10:06 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 19 May 2001 23:10:06 +0900 Subject: [Mailman-Developers] Re: [Mailman-i18n] can't decode in web using mailman. References: <766FA1FC5C2AD511B3C800D0B7A8AC4A1BFD1F@cms3.etri.re.kr> Message-ID: <3B067EBE.D6E830EC@is.kochi-u.ac.jp> > bakyh@etri.re.kr wrote: > > I'm a korean. > > I installed a mailman to Linux 2.2.18. > > I succeed in sending and receiving msg, but in web failed. > > In web, I can't read msg in Korean. Hi, I am a japanese. What is the default charset for Korean language. If the charset is other than EUC-KR, then the double-byte code may contain special characters like <,>,&. Japanese mail message is encoded with ISO-2022-JP while the Web pages and internal language data are best treated in EUC-JP. I made short scripts to convert the messages between ISO-2022-JP and EUC-JP and put them in Mailman/Handlers. You may want to browse the scripts, to_euc.py and to_jis.py, which are included in Japanese Mailman at http://mm.tkikuchi.net/mailman-2.0.5+J1.20010514.tar.gz Please check Mailman/Handlers/HandlerAPI.py how to invoke them. Regards, Tokio Kikuchi From jeb@ocha.net Sun May 20 06:36:27 2001 From: jeb@ocha.net (Jeb Bateman) Date: Sat, 19 May 2001 22:36:27 -0700 Subject: [Mailman-Developers] Template file lookup In-Reply-To: <15109.27096.120852.101214@anthem.wooz.org>; from barry@digicool.com on Fri, May 18, 2001 at 02:28:40PM -0400 References: <15109.27096.120852.101214@anthem.wooz.org> Message-ID: <20010519223627.A3526@ocha.net> On Fri, May 18, 2001 at 02:28:40PM -0400, Barry A. Warsaw wrote: > ...and also provides a much requested feature, namely that you will > only need to specialize templates that you actually want to change, > and that you have multiple levels of specialization. > > Here's how it works. > > There are 4 levels of template specialization: list-centric, > vhost-centric, site-centric, and default, corresponding to the > directories > > $prefix/lists/$listname > $prefix/templates/$host_name > $prefix/templates/site > $prefix/templates This is great, I think, since I've hacked the copy of Mailman I'm using similarly to the patch on sourceforge to enable list-specific templates, (but it was a fragile fix at best without mlist being passed to the template merge function). Anyway, I'm glad to see this is being done right, although I seem to remember seeing a comment by someone recently about the 2.1 alpha Mailman assuming that every directory under $prefix/lists/$listname being a language directory for templates, which caused problems with something, and I remember thinking there might be other reasons I'd want more directories for other purposes under a list directory. So, I'd suggest moving all list templates into a 'templates' subdirectory of the list. Ie, the first search is: $prefix/lists/$listname/templates/ This would keep the list directory uncluttered, and also eliminate code ambiguity about putting other directories under the list dir. Also, one other feature I've been thinking about is to make the web interface for editing templates include a pop-up menu of all templates that affect a list, (searching up the hierarchy for each). Then, when the admin chooses to edit one, it is saved in the $listname/templates directory. Therefore, there is no need to install the current 4 list specific templates in the list templates directory to begin with, and list admins are free to modify any templates affecting their list. Hoping that made sense, -jeb -- Jeb Bateman BuyOrganic.org project - http://buyorganic.org From claw@kanga.nu Sun May 20 19:09:36 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 20 May 2001 11:09:36 -0700 Subject: [Mailman-Developers] OT -- Webmail IMAP clients Message-ID: <15489.990382176@kanga.nu> Forget who asked about this recently. At the time I recommended Twig (its what I use). I'm currently evaluating SilkyMail: http://www.cyrusoft.com/silkymail/ If you don't need the groupware features of Twig (I don't) SilkyMail makes a compelling argument. The basic user interface if quite a bit sweeter than Twig's. And yes, its GPL. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From listmgr@perilpoint.com Sun May 20 20:19:51 2001 From: listmgr@perilpoint.com (Bradford Shaw) Date: Sun, 20 May 2001 14:19:51 -0500 Subject: [Mailman-Developers] disabling feature question Message-ID: <4.2.0.58.20010520135739.00b16bd0@perilpoint.com> Hello everyone, I am new to this list. I am the Mailing List Administrator for our company. I am impressed with the quality of the Mailman program and look forward to running the program. We just installed it for our list hosting (mainly to replace Majordomo to give our customers a web-based program for their lists). I have a question that I am not able to find answers for in the archives and am hoping that you can direct me to where I can find the answer. Simply, we need to remove the "Edit the HTML for the public list pages" under the 'Other Administrative Activities' on the General Options page. Our take on this is that once we have the list set up for our customer, we don't want them messing with the html. First, because we want our logo to stay on the list pages and, second, because many of our customers are not proficient in html and a minor slip could render the output unreadable. So can you direct me to where I can get this item removed? Well, I said a couple questions but I'll hold off on the others. I need an answer to the above question right away as I am not comfortable going public with this until I can disable that feature. I appreciate your help and I hope that I can reciprocate in the near future. Best wishes, Bradford "Biff" Shaw List Administrator PerilPoint Communications Inc. http://www.perilpoint.com From barry@digicool.com Mon May 21 03:27:55 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 20 May 2001 22:27:55 -0400 Subject: [Mailman-Developers] disabling feature question References: <4.2.0.58.20010520135739.00b16bd0@perilpoint.com> Message-ID: <15112.32043.665844.64294@anthem.wooz.org> >>>>> "BS" == Bradford Shaw writes: BS> Simply, we need to remove the "Edit the HTML for the public BS> list pages" under the 'Other Administrative Activities' on the BS> General Options page. You'll need to hack the source, but it shouldn't be too hard. Assuming you're using Mailman 2.0.5, look in the Mailman/Cgi/admin.py file, 'round about line 286. See where it says: otherlinks.AddItem(Link(mlist.GetScriptURL('edithtml'), 'Edit the HTML for the public list pages')) Comment out those two lines (put `#' at the beginning of each line). For added safety, remove the $prefix/cgi-bin/edithtml binary -- where $prefix is the install directory -- and remove `edithtml' from the CGI_PROGS variable in src/Makefile.in. -Barry From claw@kanga.nu Mon May 21 04:18:22 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 20 May 2001 20:18:22 -0700 Subject: [Mailman-Developers] Trivial stats on Postfix Message-ID: <2656.990415102@kanga.nu> I just did a very quick check: 1 message delivered to a list with 1,000 members Distribution list is pretty atypical (very low AOL, MSN, Hotmail etc counts). Its a tehcnical/professional audience. The largest number of members in the distribution list all at the same domain is AOL with 27. Average number of members per domain is 2.6. MAX_RCPT_TO is set to 5. MTA is postfix with a very close to default config (no DNS check tho) Local cacheing nameserver via DJBDNS Nameserver is pre-stuffed with records for distribution list (previous list activity). Postfix spool was compleatly empty prior to run. Machine in question is a dual PII-333 with 512Meg RAM. Spool is on the same spindle as /var/log, and is under ResierFS Postfix is logging through syslog to localhost. Postfix is configured for 10 parallel deliveries to responsive MXes. Host OS is Debian/Testing. Total time required to hand off the message (200 spool entries) and deliver the spool down to the point of only slow MX'es left: 53 seconds (might be a bit faster, my stopwatch finger was lazy). Total number of spool entries left after 53 seconds: 16/16 targets Total number of spool entries after two minutes: 14/14/targets Total number of spool entries after 10 minutes: 14/14/targets Translation: Every slow spool entry has only one RCPT TO and the slow MXes really are slow. Outbound bandwith is via 100bT to a couple T3s and a T1. Relatively meaningless numbers given the artificiality of the conditions the extremely light load, and the rather unexamined distribution pattern of the membership base, but kinda interesting none the less. Surprised me too. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From jcrey@uma.es Tue May 22 08:02:37 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Tue, 22 May 2001 09:02:37 +0200 Subject: [Mailman-Developers] Mailman install from CVS bug Message-ID: <3B0A0F0D.83AE18EF@uma.es> I have been experiencing a bug when I have tried to install mailman from CVS: When I execute './configure': [snip] creating Mailman/Queue/Makefile creating Mailman/MTA/Makefile sed: can't read ./Mailman/MTA/Makefile.in: No such file or directory creating templates/Makefile creating cron/Makefile creating filters/Makefile creating scripts/Makefile creating messages/Makefile sed: can't read ./messages/Makefile.in: No such file or directory creating cron/crontab.in creating Makefile and then when I execute 'make install' [snip] make[2]: Entering directory `/tmp/mailman/Mailman/MTA' make[2]: *** No rule to make target `install'. Stop. make[2]: Leaving directory `/tmp/mailman/Mailman/MTA' make[1]: *** [install] Error 2 make[1]: Leaving directory `/tmp/mailman/Mailman' [snip] I have noticed this for some weeks but I have not paid much attention. Has anybody experienced this too? Cheers --=20 ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From barry@digicool.com Tue May 22 20:20:11 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 22 May 2001 15:20:11 -0400 Subject: [Mailman-Developers] Mailman install from CVS bug References: <3B0A0F0D.83AE18EF@uma.es> Message-ID: <15114.48107.967199.915315@anthem.wooz.org> >>>>> "JCRA" == Juan Carlos Rey Anaya writes: JCRA> I have been experiencing a bug when I have tried to install JCRA> mailman from CVS: Be sure you do a "cvs update -P -d" to create any new directories that have shown up since your last cvs update! I just tried a fresh update, configure, and install and it works for me, modulo the following: VS> I am managing the Hungarian translation. VS> I have downloaded the current CVS and I found some problems: Cool. I've currently got Hungarian templates checked into CVS but not a message catalog. The templates may be out of date too, and I'd love to get updates for both (actually for any and all languages). VS> Creating language directory VS> /home/mailman/messages/rot/LC_MESSAGES mkdir VS> /home/mailman/messages/rot mkdir VS> /home/mailman/messages/rot/LC_MESSAGES /usr/bin/install: VS> rot/LC_MESSAGES/mailman.po: No such file or directory VS> /usr/bin/install: rot/LC_MESSAGES/mailman.mo: No such file or VS> directory make[1]: *** [doinstall] Error 1 make[1]: Leaving VS> directory `/root/mailman/messages' make: *** [doinstall] Error VS> 2 I don't get that, so the "cvs up -P -d" suggestion above should fix that. But now that we've got the start of some real languages, I think I'll delete the toy "rot" translations. VS> After the installation every 4 minutes through cron, and every VS> commandline programs get the user this message: | root@tatooin mailman]# bin/check_perms | Traceback (most recent call last): | File "bin/check_perms", line 328, in ? | checkmta() | File "bin/check_perms", line 265, in checkmta | __import__(modname) | ImportError: No module named Sendmail VS> I am using Sendmail with Mandrake 8. This is actually caused by the default value for the MTA variable in Defaults.py.in. I haven't created a Mailman/MTA/Sendmail.py module yet. I'll work on fixing that up. VS> And finally it the attachment is the notifing error message VS> for the http://servername/mailman/listinfo/ You still need to download and install mimelib 0.3 separately to use CVS. See http://sf.net/projects/mimelib for details. -Barry From neel@mediapulse.com Wed May 23 17:19:14 2001 From: neel@mediapulse.com (Michael Neel) Date: Wed, 23 May 2001 12:19:14 -0400 Subject: [Mailman-Developers] Post of white paper Message-ID: <7C0860C7F381C64DA185F431FE57C42A16AF50@JOHNSON.mediapulse.net> Hi all, I'm new to the mailman project and have email Barry briefly on some ideas I have for 3.0 mailman. I've added a white paper under MailmanThreePointOh on the zope site for your feedback. I look forward to working with you all! Mike -- Michael C. Neel Senior Programmer/Analyst Mediapulse, Inc. The Pulse of Your eBusiness Phn: 865.482.4455 x30 Fax: 4465 From jcrey@uma.es Fri May 25 12:43:48 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Fri, 25 May 2001 13:43:48 +0200 Subject: [Mailman-Developers] CVS access problem Message-ID: <3B0E4574.D5F4F7D1@uma.es> Has anybody noted anything strange accesing CVS? [jcrey@joker mailman]$ cvs -d:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman login CVS password:=20 cvs login: authorization failed: server cvs.mailman.sourceforge.net rejected access :-( --=20 ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From proski@gnu.org Fri May 25 16:40:58 2001 From: proski@gnu.org (Pavel Roskin) Date: Fri, 25 May 2001 11:40:58 -0400 (EDT) Subject: [Mailman-Developers] Feature request: regexp for posters Message-ID: Hello! I'm administering two mailing lists (mc@gnome.org and mc-devel@gnome.org) running Mailman 2.0.5. In order to stop spam, the messages from non-members are held for approval. Unfortunately, sometimes a message gets crossposted to a another list on a different site. Then we have a wave of posts from non-members. I want to accept messages from certain domains without approval. While including the mailing list domain (gnome.org) would be risky (some spammers use the victim's address in From:), other domains should be safe. I would like to be able to use regular expressions in the "poster" list, for example: .*@suse.com .*@ximian.com .*@.*mit.edu and so on. From what I see in the sources of Mailman 2.0.5, regular expressions are not used when the address is matched against the poster list. Would it be possible to use regular expressions in the future versions of Mailman? -- Regards, Pavel Roskin From barry@digicool.com Fri May 25 16:59:10 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 25 May 2001 11:59:10 -0400 Subject: [Mailman-Developers] CVS access problem References: <3B0E4574.D5F4F7D1@uma.es> Message-ID: <15118.33102.894461.107058@anthem.wooz.org> I've just logged a service request with SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=427310&group_id=1&atid=200001 but it looks like other projects are getting bit by the same bug, and it looks like it started breaking some time earlier today. -Barry From barry@digicool.com Fri May 25 17:37:53 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 25 May 2001 12:37:53 -0400 Subject: [Mailman-Developers] forwarded message from noreply@sourceforge.net Message-ID: <15118.35425.965431.437451@anthem.wooz.org> --djIzDHacbw Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Looks like it might be a while... -Barry --djIzDHacbw Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Return-Path: Delivered-To: barry@wooz.org Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253]) by mail.wooz.org (Postfix) with ESMTP id CD743D38E0 for ; Fri, 25 May 2001 12:26:54 -0400 (EDT) Received: from usw-sf-web1-b.sourceforge.net ([10.3.1.5] helo=usw-sf-web1.sourceforge.net) by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 153KQR-0006fF-00; Fri, 25 May 2001 09:26:55 -0700 Received: from nobody by usw-sf-web1.sourceforge.net with local (Exim 3.22 #1 (Debian)) id 153KQR-0001Ga-00; Fri, 25 May 2001 09:26:55 -0700 Message-Id: From: noreply@sourceforge.net Sender: nobody To: noreply@sourceforge.net Subject: [ alexandria-Support Requests-427310 ] CVS services issue: anonymous pserver fails: mailman Date: Fri, 25 May 2001 09:26:55 -0700 Support Requests item #427310, was updated on 2001-05-25 08:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200001&aid=427310&group_id=1 Category: CVS >Group: Second Level Support Status: Open >Priority: 3 Submitted By: Barry Warsaw (bwarsaw) >Assigned to: Jacob Moorman (moorman) >Summary: CVS services issue: anonymous pserver fails: mailman Initial Comment: Anonymous cvs pserver login is broken for the mailman project: % cvs -d:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman login CVS password: cvs login: authorization failed: server cvs.mailman.sourceforge.net rejected access ---------------------------------------------------------------------- >Comment By: Jacob Moorman (moorman) Date: 2001-05-25 09:26 Message: Logged In: YES user_id=152443 Greetings, At this time, I am unable to process your request due to the pending maintenance event related to SourceForge systems (as mentioned on the site status page). Once this maintenance event has been completed, your support request will be processed in the following 48-72 hours. Please let me know if I may be of further assistance in this matter. Thank you, Jacob Moorman Quality of Service Manager, SourceForge ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200001&aid=427310&group_id=1 --djIzDHacbw-- From chuqui@plaidworks.com Fri May 25 18:18:16 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 25 May 2001 10:18:16 -0700 Subject: [Mailman-Developers] site-wide list configuration... Message-ID: <200105251716.f4PHGaq17092@lists.apple.com> Just as a bit of an FYI -- I've mentioned in the past that I'd like the ability to "lock down" certain list configuration options based on site-wide standard. Having this feature has become more interesting to me, since I just has a 'situation' where it would have been really useful. I had a list admin decide he wanted to change reply-to to the list. This, despite being told not to change things. So he did. And it got involved in a situation where stuff was posted to the list (by me, in fact) that shouldn't have been because the list was configured different than everything else on the system. And that led to the "why can't we have this?" fight, and it led to a private argument with the list admin (who actually changed it twice), and all sorts of unhappiness. And one of his arguments, of course, was "if you don't want this changed, why do the pages let me"? Don't worry, my hair will grow back. Well, maybe. But take this as a real-world case where splitting out content admin from list admin from site admin and allowing the folks higher up in the hierarchy to delegate or freeze what sub-admins can do. Because while it's nice to think everyone will play nice and follow instructions, in the real world, it doesn't always happen. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. It's a thankless job, but I've got a lot of Karma to burn off. From kevinc@seaplace.org Sat May 26 19:27:33 2001 From: kevinc@seaplace.org (Kevin N. Carpenter) Date: Sat, 26 May 2001 13:27:33 -0500 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: Barry - I just got lost trying to find the patches. Is there a nice, straight-forward, FTP site I can pull patch 1-5 from? Thanks, Kevin C. -----Original Message----- From: mailman-announce-admin@python.org [mailto:mailman-announce-admin@python.org]On Behalf Of Barry A. Warsaw Sent: Monday, May 07, 2001 11:24 AM To: mailman-announce@python.org Cc: mailman-developers@python.org Subject: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 Folks, I've just released Mailman 2.0.5 which fixes a problem with stale lock files that can occur under certain situations when the user hits the `Stop' button on their browser. These stale lock files can cause mailing lists to be inaccessible for long periods of time (until the stale lock file times out or is manually removed). As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.4. You /must/ update your source to 2.0.4 before applying the 2.0.5 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.5 source tree and apply it like so: % patch -p0 < mailman-2.0.4-2.0.5.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net My thanks to those of you who gave the 2.0.5 pre-release a try! Enjoy, -Barry Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.5 retrieving revision 1.25.2.6 diff -u -r1.25.2.5 -r1.25.2.6 --- NEWS 2001/04/18 10:45:54 1.25.2.5 +++ NEWS 2001/05/03 21:06:56 1.25.2.6 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.5 (04-May-2001) + + Fix a lock stagnation problem that can result when the user hits + the `stop' button on their browser during a write operation that + can take a long time (e.g. hitting the membership management admin + page). + 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.4 retrieving revision 1.20.2.5 diff -u -r1.20.2.4 -r1.20.2.5 --- Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 +++ Mailman/Version.py 2001/05/03 20:58:19 1.20.2.5 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.4" +VERSION = "2.0.5" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 4 +MICRO_REV = 5 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.82.2.2 retrieving revision 1.82.2.3 diff -u -r1.82.2.2 -r1.82.2.3 --- Mailman/Cgi/admin.py 2001/01/03 16:47:47 1.82.2.2 +++ Mailman/Cgi/admin.py 2001/05/03 21:03:48 1.82.2.3 @@ -18,11 +18,13 @@ """ +import sys import os import cgi import string import types import rfc822 +import signal from Mailman import Utils from Mailman import MailList @@ -63,53 +65,86 @@ # get the list object listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: FormatAdminOverview('No such list %s' % listname) syslog('error', 'Someone tried to access the admin interface for a ' 'non-existent list: %s' % listname) return + + if len(parts) == 1: + category = 'general' + category_suffix = '' + else: + category = parts[1] + category_suffix = category + + # If the user is not authenticated, we're done. + cgidata = cgi.FieldStorage(keep_blank_values=1) try: - if len(parts) == 1: - category = 'general' - category_suffix = '' - else: - category = parts[1] - category_suffix = category - - # If the user is not authenticated, we're done. - cgidata = cgi.FieldStorage(keep_blank_values=1) - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admin', e.message) - return - - # Is this a log-out request? - if category == 'logout': - print mlist.ZapCookie('admin') - Auth.loginpage(mlist, 'admin', frontpage=1) - return - - if category not in map(lambda x: x[0], CATEGORIES): - category = 'general' - - # is the request for variable details? - varhelp = None - if cgidata.has_key('VARHELP'): - varhelp = cgidata['VARHELP'].value - elif cgidata.has_key('request_login') and \ - os.environ.get('QUERY_STRING'): - # POST methods, even if their actions have a query string, don't - # get put into FieldStorage's keys :-( - qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') - if qs and type(qs) == types.ListType: - varhelp = qs[0] - if varhelp: - FormatOptionHelp(doc, varhelp, mlist) - print doc.Format(bgcolor="#ffffff") - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admin', e.message) + return + + # Is this a log-out request? + if category == 'logout': + print mlist.ZapCookie('admin') + Auth.loginpage(mlist, 'admin', frontpage=1) + return + + if category not in map(lambda x: x[0], CATEGORIES): + category = 'general' + # is the request for variable details? + varhelp = None + if cgidata.has_key('VARHELP'): + varhelp = cgidata['VARHELP'].value + elif cgidata.has_key('request_login') and \ + os.environ.get('QUERY_STRING'): + # POST methods, even if their actions have a query string, don't + # get put into FieldStorage's keys :-( + qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') + if qs and type(qs) == types.ListType: + varhelp = qs[0] + if varhelp: + FormatOptionHelp(doc, varhelp, mlist) + print doc.Format(bgcolor="#ffffff") + return + + # From this point on, the MailList object must be locked. However, we + # must release the lock no matter how we exit. try/finally isn't + # enough, because of this scenario: user hits the admin page which may + # take a long time to render; user gets bored and hits the browser's + # STOP button; browser shuts down socket; server tries to write to + # broken socket and gets a SIGPIPE. Under Apache 1.3/mod_cgi, Apache + # catches this SIGPIPE (I presume it is buffering output from the cgi + # script), then turns around and SIGTERMs the cgi process. Apache + # waits three seconds and then SIGKILLs the cgi process. We /must/ + # catch the SIGTERM and do the most reasonable thing we can in as + # short a time period as possible. If we get the SIGKILL we're + # screwed (because its uncatchable and we'll have no opportunity to + # clean up after ourselves). + # + # This signal handler catches the SIGTERM and unlocks the list. The + # effect of this is that the changes made to the MailList object will + # be aborted, which seems like the only sensible semantics. + # + # BAW: This may not be portable to other web servers or cgi execution + # models. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + if cgidata.has_key('bounce_matching_headers'): pairs = mlist.parse_matching_header_opt() @@ -135,8 +170,12 @@ FormatConfiguration(doc, mlist, category, category_suffix, cgidata) print doc.Format(bgcolor="#ffffff") - finally: mlist.Save() + finally: + # Now be sure to unlock the list. It's okay if we get a signal here + # because essentially, the signal handler will do the same thing. And + # unlocking is unconditional, so it's not an error if we unlock while + # we're already unlocked. mlist.Unlock() Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.36.2.1 retrieving revision 1.36.2.4 diff -u -r1.36.2.1 -r1.36.2.4 --- Mailman/Cgi/admindb.py 2001/03/03 06:02:01 1.36.2.1 +++ Mailman/Cgi/admindb.py 2001/05/04 15:54:23 1.36.2.4 @@ -16,10 +16,12 @@ """Produce and process the pending-approval items for a list.""" +import sys import os import string import types import cgi +import signal from errno import ENOENT from Mailman import mm_cfg @@ -62,7 +64,7 @@ return # now that we have the list name, create the list object try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: handle_no_list(doc, 'No such list %s

          ' % listname) syslog('error', 'No such list "%s": %s\n' % (listname, e)) @@ -71,14 +73,34 @@ # now we must authorize the user to view this page, and if they are, to # handle both the printing of the current outstanding requests, and the # selected actions + cgidata = cgi.FieldStorage() try: - cgidata = cgi.FieldStorage() - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admindb', e.message) - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admindb', e.message) + return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + # If this is a form submission, then we'll process the requests and # print the results. otherwise (there are no keys in the form), we'll # print out the list of pending requests @@ -91,8 +113,8 @@ PrintRequests(mlist, doc) text = doc.Format(bgcolor="#ffffff") print text - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/handle_opts.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/handle_opts.py,v retrieving revision 1.30 retrieving revision 1.30.2.2 diff -u -r1.30 -r1.30.2.2 --- Mailman/Cgi/handle_opts.py 2000/11/09 16:19:03 1.30 +++ Mailman/Cgi/handle_opts.py 2001/05/03 21:05:06 1.30.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import mm_cfg from Mailman import Utils @@ -61,7 +62,7 @@ user = parts[1] try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) @@ -69,10 +70,30 @@ syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, user, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/subscribe.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v retrieving revision 1.29 retrieving revision 1.29.2.1 diff -u -r1.29 -r1.29.2.1 --- Mailman/Cgi/subscribe.py 2000/09/29 00:05:05 1.29 +++ Mailman/Cgi/subscribe.py 2001/05/03 21:05:43 1.29.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import Utils from Mailman import MailList @@ -41,18 +42,38 @@ listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) - mlist.IsListInitialized() + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) print doc.Format(bgcolor="#ffffff") syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.5 retrieving revision 1.5.2.6 diff -u -r1.5.2.5 -r1.5.2.6 --- admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 +++ admin/www/download.ht 2001/05/03 21:09:36 1.5.2.6 @@ -65,9 +65,9 @@

          Downloading

          Version -(2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:

            Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.7 retrieving revision 1.6.2.8 diff -u -r1.6.2.7 -r1.6.2.8 --- admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 +++ admin/www/download.html 2001/05/03 21:09:36 1.6.2.8 @@ -1,6 +1,6 @@ - + 2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:
              _______________________________________________ Mailman-announce mailing list Mailman-announce@python.org http://mail.python.org/mailman/listinfo/mailman-announce From barry@digicool.com Sat May 26 23:09:02 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sat, 26 May 2001 18:09:02 -0400 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 References: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <15120.10622.799984.961066@anthem.wooz.org> >>>>> "KNC" == Kevin N Carpenter writes: KNC> I just got lost trying to find the patches. Is there a nice, KNC> straight-forward, FTP site I can pull patch 1-5 from? SourceForge should have them, but you can also try ftp.gnu.org, probably in the gnu/mailman subdirectory. -Barry From a.nestico@sonetlumiere.it Tue May 29 19:47:48 2001 From: a.nestico@sonetlumiere.it (Angela) Date: Tue, 29 May 2001 11:47:48 -0700 Subject: [Mailman-Developers] cookie Message-ID: <000801c0e86f$dbe425f0$7a08090a@WINANGELA> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0E835.2F0FA8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want create an application where a user called a cookie, someone know = where I can find more information how to create a cookie Thank you Angela Nestic=F2 ------=_NextPart_000_0005_01C0E835.2F0FA8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
              I want create an application where a = user called a=20 cookie, someone know where I can find more information how to create a=20 cookie
              Thank you Angela = Nestic=F2
              ------=_NextPart_000_0005_01C0E835.2F0FA8C0-- From thomas@xs4all.net Tue May 29 13:45:07 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 29 May 2001 14:45:07 +0200 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 In-Reply-To: ; from twouters@users.sourceforge.net on Tue, May 29, 2001 at 05:06:49AM -0700 References: Message-ID: <20010529144507.T690@xs4all.nl> On Tue, May 29, 2001 at 05:06:49AM -0700, Thomas Wouters wrote: > Re-BSDify the Makefiles, by not expecting make to expand '{eggs,ham}' in > globs. (BSD 'make' does not, GNU make does.) I'm sure there is a more > satisfying way to do this, but in this case, with only two alternatives in > only two cases, just writing them out was the way of least resistance. Ugh. I now see that there are a lot more things BSD make barfs over: GNU make: mailman/messages$ gmake es/LC_MESSAGES/mailman.mo [ pygettext and other stuff snipped ] Generating binary catalog msgfmt -o es/LC_MESSAGES/mailman.mo es/LC_MESSAGES/mailman.po BSD make: mailman/messages$ make es/LC_MESSAGES/mailman.mo msgfmt -o es/LC_MESSAGES/mailman.po es/LC_MESSAGES/mailman.mo es/LC_MESSAGES/mailman.mo:1: parse error es/LC_MESSAGES/mailman.mo:2: keyword "e" unknown es/LC_MESSAGES/mailman.mo:4: keyword "W" unknown Apparently, GNU make and BSD make switch the meaning of $@ and $< in: msgfmt -o $@ $< And there's more, there, too. As usual for Makefile/make bugs, they're hard to reproduce, depending as they are on the timestamps of seemingly totally irrelevant files :) I think it's safe to say that BSD make doesn't grok the '%/LC_MESSAGES/*' construct, though. I don't have a good GNU/BSD make resource at hand to help me through the differences; if anyone sees such a resource online, please let me know ;) In the mean time, Barry, if this isn't fixed before an almost-real release, we'll either have to ship .po files, or insist on GNU make (which is available almost everywhere, even on BSD systems, though usually as 'gmake' there.) The installation procedure works with BSD make now that I regenerated the .po files with GNU make. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jarrell@vt.edu Tue May 29 19:24:15 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 29 May 2001 14:24:15 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 In-Reply-To: <20010529144507.T690@xs4all.nl> References: Message-ID: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> At 02:45 PM 5/29/01 +0200, Thomas wrote: >resource at hand to help me through the differences; if anyone sees such a >resource online, please let me know ;) In the mean time, Barry, if this >isn't fixed before an almost-real release, we'll either have to ship .po >files, or insist on GNU make (which is available almost everywhere, even on >BSD systems, though usually as 'gmake' there.) The installation procedure >works with BSD make now that I regenerated the .po files with GNU make. Unless it's absolutely impossible to do otherwise, I always recommend going with the least common denominator make. Each extra piece you require before someone can run mailman reduces the number of people willing to bother. And I think the "Whatinhell? It can't run with a normal make?" effect would be the proverbial straw for a large crowd. Ship it with pregenerated files. Include a warning that if you fiddle with the generated files, you'll probably need to install a bunch of tools, or they won't regenerate right. Included in the tools would be a make compatible with the gmake extensions. It's similar to including your autoconf and bison source files, and the generated configure and .c files, and warning people that if they want to customize, the'll need autoconf and/or bison... From barry@digicool.com Tue May 29 19:48:29 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 29 May 2001 14:48:29 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> Message-ID: <15123.61181.924613.914185@anthem.wooz.org> I had some mail outages over the weekend so I didn't see the original message in this thread (I may still get it). Checking the archive though, it appears that there are complaints about GNU-make-isms in the message/Makefile{,.in}. My intent is to indeed check in all the generated files, so that normally no one would ever have to run "make catalogs". My intention is that I would run those when the mailman.pot file needed updating, or when I got new translations and wanted to update the various language .po files. So, I'm not concerned about GNU-make-isms for "make catalogs". That's why "make all" and "make install" don't depend on any of the generated files. I should probably add a comment to the top of messages/Makefile.in just saying that "make catalogs" requires GNU make. -Barry From barry@digicool.com Tue May 29 19:54:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 29 May 2001 14:54:35 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> <15123.61181.924613.914185@anthem.wooz.org> Message-ID: <15123.61547.734290.731443@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> So, I'm not concerned about GNU-make-isms for "make BAW> catalogs". That's why "make all" and "make install" don't BAW> depend on any of the generated files. I should probably add BAW> a comment to the top of messages/Makefile.in just saying that BAW> "make catalogs" requires GNU make. Oh, yeah. I see there was a redundant definition of the .po->.mo file transformation. I'll bet BSDmake was picking up the broken .po.mo entry and GNUmake was picking up the full rule down below. I'll check in a fix for this shortly. -Barry From thomas@xs4all.net Tue May 29 23:00:34 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 30 May 2001 00:00:34 +0200 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 In-Reply-To: <15123.61547.734290.731443@anthem.wooz.org>; from barry@digicool.com on Tue, May 29, 2001 at 02:54:35PM -0400 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> <15123.61181.924613.914185@anthem.wooz.org> <15123.61547.734290.731443@anthem.wooz.org> Message-ID: <20010530000034.W690@xs4all.nl> On Tue, May 29, 2001 at 02:54:35PM -0400, Barry A. Warsaw wrote: > I see there was a redundant definition of the .po->.mo file > transformation. I'll bet BSDmake was picking up the broken .po.mo > entry and GNUmake was picking up the full rule down below. That's exactly what happened. I couldn't believe my eyes when I saw BSD make and GNU make attach the exact opposite meaning to $@ and $<, but I didn't think to search for redundant definitions ! I think $< is still a GNU-makeism, but I can live with requiring GNU make for building catalogs just fine. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@digicool.com Tue May 29 23:03:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 29 May 2001 18:03:30 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> <15123.61181.924613.914185@anthem.wooz.org> <15123.61547.734290.731443@anthem.wooz.org> <20010530000034.W690@xs4all.nl> Message-ID: <15124.7346.40630.157111@anthem.wooz.org> >>>>> "TW" == Thomas Wouters writes: TW> That's exactly what happened. I couldn't believe my eyes when TW> I saw BSD make and GNU make attach the exact opposite meaning TW> to $@ and $<, but I didn't think to search for redundant TW> definitions ! I think $< is still a GNU-makeism, but I can TW> live with requiring GNU make for building catalogs just fine. Yeah, I said to myself "no way" when I read that. It would be INSANE to swap those meanings. Then when I was cleaning up the file, I had a Homer Moment (read: "doh!" :) -Barry From Swee Heng Wed May 30 12:56:40 2001 From: Swee Heng (Swee Heng) Date: Wed, 30 May 2001 19:56:40 +0800 (SGT) Subject: [Mailman-Developers] subscriber profiler patch for mailman-2.0.5 Message-ID: hi folks, i've written a patch to mailman-2.0.5 that lets it handle subscribers' profiles. (is this the "member profiles" feature on the wishlist?) the patch is available at: http://www.srikant.org/~sh/src/mmprofiler/mm-2.0.5-prof-0.7.gz a screenshot of it in action is at: http://www.srikant.org/~sh/src/mmprofiler/screenshot.jpg this is my first serious attempt at python. so please be warned. :) feel free to comment. swee heng ====================================================================== Brief Documentation ^^^^^^^^^^^^^^^^^^^ how to install it: ^^^^^^^^^^^^^^^^^^ 1. "patch -p0 <" the patch to mailman-2.0.5 2. do the usual "./configure; make; make install" this will create Mailman/Cgi/profile.py, cgi-bin/profile and three templates files (prof_login.html, prof_list.html, prof_user.html) in templates/. it will also modify Mailman/Cgi/edithtml.py so that list admins can change the look of the templates. how to use it: ^^^^^^^^^^^^^^ for currently existing lists, you need to copy the template files: cp templates/prof_* lists/the-existing-list/ for new lists, nothing needs to be done. finally, visit the URL: http://your.domain/mailman/profile/view/name-of-list notes: ^^^^^^ 1. profile information is made available to list members and admins when private_roster == 0 or 1. it is made available only to list admins when private_roster == 2. profile information is not available otherwise. 2. the database is really just a collection of pickles, one for each subscriber, stored in lists/name-of-list/profiles/. 3. i've used a whole slew of replacement MM tags, but they all look like or . they won't pollute other tags. From barry@digicool.com Thu May 31 06:51:42 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 31 May 2001 01:51:42 -0400 Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or less...) References: Message-ID: <15125.56302.501876.382172@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> I finally found a tool that takes care of this for me -- it's CVR> called mod_layout (www.tangent.org), and it's an apache CVR> module, so this is apache specific. Very cool indeed. Although I haven't had time to play with it, it seems like a low-cost approach that gets you 90% of the way there. CVR> This gives me control over almost all of Mailman (and, hint CVR> hint) -- hopefully Barry will add the configuration for the CVR> rest down the road. CVR> One is that some of the text-box colors are hard-coded (see, CVR> for instance, /mailman/admin/listname/general/. It'd be nice CVR> (and it seems to be easy to do) to turn those into globals CVR> that can be set in mm_cfg.py instead of requiring someone to CVR> whack all of the source files they're sprinkled in. I've completely rewritten the user options page (more on this later, tomorrow is checkin day :), and have taken the opportunity to do exactly this. I may have missed some, but the idea is that the colors are now overridable in mm_cfg.py. Which makes me think more about having a better support for virtual domains by having something akin to a different mm_cfg.py per domain. That's rumbling around in the back of my head. CVR> The other key one for me are some of the admin messages CVR> (Mailman/Handlers/Hold.py). I've modified some of the CVR> messages for various reasons, and it'd be nice if I could CVR> simply override their definitions in the mm_cfg.py file I'll have to think about this. One hackish idea (untested) is to try to import Mailman.Hold from mm_cfg.py, and then set the class's __doc__ attribute with the message you want. The fact that Mailman/Hold.py imports mm_cfg.py means you might have to play games with the importer to get this to work. Not a great solution, but it might help localize your customizations for now. CVR> And the third place I've made custom changes are in some of CVR> the list templates (most radically templates/listinfo.html) CVR> -- but that's why they're template; you simply keep a copy CVR> somewhere and watch out for additions to the updated copy... Exactly, and the new template lookup scheme should be much more friendly to this approach. CVR> It took me about three days and a couple of exchanges with CVR> the author of mod_layout to get it going the way I wanted CVR> (the documentation is still being fleshed out), but it's a CVR> nice improvement to the old way of doing things -- and since CVR> I know others build custom skins around their installations, CVR> I'd thought I'd pass this one along. Yes, thanks! -Barry From chuqui@plaidworks.com Thu May 31 07:02:53 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 30 May 2001 23:02:53 -0700 Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or less...) In-Reply-To: <15125.56302.501876.382172@anthem.wooz.org> Message-ID: <200105310554.f4V5smh04253@plaidworks.com> On Wednesday, May 30, 2001, at 10:51 PM, Barry A. Warsaw wrote: > CVR> The other key one for me are some of the admin messages > CVR> (Mailman/Handlers/Hold.py). I've modified some of the > CVR> messages for various reasons, and it'd be nice if I could > CVR> simply override their definitions in the mm_cfg.py file > > I'll have to think about this. One hackish idea (untested) is to try > to import Mailman.Hold from mm_cfg.py, and then set the class's > __doc__ attribute with the message you want. I think a more general solution is to rethink the admin messages, and make them part of the site and list databases. You would have 0 ... n definitions, each of the form: regex action message lockflag where the latter is in the site database only. actions would include HOLD, DISCARD, REJECT and whatever else people would find useful. you could then define this as a set of python regexes (with, I think, a few procmail-esque extensions, so you could define whether to look in header, body or both, and in the body, optionally the first N lines...), and do something with it, and a message including python ''' multiline format. The lockflag is so the site admin can, if they choose, keep list admins from over-riding definitions. So for each message, you'd check the site-wide LOCKed lines, then the list definitions, then the site-wide definitions, and stop on the first match. that way, you stop having to migrate global definitions to each list, and have to worry about updating them on updates... And make them definable, editable and viewable from the web interface so the list admins and site admin can tweak them. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I like you. You remind me of when I was young and stupid. From chuqui@plaidworks.com Thu May 31 08:23:53 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 31 May 2001 00:23:53 -0700 Subject: [Mailman-Developers] minor qrunner bug. Message-ID: <200105310715.f4V7Fmh05534@plaidworks.com> Just noticed a minor bug in qrunner. when qrunner starts up, it opens the log files, and leaves them open. this is fine -- except when the logs get rolled and restarted. When you move the logs off and gzip them for storage, qrunner continues writing to the (now unlinked) old files, not the new, zeroed ones. So all of the qrunner stat and errror and whatever data from the time you roll the logs until that instance of qrunner exits is gone (which, if you've modified qrunner lifetime values, can become significant on a busy system) Since mailman isn't oding much log processing, not a big deal. but for sites that are (for instance) charging for list usage, or sites that have implemented reporting, there are potential holes in the data, and if they're busy so they have extended qrunner times, significant holes. while open/write/close is expensive, given all of the other stuff qrunner's doing and the relative lack of logging, I don't think it's significant. Alternatively, it can notice the files have been moved/zeroed, or perhaps accept a HUP like syslog... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I'm out of my mind, but feel free to leave a message... From jon@latchkey.com Thu May 31 18:35:59 2001 From: jon@latchkey.com (Jon Stevens) Date: Thu, 31 May 2001 10:35:59 -0700 Subject: [Mailman-Developers] minor qrunner bug. In-Reply-To: <200105310715.f4V7Fmh05534@plaidworks.com> Message-ID: on 5/31/01 12:23 AM, "Chuq Von Rospach" wrote: > > Just noticed a minor bug in qrunner. when qrunner starts up, it opens > the log files, and leaves them open. > > this is fine -- except when the logs get rolled and restarted. When you > move the logs off and gzip them for storage, qrunner continues writing > to the (now unlinked) old files, not the new, zeroed ones. So all of the > qrunner stat and errror and whatever data from the time you roll the > logs until that instance of qrunner exits is gone (which, if you've > modified qrunner lifetime values, can become significant on a busy > system) > > Since mailman isn't oding much log processing, not a big deal. but for > sites that are (for instance) charging for list usage, or sites that > have implemented reporting, there are potential holes in the data, and > if they're busy so they have extended qrunner times, significant holes. > > while open/write/close is expensive, given all of the other stuff > qrunner's doing and the relative lack of logging, I don't think it's > significant. Alternatively, it can notice the files have been > moved/zeroed, or perhaps accept a HUP like syslog... The files should remain open... Because, exactly as you suggest, there is a sever penalty for open/write/close. The way that Apache HTTPd works (as well as many other daemons) is that you move the log files out of the way and then you HUP Apache which will re-create the log files. Accepting HUP's (or a graceful restart) is functionality that should be added to qrunner if it isn't there already. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous From wilane@MINT.SN Thu May 31 20:21:59 2001 From: wilane@MINT.SN (Ousmane Wilane) Date: Thu, 31 May 2001 19:21:59 +0000 (GMT) Subject: [Mailman-Developers] FR catalog! Message-ID: Hi, A french catalog is available at http://mint.sn/Mailman/mailman.po.gz. We have also made available a test setup (2.1a2) with a Mailman-fr list supporting es, fr. Japanese will be added in no time. Thanks in advance for helps correcting the translations. Cheers. -- -- Ousmane Wilane -- "The best laid plans sometimes go awry..." From claw@kanga.nu Tue May 1 00:59:14 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 30 Apr 2001 16:59:14 -0700 Subject: [Mailman-Developers] Delivering messages to scripts/post In-Reply-To: Message from Jesper Jensen of "Tue, 01 May 2001 00:54:39 +0200." <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <2079.988675154@kanga.nu> On Tue, 01 May 2001 00:54:39 +0200 Jesper Jensen wrote: > I fully understand and respect that this is a Linux project... Actually its a GNU project, which is not at all Linux specific. Mailman in its current incarnation is Unix-centric in a number of ways (which subtley different from Linux-centric), but that is mainly due to the majority of the developers (and thus the users) having Unix as their preferred (server) platform. > We chaned to Mailman because we needed some things LISTSERV didn't > have. Like what? (might as well pump up our strengths) -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From barry@digicool.com Tue May 1 04:42:27 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 30 Apr 2001 23:42:27 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> Message-ID: <15086.12451.92841.383891@anthem.wooz.org> >>>>> "F" == Fil writes: F> "When sent" is the default. How do you change the default to F> "When Resent"? Shouldn't it be changed in the mailman's F> Defaults.py ? >>>>> "MM" == Marc MERLIN writes: MM> I very firmly believe this, and so do all the people who have MM> archives showing messages with dates of 2004 or 1990. MM> http://lists.svlug.org/pipermail/svlug/ MM> I've asked the same thing in the past, but it didn't go MM> through. We've talked in the past of adding an option to clobber_date to only munge dates when they're outrageous. This turns out to be easy to do, and I'm willing to add it for 2.1 (I'm hacking the code right now). However, it seems to me that this really ought to be a site-wide configuration instead of a list-specific configuration. I don't see a whole lot of value in allowing lists to individually clobber the dates. I see this as going hand-in-hand with external archiving; e.g. you may not want to clober the date if you're using an external archiver, because perhaps it performs its /own/ sanity checks on the Date: header. So my proposal is to - get rid of clobber_date as a list-specific variable - add a site variable ARCHIVER_CLOBBER_DATE_POLICY which takes one of three values: 0 (never override the original message's Date: header); 1 (always override the original message's Date: header with the `processed' date); 2 (only override the header if the date is outrageous). - add a site variable ARCHIVER_ALLOWABLE_SANE_DATE_SKEW which specifies a time in seconds outside of which the Date will be considered outrageous (i.e if its either too early or too late). Comments? -Barry From barry@digicool.com Tue May 1 04:46:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 30 Apr 2001 23:46:16 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> Message-ID: <15086.12680.151445.182210@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> So my proposal is to BAW> - get rid of clobber_date as a list-specific variable BAW> - add a site variable ARCHIVER_CLOBBER_DATE_POLICY which BAW> - add a site variable ARCHIVER_ALLOWABLE_SANE_DATE_SKEW which Oh yeah, the defaults would be ARCHIVER_CLOBBER_DATE_POLICY = 2 ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) so if the message had a Date: header earlier or later than 90 days from now, it would get the header overridden. Note that this munging happens before the message is handed to the archiver, and it occurs regardless of whether Pipermail or an external archiver handles it. The original Date: header will be put on X-Original-Date (does that need to be configurable?) -Barry From wilane@MINT.SN Tue May 1 05:14:40 2001 From: wilane@MINT.SN (Ousmane Wilane) Date: Tue, 1 May 2001 04:14:40 +0000 (GMT) Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.12680.151445.182210@anthem.wooz.org> Message-ID: On Mon, 30 Apr 2001, Barry A. Warsaw wrote: So far so good as usual! BAW>ARCHIVER_CLOBBER_DATE_POLICY = 2 BAW>ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) IMHO 90 It's too long as default! Why? O. W. Kind regards. From jra@baylink.com Tue May 1 05:19:54 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 00:19:54 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <20010430154146.C32211@magic.merlins.org>; from Marc MERLIN on Mon, Apr 30, 2001 at 03:41:46PM -0700 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> Message-ID: <20010501001954.24484@scfn.thpl.lib.fl.us> On Mon, Apr 30, 2001 at 03:41:46PM -0700, Marc MERLIN wrote: > > "When sent" is the default. How do you change the default to "When Resent"? > > Shouldn't it be changed in the mailman's Defaults.py ? > > I very firmly believe this, and so do all the people who have archives > showing messages with dates of 2004 or 1990. > http://lists.svlug.org/pipermail/svlug/ > > I've asked the same thing in the past, but it didn't go through. > Please? :-) Concur, FWIW. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 05:20:38 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:20:38 -0400 Subject: [Mailman-Developers] Delivering messages to scripts/post References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <15086.14742.421568.853743@anthem.wooz.org> >>>>> "JJ" == Jesper Jensen writes: JJ> We have been running Mailman on Windows for about two weeks JJ> now and most things seem to work very well. Very cool! JJ> To make it run I had to make some changes - all of them minor JJ> - and most of them related to opening files ('b'). Ah yes. That and pre-unlinking (i.e. unlinking a file you have open because you know it will go away when the file is closed) are two Unixisms that often bite me when porting Python code to Windows. I try to be good, but old habits die hard. ;) JJ> Mailmanwin (as I have named it) is probably not useful for JJ> anyone but me (and my company) right now; some things do not JJ> work at all (web interface, e-mail archive, usenet gateway, JJ> all the bin scripts) and some things are changed to make them JJ> better fit my needs. What version of Mailman are you running? I'd be interested in looking at any patches that help port Mailman to Windows (or any other platform for that matter). I develop on Linux these days, and before leaving CNRI, primarily Solaris. I'm fairly confident Mailman runs on any (sane :) Unix-like OS, and I have nothing philosophical against porting Mailman to any platform that Python runs on -- and that's a lot of platforms. But I don't have much time to do that work myself, so such porting necessarily relies on contributions from others. JJ> I have made an "install" script doing all the work and JJ> describing all the changes, so it's fairly easy getting JJ> started. I hope to get a webpage up with these things soon. When you're ready to submit patches, please upload them to SourceForge. I've created a new patch category called "cross platform". JJ> I don't expect the mailman developers to take account of any JJ> of these changes. I fully understand and respect that this is JJ> a Linux project and would hate if cross platform issues in any JJ> way affected the future direction of Mailman. Having said JJ> that, it would be nice if no module names conflicted with JJ> modules in the standard Python distribution (mailbox) ;) This should actually be better for Python 2.1 since the case-sensitivity on imports for case-preserving case-insensitive file systems (e.g. Windows) has been greatly improved (I've been told). I thought about renaming Mailbox.py, but that's a PITA because I don't want to lose the CVS history and renaming-retaining-history can't be done without access to the CVS repository. I'll probably just require MacOSX and Cygwin (and Windows :) users to use to Python 2.1. Everyone else should be fine with Python 2.0 or 2.1. JJ> 1. Delivering messages to scripts/post I could not find any JJ> MTA for Windows (I didn't look much, though) that was able to JJ> get the toaddr and deliver the message to scripts/post. JJ> Instead we are using L-soft LSMTP (we used L-soft LISTSERV JJ> before changing to Mailman). LSMTP is told to save all JJ> messages (complete with all envelope header information) and I JJ> have made a Python script that parses each message and calls JJ> Enqueu with the correct parameters. JJ> This works well, except that we have had a couple of mail JJ> loops because of auto-responders replying directly to the JJ> list. So my question is, what information does a MTA look for JJ> before passing the message to post? In the usual Unix MTA world, nothing, it's a dumb pipe. Mailman itself looks at the incoming message for X-BeenThere headers and raises a LoopError if it finds one that matches the list address. There's no guarantee that'll be preserved during the loop though, and in that case there isn't much that can be done. JJ> I found out that filtering out all messages with daemon and/or JJ> postmaster in the fromaddr is a good idea. Are there any JJ> other "keywords" that i should know of? You might look at LIKELY_BOUNCE_SENDERS in Defaults.py, which includes mailer-daemon, orphanage, and postoffice though I can't personally remember ever seeing bounce message originate from the latter two. JJ> 2. Empty envelope fromaddr In some messages the envelope JJ> fromaddr is empty. Is it safe to never deliver a message with JJ> an empty envelope fromaddr to a list? I've no idea, since I don't know why for you the From_ header is missing sometimes. JJ> 3. Using the envelope fromaddr or the message fromaddr I can JJ> see that this is a Mailman setting. What are the consequences JJ> of using only the envelope fromaddr? In practice, you'll get a lot more holds if you limit postings to members only. While the From: header is easily spoofable, it turns out to be a much greater PITA to use the From_ header (which itself isn't that hard to spoof). JJ> Just for the record. L-soft LISTSERV is a great product - the JJ> most solid/stable I have ever used. We chaned to Mailman JJ> because we needed some things LISTSERV didn't have. Cool! If you have the time, perhaps you can post a list of things you like about LISTSERV that Mailman doesn't have, and vice versa. -Barry From jra@baylink.com Tue May 1 05:21:20 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 00:21:20 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.12680.151445.182210@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Apr 30, 2001 at 11:46:16PM -0400 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> Message-ID: <20010501002120.33084@scfn.thpl.lib.fl.us> On Mon, Apr 30, 2001 at 11:46:16PM -0400, Barry A. Warsaw wrote: > >>>>> "BAW" == Barry A Warsaw writes: > BAW> So my proposal is to > BAW> - get rid of clobber_date as a list-specific variable > BAW> - add a site variable ARCHIVER_CLOBBER_DATE_POLICY which > BAW> - add a site variable ARCHIVER_ALLOWABLE_SANE_DATE_SKEW which > Oh yeah, the defaults would be > ARCHIVER_CLOBBER_DATE_POLICY = 2 > ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) > so if the message had a Date: header earlier or later than 90 days > from now, it would get the header overridden. Note that this munging > happens before the message is handed to the archiver, and it occurs > regardless of whether Pipermail or an external archiver handles it. > The original Date: header will be put on X-Original-Date (does that > need to be configurable?) That sounds good to me, although, as someone noted, perhaps 90 days is a bit long. Did you pull that number out of your butt, or was there a specific motivation for it? Cheers. - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 05:24:55 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:24:55 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <15086.12680.151445.182210@anthem.wooz.org> Message-ID: <15086.14999.492269.256070@anthem.wooz.org> >>>>> "OW" == Ousmane Wilane writes: OW> So far so good as usual! Thanks! BAW> ARCHIVER_CLOBBER_DATE_POLICY = 2 BAW> ARCHIVER_ALLOWABLE_SANE_DATE_SKEW = days(90) OW> IMHO 90 It's too long as default! Why? I figure most of the outrageous headers are something on the order of /years/ away, and I just picked 90 days out of a hat. I think it ought to be greater than the average retry interval in case a Mailman site is unavailable for a few days. So, suggest something more reasonable in between 5 and 90 days! :) -Barry From barry@digicool.com Tue May 1 05:27:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:27:16 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> Message-ID: <15086.15140.661323.198609@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> That sounds good to me, although, as someone noted, perhaps JRA> 90 days is a bit long. Did you pull that number out of your JRA> butt, or was there a specific motivation for it? See my other message. Although I'd like to think that my brain's located a little higher up in my anatomy , you're not far off. -Barry From otaylor@redhat.com Tue May 1 05:32:23 2001 From: otaylor@redhat.com (Owen Taylor) Date: 01 May 2001 00:32:23 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: Marc MERLIN's message of "Mon, 30 Apr 2001 15:41:46 -0700" References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> Message-ID: Marc MERLIN writes: > On Mon, Apr 30, 2001 at 09:28:51PM +0200, Fil wrote: > > @ Darrell Fuhriman (darrell@grumblesmurf.net) : > > > That's why under "archival options" you'll find: > > > > > > "Set date in archive to when the mail is claimed to have been > > > sent, or to the time we resend it?" > > > > > > If you leave it on 'when sent', you deserve the mess you'll get > > > in your archives. > > > > "When sent" is the default. How do you change the default to "When Resent"? > > Shouldn't it be changed in the mailman's Defaults.py ? > > I very firmly believe this, and so do all the people who have archives > showing messages with dates of 2004 or 1990. > http://lists.svlug.org/pipermail/svlug/ > > I've asked the same thing in the past, but it didn't go through. What I did for the gnome.org archives (using mhonarc plus custom perl) is to used the Received: header for the date. Which is, almost always, quite close to the time the person actually sent it, and assuming that your local server's time isn't screwed up (which is a much bigger problem...) does not have the 2004 problem. And it has the advantage over clobber_date of: - Not munging the mail - Not being skewed by moderation delays - Being independent of the archiving process, so if you import a bunch of old mail with incorrect Date: lines into the archiving process you still get the 2004 protection. I haven't looked at the clobber_date implementation recently, so I don't know if these problems have been otherwise addressed. This approach has, anyways, worked well for the 140k messages on mail.gnome.org. I wouldn't be suprised if it has defects though. Regards, Owen From jra@baylink.com Tue May 1 05:52:00 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 00:52:00 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.15140.661323.198609@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 12:27:16AM -0400 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> Message-ID: <20010501005200.43574@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 12:27:16AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> That sounds good to me, although, as someone noted, perhaps > JRA> 90 days is a bit long. Did you pull that number out of your > JRA> butt, or was there a specific motivation for it? > > See my other message. Although I'd like to think that my brain's > located a little higher up in my anatomy , you're not far off. Well, the implication was that your brain wasn't involved in the thing. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 05:57:45 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 00:57:45 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> Message-ID: <15086.16969.185480.230418@anthem.wooz.org> >>>>> "OT" == Owen Taylor writes: OT> What I did for the gnome.org archives (using mhonarc plus OT> custom perl) is to used the Received: header for the date. Ah, but which one? :) There's going to have a Received: header for each hop that message takes. By the time your message got to me, it had 7 Received: headers, and 3 (I think) by the time it reached Mailman. OT> Which is, almost always, quite close to the time the person OT> actually sent it, and assuming that your local server's time OT> isn't screwed up (which is a much bigger problem...) does OT> not have the 2004 problem. OT> And it has the advantage over clobber_date of: | - Not munging the mail True, with the disadvantage that if you use an external archiver, it'll have to handle checking for outrageous dates. clobber_date munges the message before it hits either archiver (Pipermail or external). If I was smart, I'd also count as a major disadvantage the fact that I'll have to track down all the places where the Date: header is used in Pipermail, and I /hate/ diving in that code. ;( | - Not being skewed by moderation delays Dang, yep, but fixable. | - Being independent of the archiving process, so if you | import a bunch of old mail with incorrect Date: lines | into the archiving process you still get the 2004 | protection. True, with the caveat above. This would be a reasonable option, however if you use the most recent Received: header, won't you still be subject to local server clock skew? And if you use the earliest Received: you'll be subject to the same bogosity in the Date: header. Or do you just start parsing the Received:'s back from the most recent and take the first sane one you find? -Barry From barry@digicool.com Tue May 1 06:00:14 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 01:00:14 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> Message-ID: <15086.17118.430487.160237@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Well, the implication was that your brain wasn't involved in JRA> the thing. Ah some new entries for my X-Oblique-Strategy file: Trust the Butt The Butt Knows Best When in Doubt, ButtThink ? :) -Barry From jra@baylink.com Tue May 1 06:01:45 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 01:01:45 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.17118.430487.160237@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 01:00:14AM -0400 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> Message-ID: <20010501010145.48432@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 01:00:14AM -0400, Barry A. Warsaw wrote: > Ah some new entries for my X-Oblique-Strategy file: > Trust the Butt > The Butt Knows Best > When in Doubt, ButtThink Use the farts, Luke. or, alternatively: Luke... *I* am your farter. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 06:04:34 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 01:04:34 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> Message-ID: <15086.17378.261384.350847@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Use the farts, Luke. JRA> or, alternatively: JRA> Luke... *I* am your farter. Ah, that's the spirit! Mailman's new motto: The Better Smelling List Server -Barry From thomas@xs4all.net Tue May 1 09:35:26 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 1 May 2001 10:35:26 +0200 Subject: [Mailman-Developers] Small nntp server? In-Reply-To: ; from din5w@cs.virginia.edu on Fri, Apr 27, 2001 at 10:03:05AM -0400 References: <15080.56527.608668.936637@anthem.wooz.org> Message-ID: <20010501103526.N16486@xs4all.nl> On Fri, Apr 27, 2001 at 10:03:05AM -0400, Dale Newfield wrote: > Does anyone have a (free?) unix based nntp server they'd suggest that can > be configured to be stand-alone (no pushing upstream or downstream), and > would handle 10's of local newsgroups and ~1000 subscribers reasonably > well? You can try both INN (http://www.isc.org/inn.html) and Diablo (http://www.openusenet.org/diablo/), though I'd suggest using Diablo. Both are free, but they aren't terribly easy to configure. You can definately tell them not to feed up/downstream, though. Diablo has a very active userbase, but INN's older and probably still larger. You're likely to find good FAQs and HOWTO's for both. > We're running a FreeBSD box if that matters. Well, at XS4ALL we run a news setup of 10+ machines, all running Diablo on FreeBSD, and they do it very, very well. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Tue May 1 09:39:56 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 1 May 2001 10:39:56 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010428123324.A1102@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 28, 2001 at 12:33:24PM +0200 References: <20010428123324.A1102@rix.rixhq.nu> Message-ID: <20010501103956.O16486@xs4all.nl> On Sat, Apr 28, 2001 at 12:33:24PM +0200, Ricardo Kustner wrote: > Anyway my point is that now I'm getting some complaints from members about > receiving empty digests (it only says the number of posts which should be in > there) I'm not sure yet what they are missing but I was wondering if I > could have messed things about by interrupting the process w/o a m.Save()? > When I look up the subscription options for one of the members who > complained I don't see anything weird in there... Did you exit the withlist between the two tries ? You might have screwed up one (1) of the subscribers, but definately not more of them. If you exited the withlist without doing m.Save(), nothing happened because of it. If you didn't exit, but re-did the for loop, the changes you'd made would have been saved by the m.Save() at the end, but most of those people would've been set to digest. Only the one that was being processed when you pressed ^C *might* be screwed up. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Tue May 1 09:41:21 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 1 May 2001 10:41:21 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010428132341.C1102@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 28, 2001 at 01:23:41PM +0200 References: <20010428123324.A1102@rix.rixhq.nu> <20010428132341.C1102@rix.rixhq.nu> Message-ID: <20010501104121.P16486@xs4all.nl> On Sat, Apr 28, 2001 at 01:23:41PM +0200, Ricardo Kustner wrote: > On Sat, Apr 28, 2001 at 12:33:24PM +0200, Ricardo Kustner wrote: > > Anyway my point is that now I'm getting some complaints from members about > > receiving empty digests (it only says the number of posts which should be in > > there) I'm not sure yet what they are missing but I was wondering if I > > could have messed things about by interrupting the process w/o a m.Save()? > uh oh please don't tell me that when mailman sends out digests, they travel through the > /etc/aliases addresses cause that would mean a neat little perl script I > use filters out the MIME digests... :( [I really need this script to keep > the digests clean from garbage)... hmm on the other hand it could also be > that the digests are handled directly by qrunner so they won't go through > the filter so that wouldn't explain the problems... It depends on the delivery method you chose. If you use the Sendmail module, it'll probably pass it through /etc/aliases. If you use the SMTP module and the localhost as delivery point, it'll pass through /etc/aliases too. It's damned easy to test, though: disable the filter, make a new digest list, subscribe yourself to it, and mail ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@digicool.com Tue May 1 10:13:05 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 05:13:05 -0400 Subject: [Mailman-Developers] empty digests References: <20010428123324.A1102@rix.rixhq.nu> Message-ID: <15086.32289.681349.341063@anthem.wooz.org> >>>>> "RK" == Ricardo Kustner writes: RK> This took a really long time (1635 regular subscribers) and RK> after about 20 minutes I decided to press Ctrl-C cause I was RK> afraid it hung somewhow... this means I wasn't able to do a RK> m.Save() but after checking the number of subscriber was RK> reduced to about 60 so appearantly it did work out... The reason why it took so long, /and/ the reason why most of your subscribers actually got digestered is the same: SetUserDigest() does a self.Save() after each call. As Thomas says, the worst that you could have done would be to mess up one subscriber (the one you ^C'd), but even there, you likely would have only reverted the change in that subscriber's option. I don't see how that could cause empty digests though. Now, one question is whether SetUserDigest() should do a Save() after each call. I think in all normal usage, SetUserDigest() will be wrapped in a try/finally to ensure that the list is saved. OTOH, there probably isn't any CGI way to set more than about 30 subscribers options, and even then, I'll bet the typical case sets only one or a small few, so the extra writes don't hurt too badly. That's not the case in withlist. First, you're using it to mass configure lots of users so the extra writes are killing you. But then again, it made most of your changes go through. I'm inclined to ditch the Save() at the end of SetUserDigest() at the expense of losing your changes if you quit withlist with unsaved changes. >>>>> "RK" == Ricardo Kustner writes: RK> uh oh please don't tell me that when mailman sends out RK> digests, they travel through the /etc/aliases addresses cause RK> that would mean a neat little perl script I use filters out RK> the MIME digests... :( [I really need this script to keep the RK> digests clean from garbage)... This would be my first suspicion (and not just 'cause it's perl )! The empty digests, are they MIME digests? If plain text, maybe they're still tripping up your script. Thomas outlines a good plan of first attack! -Barry From tollef@add.no Tue May 1 11:21:53 2001 From: tollef@add.no (Tollef Fog Heen) Date: 01 May 2001 12:21:53 +0200 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.14999.492269.256070@anthem.wooz.org> References: <15086.12680.151445.182210@anthem.wooz.org> <15086.14999.492269.256070@anthem.wooz.org> Message-ID: <87d79t2wu6.fsf@arabella.intern.opera.no> * (Barry A. Warsaw) | So, suggest something more reasonable in between 5 and 90 days! :) A week, or maximum 30 days. IMHO. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. (and please stop using the DUL, it's broken) From otaylor@redhat.com Tue May 1 14:00:06 2001 From: otaylor@redhat.com (Owen Taylor) Date: 01 May 2001 09:00:06 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: barry@digicool.com's message of "Tue, 1 May 2001 00:57:45 -0400" References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <20010430154146.C32211@magic.merlins.org> <15086.16969.185480.230418@anthem.wooz.org> Message-ID: barry@digicool.com (Barry A. Warsaw) writes: > >>>>> "OT" == Owen Taylor writes: > > OT> What I did for the gnome.org archives (using mhonarc plus > OT> custom perl) is to used the Received: header for the date. > > Ah, but which one? :) There's going to have a Received: header for > each hop that message takes. By the time your message got to me, it > had 7 Received: headers, and 3 (I think) by the time it reached > Mailman. The most recent. So you'll only get the wrong date if clobber_data would also get it wrong; people will tell you pretty quickly if your mail server has an incorrect clock. > OT> Which is, almost always, quite close to the time the person > OT> actually sent it, and assuming that your local server's time > OT> isn't screwed up (which is a much bigger problem...) does > OT> not have the 2004 problem. > > OT> And it has the advantage over clobber_date of: > > | - Not munging the mail > > True, with the disadvantage that if you use an external archiver, > it'll have to handle checking for outrageous dates. clobber_date > munges the message before it hits either archiver (Pipermail or > external). I guess I'd consider getting the date right to be the concern of the archiver, not of the system feeding to the archiver - after all, its pretty common to also want to feed a chunk of old pre-mailman archives into an archiver along with the mailman ones. > If I was smart, I'd also count as a major disadvantage the > fact that I'll have to track down all the places where the Date: > header is used in Pipermail, and I /hate/ diving in that code. ;( Yeah, there are always practical concerns ;-) > | - Not being skewed by moderation delays > > Dang, yep, but fixable. > > | - Being independent of the archiving process, so if you > | import a bunch of old mail with incorrect Date: lines > | into the archiving process you still get the 2004 > | protection. > > True, with the caveat above. > > This would be a reasonable option, however if you use the most recent > Received: header, won't you still be subject to local server clock > skew? And if you use the earliest Received: you'll be subject to the > same bogosity in the Date: header. Or do you just start parsing the > Received:'s back from the most recent and take the first sane one you > find? As mentioned above, local server clock breakage isn't really something I worry about; my concern with the clobber_date method wasn't that the local clock could be wrong, but rather, that it was discarding information from the message headers and replacing it with the current time, which, in some circumstances could be significantly different. Also, I did actually have a lot of old mail with bogus Date: fields that I was importing... Regards, Owen From jra@baylink.com Tue May 1 15:04:44 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 10:04:44 -0400 Subject: [Mailman-Developers] empty digests In-Reply-To: <15086.32289.681349.341063@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 05:13:05AM -0400 References: <20010428123324.A1102@rix.rixhq.nu> <15086.32289.681349.341063@anthem.wooz.org> Message-ID: <20010501100444.25644@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 05:13:05AM -0400, Barry A. Warsaw wrote: > That's not the case in withlist. First, you're using it to mass > configure lots of users so the extra writes are killing you. But then > again, it made most of your changes go through. I'm inclined to ditch > the Save() at the end of SetUserDigest() at the expense of losing your > changes if you quit withlist with unsaved changes. I contend that that is a feature, not a bug. How would you 'undo', otherwise? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jarrell@vt.edu Tue May 1 15:35:37 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 01 May 2001 10:35:37 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <15086.17378.261384.350847@anthem.wooz.org> References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010501103457.030d3b70@vtserf.cc.vt.edu> At 01:04 AM 5/1/01 -0400, Barry A. Warsaw wrote: >>>>>> "JRA" == Jay R Ashworth writes: > > JRA> Use the farts, Luke. > > JRA> or, alternatively: > > JRA> Luke... *I* am your farter. > >Ah, that's the spirit! > >Mailman's new motto: The Better Smelling List Server Barry Warsaw: The Man Who's Thoughts You Can Light.... (ducking and running very, very fast...) From barry@digicool.com Tue May 1 17:49:59 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 12:49:59 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> <5.1.0.14.2.20010501103457.030d3b70@vtserf.cc.vt.edu> Message-ID: <15086.59703.811837.444953@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Barry Warsaw: The Man Who's Thoughts You Can Light.... LOL! From jarrell@vt.edu Tue May 1 17:50:30 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 01 May 2001 12:50:30 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <5.1.0.14.2.20010501103457.030d3b70@vtserf.cc.vt.edu> References: <15086.17378.261384.350847@anthem.wooz.org> <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> <15086.12451.92841.383891@anthem.wooz.org> <15086.12680.151445.182210@anthem.wooz.org> <20010501002120.33084@scfn.thpl.lib.fl.us> <15086.15140.661323.198609@anthem.wooz.org> <20010501005200.43574@scfn.thpl.lib.fl.us> <15086.17118.430487.160237@anthem.wooz.org> <20010501010145.48432@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010501124910.03412e20@vtserf.cc.vt.edu> At 10:35 AM 5/1/01 -0400, Ron Jarrell wrote: >Barry Warsaw: The Man Who's Thoughts You Can Light.... > >(ducking and running very, very fast...) (Also using grammar very, very poorly... The things that come out of your fingers when you actually do know better. Sheesh.) From dan.mick@west.sun.com Tue May 1 20:23:01 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 12:23:01 -0700 Subject: [Mailman-Developers] Dates Message-ID: <3AEF0D15.1258875E@west.sun.com> Personally, I want the date in the Date header to be the one that shows up. I don't care when it got to the list server, finally; I care when it was sent. If the sender is too stupid to set up his machine, I want to know that, too. From jra@baylink.com Tue May 1 20:27:11 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 15:27:11 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF0D15.1258875E@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 12:23:01PM -0700 References: <3AEF0D15.1258875E@west.sun.com> Message-ID: <20010501152711.58471@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 12:23:01PM -0700, Dan Mick wrote: > Personally, I want the date in the Date header to be the one that > shows up. I don't care when it got to the list server, finally; I care > when it was sent. If the sender is too stupid to set up his machine, I > want to know that, too. It's possible, Dan, that you might have missed the fact that what's being discussed (unless *I* missed something big :-) is *what date the message is _archived_ as*... and that the original sent date is preserved in the archive. I don't think -- Barry will no doubt forrect me if my short term memory has gone completely to hell -- that he was rewriting dates on *mailed* messages... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Tue May 1 21:40:42 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 16:40:42 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <009c01c0cf5b$3165c2a0$01000001@sgergo.hu> <01042715193211.08359@graham.localdomain> Message-ID: <15087.8010.821127.647320@anthem.wooz.org> I'm CC'ing Mailman developers because I want to get some feedback from the Unix hackers amonst us; apologies for duplicates... >> We also experienced similar problems in the past with large >> lists. We found that if the admin is accessing the long and >> slow-loading members admin pages, and does not wait for the >> page to complete (e.g. clicks one of the admin links or hits >> refresh or stop) the lock will remain. As a temporary solution >> we have instructed our admins to wait for all pages to >> completely load, no stale locks since then. This is on a Cobalt >> RaQ4i (Redhat) with Apache 1.3x. Hope this helps, >>>>> "GT" == Graham TerMarsch writes: GT> Is probably related to what we're experiencing, but I'm GT> finding that even just due to the volume of hits on the GT> "subscribe" page, that we're having this problem. While GT> testing, I made sure that we had _no_ accesses to admin pages, GT> and that all of the "subscribe" hits that were coming through GT> waited for the complete response and didn't time out or have GT> the "stop" button pressed. Even in this scenario, I still GT> ended up with stale locks lingering around. [...] GT> Would it be correct to say that if the CGI process dies for GT> some unforseen reason (e.g. Apache kills it off because the GT> user pressed the "stop" button or the HTTP connection timed GT> out), that the lock from that process gets left around as a GT> lingering lock? After an all night hacking jag, lots of google searches, a re-read of Stevens Ch.10, and a short conversation with Guido, I believe I know what's going on. That's the good news. The bad news is that I don't think there's a perfect solution, but there probably is a better solution. FTR, here's my development environment: Apache 1.3.19, Python 2.1, RH6.2-ish, kernel 2.2.18, NS 4.74, and the current Mailman 2.1 CVS snapshot. Here's what I did: I loaded up a list with 60000 subscribers, then went to the members page. It did indeed take a long time, and if I let it run to completion, I get the page as expected and no locks. However, if I hit the stop button before the page is finished loading, I can see that the CGI process continues to run for a while and then it may or may not clear the locks. The page is not complete. Since sometimes the locks are cleared and sometimes they're left, it's pretty clear there are race conditions involved. I did a bit of web searching and here's what I think a stock Apache mod_cgi is supposed to do in this situation: - The user hits the stop button on the browser. The client will close the socket, which is usually eventually recognized by the server. - The cgi script meanwhile is merrily doing some long calculations, and eventually it will try to write output. It's at this point that it may be possible to detect that the socket has gone away. What's interesting is that it appears that the cgi script actually writes output to the parent Apache process, which perhaps buffers the output before sending to the client. In any event, it's the Apache parent process that gets a SIGPIPE indicating the socket it's writing to is closed. - Apache catches the SIGPIPE, turns around and sends a SIGTERM to the cgi process. Apache waits three seconds and if the cgi hasn't exited yet, it sends a SIGKILL. The default behavior for SIGTERM is to terminate the process, so whether it's the SIGTERM or SIGKILL that does the dirty work, in the end, the naive cgi script can get summarily killed without a chance at clean up. Enter Python. Python installs a few of its own signal handlers, most notably for SIGINT which it maps to the KeyboardInterrupt exception. Normally though, SIGTERM isn't caught by Python, so again, the naive Python cgi script will summarily die when receiving a SIGTERM. Under mod_cgi, even catching SIGTERM may not help if more than 3 seconds of processing occurs (I don't know if this is clock time or cpu time). Again, that's because Apache turns around and SIGKILLs the cgi, and that signal can't be caught (remember, this is what bit us a while back w.r.t. Postfix filter programs). So maybe the answer is to install a Python-level SIGTERM handler that will release the lock. To understand this, you need to know how Python handles signals. When you set a signal handler in Python, at the C level, Python installs its own signal handler, which simply sets a flag and returns. That's because Python will only run Python-level signal handlers in between bytecode boundaries. So your Python signal handler can get run at some arbitrary point in the future, and likely /not/ when the signal actually occurred. All this is very dodgy in the face of try/finally clauses, which is how cgi's like admin.py ensure that the mailing list is saved and unlocked when an exception occurs. For example, my initial solution was to install a signal handler that raised an exception, thinking that this would trigger the finally clause and do the normal save & unlock. But because of race conditions and interactions with the Python interpreter loop, I often saw that while the exception was getting raised, the finally clause wasn't always getting executed. Guido confirmed that this isn't a safe approach. So my next approach is to write a very minimal signal handler that only unlocks the list, and install this on SIGTERM. The trick is to make the signal handler, e.g. a nested function of main() in admin.py, and pass the MailList object into it using the default argument trick. This seems to work, in that the locks appear to be cleared in the cases where they were left laying around before. But because of all the race conditions, I can't be 100% sure. If you've read this far, the implication is that if the user hits the stop button, Mailman will in essence abort any changes to list configuration that this invocation may have made. Alternatively, we could try to save & unlock in the signal handler, but that raises the possibility of race conditions again. Also, it makes sense to move the save of the list data into the try: part of the clause and only do the unlocking in the finally. That way, the finally clause and the SIGTERM handler have the same semantics, and the list will get unlocked in the face of either an exception or a signal. But the list database will only get saved on sucessful completion of the task. I can live with those semantics (I think ;). So the code in admin.py looks something like: def main(): ... mlist = MailList.MailList(listname, lock=0) ... def sigterm_handler(signum, frame, mlist=mlist): mlist.Unlock() mlist.Lock() try: signal.signal(signal.SIGTERM, sigterm_handler) ... mlist.Save() finally: mlist.Unlock() I think there are still opportunities to get nailed, but I think this works as well as is possible. In my testing I've been able to clear the locks when the stop button is pushed. In the rare event that the list's config.db file gets corrupted (i.e. the handler gets called in the middle of mlist.Save()), we've always got the config.db.last file to fall back on. The other good news is that I think only admindb.py, admin.py, and confirm.py, need to be modified, since those are the only scripts that write to list attributes. I've been pretty diligent in Mailman 2.1 to only lock the mailing lists when necessary, so if the scripts are read-only, they don't acquire the lock (and get the state of the database as of the time of the initial Load()). Phew! -Barry From dan.mick@west.sun.com Tue May 1 22:27:46 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 14:27:46 -0700 Subject: [Mailman-Developers] Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> Message-ID: <3AEF2A52.A4C564B9@west.sun.com> "Jay R. Ashworth" wrote: > > On Tue, May 01, 2001 at 12:23:01PM -0700, Dan Mick wrote: > > Personally, I want the date in the Date header to be the one that > > shows up. I don't care when it got to the list server, finally; I care > > when it was sent. If the sender is too stupid to set up his machine, I > > want to know that, too. > > It's possible, Dan, that you might have missed the fact that what's > being discussed (unless *I* missed something big :-) is *what date the > message is _archived_ as*... and that the original sent date is > preserved in the archive. Right. But if it's archived as "today" when it was sent "yesterday", that's not the bahavior I would ever want, even if the Date: header is correct in the archive. > I don't think -- Barry will no doubt forrect > me if my short term memory has gone completely to hell -- that he was > rewriting dates on *mailed* messages... Right. I'm talking about the archiver too. I just wanted to point out that opinions differ. From jra@baylink.com Tue May 1 22:31:53 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 17:31:53 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF2A52.A4C564B9@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 02:27:46PM -0700 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> Message-ID: <20010501173153.19119@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 02:27:46PM -0700, Dan Mick wrote: > "Jay R. Ashworth" wrote: > > On Tue, May 01, 2001 at 12:23:01PM -0700, Dan Mick wrote: > > > Personally, I want the date in the Date header to be the one that > > > shows up. I don't care when it got to the list server, finally; I care > > > when it was sent. If the sender is too stupid to set up his machine, I > > > want to know that, too. > > > > It's possible, Dan, that you might have missed the fact that what's > > being discussed (unless *I* missed something big :-) is *what date the > > message is _archived_ as*... and that the original sent date is > > preserved in the archive. > > Right. But if it's archived as "today" when it was sent "yesterday", > that's not the bahavior I would ever want, even if the Date: header is > correct in the archive. Ok, but the situation we're discussing here is when it was sent yesterday, and received yesterday, but *dated* some time in 1982. Since the message will not contain *any* authoritative sent dates at that point, what protocol would you *suggest*, for having it archived as being sent yesterday, the way you'd like? > > I don't think -- Barry will no doubt forrect > > me if my short term memory has gone completely to hell -- that he was > > rewriting dates on *mailed* messages... > > Right. I'm talking about the archiver too. > I just wanted to point out that opinions differ. Certainly... but I don't necessarily see that you've posited a *solution*, just an opinion. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From dan.mick@west.sun.com Tue May 1 22:59:06 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 14:59:06 -0700 Subject: [Mailman-Developers] Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> Message-ID: <3AEF31AA.22A4CCBE@west.sun.com> > > Right. But if it's archived as "today" when it was sent "yesterday", > > that's not the bahavior I would ever want, even if the Date: header is > > correct in the archive. > > Ok, but the situation we're discussing here is when it was sent > yesterday, and received yesterday, but *dated* some time in 1982. > > Since the message will not contain *any* authoritative sent dates at > that point, I disagree. The authoritative date is the Date header which says 1982. That's what the sending mail program said, and I believe it. Just because its human is an ass doesn't change that. The human needs to be notified, sure. > what protocol would you *suggest*, for having it archived > as being sent yesterday, the way you'd like? That's my point: it's *not* the way I'd like. I'm not suggesting any protocol. The problem doesn't need any solution, for me. I'd suggest that the only two meaningful dates are: 1) Date: header 2) date/time of arrival at the archiver All else is sophistry. > > Right. I'm talking about the archiver too. > > I just wanted to point out that opinions differ. > > Certainly... but I don't necessarily see that you've posited a > *solution*, just an opinion. Who said anything about a solution? I started this thread, I think, by stating an opinion about the behavior I'd like. From jra@baylink.com Tue May 1 23:04:54 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 18:04:54 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF31AA.22A4CCBE@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 02:59:06PM -0700 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> Message-ID: <20010501180454.13332@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 02:59:06PM -0700, Dan Mick wrote: > > > Right. But if it's archived as "today" when it was sent "yesterday", > > > that's not the bahavior I would ever want, even if the Date: header is > > > correct in the archive. > > > > Ok, but the situation we're discussing here is when it was sent > > yesterday, and received yesterday, but *dated* some time in 1982. > > > > Since the message will not contain *any* authoritative sent dates at > > that point, > > I disagree. The authoritative date is the Date header which says 1982. > That's what the sending mail program said, and I believe it. Just > because its human is an ass doesn't change that. The human needs to be > notified, sure. I guess we'll have to agree to disagree, then. If that date is *wrong*, it's *wrong*. That it was applied by the sending MUA does *not* make it automatically authoritative; timestamps are an absolute -- there *is* a standard. > > what protocol would you *suggest*, for having it archived > > as being sent yesterday, the way you'd like? > > That's my point: it's *not* the way I'd like. I'm not suggesting > any protocol. The problem doesn't need any solution, for me. Fine. Then turn those switches off. You're in a minority, many other people hate having *incorrect* (and they are incorrect -- those messages were *not* sent in 1982) archives. > I'd suggest that the only two meaningful dates are: > > 1) Date: header > 2) date/time of arrival at the archiver > > All else is sophistry. Hmmm... isn't that what we said? And no, "time sent by the sender" is a meaningful date as well... *even if* it's not correctly represented by the header. > > > Right. I'm talking about the archiver too. > > > I just wanted to point out that opinions differ. > > > > Certainly... but I don't necessarily see that you've posited a > > *solution*, just an opinion. > > Who said anything about a solution? I started this thread, I think, by > stating an opinion about the behavior I'd like. Funny... I thought Barry'd started it. I'll have to go back and look. But regardless, I concur with Barry and the other people who called it a problem, and I think a solution is in order. Barry's solution has an on-off switch. If you think that this is not a problem *to the people for whom you maintain an archive*, then shut that switch off. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jj-list@mail.dk Tue May 1 22:30:49 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Tue, 01 May 2001 23:30:49 +0200 Subject: [Mailman-Developers] Delivering messages to scripts/post In-Reply-To: <2079.988675154@kanga.nu> References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <5.1.0.14.0.20010501232421.00bb7fa0@pop3.mail.dk> I wrote: > > We chaned to Mailman because we needed some things LISTSERV didn't > > have. J C Lawrence asked: >Like what? (might as well pump up our strengths) LISTSERV probably has the most features, but what I meant was that we now have the option of changing whatever we want to. Some messages/responses are still hard-coded into LISTSERV. The same is true for Mailman, but in Mailman I can choose to modify the source - you cannot beat that ;) Jesper. From jj-list@mail.dk Tue May 1 23:01:01 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Wed, 02 May 2001 00:01:01 +0200 Subject: [Mailman-Developers] Delivering messages to scripts/post In-Reply-To: <15086.14742.421568.853743@anthem.wooz.org> References: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> Message-ID: <5.1.0.14.0.20010501233124.03aab010@pop3.mail.dk> Barry A. Warsaw wrote: >What version of Mailman are you running? I'd be interested in looking >at any patches that help port Mailman to Windows (or any other >platform for that matter). I develop on Linux these days, and before >leaving CNRI, primarily Solaris. I'm fairly confident Mailman runs on >any (sane :) Unix-like OS, and I have nothing philosophical against >porting Mailman to any platform that Python runs on -- and that's a >lot of platforms. But I don't have much time to do that work myself, >so such porting necessarily relies on contributions from others. Mailman 2.0.3, but it will work with 2.0.4 if only changes to qrunner was made there. I am completely new to the world of sourceforge and cvs and patches and other joys it may bring. Right now my only weapon is a python script that modies Mailman to run on Windows. But using the cvs patch system is probably a good idea and I will try to go that way instead. Barry A. Warsaw wrote: >This should actually be better for Python 2.1 since the >case-sensitivity on imports for case-preserving case-insensitive file >systems (e.g. Windows) has been greatly improved (I've been told). I >thought about renaming Mailbox.py, but that's a PITA because I don't >want to lose the CVS history and renaming-retaining-history can't be >done without access to the CVS repository. I'll probably just require >MacOSX and Cygwin (and Windows :) users to use to Python 2.1. >Everyone else should be fine with Python 2.0 or 2.1. That sounds great, time for another upgrade then ;) Barry A. Warsaw wrote: >In the usual Unix MTA world, nothing, it's a dumb pipe. Mailman >itself looks at the incoming message for X-BeenThere headers and >raises a LoopError if it finds one that matches the list address. >There's no guarantee that'll be preserved during the loop though, and >in that case there isn't much that can be done. I know LISTSERV would refuse two messages with similar text sent to the same list. Or that is, the first message is sent to the list and all following messages with similar text are rejected. I don't know if this was a word by word comparison or a message size comparison. Has something similar been discussed for Mailman? Or maybe I am making a bigger issue out of this than it is. I am just terrified, that one morning I will find out, that one of the lists has been talking with some auto-reply system all night long. Jesper. From dan.mick@west.sun.com Tue May 1 23:16:27 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 01 May 2001 15:16:27 -0700 Subject: [Mailman-Developers] Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> Message-ID: <3AEF35BB.314D0EB6@west.sun.com> > > I disagree. The authoritative date is the Date header which says 1982. > > That's what the sending mail program said, and I believe it. Just > > because its human is an ass doesn't change that. The human needs to be > > notified, sure. > > I guess we'll have to agree to disagree, then. Jay, that was the point of my original post. Why are you worrying me like a dog with rawhide on this one? I'm not something you have to topple, I'm just stating my opinion. > > I'd suggest that the only two meaningful dates are: > > > > 1) Date: header > > 2) date/time of arrival at the archiver > > > > All else is sophistry. > > Hmmm... isn't that what we said? I don't know. There was a hell of a lot of discussion about Received headers and moderation delays, and I think it's wasted effort. I was mostly ignoring that conversation, but I stopped to offer an opinion-on-the-way-to-what-I'd-do-as-solution, since you seemed to be haranguing me for one. > And no, "time sent by the sender" is a meaningful date as well... *even > if* it's not correctly represented by the header. But there's no way to measure that with any accuracy at all except the Date: header, which can be wrong, but shouldn't be. All else is sophistry. > > Who said anything about a solution? I started this thread, I think, by > > stating an opinion about the behavior I'd like. > > Funny... I thought Barry'd started it. I'll have to go back and look. I started the thread titled Dates, today. > But regardless, I concur with Barry and the other people who called it > a problem, and I think a solution is in order. Barry's solution has an > on-off switch. If you think that this is not a problem *to the people > for whom you maintain an archive*, then shut that switch off. Well, duh, Jay. Again, I don't know why you think I don't understand that, or that I'm recommending any behavior for you or anyone else. I'm merely offering an opinion. Stop being so threatened by that. From dgc@uchicago.edu Tue May 1 23:21:29 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 1 May 2001 17:21:29 -0500 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501180454.13332@scfn.thpl.lib.fl.us>; from jra@baylink.com on Tue, May 01, 2001 at 06:04:54PM -0400 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> Message-ID: <20010501172129.P29821@smack.uchicago.edu> On 2001.05.01, in <20010501180454.13332@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > If that date is *wrong*, it's *wrong*. That it was applied by the > sending MUA does *not* make it automatically authoritative; timestamps > are an absolute -- there *is* a standard. But it's not the MLM's business to judge whether a Date: header is correct. How would it possibly know? You're discussing ways to make a correct guess in most cases, but not a way to ensure correct information in all cases. > Fine. Then turn those switches off. You're in a minority, many other > people hate having *incorrect* (and they are incorrect -- those messages I don't think the discussion thus far is sufficient to say who's a minority, and I don't think that's relevant. What matters is that Barry seems to agree with you, and that not one has proposed a way to make everyone happy. > people hate having *incorrect* (and they are incorrect -- those messages > were *not* sent in 1982) archives. Suppose I send a message on May 12, 2001, and my mail system goes down before it gets out. My mail system isn't back up for 10 days, but they my message hits the list with its old, but correct, Date: header. My outbound mail was still sent on May 12, no matter that it's not within 7 days of May 12 anymore. This approach to the hypothetical problem doesn't cover all cases, just the majority of cases where there's damage due to misconfiguration. Maybe that's good enough, maybe not; but I agree with Dan that varying opinions and wishes may be pointed out. -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Tue May 1 23:24:41 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 18:24:41 -0400 Subject: [Mailman-Developers] Dates In-Reply-To: <3AEF35BB.314D0EB6@west.sun.com>; from Dan Mick on Tue, May 01, 2001 at 03:16:27PM -0700 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <3AEF35BB.314D0EB6@west.sun.com> Message-ID: <20010501182441.38183@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 03:16:27PM -0700, Dan Mick wrote: > > I guess we'll have to agree to disagree, then. > > Jay, that was the point of my original post. Why are you worrying me like > a dog with rawhide on this one? I'm not something you have to topple, > I'm just stating my opinion. Hmmm... I guess, Dan, that I'll have to go re-read the thread. It seemed to me like you were popping up in the middle of a "how should we fix this" thread with "don't". > > Hmmm... isn't that what we said? > > I don't know. There was a hell of a lot of discussion about Received headers > and moderation delays, and I think it's wasted effort. I was mostly ignoring > that conversation, but I stopped to offer an > opinion-on-the-way-to-what-I'd-do-as-solution, since you seemed to be > haranguing me for one. Hmmm... > > And no, "time sent by the sender" is a meaningful date as well... *even > > if* it's not correctly represented by the header. > > But there's no way to measure that with any accuracy at all except the > Date: header, which can be wrong, but shouldn't be. All else is sophistry. That it can't accurately be measured does not make it immaterial; to so assert is also sophistry. :-) > > Funny... I thought Barry'd started it. I'll have to go back and look. > > I started the thread titled Dates, today. Congratulations. But that wasn't the thread that started the discussion of the topic; that one was "2006 Messages in Archives". And it wasn't Barry, as it happens, it was Ousmane Wilane. > > But regardless, I concur with Barry and the other people who called it > > a problem, and I think a solution is in order. Barry's solution has an > > on-off switch. If you think that this is not a problem *to the people > > for whom you maintain an archive*, then shut that switch off. > > Well, duh, Jay. Again, I don't know why you think I don't understand that, > or that I'm recommending any behavior for you or anyone else. I'm merely > offering an opinion. Stop being so threatened by that. I sounded threatened? I thought you didn't understand that because your postings made it sound like you didn't understand that. The *real* problem, as I mentioned above, is that you started a new thread for no particularly apparent reason; we were *already talking about this*, in a thread that, as my memory had led me to expect, *started the day before your posting*. So quit snarking at me, especially since you're having to invent reasons to do so. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Tue May 1 23:35:41 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 18:35:41 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501172129.P29821@smack.uchicago.edu>; from David Champion on Tue, May 01, 2001 at 05:21:29PM -0500 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> Message-ID: <20010501183541.06693@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 05:21:29PM -0500, David Champion wrote: > On 2001.05.01, in <20010501180454.13332@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > If that date is *wrong*, it's *wrong*. That it was applied by the > > sending MUA does *not* make it automatically authoritative; timestamps > > are an absolute -- there *is* a standard. > > But it's not the MLM's business to judge whether a Date: header is > correct. How would it possibly know? You're discussing ways to make a > correct guess in most cases, but not a way to ensure correct > information in all cases. Stipulated. But we're not rewriting for retransmission, only to keep the archives clean; right, Barry? > > Fine. Then turn those switches off. You're in a minority, many other > > people hate having *incorrect* (and they are incorrect -- those messages > > I don't think the discussion thus far is sufficient to say who's a > minority, and I don't think that's relevant. What matters is that > Barry seems to agree with you, and that not one has proposed a way to > make everyone happy. Well, it's a matter of personal taste, to some degree... but we could always dig up Einar Stefferud and Marshall Rose, and see what they think. But as it happens, I agree with Barry, not the other way round. > > people hate having *incorrect* (and they are incorrect -- those messages > > were *not* sent in 1982) archives. > > Suppose I send a message on May 12, 2001, and my mail system goes down > before it gets out. My mail system isn't back up for 10 days, but they > my message hits the list with its old, but correct, Date: header. My > outbound mail was still sent on May 12, no matter that it's not within > 7 days of May 12 anymore. Hmmm... to my annoyance (:-), RFC 2822 agrees with you. Date: is the time that the message was "approved for transmission" by the writer, not the time it was actually injected. Now, while I don't think the standard actually *says* (section 3.3 certainly doesn't), *I* would personally assert that that field is invalid if the clock it was generated from isn't within *some* reasonable percentage of accurate (for a machine which is continuously connected to the Internet, I'd call that a second or so; for a machine *regularly* connected, probably 30-45 seconds). > This approach to the hypothetical problem doesn't cover all cases, just > the majority of cases where there's damage due to misconfiguration. Where damage can be interpreted as "people getting annoyed about the behaviours of others based on messages with incorrect time stamps"? > Maybe that's good enough, maybe not; but I agree with Dan that varying > opinions and wishes may be pointed out. I wasn't trying to suggest otherwise. What I *can* be construed as trying to suggest is that, since the proposed solution can be switched on and off at will, popping up with "Well, *I* don't think it needs to be fixed cause I don't think it's a problem" seems, at best, not especially productive. Particularly in light of the fact that *it's already done*. (I was going to apologize for the phrasing of that, but given Dan's tone in his last posting to me, it doesn't seem worth the effort.) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From dgc@uchicago.edu Tue May 1 23:52:08 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 1 May 2001 17:52:08 -0500 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501183541.06693@scfn.thpl.lib.fl.us>; from jra@baylink.com on Tue, May 01, 2001 at 06:35:41PM -0400 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> Message-ID: <20010501175208.T29821@smack.uchicago.edu> On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > correct. How would it possibly know? You're discussing ways to make a > > correct guess in most cases, but not a way to ensure correct > > information in all cases. > > Stipulated. But we're not rewriting for retransmission, only to keep > the archives clean; right, Barry? That's what I understand, too. My personal taste is that an archive reflect with complete accuracy and fidelity what was received from the transmitter -- not the recipient's interpretation thereof. This is only relevant to particulars of implementation, though, not to whether the general solution is applied at all. For example, I think it's more appropriate to leave the default at "don't munge incoming mail at all". > > > Fine. Then turn those switches off. You're in a minority, many other > > > people hate having *incorrect* (and they are incorrect -- those messages > > > > I don't think the discussion thus far is sufficient to say who's a > > minority, and I don't think that's relevant. What matters is that > > Barry seems to agree with you, and that not one has proposed a way to > > make everyone happy. > > Well, it's a matter of personal taste, to some degree... but we could > always dig up Einar Stefferud and Marshall Rose, and see what they > think. > > But as it happens, I agree with Barry, not the other way round. Fine. I suppose I used "agree" in the sense of having equivalent opinion, not of changing one's mind to match another's. I tend to think of this commutatively. Since I was speaking to you, and my emphasis was on what Barry thinks rather than on what you think.... > not the time it was actually injected. Now, while I don't think the > standard actually *says* (section 3.3 certainly doesn't), *I* would > personally assert that that field is invalid if the clock it was > generated from isn't within *some* reasonable percentage of accurate > (for a machine which is continuously connected to the Internet, I'd > call that a second or so; for a machine *regularly* connected, probably > 30-45 seconds). Without looking, I would wager cash that the *standard-track* RFC doesn't specify expected transmission time. I think you perhaps expect too much of the Internet. > > This approach to the hypothetical problem doesn't cover all cases, just > > the majority of cases where there's damage due to misconfiguration. > > Where damage can be interpreted as "people getting annoyed about the > behaviours of others based on messages with incorrect time stamps"? Where "damage" means "undesired harm or inconvenience". > I wasn't trying to suggest otherwise. What I *can* be construed as > trying to suggest is that, since the proposed solution can be switched > on and off at will, popping up with "Well, *I* don't think it needs to > be fixed cause I don't think it's a problem" seems, at best, not > especially productive. Particularly in light of the fact that *it's > already done*. I disagree, but we can each choose our crusades. -- -D. dgc@uchicago.edu NSIT University of Chicago From otaylor@redhat.com Wed May 2 02:24:59 2001 From: otaylor@redhat.com (Owen Taylor) Date: 01 May 2001 21:24:59 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: David Champion's message of "Tue, 1 May 2001 17:52:08 -0500" References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> Message-ID: David Champion writes: > On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > > correct. How would it possibly know? You're discussing ways to make a > > > correct guess in most cases, but not a way to ensure correct > > > information in all cases. > > > > Stipulated. But we're not rewriting for retransmission, only to keep > > the archives clean; right, Barry? > > That's what I understand, too. My personal taste is that an archive > reflect with complete accuracy and fidelity what was received from the > transmitter -- not the recipient's interpretation thereof. This is > only relevant to particulars of implementation, though, not to whether > the general solution is applied at all. For example, I think it's more > appropriate to leave the default at "don't munge incoming mail at > all". At the risk of prolonging this discussion, it may be worth pointing out that there are two different "dates" here: 1) The date in the Date: field displayed in the archive 2) The date used for sorting and for splitting archives by month/year. I'm of the opinion that 1) should always be the same date as generated by the MUA, but that using that date for 2) is, from experience, a bad idea, because some user's machines will have badly screwed up clocks, and you get archive volumes for ridiculous periods, etc. Currently, Mailman, currently, always uses the same date for both 1) and 2) - either the MUA date, or the date when the mail passed through mailman. From my perspective, arguing about which one of these is superior is somewhat pointless, since as soon as you use the same date for both, you are going to have problems. Regards, Owen From barry@digicool.com Wed May 2 04:02:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 1 May 2001 23:02:19 -0400 Subject: [Mailman-Developers] Re: Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> Message-ID: <15087.30907.613868.332848@anthem.wooz.org> Phew! A little thing like dates gets us geeks in an uproar. Whodathunk? :) First, Mailman will not rewrite Date: headers for messages exploded to the list. I'm a firm believer in the least-munging rule. If the message gets sent out dated in 1982, then that's what the recipients will see. So that one's off the table. Second, /all/ we're talking about is placing the article in the archives. Ideally, the original Date: header would be preserved in the archive. But on the other hand, it really doesn't help people find information when a message is placed 8 years into the future. Mailman's current approach is less than ideal, and I think the right thing to do is for the archiver to put some sanity checks on the date for collation purposes. What Mailman and the receiving MTA can do is to mark the message with at least one date it can trust -- the date it received the message (if that server's clock is broken then oh well). So, forgetting about Mailman and Pipermail right now, what do archivers like MHonArc do when handed a message dated way in the future or way in the past? Do they dutifully put the message in the April 2006 bin? I'm not worried about messages that are a few days off, I'm much more concerned about messages that are /years/ off. I think what I will do is leave things the way they are currently, which gives Mailman the opportunity to be tuned to the archiver being used. Pipermail is dumb in the sense that it doesn't sanity check the Date:, and I can live with the fact that the Date: header in the archive won't be the original Date: header. People will still see the original Date: header in the message they receive from the list (via regular or digest delivery). If Pipermail is fixed, we can change the default to not munge Date: for the archiver, but it's not high on my priority list. The site admin can easily change the setting if they use an archiver that has better behavior. -Barry From jra@baylink.com Wed May 2 04:55:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 23:55:15 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: ; from Owen Taylor on Tue, May 01, 2001 at 09:24:59PM -0400 References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> Message-ID: <20010501235515.21932@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 09:24:59PM -0400, Owen Taylor wrote: > David Champion writes: > > On 2001.05.01, in <20010501183541.06693@scfn.thpl.lib.fl.us>, > > "Jay R. Ashworth" wrote: > > > > correct. How would it possibly know? You're discussing ways to make a > > > > correct guess in most cases, but not a way to ensure correct > > > > information in all cases. > > > > > > Stipulated. But we're not rewriting for retransmission, only to keep > > > the archives clean; right, Barry? > > > > That's what I understand, too. My personal taste is that an archive > > reflect with complete accuracy and fidelity what was received from the > > transmitter -- not the recipient's interpretation thereof. This is > > only relevant to particulars of implementation, though, not to whether > > the general solution is applied at all. For example, I think it's more > > appropriate to leave the default at "don't munge incoming mail at > > all". > > At the risk of prolonging this discussion, it may be worth pointing > out that there are two different "dates" here: > > 1) The date in the Date: field displayed in the archive > > 2) The date used for sorting and for splitting archives by > month/year. > > I'm of the opinion that 1) should always be the same date as generated > by the MUA, but that using that date for 2) is, from experience, a bad > idea, because some user's machines will have badly screwed up clocks, > and you get archive volumes for ridiculous periods, etc. I think we're all in violent agreement on that point... except maybe Dan; I can't speak for him, obviously. :-} > Currently, Mailman, currently, always uses the same date for both 1) > and 2) - either the MUA date, or the date when the mail passed through > mailman. From my perspective, arguing about which one of these > is superior is somewhat pointless, since as soon as you use the > same date for both, you are going to have problems. Well, and I think that's where we started. IIRC, Barry {was planning, thinking about, suggesting, had already written} code that rewrote 1 as 2 if it was too far out of whack, because it was easier to fix it there codewise than splitting them. [ Checks local archive } If I correctly understand where clobber_date is called in the flow of things, that paragraph is correct. And therefore, not the best approach, by concensus, apparently. Barry? Have I misunderstood you? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 04:57:54 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 23:57:54 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.30907.613868.332848@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, May 01, 2001 at 11:02:19PM -0400 References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> Message-ID: <20010501235754.34947@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 11:02:19PM -0400, Barry A. Warsaw wrote: > Phew! A little thing like dates gets us geeks in an uproar. > Whodathunk? :) Timestamps are fun things to fight about. :-) > First, Mailman will not rewrite Date: headers for messages exploded to > the list. I'm a firm believer in the least-munging rule. If the > message gets sent out dated in 1982, then that's what the recipients > will see. So that one's off the table. Outdating the message I *just* sent. Crap. I know better than not to "read everything before doing anything". > Second, /all/ we're talking about is placing the article in the > archives. Ideally, the original Date: header would be preserved in > the archive. But on the other hand, it really doesn't help people > find information when a message is placed 8 years into the future. Rog. Ok. > I'm not worried about messages that are a few days off, I'm much more > concerned about messages that are /years/ off. Indeed... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 04:59:50 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 1 May 2001 23:59:50 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501235754.34947@scfn.thpl.lib.fl.us>; from "Jay R. Ashworth" on Tue, May 01, 2001 at 11:57:54PM -0400 References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> Message-ID: <20010501235950.25781@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 11:57:54PM -0400, Jay R. Ashworth wrote: > Timestamps are fun things to fight about. :-) But only pedagogically. My apologies to Dan Mick and anyone else who took my postings earlier today personally. Cheers, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 05:10:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:10:30 -0400 Subject: [Mailman-Developers] Re: Dates References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> Message-ID: <15087.34998.85554.151195@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Well, and I think that's where we started. IIRC, Barry {was JRA> planning, thinking about, suggesting, had already written} JRA> code that rewrote 1 as 2 if it was too far out of whack, JRA> because it was easier to fix it there codewise than splitting JRA> them. JRA> [ Checks local archive } JRA> If I correctly understand where clobber_date is called in the JRA> flow of things, that paragraph is correct. JRA> And therefore, not the best approach, by concensus, JRA> apparently. Barry? Have I misunderstood you? If ARCHIVER_CLOBBER_DATE_POLICY is 1 (or 2, and the date is too far out-of-whack), then yes, the Date: header for the copy of the message being passed to the archiver gets munged. IMO, the archiver ought to be doing any date clobbering, but Pipermail is too painful to fix. Again, what do other external archivers do? I.e. if you passed an outrageously dated message to MHonArc, would it dutifully put the message in the April 2006 slot? The current approach has one hole, which would be easy to fix if it's useful. Mailman could mark the message with an `authoritatively received date' using some X-* header leaving the original Date: header alone. Then the archiver could use that date to slot the message regardless of what the Date: header said. I'm not sure this is worth it though because 1) there's no standard that I'm aware of that would let archivers and list managers/MTAs cooperate; 2) the date Mailman would stamp the message wouldn't be /that/ far off of the date the archiver got handed the message anyway, so the archiver can always do whatever it wants with dates and it'll be close enough; 3) the most recent Received: header is probably close enough so that it could be used as the `authoritatively received date' as has been suggested. I think we're good enough. If you don't like Date: header munging and have an archiver that handles outrageous dates itself, just set ARCHIVER_CLOBBER_DATE_POLICY to 0 and Mailman will pass the copy of the message to the archiver unblemished. -Barry From barry@digicool.com Wed May 2 05:11:53 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:11:53 -0400 Subject: [Mailman-Developers] Re: Dates References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> Message-ID: <15087.35081.828727.683975@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Outdating the message I *just* sent. Crap. I know better JRA> than not to "read everything before doing anything". It's that kind of thinking that got me 2300 messages in my inbox. :) -Barry From jra@baylink.com Wed May 2 05:14:09 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 00:14:09 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.35081.828727.683975@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 12:11:53AM -0400 References: <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> Message-ID: <20010502001409.25022@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 12:11:53AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> Outdating the message I *just* sent. Crap. I know better > JRA> than not to "read everything before doing anything". > > It's that kind of thinking that got me 2300 messages in my inbox. :) How many mailing lists, how many days? I can do 2300 in about a week... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 05:19:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 00:19:15 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.34998.85554.151195@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 12:10:30AM -0400 References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> <15087.34998.85554.151195@anthem.wooz.org> Message-ID: <20010502001915.28176@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 12:10:30AM -0400, Barry A. Warsaw wrote: > JRA> And therefore, not the best approach, by concensus, > JRA> apparently. Barry? Have I misunderstood you? > > If ARCHIVER_CLOBBER_DATE_POLICY is 1 (or 2, and the date is too far > out-of-whack), then yes, the Date: header for the copy of the message > being passed to the archiver gets munged. > > IMO, the archiver ought to be doing any date clobbering, but Pipermail > is too painful to fix. Again, what do other external archivers do? > I.e. if you passed an outrageously dated message to MHonArc, would it > dutifully put the message in the April 2006 slot? Ok; that's what I thought I'd heard. > The current approach has one hole, which would be easy to fix if it's > useful. Mailman could mark the message with an `authoritatively > received date' using some X-* header leaving the original Date: header > alone. Then the archiver could use that date to slot the message > regardless of what the Date: header said. > > I'm not sure this is worth it though because 1) there's no standard > that I'm aware of that would let archivers and list managers/MTAs > cooperate; Rough Concensus; Working Code. (ie: *create* such a header) > 2) the date Mailman would stamp the message wouldn't be > /that/ far off of the date the archiver got handed the message anyway, > so the archiver can always do whatever it wants with dates and it'll > be close enough; 3) the most recent Received: header is probably close > enough so that it could be used as the `authoritatively received date' > as has been suggested. Assuming you can reliably decide which one to use. Can you? > I think we're good enough. If you don't like Date: header munging and > have an archiver that handles outrageous dates itself, just set > ARCHIVER_CLOBBER_DATE_POLICY to 0 and Mailman will pass the copy of > the message to the archiver unblemished. Indeed. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 05:20:51 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:20:51 -0400 Subject: [Mailman-Developers] Re: Dates References: <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> Message-ID: <15087.35619.606174.83682@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> How many mailing lists, how many days? I can do 2300 in JRA> about a week... Oh jeez, that's just the messages I've actually looked at and buried thinking "I'll get back to them". Counts digests as single messages. I'm not claiming I'm unique or even that bad in our world of geeks. I had a boss that had 30k+ messages in his inbox, and simply had his secretary just delete the whole dang thing. There's a lot to be said for "if it's important enough, they'll keep bugging me". :) -Barry From jra@baylink.com Wed May 2 05:23:14 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 00:23:14 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.35619.606174.83682@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 12:20:51AM -0400 References: <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> <15087.35619.606174.83682@anthem.wooz.org> Message-ID: <20010502002314.62121@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 12:20:51AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> How many mailing lists, how many days? I can do 2300 in > JRA> about a week... > > Oh jeez, that's just the messages I've actually looked at and buried > thinking "I'll get back to them". Counts digests as single messages. I used to have a real problem with the standing size of my inbox. I've been managing to keep it down to about 3 to 7 messages, with a little help from =todo, instead of the 30-50 it sometimes got to before. > I'm not claiming I'm unique or even that bad in our world of geeks. I > had a boss that had 30k+ messages in his inbox, and simply had his > secretary just delete the whole dang thing. There's a lot to be said > for "if it's important enough, they'll keep bugging me". :) Assuming you see it. And sometimes, they *won't* keep bugging you cause it's more important to you than it is to them. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 05:22:59 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 00:22:59 -0400 Subject: [Mailman-Developers] Re: Dates References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> <15087.34998.85554.151195@anthem.wooz.org> <20010502001915.28176@scfn.thpl.lib.fl.us> Message-ID: <15087.35747.197313.310973@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> The current approach has one hole, which would be easy to fix >> if it's useful. Mailman could mark the message with an >> `authoritatively received date' using some X-* header leaving >> the original Date: header alone. Then the archiver could use >> that date to slot the message regardless of what the Date: >> header said. I'm not sure this is worth it though because 1) >> there's no standard that I'm aware of that would let archivers >> and list managers/MTAs cooperate; JRA> Rough Concensus; Working Code. (ie: *create* such a header) Suggestion: X-List-Received-Date ? But, is it even worth it? >> 2) the date Mailman would stamp the message wouldn't be >> /that/ far off of the date the archiver got handed the message >> anyway, so the archiver can always do whatever it wants with >> dates and it'll be close enough; 3) the most recent Received: >> header is probably close enough so that it could be used as the >> `authoritatively received date' as has been suggested. JRA> Assuming you can reliably decide which one to use. Can you? Nope, which is why I rejected this suggestion for Mailman. -Barry From claw@kanga.nu Wed May 2 05:27:41 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 01 May 2001 21:27:41 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from David Champion of "Tue, 01 May 2001 17:21:29 CDT." <20010501172129.P29821@smack.uchicago.edu> References: <3AEF0D15.1258875E@west.sun.com> <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> Message-ID: <6126.988777661@kanga.nu> On Tue, 1 May 2001 17:21:29 -0500 David Champion wrote: > But it's not the MLM's business to judge whether a Date: header is > correct. How would it possibly know? You're discussing ways to > make a correct guess in most cases, but not a way to ensure > correct information in all cases. There are two interesting facts about a message: 1) The message as the author wrote it. 2) When the message arrived at the list in terms of time and in terms of list sequence. Past that, its all quibbles. Altering either one destroys historical accuracy. Bad idea. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From dgc@uchicago.edu Wed May 2 05:53:49 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 1 May 2001 23:53:49 -0500 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <15087.30907.613868.332848@anthem.wooz.org>; from barry@digicool.com on Tue, May 01, 2001 at 11:02:19PM -0400 References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> Message-ID: <20010501235349.X29821@smack.uchicago.edu> On 2001.05.01, in <15087.30907.613868.332848@anthem.wooz.org>, "Barry A. Warsaw" wrote: > > Phew! A little thing like dates gets us geeks in an uproar. > Whodathunk? :) Well, we're touching on a matter of fidelity of a record, which is what gets me concerned about it. I guess that's a kind of geekiness, but maybe a different kind. :) > First, Mailman will not rewrite Date: headers for messages exploded to > the list. I'm a firm believer in the least-munging rule. If the > message gets sent out dated in 1982, then that's what the recipients > will see. So that one's off the table. Right, and, as a comment on our comments thus far, I think it's safe to say that we all agree on it. > Second, /all/ we're talking about is placing the article in the > archives. Ideally, the original Date: header would be preserved in > the archive. But on the other hand, it really doesn't help people > find information when a message is placed 8 years into the future. > > Mailman's current approach is less than ideal, and I think the right > thing to do is for the archiver to put some sanity checks on the date > for collation purposes. What Mailman and the receiving MTA can do is Here we brush by the unspoken third approach to the problem. Rather than altering the date in the copy of the message fed to the archiver, Mailman can feed the "correct" date out-of-band. The archiver can use this altered date, as you say, for collation, but retain the original Date: header for the archive itself. This is certainly more trouble to implement, and arguably infeasible since it could involve modification of the (external?) archiver, but I think it best meets all interests. I'd also like to offer that although, for example, PGP/MIME (and other, nonstandard, PGP message encodings for e-mail) does not sign the Date: field along with the message itself, this is not an unreasonable thing for some alternative or future signature format to do. That's just another reason that altering the archival contents themselves strikes me as a Bad Thing, even though altering the way the message is collated or indexed is fine. -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Wed May 2 06:02:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 01:02:15 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <20010501235349.X29821@smack.uchicago.edu>; from David Champion on Tue, May 01, 2001 at 11:53:49PM -0500 References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235349.X29821@smack.uchicago.edu> Message-ID: <20010502010215.17217@scfn.thpl.lib.fl.us> On Tue, May 01, 2001 at 11:53:49PM -0500, David Champion wrote: > On 2001.05.01, in <15087.30907.613868.332848@anthem.wooz.org>, > "Barry A. Warsaw" wrote: > > Phew! A little thing like dates gets us geeks in an uproar. > > Whodathunk? :) > > Well, we're touching on a matter of fidelity of a record, which is what > gets me concerned about it. I guess that's a kind of geekiness, but > maybe a different kind. :) Indeed we are. Both sides, in different ways. > > Second, /all/ we're talking about is placing the article in the > > archives. Ideally, the original Date: header would be preserved in > > the archive. But on the other hand, it really doesn't help people > > find information when a message is placed 8 years into the future. > > > > Mailman's current approach is less than ideal, and I think the right > > thing to do is for the archiver to put some sanity checks on the date > > for collation purposes. What Mailman and the receiving MTA can do is > > Here we brush by the unspoken third approach to the problem. Rather > than altering the date in the copy of the message fed to the archiver, > Mailman can feed the "correct" date out-of-band. The archiver can use > this altered date, as you say, for collation, but retain the original > Date: header for the archive itself. As Barry suggested. > This is certainly more trouble to implement, and arguably infeasible > since it could involve modification of the (external?) archiver, but I > think it best meets all interests. It does that. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Wed May 2 09:39:18 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 01:39:18 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 02 May 2001 00:19:15 EDT." <20010502001915.28176@scfn.thpl.lib.fl.us> References: <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <20010501235515.21932@scfn.thpl.lib.fl.us> <15087.34998.85554.151195@anthem.wooz.org> <20010502001915.28176@scfn.thpl.lib.fl.us> Message-ID: <1446.988792758@kanga.nu> On Wed, 2 May 2001 00:19:15 -0400 Jay R Ashworth wrote: > On Wed, May 02, 2001 at 12:10:30AM -0400, Barry A. Warsaw wrote: JRA> And therefore, not the best approach, by concensus, apparently. JRA> Barry? Have I misunderstood you? >> IMO, the archiver ought to be doing any date clobbering, but >> Pipermail is too painful to fix. Again, what do other external >> archivers do? I.e. if you passed an outrageously dated message >> to MHonArc, would it dutifully put the message in the April 2006 >> slot? > Ok; that's what I thought I'd heard. That is what it does (and what I want). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Wed May 2 09:44:27 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 01:44:27 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 02 May 2001 00:20:51 EDT." <15087.35619.606174.83682@anthem.wooz.org> References: <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> <15087.35619.606174.83682@anthem.wooz.org> Message-ID: <10970.988793067@kanga.nu> On Wed, 2 May 2001 00:20:51 -0400 Barry A Warsaw wrote: >>>>>> "JRA" == Jay R Ashworth writes: JRA> How many mailing lists, how many days? I can do 2300 in about JRA> a week... > Oh jeez, that's just the messages I've actually looked at and > buried thinking "I'll get back to them". Counts digests as single > messages. I average around 2,500 to 3,000 messages a day here (no digests). Tonight I've managed to work my unread counter down from 11,000 and something to 4549. Doing good. > I'm not claiming I'm unique or even that bad in our world of > geeks. I had a boss that had 30k+ messages in his inbox, and > simply had his secretary just delete the whole dang thing. > There's a lot to be said for "if it's important enough, they'll > keep bugging me". :) Procmail is your friend. One of the thing I do occassionally is relegate lists to the background. I then have procmail search the messages it files to their per-list folders for matches to key-word lists, and then files a second copy in my folder. Then, to have procmail auto-file that thread and all future replies into the interesting folder, I have it watch and maintain a timestamped database of MessageIDs which are then scanned for in the In-Reply-To and References: headers. Works quite nicely. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From sillygod@hotmail.com Wed May 2 12:59:20 2001 From: sillygod@hotmail.com (SillyGod) Date: Wed, 2 May 2001 07:59:20 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0D2DD.CB7DAB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, Please, could someone advise me if there is still an issue with using = case-sensitive e-mail addresses with mailman? ie. john.doe@email.com vs. = John.Doe@email.com would both get delivered? Or would the case-incorrect = version bounce? Thanks! *Larry* ------=_NextPart_000_0007_01C0D2DD.CB7DAB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
              Hello All,
               
              Please, could someone advise me if = there is still=20 an issue with using case-sensitive e-mail addresses with mailman? ie. john.doe@email.com vs. John.Doe@email.com would both get = delivered? Or would the case-incorrect version bounce?
               
              Thanks!
               
              *Larry*
              ------=_NextPart_000_0007_01C0D2DD.CB7DAB70-- From barry@digicool.com Wed May 2 14:48:26 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 09:48:26 -0400 Subject: [Mailman-Developers] Re: Dates References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235349.X29821@smack.uchicago.edu> Message-ID: <15088.4139.451332.213714@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> Here we brush by the unspoken third approach to the problem. DC> Rather than altering the date in the copy of the message fed DC> to the archiver, Mailman can feed the "correct" date DC> out-of-band. The archiver can use this altered date, as you DC> say, for collation, but retain the original Date: header for DC> the archive itself. Read "out-of-band" as "add-a-header" and I can agree. Okay, if the original Date: header isn't clobbered, I'll add the X-List-Received-Date: header to the copy of the message that the archiver gets. So you get the behavior you want by setting ARCHIVER_CLOBBER_DATE_POLICY to 0. -Barry From jra@baylink.com Wed May 2 15:12:08 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 10:12:08 -0400 Subject: [Mailman-Developers] Re: Dates In-Reply-To: <10970.988793067@kanga.nu>; from J C Lawrence on Wed, May 02, 2001 at 01:44:27AM -0700 References: <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235754.34947@scfn.thpl.lib.fl.us> <15087.35081.828727.683975@anthem.wooz.org> <20010502001409.25022@scfn.thpl.lib.fl.us> <15087.35619.606174.83682@anthem.wooz.org> <10970.988793067@kanga.nu> Message-ID: <20010502101208.60346@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 01:44:27AM -0700, J C Lawrence wrote: > > Oh jeez, that's just the messages I've actually looked at and > > buried thinking "I'll get back to them". Counts digests as single > > messages. > > I average around 2,500 to 3,000 messages a day here (no digests). > Tonight I've managed to work my unread counter down from 11,000 and > something to 4549. Doing good. For you, Carnage, I'm not surprised... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 15:17:37 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 10:17:37 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: Message-ID: <15088.5889.875850.110383@anthem.wooz.org> >>>>> "S" == SillyGod writes: S> Please, could someone advise me if there is still an issue with S> using case-sensitive e-mail addresses with mailman? S> ie. john.doe@email.com vs. John.Doe@email.com would both get S> delivered? Or would the case-incorrect version bounce? Mailman is case-preserving case-insensitive w.r.t. email addresses. What this means is that you cannot subscribe both john.doe@email.com and John.Doe@email.com; they are considered the same address for memebership purposes. However, Mailman will case-preserve the username part of the address, so that if you subscribe John.Doe@email.com, messages will be sent to John.Doe@email.com and not john.doe@email.com. -Barry From jra@baylink.com Wed May 2 15:19:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 10:19:15 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: ; from SillyGod on Wed, May 02, 2001 at 07:59:20AM -0400 References: Message-ID: <20010502101915.39202@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 07:59:20AM -0400, SillyGod wrote: > Please, could someone advise me if there is still an issue with using > case-sensitive e-mail addresses with mailman? ie. john.doe@email.com vs. > John.Doe@email.com would both get delivered? Or would the case-incorrect > version bounce? The *right hand side* of a mailbox name (which is what we're actually talking about here) is case-insensitive because it's a DNS name, and *DNS*, in turn, is case-insensitive. The *left hand side* (the "username"), OTOH, must be treated as case-sensitive, because whether it actually *is*, or not, is system-dependent... and the "system" in question is the final target mail server -- in general, I believe that Unix machines are case-sensitive and Windows ones are not, as is usually the case, but I don't know Exchange, nor non-Sendmail Unix MTA's, well enough to guarantee that. Interestingly, RFC 2822 appears silent on this point, making the *third* thing this week it's been silent on to my surprise. Hmmm... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 15:27:06 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 10:27:06 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.5889.875850.110383@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 10:17:37AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> Message-ID: <20010502102706.41364@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 10:17:37AM -0400, Barry A. Warsaw wrote: > >>>>> "S" == SillyGod writes: > S> Please, could someone advise me if there is still an issue with > S> using case-sensitive e-mail addresses with mailman? > S> ie. john.doe@email.com vs. John.Doe@email.com would both get > S> delivered? Or would the case-incorrect version bounce? > > Mailman is case-preserving case-insensitive w.r.t. email addresses. > > What this means is that you cannot subscribe both john.doe@email.com > and John.Doe@email.com; they are considered the same address for > memebership purposes. Ok... since I know that LHS's are supposed to be treated as if they *might* be case-sensitive, I dug further. The controlling paragraphs are 2.4 and 4.1.2 in RFC 2821, both of which specify that a local-part may be case sensitive. IE: oops. :-} Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 16:02:38 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 11:02:38 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> Message-ID: <15088.8590.513944.540403@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> The controlling paragraphs are 2.4 and 4.1.2 in RFC 2821, JRA> both of which specify that a local-part may be case JRA> sensitive. JRA> IE: oops. :-} No oops on Mailman's part! We case preserve for the benefit of the receiving smtpds, but I think it's perfectly valid for Mailman to case-fold subscription keys. -Barry From jra@baylink.com Wed May 2 16:05:18 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:05:18 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.8590.513944.540403@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 11:02:38AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> Message-ID: <20010502110518.45171@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 11:02:38AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> The controlling paragraphs are 2.4 and 4.1.2 in RFC 2821, > JRA> both of which specify that a local-part may be case > JRA> sensitive. > > JRA> IE: oops. :-} > > No oops on Mailman's part! We case preserve for the benefit of the > receiving smtpds, but I think it's perfectly valid for Mailman to > case-fold subscription keys. I'm afraid I must disagree: that section of 2821 implies that John.Doe@example.com and john.doe@example.com *may be separate mailboxes*. Admittedly, it's a corner case, and very unlikely ever to bite us, but doing it that was *does* violate the standard. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 16:10:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 11:10:31 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> Message-ID: <15088.9063.1167.736985@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> I'm afraid I must disagree: that section of 2821 implies that | John.Doe@example.com | and | john.doe@example.com JRA> *may be separate mailboxes*. I understand that. JRA> Admittedly, it's a corner case, and very unlikely ever to JRA> bite us, but doing it that was *does* violate the standard. Except that Mailman isn't an SMTP server, so it doesn't have to play by those rules. For a list server, I claim that allowing keys to differ only by case is confusing and needless generalization. In practice, I don't remember it ever biting us. -Barry From jra@baylink.com Wed May 2 16:13:25 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:13:25 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.9063.1167.736985@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 11:10:31AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> Message-ID: <20010502111325.45390@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 11:10:31AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> I'm afraid I must disagree: that section of 2821 implies that > > | John.Doe@example.com > | and > | john.doe@example.com > > JRA> *may be separate mailboxes*. > > I understand that. > > JRA> Admittedly, it's a corner case, and very unlikely ever to > JRA> bite us, but doing it that was *does* violate the standard. > > Except that Mailman isn't an SMTP server, so it doesn't have to play > by those rules. For a list server, I claim that allowing keys to > differ only by case is confusing and needless generalization. In > practice, I don't remember it ever biting us. No, but Mailman *is dealing with RFC[2]82{1,2} addresses, and ought to play by their rules. As I noted, it *is* a corner case; anyone who actually *does* that on a machine ought to be shot... and I wouldn't expect us to be bitten by it; being a pedant is just my *job*, damnit. Cheers, -- jr 'actually, it's an adventure' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From chuqui@plaidworks.com Wed May 2 16:26:59 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 08:26:59 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502110518.45171@scfn.thpl.lib.fl.us> Message-ID: On 5/2/01 8:05 AM, "Jay R. Ashworth" wrote: > I'm afraid I must disagree: that section of 2821 implies that > > John.Doe@example.com > and > john.doe@example.com > > *may be separate mailboxes*. Admittedly, it's a corner case, and very > unlikely ever to bite us, but doing it that was *does* violate the > standard. Sorry, I disagree. "may be" means the standard allows you to consider this as optional. That's good, because 821 made case sensistivity mandatory (and the switch shows the clear intent of the standards folks, which is moving to full case insensitivity, but they must have felt completely removing it was too big a step -- but they're telling anyone who might still have a case sensitive mailer it's time to fix it) In practice, Barry's approach is the best one. The only thing that happens if you practice case sensitivity on the user part is that users end up with multiple subscriptions, multiple copies and no clue how to fix it or what's wrong (and it's your fault, your mailer is screwed up). The rewrite of the standard makes it clear this kind of situation (John.Doe and john.doe being different people) is now optional -- and I don't know that any MLM would work cleanly if it happens (and any admin that allows it should be shot...) From jra@baylink.com Wed May 2 16:30:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:30:55 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: ; from Chuq Von Rospach on Wed, May 02, 2001 at 08:26:59AM -0700 References: <20010502110518.45171@scfn.thpl.lib.fl.us> Message-ID: <20010502113055.56791@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 08:26:59AM -0700, Chuq Von Rospach wrote: > On 5/2/01 8:05 AM, "Jay R. Ashworth" wrote: > > I'm afraid I must disagree: that section of 2821 implies that > > > > John.Doe@example.com > > and > > john.doe@example.com > > > > *may be separate mailboxes*. Admittedly, it's a corner case, and very > > unlikely ever to bite us, but doing it that was *does* violate the > > standard. > > Sorry, I disagree. "may be" means the standard allows you to consider this > as optional. That's good, because 821 made case sensistivity mandatory (and > the switch shows the clear intent of the standards folks, which is moving to > full case insensitivity, but they must have felt completely removing it was > too big a step -- but they're telling anyone who might still have a case > sensitive mailer it's time to fix it) Hmmm... Ok. If *you* think that, Chuq, I'll re-evaulate my opinion. I hadn't compared it with 821. I'm wondering why, though, they didn't make that explicit in the rewrite. > In practice, Barry's approach is the best one. The only thing that happens > if you practice case sensitivity on the user part is that users end up with > multiple subscriptions, multiple copies and no clue how to fix it or what's > wrong (and it's your fault, your mailer is screwed up). Got it. > The rewrite of the standard makes it clear this kind of situation (John.Doe > and john.doe being different people) is now optional -- and I don't know > that any MLM would work cleanly if it happens (and any admin that allows it > should be shot...) I believe I *did* evince *that* opinion, at least... :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 2 16:32:51 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 2 May 2001 11:32:51 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> <20010502111325.45390@scfn.thpl.lib.fl.us> Message-ID: <15088.10403.652262.809394@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> No, but Mailman *is dealing with RFC[2]82{1,2} addresses, and JRA> ought to play by their rules. As I noted, it *is* a corner JRA> case; anyone who actually *does* that on a machine ought to JRA> be shot... JRA> and I wouldn't expect us to be bitten by it; being a pedant JRA> is just my *job*, damnit. :) From chuqui@plaidworks.com Wed May 2 16:43:17 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 08:43:17 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502113055.56791@scfn.thpl.lib.fl.us> Message-ID: On 5/2/01 8:30 AM, "Jay R. Ashworth" wrote: > Hmmm... Ok. If *you* think that, Chuq, I'll re-evaulate my opinion. I > hadn't compared it with 821. I'm wondering why, though, they didn't > make that explicit in the rewrite. I can think of two reasons: 1) they're really codifying existing practices -- nobody was paying attention to the case sensitivity issue anyway, but in a nod to the previous standard, they didn't want to throw it out completely. It allows them to get it out of the way while still claiming (for the most part) backwards compatibility. 2) they wanted it in the standard and out the door before the fight started... (grin) In my big muther custom server, I squash everything to LC (and in fact, since my backend data store is mysql, making things case sensitive would require some significant work). I've found no cases (not few -- none) where this has caused a problem, and in fact the only time case issues come up at all is when an AOL user can't find their subscription and emails me for help and says something like "if you can't find juser@aol.com, try Juser..." I probably shouldn't squash case, really, but it simplifies dealing with this stuff somewhat, and I've found from watching the search strings that most users don't try to maintain case in their lookups anyway... Except from AOL, where it's cosmetic... I haven't really pawed through the new standard in detail, but from what I've seen, I think the intent is to say that case sensitivity is optional ("may be", not "must be"), and I think that implies that if you want to write stuff that's case sensitive on your local system, that's fine, but you can no longer assume it'll work once it leaves your control. Which is, in practice, how it's been for many years... From jra@baylink.com Wed May 2 16:47:27 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:47:27 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <15088.10403.652262.809394@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 02, 2001 at 11:32:51AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> <20010502111325.45390@scfn.thpl.lib.fl.us> <15088.10403.652262.809394@anthem.wooz.org> Message-ID: <20010502114727.57805@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 11:32:51AM -0400, Barry A. Warsaw wrote: > JRA> and I wouldn't expect us to be bitten by it; being a pedant > JRA> is just my *job*, damnit. > > :) That's an excellent attitude, Barry. I think we'll get along just fine... :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Wed May 2 16:50:09 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 2 May 2001 11:50:09 -0400 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: ; from Chuq Von Rospach on Wed, May 02, 2001 at 08:43:17AM -0700 References: <20010502113055.56791@scfn.thpl.lib.fl.us> Message-ID: <20010502115009.18635@scfn.thpl.lib.fl.us> On Wed, May 02, 2001 at 08:43:17AM -0700, Chuq Von Rospach wrote: > > Hmmm... Ok. If *you* think that, Chuq, I'll re-evaulate my opinion. I > > hadn't compared it with 821. I'm wondering why, though, they didn't > > make that explicit in the rewrite. > > I can think of two reasons: > > 1) they're really codifying existing practices -- nobody was paying > attention to the case sensitivity issue anyway, but in a nod to the previous > standard, they didn't want to throw it out completely. It allows them to get > it out of the way while still claiming (for the most part) backwards > compatibility. But is this actually true? I haven't tried it, but I thought sendmail still treated LHS's as case-sensitive... > 2) they wanted it in the standard and out the door before the fight > started... (grin) > In my big muther custom server, I squash everything to LC (and in fact, > since my backend data store is mysql, making things case sensitive would > require some significant work). I've found no cases (not few -- none) where > this has caused a problem, and in fact the only time case issues come up at > all is when an AOL user can't find their subscription and emails me for help > and says something like "if you can't find juser@aol.com, try Juser..." Hmmm... > I probably shouldn't squash case, really, but it simplifies dealing with > this stuff somewhat, and I've found from watching the search strings that > most users don't try to maintain case in their lookups anyway... Except from > AOL, where it's cosmetic... Indeed. > I haven't really pawed through the new standard in detail, but from what > I've seen, I think the intent is to say that case sensitivity is optional > ("may be", not "must be"), and I think that implies that if you want to > write stuff that's case sensitive on your local system, that's fine, but you > can no longer assume it'll work once it leaves your control. Which is, in > practice, how it's been for many years... Hmmm... *I* interpreted it to mean "someone out there might be treating this as case-sensitive, so you ought to be careful not to break their shit." But I can see your interpretation as well.. Cheers, -- jr 'be ye not overly annoying... nor too easily annoyed' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From Nigel.Metheringham@InTechnology.co.uk Wed May 2 17:01:25 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Wed, 02 May 2001 17:01:25 +0100 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 02 May 2001 11:50:09 EDT." <20010502115009.18635@scfn.thpl.lib.fl.us> Message-ID: jra@baylink.com said: > But is this actually true? I haven't tried it, but I thought sendmail > still treated LHS's as case-sensitive... Depending on your rewrite rules, sendmail can be either case sensitive or case insensitive. Exim also has a choice:- > locally_caseless > Type: boolean > Default: true > Domains in mail addresses are specified as being case-independent, but > this it not true of local parts. For most Unix systems, however, it is > desirable that local parts of local mail addresses be treated in a > case-independent manner, since most users expect that mail to OBailey > and obailey, for example, will end up in the same mailbox. By default, > when it is processing an address whose domain is local, Exim > lower-cases the local part at the start of processing, on the > assumption that account names in the password file are in lower-case. > For installations that want to draw case distinctions, this option is > provided. When turned off, local local parts are handled verbatim > during delivery. If there are names containing upper case letters in > the password file, the most convenient way to provide for caseless > mail delivery is to set up a smartuser director as the first director, > and to make it do a lowercased lookup of the local part, in order to > translate it to the correctly cased version, using the new_address > option. There is a special place in hell reserved for those that use mixed case usernames on Unix and also expect caseless operation. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From chuqui@plaidworks.com Wed May 2 17:09:03 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 09:09:03 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502115009.18635@scfn.thpl.lib.fl.us> Message-ID: On 5/2/01 8:50 AM, "Jay R. Ashworth" wrote: > But is this actually true? I haven't tried it, but I thought sendmail > still treated LHS's as case-sensitive... Not to my knowledge, and I just tested it on my system and it's not, and my config should be standard for this. A quick grep of the docs doesn't show me any documentation at all on case sensitivity, so it looks like they removed it completely at some point -- I know at one point there was an option to turn it on; that seems gone. > Hmmm... *I* interpreted it to mean "someone out there might be treating > this as case-sensitive, so you ought to be careful not to break their > shit." Not unreasonable, but compare it to the old definition. It used to be case sensitive, even though we all ignored it. Now, it may be case sensitive. The intent is clearly to make it non-mandatory. That means you can't depend on it being allowed unless you control the e-mail completely. And that means while I shouldn't arbitrarily do weird things to it simply because I can, you can no longer assume I WON'T do weird things to it, because the standard no longer tells me not to... From thomas@xs4all.net Wed May 2 18:05:40 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 2 May 2001 19:05:40 +0200 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: <20010502111325.45390@scfn.thpl.lib.fl.us>; from jra@baylink.com on Wed, May 02, 2001 at 11:13:25AM -0400 References: <15088.5889.875850.110383@anthem.wooz.org> <20010502102706.41364@scfn.thpl.lib.fl.us> <15088.8590.513944.540403@anthem.wooz.org> <20010502110518.45171@scfn.thpl.lib.fl.us> <15088.9063.1167.736985@anthem.wooz.org> <20010502111325.45390@scfn.thpl.lib.fl.us> Message-ID: <20010502190540.Q16486@xs4all.nl> On Wed, May 02, 2001 at 11:13:25AM -0400, Jay R. Ashworth wrote: > and I wouldn't expect us to be bitten by it; being a pedant is just my > *job*, damnit. Don't worry, you're not alone. I remember some pretty frustrating pedantic discussions where I had trouble convincing people I really *was* a nice guy, but I still stood by my pedantic point. Some of them were on python-dev, even :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From claw@kanga.nu Wed May 2 19:31:12 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 11:31:12 -0700 Subject: [Mailman-Developers] Re: Dates In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 02 May 2001 09:48:26 EDT." <15088.4139.451332.213714@anthem.wooz.org> References: <20010501152711.58471@scfn.thpl.lib.fl.us> <3AEF2A52.A4C564B9@west.sun.com> <20010501173153.19119@scfn.thpl.lib.fl.us> <3AEF31AA.22A4CCBE@west.sun.com> <20010501180454.13332@scfn.thpl.lib.fl.us> <20010501172129.P29821@smack.uchicago.edu> <20010501183541.06693@scfn.thpl.lib.fl.us> <20010501175208.T29821@smack.uchicago.edu> <15087.30907.613868.332848@anthem.wooz.org> <20010501235349.X29821@smack.uchicago.edu> <15088.4139.451332.213714@anthem.wooz.org> Message-ID: <24226.988828272@kanga.nu> On Wed, 2 May 2001 09:48:26 -0400 Barry A Warsaw wrote: > I'll add the X-List-Received-Date: header to the copy of the > message that the archiver gets. Oo00, please! Especially if: -- You also mention the list name/address in the same header -- You don't stomp any previous X-List-Received-Date headers that are alsoready present. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From mailman@howlingfrog.com Wed May 2 19:30:59 2001 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Wed, 2 May 2001 11:30:59 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <15087.8010.821127.647320@anthem.wooz.org> References: <0104271309330S.08359@graham.localdomain> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> Message-ID: <01050211305908.03885@graham.localdomain> On Tuesday 01 May 2001 13:40, you wrote: [.....snip.....] > Here's what I did: I loaded up a list with 60000 subscribers, then > went to the members page. It did indeed take a long time, and if I > let it run to completion, I get the page as expected and no locks. > > However, if I hit the stop button before the page is finished loading, > I can see that the CGI process continues to run for a while and then > it may or may not clear the locks. The page is not complete. Since > sometimes the locks are cleared and sometimes they're left, it's > pretty clear there are race conditions involved. [.....snip.....] > This seems to work, in that the locks appear to be cleared in the > cases where they were left laying around before. But because of all > the race conditions, I can't be 100% sure. > > If you've read this far, the implication is that if the user hits the > stop button, Mailman will in essence abort any changes to list > configuration that this invocation may have made. Alternatively, we > could try to save & unlock in the signal handler, but that raises the > possibility of race conditions again. Also, it makes sense to move > the save of the list data into the try: part of the clause and only do > the unlocking in the finally. That way, the finally clause and the > SIGTERM handler have the same semantics, and the list will get > unlocked in the face of either an exception or a signal. But the list > database will only get saved on sucessful completion of the task. I > can live with those semantics (I think ;). [.....snip.....] Barry, wanted to thank you muchly for the lengthy description of the problem and the patch that you provided. I figured that this was probably what was happening, after having gone through the process of running the CGIs repeatedly myself here. From the initial testing that I've done, it appears that the patch that you provided does work (near as I can tell so far), and has helped eliminate the dangling/stale lockfile problems that we've been having. As for the semantics of "save the list only if everything was successful", I too believe that those are livable (and likely proper) semantics to live with. Will let you know again if we continue to have this problem, but from what I've seen so far this appears to have fixed the major fire that I've had. Now all I've got to figure out is how to try to speed up the admin CGIs so that they don't take two or three minutes to load when dealing with large lists... Thanks again Barry, -- Graham TerMarsch From claw@kanga.nu Wed May 2 19:43:16 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 11:43:16 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: Message from Chuq Von Rospach of "Wed, 02 May 2001 08:26:59 PDT." References: Message-ID: <14112.988828996@kanga.nu> On Wed, 02 May 2001 08:26:59 -0700 Chuq Von Rospach wrote: > On 5/2/01 8:05 AM, "Jay R. Ashworth" wrote: >> I'm afraid I must disagree: that section of 2821 implies that > Sorry, I disagree. "may be" means the standard allows you to > consider this as optional. That's good, because 821 made case > sensistivity mandatory (and the switch shows the clear intent of > the standards folks, which is moving to full case insensitivity, > but they must have felt completely removing it was too big a step > -- but they're telling anyone who might still have a case > sensitive mailer it's time to fix it) IIRC some of the old BitNet systems mandated case sensitive LHS and were not configurable in that regard. As a result the gateways would upcase everything for portability. Its questionable if any of them are still on the 'net, but that's another question. > In practice, Barry's approach is the best one. The only thing that > happens if you practice case sensitivity on the user part is that > users end up with multiple subscriptions, multiple copies and no > clue how to fix it or what's wrong (and it's your fault, your > mailer is screwed up). The principle of least surprise. People have enough problem with case sensitive passwords. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Wed May 2 19:46:40 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 02 May 2001 11:46:40 -0700 Subject: [Mailman-Developers] case-sensitive e-mail addresses In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 02 May 2001 11:50:09 EDT." <20010502115009.18635@scfn.thpl.lib.fl.us> References: <20010502113055.56791@scfn.thpl.lib.fl.us> <20010502115009.18635@scfn.thpl.lib.fl.us> Message-ID: <20419.988829200@kanga.nu> On Wed, 2 May 2001 11:50:09 -0400 Jay R Ashworth wrote: > On Wed, May 02, 2001 at 08:43:17AM -0700, Chuq Von Rospach wrote: > But is this actually true? I haven't tried it, but I thought > sendmail still treated LHS's as case-sensitive... Its a config option. Ditto for Exim. I haven't looked at Postfix in this regard (and am sitting on a slow 28.8K link right now, so I'll leave that to the reader). <> -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From chuqui@plaidworks.com Wed May 2 20:05:08 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 02 May 2001 12:05:08 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <01050211305908.03885@graham.localdomain> Message-ID: On 5/2/01 11:30 AM, "Graham TerMarsch" wrote: > Barry, wanted to thank you muchly for the lengthy description of the > problem and the patch that you provided. I figured that this was probably > what was happening, after having gone through the process of running the > CGIs repeatedly myself here. By the by, I hate to say this, but I think this thing deserves a 2.0.5 subrelease.... From barry@digicool.com Thu May 3 09:08:52 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 04:08:52 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> <01050211305908.03885@graham.localdomain> Message-ID: <15089.4628.281146.976049@anthem.wooz.org> >>>>> "GT" == Graham TerMarsch writes: GT> Barry, wanted to thank you muchly for the lengthy description GT> of the problem and the patch that you provided. I figured GT> that this was probably what was happening, after having gone GT> through the process of running the CGIs repeatedly myself GT> here. You're welcome, and thanks for the feedback. I've committed those changes to CVS so they'll be part of 2.1. GT> As for the semantics of "save the list only if everything was GT> successful", I too believe that those are livable (and likely GT> proper) semantics to live with. I think it's the only sane thing to do. GT> Will let you know again if we continue to have this problem, GT> but from what I've seen so far this appears to have fixed the GT> major fire that I've had. Now all I've got to figure out is GT> how to try to speed up the admin CGIs so that they don't take GT> two or three minutes to load when dealing with large lists... Check to see if it's disk access. Remember you've got to load the entire marshaled dict into memory for each web hit, and that's gotta be expensive. Things will get much better for 2.1 from the email side because there'll be some caching involved (there's a long running qrunner process now), but you'll still pay the penalty on the web side. Really fixing that will be a job for Mailman 3.0. -Barry From barry@digicool.com Thu May 3 09:13:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 04:13:30 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <01050211305908.03885@graham.localdomain> Message-ID: <15089.4906.893381.544950@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> Barry, wanted to thank you muchly for the lengthy description >> of the problem and the patch that you provided. I figured that >> this was probably what was happening, after having gone through >> the process of running the CGIs repeatedly myself here. CVR> By the by, I hate to say this, but I think this thing CVR> deserves a 2.0.5 subrelease.... I was thinking the same thing. :/ I'd like to get more feedback on how important/useful you site guys think it would be. Chuq's vote is counted. :) -Barry From barry@digicool.com Thu May 3 09:14:25 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 04:14:25 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <01050211305908.03885@graham.localdomain> Message-ID: <15089.4961.73484.417761@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> By the by, I hate to say this, but I think this thing CVR> deserves a 2.0.5 subrelease.... Oh, let me add (since it's 4am :), that I also would like to get more feedback on the success of the patch. One thing I don't want to do is have 2.0.5 make things worse! -Barry From wildfire@progsoc.uts.edu.au, mailman-developers@python.org Thu May 3 17:41:04 2001 From: wildfire@progsoc.uts.edu.au, mailman-developers@python.org (Anand Kumria) Date: Fri, 4 May 2001 02:41:04 +1000 Subject: [Mailman-Developers] MHonArc integration Message-ID: <20010504024104.I28298@ftoomsh.progsoc.uts.edu.au> --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, I've just setup another mailman site and once again I wanted to integrate it with MHonArc. Previously I'd been using shell script that played games with symlinks and the the archive files behind Mailman's back. I wanted something simpler to use, so after much judicious cutting and pasting of other code I've put together MHonArc.py which you can use as an almost compatible replacement for HyperArch.py There are a number of things left to do: - generate HTML index pages properly - store text versions of the archive along with each dir. - cleanup the code and document it This is my first real experience with Python, so no laughing (too loud). I think I've also noticed a bug where Mailman uses the udnerlying Pythong rfc822 object when Mailman's is more useful -- see comments in add_article. I've also simplified the date handling (the current archiving stuff hyperarch/pipermail convert a to/from unix epoch lots of times) Doing this also made clear that a nicer interface in Archive.py could be done which should handle, imo: - message date => volume (and thus path) conversions - make the archive date format local to each list e.g. I'd like to have 2001/05/01 instead of 20010501 - generation of HTML index pages - make the HTML template editable via the admin interface - expose some way to allow list-admins to configure any options the archiver might allow (MHonArc allows a lot) Feedback on all of this welcome. Regards, Anand --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="MHonArc.py" # # Archive interface for MHonArc and Mailman # """ This attempts to simulate the HpyerArch python script but using instead MHonArc. By doing this I hope to avoid the need to have 'list rotation' and 'index generation' as external jobs 1. setup archive directory - set ARCHIVE_PERIOD to appropriate value 2. convert mbox into individual messages - figure out location to put message - convert message date to appropriate directory - create directory if needed 3. add message to archive - add message to text file in - interperlate -output and -resource into appropriate directory - execute MHonArc 4. create HTML index pages """ import sys import os import time import string from Mailman import mm_cfg from Mailman import Utils from Mailman.Logging.Syslog import syslog from Mailman.Mailbox import Mailbox from Mailman.Utils import mkdir, open_ex DIRMODE = 0755 # Mode to give to created directories FILEMODE = 0644 # Mode to give to created files INDEX_EXT = ".html" # Extension for indexes VERBOSE = 1 TOC_template='''\ The %(listname)s Archives

              The %(listname)s Archives

              You can get more information about this list or you can download the full raw archive (%(size)s).

              %(noarchive_msg)s %(archive_listing_start)s %(archive_listing)s %(archive_listing_end)s ''' TOC_entry_template = '''\ %(archive)s: [ Thread ] [ Subject ] [ Author ] [ Date ] %(textlink)s ''' def sizeof(filename): size = os.path.getsize(filename) if size < 1000: return ' %d bytes ' % size elif size < 1000000: return ' %d KB ' % (size / 1000) # GB?? :-) return ' %d MB ' % (size / 1000000) class HyperArchive: def __init__(self, maillist): # make mailist available inside this object self.maillist = maillist # setup archive attributes if hasattr(self.maillist,'archive_volume_frequency'): if self.maillist.archive_volume_frequency == 0: self.ARCHIVE_PERIOD='year' elif self.maillist.archive_volume_frequency == 2: self.ARCHIVE_PERIOD='quarter' elif self.maillist.archive_volume_frequency == 3: self.ARCHIVE_PERIOD='week' elif self.maillist.archive_volume_frequency == 4: self.ARCHIVE_PERIOD='day' else: self.ARCHIVE_PERIOD='month' self.html_TOC_tmpl = TOC_template self.TOC_entry_tmpl = TOC_entry_template # def processUnixMailbox(self, input, articleClass = Article): def processUnixMailbox(self, input ): mbox = Mailbox(input) while 1: m = mbox.next() if not m: break self.message("constructed 0 ") self.set_msg_date_tuple(m) self.message(self.msg_date_tuple) self.make_archive(self.get_list_archive_path()) self.add_article(m) self.message("constructed 3 ") def make_archive(self, path): # If the archive directory doesn't exist, create it # recursively try: os.stat(path) except os.error, errdata: errno, errmsg = errdata if errno == 2: mkdir(path, DIRMODE) self.message("created: %s" % path) else: raise os.error, errdata def add_article(self, msg): # Using a mailbox give us (eventually) Python's # rfc822 Message object instead of Mailman's. # Here we simply reach in and do the necessary # but the real fix is to ensure Mailman ships # its own version of mailbox.py instead of # relying on Python's. # convert rfc822 Message object back into text txt = msg.unixfrom + string.join(msg.headers,'') + '\n' + msg.fp.read() self.ExternalArchive(mm_cfg.MHONARC, txt) return def message(self, msg): if VERBOSE: f = sys.stderr f.write(msg) if msg[-1:] != '\n': f.write('\n') f.flush() def ExternalArchive(self, ar, txt): l = Utils.SafeDict({'listname': self.maillist.internal_name()}) a = Utils.SafeDict({'archivedir': self.get_list_archive_path()}) cmd = ar % l cmd = cmd % a self.message("cmd = %s" % cmd) extarch = os.popen(cmd, 'w') extarch.write(txt) status = extarch.close() if status: syslog('error', 'external archiver non-zero exit status: %d\n' % (status & 0xff00) >> 8) # The following two methods should be inverses of each other. -ddm def dateToVolName(self,date): # datetuple=time.localtime(date) datetuple = date if self.ARCHIVE_PERIOD=='year': return time.strftime("%Y",datetuple) elif self.ARCHIVE_PERIOD=='quarter': if datetuple[1] in [1,2,3]: return time.strftime("%Yq1",datetuple) elif datetuple[1] in [4,5,6]: return time.strftime("%Yq2",datetuple) elif datetuple[1] in [7,8,9]: return time.strftime("%Yq3",datetuple) else: return time.strftime("%Yq4",datetuple) elif self.ARCHIVE_PERIOD == 'day': return time.strftime("%Y%m%d", datetuple) elif self.ARCHIVE_PERIOD == 'week': # Reconstruct "seconds since epoch", and subtract weekday # multiplied by the number of seconds in a day. monday = time.mktime(datetuple) - datetuple[6] * 24 * 60 * 60 # Build a new datetuple from this "seconds since epoch" value datetuple = time.localtime(monday) return time.strftime("Week-of-Mon-%Y%m%d", datetuple) # month. -ddm else: return time.strftime("%Y-%B",datetuple) ### my stuff # We convert from string to seconds since # Epoch in order to validate the date. def set_msg_date_tuple(self, message): if message.has_key('Date'): date = message.getdate_tz('Date') date, tzoffset = date[:9], date[-1] or 0 try: date = time.mktime(date) # - tzoffset date = time.localtime(date) except (ValueError, OverflowError): date = time.localtime(time.time()) else: date = time.localtime(time.time()) self.msg_date_tuple = date def get_list_archive_path(self): basedir = self.maillist.archive_dir() arch = self.dateToVolName(self.msg_date_tuple) archivedir = os.path.join(basedir, arch) return archivedir #### def write_TOC(self): # self.sortarchives() basedir = self.maillist.archive_dir() toc=open_ex(os.path.join(basedir, 'index.html'), 'w') toc.write(self.html_TOC()) toc.close() def html_TOC(self): # for know, fudge the fact we have no archives self.archives = None listname = self.maillist.internal_name() mbox = os.path.join(self.maillist.archive_directory+'.mbox', listname+'.mbox') d = {"listname": self.maillist.real_name, "listinfo": self.maillist.GetScriptURL('listinfo', absolute=1), "fullarch": '../%s.mbox/%s.mbox' % (listname, listname), "size": sizeof(mbox), } if not self.archives: d["noarchive_msg"] = '

              Currently, there are no archives.

              ' d["archive_listing_start"] = "" d["archive_listing_end"] = "" d["archive_listing"] = "" else: d["noarchive_msg"] = "" d["archive_listing_start"] = self.arch_listing_start d["archive_listing_end"] = self.arch_listing_end accum = [] for a in self.archives: accum.append(self.html_TOC_entry(a)) d["archive_listing"] = string.join(accum, '') if not d.has_key("encoding"): d["encoding"] = "" return self.html_TOC_tmpl % d def html_TOC_entry(self, arch): # Check to see if the archive is gzip'd or not txtfile = os.path.join(mm_cfg.PRIVATE_ARCHIVE_FILE_DIR, self.maillist.internal_name(), arch + '.txt') gzfile = txtfile + '.gz' templ = '[ %(fmt)sText%(sz)s]' # which exists? .txt.gz first, then .txt if os.path.exists(gzfile): file = gzfile url = arch + '.txt.gz' fmt = "Gzip'd " elif os.path.exists(txtfile): file = txtfile url = arch + '.txt' fmt = '' else: # neither found? file = None # in Python 1.5.2 we have an easy way to get the size if file: textlink = templ % {'url': url, 'fmt': fmt, 'sz' : sizeof(file), } else: # there's no archive file at all... hmmm. textlink = '' return self.TOC_entry_tmpl % { 'archive': arch, 'textlink': textlink } def close(self): # "Close an archive, save its state, and update any changed archives." # self.update_dirty_archives() # self.update_TOC = 0 self.write_TOC() # # Save the collective state # self.message('Pickling archive state into ' \ # + os.path.join(self.basedir, 'pipermail.pck')) # self.database.close() # del self.database # # f = open(os.path.join(self.basedir, 'pipermail.pck'), 'w') # pickle.dump(self.getstate(), f) # f.close() return --m51xatjYGsM+13rf-- From mailman@howlingfrog.com Thu May 3 19:14:09 2001 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Thu, 3 May 2001 11:14:09 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <15089.4906.893381.544950@anthem.wooz.org> References: <01050211305908.03885@graham.localdomain> <15089.4906.893381.544950@anthem.wooz.org> Message-ID: <0105031114090E.07532@graham.localdomain> On Thursday 03 May 2001 01:13, Barry A. Warsaw wrote: > >>>>> "CVR" == Chuq Von Rospach writes: > >> Barry, wanted to thank you muchly for the lengthy description > >> of the problem and the patch that you provided. I figured that > >> this was probably what was happening, after having gone through > >> the process of running the CGIs repeatedly myself here. > > CVR> By the by, I hate to say this, but I think this thing > CVR> deserves a 2.0.5 subrelease.... > > I was thinking the same thing. :/ I'd like to get more feedback on > how important/useful you site guys think it would be. > > Chuq's vote is counted. :) Count my vote in; I'm all for smaller, quicker, more incremental releases (especially when they contain bugfixes). :) -- Graham TerMarsch From mailman@howlingfrog.com Thu May 3 19:17:48 2001 From: mailman@howlingfrog.com (Graham TerMarsch) Date: Thu, 3 May 2001 11:17:48 -0700 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... In-Reply-To: <15089.4961.73484.417761@anthem.wooz.org> References: <01050211305908.03885@graham.localdomain> <15089.4961.73484.417761@anthem.wooz.org> Message-ID: <0105031117480F.07532@graham.localdomain> On Thursday 03 May 2001 01:14, Barry A. Warsaw wrote: > >>>>> "CVR" == Chuq Von Rospach writes: > > CVR> By the by, I hate to say this, but I think this thing > CVR> deserves a 2.0.5 subrelease.... > > Oh, let me add (since it's 4am :), that I also would like to get more > feedback on the success of the patch. One thing I don't want to do is > have 2.0.5 make things worse! FWIW Barry, this patch appears to have just about completely solved our lockfile problems and stalled WWW pages that we were having. I used to be able to use "ab" (ApacheBench) to pound on one of the "subscribe" pages, and could just about guarantee stale/dangling lockfiles. Even at 10 requests total, 5 concurrently, this problem would appear. After applying the patch, though, I've been able to crank it up to 100 total requests, 10 concurrent, and not see any dangling/stale locks. Didn't test any further beyond that as it at least identified for me that the problem (if it was still around) wasn't anywhere near as serious or identifiable as it was previously. -- Graham TerMarsch From barry@digicool.com Thu May 3 19:41:09 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 14:41:09 -0400 Subject: [Mailman-Developers] Re: Big problems with stale lockfiles on large list... References: <01050211305908.03885@graham.localdomain> <15089.4961.73484.417761@anthem.wooz.org> <0105031117480F.07532@graham.localdomain> Message-ID: <15089.42565.24918.848597@anthem.wooz.org> >>>>> "GT" == Graham TerMarsch writes: GT> FWIW Barry, this patch appears to have just about completely GT> solved our lockfile problems and stalled WWW pages that we GT> were having. GT> I used to be able to use "ab" (ApacheBench) to pound on one of GT> the "subscribe" pages, and could just about guarantee GT> stale/dangling lockfiles. Even at 10 requests total, 5 GT> concurrently, this problem would appear. After applying the GT> patch, though, I've been able to crank it up to 100 total GT> requests, 10 concurrent, and not see any dangling/stale locks. GT> Didn't test any further beyond that as it at least identified GT> for me that the problem (if it was still around) wasn't GT> anywhere near as serious or identifiable as it was previously. Excellent. Thanks for the feedback. I'm definitely warming to a 2.0.5 bug fix release. -Barry From barry@digicool.com Thu May 3 20:26:38 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 15:26:38 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <009c01c0cf5b$3165c2a0$01000001@sgergo.hu> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> Message-ID: <15089.45294.645712.975619@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> So the code in admin.py looks something like: | def main(): | ... | mlist = MailList.MailList(listname, lock=0) | ... | | def sigterm_handler(signum, frame, mlist=mlist): | mlist.Unlock() | | mlist.Lock() | try: | signal.signal(signal.SIGTERM, sigterm_handler) | ... | mlist.Save() | finally: | mlist.Unlock() I think this code isn't quite right. I think to be totally safe, you want sigterm_handler() to sys.exit(0) after the call to mlist.Unlock(). Otherwise, depending on race conditions, after unlocking the list you could still enter Save(), which would fail because it would first try to refresh a lock you no longer own. I'll work up a proper patch to Mailman 2.0.4 and post it to SF for you to try. Or you could modify your patched version and test it in the meantime. -Barry From barry@digicool.com Thu May 3 22:24:50 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 3 May 2001 17:24:50 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list... References: <0104271309330S.08359@graham.localdomain> <009c01c0cf5b$3165c2a0$01000001@sgergo.hu> <01042715193211.08359@graham.localdomain> <15087.8010.821127.647320@anthem.wooz.org> <15089.45294.645712.975619@anthem.wooz.org> Message-ID: <15089.52386.871196.668108@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> I think this code isn't quite right. I think to be totally BAW> safe, you want sigterm_handler() to sys.exit(0) after the BAW> call to mlist.Unlock(). Otherwise, depending on race BAW> conditions, after unlocking the list you could still enter BAW> Save(), which would fail because it would first try to BAW> refresh a lock you no longer own. BAW> I'll work up a proper patch to Mailman 2.0.4 and post it to BAW> SF for you to try. Or you could modify your patched version BAW> and test it in the meantime. On second thought, I'm only going to post the patch when I do the 2.0.5 release (which will happen tomorrow). All the changes are in the CVS Release_2_0_1-branch maintenance branch so you can check them out there for a preview. I plan on doing some more testing tomorrow before the release, but so far it looks pretty good. -Barry From benwa@ocentrix.com Fri May 4 03:50:55 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 3 May 2001 19:50:55 -0700 Subject: [Mailman-Developers] Patch to add class Img to htmlformat.py Message-ID: <200105040250.f442otL28067@mail.ocentrix.net> This is a multi-part message in MIME format. ------=_Next20010503-195055-28062-1287737225 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SSBkb24ndCBrbm93IGlmIGFueW9uZSBlbHNlIHdpbGwgZmluZCB0 aGlzIHVzZWZ1bGwsIGJ1dCBoZXJlCmdvZXMuCgotIEJlbgoKUFMg SSB1c2VkIGl0IHRvIGFkZCBhIGxvZ28gdG8gdGhlIHRvcCBvZiBz b21lIG9mIHRoZSB3ZWIKaW50ZXJmYWNlIHBhZ2VzIGZvciBleGFt cGxlIGluIGxpc3RpbmZvLnB5CgotLS08c25pcD4tLS0KZGVmIEZv cm1hdExpc3RpbmZvT3ZlcnZpZXcoZXJyb3I9Tm9uZSk6CiAgICAi UHJlc2VudCBhIGdlbmVyYWwgd2VsY29tZSBhbmQgaXRlbWl6ZSB0 aGUgKHB1YmxpYykKbGlzdHMgZm9yIHRoaXMgaG9zdC4iCiAKICAg ICMgWFhYIFdlIG5lZWQgYSBwb3J0YWJsZSB3YXkgdG8gZGV0ZXJt aW5lIHRoZSBob3N0IGJ5CndoaWNoIHdlIGFyZSBiZWluZwogICAg IyAgICAgdmlzaXRlZCEgIEFuIGFic29sdXRlIFVSTCB3b3VsZCBk by4uLgogICAgaHR0cF9ob3N0ID0gb3MuZW52aXJvbi5nZXQoJ0hU VFBfSE9TVCcsCm9zLmVudmlyb24uZ2V0KCdTRVJWRVJfTkFNRScp KQogICAgcG9ydCA9IG9zLmVudmlyb24uZ2V0KCdTRVJWRVJfUE9S VCcpCiAgICAjIHN0cmlwIG9mZiB0aGUgcG9ydCBpZiB0aGVyZSBp cyBvbmUKICAgIGlmIHBvcnQgYW5kIGh0dHBfaG9zdFstbGVuKHBv cnQpLTE6XSA9PSAnOicrcG9ydDoKICAgICAgICBodHRwX2hvc3Qg PSBodHRwX2hvc3RbOi1sZW4ocG9ydCktMV0KICAgIGlmIG1tX2Nm Zy5WSVJUVUFMX0hPU1RfT1ZFUlZJRVcgYW5kIGh0dHBfaG9zdDoK ICAgICAgICBob3N0X25hbWUgPSBodHRwX2hvc3QKICAgIGVsc2U6 CiAgICAgICAgaG9zdF9uYW1lID0gbW1fY2ZnLkRFRkFVTFRfSE9T VF9OQU1FCiAKICAgIGRvYyA9IERvY3VtZW50KCkKICAgIGxlZ2Vu ZCA9ICIlcyBNYWlsaW5nIExpc3RzIiAlIGhvc3RfbmFtZQogICAg ZG9jLlNldFRpdGxlKGxlZ2VuZCkKIAojIGxldHMgc2VlIGlmIHdl IGNhbiBpbnNlcnQgYW4gaW1hZ2UgYXQgdGhlIHRvcCBvZiB0aGlz IHBhZ2UKICAgIHRvcGxvZ28gPQpJbWcoJy9tYWlsbWFubG9nb3Mv cmlkZXJzX2Nvbm5lY3Rpb25faGVhZGVyLnBuZycsJzc1MCcsJzEx NScsIk9jZW50cml4ClJpZGVycycgQ29ubmVjdGlvbiIsJzAnKQog ICAgZG9jLkFkZEl0ZW0odG9wbG9nbykKIAogICAgdGFibGUgPSBU YWJsZShib3JkZXI9MCwgd2lkdGg9IjEwMCUiKQogCiAgICB0YWJs ZS5BZGRSb3coW0NlbnRlcihIZWFkZXIoMiwgbGVnZW5kKSldKQog CiAgICB0YWJsZS5BZGRDZWxsSW5mbyhtYXgodGFibGUuR2V0Q3Vy cmVudFJvd0luZGV4KCksIDApLCAwLAogICAgICAgICAgICAgICAg ICAgICAgY29sc3Bhbj0yLApiZ2NvbG9yPSIjOTljY2ZmIikgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKLS0tPC9zbmlwPi0t LQ== ------=_Next20010503-195055-28062-1287737225 Content-Type: application/octet-stream; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="htmlformat.py_add_image_class_patch.gz" H4sICCgM8joAA2h0bWxmb3JtYXQucHlfYWRkX2ltYWdlX2NsYXNzX3BhdGNoAI1SXU+DMBR9 Hr/i2mTZQEA+dBriTHxZNHHxYXsnDLpRw1doF52/3tsWCMbFrA/l3sM95/b01rIsKBNWlEnl BK7nhjdrnd3koiz2dVsmwm1Ok3VdwYY24PsQ+JEXROECAs/zDMdx4Dxlmx/xzwkgBP8hCu8i /15SfMP6vWSOoqEd+AtQgNRUQHgLGDsGwEQugJft+m2lOrzvPmgq5pwWe1fQL2EDqzJaCdPE auMa0iLhHF7LQ4SJXBndQxyziok4VjQbeJva8MkykduQU3bIUSUpcNvVbUbbpWdK8kT1wFpY SsaAKCJi6jugWgdhHQw46iKI+4DoJgjqoDvm6LTaaHdW7a47Ur/QeCMVCBmBbA9j/asleMrG mDDrLZIpJzOYjhmytqXi2FYwe2TlQZpWddqpDrU7HaMpHUz5k9San5+Suu1uSLZs8t9Iu6lc Wt5P79J6NeW/xep6TMzxDekHtKorsWHfNDL05RJCeggYhx1l1QGH1bQ0TQTNwIEjp4r1LEQ7 d10XnxkWLwmGxMSeXNAkc1HH+AH+4SJvfAMAAA== ------=_Next20010503-195055-28062-1287737225-- From mpaludo@ottawa.com Fri May 4 07:54:10 2001 From: mpaludo@ottawa.com (Marco Paludo) Date: Fri, 4 May 2001 02:54:10 -0400 (EDT) Subject: [Mailman-Developers] Running Solaris 8 on Intel platform with i810 chipset Message-ID: <200105040654.CAA05056@mail.ottawa.com> Hello to All, Is there a XServer to have Solaris 8 Intel platform edition running properly with the Intel 82810 chipset? As much as know, XFree86 release 4.0.3 only supports the i810 chipset for the Linux operating system. Is there a technical reason, why this hardware is not supported for the Solaris Intel platform? Also, is there any chance that the XServer for i810 will be available for Solaris in the near future? Thank you for your attention and help. Marco Paludo Get your Free email at http://mail.ottawa.com/ From barry@digicool.com Fri May 4 17:58:54 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 4 May 2001 12:58:54 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch Message-ID: <15090.57294.242909.931852@anthem.wooz.org> Hi all, I've uploaded the Mailman 2.0.5 patch and tarball to SourceForge. Please check out http://sourceforge.net/project/showfiles.php?group_id=103 I've tested this on my system and on {python,zope}.org and it seems to work well. Still, I would love to get some feedback on this specific patch before making a wider announcement (won't it be great when I have a unit test suite? :). Please give it a shot and let me know. If there are no showstoppers, I will make the announcement on Monday. Thanks, -Barry From marc_news@valinux.com Fri May 4 20:14:00 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Fri, 4 May 2001 12:14:00 -0700 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15090.57294.242909.931852@anthem.wooz.org>; from barry@digicool.com on Fri, May 04, 2001 at 12:58:54PM -0400 References: <15090.57294.242909.931852@anthem.wooz.org> Message-ID: <20010504121400.Z21233@magic.merlins.org> On Fri, May 04, 2001 at 12:58:54PM -0400, Barry A. Warsaw wrote: > > Hi all, > > I've uploaded the Mailman 2.0.5 patch and tarball to SourceForge. > Please check out > > http://sourceforge.net/project/showfiles.php?group_id=103 lynx -dump http://lists.sourceforge.net/lists/listinfo/test | grep version version 2.0.5 [7]Python Powered [8]GNU's Not Unix [9]Mailman home page The uprade procedure was a bit painful, because once again, update touched all my lists as root, recreated all the config.db files as root, which broke all the lists on my system (admittedly, that's my fault for having restricted hardlinks) This, in the update process, is what is screwing me over: - updating old public mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me Can't update see that upgrading from 2.0.x to 2.0.y doesn't require that and only run it when it's really really needed? (in my case, with 10,000+ lists, it takes a really long time to run, up to 10-20mn). Would you accept a patch that made update change its uid to mailman (requiring make install to be ran as root or mailman) for everyone? The problem is that securelinux_fix is to be run after make install, and while make install is being run, and update goes through all the lists, all the lists are non functionning on my system Anyway, everything is back up now, I cleared the lock directory, and ran: find lists | grep config.db | grep -v "config.db.last" | grep -v config.db$ | xargs rm I'll try to remember to check it again on sunday night and report back. 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@digicool.com Fri May 4 21:25:52 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 4 May 2001 16:25:52 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> Message-ID: <15091.4176.978177.88211@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> The uprade procedure was a bit painful, because once again, MM> update touched all my lists as root, recreated all the MM> config.db files as root, which broke all the lists on my MM> system (admittedly, that's my fault for having restricted MM> hardlinks) | This, in the update process, is what is screwing me over: | - updating old public mbox file | looks like you have a really recent CVS installation... | you're either one brave soul, or you already ran me Close, but not quite. There's a step in bin/update, function dolist(), which sets some list attributes unconditionally. Of course, to do this, it must lock the list, change the attrs and save the list. There's a similar step in main() where the old gate_watermarks file is transformed into the usenet_watermark attribute, but that step isn't done if the gate_watermarks file isn't found (which it won't be for any 2.0.x upgrade). The problem is that while the dolist() step happens unconditionally, it only needs to be done if it updates the archive_directory or private_archive_file_dir attributes. Below is a patch to skip this step if those attrs don't need to be upgraded. MM> Would you accept a patch that made update change its uid to MM> mailman (requiring make install to be ran as root or mailman) MM> for everyone? I'm not so sure. Say I install Mailman as user `barry', I don't want to be running the upgrade as user `mailman'. Probably a better approach is to refuse to run update if the effective uid doesn't equal mm_cfg.MAILMAN_UID. On the other hand, the attached patch might be enough. On the third hand, maybe bin/update should just be culled of all ability to upgrade from a pre-2.0 revision? In that case, I'll bet bin/update can just go away. -Barry -------------------- snip snip -------------------- Index: update =================================================================== RCS file: /cvsroot/mailman/mailman/bin/update,v retrieving revision 1.24.2.1 diff -u -r1.24.2.1 update --- update 2001/03/02 23:19:33 1.24.2.1 +++ update 2001/05/04 20:25:01 @@ -80,28 +80,25 @@ def dolist(listname): errors = 0 mlist = MailList.MailList(listname, lock=0) - try: - mlist.Lock(0.5) - except TimeOutError: - print 'WARNING: could not acquire lock for list:', listname - return 1 - - mbox_dir = make_varabs('archives/private/%s.mbox' % (listname)) - mbox_file = make_varabs('archives/private/%s.mbox/%s' % (listname, - listname)) + + mbox_dir = make_varabs('archives/private/%s.mbox' % listname) + mbox_file = make_varabs('archives/private/%s.mbox/%s' % + (listname, listname)) - o_pub_mbox_file = make_varabs('archives/public/%s' % (listname)) - o_pri_mbox_file = make_varabs('archives/private/%s' % (listname)) + o_pub_mbox_file = make_varabs('archives/public/%s' % listname) + o_pri_mbox_file = make_varabs('archives/private/%s' % listname) html_dir = o_pri_mbox_file - o_html_dir = makeabs('public_html/archives/%s' % (listname)) + o_html_dir = makeabs('public_html/archives/%s' % listname) # # make the mbox directory if it's not there. # if not os.path.exists(mbox_dir): ou = os.umask(0) - os.mkdir(mbox_dir, 02775) - os.umask(ou) + try: + os.mkdir(mbox_dir, 02775) + finally: + os.umask(ou) else: # this shouldn't happen, but hey, just in case if not os.path.isdir(mbox_dir): @@ -197,10 +194,17 @@ # save the new variables and # let it create public symlinks if necessary # - mlist.archive_directory = make_varabs('archives/private/%s' % (listname)) - mlist.private_archive_file_dir = make_varabs('archives/private/%s.mbox' % - listname) - mlist.Save() + archivedir = make_varabs('archives/private/%s' % listname) + if mlist.archive_directory <> archivedir or \ + mlist.private_archive_file_dir <> mbox_dir: + print " I have to update the list's archive directory attributes" + mlist.Lock() + try: + mlist.archive_directory = archivedir + mlist.private_archive_file_dir = mbox_dir + mlist.Save() + finally: + mlist.Unlock() # # check to see if pre-b4 list-specific templates are around # and move them to the new place if there's not already @@ -222,8 +226,6 @@ else: print "- both %s and %s exist, leaving untouched" \ % (o_tmpl, n_tmpl) - # Avoid eating filehandles with the list lockfiles - mlist.Unlock() return 0 @@ -296,18 +298,14 @@ if listname not in listnames: # this list no longer exists continue - mlist = MailList.MailList(listname, lock=0) + mlist = MailList.MailList(listname) try: - mlist.Lock(0.5) - except TimeOutError: - print 'WARNING: could not acquire lock for list:', listname - errors = errors + 1 - else: # Pre 1.0b7 stored 0 in the gate_watermarks file to indicate # that no gating had been done yet. Without coercing this to # None, the list could now suddenly get flooded. mlist.usenet_watermark = d[listname] or None mlist.Save() + finally: mlist.Unlock() os.unlink(wmfile) print '- usenet watermarks updated and gate_watermarks removed' From marc_news@valinux.com Fri May 4 21:49:38 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Fri, 4 May 2001 13:49:38 -0700 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15091.4176.978177.88211@anthem.wooz.org>; from barry@digicool.com on Fri, May 04, 2001 at 04:25:52PM -0400 References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> <15091.4176.978177.88211@anthem.wooz.org> Message-ID: <20010504134938.C21233@magic.merlins.org> On Fri, May 04, 2001 at 04:25:52PM -0400, Barry A. Warsaw wrote: > The problem is that while the dolist() step happens unconditionally, > it only needs to be done if it updates the archive_directory or > private_archive_file_dir attributes. Below is a patch to skip this > step if those attrs don't need to be upgraded. Great, thanks. > MM> Would you accept a patch that made update change its uid to > MM> mailman (requiring make install to be ran as root or mailman) > MM> for everyone? > > I'm not so sure. Say I install Mailman as user `barry', I don't want > to be running the upgrade as user `mailman'. Yeah, I figured that afterwards. Fair enough. > Probably a better approach is to refuse to run update if the effective > uid doesn't equal mm_cfg.MAILMAN_UID. On the other hand, the attached Mmmh, that will fail for you when you do make install as barry, then. Letme think. How about if euid != mm_cfg.MAILMAN_UID: if euid == 0 setgid (mm_cfg.MAILMAN_GID) setuid (mm_cfg.MAILMAN_UID) This way, when you install as root, it setuids to mailman first, if you install as mailman, everything is fine too, and if you install as barry, that continues to work (although it obviously won't work with restricted hardlinks) > patch might be enough. On the third hand, maybe bin/update should > just be culled of all ability to upgrade from a pre-2.0 revision? In > that case, I'll bet bin/update can just go away. The upgrade code is probably useful to some. I don't mind it myself as long as it doesn't try to run on my machines when I upgrade from 2.0.x to 2.0.y. :-) I'll apply your patch to my tree when I upgrade mailman on my 3 other list servers, and I'll report back. Thanks, 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 tollef@add.no Sat May 5 12:11:19 2001 From: tollef@add.no (Tollef Fog Heen) Date: 05 May 2001 13:11:19 +0200 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15091.4176.978177.88211@anthem.wooz.org> References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> <15091.4176.978177.88211@anthem.wooz.org> Message-ID: <87zocst5ig.fsf@arabella.intern.opera.no> * (Barry A. Warsaw) | On the third hand, maybe bin/update should just be culled of all | ability to upgrade from a pre-2.0 revision? In that case, I'll bet | bin/update can just go away. Please, please, please, please don't do that. It will force me to maintain that code in Debian, because Debian stable has an old version (1.1) and we absolutely need to have a clean upgrade path. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From Chopp@cusquena.com.pe Sat May 5 19:11:28 2001 From: Chopp@cusquena.com.pe (=?iso-8859-1?Q?CLUB_CUSQUE=D1A?=) Date: Sat, 5 May 2001 13:11:28 -0500 Subject: [Mailman-Developers] =?iso-8859-1?Q?Promoci=F3n_Chopp_Cusque=F1a?= Message-ID: <06cc82811180551CMPS1@cmps1.collectivemind.com.pe> This is a multi-part message in MIME format. ------=_NextPart_000_1F3B5_01C0D564.E4F2B0D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ..P=EDdelo=20 AQU=CD =20 =20 =20 =20 Como hacer el pedido?=20 Solo necesitas llenar tus datos en el=20 formulario de pedidos de CHOPP...=20 y LISTO!!!=20 RD: 152-2001-IN-1501=20 Visita el Web site de Cerveza Cusque=F1a en:=20 http://www.cusquena.com.pe=20 Si quieres entrar al Chat Cusque=F1a haz click Aqu=ED =20 Recibes este e-mail porque estas suscrito al CLUB CUSQUE=D1A o un amigo tuyo te ha recomendado. Para cancelar el env=EDo de este email, reenv=EDanos este email con el t=EDtulo: QUITARME DE LA LISTA=20 ------=_NextPart_000_1F3B5_01C0D564.E4F2B0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable www.cusquena.com.pe - Chopp

              ...P=EDdelo
                               AQU=CD

                    

              Como hacer el pedido?
              Solo necesitas llenar tus = datos en el
              formulario de pedidos de CHOPP...
              y LISTO!!!

              RD: 152-2001-IN-1501


              Visita el Web site de Cerveza Cusque=F1a en:
              http://www.cusquena.com.pe


              Si quieres entrar al Chat Cusque=F1a haz click Aqu=ED


              Recibes este e-mail porque estas suscrito al CLUB CUSQUE=D1A o un amigo tuyo te ha recomendado.
              Para cancelar el env=EDo de este email, reenv=EDanos este email con el t=EDtulo: QUITARME DE LA LISTA                             ------=_NextPart_000_1F3B5_01C0D564.E4F2B0D0-- From marc_news@valinux.com Mon May 7 02:13:46 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Sun, 6 May 2001 18:13:46 -0700 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <20010504121400.Z21233@magic.merlins.org>; from marc_news@valinux.com on Fri, May 04, 2001 at 12:14:00PM -0700 References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> Message-ID: <20010506181345.G19166@magic.merlins.org> On Fri, May 04, 2001 at 12:14:00PM -0700, Marc MERLIN wrote: > I'll try to remember to check it again on sunday night and report back. Just for info: No stale locks showed up over the weekend with 2.0.5, and messages are still happily flowing. 2.0.5 looks good. Thanks Barry 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@digicool.com Mon May 7 02:44:55 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 6 May 2001 21:44:55 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch References: <15090.57294.242909.931852@anthem.wooz.org> Message-ID: <15093.65047.483993.636622@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> I've uploaded the Mailman 2.0.5 patch and tarball to BAW> SourceForge. Please check out The 2.0.5 tarball had a bug in the admindb.py. Thanks to Phil Barnett who helped discover this. The patch file did not have the bug. I've just uploaded a new 2.0.5 tarball, and will be sending out the announcements tomorrow morning. Cheers, -Barry From barry@digicool.com Mon May 7 02:57:52 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 6 May 2001 21:57:52 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch References: <15090.57294.242909.931852@anthem.wooz.org> <20010504121400.Z21233@magic.merlins.org> <20010506181345.G19166@magic.merlins.org> Message-ID: <15094.288.916835.668815@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Just for info: No stale locks showed up over the weekend with MM> 2.0.5, and messages are still happily flowing. MM> 2.0.5 looks good. Yay! MM> Thanks Barry MM> Marc You're very welcome, thanks for the feedback. Announcements go out tomorrow. -Barry From midnight@the-oasis.net Mon May 7 05:20:36 2001 From: midnight@the-oasis.net (Phil Barnett) Date: Mon, 7 May 2001 00:20:36 -0400 Subject: [Mailman-Developers] Mailman 2.0.5 patch In-Reply-To: <15093.65047.483993.636622@anthem.wooz.org> Message-ID: <3AF5EA54.19456.76935707@localhost> On 6 May 2001, at 21:44, Barry A. Warsaw wrote: > >>>>> "BAW" == Barry A Warsaw writes: > > BAW> I've uploaded the Mailman 2.0.5 patch and tarball to > BAW> SourceForge. Please check out > > The 2.0.5 tarball had a bug in the admindb.py. Thanks to Phil Barnett > who helped discover this. The patch file did not have the bug. > > I've just uploaded a new 2.0.5 tarball, and will be sending out the > announcements tomorrow morning. Confiming: The new tarball works great. Thanks. -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net From barry@digicool.com Mon May 7 17:24:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 7 May 2001 12:24:16 -0400 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 Message-ID: <15094.52272.753043.181192@anthem.wooz.org> Folks, I've just released Mailman 2.0.5 which fixes a problem with stale lock files that can occur under certain situations when the user hits the `Stop' button on their browser. These stale lock files can cause mailing lists to be inaccessible for long periods of time (until the stale lock file times out or is manually removed). As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.4. You /must/ update your source to 2.0.4 before applying the 2.0.5 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.5 source tree and apply it like so: % patch -p0 < mailman-2.0.4-2.0.5.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net My thanks to those of you who gave the 2.0.5 pre-release a try! Enjoy, -Barry Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.5 retrieving revision 1.25.2.6 diff -u -r1.25.2.5 -r1.25.2.6 --- NEWS 2001/04/18 10:45:54 1.25.2.5 +++ NEWS 2001/05/03 21:06:56 1.25.2.6 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.5 (04-May-2001) + + Fix a lock stagnation problem that can result when the user hits + the `stop' button on their browser during a write operation that + can take a long time (e.g. hitting the membership management admin + page). + 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.4 retrieving revision 1.20.2.5 diff -u -r1.20.2.4 -r1.20.2.5 --- Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 +++ Mailman/Version.py 2001/05/03 20:58:19 1.20.2.5 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.4" +VERSION = "2.0.5" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 4 +MICRO_REV = 5 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.82.2.2 retrieving revision 1.82.2.3 diff -u -r1.82.2.2 -r1.82.2.3 --- Mailman/Cgi/admin.py 2001/01/03 16:47:47 1.82.2.2 +++ Mailman/Cgi/admin.py 2001/05/03 21:03:48 1.82.2.3 @@ -18,11 +18,13 @@ """ +import sys import os import cgi import string import types import rfc822 +import signal from Mailman import Utils from Mailman import MailList @@ -63,53 +65,86 @@ # get the list object listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: FormatAdminOverview('No such list %s' % listname) syslog('error', 'Someone tried to access the admin interface for a ' 'non-existent list: %s' % listname) return + + if len(parts) == 1: + category = 'general' + category_suffix = '' + else: + category = parts[1] + category_suffix = category + + # If the user is not authenticated, we're done. + cgidata = cgi.FieldStorage(keep_blank_values=1) try: - if len(parts) == 1: - category = 'general' - category_suffix = '' - else: - category = parts[1] - category_suffix = category - - # If the user is not authenticated, we're done. - cgidata = cgi.FieldStorage(keep_blank_values=1) - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admin', e.message) - return - - # Is this a log-out request? - if category == 'logout': - print mlist.ZapCookie('admin') - Auth.loginpage(mlist, 'admin', frontpage=1) - return - - if category not in map(lambda x: x[0], CATEGORIES): - category = 'general' - - # is the request for variable details? - varhelp = None - if cgidata.has_key('VARHELP'): - varhelp = cgidata['VARHELP'].value - elif cgidata.has_key('request_login') and \ - os.environ.get('QUERY_STRING'): - # POST methods, even if their actions have a query string, don't - # get put into FieldStorage's keys :-( - qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') - if qs and type(qs) == types.ListType: - varhelp = qs[0] - if varhelp: - FormatOptionHelp(doc, varhelp, mlist) - print doc.Format(bgcolor="#ffffff") - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admin', e.message) + return + + # Is this a log-out request? + if category == 'logout': + print mlist.ZapCookie('admin') + Auth.loginpage(mlist, 'admin', frontpage=1) + return + + if category not in map(lambda x: x[0], CATEGORIES): + category = 'general' + # is the request for variable details? + varhelp = None + if cgidata.has_key('VARHELP'): + varhelp = cgidata['VARHELP'].value + elif cgidata.has_key('request_login') and \ + os.environ.get('QUERY_STRING'): + # POST methods, even if their actions have a query string, don't + # get put into FieldStorage's keys :-( + qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') + if qs and type(qs) == types.ListType: + varhelp = qs[0] + if varhelp: + FormatOptionHelp(doc, varhelp, mlist) + print doc.Format(bgcolor="#ffffff") + return + + # From this point on, the MailList object must be locked. However, we + # must release the lock no matter how we exit. try/finally isn't + # enough, because of this scenario: user hits the admin page which may + # take a long time to render; user gets bored and hits the browser's + # STOP button; browser shuts down socket; server tries to write to + # broken socket and gets a SIGPIPE. Under Apache 1.3/mod_cgi, Apache + # catches this SIGPIPE (I presume it is buffering output from the cgi + # script), then turns around and SIGTERMs the cgi process. Apache + # waits three seconds and then SIGKILLs the cgi process. We /must/ + # catch the SIGTERM and do the most reasonable thing we can in as + # short a time period as possible. If we get the SIGKILL we're + # screwed (because its uncatchable and we'll have no opportunity to + # clean up after ourselves). + # + # This signal handler catches the SIGTERM and unlocks the list. The + # effect of this is that the changes made to the MailList object will + # be aborted, which seems like the only sensible semantics. + # + # BAW: This may not be portable to other web servers or cgi execution + # models. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + if cgidata.has_key('bounce_matching_headers'): pairs = mlist.parse_matching_header_opt() @@ -135,8 +170,12 @@ FormatConfiguration(doc, mlist, category, category_suffix, cgidata) print doc.Format(bgcolor="#ffffff") - finally: mlist.Save() + finally: + # Now be sure to unlock the list. It's okay if we get a signal here + # because essentially, the signal handler will do the same thing. And + # unlocking is unconditional, so it's not an error if we unlock while + # we're already unlocked. mlist.Unlock() Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.36.2.1 retrieving revision 1.36.2.4 diff -u -r1.36.2.1 -r1.36.2.4 --- Mailman/Cgi/admindb.py 2001/03/03 06:02:01 1.36.2.1 +++ Mailman/Cgi/admindb.py 2001/05/04 15:54:23 1.36.2.4 @@ -16,10 +16,12 @@ """Produce and process the pending-approval items for a list.""" +import sys import os import string import types import cgi +import signal from errno import ENOENT from Mailman import mm_cfg @@ -62,7 +64,7 @@ return # now that we have the list name, create the list object try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: handle_no_list(doc, 'No such list %s

              ' % listname) syslog('error', 'No such list "%s": %s\n' % (listname, e)) @@ -71,14 +73,34 @@ # now we must authorize the user to view this page, and if they are, to # handle both the printing of the current outstanding requests, and the # selected actions + cgidata = cgi.FieldStorage() try: - cgidata = cgi.FieldStorage() - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admindb', e.message) - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admindb', e.message) + return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + # If this is a form submission, then we'll process the requests and # print the results. otherwise (there are no keys in the form), we'll # print out the list of pending requests @@ -91,8 +113,8 @@ PrintRequests(mlist, doc) text = doc.Format(bgcolor="#ffffff") print text - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/handle_opts.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/handle_opts.py,v retrieving revision 1.30 retrieving revision 1.30.2.2 diff -u -r1.30 -r1.30.2.2 --- Mailman/Cgi/handle_opts.py 2000/11/09 16:19:03 1.30 +++ Mailman/Cgi/handle_opts.py 2001/05/03 21:05:06 1.30.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import mm_cfg from Mailman import Utils @@ -61,7 +62,7 @@ user = parts[1] try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) @@ -69,10 +70,30 @@ syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, user, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/subscribe.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v retrieving revision 1.29 retrieving revision 1.29.2.1 diff -u -r1.29 -r1.29.2.1 --- Mailman/Cgi/subscribe.py 2000/09/29 00:05:05 1.29 +++ Mailman/Cgi/subscribe.py 2001/05/03 21:05:43 1.29.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import Utils from Mailman import MailList @@ -41,18 +42,38 @@ listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) - mlist.IsListInitialized() + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) print doc.Format(bgcolor="#ffffff") syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.5 retrieving revision 1.5.2.6 diff -u -r1.5.2.5 -r1.5.2.6 --- admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 +++ admin/www/download.ht 2001/05/03 21:09:36 1.5.2.6 @@ -65,9 +65,9 @@

              Downloading

              Version -(2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:

                Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.7 retrieving revision 1.6.2.8 diff -u -r1.6.2.7 -r1.6.2.8 --- admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 +++ admin/www/download.html 2001/05/03 21:09:36 1.6.2.8 @@ -1,6 +1,6 @@ - + 2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:
                  From josh@ernestallen.com Mon May 7 19:01:03 2001 From: josh@ernestallen.com (Joshua Erdman) Date: Mon, 7 May 2001 11:01:03 -0700 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <001101c0d71f$af1d60b0$02930440@tron> When you say to CD into our sourcetree, is that the location where I originally compiled mailman or is that where I have the current working copy of the software? Joshua Erdman Ernest & Allen, Inc. CIO/Network Systems Administrator Tel (805) 781-0317 Fax (805) 781-0725 josh@ernestallen.com -----Original Message----- From: mailman-announce-admin@python.org [mailto:mailman-announce-admin@python.org]On Behalf Of Barry A. Warsaw Sent: Monday, May 07, 2001 9:24 AM To: mailman-announce@python.org Cc: mailman-developers@python.org Subject: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 Folks, I've just released Mailman 2.0.5 which fixes a problem with stale lock files that can occur under certain situations when the user hits the `Stop' button on their browser. These stale lock files can cause mailing lists to be inaccessible for long periods of time (until the stale lock file times out or is manually removed). As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.4. You /must/ update your source to 2.0.4 before applying the 2.0.5 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.5 source tree and apply it like so: % patch -p0 < mailman-2.0.4-2.0.5.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net My thanks to those of you who gave the 2.0.5 pre-release a try! Enjoy, -Barry Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.5 retrieving revision 1.25.2.6 diff -u -r1.25.2.5 -r1.25.2.6 --- NEWS 2001/04/18 10:45:54 1.25.2.5 +++ NEWS 2001/05/03 21:06:56 1.25.2.6 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.5 (04-May-2001) + + Fix a lock stagnation problem that can result when the user hits + the `stop' button on their browser during a write operation that + can take a long time (e.g. hitting the membership management admin + page). + 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.4 retrieving revision 1.20.2.5 diff -u -r1.20.2.4 -r1.20.2.5 --- Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 +++ Mailman/Version.py 2001/05/03 20:58:19 1.20.2.5 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.4" +VERSION = "2.0.5" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 4 +MICRO_REV = 5 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.82.2.2 retrieving revision 1.82.2.3 diff -u -r1.82.2.2 -r1.82.2.3 --- Mailman/Cgi/admin.py 2001/01/03 16:47:47 1.82.2.2 +++ Mailman/Cgi/admin.py 2001/05/03 21:03:48 1.82.2.3 @@ -18,11 +18,13 @@ """ +import sys import os import cgi import string import types import rfc822 +import signal from Mailman import Utils from Mailman import MailList @@ -63,53 +65,86 @@ # get the list object listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: FormatAdminOverview('No such list %s' % listname) syslog('error', 'Someone tried to access the admin interface for a ' 'non-existent list: %s' % listname) return + + if len(parts) == 1: + category = 'general' + category_suffix = '' + else: + category = parts[1] + category_suffix = category + + # If the user is not authenticated, we're done. + cgidata = cgi.FieldStorage(keep_blank_values=1) try: - if len(parts) == 1: - category = 'general' - category_suffix = '' - else: - category = parts[1] - category_suffix = category - - # If the user is not authenticated, we're done. - cgidata = cgi.FieldStorage(keep_blank_values=1) - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admin', e.message) - return - - # Is this a log-out request? - if category == 'logout': - print mlist.ZapCookie('admin') - Auth.loginpage(mlist, 'admin', frontpage=1) - return - - if category not in map(lambda x: x[0], CATEGORIES): - category = 'general' - - # is the request for variable details? - varhelp = None - if cgidata.has_key('VARHELP'): - varhelp = cgidata['VARHELP'].value - elif cgidata.has_key('request_login') and \ - os.environ.get('QUERY_STRING'): - # POST methods, even if their actions have a query string, don't - # get put into FieldStorage's keys :-( - qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') - if qs and type(qs) == types.ListType: - varhelp = qs[0] - if varhelp: - FormatOptionHelp(doc, varhelp, mlist) - print doc.Format(bgcolor="#ffffff") - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admin', e.message) + return + + # Is this a log-out request? + if category == 'logout': + print mlist.ZapCookie('admin') + Auth.loginpage(mlist, 'admin', frontpage=1) + return + + if category not in map(lambda x: x[0], CATEGORIES): + category = 'general' + # is the request for variable details? + varhelp = None + if cgidata.has_key('VARHELP'): + varhelp = cgidata['VARHELP'].value + elif cgidata.has_key('request_login') and \ + os.environ.get('QUERY_STRING'): + # POST methods, even if their actions have a query string, don't + # get put into FieldStorage's keys :-( + qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') + if qs and type(qs) == types.ListType: + varhelp = qs[0] + if varhelp: + FormatOptionHelp(doc, varhelp, mlist) + print doc.Format(bgcolor="#ffffff") + return + + # From this point on, the MailList object must be locked. However, we + # must release the lock no matter how we exit. try/finally isn't + # enough, because of this scenario: user hits the admin page which may + # take a long time to render; user gets bored and hits the browser's + # STOP button; browser shuts down socket; server tries to write to + # broken socket and gets a SIGPIPE. Under Apache 1.3/mod_cgi, Apache + # catches this SIGPIPE (I presume it is buffering output from the cgi + # script), then turns around and SIGTERMs the cgi process. Apache + # waits three seconds and then SIGKILLs the cgi process. We /must/ + # catch the SIGTERM and do the most reasonable thing we can in as + # short a time period as possible. If we get the SIGKILL we're + # screwed (because its uncatchable and we'll have no opportunity to + # clean up after ourselves). + # + # This signal handler catches the SIGTERM and unlocks the list. The + # effect of this is that the changes made to the MailList object will + # be aborted, which seems like the only sensible semantics. + # + # BAW: This may not be portable to other web servers or cgi execution + # models. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + if cgidata.has_key('bounce_matching_headers'): pairs = mlist.parse_matching_header_opt() @@ -135,8 +170,12 @@ FormatConfiguration(doc, mlist, category, category_suffix, cgidata) print doc.Format(bgcolor="#ffffff") - finally: mlist.Save() + finally: + # Now be sure to unlock the list. It's okay if we get a signal here + # because essentially, the signal handler will do the same thing. And + # unlocking is unconditional, so it's not an error if we unlock while + # we're already unlocked. mlist.Unlock() Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.36.2.1 retrieving revision 1.36.2.4 diff -u -r1.36.2.1 -r1.36.2.4 --- Mailman/Cgi/admindb.py 2001/03/03 06:02:01 1.36.2.1 +++ Mailman/Cgi/admindb.py 2001/05/04 15:54:23 1.36.2.4 @@ -16,10 +16,12 @@ """Produce and process the pending-approval items for a list.""" +import sys import os import string import types import cgi +import signal from errno import ENOENT from Mailman import mm_cfg @@ -62,7 +64,7 @@ return # now that we have the list name, create the list object try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: handle_no_list(doc, 'No such list %s

                  ' % listname) syslog('error', 'No such list "%s": %s\n' % (listname, e)) @@ -71,14 +73,34 @@ # now we must authorize the user to view this page, and if they are, to # handle both the printing of the current outstanding requests, and the # selected actions + cgidata = cgi.FieldStorage() try: - cgidata = cgi.FieldStorage() - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admindb', e.message) - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admindb', e.message) + return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + # If this is a form submission, then we'll process the requests and # print the results. otherwise (there are no keys in the form), we'll # print out the list of pending requests @@ -91,8 +113,8 @@ PrintRequests(mlist, doc) text = doc.Format(bgcolor="#ffffff") print text - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/handle_opts.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/handle_opts.py,v retrieving revision 1.30 retrieving revision 1.30.2.2 diff -u -r1.30 -r1.30.2.2 --- Mailman/Cgi/handle_opts.py 2000/11/09 16:19:03 1.30 +++ Mailman/Cgi/handle_opts.py 2001/05/03 21:05:06 1.30.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import mm_cfg from Mailman import Utils @@ -61,7 +62,7 @@ user = parts[1] try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) @@ -69,10 +70,30 @@ syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, user, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/subscribe.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v retrieving revision 1.29 retrieving revision 1.29.2.1 diff -u -r1.29 -r1.29.2.1 --- Mailman/Cgi/subscribe.py 2000/09/29 00:05:05 1.29 +++ Mailman/Cgi/subscribe.py 2001/05/03 21:05:43 1.29.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import Utils from Mailman import MailList @@ -41,18 +42,38 @@ listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) - mlist.IsListInitialized() + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) print doc.Format(bgcolor="#ffffff") syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.5 retrieving revision 1.5.2.6 diff -u -r1.5.2.5 -r1.5.2.6 --- admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 +++ admin/www/download.ht 2001/05/03 21:09:36 1.5.2.6 @@ -65,9 +65,9 @@

                  Downloading

                  Version -(2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:

                    Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.7 retrieving revision 1.6.2.8 diff -u -r1.6.2.7 -r1.6.2.8 --- admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 +++ admin/www/download.html 2001/05/03 21:09:36 1.6.2.8 @@ -1,6 +1,6 @@ - + 2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:
                      _______________________________________________ Mailman-announce mailing list Mailman-announce@python.org http://mail.python.org/mailman/listinfo/mailman-announce From barry@digicool.com Mon May 7 19:05:08 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 7 May 2001 14:05:08 -0400 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 References: <15094.52272.753043.181192@anthem.wooz.org> <001101c0d71f$af1d60b0$02930440@tron> Message-ID: <15094.58324.448018.842017@anthem.wooz.org> >>>>> "JE" == Joshua Erdman writes: JE> When you say to CD into our sourcetree, is that the location JE> where I originally compiled mailman or is that where I have JE> the current working copy of the software? It's the directory where you original did the "configure; make install" I.e. not /home/mailman. -Barry From ricardo@rixhq.nu Mon May 7 22:37:10 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Mon, 7 May 2001 23:37:10 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010501104121.P16486@xs4all.nl>; from thomas@xs4all.net on Tue, May 01, 2001 at 10:41:21AM +0200 References: <20010428123324.A1102@rix.rixhq.nu> <20010428132341.C1102@rix.rixhq.nu> <20010501104121.P16486@xs4all.nl> Message-ID: <20010507233710.I1983@rix.rixhq.nu> I finally got a bit of time to respond to this thread... On Tue, May 01, 2001 at 10:41:21AM +0200, Thomas Wouters wrote: > > > Anyway my point is that now I'm getting some complaints from members about > > > receiving empty digests (it only says the number of posts which should be in > > > there) I'm not sure yet what they are missing but I was wondering if I > > > could have messed things about by interrupting the process w/o a m.Save()? > > uh oh please don't tell me that when mailman sends out digests, they travel through the > > /etc/aliases addresses cause that would mean a neat little perl script I > It depends on the delivery method you chose. If you use the Sendmail module, > it'll probably pass it through /etc/aliases. If you use the SMTP module and > the localhost as delivery point, it'll pass through /etc/aliases too. It's > damned easy to test, though: disable the filter, make a new digest list, > subscribe yourself to it, and mail ;) After a few days I have to conclude that the problem is probably on the client side... I'm using the SMTPDirect/localhost but the MIME digests are NOT filtered out by the perl script (I changed my own subscription from plain to digest and it arrives perfectly in my mailbox)... One of the complaints was from somebody using an Hotmail account but I doubt that hotmail could have any problems with mime digest (I don't really feel like trying it out with hotmail myself... as a list admin you develop a certain hate feeling towards unreliable erm... free email services ;-( ) OTH I was just thinking that some users are not smart enough to notice that the actual messages are at the bottom of the message as a bunch of icons or whatever way their email client displays mime digest... wouldn't surprise me to be honest... Regards, Ricardo -- International Janet Jackson fanclub called MISS JANET. For more information write to: Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands Email: fanclub@miss-janet.com Check out our website: http://miss-janet.com From josh@ernestallen.com Tue May 8 00:56:44 2001 From: josh@ernestallen.com (Joshua Erdman) Date: Mon, 7 May 2001 16:56:44 -0700 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <002801c0d751$5f81f890$02930440@tron> Since installing Mailman I have noticed the size of my backups increasing steadily. I did some investigating and noticed the size of the log file in the mailman/logs directory. By adding a few lines of code to your /etc/logrotate.conf file you can have these log files rotated just like all the log files in /var/logs Some quick info about the /etc/logrotate.conf file At the top are the global settings with a comment for each one Mine had: -- Beginning of lines added to logrotate.conf -- # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # e-mail errors to root errors root # create new (empty) log files after rotating old ones with the same # security settings as the ones already rotated. create "/home/mailman/logs/post" { } "/home/mailman/logs/smtp" { compress } "/home/mailman/logs/smtp-failure" { } "/home/mailman/logs/subscribe" { } "/home/mailman/logs/bounce" { } "/home/mailman/logs/vette" { } "/home/mailman/logs/qrunner" { } "/home/mailman/logs/error" { } "/home/mailman/logs/digest" { } --End logrotate.conf If you have any questions about setting up logrotate or extra features, look at your man pages. Joshua Erdman Ernest & Allen, Inc. CIO/Network Systems Administrator Tel (805) 781-0317 Fax (805) 781-0725 josh@ernestallen.com From trey@anvils.org Tue May 8 05:16:24 2001 From: trey@anvils.org (Trey Valenta) Date: Mon, 7 May 2001 21:16:24 -0700 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: "Joshua Erdman" "[Mailman-Developers] Rotating Logs with Mailman" (May 7, 16:56) Message-ID: <20010508041624.13939.qmail@zipcon.net> On 2001 May 7, 16:56, "Joshua Erdman" wrote: } Subject: [Mailman-Developers] Rotating Logs with Mailman > Since installing Mailman I have noticed the size of my backups increasing > steadily. I did some investigating and noticed the size of the log file in > the mailman/logs directory. By adding a few lines of code to your > /etc/logrotate.conf file you can have these log files rotated just like all > the log files in /var/logs > Ummm..... you're assuming that everyone runs RedHat and has a logrotate.conf. -- trey valenta trey@anvils.org seattle (maybe a) random quote--v Nature always sides with the hidden flaw. From chuqui@plaidworks.com Tue May 8 06:07:21 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 07 May 2001 22:07:21 -0700 Subject: [Mailman-Developers] InSTALL questions... Message-ID: Barry, I'm upgrading to 2.0.5, and a couple of thoughts... In the INSTALL file: You must have the Python interpreter installed somewhere on your system. Currently Python 1.5.2 or later is required (Python 2.0 should work fine). For information about obtaining Python source code, RPM packages, or pre-compiled binaries please see: Do you want to now recommend Python 2.0 over 1.5.2? Or say something more definitive than "should work fine"? Isn't 2.0 the recommended version now? There's a similar comment in README The UPGRADING file stops at 2.0.2. It probably makes sense to add a "if you're upgrading from any 2.0 release...." Looks good so far... From tollef@add.no Tue May 8 07:48:16 2001 From: tollef@add.no (Tollef Fog Heen) Date: 08 May 2001 08:48:16 +0200 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: <20010508041624.13939.qmail@zipcon.net> References: <20010508041624.13939.qmail@zipcon.net> Message-ID: <8766fc2v67.fsf@arabella.intern.opera.no> * Trey Valenta | Ummm..... you're assuming that everyone runs RedHat and has a | logrotate.conf. Debian has logrotate as well. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From richarde@eskom.co.za Tue May 8 08:46:51 2001 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Tue, 08 May 2001 09:46:51 +0200 Subject: [Mailman-Developers] Explanation required after upgrade to 2.0.5 Message-ID: I have just upgraded mailman from 1.1 to 2.0.5 - everything went smoothly, = but I have some minor issues though. 1) When the news gate service tries to connect to a down NNTP server, ugly = messages are logged in the error log. Maybe the fact should rather just be = logged in the fromusenet log? Here is an example: Traceback (innermost last): File "/home/mailman/cron/gate_news", line 222, in ? main() File "/home/mailman/cron/gate_news", line 203, in main process_lists(lock) File "/home/mailman/cron/gate_news", line 148, in process_lists conn, first, last =3D open_newsgroup(mlist) File "/home/mailman/cron/gate_news", line 75, in open_newsgroup password=3Dmm_cfg.NNTP_PASSWORD) File "/home/mailman/Mailman/pythonlib/nntplib.py", line 111, in __init__ self.sock.connect((self.host, self.port)) socket.error: (111, 'Connection refused') 2) I get another funny error also from the news gateway. I cannot explain = it though: Traceback (innermost last): File "/home/mailman/cron/gate_news", line 222, in ? main() File "/home/mailman/cron/gate_news", line 203, in main process_lists(lock) File "/home/mailman/cron/gate_news", line 148, in process_lists conn, first, last =3D open_newsgroup(mlist) File "/home/mailman/cron/gate_news", line 75, in open_newsgroup password=3Dmm_cfg.NNTP_PASSWORD) File "/home/mailman/Mailman/pythonlib/nntplib.py", line 114, in __init__ self.welcome =3D self.getresp() File "/home/mailman/Mailman/pythonlib/nntplib.py", line 180, in getresp resp =3D self.getline() File "/home/mailman/Mailman/pythonlib/nntplib.py", line 172, in getline if not line: raise EOFError EOFError 3) Something is funny with bounce detection. My test list has the = following bounce options: Minimum number of posts to the list since members first bounce before we consider removing them from the list =3D 3 Action when critical or excessive bounces are detected =3D Remove and = notify me The list also requires post approval from the moderator I get this in the log when sending a couple of message to the list with a = bogus address that I added manually: May 07 17:41:00 2001 (8803) Test: kajshd@eskom.co.za - first May 08 09:01:01 2001 (29662) Test: kajshd@eskom.co.za - 1 more allowed = over 376799 secs May 08 09:01:01 2001 (29662) Test: kajshd@eskom.co.za - 1 more allowed = over 376799 secs May 08 09:15:01 2001 (32675) Test: kajshd@eskom.co.za - 0 more allowed = over 375958 secs May 08 09:24:01 2001 (2018) Test: kajshd@eskom.co.za - 0 more allowed over = 375418 secs I don't understand the sequence of numbers - why 0 0 then 1 1? The address = does not get removed after three failures. I have sent more tests and they = all say 0 more allowed - what gives? -- Richard Ellerbrock richarde@eskom.co.za From richarde@eskom.co.za Tue May 8 08:51:51 2001 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Tue, 08 May 2001 09:51:51 +0200 Subject: [Mailman-Developers] Rotating Logs with Mailman Message-ID: I don't think it should be a problem to add it as a contrib to mailman - I = have also written such a script and think it would be most useful if = something was included. There is a better way of doing it though. Rather just drop a dedicated = script in the /etc/logrotate.d directory called mailman. These scripts are = automagically executed when it is time to do logrotation. No need to = modify the main logrotate.conf file. -- Richard Ellerbrock richarde@eskom.co.za >>> Tollef Fog Heen 2001/05/08 08:48:16 >>> * Trey Valenta=20 | Ummm..... you're assuming that everyone runs RedHat and has a | logrotate.conf. Debian has logrotate as well. --=20 Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org=20 http://mail.python.org/mailman/listinfo/mailman-developers From claw@kanga.nu Tue May 8 09:41:03 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 08 May 2001 01:41:03 -0700 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: Message from Tollef Fog Heen of "08 May 2001 08:48:16 +0200." <8766fc2v67.fsf@arabella.intern.opera.no> References: <20010508041624.13939.qmail@zipcon.net> <8766fc2v67.fsf@arabella.intern.opera.no> Message-ID: <4094.989311263@kanga.nu> On 08 May 2001 08:48:16 +0200 Tollef Fog Heen wrote: > * Trey Valenta | Ummm..... you're assuming that everyone runs > RedHat and has a | logrotate.conf. > Debian has logrotate as well. Debian's Mailman package automatically inserts the appropriate logrotate files as part of the package install. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From barry@digicool.com Tue May 8 14:51:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 8 May 2001 09:51:40 -0400 Subject: [Mailman-Developers] InSTALL questions... References: Message-ID: <15095.63980.52400.171288@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Barry, I'm upgrading to 2.0.5, and a couple of thoughts... CVR> In the INSTALL file: CVR> You must have the Python interpreter installed somewhere CVR> on your system. Currently Python 1.5.2 or later is required CVR> (Python 2.0 should work fine). For information about CVR> obtaining Python source code, RPM packages, or pre-compiled CVR> binaries please see: CVR> Do you want to now recommend Python 2.0 over 1.5.2? Or say CVR> something more definitive than "should work fine"? Isn't 2.0 CVR> the recommended version now? I'd /recommend/ Python 2.0 or 2.1, but for the Mailman 2.0.x series only Python 1.5.2 is required. It's getting harder and harder to work with the Mailman 2.0.x codebase, but I still don't want to force people to upgrade their Python just to get the next micro maintenance release of Mailman. Python 2.0 will definitely be required for Mailman 2.1 and there's a slim chance I'll require Python 2.1 (but doubtful). Still, I should clarify this in the INSTALL, README, and UPGRADING. CVR> There's a similar comment in README CVR> The UPGRADING file stops at 2.0.2. It probably makes sense to CVR> add a "if you're upgrading from any 2.0 release...." CVR> Looks good so far... Thanks, -Barry From jra@baylink.com Tue May 8 15:37:01 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 8 May 2001 10:37:01 -0400 Subject: [Mailman-Developers] Rotating Logs with Mailman In-Reply-To: <20010508041624.13939.qmail@zipcon.net>; from Trey Valenta on Mon, May 07, 2001 at 09:16:24PM -0700 References: <20010508041624.13939.qmail@zipcon.net> Message-ID: <20010508103701.61384@scfn.thpl.lib.fl.us> On Mon, May 07, 2001 at 09:16:24PM -0700, Trey Valenta wrote: > On 2001 May 7, 16:56, "Joshua Erdman" wrote: > } Subject: [Mailman-Developers] Rotating Logs with Mailman > > Since installing Mailman I have noticed the size of my backups increasing > > steadily. I did some investigating and noticed the size of the log file in > > the mailman/logs directory. By adding a few lines of code to your > > /etc/logrotate.conf file you can have these log files rotated just like all > > the log files in /var/logs > > Ummm..... you're assuming that everyone runs RedHat and has a > logrotate.conf. They don't? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From joker@aol.com Wed May 9 04:03:41 2001 From: joker@aol.com (joker@aol.com) Date: Tue, 8 May 2001 23:03:41 -0400 (EDT) Subject: [Mailman-Developers] Hi Message-ID: <200105090303.XAA14655@mclean.mail.mindspring.net> Hi From barry@digicool.com Wed May 9 06:45:36 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 01:45:36 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web Message-ID: <15096.55680.384791.933908@anthem.wooz.org> Last night I got inspired to add back the through-the-web creation and deletion of mailing lists. I've now got this working for Postfix and can work with other MTAs with a little help from y'all. I will soon be checking all this code into the 2.1 codebase, so watch mailman-checkins shortly. (And hey, it only took 24 hours from inception to completion! :). Apologies in advance for the length of this message. First, there is a new pseudo-role[1] called `list creator'. There is a separate, global list creator password, similar to but different than the site admin password. This is because list creation is a site-wide operation, but I don't want to have to give out the site admin password to someone who may only have list creation duties. Needless to say, the site admin can create lists through the web too. You set the list creator's password by using mmsitepass with the -c option. Let's say Mailman is installed at http://yoursite.com/mailman, then the list creation page is at http://yoursite.com/mailman/create which is linked to from the admin overview page (but not the listinfo overview page). The create page requires you to enter the name of your list, the email address of the initial list owner, the initial list password (with confirmation), and the list creator's password. There is then a "Create" button to submit the form. Assuming everything checks out, the new list is created, and the results page gives you three links to follow from there (go to the list's info page, the list's admin page, or create another list). Deleting a list is done from the list's admin page. There is now another link under "Other Administrative Activities" that says "Delete this list (requires confirmation)". Click on that and you're brought to a page for confirmation of the list deletion operation. You have a radio button to choose whether the archives should be deleted or not (the default is not), and you're prompted for the list admin password[2]. There's a link to cancel the deletion and return to the list's admin page, and a button to actually do the list deletion. For bonus, the site administrator can inhibit the ability for individual list owners to delete their lists through the web by setting OWNERS_CAN_DELETE_THEIR_OWN_LISTS = 0 in mm_cfg.py. Do this, and the link is not shown in the "Other Administrative Activities" list, and the rmlist cgi will error out every time. The current default for OWNERS_CAN_DELETE_THEIR_OWN_LISTS is 0, but that may change to 1 before the final release. The disadvantage is that with this variable set to 0, list deletion must be done via the command line script. Now, how to integrate this with MTAs? One reason why ttw list creation and deletion hasn't been (re-)added to Mailman until now is that you typically have to do some manual and difficult crud like edit an /etc/aliases file and run `newaliases' (as root!). I've figured a way around this with Postfix, and of course Exim can be configured to automatically recognize new mailing lists, so I figured it was time to do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst yourselves will contribute the code to glue this together for other mailers. Here's how I solved it for Postfix; this is outlined in a new README.POSTFIX file. Postfix has a configuration variable called `alias_maps' which tells it where to look for local delivery address associations. It has another variable called `alias_databases' which tells it which files to rebuild when invoked as newaliases. For each of these you can specify the type of map database the file is kept as. One of these choices is `hash', which is really a BSD dbhash file. Python has a dbhash module which nicely handles reading and writing dbhash files (and it should be enabled by default in Python 2.x, if your system has Berkeley DB installed, as most Linux distros ought to). It's moderately well-published what Postfix expects as entries in the dbhash (and it's easy to figure out by dumping a newaliases generated .db file) so, when creating a new list, Mailman can add the necessary keys and values to make Postfix happy. Let's say Mailman is installed as /home/mailman and writes its new list alias entries to the dbhash file at /home/mailman/data/aliases.db. By adding "hash:/home/mailman/data/aliases" to your Postfix's alias_maps variable, Postfix will automatically deliver to your new list. Deleting is as simple as removing the keys from the dbhash. Note that you do /not/ want to add this file to alias_databases since newaliases won't be touching it. So this works great, but there's a catch! Postfix will invoke the filter programs under the uid of the owner of the aliases.db file, unless that's root, in which case it'll invoke it as the user defined in the default_privs variable (by default `nobody'). And of course the gid has to match what you specify in --with-mail-gid or Mailman's mail wrapper will complain. The trick is to touch the alias.db file as root, set the group owner to mailman, and make sure the file is user and group writable. Now, when Mailman adds new keys to aliases.db, the user ownership will remain as root, so Postfix invokes it correctly as nobody. But because aliases.db is group-owned by mailman, the cgi processes can write to the file. And no setuid-root script in sight. I've tested this and it works like a charm. (Of course, all this is described in cookbook form without the gory details in README.POSTFIX. Also, I like this approach much better than the luser_relay hack I posted about a while ago.) There's one last bit of glue, and here's where you come in (I'm speaking to the one of you who is still reading this. :). There's a new variable in Defaults.py.in called MTA which must point to a module in the Mailman/MTA directory. This implements the MTA-specific operations needed when creating or deleting a list. The API is that this module should provide two functions: create() and remove() both of which take a MailList object. They should do whatever is necessary to inform the MTA that it's alias database has changed. For Postfix it's really not a lot of code[3]. For Exim, I predict "MTA = None" in mm_cfg.py will Do The Right Thing, since nothing special has to be done. I've no idea at this time what Sendmail, Qmail, or any other MTA will require, and I'm hoping those of you who use those mailers will be able to donate a module. Phew, that's it. I need sleep. I'm very interested in getting some feedback, especially for those hearty souls who can check out the current codebase, and give it a whirl. I'm no doubt forgetting some important details, but it sure has been fun. :) Enjoy, -Barry [1] I call it a pseudo-role because eventually this will be a role that can be given to specific users (once there's a Real User Database). [2] Because list deletion is not handled by the admin.py cgi script, it isn't protected by the normal admin login screen. I could (and may) add this extra authentication step, but I'll probably still keep the list password requirement on the deletion page as a strong confirmation of the list owner's intention. [3] There's one caveat: because I don't want to have to include a setuid-root script, the Postfix.py module doesn't call `postfix reload'. This command has to be done as root. The tradeoff is that Postfix will take about a minute to recognize its alias database has changed. To me that's an acceptable limitation. From barry@digicool.com Wed May 9 07:47:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 02:47:49 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <15096.59413.551202.308904@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> I will soon be checking all this code into the 2.1 codebase, BAW> so watch mailman-checkins shortly. I'm too tired to finish the checkins tonight. The committed trunk is probably unstable at the moment, so even though you're as flush with excitement as I , please wait until tomorrow before doing your cvs update. G'night, -Barry From joker@aol.com Wed May 9 08:55:08 2001 From: joker@aol.com (joker@aol.com) Date: Wed, 9 May 2001 03:55:08 -0400 (EDT) Subject: [Mailman-Developers] Hi Message-ID: <200105090755.DAA14585@smtp6.mindspring.com> Hi From thomas@xs4all.net Wed May 9 12:53:47 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 9 May 2001 13:53:47 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15096.55680.384791.933908@anthem.wooz.org>; from barry@digicool.com on Wed, May 09, 2001 at 01:45:36AM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010509135347.H16486@xs4all.nl> On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: > The create page requires you to enter the name of your list, the email > address of the initial list owner, the initial list password (with > confirmation), and the list creator's password. There is then a > "Create" button to submit the form. What about a 'send list creation message' ? And a 'auto-generate password' button ? In my eyes, typically, the person creating the list won't be the list owner him/herself, so those things make sense to me. And what about the domain the list should be created on ? > Deleting a list is done from the list's admin page. There is now > another link under "Other Administrative Activities" that says "Delete > this list (requires confirmation)". Click on that and you're brought > to a page for confirmation of the list deletion operation. You have a > radio button to choose whether the archives should be deleted or not > (the default is not), and you're prompted for the list admin > password[2]. There's a link to cancel the deletion and return to the > list's admin page, and a button to actually do the list deletion. Why not have the 'delete a list' option be on the list creation page as well (make it the 'site administration page' or something.) Again, this won't make sense everywhere, but I'd *love* to be able to give our Sales dept. the list creator password to have them create and destroy lists, without giving them the site password. > Here's how I solved it for Postfix; this is outlined in a new > README.POSTFIX file. You'll want to add checks for the permissios of this file to bin/check_perms, just to be sure. If not run as root, it can't fix it automatically, but it can whine incessantly. > There's one last bit of glue, and here's where you come in (I'm > speaking to the one of you who is still reading this. :). Hi, Barry ! =) > There's a new variable in Defaults.py.in called MTA which must point > to a module in the Mailman/MTA directory. This implements the > MTA-specific operations needed when creating or deleting a list. > The API is that this module should provide two functions: create() > and remove() both of which take a MailList object. They should do > whatever is necessary to inform the MTA that it's alias database has > changed. For Postfix it's really not a lot of code[3]. > For Exim, I predict "MTA = None" in mm_cfg.py will Do The Right Thing, > since nothing special has to be done. I've no idea at this time what > Sendmail, Qmail, or any other MTA will require, and I'm hoping those > of you who use those mailers will be able to donate a module. Sendmail can work in the same way as Postfix, I believe. I'm not sure if you can tell it to use more than one aliases.db file, but if it can, the only difference is the permissions with which the commands are executed. As far as I know, Sendmail also uses dbhash (hash or btree, depending on how you make them) so no problem there. There's another dimension to it, though. At XS4ALL we use a central database (currently MySQL, soon to be PostgresSQL) for all email aliases, and the list creation mechanism should insert the appropriate aliases into that as well as into the local database -- and they have to differ slightly. (local alias is, say, 'list@listXX.xs4all.nl', where XX is a growing number, but the global alias should be either list@xs4all.nl or list@domain.com, pointing to list@listXX.xs4all.nl). I could do this fairly easily by adapting the Sendmail (or Postfix) MTA module and placing it in the MTA directory under a different name. > [3] There's one caveat: because I don't want to have to include a > setuid-root script, the Postfix.py module doesn't call `postfix > reload'. This command has to be done as root. The tradeoff is that > Postfix will take about a minute to recognize its alias database has > changed. To me that's an acceptable limitation. A minute ? Heh. I doubt that's ever going to be a problem, most humans take a minute to read the resulting webpage, let alone that they compose and send a message inside that minute. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From tollef@add.no Wed May 9 13:08:04 2001 From: tollef@add.no (Tollef Fog Heen) Date: 09 May 2001 14:08:04 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <20010509135347.H16486@xs4all.nl> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509135347.H16486@xs4all.nl> Message-ID: <87g0eeu3mj.fsf@arabella.intern.opera.no> * Thomas Wouters | Sendmail can work in the same way as Postfix, I believe. I'm not sure | if you can tell it to use more than one aliases.db file, but if it | can, the only difference is the permissions with which the commands | are executed. As far as I know, Sendmail also uses dbhash (hash or | btree, depending on how you make them) so no problem there. IIRC, Sendmail will whine a lot if the group file or any directory up to it is writeable by anybody else than 'trusted' users. But it is certainly possible to have more than one alias file. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From richarde@eskom.co.za Wed May 9 14:44:44 2001 From: richarde@eskom.co.za (Richard Ellerbrock) Date: Wed, 09 May 2001 15:44:44 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web Message-ID: >On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: >> For Exim, I predict "MTA =3D None" in mm_cfg.py will Do The Right = Thing, >> since nothing special has to be done. I've no idea at this time what >> Sendmail, Qmail, or any other MTA will require, and I'm hoping those >> of you who use those mailers will be able to donate a module. > >Sendmail can work in the same way as Postfix, I believe. I'm not sure >if you can tell it to use more than one aliases.db file, but if it >can, the only difference is the permissions with which the commands >are executed. As far as I know, Sendmail also uses dbhash (hash or >btree, depending on how you make them) so no problem there. Yes sendmail can have multiple aliases files, just comma seperate them in = the sendmail.cf file. This is for 8.11.1 which I am running - do not know = for older versions. The only problem is that newaliases needs to be run as = root, or else modify the sendmail.cf file to automagically rebuild the = aliases files from time to time (you can specify the time out). I don't = know what happens though when broken alias files are fed in though - does = it just ignore the new file? -- Richard Ellerbrock richarde@eskom.co.za From jra@baylink.com Wed May 9 15:13:21 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 9 May 2001 10:13:21 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15096.55680.384791.933908@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 09, 2001 at 01:45:36AM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010509101321.61492@scfn.thpl.lib.fl.us> On Wed, May 09, 2001 at 01:45:36AM -0400, Barry A. Warsaw wrote: > Last night I got inspired to add back the through-the-web creation and > deletion of mailing lists. I've now got this working for Postfix and > can work with other MTAs with a little help from y'all. I will soon > be checking all this code into the 2.1 codebase, so watch > mailman-checkins shortly. (And hey, it only took 24 hours from > inception to completion! :). Ain't Python great? > Now, how to integrate this with MTAs? One reason why ttw list > creation and deletion hasn't been (re-)added to Mailman until now is > that you typically have to do some manual and difficult crud like edit > an /etc/aliases file and run `newaliases' (as root!). I've figured a > way around this with Postfix, and of course Exim can be configured to > automatically recognize new mailing lists, so I figured it was time to > do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst > yourselves will contribute the code to glue this together for other > mailers. IMHO, the proper solution for sendmail is for the admin to put an :include: in /etc/aliases pointing to /home/mailman/data/aliases, and rebuild that from scratch against the current list of lists every time that list changes. > It's moderately well-published what Postfix expects as entries in the > dbhash (and it's easy to figure out by dumping a newaliases generated > .db file) so, when creating a new list, Mailman can add the necessary > keys and values to make Postfix happy. Let's say Mailman is installed > as /home/mailman and writes its new list alias entries to the dbhash > file at /home/mailman/data/aliases.db. By adding > "hash:/home/mailman/data/aliases" to your Postfix's alias_maps > variable, Postfix will automatically deliver to your new list. > Deleting is as simple as removing the keys from the dbhash. > > Note that you do /not/ want to add this file to alias_databases since > newaliases won't be touching it. You're working at the 'compiled' level there, right? > There's one last bit of glue, and here's where you come in (I'm > speaking to the one of you who is still reading this. :). There's a > new variable in Defaults.py.in called MTA which must point to a module > in the Mailman/MTA directory. This implements the MTA-specific > operations needed when creating or deleting a list. The API is that > this module should provide two functions: create() and remove() both > of which take a MailList object. They should do whatever is necessary > to inform the MTA that it's alias database has changed. For Postfix > it's really not a lot of code[3]. I suspect you'll need one more: how to get the aliases database rebuilt when it's been changed. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Wed May 9 17:27:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 12:27:49 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> Message-ID: <15097.28677.242197.400892@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Ain't Python great? (ssshhh! they'll discover our secret weapon. :) JRA> IMHO, the proper solution for sendmail is for the admin to JRA> put an :include: in /etc/aliases pointing to JRA> /home/mailman/data/aliases, and rebuild that from scratch JRA> against the current list of lists every time that list JRA> changes. I'm really trying to avoid having to write the sendmail code myself. I just have too many scary flashbacks when I even think about mucking with sendmail. ;} Now that everything's checked in, folks can see how I'm doing it with Postfix, so I hope eventually someone will contribute a Mailman/MTA/Sendmail.py module. Until then, I'll work it so it does something simple. >> Deleting is as simple as removing the keys from the dbhash. >> Note that you do /not/ want to add this file to alias_databases >> since newaliases won't be touching it. JRA> You're working at the 'compiled' level there, right? If I understand what you're asking, yes. IOW, I don't muck about in the plain text aliases file, but I write directly to the file that newaliases would produce. >> They should do whatever is necessary to inform the MTA that >> it's alias database has changed. For Postfix it's really not a >> lot of code[3]. JRA> I suspect you'll need one more: how to get the aliases JRA> database rebuilt when it's been changed. That's the beauty of the Postfix approach: I'm modifying the database directly so it doesn't need to be rebuilt (i.e. no need to run newaliases). I don't even have to notify Postfix since it'll notice the change after one minute. >>>>> "TW" == Thomas Wouters writes: TW> What about a 'send list creation message' ? And a TW> 'auto-generate password' button ? In my eyes, typically, the TW> person creating the list won't be the list owner him/herself, TW> so those things make sense to me. The list creation message is always sent currently. Does it make sense to be able to inhibit that? The auto-generate password button is a good idea, I'll add that. TW> And what about the domain the list should be created on ? The domain in the url to the `create' script! Note that bin/newlist does need a domain switch, since the context can't be determined when run from the command line, but the create cgi doesn't have that problem. E.g. if I want to create a new list on python.org, I'd visit http://mail.python.org/mailman/create but if I wanted to create a new list on zope.org (a virtual host of a shared Mailman installation), I'd visit http://mail.zope.org/mailman/create. TW> Why not have the 'delete a list' option be on the list TW> creation page as well (make it the 'site administration page' TW> or something.) I thought about that, but it makes things too complicated. E.g. now that global page has to have some pull down menu or other way to specify which list you want to delete. List deletion is list-centric, so it's okay to have it hang off the list admin page (really, it's that the rmlist cgi script requires a list name in the url). TW> Again, this won't make sense everywhere, but I'd *love* to be TW> able to give our Sales dept. the list creator password to have TW> them create and destroy lists, without giving them the site TW> password. That's a great idea, and I'll make the change so that list deletion follows this password chain: list-owner, global list-creator, site admin. >> Here's how I solved it for Postfix; this is outlined in a new >> README.POSTFIX file. TW> You'll want to add checks for the permissios of this file to TW> bin/check_perms, just to be sure. If not run as root, it can't TW> fix it automatically, but it can whine incessantly. Good point! This should probably be done in the Mailman/MTA/Foo.py module so MTA-specific adaptors can do whatever additional checks are necessary. >> There's one last bit of glue, and here's where you come in (I'm >> speaking to the one of you who is still reading this. :). TW> Hi, Barry ! =) Hi Thomas! :) TW> There's another dimension to it, though. At XS4ALL we use a TW> central database (currently MySQL, soon to be PostgresSQL) for TW> all email aliases, and the list creation mechanism should TW> insert the appropriate aliases into that as well as into the TW> local database -- and they have to differ slightly. (local TW> alias is, say, 'list@listXX.xs4all.nl', where XX is a growing TW> number, but the global alias should be either list@xs4all.nl TW> or list@domain.com, pointing to list@listXX.xs4all.nl). I TW> could do this fairly easily by adapting the Sendmail (or TW> Postfix) MTA module and placing it in the MTA directory under TW> a different name. I think that's the right approach. >> [3] There's one caveat: because I don't want to have to include >> a setuid-root script, the Postfix.py module doesn't call >> `postfix reload'. This command has to be done as root. The >> tradeoff is that Postfix will take about a minute to recognize >> its alias database has changed. To me that's an acceptable >> limitation. TW> A minute ? Heh. I doubt that's ever going to be a problem, TW> most humans take a minute to read the resulting webpage, let TW> alone that they compose and send a message inside that minute. My thinking exactly! -Barry From Nigel.Metheringham@InTechnology.co.uk Wed May 9 17:43:44 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Wed, 09 May 2001 17:43:44 +0100 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 09 May 2001 12:27:49 EDT." <15097.28677.242197.400892@anthem.wooz.org> Message-ID: I hesitate to bring this up since Barry has currently produced a front end for existing mailman functionality rather than rehashing things... but one of the things I keep being asked about is better domain support.... I think that in general people wish to be able to have multiple domains on a machine and have *distinct* lists of the form list-name@domain1 list-name@domain2 Personally I am actually pretty happy with the current behaviour, and it could be very painful if the case where a current list sometimes gets requests on more than one domain was broken to handle this new case... Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry@digicool.com Wed May 9 17:53:58 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 12:53:58 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15097.28677.242197.400892@anthem.wooz.org> Message-ID: <15097.30246.409301.792141@anthem.wooz.org> >>>>> "NM" == Nigel Metheringham >>>>> writes: NM> Personally I am actually pretty happy with the current NM> behaviour, and it could be very painful if the case where a NM> current list sometimes gets requests on more than one domain NM> was broken to handle this new case... I think it would have to be broken. The `quick-fix' approach I've been mulling would involve encoding the domain into the path to the list's config.db file. I think it would be pretty painful to do that and arrange for lists to span multiple domains. But then again, maybe not. If the list's directory lived in $mailman/lists then it would span, but if it lived in $mailman/lists/$domain it would not span. Note, I'm no where near complete in my thinking on this, except to say that I believe the current situation is liveable and I've got other things higher up on my TODO list. -Barry From jra@baylink.com Wed May 9 18:08:24 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 9 May 2001 13:08:24 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15097.28677.242197.400892@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 09, 2001 at 12:27:49PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> Message-ID: <20010509130824.50367@scfn.thpl.lib.fl.us> On Wed, May 09, 2001 at 12:27:49PM -0400, Barry A. Warsaw wrote: > JRA> IMHO, the proper solution for sendmail is for the admin to > JRA> put an :include: in /etc/aliases pointing to > JRA> /home/mailman/data/aliases, and rebuild that from scratch > JRA> against the current list of lists every time that list > JRA> changes. > > I'm really trying to avoid having to write the sendmail code myself. > I just have too many scary flashbacks when I even think about mucking > with sendmail. ;} It seems pretty plain to me. Just expand the "list of lists" though a text filter that explodes the list names into what the doco says the alias entry needs to look like. > Now that everything's checked in, folks can see how I'm doing it with > Postfix, so I hope eventually someone will contribute a > Mailman/MTA/Sendmail.py module. Until then, I'll work it so it does > something simple. See above. :-) I can't code, but I *can* design... > JRA> You're working at the 'compiled' level there, right? > > If I understand what you're asking, yes. IOW, I don't muck about in > the plain text aliases file, but I write directly to the file that > newaliases would produce. Thought so. Forgive me, my revered senior hat, but that's a bad design. You've put yourself at their mercy by going behind their API... > JRA> I suspect you'll need one more: how to get the aliases > JRA> database rebuilt when it's been changed. > > That's the beauty of the Postfix approach: I'm modifying the database > directly so it doesn't need to be rebuilt (i.e. no need to run > newaliases). I don't even have to notify Postfix since it'll notice > the change after one minute. See above. ;-) > TW> And what about the domain the list should be created on ? > > The domain in the url to the `create' script! Note that bin/newlist > does need a domain switch, since the context can't be determined when > run from the command line, but the create cgi doesn't have that > problem. E.g. if I want to create a new list on python.org, I'd visit > http://mail.python.org/mailman/create but if I wanted to create a new > list on zope.org (a virtual host of a shared Mailman installation), > I'd visit http://mail.zope.org/mailman/create. Oh... mailman *does* get that right? Cool; missed that. If it knows that, though, how come my mails go out with the wrong From line? Doesn't it set the from line to the proper virtual domain? Or is my configuration wrong? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From dgc@uchicago.edu Wed May 9 18:10:49 2001 From: dgc@uchicago.edu (David Champion) Date: Wed, 9 May 2001 12:10:49 -0500 Subject: [Mailman-Developers] Re: Creation/deletion of lists through-the-web In-Reply-To: <20010509101321.61492@scfn.thpl.lib.fl.us> Message-ID: <20010509121049.R10115@smack.uchicago.edu> On 2001.05.09, in <20010509101321.61492@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > that you typically have to do some manual and difficult crud like edit > > an /etc/aliases file and run `newaliases' (as root!). I've figured a > > way around this with Postfix, and of course Exim can be configured to > > automatically recognize new mailing lists, so I figured it was time to > > do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst > > yourselves will contribute the code to glue this together for other > > mailers. > > IMHO, the proper solution for sendmail is for the admin to put an > :include: in /etc/aliases pointing to /home/mailman/data/aliases, and > rebuild that from scratch against the current list of lists every time > that list changes. I've written a mailer (in the sendmail sense) for Mailman. You can define a mailertable entry as: server.name.mil mailman:server.name.mil And add the mailer to sendmail.cf: MMailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u ...and it's all automagical. No more aliases, no more recompiling map datbases. You can find it in the archives, or I can mail you the most recent working version. -- -D. dgc@uchicago.edu NSIT University of Chicago From claw@kanga.nu Wed May 9 18:39:02 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 09 May 2001 10:39:02 -0700 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 09 May 2001 12:27:49 EDT." <15097.28677.242197.400892@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> Message-ID: <13617.989429942@kanga.nu> On Wed, 9 May 2001 12:27:49 -0400 Barry A Warsaw wrote: > If I understand what you're asking, yes. IOW, I don't muck about > in the plain text aliases file, but I write directly to the file > that newaliases would produce. Then what happens when I need to manually touch that alias file for some reason (eg I edit the aliases to insert demime in the pipeline) and have postfix rebuild it? You need to touch both the plain text alias file and the DBM. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From barry@digicool.com Wed May 9 18:40:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 9 May 2001 13:40:19 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <20010509130824.50367@scfn.thpl.lib.fl.us> Message-ID: <15097.33027.212039.19427@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> I'm really trying to avoid having to write the sendmail code >> myself. I just have too many scary flashbacks when I even >> think about mucking with sendmail. ;} JRA> It seems pretty plain to me. Just expand the "list of lists" JRA> though a text filter that explodes the list names into what JRA> the doco says the alias entry needs to look like. That's not the difficult part. What I'm purposefully avoiding is having to install sendmail, and /test/ the interoperability. There are all kinds of dark corners lurking there that only someone who uses and knows sendmail well enough will be able to solve. As I've done for Postfix. >> JRA> You're working at the 'compiled' level there, right? >> If I understand what you're asking, yes. IOW, I don't muck >> about in the plain text aliases file, but I write directly to >> the file that newaliases would produce. JRA> Thought so. Forgive me, my revered senior hat, but that's a JRA> bad design. You've put yourself at their mercy by going JRA> behind their API... I disagree. Postfix documents all this, so I consider it part of their API. And the fact that they have alias_maps /and/ alias_databases shows that they intend for external applications to create and manage maps that Postfix will consult. >> cgi doesn't have that problem. E.g. if I want to create a new >> list on python.org, I'd visit >> http://mail.python.org/mailman/create but if I wanted to create >> a new list on zope.org (a virtual host of a shared Mailman >> installation), I'd visit http://mail.zope.org/mailman/create. JRA> Oh... mailman *does* get that right? Cool; missed that. JRA> If it knows that, though, how come my mails go out with the JRA> wrong From line? Doesn't it set the from line to the proper JRA> virtual domain? Or is my configuration wrong? That's almost invariably a sending-MTA configuration issue. I know for a fact that Sendmail used to munge From: headers according to its own whims. You could set all the headers properly to your hearts content, and if Sendmail was misconfigured, they'd be broken when the end user gets them. I'll note that python.org and zope.org are a shared Mailman, virtual host arrangement, and it's all worked perfectly with both Postfix, and now Exim. -Barry From marc_news@valinux.com Wed May 9 18:43:04 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Wed, 9 May 2001 10:43:04 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org>; from barry@digicool.com on Mon, May 07, 2001 at 12:24:16PM -0400 References: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <20010509104304.J29713@magic.merlins.org> On Mon, May 07, 2001 at 12:24:16PM -0400, Barry A. Warsaw wrote: > > Folks, > > I've just released Mailman 2.0.5 which fixes a problem with stale lock > files that can occur under certain situations when the user hits the > `Stop' button on their browser. These stale lock files can cause > mailing lists to be inaccessible for long periods of time (until the > stale lock file times out or is manually removed). I just noticed this in my locks directory: usw-sf-list1:/var/local/mailman/bin# l ../locks/ total 24 drwxrwsr-x 2 mailman mailman 16384 May 9 10:40 ./ drwxrwsr-x 21 mailman mailman 4096 Apr 10 15:06 ../ -rw-rw-r-- 1 mailman mailman 59 May 7 05:42 jboss-user.lock.usw-sf-list1.26443 usw-sf-list1:/var/local/mailman/bin# (prcoss 26443 doesn't exist obviously) Note that this is not bad because it doesn't keep the list locked. There is probably a small race in the removal of the temporary lockfile that you link to though. I'll delete this one and see if others pop up over time. 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 jra@baylink.com Wed May 9 18:59:52 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 9 May 2001 13:59:52 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15097.33027.212039.19427@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, May 09, 2001 at 01:40:19PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <20010509130824.50367@scfn.thpl.lib.fl.us> <15097.33027.212039.19427@anthem.wooz.org> Message-ID: <20010509135952.46012@scfn.thpl.lib.fl.us> On Wed, May 09, 2001 at 01:40:19PM -0400, Barry A. Warsaw wrote: > JRA> It seems pretty plain to me. Just expand the "list of lists" > JRA> though a text filter that explodes the list names into what > JRA> the doco says the alias entry needs to look like. > > That's not the difficult part. What I'm purposefully avoiding is > having to install sendmail, and /test/ the interoperability. There > are all kinds of dark corners lurking there that only someone who uses > and knows sendmail well enough will be able to solve. As I've done > for Postfix. Ah. > JRA> Thought so. Forgive me, my revered senior hat, but that's a > JRA> bad design. You've put yourself at their mercy by going > JRA> behind their API... > > I disagree. Postfix documents all this, so I consider it part of > their API. And the fact that they have alias_maps /and/ > alias_databases shows that they intend for external applications to > create and manage maps that Postfix will consult. Oh. Didn't realize that. As JC notes, though, there's a problem in reverse. > >> cgi doesn't have that problem. E.g. if I want to create a new > >> list on python.org, I'd visit > >> http://mail.python.org/mailman/create but if I wanted to create > >> a new list on zope.org (a virtual host of a shared Mailman > >> installation), I'd visit http://mail.zope.org/mailman/create. > > JRA> Oh... mailman *does* get that right? Cool; missed that. > JRA> If it knows that, though, how come my mails go out with the > JRA> wrong From line? Doesn't it set the from line to the proper > JRA> virtual domain? Or is my configuration wrong? > > That's almost invariably a sending-MTA configuration issue. I know > for a fact that Sendmail used to munge From: headers according to its > own whims. You could set all the headers properly to your hearts > content, and if Sendmail was misconfigured, they'd be broken when the > end user gets them. > > I'll note that python.org and zope.org are a shared Mailman, virtual > host arrangement, and it's all worked perfectly with both Postfix, and > now Exim. Noted. Which do you like better? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jarrell@vt.edu Wed May 9 20:23:19 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 09 May 2001 15:23:19 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15097.28677.242197.400892@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010509151550.02abd380@vtserf.cc.vt.edu> At 12:27 PM 5/9/01 -0400, Barry A. Warsaw wrote: >>>>>> "JRA" == Jay R Ashworth writes: > > JRA> Ain't Python great? > >(ssshhh! they'll discover our secret weapon. :) > > JRA> IMHO, the proper solution for sendmail is for the admin to > JRA> put an :include: in /etc/aliases pointing to > JRA> /home/mailman/data/aliases, and rebuild that from scratch > JRA> against the current list of lists every time that list > JRA> changes. > >I'm really trying to avoid having to write the sendmail code myself. >I just have too many scary flashbacks when I even think about mucking >with sendmail. ;} That's in the cf file. You can specify more than one alias file. Which is probably the cleanest way to do it; you'll still need something, if only a cronjob that runs newaliases - I shudder at the the thought of manipulating the sendmail alias db file directly, particularly since my python 2.0 will flatly not compile with the version of DB that sendmail is using; I suspect it's too new for the DB routines shipped with python. Note that eric said a while ago that he's deprecating the "auto rebuild alias file" for security reasons, so at some point that functionality will likely go away. > JRA> I suspect you'll need one more: how to get the aliases > JRA> database rebuilt when it's been changed. > >That's the beauty of the Postfix approach: I'm modifying the database >directly so it doesn't need to be rebuilt (i.e. no need to run >newaliases). I don't even have to notify Postfix since it'll notice >the change after one minute. Until the first time something goes wrong... Then you'll need a tool to regenerate all the aliases again from scratch. I really don't like the fact that I won't have a text DB source file around... >>>>>> "TW" == Thomas Wouters writes: > > TW> What about a 'send list creation message' ? And a > TW> 'auto-generate password' button ? In my eyes, typically, the > TW> person creating the list won't be the list owner him/herself, > TW> so those things make sense to me. > >The list creation message is always sent currently. Does it make >sense to be able to inhibit that? Yes. I currently manually go in and fix some things that just can't be set from defaults easily before letting the admin know. Ideally I'd like a button for "(re)send list creation message now", because what I do is run newlist, hit ctl-z, go off and make my changes, fg it, and let it send the list message... From fil@rezo.net Wed May 9 22:23:29 2001 From: fil@rezo.net (Fil) Date: Wed, 9 May 2001 23:23:29 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15096.55680.384791.933908@anthem.wooz.org>; from barry@digicool.com on Wed, May 09, 2001 at 01:45:36AM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010509232329.B30678@orwell.bok.net> @ Barry A. Warsaw (barry@digicool.com) : > Last night I got inspired to add back the through-the-web creation and > deletion of mailing lists. I've now got this working for Postfix and Sorry I'm catching this thread late. I've been hacking another way with mailman and postfix, and thought I should share. The idea is outlined below, and the details are on http://listes.rezo.net/comment.php (in French, but there are mostly codes... in code.) So in postfix create a new virtual domain (listes.rezo.net in my case) within the /etc/postfix/virtual file ; **this domain will be totally used by mailman** ; then use some regexp virtual addresses so that (.*)-post is sent to mailman-post+$1@localhost (.*)-subscribe to mailman-subscribe+$1@localhost and so on. If an adress mathces none of the -action filters, send it to $1-post (so that listname@listes.rezo.net is sent to list-post then to the post programme) then in the /etc/aliases file define mailman-post: "|/var/lib/mailman/mail/wrapper post $EXTENSION" and allow the '+' sign as an extension delimiteer in postfix. Then (shazzam!) any mail coming to the listes.rezo.net domain is processed by the right mailman scripts. Of course we intercept required addresses before the regexp ones, so that postmaster@, abuse@ and root@listes.rezo.net go to root@localhost. What gives? When I need to create a list, or to delete one, I don't need root privileges or access to any postfix file. I just do the bin/newlist stuff and the list is ready. Hope this can be helpful. From benwa@ocentrix.com Thu May 10 00:21:53 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Wed, 9 May 2001 16:21:53 -0700 Subject: [Mailman-Developers] Creation/deletion of liststhrough-the-web Message-ID: <200105092321.f49NLrW08277@mail.ocentrix.net> ------- Original Copy ------- >Subject: Re: [Mailman-Developers] Creation/deletion of liststhrough-the-web >Date: 05/09/2001 3:23 PM >From: Ron Jarrell >To: barry@digicool.com (Barry A. Warsaw), "Jay R. Ashworth" >Cc: mailman-developers@python.org >>The list creation message is always sent currently. Does it make >>sense to be able to inhibit that? > >Yes. I currently manually go in and fix some things that just can't be set >from defaults easily before letting the admin know. Ideally I'd like a button >for "(re)send list creation message now", because what I do is run newlist, >hit ctl-z, go off and make my changes, fg it, and let it send the list message... FWIW I do sort of the same thing. I have hacked newlist to accept another option as described below. [mailman@mail riders_connection]$ ./bin/newlist --help Create a new, unpopulated mailing list. Usage: %(PROGRAM)s [options] listname listadmin-addr admin-password Options: -q --quiet Normally the administrator is notified by email (after a prompt) that their list has been created. This option suppresses that notification and the prompting. -s file --saveemail=file Append the email that is sent to the administrator of the new list to file. This is in addition to sending the email to the administrator unless -q is used. -o file --output=file Append the alias setting recommendations to file, in addition to printing them to standard output. -h/--help Print this help text and exit. You can specify as many of the arguments as you want on the command line: you will be prompted for the missing ones. Note that listnames are forced to lowercase. [mailman@mail riders_connection]$ a patch for this against 2.0.3 is attached if anyone is interested. -Ben From Dan Mick Thu May 10 00:51:52 2001 From: Dan Mick (Dan Mick) Date: Wed, 9 May 2001 16:51:52 -0700 (PDT) Subject: [Mailman-Developers] RFE: check_perms: ignore archives Message-ID: <200105092351.QAA07292@utopia.West.Sun.COM> Allow check_perms to bypass the archives subdirs. When they get large, check_perms can take *forever*, and so people won't run it, which is bad. I hacked something quickly that should be an option instead: $ diff check_perms check_perms2 80a81,86 > > if 'archives' in names: > print 'removing archives from names array' > names.remove('archives') > return > From andrewm@connect.com.au Thu May 10 06:15:33 2001 From: andrewm@connect.com.au (Andrew McNamara) Date: Thu, 10 May 2001 15:15:33 +1000 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Your message of "Wed, 09 May 2001 01:45:36 -0400." <15096.55680.384791.933908@anthem.wooz.org> Message-ID: <20010510051533.C63B2285BF@wawura.off.connect.com.au> >Postfix has a configuration variable called `alias_maps' which tells >it where to look for local delivery address associations. It has >another variable called `alias_databases' which tells it which files >to rebuild when invoked as newaliases. For each of these you can >specify the type of map database the file is kept as. One of these >choices is `hash', which is really a BSD dbhash file. Python has a >dbhash module which nicely handles reading and writing dbhash files >(and it should be enabled by default in Python 2.x, if your system has >Berkeley DB installed, as most Linux distros ought to). It should be mentioned here that postfix and python need to be linked against the same version of libdb as most versions of libdb have incompatible file formats. One other small caveat is file locking - some versions of libdb (certainly 1.96 and prior) are not safe during updates. The postfix tool that builds libdb hashes uses it's own file locking (check source for details). --- Andrew McNamara (System Architect) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9409 2117, Fax: +61 2 9409 2111 From thomas@xs4all.net Thu May 10 10:17:04 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 10 May 2001 11:17:04 +0200 Subject: [Mailman-Developers] Re: Creation/deletion of lists through-the-web In-Reply-To: <20010509121049.R10115@smack.uchicago.edu>; from dgc@uchicago.edu on Wed, May 09, 2001 at 12:10:49PM -0500 References: <20010509101321.61492@scfn.thpl.lib.fl.us> <20010509121049.R10115@smack.uchicago.edu> Message-ID: <20010510111704.I16486@xs4all.nl> On Wed, May 09, 2001 at 12:10:49PM -0500, David Champion wrote: > On 2001.05.09, in <20010509101321.61492@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > > that you typically have to do some manual and difficult crud like edit > > > an /etc/aliases file and run `newaliases' (as root!). I've figured a > > > way around this with Postfix, and of course Exim can be configured to > > > automatically recognize new mailing lists, so I figured it was time to > > > do it. I'm hoping that Sendmail, Qmail, and other MTA users amongst > > > yourselves will contribute the code to glue this together for other > > > mailers. > > > > IMHO, the proper solution for sendmail is for the admin to put an > > :include: in /etc/aliases pointing to /home/mailman/data/aliases, and > > rebuild that from scratch against the current list of lists every time > > that list changes. > > I've written a mailer (in the sendmail sense) for Mailman. You can > define a mailertable entry as: > server.name.mil mailman:server.name.mil > And add the mailer to sendmail.cf: > MMailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, > S=EnvFromL, R=EnvToL/HdrToL, > A=mm-handler $h $u > ...and it's all automagical. No more aliases, no more recompiling map > datbases. > You can find it in the archives, or I can mail you the most recent > working version. I think that would be *perfect*. Mailers is exactly one of Sendmail's fortes, and very useful if you know how to use them (we do, for various uhm, 'creative systems' :) I'd very much like to test this sometime (but not soon, unfortunately my other work stuff is swamping me) on our list servers! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@digicool.com Thu May 10 17:29:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 12:29:19 -0400 Subject: [Mailman-Developers] Re: Creation/deletion of lists through-the-web References: <20010509101321.61492@scfn.thpl.lib.fl.us> <20010509121049.R10115@smack.uchicago.edu> Message-ID: <15098.49631.621295.671358@yyz.digicool.com> >>>>> "DC" == David Champion writes: DC> On 2001.05.09, in <20010509101321.61492@scfn.thpl.lib.fl.us>, DC> I've written a mailer (in the sendmail sense) for Mailman. DC> You can define a mailertable entry as: server.name.mil DC> mailman:server.name.mil DC> And add the mailer to sendmail.cf: MMailman, DC> P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, DC> S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u DC> ...and it's all automagical. No more aliases, no more DC> recompiling map datbases. DC> You can find it in the archives, or I can mail you the most DC> recent working version. David, This is really cool! Please send me the latest version of mm-handler so I can add it to the contrib directory. I've updated README.SENDMAIL with the following text; does it accurately describe the steps one should take to integrate Mailman and Sendmail? If not, please let me know what changes should be made. Thanks, -Barry -------------------- snip snip -------------------- INTEGRATING SENDMAIL AND MAILMAN David Champion has contributed a Sendmail mailer which you can use so that Sendmail will automatically deliver to Mailman mailing lists without manual intervention (i.e. updated an aliases file or running newaliases). He suggests adding the following to your sendmail.cf file: MMailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u The mm-handler script can be found in the contrib directory; copy this script to /etc/mail and in your Mailman/mm_cfg.py file, add the following: MTA = None Now Sendmail should automagically deliver to the standard Mailman aliases for mailing lists. From barry@digicool.com Thu May 10 18:10:46 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 13:10:46 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> Message-ID: <15098.52118.767944.272250@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> If I understand what you're asking, yes. IOW, I don't muck >> about in the plain text aliases file, but I write directly to >> the file that newaliases would produce. JCL> Then what happens when I need to manually touch that alias JCL> file for some reason (eg I edit the aliases to insert demime JCL> in the pipeline) and have postfix rebuild it? You need to JCL> touch both the plain text alias file and the DBM. Two suggestions: - If you want to insert demime in front of the pipeline for all lists, then edit Mailman/MTA/Utils.py to generate whatever expansion of the aliases you want. Currently these expand to mylist: "|/path/to/mailman/mail/wrapper post mylist" mylist-admin: "|/path/to/mailman/mail/wrapper mailowner mylist" mylist-request: "|/path/to/mailman/mail/wrapper mailcmd mylist" mylist-owner: mylist-admin - If you only want to insert demime in front of some lists and not others, then I would suggest writing a custom module for the Mailman/MTA directory and using that instead (i.e. setting MTA = 'MyCustomMTA' in mm_cfg.py). That having been said, I'm adding a command line script (bin/genaliases) that will re-generate both the dbhash alias file and the plain-text alias file based on the list of mailing lists. What I don't want to do is use the plain text file as the canonical database file for integration with the MTA. I fear the grepping and cut-n-paste that would have to be done programmatically would be too fragile. And then you still have to get newaliases run, which poses problems in its own right. Ideally, none of this would be necessary because the MTA would just have a single hook for it to auto-recognize mailing lists. Exim does it well, and it looks like David Champion's got a good solution for Sendmail. I'll follow up on the alternative Postfix solution shortly, in a separate email. -Barry P.S. genaliases and Mailman/MTA/Utils.py will be checked in soon. From barry@digicool.com Thu May 10 18:20:54 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 13:20:54 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <20010509130824.50367@scfn.thpl.lib.fl.us> <15097.33027.212039.19427@anthem.wooz.org> <20010509135952.46012@scfn.thpl.lib.fl.us> Message-ID: <15098.52726.758080.651119@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> I disagree. Postfix documents all this, so I consider it part >> of their API. And the fact that they have alias_maps /and/ >> alias_databases shows that they intend for external >> applications to create and manage maps that Postfix will >> consult. JRA> Oh. Didn't realize that. As JC notes, though, there's a JRA> problem in reverse. Not really, because I submit that you shouldn't have to touch the plain text Mailman-specific aliases file. You shouldn't be mixing non-Mailman aliases into this file (and don't need to since Postfix will happily consult any number of files via alias_maps), and Mailman can be taught to DTRT for the Mailman-related aliases. >> I'll note that python.org and zope.org are a shared Mailman, >> virtual host arrangement, and it's all worked perfectly with >> both Postfix, and now Exim. JRA> Noted. Which do you like better? I'm mostly agnostic here. I chose Postfix years ago for the old CNRI machines when I was just frustrated beyond my breaking point with Sendmail (you don't even want to hear about our even older, internal, and hand-crufted mmdf installation). Once I learned it I had little reason - or really, time - to change. When we (and our lists ;) moved to Digital Creations, and we integrated the python.org and zope.org domains, I was able to pawn^H^H^H^H, er, hand off the specific MTA duties to the zope.org webmaster. He was very comfortable with Exim and since I was load-shedding, I wasn't in a position to argue. Exim's done the job quite admirably since then. And it's very nice that Exim is so easily integrated with Mailman! -Barry From jra@baylink.com Thu May 10 18:37:40 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 10 May 2001 13:37:40 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15098.52118.767944.272250@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, May 10, 2001 at 01:10:46PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> Message-ID: <20010510133740.47780@scfn.thpl.lib.fl.us> On Thu, May 10, 2001 at 01:10:46PM -0400, Barry A. Warsaw wrote: > What I don't want to do is use the plain text file as the canonical > database file for integration with the MTA. I fear the grepping and > cut-n-paste that would have to be done programmatically would be too > fragile. And then you still have to get newaliases run, which poses > problems in its own right. Well, I *had* suggested making the admin do *1* :include: in the alias file that sendmail knows about, to a file tha mailman *owns*... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Thu May 10 18:43:17 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 10 May 2001 10:43:17 -0700 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Thu, 10 May 2001 13:10:46 EDT." <15098.52118.767944.272250@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> Message-ID: <30844.989516597@kanga.nu> On Thu, 10 May 2001 13:10:46 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: >>> If I understand what you're asking, yes. IOW, I don't muck >>> about in the plain text aliases file, but I write directly to >>> the file that newaliases would produce. JCL> Then what happens when I need to manually touch that alias file JCL> for some reason (eg I edit the aliases to insert demime in the JCL> pipeline) and have postfix rebuild it? You need to touch both JCL> the plain text alias file and the DBM. > Two suggestions: > - If you want to insert demime in front of the pipeline for all > lists, then edit Mailman/MTA/Utils.py to generate whatever > expansion of the aliases you want. Currently these expand to ... > - If you only want to insert demime in front of some lists and not > others, then I would suggest writing a custom module for the > Mailman/MTA directory and using that instead (i.e. setting MTA = > 'MyCustomMTA' in mm_cfg.py). That's taking something which is simple and obvious, which every SysAdm out there who has ever touched mail on a *nix system understands editing alias files, and then turning it into something special cased for Mailman. Bad. > That having been said, I'm adding a command line script > (bin/genaliases) that will re-generate both the dbhash alias file > and the plain-text alias file based on the list of mailing lists. Yeesh. No. If you touch the DBM file you need to touch the aliases file, always. Otherwise you're in the position of actively working to deceive admins in regard to the state of their mail system (what they can see says one thing, what they can't see says another, and they have to have specialised knowledge to know that there's likely to be a difference). > What I don't want to do is use the plain text file as the > canonical database file for integration with the MTA. I fear the > grepping and cut-n-paste that would have to be done > programmatically would be too fragile. Hardly. Put a comment block at the top of the file stating that this file is maintained by the CGI at URL . Include a warning that manual editing *might* break supports for this file format. Have newlist and the CGI always use the same formating. As all you are relly interested in are the ^listname:[ \t]*.* lines, they're easy enough to match and edit. > And then you still have to get newaliases run, which poses > problems in its own right. Nope. You do both: touch the text file AND the DBM. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From barry@digicool.com Thu May 10 19:37:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 14:37:40 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <5.1.0.14.2.20010509151550.02abd380@vtserf.cc.vt.edu> Message-ID: <15098.57332.841432.595430@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> That's in the cf file. You can specify more than one alias RJ> file. Which is probably the cleanest way to do it; you'll RJ> still need something, if only a cronjob that runs newaliases - RJ> I shudder at the the thought of manipulating the sendmail RJ> alias db file directly, particularly since my python 2.0 will RJ> flatly not compile with the version of DB that sendmail is RJ> using; I suspect it's too new for the DB routines shipped with RJ> python. Ah. Python 2.1 should have a much better story here. It doesn't statically link against the db library, and you can install the latest Sleepycat version of BerkeleyDB, and use Robin Dunn's PyBSDDB3 wrapper (pybsddb.sourceforge.net). Yup, that's more work, and it's not ideal, but it ought to work. RJ> Note that eric said a while ago that he's deprecating the RJ> "auto rebuild alias file" for security reasons, so at some RJ> point that functionality will likely go away. Another nail in the coffin for maintaining the aliases in the plain text file. But it looks like David Champion got the right solution for Sendmail. RJ> Until the first time something goes wrong... Then you'll need RJ> a tool to regenerate all the aliases again from scratch. I RJ> really don't like the fact that I won't have a text DB source RJ> file around... bin/genaliases >> The list creation message is always sent currently. Does it >> make sense to be able to inhibit that? RJ> Yes. I currently manually go in and fix some things that just RJ> can't be set from defaults easily before letting the admin RJ> know. Ideally I'd like a button for "(re)send list creation RJ> message now", because what I do is run newlist, hit ctl-z, go RJ> off and make my changes, fg it, and let it send the list RJ> message... I think the easiest thing to do right now is to restore the prompt before notification is sent for the command line script. It's not immediately clear how I should handle this for the create cgi... -Barry From barry@digicool.com Thu May 10 19:48:28 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 14:48:28 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <20010510133740.47780@scfn.thpl.lib.fl.us> Message-ID: <15098.57980.802114.12603@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Well, I *had* suggested making the admin do *1* :include: in JRA> the alias file that sendmail knows about, to a file tha JRA> mailman *owns*... Which makes it a little easier to control the contents of the file, but not foolproof. That's not counting getting newaliases to run under the proper permissions (which still has to be done with :include: files right?) I still like David's solution best for Sendmail. Cheers, -Barry From barry@digicool.com Thu May 10 19:59:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 14:59:35 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509232329.B30678@orwell.bok.net> Message-ID: <15098.58647.622157.397405@anthem.wooz.org> Fil> So in postfix create a new virtual domain (listes.rezo.net in Fil> my case) within the /etc/postfix/virtual file ; **this domain Fil> will be totally used by mailman** Hi Fil, If I understand correctly, this means your mailing lists have to be advertised as mylist@virt.mydomain.com, right? I.e. you have to expose the virtual host in the domain part of the address. What if I want to advertise lists as mylist@mydomain.com? Does your approach accomodate that? Thanks, -Barry From barry@digicool.com Thu May 10 20:06:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 15:06:35 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <30844.989516597@kanga.nu> Message-ID: <15098.59067.652111.916123@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> If you touch the DBM file you need to touch the aliases file, JCL> always. Otherwise you're in the position of actively working JCL> to deceive admins in regard to the state of their mail system JCL> (what they can see says one thing, what they can't see says JCL> another, and they have to have specialised knowledge to know JCL> that there's likely to be a difference). >> What I don't want to do is use the plain text file as the >> canonical database file for integration with the MTA. I fear >> the grepping and cut-n-paste that would have to be done >> programmatically would be too fragile. JCL> Hardly. JCL> Put a comment block at the top of the file stating that this JCL> file is maintained by the CGI at URL . Include a JCL> warning that manual editing *might* break supports for this JCL> file format. Have newlist and the CGI always use the same JCL> formating. As all you are relly interested in are the JCL> ^listname:[ \t]*.* lines, they're easy enough to match and JCL> edit. >> And then you still have to get newaliases run, which poses >> problems in its own right. JCL> Nope. You do both: touch the text file AND the DBM. I think I see what you're getting at. Agreed, with the caveat that if the human operator modifies the text file and regens the db file, any f*ckups are outside Mailman's responsibilities to fix (although I'll do my best to fail gracefully). -Barry From fil@rezo.net Thu May 10 20:57:01 2001 From: fil@rezo.net (Fil) Date: Thu, 10 May 2001 21:57:01 +0200 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15098.58647.622157.397405@anthem.wooz.org>; from barry@digicool.com on Thu, May 10, 2001 at 02:59:35PM -0400 References: <15096.55680.384791.933908@anthem.wooz.org> <20010509232329.B30678@orwell.bok.net> <15098.58647.622157.397405@anthem.wooz.org> Message-ID: <20010510215701.A7641@orwell.bok.net> @ Barry A. Warsaw (barry@digicool.com) : > > Fil> So in postfix create a new virtual domain (listes.rezo.net in > Fil> my case) within the /etc/postfix/virtual file ; **this domain > Fil> will be totally used by mailman** > > Hi Fil, > > If I understand correctly, this means your mailing lists have to be > advertised as mylist@virt.mydomain.com, right? I.e. you have to > expose the virtual host in the domain part of the address. > > What if I want to advertise lists as mylist@mydomain.com? Does your > approach accomodate that? Dear Barry, In fact I do expose them as listname@rezo.net (and not listname@listes.rezo.net). On the rezo.net server (which i separate from listes.rezo.net for efficiency purposes: I don't want my personal mail mixed with heavy list sends) there is a fallback mechanism implemented with a virtual domain served as regexp. **This is very convenient, but not necessary, as the following will show.** Let's summarize what I use ************************** on rezo.net you find: ----------- /etc/postfix/main.cf: virtual_maps = hash:/etc/postfix/virtual /etc/postfix/virtual: rezo.net virtual fil@rezo.net fil # localhost delivery .... # any other fixed addresses and aliases @rezo.net @listes.rezo.net on listes.rezo.net: ------------------ /etc/postfix/main.cf virtual_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/virtual-regexp /etc/postfix/virtual: listes.rezo.net virtual postmaster@listes.rezo.net root # intercept the usual stuff root@listes.rezo.net root abuse@listes.rezo.net root /etc/postfix/virtual-regexp: # everything that comes here is served (of refused!) by mailman /^([a-zA-Z0-9\_\-]+)-(post|admin|request|subscribe|unsubscribe)@listes\.rezo\.net$/ mailman-$2+$1 # everything that comes here is for posting to a list, so go back to list-post /^([a-zA-Z0-9\_\-]+)@listes\.rezo\net$/ $1-post@listes.rezo.net # everything that comes here is braindead (addresses like toto%2@listes.rezo.net) /@listes\.rezo\.net$/ abuse@listes.rezo.net How to do it more simply (i.e. no supplementary domain) ************************ Just take the listes.rezo.net part, replace listes.rezo.net by your domain.net, and add the "fixed aliases" after the abuse@domain.net line in /etc/postfix/virtual Hope this helps -- Fil From benwa@ocentrix.com Thu May 10 20:52:40 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 10 May 2001 12:52:40 -0700 Subject: [Mailman-Developers] Creation/deletion of liststhrough-the-web Message-ID: <200105101952.f4AJqeb18762@mail.ocentrix.net> This is a multi-part message in MIME format. ------=_Next20010510-125240-18757-1424770306 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 TXkgYXBvbG9naWVzIGZvciB0aGUgbWlzc2luZyBhdHRhY2hlbWVu dC4KCi1CZW4= ------=_Next20010510-125240-18757-1424770306 Content-Type: application/octet-stream; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="saveemail_patch_for_newlist.txt.gz" H4sICOLL+ToAA25ld2xpc3QAjRn9b5tI9uei/SPeOvKBdTax095H3U1VN3VTS3Gasx1V0V5l ERjHqMCQGYhr7e797ffezICBkLSoqmHmfX/P5OhXOM6lOL4Nk2OWPEC6z7Y8sY6sIzjj6V6E d9sMnLMejF6//ncf/3vdPxkOh/TfCG73kG0ZfBSMwZJvsp0n8IvnSeBlIU/6MEt8V9FabUMJ qeB3wosBXzeEIg3KG9jzHHwvAcGCUGYivM0zBmEGXhIcc4H4MQ/CzZ6WkDgTim3GRCyBb9TH +eU1nLOECS+Cq/w2Cn24CH2WSIbYHvKmNbllwY+EfgMsxH0BD0xI/IYTJGCYGIp94AIcLyOx BfCU0Hoo6x4iLztgoubQovpBwwDCRNHd8hTV2SJFVHAXRhHcMsgl2+RRHykgLHyZrT59vl7B 5PIGvkwWi8nl6uYNwqK3cJc9ME0pjNMoRMKolPCSbI+SI4H5dHH2CTEm72cXs9UNif9xtrqc Lpfw8fMCJnA1WaxmZ9cXkwVcXS+uPi+nLsCSkVBkv6eNCxukFXO0YMAyL4ykUfoGHSpRtCiA rffA0LE+Cx9QMA98DKuf81rEkzulIsIebPgGwg0kPOvDToQYJhlv8SeiN+OwD/94DSuGBmJw FXk+gwEsc6Lw8uWwD++5zAh0PoHhyWg0GoxeDv/Vh+vlxLWsTqdzJhg6F+VP2K6PUZjyNCd3 BxCj3iFKivGVIey19O7YGLrO1eLz+WIy70n4XceI/KpgEi9m6sUL4jAZeEEgQL+mnpQ7LgLL +qwRxpYF+Azu9c/gPg9Zpt7pueQi9qJIx7OiQKHlZegSNBeaKNyEOuAZyYghu6Hw9MiScZr1 VMiV1JBIKJRc6DKJEYgh5SulAwwGFcVaDZB5mgomJZN1Cpqjr2xOqavk0rzQPq7RBZM/jJhR SGJwKOFO1eKLSZoyg6hl1lkhQbIkK1xdV9WEErpFCW+9QCgiVghN/1CcIAiVXLiLtAJyWIVL C2HrRZ5EqCVan2hgOgaFCryqAuZfmmen5Qo9FTW8KPRI/IxsQHnA45iZwJRgZO03RCwJpSJM MiNrrGTP0LCeCECzLSTaHg8GWxalJeIVIeq8oXUslt9VOQX2PSSsG1NxZcp8qqwoY0wVzFjT E3c5iplJ2qDqvMNqAlwXGVKBSGHUs7Gldk3N0s7GmKOyQKBxKCWJzxOGpcG65JkpdEUiIAOh qoiPWKhfxHdM+J5kLiWdZWFB4yIDuZfFKy/fqI4md8VXFsaseL9jGeVS5RNDtySWetlWWhuU FebofdQFzE4cr/3NXesWfV5QfLVtXmdY+lp3pkJw0b41x+DCUlHbcz+hYSPsHwWQ+Z5czepw Z2KfZgWQTx+WZQoOnJK5XHThw+/Dr5a1nF5+mE9mF+vJxWyyXK+m86uLyWqKYLZtW0dHWKoK b/RkrZrRpikBVNAwaAmi62AuiJ60NB6udP7sOjvhYdDjMqRYSWs0OwipUusRKDHjO6z/j+AF u89ZC3HC8OPgEbyicqKkO2wMFFeL1LT+024CCjJMF+ZvOdh/YlmjoIZn1bHh7f9UVh+79yTO oLr5A2LtCj9L0SjxY7pNszxP1Rj4QPdvj5k+oqBEf0Lfn8GvgShihO9vcbyDf756BU9DP7N1 MNDPECoUfw7kh5K12EFVqyMcgzZeHmXSWq4+4Lw2X55Tnk2TTOxVUVRkmO6BY9tS8VgJxydy 1bJktse55dTUPFeVSUeXK3e+mmj46XK9XN1cTHsWjkgaA06RvRLaHqvm0OTYlhcKsKbAiptC QKUlw1Zk9EAVMBgLZr+9BZuaa4WdamDQ+eKJBOX+FWYQ8MQ2Y7xqZkWHJArjTh+eUqpCznZU Y1NdR68UXDUZ13V7mPLWLxa6g6o/FSzyk9PTUhXfqBqXLp57QoHzOgI69vVyurB7NCI3dy4+ n19O5lO7p0joIbSkNC47b9FkdkG5VGGHy0Qt3eVh4CAHEg7fej0q1c/SrRCxf8uTbwkG4Vtb bQskIpISotQ8p/7i+DzAASOWd6e23at6Zb0OuL9eF2wRYlwfPGhJrVA/ocFB0eqV9NHiSWFS DPADNnZb2achQqK0uvu6+scpW9No/LUP9paP7zGK+iXqM8/vNo0yNmKZmYte1UhML4dR0v6q XcS++ywtur/LqBP361pqA43Uak+PUp4a3Sg9UfRLnFvUquKCC0NNmNg0QSi7kY9Sm8Y5skEl Kja0QOuOPeAkbzE5Fj4pnpoASKudxFaTUAZpENBKDXvtiPcaUZutgVloObJe1HCkxiktTHgv moYgUYtQiljikPd78BaGCFseexSYLGKdRZLVd4W3W4cJWsXpYM00B321ZwZTgh1DRytXQazV xbIslwLZ72zSpdhoiQCbhjvNKs7pjZP2fpQHDDrvOmOw4e/wmLCa/FxaX2OCyEwemD/JxIuw lAZ70AhPUa7acIRWUj1nrYqcseKoZsXa/sGO2lEVa+oTjzEnTg8Sp3qRJ0lxIiot3CbIiXHX Ot0VUpxUpSg0PsCYUdw1v05nluApB8/7XRytzHkX2UG3YgKicATKVgWIpNMK+eSWNEizvVVn Y/xPP6ljlmuF2qy1OWVltC6ZNXnZxhixgjotzwJu8eL0HtdAJZaazAt5oG/C5ZxlC+x8PF4y RrW/xDmCu9yjixtmjkl4vKeTLZ7xzRyuBgepL1XM8Rp9SH5URy26dToQM5t3gucpqPiQ2zAt LmZQO9Q3F4c7MS/PuM8TbOc+mjGrUGIJHdF0iBixghAPs3hODqviaFYyC/1ve7gNqTEfyPAI e7T8pptuTq/OcHhy0L5mvtaF0gmuvo4pk60Ph/DvQ+H64tmECd2TPKZVymFEO6CZ3qGPb+58 /t4LpkRcLbTVWwokBNJymCSjqx085OkMPwj4NBeKpYmuDlNVHJ5l97PFRGmqeg2avj7/deGP GnG7QLXHJZX+Ywib3jBru4OTV5Jyt3QEcu+MO70Gjjmo2Ihjd+Vx+dktpr0vi8nV1XSx/jBb NFDNQaLBrtM1Y/+4VjkauGbUtx/jmp1nsfWR0m7hrHaexaWjsjES3UtQXdrQi2N3g0H3dtC9 wZaqdiLue5HaUp/qrddr0qPRztCrjbN1sL8a41s5wjfWdTBU54PD0FEPtk1K2ZpSByghMPI8 u5FgqasuYx1N+YlN+7/JYzw/4hIVsSrFxpw0VOvnWEpYeZ2k6m95OlOPutg6NYU19r4xWnDq 1qMKSkUj+541Js0/DgGvrdse9GAXraEChhW9Dw0wFZPrXEQ6YnWtwnK/VAX1enHhmIDGMfFW 8ijP2Omo94gMoYVYchWldjIFSINSg5CJcypEOgvK0H/XrSdu33DZctSsJaRpVK9ZqgHegP7r 4Gicraln6tsu9xpj97JyUVx3VaWK110Y63svnXrvqMg9y9++oT/N0J1w9T6rXh3rGBQ2GIU0 +JZT7VO5UAI8lwqaYOvWzyWCGVzUUF6XRGex0/mEDZbpwQ7P55xuinOm/2KC05XuRNVLeTwX d9oOWk/WMTqsySwIE5eaDN06OXW5j9TJu5qq5iq9JVPpOVxnuh9YFD4wseIUEY7ypjmHKYM0 W7Z293WC9fIbWekXuuNYK9ev1+qWY01xk6zX5uZBH06t/wMUoqEv4RwAAA== ------=_Next20010510-125240-18757-1424770306-- From marc_news@valinux.com Thu May 10 21:42:57 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Thu, 10 May 2001 13:42:57 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <20010509104304.J29713@magic.merlins.org>; from marc_news@valinux.com on Wed, May 09, 2001 at 10:43:04AM -0700 References: <15094.52272.753043.181192@anthem.wooz.org> <20010509104304.J29713@magic.merlins.org> Message-ID: <20010510134257.Q31816@magic.merlins.org> On Wed, May 09, 2001 at 10:43:04AM -0700, Marc MERLIN wrote: > I just noticed this in my locks directory: > usw-sf-list1:/var/local/mailman/bin# l ../locks/ > total 24 > drwxrwsr-x 2 mailman mailman 16384 May 9 10:40 ./ > drwxrwsr-x 21 mailman mailman 4096 Apr 10 15:06 ../ > -rw-rw-r-- 1 mailman mailman 59 May 7 05:42 jboss-user.lock.usw-sf-list1.26443 > usw-sf-list1:/var/local/mailman/bin# > (prcoss 26443 doesn't exist obviously) > > Note that this is not bad because it doesn't keep the list locked. There is > probably a small race in the removal of the temporary lockfile that you link > to though. > > I'll delete this one and see if others pop up over time. Just got another one (so it's apparently not an isolated case) usw-sf-list1:/var/local/mailman/bin# l ../locks/ total 24 drwxrwsr-x 2 mailman mailman 16384 May 10 13:40 ./ drwxrwsr-x 21 mailman mailman 4096 Apr 10 15:06 ../ -rw-rw-r-- 1 mailman mailman 60 May 10 05:29 madchat-spam.lock.usw-sf-list1.8790 Again, it's not fatal since the list doesn't remain in locked state, but something is apparently still slightly off somewhere :-) 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@digicool.com Thu May 10 22:31:48 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 10 May 2001 17:31:48 -0400 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 References: <15094.52272.753043.181192@anthem.wooz.org> <20010509104304.J29713@magic.merlins.org> <20010510134257.Q31816@magic.merlins.org> Message-ID: <15099.2244.184017.746400@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Just got another one (so it's apparently not an isolated case) Dang. MM> usw-sf-list1:/var/local/mailman/bin# l ../locks/ total 24 MM> drwxrwsr-x 2 mailman mailman 16384 May 10 13:40 ./ drwxrwsr-x MM> 21 mailman mailman 4096 Apr 10 15:06 ../ -rw-rw-r-- 1 mailman MM> mailman 60 May 10 05:29 madchat-spam.lock.usw-sf-list1.8790 MM> Again, it's not fatal since the list doesn't remain in locked MM> state, but something is apparently still slightly off MM> somewhere :-) Yeah, that's annoying. :) I haven't got any lock turds on python.org, but then again, you probably have slightly higher traffic than we do . If I get some time, I'll stare at the LockFile.py code again. Any idea what process 8790 was? I wonder if it's the same code that's not cleaning up after itself. Hmm, -Barry From chuqui@plaidworks.com Fri May 11 06:23:30 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 10 May 2001 22:23:30 -0700 Subject: [Mailman-Developers] http headers? Message-ID: I can't find these offhand in the source -- anyone know what the MIME type the python returns itself as for the pages it generates? I'm experimenting with a new (non-intrusive) way to skin a UI on Python, but they aren't quite cooperating... From claw@kanga.nu Fri May 11 06:56:15 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 10 May 2001 22:56:15 -0700 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Thu, 10 May 2001 15:06:35 EDT." <15098.59067.652111.916123@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <30844.989516597@kanga.nu> <15098.59067.652111.916123@anthem.wooz.org> Message-ID: <2127.989560575@kanga.nu> On Thu, 10 May 2001 15:06:35 -0400 Barry A Warsaw wrote: > I think I see what you're getting at. Agreed, with the caveat > that if the human operator modifies the text file and regens the > db file, any f*ckups are outside Mailman's responsibilities to fix > (although I'll do my best to fail gracefully). Precisely. Ultimately its the principle of least surprise. What I don't want to see is: Mailman is so lame and broken! Our admin just touched the alias file and now ___ALL___ of our Mailman lists are gone -- AND HE DIDN"T EVEN CHANGE ANYTHING! Stoopid bloody software. Mailman is just so braindead... Or words to that effect. I think we can handle things a little more gracefully than that, both by adding a commented warning and documentation at the top of the alias file (genned on file create and re-added if file touched by Mailman and comments cound missing (cf IMAP and first message)), and by attempting to be graceful (which also means keeping backups at the filesystem level), about all Mailman-driven alias file operations. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From lmb@suse.de Fri May 11 10:18:42 2001 From: lmb@suse.de (Lars Marowsky-Bree) Date: Fri, 11 May 2001 11:18:42 +0200 Subject: [Mailman-Developers] Porting "NetiquetteEnforcer" to mailman Message-ID: <20010511111842.X639@marowsky-bree.de> Good morning, I have switched my mailing lists from ezmlm to mailman (mostly because I wanted to use postfix) a few months ago. Under ezmlm, I wrote a cute little script called "NetiquetteEnforcer.pl", which did a rather good job at rejecting "annoying" (incorrectly formatted etc) mails. (If you are interested, you can look at http://lars.marowsky-bree.de/dl/NetiquetteEnforcer.pl ) Now, I meant to port this ages ago, but you know how "I will do it in my copious spare time" works out in practice... I am looking at how to integrate this properly with mailman. What I would probably have to do is to hook in HandlerAPI much like the "Hold" Handler and either hold the message, reject it immediately or let it pass through. However, I am unclear about how to do get the configuration information done properly - I would rather like an additional screen for the Content Filtering scheme in the Web management tools, and it isn't immediately obvious to me how I would go about this. Any insight would be appreciated. Sincerely, Lars Marowsky-Brée -- Perfection is our goal, excellence will be tolerated. -- J. Yahl From thomas@xs4all.net Fri May 11 13:28:29 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 11 May 2001 14:28:29 +0200 Subject: [Mailman-Developers] http headers? In-Reply-To: ; from chuqui@plaidworks.com on Thu, May 10, 2001 at 10:23:30PM -0700 References: Message-ID: <20010511142829.N16486@xs4all.nl> On Thu, May 10, 2001 at 10:23:30PM -0700, Chuq Von Rospach wrote: > I can't find these offhand in the source -- anyone know what the MIME type > the python returns itself as for the pages it generates? I'm experimenting > with a new (non-intrusive) way to skin a UI on Python, but they aren't quite > cooperating... I'm not sure I understand the question. You want to know what mimetype CGI scripts written in Python return by default ? Well.... nothing :) CGI scripts have to return the mimetype explicitly. The 'cgi' module only handles the request part of CGI, not the response part. If you use something like HTMLgen, it depends on what Document you generate. So it should be stated, either explicitly or implicitly, somewhere in your code. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From webmaster@isu.edu Fri May 11 14:54:43 2001 From: webmaster@isu.edu (Webmaster) Date: Fri, 11 May 2001 07:54:43 -0600 Subject: [Mailman-Developers] Qrunner error Message-ID: <3AFBEF23.AEF4668B@isu.edu> Does anyone know what this error means and how to fix it. Traceback (innermost last): File "/home/mailman/cron/qrunner", line 78, in ? import time ImportError: /usr/lib/python1.5/lib-dynload/timemodule.so: undefined symbol: PyErr_Format -- ############################### Webmaster webmaster@isu.edu Computing & Communications ################################ From barry@digicool.com Fri May 11 15:53:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 11 May 2001 10:53:49 -0400 Subject: [Mailman-Developers] Qrunner error References: <3AFBEF23.AEF4668B@isu.edu> Message-ID: <15099.64766.425834.892330@anthem.wooz.org> >>>>> "W" == Webmaster writes: W> Does anyone know what this error means and how to fix it. W> Traceback (innermost last): | File "/home/mailman/cron/qrunner", line 78, in ? | import time W> ImportError: /usr/lib/python1.5/lib-dynload/timemodule.so: W> undefined symbol: PyErr_Format It looks to me like your Python installation is pretty broken. What Python version are you using? I'd suggest re-installing Python. -Barry From barry@digicool.com Fri May 11 21:49:47 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 11 May 2001 16:49:47 -0400 Subject: [Mailman-Developers] Porting "NetiquetteEnforcer" to mailman References: <20010511111842.X639@marowsky-bree.de> Message-ID: <15100.20587.961110.136806@anthem.wooz.org> >>>>> "LM" == Lars Marowsky-Bree writes: LM> I have switched my mailing lists from ezmlm to mailman (mostly LM> because I wanted to use postfix) a few months ago. Under LM> ezmlm, I wrote a cute little script called LM> "NetiquetteEnforcer.pl", which did a rather good job at LM> rejecting "annoying" (incorrectly formatted etc) mails. | (If you are interested, you can look at | http://lars.marowsky-bree.de/dl/NetiquetteEnforcer.pl ) LM> Now, I meant to port this ages ago, but you know how "I will LM> do it in my copious spare time" works out in practice... LM> I am looking at how to integrate this properly with LM> mailman. What I would probably have to do is to hook in LM> HandlerAPI much like the "Hold" Handler and either hold the LM> message, reject it immediately or let it pass through. LM> However, I am unclear about how to do get the configuration LM> information done properly - I would rather like an additional LM> screen for the Content Filtering scheme in the Web management LM> tools, and it isn't immediately obvious to me how I would go LM> about this. LM> Any insight would be appreciated. Adding a new admin screen is actually pretty easy. I think a good (modern) example is GatewayManager.py or Autoresponder.py. Essentially you are going to write a mixin class that will be added to the base classes for MailList. Your mixin should include a GetConfigInfo() method which contains all the specifications for the gui widgets on your admin screen. You might also need an InitVars() method. Where the black magic comes in: if you're adding new attributes to the MailList object, you should add code to versions.py so that existing list schemas will be automatically updated when the list is loaded. You also need to do a moderate bit of glue work in the MailList class and in the admin.py script. Adding NetiquetteEnforcer as another hold should be much simpler, and I still have it on my todo list for 2.1 to improve the configurability of the holds (so some matches can automatically discard or reject, etc). -Barry From jarrell@vt.edu Sat May 12 01:41:43 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 11 May 2001 20:41:43 -0400 Subject: [Mailman-Developers] Creation/deletion of lists through-the-web In-Reply-To: <15098.57980.802114.12603@anthem.wooz.org> References: <15096.55680.384791.933908@anthem.wooz.org> <20010509101321.61492@scfn.thpl.lib.fl.us> <15097.28677.242197.400892@anthem.wooz.org> <13617.989429942@kanga.nu> <15098.52118.767944.272250@anthem.wooz.org> <20010510133740.47780@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.2.20010511203909.02b2cda0@vtserf.cc.vt.edu> At 02:48 PM 5/10/01 -0400, Barry A. Warsaw wrote: >I still like David's solution best for Sendmail. His solution is slick, but it requires you run mailman lists off of a special hostname. Granted, many of us do, but not everyone. Heck, my mail mailman server has several lists.whoever domains, but also has some orphan lists not claimed by a particular organization that list under the machines own hostname. Which is where mailman insists on creating them by default normally... From chuqui@plaidworks.com Sat May 12 05:47:38 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 11 May 2001 21:47:38 -0700 Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or less...) Message-ID: I've got this running now, so I figured I'd toss out a cookbook recipe on it while it's fresh. I've always hacked Mailman to install a custom interface on it so it matches the rest of my sites (for instance, see www.hockeyfanz.com/mailman/listinfo). The downside to this is that every time a new release comes out, you have to repatch all your changes. This makes it more work to upgrade than it should be, so I've been keeping an eye out for a better way to do this (and it gets worse -- on one of my sites, I also have a web board that needs custom patching, my mhonarc rcfiles that need patching, and the standard files that need tweaking every time the UI or graphics get revamped, and I'm not always in control of when they get redone...) I finally found a tool that takes care of this for me -- it's called mod_layout (www.tangent.org), and it's an apache module, so this is apache specific. If you run your apache with DSO (and if you don't, you're crazy...), installation is trivial. Download the thing, unpack it, then run "make" and "make install". It uses APXS to handle everything. To get it running, I added these lines to the httpd.conf. In my case, they're in the declaration (it supports all fo the apache stuff, so it recognizes and honors virtual hosts, directories, etc... Very flexible beast) # stuff to wire in mod_layout LayoutMerge On LayoutFooter /home/httpd/html/footer.incl LayoutHeader /home/httpd/html/header.incl (I also have some lines causing it to NOT tweak files in directories I want left alone -- it can be configured on a file or directory basis, host basis, or systemwide) Then create the header and footer, and restart apache. What mod_layout does (as configured here) is put itself in the middle of everything, and when it sees the declaration, it inserts the header. And when it sees it inserts the footer before it. For the CGI or html page, it's completely transparent, and you don't have to worry about screwing up CSS or javascript, and it leaves cookies alone. It also doesn't affect your HTML, since it comes after the so it can't interrupt tables or other location sensitive things. Very nice hack, IMHO, and allows you to wrap an interface around mailman quite nicely -- as well as most other CGI-based stuff that doesn't support templating. And even nicer, IMHO, is that if you need to change things, you change the included files -- and it magically propogates, no need to even restart apache. This gives me control over almost all of Mailman (and, hint hint) -- hopefully Barry will add the configuration for the rest down the road. One is that some of the text-box colors are hard-coded (see, for instance, /mailman/admin/listname/general/. It'd be nice (and it seems to be easy to do) to turn those into globals that can be set in mm_cfg.py instead of requiring someone to whack all of the source files they're sprinkled in. The other key one for me are some of the admin messages (Mailman/Handlers/Hold.py). I've modified some of the messages for various reasons, and it'd be nice if I could simply override their definitions in the mm_cfg.py file And the third place I've made custom changes are in some of the list templates (most radically templates/listinfo.html) -- but that's why they're template; you simply keep a copy somewhere and watch out for additions to the updated copy... It took me about three days and a couple of exchanges with the author of mod_layout to get it going the way I wanted (the documentation is still being fleshed out), but it's a nice improvement to the old way of doing things -- and since I know others build custom skins around their installations, I'd thought I'd pass this one along. If you want to see a version of mailman with mod_layout, see www.plaidworks.com. My mailman set up the old way is www.hockeyfanz.com (for now. I'll be working to move this to all my stuff over time...) Chuq From Donal.Hunt2@mail.dcu.ie Sat May 12 18:54:11 2001 From: Donal.Hunt2@mail.dcu.ie (Donal Hunt) Date: Sat, 12 May 2001 18:54:11 +0100 Subject: [Mailman-Developers] Re: Mailman and LDAP integration [was python-ldap and openldap 2.07] References: Message-ID: <3AFD78C3.6138ED36@mail.dcu.ie> Jens Vagelpohl wrote: > > > Have the authentication bit working at the moment. Having a think about > > how to store the mailman subscription information still. Whether to store > > the attributes (subscription type, nomail option, etc) as a sub-object of > > the person object or to have lots of atrributes named in such a way that > > they are unique to their list, but easily searchable and don't add a lot > > of load to the LDAP protocol. Any suggestions or preferences from a > > general POV?? > > i personally would define an object class that has all the mailman-specific > attributes as "MAY"-attributes. then you simply add this object class into > the object class statements for your user records. all mailman-specific > records are then simply stored on your user record along with the rest of > the information. > > you could also create separate records that carry the email address and > mailman-specific stuff (or better, that carry anything needed by mailman), > but then you'd have to make sure that info is in sync with your "normal" > user records in case someone is defined as a normal user record and has a > separate mailman record as well. I'm sure whether to have something like a sub-object with something like: dn: cn=myname, ou=dept, o=company | ---------------------------------------------------- | | dn: maillist=mylist@dom.org, cn=myname, ou=dept, o=company another maillist dn | | |-nomail: yes |-nomail: no |-digest: no |- etc |-etc or dn: cn=myname, ou=dept, o=company | |- some attribute combinations... |- nomail: yes |- digest: yes |- etc the top way of organising things is more scalable and easier to manage (i think). but the second one only allows for one option for all your mailing lists - ie you have digest enabled for all or non e of your mailing list subscriptions. Or maybe i list the mailing list names in the nomail attribute and parse it on the mailman side to see if nomail is set for the particular list. eg: nomail-yes: maillist-1@list.org, maillist-2@list.org nomail-no: maillist-4@list.org, maillist-5@list.org or something along those lines... Hmm... think i should cc this onto Mailman-dev actually... > > As regards code, I'll be releasing it to the Mailman developers and anyone > > who wants it once it's working... > > barry warsaw is working for my company ;) I'm cc-ing this to the Mailman-dev mailing list - I'm subscribed to it, but slightly behind in reading the digests (only by some 75 days!! hehe) - just so they know someone is playing with it. I know it's on the WishList for Mailman 3.x, but no harm in seeing what's involved and exploring the unknown... Regards Donal From claw@kanga.nu Mon May 14 07:21:43 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 13 May 2001 23:21:43 -0700 Subject: [Mailman-Developers] Administrivia: Move to EZMLM (fwd) Message-ID: <2799.989821303@kanga.nu> An message interesting for some of the advantages they see in EZMLM as versus ListServ. While obviously not the driving forces, the comments about Precedence: and Sender: headers caught me by surprise. ------- Forwarded Message Date: Sun, 13 May 2001 23:51:27 -0600 From: aleph1@securityfocus.com To: bugtraq@securityfocus.com Cc: aris-users@securityfocus.com, bugtraq-es@securityfocus.com, bugtraq-jp@securityfocus.com, certification@securityfocus.com, cisspstudy@securityfocus.com, focus-ids@securityfocus.com, focus-linux@securityfocus.com, focus-ms@securityfocus.com, focus-sun@securityfocus.com, focus-virus@securityfocus.com, forensics@securityfocus.com, incidents@securityfocus.com, isn@securityfocus.com, libnet@securityfocus.com, linux-secnews@securityfocus.com, ms-secnews@securityfocus.com, pen-test@securityfocus.com, secevents@securityfocus.com, secpapers@securityfocus.com, secprod@securityfocus.com, secprog@securityfocus.com, sectools@securityfocus.com, security-basics@securityfocus.com, securityjobs@securityfocus.com, sf-news@securityfocus.com, vpn@securityfocus.com, vuln-dev@securityfocus.com, www-mobile-code@securityfocus.com Subject: Administrivia: Move to EZMLM Good day, [ I apologize to those that will receive this message multiple times ] As undoubtedly you will have noticed by now we experienced some problem with our mailing lists this past week. In short, LISTSERV finally croaked. It simply could not handle the load. We hoped to perform the these changes in a couple of months as part of our upgrade strategy but we were forced to accelerate our scheduled plans. We have moved the mailing lists over to ezmlm-idx. This will require a little getting used to but it should not be particularly challenging. ezmlm-idx offers most of the features LISTSERV does and a few of its own. Performance wise it should give LISTSERV a good beating. To familiarize yourself with ezmlm-idx review the ezman manual at http://www.ezmlm.org/ezman-0.32/index.html. If you were using the digest option under LISTSERV you will need to unsubscribe from the list and resubscribe to the digest. This can be easily accomplished by sending messages to the -unsubscribe@securityfocus.com and -digest-subscribe@securityfocus.com addresses. Messages that had been received by LISTSERV but not yet processed, including messages that had become stuck on its queue and appeared to disappear last week, have been re-injected into the mail system. List moderators may, or may not, approve them, as appropriate. Aside from the speed benefits of ezmlm, messages now include a Precedence header which should cut down on the number of out-of-office and similar messages people that post to the list get. This is a feature L-Soft refused to provide. If you ever post to the list this should make you very happy. People that send messages with strange Sender headers should have no more problems either. Another quirk of LISTSERV L-Soft did not believe to be a problem. If you have any questions or comments please feel free to contact me. Cheers. - -- Elias Levy SecurityFocus.com http://www.securityfocus.com/ Si vis pacem, para bellum ------- End of Forwarded Message -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From chuqui@plaidworks.com Mon May 14 07:52:22 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 13 May 2001 23:52:22 -0700 Subject: [Mailman-Developers] Administrivia: Move to EZMLM In-Reply-To: <2799.989821303@kanga.nu> Message-ID: On 5/13/01 11:21 PM, "J C Lawrence" wrote: > While obviously not the driving forces, the > comments about Precedence: and Sender: headers caught me by > surprise. > Aside from the speed benefits of ezmlm, messages now include a > Precedence header which should cut down on the number of out-of-office > and similar messages people that post to the list get. Very true. Precedence: bulk or Precedence: junk helps a lot. Sendmail's vacation program is smart enough to not respond to stuff so flagged. Not everyone does (sigh), but I've tested this, and there's a big improvement. > This is a feature > L-Soft refused to provide. (boggle) > People that send messages with strange Sender headers should have > no more problems either. Another quirk of LISTSERV L-Soft did not > believe to be a problem. The implication being if I insert a Sender line, under some cases LISTSERV does something weird to it? Shouldn't a MLM override this and replace it with the MLM's? From Nigel.Metheringham@InTechnology.co.uk Mon May 14 09:38:41 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Mon, 14 May 2001 09:38:41 +0100 Subject: [Mailman-Developers] Administrivia: Move to EZMLM (fwd) In-Reply-To: Message from J C Lawrence of "Sun, 13 May 2001 23:21:43 PDT." <2799.989821303@kanga.nu> Message-ID: claw@kanga.nu said: > An message interesting for some of the advantages they see in EZMLM as > versus ListServ. While obviously not the driving forces, the comments > about Precedence: and Sender: headers caught me by surprise. Relating this to mailman, it appears to me that we do the right thing (tm) with both those headers. The big advantage with EZMLM is the bounce handling - basically because it uses VERP and mangles the envelope. The downside is the mail-only one address per function (subscriber) control interface (although it is proof against the Outlook user incapable of sending plain unencoded text problem). Those that pay per byte bandwidth charges might also find ezmlm more expensive to run. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From claw@kanga.nu Mon May 14 09:50:21 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 14 May 2001 01:50:21 -0700 Subject: [Mailman-Developers] Administrivia: Move to EZMLM (fwd) In-Reply-To: Message from Nigel Metheringham of "Mon, 14 May 2001 09:38:41 BST." References: Message-ID: <731.989830221@kanga.nu> On Mon, 14 May 2001 09:38:41 +0100 Nigel Metheringham wrote: > The big advantage with EZMLM is the bounce handling - basically > because it uses VERP and mangles the envelope. The downside is > the mail-only one address per function (subscriber) control > interface (although it is proof against the Outlook user incapable > of sending plain unencoded text problem). Those that pay per byte > bandwidth charges might also find ezmlm more expensive to run. It doesn't seem conceptually difficult to setup an Exim filter which could be installed on a smart host such that list mail sent through it is VERPed EZMLM-style. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From jra@baylink.com Mon May 14 14:45:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 14 May 2001 09:45:15 -0400 Subject: [Mailman-Developers] Administrivia: Move to EZMLM In-Reply-To: ; from Chuq Von Rospach on Sun, May 13, 2001 at 11:52:22PM -0700 References: <2799.989821303@kanga.nu> Message-ID: <20010514094515.16447@scfn.thpl.lib.fl.us> On Sun, May 13, 2001 at 11:52:22PM -0700, Chuq Von Rospach wrote: > > This is a feature > > L-Soft refused to provide. > > (boggle) Indeed. > > People that send messages with strange Sender headers should have > > no more problems either. Another quirk of LISTSERV L-Soft did not > > believe to be a problem. > > The implication being if I insert a Sender line, under some cases LISTSERV > does something weird to it? Shouldn't a MLM override this and replace it > with the MLM's? Unless I've *vastly* misunderstood everything I've read: no. It should add Resent- headers, but Sender: carries valid sourcing information, and I don't think it should be replaced. (I'm deriving that from RFC 2822, 3.6.2 and 3.6.6, but I've been known to be wrong before...) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From olk@olk.co.kr Wed May 16 17:50:51 2001 From: olk@olk.co.kr (¿Â¶óÀÎÄÚ¸®¾Æ) Date: Thu, 17 May 2001 01:50:51 +0900 Subject: [Mailman-Developers] mailman-developers´Ô ¾È³çÇϼ¼¿ä? Message-ID: <3W-POP3-AC9EXxt5BBB00000712@3w-pop3-ac.korea.com> PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWljcm9z b2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KPFA+PEZPTlQgY29sb3I9IzAwODAwMCBmYWNlPbG8uLLDvCBzaXplPTI+osQg v8C0w8DHIMCvuNMgosU8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0y PjxGT05UIGNvbG9yPSMwMDAwODA+oeGw+r3Dv+U8L0ZPTlQ+PEJSPkEgZ2lybCBnb3QgYW4g DQplbmdhZ2VtZW50IHJpbmcsIGFuZCB3b3VsZCBzZWl6ZSBldmVyeSBvcHBvcnR1bml0eSBm b3IgPEJSPmNhbGxpbmcgYXR0ZW50aW9uIHRvIA0KaXQuJm5ic3A7IDxCUj5JbiBhIGdyb3Vw IHdpdGggZ2lybCBmcmllbmRzIG5vIG9uZSBub3RpY2VkIGl0LiZuYnNwOyBGaW5hbGx5IHdo ZW4gDQpoZXI8QlI+ZnJpZW5kcyB3ZXJlIHNpdHRpbmcgYXJvdW5kIHRhbGtpbmcsIHNoZSBn b3QgdXAgc3VkZGVubHkgYW5kIHNhaWQsIA0KPEJSPiJJdCdzIGF3ZnVsbHkgaG90IGluIGhl cmUuIEkgdGhpbmsgSSdsbCB0YWtlIG15IHJpbmcgb2ZmLiI8L0ZPTlQ+PC9QPg0KPFA+PEZP TlQgZmFjZT2xvLiyw7wgc2l6ZT0yPqHec2VpemUgZXZlcnkgb3Bwb3J0dW5pdHkgZm9yIH4g aW5nIDogseLIuLi4IMDWwLi46SB+IA0Kx8+02S48QlI+od5jYWxsIGF0dGVudGlvbiB0byA6 IH4gv6EgwdbAx7imIMivseK9w8WwtNkuIDxCUj6h3mF3ZnVsbHkgOiB2ZXJ5IDwvRk9OVD48 L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+vuDIpbndwfa4piC53sC6IL7GsKG+ vrTCILHiyLi4uCDA1sC4uOkgu+e297Xpv6Gw1CCx1yC53cH2uKYguri/qcHWt8Gw7SZuYnNw OyANCjxCUj616b76tNkmbmJzcDsgPEJSPsfRufjAuiC/qcDaxKOxuLXpsPogvu6/77fItMK1 pSC+xrmrtbUgsdcgud3B9rimILSrv6mw3CC6wcHWwfYgvsq+0rTZPEJSPri2xKezuyC+xrCh vr60wiC02bXpILXRt6++yb7GIA0KwMy+37HiuKYgs6q0qbDtIMDWtMIgxse/oSC5+raxIMDP vu68rbjpvK0gPEJSPri7x9+02S48QlI+Ir7uyN4sILT1v/a8rSC4+CCw37XwsNqz1y4gs6og ud3B9rimILupvt8gx9Kx7rrBISImbmJzcDsgDQo8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgY29s b3I9IzAwODAwMCBmYWNlPbG8uLLDvCBzaXplPTI+osQgv8C0w8DHIL+1vu4gx9G4trXwIKLF PC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48Rk9OVCBjb2xvcj0j MDAwMDgwPqLDILCou+fAxyC4u8C7IMfSILanPEJSPjwvRk9OVD6/3LG5wM616cC6ILOyv6Gw 1CC+xsHWIA0KwNvAuiC1tb/ywLsgud6+xrW1ICJUaGFuayB5b3UuKLCou+fH1bTPtNkuKSK2 87DtIDxCUj64u8fYv+QuIMDMsM3AuiC+7rfIwLsgtqe6zsXNILHXt7EgsbPAsMC7ILnewLi4 6bytIMDatvMgv9Sx4iC2p7muv6EguPa/oSANCjxCUj66o77uIMDWvu4gu/O067nmwMcgu+e8 0sfRILW1v/LAzLOqIMSjwP2/obW1ICJUaGFuayB5b3UuIrbzsO0guLvHz7TCIL3AsPw8QlI+ wLsgsK6w1CC1yLDFILCwvsa/5C4gubC30Cwgv+y4rrW1IA0KuLbC+bChwfbB9ri4v+QuPEJS PiJUaGFuayB5b3UuIr+hILTrx9EgwMC05MC6ICLDtbi4v6G/5C4itvO0wiC25sC4t84gIllv dSBhcmUgd2VsY29tZS4gLzxCUj5Eb24ndCANCm1lbnRpb24gaXQuIC9Ob3QgYXQgYWxsLiK1 7sDHIMelx/bAuyC+ssHSLiA8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6 ZT0yPkE6IEl0IHdhcyB2ZXJ5IGtpbmQgb2YgeW91IHRvIGdvIHRvIHRoYXQgdHJvdWJsZSBm b3IgDQptZS48QlI+QjogSXQgd2FzIG5vIHRyb3VibGUgYXQgYWxsLiBJdCB3YXMgbXkgcGxl YXN1cmUuPEJSPkE6IEl0J3MgdmVyeSBraW5kIG9mIA0KeW91IHRvIHNheSBzby48QlI+Jm5i c3A7PEJSPkE6IMD6uKYgwKfH2LytILHXt7EgvPaw7bimIMfYIMHWvcO0zyDBpLi7ILDtuL+9 wLTPtNkuPEJSPkI6ILm5ILz2sO229iCwzcDMIMDWs6q/5C4gDQrBprChIMHBvsa8rSDH0SDA z8DOtaW/5C48QlI+QTogsde3uLDUILi7vrjH2CDB1r3DtM8gwaS4uyCw7bi/vcC0z7TZLjxC Uj4mbmJzcDs8QlI+PEZPTlQgY29sb3I9IzAwMDA4MD6h4bCou+fAxyANCrHiursgx6XH9jxC Uj48L0ZPTlQ+osIgVGhhbmsgeW91LiAvVGhhbmtzLjxCUj4mbmJzcDsmbmJzcDsgormwqLvn x9W0z7TZLjxCUj6iwiBUaGFua3MgYSBsb3QuIA0KL1RoYW5rIHlvdSB2ZXJ5IG11Y2guIC9U aGFuayB5b3Ugc28gbXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5tOu03Mj3ILCou+fH1bTPtNku PEJSPqLCIEknZCANCmFwcHJlY2lhdGUgaXQuPEJSPiZuYnNwOyZuYnNwOyCiubHXt7iw1CDH 2CDB1r3DuOkgsKi758fPsNq9wLTPtNkuPEJSPqLCIEkgYXBwcmVjaWF0ZSBpdCB2ZXJ5IA0K bXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5sdcgwaEgwaS4uyCwqLvnx9W0z7TZLjxCUj6iwiBP biBiZWhhbGYgb2Ygb3VyIGVtcGxveWVlcyBJJ2QgbGlrZSB0byANCnRoYW5rIHlvdS48QlI+ Jm5ic3A7Jm5ic3A7IKK5wPrI8SDIuLvnv/i16cC7ILTrx6XH2LytILTnvcW/obDUILCou+cg teW4rrDtIL3NvcC0z7TZLjxCUj4mbmJzcDs8QlI+PEZPTlQgDQpjb2xvcj0jMDA4MDAwPqLE IMDfuPggvrLAzyC89iDA1rTCIMelx/YgosU8QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBj b2xvcj0jMDAwMDgwPqLDIL+pseK8rSANCjHIo7yxwLi3ziCwpb7Gxbi8xb7fIMfVtM+02Twv Rk9OVD48QlI+Jm5ic3A7PEJSPjxGT05UIGNvbG9yPSNmZjAwMDA+oeFZb3UgaGF2ZSB0byBz aGlmdCB0byANCnRoZSBOby4xIExpbmUuoeuh66Hroeuh66Hroeuh66Hroeuh66HtKFgpPEJS PjwvRk9OVD48Rk9OVCBjb2xvcj0jODAwMDgwPqHhWW91J2xsIGhhdmUgdG8gDQp0cmFuc2Zl ciB0byB0aGUgTm8uMSBMaW5lIGZyb20gaGVyZS6h66Hroeuh7ShPKTxCUj4mbmJzcDs8QlI+ PC9GT05UPqLBc2hpZnS0wiC067CzILDFwdbB9rOqIA0Ku/2wosC7ILnZstu02bTCILbmwMy5 x7fOIL+pseK8rbTCILjCwfYgvsq+xr/kLiA8QlI+Jm5ic3A7ILGzxevG7cC7ILClvsbFuLTC ILDNwLogurjF6yB0cmFuc2ZlcrbzsO0gx9i/5C4gsde4rrDtILPrvLHAuyANCrClvsbFuLTC IDxCUj4mbmJzcDsgyK+9wr+qtbUgdHJhbnNmZXK287DtIMfPtMK1pSwgwMy2p7TCILjtu+fA 1LTPtNkuIDxCUj4mbmJzcDsguvHH4LHiIL+px+Agwd+/oSCwpb7Gxbi0wiCx4sL4wfa0wiAN CnN0b3BvdmVytvOw7SDH2L/kLjxCUj4mbmJzcDs8QlI+od5Ob3cgeW91IGhhdmUgdG8gc3dp dGNoIHRvIHRoZSBOby4xIExpbmUuKL+pseK8rSAxyKO8scC4t84gDQqwpb7Gxbi8vL/kLik8 QlI+od5Zb3UgaGF2ZSB0byBnZXQgb3ZlciB0byB0aGUgTm8uMSBMaW5lLigxyKO8sSDCysC4 t84gsKG8xbytIMW4vLy/5C4pPC9GT05UPjwvUD4NCjxQPjxGT05UIGNvbG9yPSMwMDgwMDAg ZmFjZT2xvLiyw7wgc2l6ZT0yPqLEIL/AtMPAxyDAz77uIMfRuLa18CCixTwvRk9OVD48L1A+ DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+osLAz7q7vu61tSC/tb7uv80gsLDAuiDH /MXCt84gsbi8urXHvu4gwNa9wLTPtNkuPEJSPjxGT05UIA0KY29sb3I9IzAwODA4MD6h66Hr oeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hr oeuh66Hroeuh66HrPC9GT05UPjxCUj5tYWlsbWFuLWRldmVsb3BlcnO01CC+yLPnx8+8vL/k PyANCjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+wPrI8bTCIMD8 yK24piDAzL/rx9i8rSCwrbvnv80gMSA6IDEgt84gv9yxub7uIMfQvcDAuyDH0iC89iDA1rTC IDxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cub2xrLmNvLmtyIj6ixCBPbmxpbmUgS29yZWEg osUgPC9BPrbzsO0gx9W0z7TZLjxCUj65zLiuIMfjtvS53sH2IL7KsO0gxu3B9iC15bfBIA0K wcu828fVtM+02S4gus618CCzyrHXt6+/7L3FIL/rvK24pi4uLi4uLjwvRk9OVD48L1A+DQo8 UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+wPrI8SDIuLvnv6G8rbTCIL/csbm+7ii/tb7u LMDPvu4pv6EgsPy9ySDA1rTCILi5wLogutC16bKyILjFwM8ov/ktsd0pLCA8QlI+v7W+7sCv uNO/zSANCrv9yLC/oSDHyr/kx9EgyLjIrSDH0SC5rsDlvr/AuyC5q7fht84gurizuyC15biu sO0gwNa+7r/kLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+wKe/ zSCwsMC6ILO7v+vAxyC8rbrxvbq4piC53r7Gurix4iC/+MfPvcO46SCh7CA8QSANCmhyZWY9 Im1haWx0bzpvbGtAb2xrLmNvLmtyIj5vbGtAb2xrLmNvLmtyPC9BPiCh7bfOIDxCUj4iPEZP TlQgDQpjb2xvcj0jZmYwMDAwPnllczwvRk9OVD4itvO0wiCzu7/rwMcgtOTA5cC7IMHWvcOx 4iC52bb4tM+02S4gPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj6x 17iusO0sIMD6yPEgwPzIrSC/3LG5vu4gsK3Ax7ChILHDsd3Hz73FILrQtenAuyDAp8fYLCAx yLi/oSDH0cfYvK08QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3Lm9say5jby5rci9pbnN0aV9m cmFtZS5odG0iPqLCILmrt+EgvcO5/LCtwMcgosI8L0E+tbUgvce9w8fYILXluK6w7SDA1sC4 tM8gx9G5+CC16b7uuriw7SANCr3NwLi9w7jpIDxCUj7B9rHdIL3Fw7vH2CDB1ry8v+QuPC9G T05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj65q7fhIL3DufywrcDHIL3F w7sguea5/cC6IDxBIA0KaHJlZj0iaHR0cDovL3d3dy5vbGsuY28ua3IvaW5zdGlfZnJhbWUu aHRtIj6iuiDAzLD3IKK4IDwvQT7AuyDFrLivx8+9xSDIxCCwrcDHIL3Fw7u29b+hIA0KwNa0 wjxCUj69w7n8sK3AxyC9xcO7IMb7wLsgwNu8usfPvMW8rSC6uLO7IMHWvcO46SC1y7TPtNku PEJSPrmwt9AsIMD8yK0gPEZPTlQgY29sb3I9I2ZmMDAwMD4wMi01ODgtMDUxMCANCjwvRk9O VD7AuLfOtbUgvcXDu8fPvccgvPYgwNaxuL/kLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNl PbG8uLLDvCBzaXplPTI+vsa5q8LJt88gwMwgx9C9wLn9wMwgbWFpbG1hbi1kZXZlbG9wZXJz tNTAxyDIuMitIL3Ht8Igx+K787+hIMDbwLogurjFxsDMIDxCUj61x776wLi46SANCsfVtM+0 2S48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPm1haWxtYW4tZGV2 ZWxvcGVyc7TUsrK0wiBodHRwOi8vd3d3LmtyLmdudS5vcmcvZGlyZWN0b3J5L21haWxtYW4u aHRtbL+hIMDWtMIgwda80rimILq4sO0guN7AzyC15bfItMK1pb/kLDxCUj660sfKv+TH0SAN CsGkuri/tLTZuOkgwaS4uyDBy7zbx9W0z7TZLjxCUj6+1cC4t84gx+O29L74tMIguN7Az8C6 ILXluK7B9iC+yrW1t88gx8+w2r3AtM+02S48QlI+sde3sywgvsiz58j3IA0KsOi8vL/kLjwv Rk9OVD48L1A+DQo8L0JPRFk+DQo8L0hUTUw+DQo= From marc_news@valinux.com Tue May 15 02:05:12 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 14 May 2001 18:05:12 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15099.2244.184017.746400@anthem.wooz.org>; from barry@digicool.com on Thu, May 10, 2001 at 05:31:48PM -0400 References: <15094.52272.753043.181192@anthem.wooz.org> <20010509104304.J29713@magic.merlins.org> <20010510134257.Q31816@magic.merlins.org> <15099.2244.184017.746400@anthem.wooz.org> Message-ID: <20010514180512.B4194@moremagic.merlins.org> On Thu, May 10, 2001 at 05:31:48PM -0400, Barry A. Warsaw wrote: > If I get some time, I'll stare at the LockFile.py code again. Any > idea what process 8790 was? I wonder if it's the same code that's > not cleaning up after itself. Sorry for the late answer. I did look in the logfiles, but nothing showed up with pid 8790. Kinda weird... That said, we just got a list with 10,000+ users (nuked since then, see message sent after this one), and loading the admin page up took a while. My locks directory now has 35 desi-os-maps.lock.usw-sf-list1.pid files. Then again, it doesn't block the list, so it's not that bad 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@valinux.com Tue May 15 02:05:27 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 14 May 2001 18:05:27 -0700 Subject: [Mailman-Developers] Feature request Message-ID: <20010514180527.T1487@magic.merlins.org> Looking at it now, it's surprising that this hasn't happened sooner: SF's mailman was abused with someone creating a bogus project with a mailing list which was then used to subscribe about 10,000 people and then spam them into oblivion. The best/worst part is how people made it a lot worse by complaining to the list itself and spamming one another after that: http://www.geocrawler.com/lists/3/SourceForge/10386/0/ Anyway, I patched admin.py to just disallow admin web subscribes altogether. In order of preference, for a future mailman version, it'd be nice if mailman would: - Have a config.db entry: allow web subscribes, that can only be changed by the mailman owner (i.e. master password, not list password) - Easier: have a sitewide mm_cfg.py variable to allow/disallow web subscribes by the list admin Thanks, 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 Tue May 15 02:09:35 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 14 May 2001 18:09:35 -0700 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.5 In-Reply-To: <20010514180512.B4194@moremagic.merlins.org> Message-ID: On 5/14/01 6:05 PM, "Marc MERLIN" wrote: > > Sorry for the late answer. > I did look in the logfiles, but nothing showed up with pid 8790. > Kinda weird... > > That said, we just got a list with 10,000+ users (nuked since then, see > message sent after this one), and loading the admin page up took a while. > My locks directory now has 35 desi-os-maps.lock.usw-sf-list1.pid files. That implies to me that your process has the list locked, and other people are trying to access it, finding it locked and exiting -- but leaving a lockfile dribble behind. From chuqui@plaidworks.com Tue May 15 04:32:17 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 14 May 2001 20:32:17 -0700 Subject: [Mailman-Developers] Feature request In-Reply-To: <20010514180527.T1487@magic.merlins.org> Message-ID: On 5/14/01 6:05 PM, "Marc MERLIN" wrote: > Looking at it now, it's surprising that this hasn't happened sooner: SF's > mailman was abused with someone creating a bogus project with a mailing list > which was then used to subscribe about 10,000 people and then spam them into > oblivion. It was going to happen sooner or later if you have people allowed to create stuff without adult supervision. This has been a continuing discussion in the list-managers area, because of the problem of places like yahoo groups that allow this kind of thing. Unfortunately, fi you have a large population, administratively babysitting them becomes really time intensive, so you have to find 'reasonable' tradeoffs here. > - Have a config.db entry: allow web subscribes, that can only be changed by > the mailman owner (i.e. master password, not list password) This is one of the basic realities -- either disabling or limiting the size of web imports until someone has been 'cleared' as a trusted admin. That would mean some form of vetting procedurel, which means a human body in place to make sure things are legit. Until that happens, web-loads are limited to small values (because, honestly, you don't want to bother with small groups -- at worst, the damage is minimal, and most likely, someone loading in 100 addresses isn't spamming, the larger the number, the less likely it's legit). Unfortunately, while we want to automate stuff, there are places where human bodies have to step in, and having the human body in place solves 90% of the problem, because the idiots won't bother trying -- unless they're really stupid or really arrogant. My idea is that permission is done on a per-admin basis. Once you've vetted a guy on one list, you don't want to have to manually re-vet them on their next list, and the next, and... And without it, you're limited to 150 subscribers via auto-loads of any sort, and to be vetted, you have to request permission, and you have to be findable through a verifiable, non-free e-mail address. That means even if the list is officially run from, say, fred@hotmail.com, you can't be vetted as admin from there -- there has to be a "real" address, not a throwaway one. And places like sourceforge get to define 'real' and "throwaway" as they see fit... From marc_news@valinux.com Tue May 15 04:48:40 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 14 May 2001 20:48:40 -0700 Subject: [Mailman-Developers] Feature request In-Reply-To: ; from chuqui@plaidworks.com on Mon, May 14, 2001 at 08:32:17PM -0700 References: <20010514180527.T1487@magic.merlins.org> Message-ID: <20010514204839.N15537@magic.merlins.org> On Mon, May 14, 2001 at 08:32:17PM -0700, Chuq Von Rospach wrote: > > Looking at it now, it's surprising that this hasn't happened sooner: SF's > > mailman was abused with someone creating a bogus project with a mailing list > > which was then used to subscribe about 10,000 people and then spam them into > > oblivion. > > It was going to happen sooner or later if you have people allowed to create > stuff without adult supervision. Turns out that it actually was a misguided user with a real project who apparently thought a lot of people should know about it. The problem remains though. BTW, there is adult supervision, SF does check and approve projects one per one, but there isn't much you can do about people who lie and set up a phony project that looks real. > > - Have a config.db entry: allow web subscribes, that can only be changed by > > the mailman owner (i.e. master password, not list password) > > This is one of the basic realities -- either disabling or limiting the size > of web imports until someone has been 'cleared' as a trusted admin. That > would mean some form of vetting procedurel, which means a human body in > place to make sure things are legit. Until that happens, web-loads are > limited to small values (because, honestly, you don't want to bother with > small groups -- at worst, the damage is minimal, and most likely, someone > loading in 100 addresses isn't spamming, the larger the number, the less > likely it's legit). Agreed. Note that it introduces the concept of an uber user who gets those admin check Emails and other things to confirm instead of the list admin. > My idea is that permission is done on a per-admin basis. Once you've vetted > a guy on one list, you don't want to have to manually re-vet them on their > next list, and the next, and... That could work for some, but doesn't help that much with a determined spammer who lies to get this access and then does the bad deed. That said, it'd still be a lot better than what we have now. I guess the best would be to have a config option that says what the max number of people who can be added through the web is (0 being a possibility) Having oversized adds go to a site admin for confirmation instead of just failing would be an added bonus. 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 Tue May 15 04:59:21 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 14 May 2001 20:59:21 -0700 Subject: [Mailman-Developers] Feature request In-Reply-To: <20010514204839.N15537@magic.merlins.org> Message-ID: On 5/14/01 8:48 PM, "Marc MERLIN" wrote: > Turns out that it actually was a misguided user with a real project who > apparently thought a lot of people should know about it. > The problem remains though. Zealots are zealots, whether it's their business, product, god or politics... (grin) > BTW, there is adult supervision, SF does check and approve projects one per > one, but there isn't much you can do about people who lie and set up a phony > project that looks real. True -- which puts you a step ahead of yahoogroups, but as you note, it's not all that difficult to fake it enough to look legit. It's really a difficult thing to solve -- especially if you can't "track back" a user past a disposable email address at hotmail or any of the other freebies. If you have a trackable address, you have a chance of having THEIR ISP break a kneecap for you, and at the least, you can ban the user (and if necessary) the ISP to limit future damages.... > Note that it introduces the concept of an uber user who gets those admin > check Emails and other things to confirm instead of the list admin. Well, I use the following concepts in my sites: O site mom: basically, god. O list mom: god for a list. O assistant list mom: does the stuff the list mom can pawn off on them. O content mom: handles mail that hits the admin page for some kind of hold, and monitors/administers the content of the list. You need a site mom to oversee everything and set policy (and vet/train/monitor/break kneecaps on list moms). List moms handle administrative stuff and have access to the subscribe pages; content moms don't -- each list tends to organize as it sees fit around those restrictions. Seems to work okay. It allows the list owner to hand off part or all of the list responsbility (at Apple, no list exists without an internal sponsor; that sponsor may or may not manage the list -- it might be someone in that group, or they may bonk an outside person to handle day to day operations). And responsibility flows upstairs, and memos flow back down.. (snicker) > That could work for some, but doesn't help that much with a determined > spammer who lies to get this access and then does the bad deed. But that's why you have to require a 'verifiable' address -- so if they do it, you have a chance of having an ISP be responsible for it, and if not, at least you can nuke that account and ISP from the 'verifiable' list so they can't pull it twice. > I guess the best would be to have a config option that says what the max > number of people who can be added through the web is (0 being a possibility) > > Having oversized adds go to a site admin for confirmation instead of just > failing would be an added bonus. Agreed and agreed -- it'd give the admin a chance to, say, pull a random subset to verify they'd agreed to this. If the list comes up clean, good. If not, you know you have a problem. From barry@digicool.com Wed May 16 20:04:24 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 16 May 2001 15:04:24 -0400 Subject: [Mailman-Developers] Virtual hosting Message-ID: <15106.53048.622149.841936@anthem.wooz.org> I've started to sketch out some requirements for improving the virtual hosting support for Mailman. It's not finished, but I'm soliciting comments anyway. Please see http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting and please add comments to the Wiki page. I'm not sure whether this stuff will make it into Mailman 2.1 or will have to be postponed. Cheers, -Barry From barry@digicool.com Wed May 16 20:10:05 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 16 May 2001 15:10:05 -0400 Subject: [Mailman-Developers] Feature request References: <20010514180527.T1487@magic.merlins.org> Message-ID: <15106.53389.341765.198492@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> My idea is that permission is done on a per-admin basis. Once CVR> you've vetted a guy on one list, you don't want to have to CVR> manually re-vet them on their next list, and the next, and... I think this is the right approach, but has the disadvantage of being unweildy until we've rearchitected the user database and authentication components. Which will not happen for MM2.1. -Barry From jj-list@mail.dk Thu May 17 00:49:54 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Thu, 17 May 2001 01:49:54 +0200 Subject: [Mailman-Developers] Moderator approval Message-ID: <5.1.0.14.0.20010517012616.04088a10@wheresmymailserver.com> I saw this on the Mailman 2.1 Wiki page: "Provide an email interface to all administrative commands" Does this include the approval of moderated messages? If so, has any work been done on this or do you know how it will work? Will it be (or is it already) possible to have the approval sent to more than one person? Thanks, Jesper. From barry@digicool.com Thu May 17 01:59:23 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 16 May 2001 20:59:23 -0400 Subject: [Mailman-Developers] Moderator approval References: <5.1.0.14.0.20010517012616.04088a10@wheresmymailserver.com> Message-ID: <15107.8811.880968.937449@anthem.wooz.org> >>>>> "JJ" == Jesper Jensen writes: JJ> I saw this on the Mailman 2.1 Wiki page: JJ> "Provide an email interface to all administrative commands" JJ> Does this include the approval of moderated messages? Yes, especially so! This is very high on my personal threshold of pain. :) JJ> If so, has any work been done on this or do you know how it JJ> will work? No work's been done on it yet. I'm not sure exactly how I'm going to do it, other than to probably hook into the new confirmation stuff already in CVS. The problem is that there are two outcomes: reject or approve. Which do you make easiest? (Probably reject since it's much more common.) Maybe there's auto-reject by default or timeout, with approvals being the easy path. Not sure yet. JJ> Will it be (or is it already) possible to have the approval JJ> sent to more than one person? I'm toying with the idea of adding a moderators' role, separate from and with fewer privs than the list owner. Even without that, such confirmations will be sent to the list owners, so yes. -Barry From tkikuchi@is.kochi-u.ac.jp Thu May 17 04:03:50 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu, 17 May 2001 12:03:50 +0900 Subject: [Mailman-Developers] How about Auto Discard Message-ID: <3B033F96.CF44CFB9@is.kochi-u.ac.jp> Hi! Developers, It is cumbersome to click 'Discard' on the admindb page each time a spam message come to the list address or at least every day basis. If we have an automatic discard function which will be ivoked by cron, we can just check the admin notice and do nothing. The held message will disappear two or three days later. Following script will do the job (I hope). Please review it and comment! Would it be better to define the expiration period in mm_cfg.py ? (I omitted the copyright/license notices) Regards, Tokio Kikuchi #!/usr/bin/env python # import sys import paths import time from Mailman import mm_cfg from Mailman import MailList from Mailman import Utils expire = 2 * 24 * 60 * 60 # 2 days now = time.time() def auto_discard(mlist): if not mlist.NumRequestsPending(): return heldmsgs = mlist.GetHeldMessageIds() total = len(heldmsgs) if total: for id in heldmsgs: info = mlist.GetRecord(id) ptime,sender,subject,reason,filename,msgdata = info if now - ptime > expire: print 'DISCARD',id, ptime, sender, subject mlist.HandleRequest(id, mm_cfg.DISCARD) mlist.Save() def main(): confined_to = sys.argv[1:] for listname in Utils.list_names(): if confined_to and listname not in confined_to: continue mlist = MailList.MailList(listname, lock=0) mlist.Lock() auto_discard(mlist) mlist.Unlock() if __name__ == '__main__': main() From wheakory@isu.edu Thu May 17 06:01:25 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Wed, 16 May 2001 23:01:25 -0600 Subject: [Mailman-Developers] Mailman error Bad Marshal Message-ID: <3B035B25.21C076A5@isu.edu> Received this for a hour and then it went away everything worked after that, but is there any solution to this problem. ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/wrapper mailowner ccaussec" (expanded from: ccaussec-admin) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/scripts/mailowner", line 33, in ? from Mailman import MailList ValueError: bad marshal data 554 "|/home/mailman/mail/wrapper mailowner ccaussec"... unknown mailer error 1 From Nigel.Metheringham@InTechnology.co.uk Thu May 17 09:41:07 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Thu, 17 May 2001 09:41:07 +0100 Subject: [Mailman-Developers] Moderator approval In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 16 May 2001 20:59:23 EDT." <15107.8811.880968.937449@anthem.wooz.org> Message-ID: barry@digicool.com said: > The problem is that there are two outcomes: reject or approve. Which > do you make easiest? (Probably reject since it's much more common.) Actually I approve the majority of stuff - since I run all my lists with member posting only, but people either post relevant stuff as non-members, or they have multiple email addresses and use the wrong one. I also discard a lot of items - however thats a peculiarity of how the list is set up in this case. If mail based moderation is available, then there needs to be an option to send more of the original message out with the notification of waiting mail - or a way of getting some header and body data back. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jcrey@uma.es Thu May 17 11:36:13 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Thu, 17 May 2001 12:36:13 +0200 Subject: [Mailman-Developers] Error in bin/config_list Message-ID: <3B03A99D.D9AC7C8@uma.es> I have received a message with the error description: Vizi Szilard > - I found an error: > [root@tatooin bin]# ./config_list -o /root/config test > Traceback (most recent call last): > File "./config_list", line 261, in ? > main() > File "./config_list", line 254, in main > do_output(listname, outfile) > File "./config_list", line 115, in do_output > info =3D config[k] > KeyError: altalanos = > = > altalanos means general in English. What is the problem? I have taken a glance to Mailman code and I have found: in MailList.py.GetConfigInfo: config_info['general'] =3D [_( "Fundamental list characteristics, including descriptive" " info and basic behaviors."), ('real_name', mm_cfg.String, 50, 0, _('The public name of this list (make case-changes only).'), and in config_list.do_output: config =3D mlist.GetConfigInfo() categories =3D (_('general'), _('privacy'), _('nondigest'), _('digest'), _('bounce'), _('archive'), _('gateway'), _('autoreply')) for k in categories: info =3D config[k] So 'k' must be untranslated, that's because that key does not exists in array 'config' -- = ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From barry@digicool.com Thu May 17 15:55:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 17 May 2001 10:55:35 -0400 Subject: [Mailman-Developers] Moderator approval References: <15107.8811.880968.937449@anthem.wooz.org> Message-ID: <15107.58983.480918.413334@anthem.wooz.org> >>>>> "NM" == Nigel Metheringham >>>>> writes: NM> If mail based moderation is available, then there needs to be NM> an option to send more of the original message out with the NM> notification of waiting mail - or a way of getting some header NM> and body data back. Oh absolutely! I think the right solution is to include the entire original message as an attachment (preferrably MIME, but there probably needs to be a non-MIME option). -Barry From barry@digicool.com Fri May 18 19:28:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 18 May 2001 14:28:40 -0400 Subject: [Mailman-Developers] Template file lookup Message-ID: <15109.27096.120852.101214@anthem.wooz.org> I'm about to change the search order for templates -- you know, those pesky .html and .txt files that live in $prefix/templates and $prefix/lists/$mylist. This change is necessary to properly support language templates, and also provides a much requested feature, namely that you will only need to specialize templates that you actually want to change, and that you have multiple levels of specialization. Here's how it works. There are 4 levels of template specialization: list-centric, vhost-centric, site-centric, and default, corresponding to the directories $prefix/lists/$listname $prefix/templates/$host_name $prefix/templates/site $prefix/templates Each of these locations is further organized by language subdirectories. So let's say you were looking for the listinfo.html template for list foobar in language es. You'd actually end up searching 12 directories, with of course, the first hit stopping the search. Let's say further that list foobar is in the www.foobar.com virtual domain, and that it's list-preferred language is fr, while the server's default language is en. Here's the files you'd search for: $prefix/lists/foobar/es/listinfo.html $prefix/templates/www.foobar.com/es/listinfo.html $prefix/templates/site/es/listinfo.html $prefix/templates/es/listinfo.html $prefix/lists/foobar/fr/listinfo.html $prefix/templates/www.foobar.com/fr/listinfo.html $prefix/templates/site/fr/listinfo.html $prefix/templates/fr/listinfo.html $prefix/lists/foobar/en/listinfo.html $prefix/templates/www.foobar.com/en/listinfo.html $prefix/templates/site/en/listinfo.html $prefix/templates/en/listinfo.html Note that the Mailman 2.0.x search directories of $prefix/lists/*.{html,txt} and $prefix/templates/*.{html,txt} are deprecated and no longer searched. The bin/upgrade script will actually md5 checksum all the old files and remove any templates in more-specific locations that exactly match their more-general counterparts. Any template in $prefix/lists or $templates will have to be moved manually. It is highly discouraged that you will ever manually edit a file in $prefix/templates/$lang, and Mailman's install target will have every right to overwrite them on an upgrade. That's what the templates/site subdirectory is for; upgrading will never touch site-centric, domain-centric, or list-centric templates. Of course, that means it's up to site administrators to merge in changes to the default templates. Watch for checkins shortly. Comments? -Barry From scott-brown@home.com Fri May 18 21:39:11 2001 From: scott-brown@home.com (Scott Brown) Date: Fri, 18 May 2001 16:39:11 -0400 Subject: [Mailman-Developers] Template file lookup In-Reply-To: <15109.27096.120852.101214@anthem.wooz.org> Message-ID: <007201c0dfda$991aaa20$0401a8c0@ibmpeers> [majority removed] > It is highly discouraged that you will ever manually edit a file in > $prefix/templates/$lang, and Mailman's install target will have every > right to overwrite them on an upgrade. That's what the templates/site > subdirectory is for; upgrading will never touch site-centric, > domain-centric, or list-centric templates. Of course, that means it's > up to site administrators to merge in changes to the default > templates. > > Watch for checkins shortly. > > Comments? Dont know if you read my comments on the wikki, but as a small (very small :) hosting co owner, I'd like to see some way of maintaining virt domain specific information within the virt domain directory tree... something like: $prefix = master mailman install directory $virtprefix = site specific data file directory (eg /home/somedomain.com/mailman) $virtprefix/lists/{lang}/listinfo.html $virtprefix/templates/{lang}/listinfo.html $prefix/templates/site/{lang}/listinfo.html $prefix/templates/{lang}/listinfo.html Plaster appropriate protection to keep people meddling with them - but dont hide them off somewhere else on the disk - keep them with the virtual domain itself. Gives two benefits (that I see): 1 - all the files associated with that domain are hung under one tree - making backup/restore of individual domains simpler. 2 - those host co's using soft quotas dont have to scour the disk looking for files that should be applied against each virt domain. Could be more - but my mind is elsewhere right now. From bakyh@etri.re.kr Sat May 19 06:32:13 2001 From: bakyh@etri.re.kr (bakyh@etri.re.kr) Date: Sat, 19 May 2001 14:32:13 +0900 Subject: [Mailman-Developers] =?euc-kr?B?W8D8w7zIuL3FXSBbTWFpbG1hbi1pMThuXSBjYW4ndCBkZWNvZGUg?= =?euc-kr?B?aW4gd2ViIHVzaW5nIG1haWxtYW4u?= Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A1BFD1F@cms3.etri.re.kr> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E025.0ED6E4F0 Content-Type: text/plain; charset="euc-kr" I'm a korean. I installed a mailman to Linux 2.2.18. I succeed in sending and receiving msg, but in web failed. In web, I can't read msg in Korean. How can I do it? I think, its reason is that in web browser can't decoding that msg. Shoud I patch about it? What is the patch program and where I can get it? Please, help me. Bak, Yuhyeon. ------_=_NextPart_001_01C0E025.0ED6E4F0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] [Mailman-i18n] can't decode in web = using mailman.

                      I'm a korean.

                      I installed a mailman to Linux 2.2.18.

                      I succeed in sending and receiving msg, but in web = failed.

                      In web, I can't read msg in Korean.

                      How can I do it?

                      I think, its reason is that in web browser can't = decoding that msg.

                      Shoud I patch about it?

                      What is the patch program and where I can get = it?
                       

                      Please, help me.

                       

                      Bak, Yuhyeon.

                       

                      ------_=_NextPart_001_01C0E025.0ED6E4F0-- From tkikuchi@is.kochi-u.ac.jp Sat May 19 15:10:06 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 19 May 2001 23:10:06 +0900 Subject: [Mailman-Developers] Re: [Mailman-i18n] can't decode in web using mailman. References: <766FA1FC5C2AD511B3C800D0B7A8AC4A1BFD1F@cms3.etri.re.kr> Message-ID: <3B067EBE.D6E830EC@is.kochi-u.ac.jp> > bakyh@etri.re.kr wrote: > > I'm a korean. > > I installed a mailman to Linux 2.2.18. > > I succeed in sending and receiving msg, but in web failed. > > In web, I can't read msg in Korean. Hi, I am a japanese. What is the default charset for Korean language. If the charset is other than EUC-KR, then the double-byte code may contain special characters like <,>,&. Japanese mail message is encoded with ISO-2022-JP while the Web pages and internal language data are best treated in EUC-JP. I made short scripts to convert the messages between ISO-2022-JP and EUC-JP and put them in Mailman/Handlers. You may want to browse the scripts, to_euc.py and to_jis.py, which are included in Japanese Mailman at http://mm.tkikuchi.net/mailman-2.0.5+J1.20010514.tar.gz Please check Mailman/Handlers/HandlerAPI.py how to invoke them. Regards, Tokio Kikuchi From jeb@ocha.net Sun May 20 06:36:27 2001 From: jeb@ocha.net (Jeb Bateman) Date: Sat, 19 May 2001 22:36:27 -0700 Subject: [Mailman-Developers] Template file lookup In-Reply-To: <15109.27096.120852.101214@anthem.wooz.org>; from barry@digicool.com on Fri, May 18, 2001 at 02:28:40PM -0400 References: <15109.27096.120852.101214@anthem.wooz.org> Message-ID: <20010519223627.A3526@ocha.net> On Fri, May 18, 2001 at 02:28:40PM -0400, Barry A. Warsaw wrote: > ...and also provides a much requested feature, namely that you will > only need to specialize templates that you actually want to change, > and that you have multiple levels of specialization. > > Here's how it works. > > There are 4 levels of template specialization: list-centric, > vhost-centric, site-centric, and default, corresponding to the > directories > > $prefix/lists/$listname > $prefix/templates/$host_name > $prefix/templates/site > $prefix/templates This is great, I think, since I've hacked the copy of Mailman I'm using similarly to the patch on sourceforge to enable list-specific templates, (but it was a fragile fix at best without mlist being passed to the template merge function). Anyway, I'm glad to see this is being done right, although I seem to remember seeing a comment by someone recently about the 2.1 alpha Mailman assuming that every directory under $prefix/lists/$listname being a language directory for templates, which caused problems with something, and I remember thinking there might be other reasons I'd want more directories for other purposes under a list directory. So, I'd suggest moving all list templates into a 'templates' subdirectory of the list. Ie, the first search is: $prefix/lists/$listname/templates/ This would keep the list directory uncluttered, and also eliminate code ambiguity about putting other directories under the list dir. Also, one other feature I've been thinking about is to make the web interface for editing templates include a pop-up menu of all templates that affect a list, (searching up the hierarchy for each). Then, when the admin chooses to edit one, it is saved in the $listname/templates directory. Therefore, there is no need to install the current 4 list specific templates in the list templates directory to begin with, and list admins are free to modify any templates affecting their list. Hoping that made sense, -jeb -- Jeb Bateman BuyOrganic.org project - http://buyorganic.org From claw@kanga.nu Sun May 20 19:09:36 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 20 May 2001 11:09:36 -0700 Subject: [Mailman-Developers] OT -- Webmail IMAP clients Message-ID: <15489.990382176@kanga.nu> Forget who asked about this recently. At the time I recommended Twig (its what I use). I'm currently evaluating SilkyMail: http://www.cyrusoft.com/silkymail/ If you don't need the groupware features of Twig (I don't) SilkyMail makes a compelling argument. The basic user interface if quite a bit sweeter than Twig's. And yes, its GPL. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From listmgr@perilpoint.com Sun May 20 20:19:51 2001 From: listmgr@perilpoint.com (Bradford Shaw) Date: Sun, 20 May 2001 14:19:51 -0500 Subject: [Mailman-Developers] disabling feature question Message-ID: <4.2.0.58.20010520135739.00b16bd0@perilpoint.com> Hello everyone, I am new to this list. I am the Mailing List Administrator for our company. I am impressed with the quality of the Mailman program and look forward to running the program. We just installed it for our list hosting (mainly to replace Majordomo to give our customers a web-based program for their lists). I have a question that I am not able to find answers for in the archives and am hoping that you can direct me to where I can find the answer. Simply, we need to remove the "Edit the HTML for the public list pages" under the 'Other Administrative Activities' on the General Options page. Our take on this is that once we have the list set up for our customer, we don't want them messing with the html. First, because we want our logo to stay on the list pages and, second, because many of our customers are not proficient in html and a minor slip could render the output unreadable. So can you direct me to where I can get this item removed? Well, I said a couple questions but I'll hold off on the others. I need an answer to the above question right away as I am not comfortable going public with this until I can disable that feature. I appreciate your help and I hope that I can reciprocate in the near future. Best wishes, Bradford "Biff" Shaw List Administrator PerilPoint Communications Inc. http://www.perilpoint.com From barry@digicool.com Mon May 21 03:27:55 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 20 May 2001 22:27:55 -0400 Subject: [Mailman-Developers] disabling feature question References: <4.2.0.58.20010520135739.00b16bd0@perilpoint.com> Message-ID: <15112.32043.665844.64294@anthem.wooz.org> >>>>> "BS" == Bradford Shaw writes: BS> Simply, we need to remove the "Edit the HTML for the public BS> list pages" under the 'Other Administrative Activities' on the BS> General Options page. You'll need to hack the source, but it shouldn't be too hard. Assuming you're using Mailman 2.0.5, look in the Mailman/Cgi/admin.py file, 'round about line 286. See where it says: otherlinks.AddItem(Link(mlist.GetScriptURL('edithtml'), 'Edit the HTML for the public list pages')) Comment out those two lines (put `#' at the beginning of each line). For added safety, remove the $prefix/cgi-bin/edithtml binary -- where $prefix is the install directory -- and remove `edithtml' from the CGI_PROGS variable in src/Makefile.in. -Barry From claw@kanga.nu Mon May 21 04:18:22 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 20 May 2001 20:18:22 -0700 Subject: [Mailman-Developers] Trivial stats on Postfix Message-ID: <2656.990415102@kanga.nu> I just did a very quick check: 1 message delivered to a list with 1,000 members Distribution list is pretty atypical (very low AOL, MSN, Hotmail etc counts). Its a tehcnical/professional audience. The largest number of members in the distribution list all at the same domain is AOL with 27. Average number of members per domain is 2.6. MAX_RCPT_TO is set to 5. MTA is postfix with a very close to default config (no DNS check tho) Local cacheing nameserver via DJBDNS Nameserver is pre-stuffed with records for distribution list (previous list activity). Postfix spool was compleatly empty prior to run. Machine in question is a dual PII-333 with 512Meg RAM. Spool is on the same spindle as /var/log, and is under ResierFS Postfix is logging through syslog to localhost. Postfix is configured for 10 parallel deliveries to responsive MXes. Host OS is Debian/Testing. Total time required to hand off the message (200 spool entries) and deliver the spool down to the point of only slow MX'es left: 53 seconds (might be a bit faster, my stopwatch finger was lazy). Total number of spool entries left after 53 seconds: 16/16 targets Total number of spool entries after two minutes: 14/14/targets Total number of spool entries after 10 minutes: 14/14/targets Translation: Every slow spool entry has only one RCPT TO and the slow MXes really are slow. Outbound bandwith is via 100bT to a couple T3s and a T1. Relatively meaningless numbers given the artificiality of the conditions the extremely light load, and the rather unexamined distribution pattern of the membership base, but kinda interesting none the less. Surprised me too. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows From jcrey@uma.es Tue May 22 08:02:37 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Tue, 22 May 2001 09:02:37 +0200 Subject: [Mailman-Developers] Mailman install from CVS bug Message-ID: <3B0A0F0D.83AE18EF@uma.es> I have been experiencing a bug when I have tried to install mailman from CVS: When I execute './configure': [snip] creating Mailman/Queue/Makefile creating Mailman/MTA/Makefile sed: can't read ./Mailman/MTA/Makefile.in: No such file or directory creating templates/Makefile creating cron/Makefile creating filters/Makefile creating scripts/Makefile creating messages/Makefile sed: can't read ./messages/Makefile.in: No such file or directory creating cron/crontab.in creating Makefile and then when I execute 'make install' [snip] make[2]: Entering directory `/tmp/mailman/Mailman/MTA' make[2]: *** No rule to make target `install'. Stop. make[2]: Leaving directory `/tmp/mailman/Mailman/MTA' make[1]: *** [install] Error 2 make[1]: Leaving directory `/tmp/mailman/Mailman' [snip] I have noticed this for some weeks but I have not paid much attention. Has anybody experienced this too? Cheers --=20 ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From barry@digicool.com Tue May 22 20:20:11 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 22 May 2001 15:20:11 -0400 Subject: [Mailman-Developers] Mailman install from CVS bug References: <3B0A0F0D.83AE18EF@uma.es> Message-ID: <15114.48107.967199.915315@anthem.wooz.org> >>>>> "JCRA" == Juan Carlos Rey Anaya writes: JCRA> I have been experiencing a bug when I have tried to install JCRA> mailman from CVS: Be sure you do a "cvs update -P -d" to create any new directories that have shown up since your last cvs update! I just tried a fresh update, configure, and install and it works for me, modulo the following: VS> I am managing the Hungarian translation. VS> I have downloaded the current CVS and I found some problems: Cool. I've currently got Hungarian templates checked into CVS but not a message catalog. The templates may be out of date too, and I'd love to get updates for both (actually for any and all languages). VS> Creating language directory VS> /home/mailman/messages/rot/LC_MESSAGES mkdir VS> /home/mailman/messages/rot mkdir VS> /home/mailman/messages/rot/LC_MESSAGES /usr/bin/install: VS> rot/LC_MESSAGES/mailman.po: No such file or directory VS> /usr/bin/install: rot/LC_MESSAGES/mailman.mo: No such file or VS> directory make[1]: *** [doinstall] Error 1 make[1]: Leaving VS> directory `/root/mailman/messages' make: *** [doinstall] Error VS> 2 I don't get that, so the "cvs up -P -d" suggestion above should fix that. But now that we've got the start of some real languages, I think I'll delete the toy "rot" translations. VS> After the installation every 4 minutes through cron, and every VS> commandline programs get the user this message: | root@tatooin mailman]# bin/check_perms | Traceback (most recent call last): | File "bin/check_perms", line 328, in ? | checkmta() | File "bin/check_perms", line 265, in checkmta | __import__(modname) | ImportError: No module named Sendmail VS> I am using Sendmail with Mandrake 8. This is actually caused by the default value for the MTA variable in Defaults.py.in. I haven't created a Mailman/MTA/Sendmail.py module yet. I'll work on fixing that up. VS> And finally it the attachment is the notifing error message VS> for the http://servername/mailman/listinfo/ You still need to download and install mimelib 0.3 separately to use CVS. See http://sf.net/projects/mimelib for details. -Barry From neel@mediapulse.com Wed May 23 17:19:14 2001 From: neel@mediapulse.com (Michael Neel) Date: Wed, 23 May 2001 12:19:14 -0400 Subject: [Mailman-Developers] Post of white paper Message-ID: <7C0860C7F381C64DA185F431FE57C42A16AF50@JOHNSON.mediapulse.net> Hi all, I'm new to the mailman project and have email Barry briefly on some ideas I have for 3.0 mailman. I've added a white paper under MailmanThreePointOh on the zope site for your feedback. I look forward to working with you all! Mike -- Michael C. Neel Senior Programmer/Analyst Mediapulse, Inc. The Pulse of Your eBusiness Phn: 865.482.4455 x30 Fax: 4465 From jcrey@uma.es Fri May 25 12:43:48 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Fri, 25 May 2001 13:43:48 +0200 Subject: [Mailman-Developers] CVS access problem Message-ID: <3B0E4574.D5F4F7D1@uma.es> Has anybody noted anything strange accesing CVS? [jcrey@joker mailman]$ cvs -d:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman login CVS password:=20 cvs login: authorization failed: server cvs.mailman.sourceforge.net rejected access :-( --=20 ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From proski@gnu.org Fri May 25 16:40:58 2001 From: proski@gnu.org (Pavel Roskin) Date: Fri, 25 May 2001 11:40:58 -0400 (EDT) Subject: [Mailman-Developers] Feature request: regexp for posters Message-ID: Hello! I'm administering two mailing lists (mc@gnome.org and mc-devel@gnome.org) running Mailman 2.0.5. In order to stop spam, the messages from non-members are held for approval. Unfortunately, sometimes a message gets crossposted to a another list on a different site. Then we have a wave of posts from non-members. I want to accept messages from certain domains without approval. While including the mailing list domain (gnome.org) would be risky (some spammers use the victim's address in From:), other domains should be safe. I would like to be able to use regular expressions in the "poster" list, for example: .*@suse.com .*@ximian.com .*@.*mit.edu and so on. From what I see in the sources of Mailman 2.0.5, regular expressions are not used when the address is matched against the poster list. Would it be possible to use regular expressions in the future versions of Mailman? -- Regards, Pavel Roskin From barry@digicool.com Fri May 25 16:59:10 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 25 May 2001 11:59:10 -0400 Subject: [Mailman-Developers] CVS access problem References: <3B0E4574.D5F4F7D1@uma.es> Message-ID: <15118.33102.894461.107058@anthem.wooz.org> I've just logged a service request with SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=427310&group_id=1&atid=200001 but it looks like other projects are getting bit by the same bug, and it looks like it started breaking some time earlier today. -Barry From barry@digicool.com Fri May 25 17:37:53 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 25 May 2001 12:37:53 -0400 Subject: [Mailman-Developers] forwarded message from noreply@sourceforge.net Message-ID: <15118.35425.965431.437451@anthem.wooz.org> --djIzDHacbw Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Looks like it might be a while... -Barry --djIzDHacbw Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Return-Path: Delivered-To: barry@wooz.org Received: from usw-sf-netmisc.sourceforge.net (usw-sf-sshgate.sourceforge.net [216.136.171.253]) by mail.wooz.org (Postfix) with ESMTP id CD743D38E0 for ; Fri, 25 May 2001 12:26:54 -0400 (EDT) Received: from usw-sf-web1-b.sourceforge.net ([10.3.1.5] helo=usw-sf-web1.sourceforge.net) by usw-sf-netmisc.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 153KQR-0006fF-00; Fri, 25 May 2001 09:26:55 -0700 Received: from nobody by usw-sf-web1.sourceforge.net with local (Exim 3.22 #1 (Debian)) id 153KQR-0001Ga-00; Fri, 25 May 2001 09:26:55 -0700 Message-Id: From: noreply@sourceforge.net Sender: nobody To: noreply@sourceforge.net Subject: [ alexandria-Support Requests-427310 ] CVS services issue: anonymous pserver fails: mailman Date: Fri, 25 May 2001 09:26:55 -0700 Support Requests item #427310, was updated on 2001-05-25 08:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200001&aid=427310&group_id=1 Category: CVS >Group: Second Level Support Status: Open >Priority: 3 Submitted By: Barry Warsaw (bwarsaw) >Assigned to: Jacob Moorman (moorman) >Summary: CVS services issue: anonymous pserver fails: mailman Initial Comment: Anonymous cvs pserver login is broken for the mailman project: % cvs -d:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman login CVS password: cvs login: authorization failed: server cvs.mailman.sourceforge.net rejected access ---------------------------------------------------------------------- >Comment By: Jacob Moorman (moorman) Date: 2001-05-25 09:26 Message: Logged In: YES user_id=152443 Greetings, At this time, I am unable to process your request due to the pending maintenance event related to SourceForge systems (as mentioned on the site status page). Once this maintenance event has been completed, your support request will be processed in the following 48-72 hours. Please let me know if I may be of further assistance in this matter. Thank you, Jacob Moorman Quality of Service Manager, SourceForge ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200001&aid=427310&group_id=1 --djIzDHacbw-- From chuqui@plaidworks.com Fri May 25 18:18:16 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 25 May 2001 10:18:16 -0700 Subject: [Mailman-Developers] site-wide list configuration... Message-ID: <200105251716.f4PHGaq17092@lists.apple.com> Just as a bit of an FYI -- I've mentioned in the past that I'd like the ability to "lock down" certain list configuration options based on site-wide standard. Having this feature has become more interesting to me, since I just has a 'situation' where it would have been really useful. I had a list admin decide he wanted to change reply-to to the list. This, despite being told not to change things. So he did. And it got involved in a situation where stuff was posted to the list (by me, in fact) that shouldn't have been because the list was configured different than everything else on the system. And that led to the "why can't we have this?" fight, and it led to a private argument with the list admin (who actually changed it twice), and all sorts of unhappiness. And one of his arguments, of course, was "if you don't want this changed, why do the pages let me"? Don't worry, my hair will grow back. Well, maybe. But take this as a real-world case where splitting out content admin from list admin from site admin and allowing the folks higher up in the hierarchy to delegate or freeze what sub-admins can do. Because while it's nice to think everyone will play nice and follow instructions, in the real world, it doesn't always happen. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. It's a thankless job, but I've got a lot of Karma to burn off. From kevinc@seaplace.org Sat May 26 19:27:33 2001 From: kevinc@seaplace.org (Kevin N. Carpenter) Date: Sat, 26 May 2001 13:27:33 -0500 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 In-Reply-To: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: Barry - I just got lost trying to find the patches. Is there a nice, straight-forward, FTP site I can pull patch 1-5 from? Thanks, Kevin C. -----Original Message----- From: mailman-announce-admin@python.org [mailto:mailman-announce-admin@python.org]On Behalf Of Barry A. Warsaw Sent: Monday, May 07, 2001 11:24 AM To: mailman-announce@python.org Cc: mailman-developers@python.org Subject: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 Folks, I've just released Mailman 2.0.5 which fixes a problem with stale lock files that can occur under certain situations when the user hits the `Stop' button on their browser. These stale lock files can cause mailing lists to be inaccessible for long periods of time (until the stale lock file times out or is manually removed). As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.4. You /must/ update your source to 2.0.4 before applying the 2.0.5 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.5 source tree and apply it like so: % patch -p0 < mailman-2.0.4-2.0.5.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net My thanks to those of you who gave the 2.0.5 pre-release a try! Enjoy, -Barry Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.5 retrieving revision 1.25.2.6 diff -u -r1.25.2.5 -r1.25.2.6 --- NEWS 2001/04/18 10:45:54 1.25.2.5 +++ NEWS 2001/05/03 21:06:56 1.25.2.6 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.5 (04-May-2001) + + Fix a lock stagnation problem that can result when the user hits + the `stop' button on their browser during a write operation that + can take a long time (e.g. hitting the membership management admin + page). + 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.4 retrieving revision 1.20.2.5 diff -u -r1.20.2.4 -r1.20.2.5 --- Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 +++ Mailman/Version.py 2001/05/03 20:58:19 1.20.2.5 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.4" +VERSION = "2.0.5" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 4 +MICRO_REV = 5 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Cgi/admin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admin.py,v retrieving revision 1.82.2.2 retrieving revision 1.82.2.3 diff -u -r1.82.2.2 -r1.82.2.3 --- Mailman/Cgi/admin.py 2001/01/03 16:47:47 1.82.2.2 +++ Mailman/Cgi/admin.py 2001/05/03 21:03:48 1.82.2.3 @@ -18,11 +18,13 @@ """ +import sys import os import cgi import string import types import rfc822 +import signal from Mailman import Utils from Mailman import MailList @@ -63,53 +65,86 @@ # get the list object listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: FormatAdminOverview('No such list %s' % listname) syslog('error', 'Someone tried to access the admin interface for a ' 'non-existent list: %s' % listname) return + + if len(parts) == 1: + category = 'general' + category_suffix = '' + else: + category = parts[1] + category_suffix = category + + # If the user is not authenticated, we're done. + cgidata = cgi.FieldStorage(keep_blank_values=1) try: - if len(parts) == 1: - category = 'general' - category_suffix = '' - else: - category = parts[1] - category_suffix = category - - # If the user is not authenticated, we're done. - cgidata = cgi.FieldStorage(keep_blank_values=1) - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admin', e.message) - return - - # Is this a log-out request? - if category == 'logout': - print mlist.ZapCookie('admin') - Auth.loginpage(mlist, 'admin', frontpage=1) - return - - if category not in map(lambda x: x[0], CATEGORIES): - category = 'general' - - # is the request for variable details? - varhelp = None - if cgidata.has_key('VARHELP'): - varhelp = cgidata['VARHELP'].value - elif cgidata.has_key('request_login') and \ - os.environ.get('QUERY_STRING'): - # POST methods, even if their actions have a query string, don't - # get put into FieldStorage's keys :-( - qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') - if qs and type(qs) == types.ListType: - varhelp = qs[0] - if varhelp: - FormatOptionHelp(doc, varhelp, mlist) - print doc.Format(bgcolor="#ffffff") - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admin', e.message) + return + + # Is this a log-out request? + if category == 'logout': + print mlist.ZapCookie('admin') + Auth.loginpage(mlist, 'admin', frontpage=1) + return + + if category not in map(lambda x: x[0], CATEGORIES): + category = 'general' + # is the request for variable details? + varhelp = None + if cgidata.has_key('VARHELP'): + varhelp = cgidata['VARHELP'].value + elif cgidata.has_key('request_login') and \ + os.environ.get('QUERY_STRING'): + # POST methods, even if their actions have a query string, don't + # get put into FieldStorage's keys :-( + qs = cgi.parse_qs(os.environ['QUERY_STRING']).get('VARHELP') + if qs and type(qs) == types.ListType: + varhelp = qs[0] + if varhelp: + FormatOptionHelp(doc, varhelp, mlist) + print doc.Format(bgcolor="#ffffff") + return + + # From this point on, the MailList object must be locked. However, we + # must release the lock no matter how we exit. try/finally isn't + # enough, because of this scenario: user hits the admin page which may + # take a long time to render; user gets bored and hits the browser's + # STOP button; browser shuts down socket; server tries to write to + # broken socket and gets a SIGPIPE. Under Apache 1.3/mod_cgi, Apache + # catches this SIGPIPE (I presume it is buffering output from the cgi + # script), then turns around and SIGTERMs the cgi process. Apache + # waits three seconds and then SIGKILLs the cgi process. We /must/ + # catch the SIGTERM and do the most reasonable thing we can in as + # short a time period as possible. If we get the SIGKILL we're + # screwed (because its uncatchable and we'll have no opportunity to + # clean up after ourselves). + # + # This signal handler catches the SIGTERM and unlocks the list. The + # effect of this is that the changes made to the MailList object will + # be aborted, which seems like the only sensible semantics. + # + # BAW: This may not be portable to other web servers or cgi execution + # models. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + if cgidata.has_key('bounce_matching_headers'): pairs = mlist.parse_matching_header_opt() @@ -135,8 +170,12 @@ FormatConfiguration(doc, mlist, category, category_suffix, cgidata) print doc.Format(bgcolor="#ffffff") - finally: mlist.Save() + finally: + # Now be sure to unlock the list. It's okay if we get a signal here + # because essentially, the signal handler will do the same thing. And + # unlocking is unconditional, so it's not an error if we unlock while + # we're already unlocked. mlist.Unlock() Index: Mailman/Cgi/admindb.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.36.2.1 retrieving revision 1.36.2.4 diff -u -r1.36.2.1 -r1.36.2.4 --- Mailman/Cgi/admindb.py 2001/03/03 06:02:01 1.36.2.1 +++ Mailman/Cgi/admindb.py 2001/05/04 15:54:23 1.36.2.4 @@ -16,10 +16,12 @@ """Produce and process the pending-approval items for a list.""" +import sys import os import string import types import cgi +import signal from errno import ENOENT from Mailman import mm_cfg @@ -62,7 +64,7 @@ return # now that we have the list name, create the list object try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: handle_no_list(doc, 'No such list %s

                      ' % listname) syslog('error', 'No such list "%s": %s\n' % (listname, e)) @@ -71,14 +73,34 @@ # now we must authorize the user to view this page, and if they are, to # handle both the printing of the current outstanding requests, and the # selected actions + cgidata = cgi.FieldStorage() try: - cgidata = cgi.FieldStorage() - try: - Auth.authenticate(mlist, cgidata) - except Auth.NotLoggedInError, e: - Auth.loginpage(mlist, 'admindb', e.message) - return + Auth.authenticate(mlist, cgidata) + except Auth.NotLoggedInError, e: + Auth.loginpage(mlist, 'admindb', e.message) + return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + mlist.Lock() + try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + # If this is a form submission, then we'll process the requests and # print the results. otherwise (there are no keys in the form), we'll # print out the list of pending requests @@ -91,8 +113,8 @@ PrintRequests(mlist, doc) text = doc.Format(bgcolor="#ffffff") print text - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/handle_opts.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/handle_opts.py,v retrieving revision 1.30 retrieving revision 1.30.2.2 diff -u -r1.30 -r1.30.2.2 --- Mailman/Cgi/handle_opts.py 2000/11/09 16:19:03 1.30 +++ Mailman/Cgi/handle_opts.py 2001/05/03 21:05:06 1.30.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import mm_cfg from Mailman import Utils @@ -61,7 +62,7 @@ user = parts[1] try: - mlist = MailList.MailList(listname) + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) @@ -69,10 +70,30 @@ syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, user, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: Mailman/Cgi/subscribe.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Cgi/subscribe.py,v retrieving revision 1.29 retrieving revision 1.29.2.1 diff -u -r1.29 -r1.29.2.1 --- Mailman/Cgi/subscribe.py 2000/09/29 00:05:05 1.29 +++ Mailman/Cgi/subscribe.py 2001/05/03 21:05:43 1.29.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -20,6 +20,7 @@ import os import string import cgi +import signal from Mailman import Utils from Mailman import MailList @@ -41,18 +42,38 @@ listname = string.lower(parts[0]) try: - mlist = MailList.MailList(listname) - mlist.IsListInitialized() + mlist = MailList.MailList(listname, lock=0) except Errors.MMListError, e: doc.AddItem(Header(2, "Error")) doc.AddItem(Bold('No such list %s' % listname)) print doc.Format(bgcolor="#ffffff") syslog('error', 'No such list "%s": %s\n' % (listname, e)) return + + # We need a signal handler to catch the SIGTERM that can come from Apache + # when the user hits the browser's STOP button. See the comment in + # admin.py for details. + # + # BAW: Strictly speaking, the list should not need to be locked just to + # read the request database. However the request database asserts that + # the list is locked in order to load it and it's not worth complicating + # that logic. + def sigterm_handler(signum, frame, mlist=mlist): + # Make sure the list gets unlocked... + mlist.Unlock() + # ...and ensure we exit, otherwise race conditions could cause us to + # enter MailList.Save() while we're in the unlocked state, and that + # could be bad! + sys.exit(0) + + mlist.Lock() try: + # Install the emergency shutdown signal handler + signal.signal(signal.SIGTERM, sigterm_handler) + process_form(mlist, doc) - finally: mlist.Save() + finally: mlist.Unlock() Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.5 retrieving revision 1.5.2.6 diff -u -r1.5.2.5 -r1.5.2.6 --- admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 +++ admin/www/download.ht 2001/05/03 21:09:36 1.5.2.6 @@ -65,9 +65,9 @@

                      Downloading

                      Version -(2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:

                        Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.7 retrieving revision 1.6.2.8 diff -u -r1.6.2.7 -r1.6.2.8 --- admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 +++ admin/www/download.html 2001/05/03 21:09:36 1.6.2.8 @@ -1,6 +1,6 @@ - + 2.0.4, +(2.0.5, released on -Apr 18 2001) +May 4 2001) is the current GNU release. It is available from the following mirror sites:
                          _______________________________________________ Mailman-announce mailing list Mailman-announce@python.org http://mail.python.org/mailman/listinfo/mailman-announce From barry@digicool.com Sat May 26 23:09:02 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sat, 26 May 2001 18:09:02 -0400 Subject: [Mailman-Developers] RE: [Mailman-Announce] ANNOUNCE Mailman 2.0.5 References: <15094.52272.753043.181192@anthem.wooz.org> Message-ID: <15120.10622.799984.961066@anthem.wooz.org> >>>>> "KNC" == Kevin N Carpenter writes: KNC> I just got lost trying to find the patches. Is there a nice, KNC> straight-forward, FTP site I can pull patch 1-5 from? SourceForge should have them, but you can also try ftp.gnu.org, probably in the gnu/mailman subdirectory. -Barry From a.nestico@sonetlumiere.it Tue May 29 19:47:48 2001 From: a.nestico@sonetlumiere.it (Angela) Date: Tue, 29 May 2001 11:47:48 -0700 Subject: [Mailman-Developers] cookie Message-ID: <000801c0e86f$dbe425f0$7a08090a@WINANGELA> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0E835.2F0FA8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want create an application where a user called a cookie, someone know = where I can find more information how to create a cookie Thank you Angela Nestic=F2 ------=_NextPart_000_0005_01C0E835.2F0FA8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
                          I want create an application where a = user called a=20 cookie, someone know where I can find more information how to create a=20 cookie
                          Thank you Angela = Nestic=F2
                          ------=_NextPart_000_0005_01C0E835.2F0FA8C0-- From thomas@xs4all.net Tue May 29 13:45:07 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 29 May 2001 14:45:07 +0200 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 In-Reply-To: ; from twouters@users.sourceforge.net on Tue, May 29, 2001 at 05:06:49AM -0700 References: Message-ID: <20010529144507.T690@xs4all.nl> On Tue, May 29, 2001 at 05:06:49AM -0700, Thomas Wouters wrote: > Re-BSDify the Makefiles, by not expecting make to expand '{eggs,ham}' in > globs. (BSD 'make' does not, GNU make does.) I'm sure there is a more > satisfying way to do this, but in this case, with only two alternatives in > only two cases, just writing them out was the way of least resistance. Ugh. I now see that there are a lot more things BSD make barfs over: GNU make: mailman/messages$ gmake es/LC_MESSAGES/mailman.mo [ pygettext and other stuff snipped ] Generating binary catalog msgfmt -o es/LC_MESSAGES/mailman.mo es/LC_MESSAGES/mailman.po BSD make: mailman/messages$ make es/LC_MESSAGES/mailman.mo msgfmt -o es/LC_MESSAGES/mailman.po es/LC_MESSAGES/mailman.mo es/LC_MESSAGES/mailman.mo:1: parse error es/LC_MESSAGES/mailman.mo:2: keyword "e" unknown es/LC_MESSAGES/mailman.mo:4: keyword "W" unknown Apparently, GNU make and BSD make switch the meaning of $@ and $< in: msgfmt -o $@ $< And there's more, there, too. As usual for Makefile/make bugs, they're hard to reproduce, depending as they are on the timestamps of seemingly totally irrelevant files :) I think it's safe to say that BSD make doesn't grok the '%/LC_MESSAGES/*' construct, though. I don't have a good GNU/BSD make resource at hand to help me through the differences; if anyone sees such a resource online, please let me know ;) In the mean time, Barry, if this isn't fixed before an almost-real release, we'll either have to ship .po files, or insist on GNU make (which is available almost everywhere, even on BSD systems, though usually as 'gmake' there.) The installation procedure works with BSD make now that I regenerated the .po files with GNU make. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jarrell@vt.edu Tue May 29 19:24:15 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 29 May 2001 14:24:15 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 In-Reply-To: <20010529144507.T690@xs4all.nl> References: Message-ID: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> At 02:45 PM 5/29/01 +0200, Thomas wrote: >resource at hand to help me through the differences; if anyone sees such a >resource online, please let me know ;) In the mean time, Barry, if this >isn't fixed before an almost-real release, we'll either have to ship .po >files, or insist on GNU make (which is available almost everywhere, even on >BSD systems, though usually as 'gmake' there.) The installation procedure >works with BSD make now that I regenerated the .po files with GNU make. Unless it's absolutely impossible to do otherwise, I always recommend going with the least common denominator make. Each extra piece you require before someone can run mailman reduces the number of people willing to bother. And I think the "Whatinhell? It can't run with a normal make?" effect would be the proverbial straw for a large crowd. Ship it with pregenerated files. Include a warning that if you fiddle with the generated files, you'll probably need to install a bunch of tools, or they won't regenerate right. Included in the tools would be a make compatible with the gmake extensions. It's similar to including your autoconf and bison source files, and the generated configure and .c files, and warning people that if they want to customize, the'll need autoconf and/or bison... From barry@digicool.com Tue May 29 19:48:29 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 29 May 2001 14:48:29 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> Message-ID: <15123.61181.924613.914185@anthem.wooz.org> I had some mail outages over the weekend so I didn't see the original message in this thread (I may still get it). Checking the archive though, it appears that there are complaints about GNU-make-isms in the message/Makefile{,.in}. My intent is to indeed check in all the generated files, so that normally no one would ever have to run "make catalogs". My intention is that I would run those when the mailman.pot file needed updating, or when I got new translations and wanted to update the various language .po files. So, I'm not concerned about GNU-make-isms for "make catalogs". That's why "make all" and "make install" don't depend on any of the generated files. I should probably add a comment to the top of messages/Makefile.in just saying that "make catalogs" requires GNU make. -Barry From barry@digicool.com Tue May 29 19:54:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 29 May 2001 14:54:35 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> <15123.61181.924613.914185@anthem.wooz.org> Message-ID: <15123.61547.734290.731443@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> So, I'm not concerned about GNU-make-isms for "make BAW> catalogs". That's why "make all" and "make install" don't BAW> depend on any of the generated files. I should probably add BAW> a comment to the top of messages/Makefile.in just saying that BAW> "make catalogs" requires GNU make. Oh, yeah. I see there was a redundant definition of the .po->.mo file transformation. I'll bet BSDmake was picking up the broken .po.mo entry and GNUmake was picking up the full rule down below. I'll check in a fix for this shortly. -Barry From thomas@xs4all.net Tue May 29 23:00:34 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 30 May 2001 00:00:34 +0200 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 In-Reply-To: <15123.61547.734290.731443@anthem.wooz.org>; from barry@digicool.com on Tue, May 29, 2001 at 02:54:35PM -0400 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> <15123.61181.924613.914185@anthem.wooz.org> <15123.61547.734290.731443@anthem.wooz.org> Message-ID: <20010530000034.W690@xs4all.nl> On Tue, May 29, 2001 at 02:54:35PM -0400, Barry A. Warsaw wrote: > I see there was a redundant definition of the .po->.mo file > transformation. I'll bet BSDmake was picking up the broken .po.mo > entry and GNUmake was picking up the full rule down below. That's exactly what happened. I couldn't believe my eyes when I saw BSD make and GNU make attach the exact opposite meaning to $@ and $<, but I didn't think to search for redundant definitions ! I think $< is still a GNU-makeism, but I can live with requiring GNU make for building catalogs just fine. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@digicool.com Tue May 29 23:03:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 29 May 2001 18:03:30 -0400 Subject: [Mailman-Developers] Re: [Mailman-checkins] CVS: mailman/messages Makefile.in,2.1,2.2 References: <5.1.0.14.2.20010529142025.03b484e0@lennier.cc.vt.edu> <15123.61181.924613.914185@anthem.wooz.org> <15123.61547.734290.731443@anthem.wooz.org> <20010530000034.W690@xs4all.nl> Message-ID: <15124.7346.40630.157111@anthem.wooz.org> >>>>> "TW" == Thomas Wouters writes: TW> That's exactly what happened. I couldn't believe my eyes when TW> I saw BSD make and GNU make attach the exact opposite meaning TW> to $@ and $<, but I didn't think to search for redundant TW> definitions ! I think $< is still a GNU-makeism, but I can TW> live with requiring GNU make for building catalogs just fine. Yeah, I said to myself "no way" when I read that. It would be INSANE to swap those meanings. Then when I was cleaning up the file, I had a Homer Moment (read: "doh!" :) -Barry From Swee Heng Wed May 30 12:56:40 2001 From: Swee Heng (Swee Heng) Date: Wed, 30 May 2001 19:56:40 +0800 (SGT) Subject: [Mailman-Developers] subscriber profiler patch for mailman-2.0.5 Message-ID: hi folks, i've written a patch to mailman-2.0.5 that lets it handle subscribers' profiles. (is this the "member profiles" feature on the wishlist?) the patch is available at: http://www.srikant.org/~sh/src/mmprofiler/mm-2.0.5-prof-0.7.gz a screenshot of it in action is at: http://www.srikant.org/~sh/src/mmprofiler/screenshot.jpg this is my first serious attempt at python. so please be warned. :) feel free to comment. swee heng ====================================================================== Brief Documentation ^^^^^^^^^^^^^^^^^^^ how to install it: ^^^^^^^^^^^^^^^^^^ 1. "patch -p0 <" the patch to mailman-2.0.5 2. do the usual "./configure; make; make install" this will create Mailman/Cgi/profile.py, cgi-bin/profile and three templates files (prof_login.html, prof_list.html, prof_user.html) in templates/. it will also modify Mailman/Cgi/edithtml.py so that list admins can change the look of the templates. how to use it: ^^^^^^^^^^^^^^ for currently existing lists, you need to copy the template files: cp templates/prof_* lists/the-existing-list/ for new lists, nothing needs to be done. finally, visit the URL: http://your.domain/mailman/profile/view/name-of-list notes: ^^^^^^ 1. profile information is made available to list members and admins when private_roster == 0 or 1. it is made available only to list admins when private_roster == 2. profile information is not available otherwise. 2. the database is really just a collection of pickles, one for each subscriber, stored in lists/name-of-list/profiles/. 3. i've used a whole slew of replacement MM tags, but they all look like or . they won't pollute other tags. From barry@digicool.com Thu May 31 06:51:42 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 31 May 2001 01:51:42 -0400 Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or less...) References: Message-ID: <15125.56302.501876.382172@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> I finally found a tool that takes care of this for me -- it's CVR> called mod_layout (www.tangent.org), and it's an apache CVR> module, so this is apache specific. Very cool indeed. Although I haven't had time to play with it, it seems like a low-cost approach that gets you 90% of the way there. CVR> This gives me control over almost all of Mailman (and, hint CVR> hint) -- hopefully Barry will add the configuration for the CVR> rest down the road. CVR> One is that some of the text-box colors are hard-coded (see, CVR> for instance, /mailman/admin/listname/general/. It'd be nice CVR> (and it seems to be easy to do) to turn those into globals CVR> that can be set in mm_cfg.py instead of requiring someone to CVR> whack all of the source files they're sprinkled in. I've completely rewritten the user options page (more on this later, tomorrow is checkin day :), and have taken the opportunity to do exactly this. I may have missed some, but the idea is that the colors are now overridable in mm_cfg.py. Which makes me think more about having a better support for virtual domains by having something akin to a different mm_cfg.py per domain. That's rumbling around in the back of my head. CVR> The other key one for me are some of the admin messages CVR> (Mailman/Handlers/Hold.py). I've modified some of the CVR> messages for various reasons, and it'd be nice if I could CVR> simply override their definitions in the mm_cfg.py file I'll have to think about this. One hackish idea (untested) is to try to import Mailman.Hold from mm_cfg.py, and then set the class's __doc__ attribute with the message you want. The fact that Mailman/Hold.py imports mm_cfg.py means you might have to play games with the importer to get this to work. Not a great solution, but it might help localize your customizations for now. CVR> And the third place I've made custom changes are in some of CVR> the list templates (most radically templates/listinfo.html) CVR> -- but that's why they're template; you simply keep a copy CVR> somewhere and watch out for additions to the updated copy... Exactly, and the new template lookup scheme should be much more friendly to this approach. CVR> It took me about three days and a couple of exchanges with CVR> the author of mod_layout to get it going the way I wanted CVR> (the documentation is still being fleshed out), but it's a CVR> nice improvement to the old way of doing things -- and since CVR> I know others build custom skins around their installations, CVR> I'd thought I'd pass this one along. Yes, thanks! -Barry From chuqui@plaidworks.com Thu May 31 07:02:53 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 30 May 2001 23:02:53 -0700 Subject: [Mailman-Developers] Skinning Mailman (how to add a customer UI in five minutes or less...) In-Reply-To: <15125.56302.501876.382172@anthem.wooz.org> Message-ID: <200105310554.f4V5smh04253@plaidworks.com> On Wednesday, May 30, 2001, at 10:51 PM, Barry A. Warsaw wrote: > CVR> The other key one for me are some of the admin messages > CVR> (Mailman/Handlers/Hold.py). I've modified some of the > CVR> messages for various reasons, and it'd be nice if I could > CVR> simply override their definitions in the mm_cfg.py file > > I'll have to think about this. One hackish idea (untested) is to try > to import Mailman.Hold from mm_cfg.py, and then set the class's > __doc__ attribute with the message you want. I think a more general solution is to rethink the admin messages, and make them part of the site and list databases. You would have 0 ... n definitions, each of the form: regex action message lockflag where the latter is in the site database only. actions would include HOLD, DISCARD, REJECT and whatever else people would find useful. you could then define this as a set of python regexes (with, I think, a few procmail-esque extensions, so you could define whether to look in header, body or both, and in the body, optionally the first N lines...), and do something with it, and a message including python ''' multiline format. The lockflag is so the site admin can, if they choose, keep list admins from over-riding definitions. So for each message, you'd check the site-wide LOCKed lines, then the list definitions, then the site-wide definitions, and stop on the first match. that way, you stop having to migrate global definitions to each list, and have to worry about updating them on updates... And make them definable, editable and viewable from the web interface so the list admins and site admin can tweak them. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I like you. You remind me of when I was young and stupid. From chuqui@plaidworks.com Thu May 31 08:23:53 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 31 May 2001 00:23:53 -0700 Subject: [Mailman-Developers] minor qrunner bug. Message-ID: <200105310715.f4V7Fmh05534@plaidworks.com> Just noticed a minor bug in qrunner. when qrunner starts up, it opens the log files, and leaves them open. this is fine -- except when the logs get rolled and restarted. When you move the logs off and gzip them for storage, qrunner continues writing to the (now unlinked) old files, not the new, zeroed ones. So all of the qrunner stat and errror and whatever data from the time you roll the logs until that instance of qrunner exits is gone (which, if you've modified qrunner lifetime values, can become significant on a busy system) Since mailman isn't oding much log processing, not a big deal. but for sites that are (for instance) charging for list usage, or sites that have implemented reporting, there are potential holes in the data, and if they're busy so they have extended qrunner times, significant holes. while open/write/close is expensive, given all of the other stuff qrunner's doing and the relative lack of logging, I don't think it's significant. Alternatively, it can notice the files have been moved/zeroed, or perhaps accept a HUP like syslog... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I'm out of my mind, but feel free to leave a message... From jon@latchkey.com Thu May 31 18:35:59 2001 From: jon@latchkey.com (Jon Stevens) Date: Thu, 31 May 2001 10:35:59 -0700 Subject: [Mailman-Developers] minor qrunner bug. In-Reply-To: <200105310715.f4V7Fmh05534@plaidworks.com> Message-ID: on 5/31/01 12:23 AM, "Chuq Von Rospach" wrote: > > Just noticed a minor bug in qrunner. when qrunner starts up, it opens > the log files, and leaves them open. > > this is fine -- except when the logs get rolled and restarted. When you > move the logs off and gzip them for storage, qrunner continues writing > to the (now unlinked) old files, not the new, zeroed ones. So all of the > qrunner stat and errror and whatever data from the time you roll the > logs until that instance of qrunner exits is gone (which, if you've > modified qrunner lifetime values, can become significant on a busy > system) > > Since mailman isn't oding much log processing, not a big deal. but for > sites that are (for instance) charging for list usage, or sites that > have implemented reporting, there are potential holes in the data, and > if they're busy so they have extended qrunner times, significant holes. > > while open/write/close is expensive, given all of the other stuff > qrunner's doing and the relative lack of logging, I don't think it's > significant. Alternatively, it can notice the files have been > moved/zeroed, or perhaps accept a HUP like syslog... The files should remain open... Because, exactly as you suggest, there is a sever penalty for open/write/close. The way that Apache HTTPd works (as well as many other daemons) is that you move the log files out of the way and then you HUP Apache which will re-create the log files. Accepting HUP's (or a graceful restart) is functionality that should be added to qrunner if it isn't there already. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous From wilane@MINT.SN Thu May 31 20:21:59 2001 From: wilane@MINT.SN (Ousmane Wilane) Date: Thu, 31 May 2001 19:21:59 +0000 (GMT) Subject: [Mailman-Developers] FR catalog! Message-ID: Hi, A french catalog is available at http://mint.sn/Mailman/mailman.po.gz. We have also made available a test setup (2.1a2) with a Mailman-fr list supporting es, fr. Japanese will be added in no time. Thanks in advance for helps correcting the translations. Cheers. -- -- Ousmane Wilane -- "The best laid plans sometimes go awry..."