From somuchfun at atlantismail.com Thu Jul 1 12:46:47 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Thu Jul 1 12:47:10 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: <7012.1088637511@kanga.nu> Message-ID: J.C., I agree with you that there is never a right time. BUT, when introducing a new feature (like mailman did with the VERP bounce probes) it is wise to have the option to turn this feature off (perhaps until 2.1.6 comes out) to give people time to adjust their settings and systems. ---------------------------------------- MANA TANGATA > -----Original Message----- > From: J C Lawrence [mailto:claw@kanga.nu] > Sent: Wednesday, June 30, 2004 4:19 PM > To: Somuchfun > Cc: 'Brad Knowles'; mailman-developers@python.org > Subject: Re: [Mailman-Developers] [Greg Stark > ] Re: Bounceremoval parameters default values > > On Wed, 30 Jun 2004 09:04:14 -0700 > somuchfun wrote: > > > The issue is not whether it was obvious or not, the issue > is that this > > new feature cannot even be turned off, just changed to a different > > format. Since there are many configurations out there that > might not > > work with VERP I find introducing a feature that is on by > default and > > that cannot be turned off causing more harm than doing good. > > Without disagreeing with your point: > > At some point Mailman ends up in the position of pushing technical > standard adoption (such as the RFC 2369 List-* headers). No matter > when the adoption decision is made someone will be unhappy. > > Plus addressing is not even close to new. I'm aware of no > production > MTAs that don't support plus-addressing. At what point > should Mailman > simply assume technical capability on the part of > installation sites? > Mailman already currently assumes a number of non-default > things about > the execution space, why not plus-addressing as well? > > When is the right time? > > Remember: You don't have to upgrade. > > -- > J C Lawrence > ---------(*) Satan, oscillate my metallic sonatas. > claw@kanga.nu He lived as a devil, eh? > http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. > From claw at kanga.nu Thu Jul 1 12:57:03 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jul 1 12:57:07 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: Message from "Somuchfun" of "Thu, 01 Jul 2004 09:46:47 PDT." Message-ID: <25785.1088701023@kanga.nu> On Thu, 1 Jul 2004 09:46:47 -0700 somuchfun wrote: > J.C., I agree with you that there is never a right time. BUT, when > introducing a new feature (like mailman did with the VERP bounce > probes) it is wise to have the option to turn this feature off > (perhaps until 2.1.6 comes out) to give people time to adjust their > settings and systems. They can of course always gain that same time and more by simply not upgrading. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From brad.knowles at skynet.be Thu Jul 1 15:04:53 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jul 1 15:31:07 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] pl translation fix In-Reply-To: References: Message-ID: At 12:08 PM +0200 2004-07-01, Pawe? Go?aszewski wrote: > This is small pl translation fix. Without that message from moderator was > ugly and causes line break in some MUA. See and the language champions for Polish. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From jwblist at olympus.net Thu Jul 1 20:48:21 2004 From: jwblist at olympus.net (John W. Baxter) Date: Thu Jul 1 20:48:48 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: <25785.1088701023@kanga.nu> Message-ID: On 7/1/2004 9:57, "J C Lawrence" wrote: > On Thu, 1 Jul 2004 09:46:47 -0700 > somuchfun wrote: > >> J.C., I agree with you that there is never a right time. BUT, when >> introducing a new feature (like mailman did with the VERP bounce >> probes) it is wise to have the option to turn this feature off >> (perhaps until 2.1.6 comes out) to give people time to adjust their >> settings and systems. > > They can of course always gain that same time and more by simply not > upgrading. Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 announcement: > This version also contains a fix > for an exploit that could allow 3rd parties to retrieve member > passwords. It is thus highly recommended that all existing sites > upgrade to the latest version. --John From claw at kanga.nu Thu Jul 1 20:57:38 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jul 1 20:59:02 2004 Subject: [Mailman-Developers] [Greg Stark ] Re: Bounceremoval parameters default values In-Reply-To: Message from "John W. Baxter" of "Thu, 01 Jul 2004 17:48:21 PDT." References: Message-ID: <32708.1088729858@kanga.nu> On Thu, 01 Jul 2004 17:48:21 -0700 John W Baxter wrote: > On 7/1/2004 9:57, "J C Lawrence" wrote: >> They can of course always gain that same time and more by simply not >> upgrading. > Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 > announcement: > This version also contains a fix for an exploit that could allow 3rd > parties to retrieve member passwords. It is thus highly recommended > that all existing sites upgrade to the latest version. Yup, of such hard choices are upgrades made. Of course Mailman passwords are also not the most significant things in the computing universe. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jwt at OnJapan.net Fri Jul 2 04:51:52 2004 From: jwt at OnJapan.net (Jim Tittsler) Date: Fri Jul 2 04:51:25 2004 Subject: [Mailman-Developers] Jira text field In-Reply-To: References: Message-ID: <20040702085152.GB5840@server.onjapan.net> On Mon, Jun 28, 2004 at 02:55:03PM -0700, Bev Scott wrote: > Does anyone know how to make a text field in mailman read only > or how to just display the information in the field. If you want the change to apply to all of the lists in a given instance of Mailman, the easiest way would be to modify the appropriate (depending upon which field you want to be "read only") routine in Mailman/Cgi/*.py so that it ignores any value submitted for that field. -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/ Ringo MUG Tokyo http://www.ringo.net/rss.html From somuchfun at atlantismail.com Fri Jul 2 13:21:26 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Fri Jul 2 13:21:54 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: <32708.1088729858@kanga.nu> Message-ID: This is not the point here, J.C. The important point is the fact that mailman did introduce a new way of handling bounces without a way to opt-out of this new way. Normally every software package that introduces a new way of doing a certain task (opposed to a complete new functionality) there is an option to opt-out and continue "the old way" until all proper changes have been done. Take cPanel for example, they have still not gotten around to make the proper adjustments to their highly complex environment and they are used hundreds of thousands of times around the world by web hosting companies. Right now people are unsubscribed because of this all over the place for no apparent reason (from the view of the user). The only way to not end up in trouble in this environment is to turn off bounce handling completely in mailman 2.1.5 So looking at this, do you still think it was wise to introduce VERP bounce probes by default and by force with no choice? ---------------------------------------- MANA TANGATA > -----Original Message----- > From: J C Lawrence [mailto:claw@kanga.nu] > Sent: Thursday, July 01, 2004 5:58 PM > To: John W. Baxter > Cc: mailman-developers@python.org > Subject: Re: [Mailman-Developers] [Greg Stark > ] Re:Bounceremoval parameters default values > > On Thu, 01 Jul 2004 17:48:21 -0700 > John W Baxter wrote: > > On 7/1/2004 9:57, "J C Lawrence" wrote: > > >> They can of course always gain that same time and more by > simply not > >> upgrading. > > > Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 > > announcement: > > > This version also contains a fix for an exploit that > could allow 3rd > > parties to retrieve member passwords. It is thus highly > recommended > > that all existing sites upgrade to the latest version. > > Yup, of such hard choices are upgrades made. > > Of course Mailman passwords are also not the most significant > things in > the computing universe. > > -- > J C Lawrence > ---------(*) Satan, oscillate my metallic sonatas. > claw@kanga.nu He lived as a devil, eh? > http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/somu > chfun%40atlantismail.com > From brad.knowles at skynet.be Fri Jul 2 13:41:13 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Jul 2 14:08:16 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: <200407021723.i62HNh31030927@inmx008.isp.belgacom.be> References: <200407021723.i62HNh31030927@inmx008.isp.belgacom.be> Message-ID: At 10:21 AM -0700 2004-07-02, Somuchfun wrote: > This is not the point here, J.C. > The important point is the fact that mailman did introduce a new way of > handling bounces without a way to opt-out of this new way. Sure. Just don't upgrade. > Normally every > software package that introduces a new way of doing a certain task (opposed > to a complete new functionality) there is an option to opt-out and continue > "the old way" until all proper changes have been done. Certainly not every package does this. Some do, some don't. If you want to run the latest version of many packages, you might have to upgrade your OS and/or hardware to do that. Even if they aren't issuing patches/fixes for the old version, you have to decide if it's worthwhile to upgrade those other things, in order to get the thing you want. This is called "life". > Take cPanel for example, they have still not gotten around to make the > proper adjustments to their highly complex environment and they are used > hundreds of thousands of times around the world by web hosting companies. > Right now people are unsubscribed because of this all over the place for no > apparent reason (from the view of the user). The only way to not end up in > trouble in this environment is to turn off bounce handling completely in > mailman 2.1.5 Anyone using CPanel with Mailman needs to get their support from CPanel. If they installed a new version of Mailman without getting that from the CPanel folks, and getting it suitably modified to fit their method of working, then they've shot themselves in the foot and they have only themselves to blame. Or do you blame BMW when you swap the engine in your car for the latest and greatest from Mercedes, only to find that things don't work the way you wanted? > So looking at this, do you still think it was wise to introduce VERP bounce > probes by default and by force with no choice? Let's go over this one last time. Repeat after me -- NO ONE IS FORCING YOU TO UPGRADE!!! -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From bob at nleaudio.com Fri Jul 2 15:01:11 2004 From: bob at nleaudio.com (Bob Puff@NLE) Date: Fri Jul 2 15:00:33 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: <20040702172338.5BB7619E014@web3.nlenet.net> References: <20040702172338.5BB7619E014@web3.nlenet.net> Message-ID: <40E5B0F7.70803@nleaudio.com> Unless I am missing something here, why don't you just enable verp in your MTA? Postfix, Sendmail, Exim, and Qmail all support it. What's the big deal? Bob Somuchfun wrote: > This is not the point here, J.C. > The important point is the fact that mailman did introduce a new way of > handling bounces without a way to opt-out of this new way. Normally every > software package that introduces a new way of doing a certain task (opposed > to a complete new functionality) there is an option to opt-out and continue > "the old way" until all proper changes have been done. > Take cPanel for example, they have still not gotten around to make the > proper adjustments to their highly complex environment and they are used > hundreds of thousands of times around the world by web hosting companies. > Right now people are unsubscribed because of this all over the place for no > apparent reason (from the view of the user). The only way to not end up in > trouble in this environment is to turn off bounce handling completely in > mailman 2.1.5 > So looking at this, do you still think it was wise to introduce VERP bounce > probes by default and by force with no choice? > > ---------------------------------------- > MANA TANGATA > > >>-----Original Message----- >>From: J C Lawrence [mailto:claw@kanga.nu] >>Sent: Thursday, July 01, 2004 5:58 PM >>To: John W. Baxter >>Cc: mailman-developers@python.org >>Subject: Re: [Mailman-Developers] [Greg Stark >>] Re:Bounceremoval parameters default values >> >>On Thu, 01 Jul 2004 17:48:21 -0700 >>John W Baxter wrote: >> >>>On 7/1/2004 9:57, "J C Lawrence" wrote: >> >>>>They can of course always gain that same time and more by >> >>simply not >> >>>>upgrading. >> >>>Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 >>>announcement: >> >>> This version also contains a fix for an exploit that >> >>could allow 3rd >> >>> parties to retrieve member passwords. It is thus highly >> >>recommended >> >>> that all existing sites upgrade to the latest version. >> >>Yup, of such hard choices are upgrades made. >> >>Of course Mailman passwords are also not the most significant >>things in >>the computing universe. >> >>-- >>J C Lawrence >>---------(*) Satan, oscillate my metallic sonatas. >>claw@kanga.nu He lived as a devil, eh? >>http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. >> >>_______________________________________________ >>Mailman-Developers mailing list >>Mailman-Developers@python.org >>http://mail.python.org/mailman/listinfo/mailman-developers >>Unsubscribe: >>http://mail.python.org/mailman/options/mailman-developers/somu >>chfun%40atlantismail.com >> > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > From dallas at dreamhost.com Fri Jul 2 15:23:22 2004 From: dallas at dreamhost.com (Dallas Bethune) Date: Fri Jul 2 15:23:27 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: <40E5B0F7.70803@nleaudio.com> References: <20040702172338.5BB7619E014@web3.nlenet.net> <40E5B0F7.70803@nleaudio.com> Message-ID: <4834B9E0-CC5D-11D8-B3D1-000A95AA76E0@dreamhost.com> I think the issue is that CPanel sort of takes over your machine and handles all the major configuration and it does not support VERP configurations. I've never used CPanel so I don't know the specifics, but I believe that's the issue. Dallas On Jul 2, 2004, at 12:01 PM, Bob Puff@NLE wrote: > Unless I am missing something here, why don't you just enable verp in > your MTA? Postfix, Sendmail, Exim, and Qmail all support it. What's > the big deal? > > Bob > > Somuchfun wrote: >> This is not the point here, J.C. >> The important point is the fact that mailman did introduce a new way >> of >> handling bounces without a way to opt-out of this new way. Normally >> every >> software package that introduces a new way of doing a certain task >> (opposed >> to a complete new functionality) there is an option to opt-out and >> continue >> "the old way" until all proper changes have been done. >> Take cPanel for example, they have still not gotten around to make the >> proper adjustments to their highly complex environment and they are >> used >> hundreds of thousands of times around the world by web hosting >> companies. >> Right now people are unsubscribed because of this all over the place >> for no >> apparent reason (from the view of the user). The only way to not end >> up in >> trouble in this environment is to turn off bounce handling completely >> in >> mailman 2.1.5 >> So looking at this, do you still think it was wise to introduce VERP >> bounce >> probes by default and by force with no choice? >> ---------------------------------------- >> MANA TANGATA >>> -----Original Message----- >>> From: J C Lawrence [mailto:claw@kanga.nu] Sent: Thursday, July 01, >>> 2004 5:58 PM >>> To: John W. Baxter >>> Cc: mailman-developers@python.org >>> Subject: Re: [Mailman-Developers] [Greg Stark ] >>> Re:Bounceremoval parameters default values >>> On Thu, 01 Jul 2004 17:48:21 -0700 John W Baxter >>> wrote: >>> >>>> On 7/1/2004 9:57, "J C Lawrence" wrote: >>> >>>>> They can of course always gain that same time and more by >>> >>> simply not >>> >>>>> upgrading. >>> >>>> Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 >>>> announcement: >>> >>>> This version also contains a fix for an exploit that >>> >>> could allow 3rd >>> >>>> parties to retrieve member passwords. It is thus highly >>> >>> recommended >>> >>>> that all existing sites upgrade to the latest version. >>> >>> Yup, of such hard choices are upgrades made. >>> >>> Of course Mailman passwords are also not the most significant things >>> in >>> the computing universe. >>> >>> -- >>> J C Lawrence >>> ---------(*) Satan, oscillate my metallic sonatas. >>> claw@kanga.nu He lived as a devil, eh? >>> http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. >>> From bob at nleaudio.com Fri Jul 2 15:27:32 2004 From: bob at nleaudio.com (Bob Puff@NLE) Date: Fri Jul 2 15:26:52 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: <4834B9E0-CC5D-11D8-B3D1-000A95AA76E0@dreamhost.com> References: <20040702172338.5BB7619E014@web3.nlenet.net> <40E5B0F7.70803@nleaudio.com> <4834B9E0-CC5D-11D8-B3D1-000A95AA76E0@dreamhost.com> Message-ID: <40E5B724.3060103@nleaudio.com> Ah, didn't realize he was using cpanel. Yeah, it does ALL SORTS of non-standard stuff. I'm on the Interchange list (shopping cart), and they flat out won't support anyone using cpanel. Bob Dallas Bethune wrote: > I think the issue is that CPanel sort of takes over your machine and > handles all the major configuration and it does not support VERP > configurations. I've never used CPanel so I don't know the specifics, > but I believe that's the issue. > > Dallas > > > > On Jul 2, 2004, at 12:01 PM, Bob Puff@NLE wrote: > >> Unless I am missing something here, why don't you just enable verp in >> your MTA? Postfix, Sendmail, Exim, and Qmail all support it. What's >> the big deal? >> >> Bob >> >> Somuchfun wrote: >> >>> This is not the point here, J.C. >>> The important point is the fact that mailman did introduce a new way of >>> handling bounces without a way to opt-out of this new way. Normally >>> every >>> software package that introduces a new way of doing a certain task >>> (opposed >>> to a complete new functionality) there is an option to opt-out and >>> continue >>> "the old way" until all proper changes have been done. >>> Take cPanel for example, they have still not gotten around to make the >>> proper adjustments to their highly complex environment and they are used >>> hundreds of thousands of times around the world by web hosting >>> companies. >>> Right now people are unsubscribed because of this all over the place >>> for no >>> apparent reason (from the view of the user). The only way to not end >>> up in >>> trouble in this environment is to turn off bounce handling completely in >>> mailman 2.1.5 >>> So looking at this, do you still think it was wise to introduce VERP >>> bounce >>> probes by default and by force with no choice? >>> ---------------------------------------- >>> MANA TANGATA >>> >>>> -----Original Message----- >>>> From: J C Lawrence [mailto:claw@kanga.nu] Sent: Thursday, July 01, >>>> 2004 5:58 PM >>>> To: John W. Baxter >>>> Cc: mailman-developers@python.org >>>> Subject: Re: [Mailman-Developers] [Greg Stark ] >>>> Re:Bounceremoval parameters default values >>>> On Thu, 01 Jul 2004 17:48:21 -0700 John W Baxter >>>> wrote: >>>> >>>>> On 7/1/2004 9:57, "J C Lawrence" wrote: >>>> >>>> >>>>>> They can of course always gain that same time and more by >>>> >>>> >>>> simply not >>>> >>>>>> upgrading. >>>> >>>> >>>>> Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 >>>>> announcement: >>>> >>>> >>>>> This version also contains a fix for an exploit that >>>> >>>> >>>> could allow 3rd >>>> >>>>> parties to retrieve member passwords. It is thus highly >>>> >>>> >>>> recommended >>>> >>>>> that all existing sites upgrade to the latest version. >>>> >>>> >>>> Yup, of such hard choices are upgrades made. >>>> >>>> Of course Mailman passwords are also not the most significant things in >>>> the computing universe. >>>> >>>> -- >>>> J C Lawrence >>>> ---------(*) Satan, oscillate my metallic sonatas. >>>> claw@kanga.nu He lived as a devil, eh? >>>> http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. >>>> > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > From claw at kanga.nu Fri Jul 2 16:57:41 2004 From: claw at kanga.nu (J C Lawrence) Date: Fri Jul 2 16:57:46 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: Message from "Somuchfun" of "Fri, 02 Jul 2004 10:21:26 PDT." Message-ID: <28648.1088801861@kanga.nu> On Fri, 2 Jul 2004 10:21:26 -0700 somuchfun wrote: > This is not the point here, J.C. Actually, it is very precisely the point. As this message is repetition so I'll likely be ending my participation in this thread with this message. > The important point is the fact that mailman did introduce a new way > of handling bounces without a way to opt-out of this new way. Yup. > Normally every software package that introduces a new way of doing a > certain task (opposed to a complete new functionality) there is an > option to opt-out and continue "the old way" until all proper changes > have been done. I'm sure that Barry et al would have welcomed your patches. I'm also sure that Barry et al would have welcomed funding by you or cPanel to do the appropriate work. Equally I'm sure that Barry et al would have welcomed an email from cPanel mentioning that they don't support plus addressing and could the Mailman README be updated with a more strongly phrased warning? But, none of these things happened. > Take cPanel for example, they have still not gotten around to make the > proper adjustments to their highly complex environment and they are > used hundreds of thousands of times around the world by web hosting > companies. Yup. > Right now people are unsubscribed because of this all over the place > for no apparent reason (from the view of the user). The only way to > not end up in trouble in this environment is to turn off bounce > handling completely in mailman 2.1.5... Or to have not installed/upgraded_to 2.1.5 in the first place. Nobody pointed a gun at their heads. These are free choices, freely made, freely paid for. > ... So looking at this, do you still think it was wise to introduce > VERP bounce probes by default and by force with no choice? Frankly I just don't think it is very important. I see it as a nice-to-have on all scales: "Hey, it would have been nice if the release docs said something a bit more blatant about requiring plus addressing supports in the local MTA. You know, some CAPS or something." "Yeah, you're right that would have been better to put in CAPs or something. But we didn't hide it, it was in the docs." "Oh yeah." "Wanna go get a beer?" "Sure!" -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From brian at interlinx.bc.ca Sun Jul 4 14:32:42 2004 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sun Jul 4 14:32:59 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? Message-ID: <1088965963.6403.109.camel@pc> I am using MM 2.1.4 and have been getting some "Uncaught bounce notification" messages from it. The MTA is Postfix (a 2.1.0 snapshot as of 20040209) and it is the local MTA (i.e. on the same machine and in the same administrative domain as MM) that is generating the bounces, complete with DSNs. The issue seems to be that the Action: in the DSN is "delayed". These delivery notifications are the "we have been trying for 4 hours and have not been successful but will try for 5 days before giving up" kind of notifications. Looking into the DSN handling code for MM, I see that in DSN.py, the check() method returns "Stop" if action == 'delayed'. The caller (BouncerAPI.py:ScanMessages()) then returns an empty list if the callee returns Stop, which triggers the "unknown bounce" processing. Why is delayed not handled more gracefully than treating it as an unknown bounce type? Or am I totally missing something here? Thanx, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040704/837d11b5/attachment.bin From brad.knowles at skynet.be Sun Jul 4 15:52:09 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Jul 4 15:52:25 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? In-Reply-To: <1088965963.6403.109.camel@pc> References: <1088965963.6403.109.camel@pc> Message-ID: At 2:32 PM -0400 2004-07-04, Brian J. Murrell wrote: > Why is delayed not handled more gracefully than treating it as an > unknown bounce type? Or am I totally missing something here? Search the archives. I believe you'll find that the answer is that you (the mailing list administrator) should have control over the MTA, and if you don't want warnings to be treated the same as bounces, then you should configure the MTA so that it doesn't generate warnings. But you should search the archives to get the full picture of previous discussions. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brian at interlinx.bc.ca Sun Jul 4 16:16:53 2004 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sun Jul 4 16:17:00 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? In-Reply-To: References: <1088965963.6403.109.camel@pc> Message-ID: <1088972213.6403.129.camel@pc> On Sun, 2004-07-04 at 21:52 +0200, Brad Knowles wrote: > > Search the archives. I did. > I believe you'll find that the answer is > that you (the mailing list administrator) should have control over > the MTA, I do -- to the extent that the MTA gives me that control. > and if you don't want warnings to be treated the same as > bounces, then you should configure the MTA so that it doesn't > generate warnings. To say "in order to not treat warnings as errors, disable warnings" is, respectfully, silly. Warnings should be heeded but they do not necessarily indicate that they should be treated as errors. Where in life is it valid to say "to not treat warnings as errors, ignore warnings"? > But you should search the archives to get the full picture of > previous discussions. You are probably referring to the recent discussion of May 2004. I did read it. It did not seem to indicate any real solution (other than ignore warnings). And for mailing list mail, it is _perhaps_ valid to simply disable warnings, so I did look into how to do this. I did not seem to find any way to disable warnings for a given Precedence: level in Postfix. i.e. for Precedence: list only, disable warnings, but for regular Precedence: I do want warnings. I don't think this changes the fact that MM should deal with warnings without barfing them out as "unknown bounces". They are known. The code is there to "know" them. MM just prefers to not deal with them, which I think it should, even if it's to simply ignore them. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040704/8fbeb5c0/attachment.bin From brad.knowles at skynet.be Sun Jul 4 16:43:53 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Jul 4 16:58:30 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? In-Reply-To: <1088972213.6403.129.camel@pc> References: <1088965963.6403.109.camel@pc> <1088972213.6403.129.camel@pc> Message-ID: At 4:16 PM -0400 2004-07-04, Brian J. Murrell wrote: > I don't think this changes the fact that MM should deal with warnings > without barfing them out as "unknown bounces". They are known. The > code is there to "know" them. MM just prefers to not deal with them, > which I think it should, even if it's to simply ignore them. I'm not entirely sure that I disagree with you, but this is functionality not currently found in Mailman, and this is an open source project. If you want to contribute code to make this change happen, and post that as a patch in the SourceForge patch system for Mailman, I'm sure that it would be gladly accepted. No guarantees that this functionality would ever be incorporated, but this would be the most likely way to ensure that this would happen. Otherwise, you're at the mercy of the developers on the project. This project is not a full-time job for anyone (so far as I know), and people have to squeeze in what work that they can, when they can. Right now, the primary focus in Mailman is on the upcoming version 3 stuff, and any work on patching/fixing the current version is going to have to be something pretty major. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brian at interlinx.bc.ca Sun Jul 4 17:08:52 2004 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sun Jul 4 17:08:59 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? In-Reply-To: References: <1088965963.6403.109.camel@pc> <1088972213.6403.129.camel@pc> Message-ID: <1088975332.6403.146.camel@pc> On Sun, 2004-07-04 at 22:43 +0200, Brad Knowles wrote: > > I'm not entirely sure that I disagree with you, OK. So I am not totally off my nut then. :-) > but this is > functionality not currently found in Mailman, and this is an open > source project. Indeed. Very fair points. > If you want to contribute code to make this change happen, and > post that as a patch in the SourceForge patch system for Mailman, I'm > sure that it would be gladly accepted. No guarantees that this > functionality would ever be incorporated, but this would be the most > likely way to ensure that this would happen. Right. I guess I just wanted to make sure my analysis was correct first. Seems it is then. > Otherwise, you're at the mercy of the developers on the project. > This project is not a full-time job for anyone (so far as I know), > and people have to squeeze in what work that they can, when they can. I hear ya. I'm in that same boat. :-) > Right now, the primary focus in Mailman is on the upcoming version 3 > stuff, and any work on patching/fixing the current version is going > to have to be something pretty major. So will version 3 be the next release? i.e. nothing until then? Does v.3 address this issue at all or is it pretty much the same in 3? The next question is, what should MM do with delivery warnings? Is there any merit to doing anything but ignore them silently? That begs the question of why even issue them from the MTA of course, but perhaps not all MTAs are flexible enough to disable those warnings for or below a certain Precedence level. Perhaps for regular mail those warnings are still wanted. Postfix falls into this category as far as I can see, but then I am only a casual user of Postfix -- maybe it is configurable. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040704/edeb642c/attachment.bin From brad.knowles at skynet.be Sun Jul 4 17:39:36 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Jul 4 17:40:31 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? In-Reply-To: <1088975332.6403.146.camel@pc> References: <1088965963.6403.109.camel@pc> <1088972213.6403.129.camel@pc> <1088975332.6403.146.camel@pc> Message-ID: At 5:08 PM -0400 2004-07-04, Brian J. Murrell wrote: > So will version 3 be the next release? i.e. nothing until then? Does > v.3 address this issue at all or is it pretty much the same in 3? I understand that version 3 is going to be a pretty big change, although I don't know if it's going to be a complete re-write. There may or may not be a 2.1.6 released before version 3 arrives, but I wouldn't want to take any bets either way. > The next question is, what should MM do with delivery warnings? Is > there any merit to doing anything but ignore them silently? I'm not sure that there is anything more we can do with them. Hence the suggestion not to generate them, if you don't want them. Of course, most MTAs will only generate one additional warning beyond the bounce itself, so this should have relatively minimal impact if you don't ignore them. If it does have an impact, the other option would be to change the bounce process handling so that you increase the required score by the number of warnings that might be generated, and the impact of warnings should be eliminated. That said, for an MTA which is shared amongst some mailing lists and some real users, it might be better to configure Mailman to ignore warnings than to depend on the MTA not to generate them. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brian at interlinx.bc.ca Sun Jul 4 19:20:30 2004 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sun Jul 4 19:20:44 2004 Subject: [Mailman-Developers] why treat action: delayed in DSN as an unrecognized bounce? In-Reply-To: References: <1088965963.6403.109.camel@pc> <1088972213.6403.129.camel@pc> <1088975332.6403.146.camel@pc> Message-ID: <1088983230.6403.153.camel@pc> On Sun, 2004-07-04 at 23:39 +0200, Brad Knowles wrote: > > I'm not sure that there is anything more we can do with them. Indeed. It is only a warning of non-delivery. The bounce is the important one. > Hence the suggestion not to generate them, if you don't want them. If that is doable, I agree, but to your point below... > Of course, most MTAs will only generate one additional warning beyond > the bounce itself, so this should have relatively minimal impact if > you don't ignore them. You would think but if one is generated for every message for every recipient that does not take delivery within (for example) 4 hours, it does get quite annoying. > If it does have an impact, the other option > would be to change the bounce process handling so that you increase > the required score by the number of warnings that might be generated, > and the impact of warnings should be eliminated. But the issue is not really in thresholds and unsubscriptions and so forth but simply that the list manager's mailbox gets littered with these "unrecognized bounce" messages. Simply having MM ignore them would be sufficient methinks. > That said, for an MTA which is shared amongst some mailing lists > and some real users, it might be better to configure Mailman to > ignore warnings than to depend on the MTA not to generate them. Right. And it seems that a simple "continue" rather than "return Stop" if action == 'delayed' should be the ticket -- not being an MM hacker at the moment anyway. :-) b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040704/5e99671e/attachment.bin From srinoo at rediffmail.com Mon Jul 5 03:11:47 2004 From: srinoo at rediffmail.com (Sreenivas Ganji) Date: Mon Jul 5 03:11:59 2004 Subject: [Mailman-Developers] JTABLE + JDBC Message-ID: <20040705071147.5797.qmail@webmail30.rediffmail.com> Hi all, ? I have a problem in JTable. I wrote a simple application which contains JTextArea and JButtons and JTable. It is workling like.... We can issue a sql query in TextArea, once click on fetch button, it will displaying records in Jtable, but if records are more, I implemented a button called Next(JButton). My requirement is if records are more than 25, then it should be display only first 25 records, if click on next button, we can get next 25 records, it should be goes until all records (each time only 25 records). Please let me know, how to fetch and display only few records in JTable from whole recordset. Please............., if any body knows & have ideas, please share with me. Regards, Srini. From brad.knowles at skynet.be Mon Jul 5 04:54:07 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon Jul 5 04:54:27 2004 Subject: [Mailman-Developers] JTABLE + JDBC In-Reply-To: <20040705071147.5797.qmail@webmail30.rediffmail.com> References: <20040705071147.5797.qmail@webmail30.rediffmail.com> Message-ID: At 7:11 AM +0000 2004-07-05, Sreenivas Ganji wrote: > I have a problem in JTable. > I wrote a simple application which contains JTextArea and JButtons and > JTable. I think you're on the wrong mailing list. This mailing list is for discussions of things related to the Mailman mailing list management program, not anything related to Java. See for more information about the various mailing lists related to Mailman. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From om at onlinehome.de Tue Jul 6 14:10:01 2004 From: om at onlinehome.de (om@onlinehome.de) Date: Tue Jul 6 14:12:05 2004 Subject: [Mailman-Developers] Using bouncer engine as standalone Message-ID: <6871257$108911490940ea931d0275f1.14679779@config18.schlund.de> Hi there, Mailman has rather impressive bouncer code part and I would like to use it for my CRM process to identify bounces. Can one run the bouncer code as a standalone engine, and what would be the right way to do it? Is it a wise thing to do? Basically there is a file with all email bounce messages from my customers and as the result I would need a list of all bounced emails addresses. Bouncer.py needs a mailing list as one of its parameteres. Is it trivial to change the code so that it functions just as a filter for a single file? I do not know that much of Python, so it would take too much time for me to see if it doable in a reasonable time. Should you suggest it is doable, I would spend some time playing around with Python and Mailman code. Best regards, Egor From om at onlinehome.de Tue Jul 6 17:26:03 2004 From: om at onlinehome.de (om@onlinehome.de) Date: Tue Jul 6 17:28:09 2004 Subject: =?iso-8859-1?Q?Re:_Re:_[Mailman-Developers]_Using_bouncer_engine_as_standalone?= Message-ID: <6871257$108912740240eac3ea5b65c3.09186004@config22.schlund.de> Bryan Bradsby schrieb am 06.07.2004, 16:39:13: > Challenge Response sux. > > Friends don't let friends do C/R. > > Just say no to C/R. > > Just my opinion. > > Thank you, > -bryan bradsby > ======================================================================== > > On Tue, 6 Jul 2004 om@onlinehome.de wrote: > > > > > Hi there, > > > > Mailman has rather impressive bouncer code part and I would like to use > > it for my CRM process to identify bounces. ... Thank you for your prompt reaction, Bryan. Could you please elaborate a little bit more on how Challenge Response is connected with using Mailman bouncer code to identify bounces in my inbox? Rgrds, Egor From terri at zone12.com Tue Jul 6 17:46:06 2004 From: terri at zone12.com (Terri Oda) Date: Tue Jul 6 17:45:15 2004 Subject: [Mailman-Developers] Using bouncer engine as standalone In-Reply-To: <6871257$108911490940ea931d0275f1.14679779@config18.schlund.de> References: <6871257$108911490940ea931d0275f1.14679779@config18.schlund.de> Message-ID: <97A8CB3E-CF63-11D8-8F99-000D934FBF38@zone12.com> On Jul 6, 2004, at 8:10 AM, wrote: > Bouncer.py needs a mailing list as one of its parameteres. Is it > trivial > to change the code so that it functions just as a filter for a single > file? I do not know that much of Python, so it would take too much time > for me to see if it doable in a reasonable time. Should you suggest it > is doable, I would spend some time playing around with Python and > Mailman code. This doesn't exactly answer your question, but why not make a list (with all notifications turned off so you don't annoy your customers!), put your addresses into that list and use Bouncer.py with that list as the parameter? Terri From i.am at jimramsay.com Tue Jul 6 19:15:56 2004 From: i.am at jimramsay.com (Jim Ramsay) Date: Tue Jul 6 19:30:27 2004 Subject: [Mailman-Developers] Various strange permission errors Message-ID: I'm running Mailman 2.1.5, as installed by the Gentoo ebuild, and have a couple questions about some strange permission errors I'm getting: 1 - For some reason the permissions on the /usr/local/mailman/archives/private is drwxr-xr-x, but the /usr/local/mailman/cgi-bin/create is only rwxr-sr-x, so the 'create' web script can't ever create anything in that directory. So, should the permissions on the archive directory be 775, or should the 'create' script be suid? 2 - It looks like nothing poperly sets the permissions on data/aliases(.db) or data/virtual-mailman(.db). I did this by hand, but maybe someone else should do that. 3 - After I 'fixed' the first error here by temporarily setting the permissions on the 'create' script to suid, and after fixing the permissions on the postfix alias files by hand, and creating a list, check_perms says that there is a problem - the archive directories should be mode 02775. Why aren't they? None of these are big problems, and I have work-arounds for all, but they are weird. That is all. -- Jim Ramsay "Me fail English? That's unpossible!" From chuqui at plaidworks.com Tue Jul 6 23:35:32 2004 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Tue Jul 6 23:35:39 2004 Subject: [Mailman-Developers] skinning mailman pages... Message-ID: <68ADD732-CF94-11D8-A503-000D93C23532@plaidworks.com> someone please tell me I'm not crazy. I remember a set of patches that could be added to mailman that allowed defining header/footer for mailman without having to hack everything -- and now, I can't find them. Can someone point them out to me? Or suggest ways to add a site look/feel to mailman without hacking everything? I've been using mod_layout to do this, but I'm looking for other options for future uses... From dgc at uchicago.edu Wed Jul 7 00:13:02 2004 From: dgc at uchicago.edu (David Champion) Date: Wed Jul 7 00:13:09 2004 Subject: [Mailman-Developers] Re: skinning mailman pages... In-Reply-To: <68ADD732-CF94-11D8-A503-000D93C23532@plaidworks.com> References: <68ADD732-CF94-11D8-A503-000D93C23532@plaidworks.com> Message-ID: <20040706221302.GK2543@dust.uchicago.edu> * On 2004.07.06, in <68ADD732-CF94-11D8-A503-000D93C23532@plaidworks.com>, * "Chuq Von Rospach" wrote: > > someone please tell me I'm not crazy. I remember a set of patches that > could be added to mailman that allowed defining header/footer for > mailman without having to hack everything -- and now, I can't find > them. Can someone point them out to me? Or suggest ways to add a site > look/feel to mailman without hacking everything? You might be thinking of the ones I wrote for 2.0 beta. (If so, good memory!) I don't see them on the Sourgeforge patch manager anymore, so any description or commentary from then is lost, I guess. At the time (7 Sept 2000), Barry was too far along toward release to include them, and so many changes occurred afterward that I have been too busy to update them. Original posting: Message-ID: <20000907232200.I17203@smack.uchicago.edu> Since Sourceforge looks to have been purged, I put my patches here: http://home.uchicago.edu/~dgc/sw/mailman/patches/ You're welcome to take and use anything you can. Updating the patch(es) should be somewhat time-consuming, but probably not too head-scratching. So much has changed that I don't expect diffs to apply cleanly at all. On the other hand, the changes I made are conceptually pretty straightforward, and if you're willing to put time into very boring menial tasks it should be easy enough to work out using my patch(es) as a guideline. mailman-2.0.dgc.admlogin.2 Adds an admlogin.html template mailman-2.0.dgc.barprint.1 Alternating coloring of rows in listinfo table view mailman-2.0.dgc.config_color.6 Allows customization of color styles mailman-2.0.dgc.global_header.1 Sitewide header/footer templates mailman-2.0.dgc.listintro.3 Afraid I don't quite recall mailman-2.0.dgc.opts_error.1 More pleasant response to invalid CGI parameters mailman-2.0.dgc.uchi-custom.1 mailman-2.0.dgc.uchi_mm_cfg.1 Local style customizations mailman-2.0.dgc.update_var.1 Minor fix to bin/update's use of hard-coded archive paths -- -D. dgc@uchicago.edu NSIT::ENSS No money, no book. No book, no study. No study, no pass. No pass, no graduate. No graduate, no job. No job, no money. T h e U n i v e r s i t y o f C h i c a g o From wheakory at isu.edu Thu Jul 8 18:17:26 2004 From: wheakory at isu.edu (Kory Wheatley) Date: Thu Jul 8 18:27:54 2004 Subject: [Mailman-Developers] Bug error in Send filter option Message-ID: <40ED7396.3060909@isu.edu> I recieve this below error when I setup the non-member messages to be discarded when no action is taken in the send filters option. Any Solution to this? Bug in Mailman version 2.1.5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 87, in run_main main() File "/home/mailman/Mailman/Cgi/admin.py", line 175, in main change_options(mlist, category, subcat, cgidata, doc) File "/home/mailman/Mailman/Cgi/admin.py", line 1296, in change_options gui.handleForm(mlist, category, subcat, cgidata, doc) File "/home/mailman/Mailman/Gui/Privacy.py", line 510, in handleForm GUIBase.handleForm(self, mlist, category, subcat, cgidata, doc) File "/home/mailman/Mailman/Gui/GUIBase.py", line 158, in handleForm doc.addError( File "/home/mailman/Mailman/htmlformat.py", line 340, in addError self.AddItem(Header(3, Bold(FontAttr( TypeError: not enough arguments for format string ------------------------------------------------------------------------ Python information: Variable Value sys.version 2.1.3 (#1, Apr 9 2002, 22:27:11) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] sys.executable /usr/local/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 ------------------------------------------------------------------------ Environment variables: Variable Value DOCUMENT_ROOT /var/www/mailman SERVER_ADDR 134.50.250.14 HTTP_ACCEPT_ENCODING gzip,deflate CONTENT_LENGTH 10956 CONTENT_TYPE application/x-www-form-urlencoded PATH_TRANSLATED /var/www/mailman/irh/privacy/sender REMOTE_ADDR 134.50.249.22 SERVER_SOFTWARE Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_ssl/2.8.12 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 GATEWAY_INTERFACE CGI/1.1 HTTP_COOKIE mailman+admin=280200000069c256ed40732800000033303035313436383336313330616362353433663334386633353436343835626139343036666136; childts+admin=280200000069f756ed40732800000063653036323334393331303563313233646639616231336137626234373830306134663937616466; irh+admin=280200000069d072ed40732800000066616661663263616337383662653834323236333066393861346135613833383637616233663930 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 REMOTE_PORT 1806 SERVER_PORT 80 HTTP_CONNECTION keep-alive HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 REQUEST_URI /mailman/admin/irh/privacy/sender QUERY_STRING SERVER_PROTOCOL HTTP/1.1 HTTP_KEEP_ALIVE 300 HTTP_HOST mm.isu.edu REQUEST_METHOD POST SERVER_SIGNATURE Apache/1.3.27 Server at mm.isu.edu Port 80 SCRIPT_NAME /mailman/admin SERVER_ADMIN wheakory@isu.edu SCRIPT_FILENAME /home/mailman/cgi-bin/admin PYTHONPATH /home/mailman PATH_INFO /irh/privacy/sender HTTP_REFERER http://mm.isu.edu/mailman/admin/irh/privacy/sender SERVER_NAME mm.isu.edu -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From tgc at statsbiblioteket.dk Fri Jul 9 09:48:24 2004 From: tgc at statsbiblioteket.dk (Tom G. Christensen) Date: Fri Jul 9 09:48:26 2004 Subject: [Mailman-Developers] AssertionError in 2.1.5 Message-ID: <40EE4DC8.3040206@statsbiblioteket.dk> Hi, I just hit a bug in 2.1.5 in the 'Confirm subscription request' page. If you press 'Cancel my subscription request' you just get a crash like the one below. Just as an experiment I tried the same thing with my subscription to mailman-developers and the Mailman 2.1.5 at mail.python.org promptly crashed with the same Traceback. Bug in Mailman version 2.1.5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/export/home/mailman/scripts/driver", line 87, in run_main main() File "/export/home/mailman/Mailman/Cgi/confirm.py", line 114, in main subscription_cancel(mlist, doc, cookie) File "/export/home/mailman/Mailman/Cgi/confirm.py", line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/export/home/mailman/Mailman/Pending.py", line 141, in pend_confirm assert self.Locked() AssertionError Python information: Variable Value sys.version 2.3.4 (#1, Jun 2 2004, 10:42:24) [GCC 3.3.2] sys.executable /usr/local/bin/python2.3 sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform sunos5 -tgc From jwt at OnJapan.net Fri Jul 9 15:20:14 2004 From: jwt at OnJapan.net (Jim Tittsler) Date: Fri Jul 9 15:19:35 2004 Subject: [Mailman-Developers] AssertionError in 2.1.5 In-Reply-To: <40EE4DC8.3040206@statsbiblioteket.dk> References: <40EE4DC8.3040206@statsbiblioteket.dk> Message-ID: <20040709132013.GC6654@server.onjapan.net> On Fri, Jul 09, 2004 at 09:48:24AM +0200, Tom G. Christensen wrote: > I just hit a bug in 2.1.5 in the 'Confirm subscription request' page. > > If you press 'Cancel my subscription request' you just get a crash like the > one below. Thanks for the report. The subscription_cancel method fails to lock the list before acting on the pending database (the same lock guards both the list configuration and the pending pck). A quick fix would be to wrap it (in Mailman/Cgi/confirm.py): --- confirm.py-2.1.5 2004-02-11 07:50:10.000000000 +0900 +++ confirm.py 2004-07-09 21:48:32.753528352 +0900 @@ -308,8 +308,12 @@ def subscription_cancel(mlist, doc, cookie): - # Discard this cookie - userdesc = mlist.pend_confirm(cookie)[1] + mlist.Lock() + try: + # Discard this cookie + userdesc = mlist.pend_confirm(cookie)[1] + finally: + mlist.Unlock() lang = userdesc.language i18n.set_language(lang) doc.set_language(lang) However in looking at this, I noticed the other _cancel methods fail to use the user's preferred language when reporting their cancel results. If my preferred language is Japanese and I submit an address change, and then cancel that change... the resulting page is in English. So a more complete patch to confirm.py really needs to be developed that addresses both problems. -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/ Ringo MUG Tokyo http://www.ringo.net/rss.html From brad.knowles at skynet.be Sun Jul 11 16:37:31 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Jul 11 16:37:45 2004 Subject: [Mailman-Developers] [Greg Stark ] Re:Bounceremoval parameters default values In-Reply-To: <28648.1088801861@kanga.nu> References: <28648.1088801861@kanga.nu> Message-ID: At 4:57 PM -0400 2004-07-02, J C Lawrence wrote: > Or to have not installed/upgraded_to 2.1.5 in the first place. Nobody > pointed a gun at their heads. These are free choices, freely made, > freely paid for. I added the FAQ entry to address this issue. Can we now consider this matter closed? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tgc at statsbiblioteket.dk Mon Jul 12 08:59:19 2004 From: tgc at statsbiblioteket.dk (Tom G. Christensen) Date: Mon Jul 12 08:59:25 2004 Subject: [Mailman-Developers] AssertionError in 2.1.5 In-Reply-To: <20040709132013.GC6654@server.onjapan.net> References: <40EE4DC8.3040206@statsbiblioteket.dk> <20040709132013.GC6654@server.onjapan.net> Message-ID: <40F236C7.5030306@statsbiblioteket.dk> Jim Tittsler wrote: > On Fri, Jul 09, 2004 at 09:48:24AM +0200, Tom G. Christensen wrote: > >>I just hit a bug in 2.1.5 in the 'Confirm subscription request' page. >> >>If you press 'Cancel my subscription request' you just get a crash like the >>one below. > > > Thanks for the report. The subscription_cancel method fails to > lock the list before acting on the pending database (the same > lock guards both the list configuration and the pending pck). > Your patch seems to do the trick so I'll use that for now. Thanks. -tgc From fil at rezo.net Mon Jul 12 23:14:49 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 00:13:02 2004 Subject: [Mailman-Developers] VERPing: ouch! Message-ID: <20040712211448.GA2098@rezo.net> Hi, I think there's a small design flaw with the once-in-a-wile VERPing scheme. My biggest list is 180k subscribers, and I've set up Mailman to VERP once every 10th message. Well, it happened today that the big list was hit by its VERP time, and it's a bit awful - it looks like the list has taken control of Mailman, and no other mail can pass through it. I think it might be wiser to say "every 10th recipient" is VERPed at each sending, than what we have now. Of course, it needs rotating things, or randomizing them, so it's not a two-lines of code I guess. Meanwhile I'll just have to disable VERP for this list (or for the whole server). -- Fil From somuchfun at atlantismail.com Tue Jul 13 00:24:32 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Tue Jul 13 00:24:42 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040712211448.GA2098@rezo.net> Message-ID: <20040712222441.079E11E4002@bag.python.org> The problem is you cannot disable the VERP bounce probe (ping) even if you disable VERP in the mm_cfg.py ---------------------------------------- MANA TANGATA > -----Original Message----- > From: Fil [mailto:fil@rezo.net] > Sent: Monday, July 12, 2004 2:15 PM > To: Mailman Developers > Subject: [Mailman-Developers] VERPing: ouch! > > > Hi, > > I think there's a small design flaw with the once-in-a-wile > VERPing scheme. > My biggest list is 180k subscribers, and I've set up Mailman > to VERP once > every 10th message. Well, it happened today that the big list > was hit by its > VERP time, and it's a bit awful - it looks like the list has > taken control > of Mailman, and no other mail can pass through it. > > I think it might be wiser to say "every 10th recipient" is > VERPed at each > sending, than what we have now. Of course, it needs rotating > things, or > randomizing them, so it's not a two-lines of code I guess. > > Meanwhile I'll just have to disable VERP for this list (or > for the whole > server). > > -- Fil > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/somu > chfun%40atlantismail.com > From brad.knowles at skynet.be Tue Jul 13 01:02:40 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 01:17:37 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040712211448.GA2098@rezo.net> References: <20040712211448.GA2098@rezo.net> Message-ID: At 11:14 PM +0200 2004-07-12, Fil wrote: > I think there's a small design flaw with the once-in-a-wile VERPing scheme. > My biggest list is 180k subscribers, and I've set up Mailman to VERP once > every 10th message. Well, it happened today that the big list was hit by its > VERP time, and it's a bit awful - it looks like the list has taken control > of Mailman, and no other mail can pass through it. Well, a 180k list is pretty big by Mailman standards. That's the largest list in current operations that I know of. There have been larger lists in the past, but I haven't heard of any this size or larger since. A big list is going to be painful to send out, if you don't have the hardware sized and configured correctly for this. Search the FAQ wizard for the word "performance" and read every entry returned, if you want to get some idea of what this entails. > I think it might be wiser to say "every 10th recipient" is VERPed at each > sending, than what we have now. Of course, it needs rotating things, or > randomizing them, so it's not a two-lines of code I guess. As you point out, this is a non-trivial change. > Meanwhile I'll just have to disable VERP for this list (or for the whole > server). I imagine that disabling VERP for this one list should probably be enough. If it wasn't, you would have been coming to us already asking about how you can tune your performance. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad.knowles at skynet.be Tue Jul 13 01:03:20 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 01:17:45 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040712222441.079E11E4002@bag.python.org> References: <20040712222441.079E11E4002@bag.python.org> Message-ID: At 3:24 PM -0700 2004-07-12, Somuchfun wrote: > The problem is you cannot disable the VERP bounce probe (ping) even if you > disable VERP in the mm_cfg.py This is assuming you're using Mailman 2.1.5. See also . Moreover, this is just the bounce management system, which should be many, many orders of magnitude smaller than the largest list on the system. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From kiko at async.com.br Tue Jul 13 02:26:23 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue Jul 13 02:26:31 2004 Subject: [Mailman-Developers] Bug 930819 -- onload focus for admlogin.html In-Reply-To: <26726.1088081769@kanga.nu> References: <20040618233842.GD5628@async.com.br> <26726.1088081769@kanga.nu> Message-ID: <20040713002623.GI12694@async.com.br> On Thu, Jun 24, 2004 at 08:56:09AM -0400, J C Lawrence wrote: > On Fri, 18 Jun 2004 20:38:42 -0300 > Christian Robottom Reis wrote: > > > Just a heads-up for bug 930819, which has a patch (two now) that adds > > onload form focus to the password entry in admlogin.html, a usability > > improvement for people using graphical browsers and maintaining many > > lists. > > +1 Anyone else for/against the patch? If it's okay, can someone move towards applying it and notify me? I'd like to keep it from bitrotting, and I have had it on my TODO list for ages now, so I want to ensure it goes upstream. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From fil at rezo.net Tue Jul 13 11:08:38 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 11:07:34 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040712211448.GA2098@rezo.net> References: <20040712211448.GA2098@rezo.net> Message-ID: <20040713090837.GH9327@rezo.net> > I think there's a small design flaw with the once-in-a-wile VERPing scheme. > My biggest list is 180k subscribers, and I've set up Mailman to VERP once > every 10th message. Well, it happened today that the big list was hit by its > VERP time, and it's a bit awful - it looks like the list has taken control > of Mailman, and no other mail can pass through it. In fact I bragged: it's only 152991 subs :) Here's the smtp log line: Jul 13 02:05:22 2004 (435) <20040712150834.DCA153680BD@alan.rezo.net> smtp for 152991 recips, completed in 31782.241 seconds At 02:05 suddenly all the other messages that were waiting to be sent were sent, and the server went into unstable mode (my graphics logs did panic for a while), then everything reverted to normal. In any case, 2 seconds per VERP message for such a big list is too costly, so I'll just disable VERPing the normal messages for now - with the price of not being able to clean the list as efficiently as I could with the occasional VERP. I hope this feedback can be useful, if you have scalability in mind for MM3. -- Fil From brad.knowles at skynet.be Tue Jul 13 13:52:16 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 14:11:47 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040713090837.GH9327@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> Message-ID: At 11:08 AM +0200 2004-07-13, Fil wrote: > Here's the smtp log line: > Jul 13 02:05:22 2004 (435) <20040712150834.DCA153680BD@alan.rezo.net> smtp > for 152991 recips, completed in 31782.241 seconds How does this compare to a normal, non-VERPed delivery for this list? I ask because Chuq Von Rospach has done some calculations on what should theoretically happen to your performance if you enable VERP, but I don't know of anyone who has actually timed the performance difference on large lists. > In any case, 2 seconds per VERP message for such a big list is too costly, > so I'll just disable VERPing the normal messages for now - with the price of > not being able to clean the list as efficiently as I could with the > occasional VERP. > > I hope this feedback can be useful, if you have scalability in mind for MM3. This is really more of an MTA limitation, although there might be some things we can do to try to work around it with Mailman. For example, it might be faster/lower overall load on the server if we had the MTA do the VERPing for us -- we're pretty sure that's supported by some MTAs (e.g., at least some versions of Exim), and we know it's faster for at least some of them (e.g., Exim). -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From fil at rezo.net Tue Jul 13 14:28:34 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 14:27:31 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> Message-ID: <20040713122833.GD26991@rezo.net> > > for 152991 recips, completed in 31782.241 seconds > > How does this compare to a normal, non-VERPed delivery for this list? grep -E "1..... recips" logs/smtp May 27 16:43:46 2004 (440) <20040527135407.74A5F368143@alan.rezo.net> smtp for 151942 recips, completed in 1231.438 seconds Jun 11 19:05:45 2004 (440) <20040611163245.ED9CB3680AE@alan.rezo.net> smtp for 152333 recips, completed in 649.634 seconds Jun 30 15:39:26 2004 (435) <20040630132741.F1A0836811C@alan.rezo.net> smtp for 152717 recips, completed in 428.891 seconds Jul 13 02:05:22 2004 (435) <20040712150834.DCA153680BD@alan.rezo.net> smtp for 152991 recips, completed in 31782.241 seconds > I ask because Chuq Von Rospach has done some calculations on what > should theoretically happen to your performance if you enable VERP, > but I don't know of anyone who has actually timed the performance > difference on large lists. Usually the sending (mailman to postfix to 90% of users) takes a bit more than two hours ; yesterday it took about 6 hours. But more importantly, the Mailman -> postfix thing took 5 hours instead of ~ 15 minutes. > This is really more of an MTA limitation, although there might be > some things we can do to try to work around it with Mailman. For > example, it might be faster/lower overall load on the server if we > had the MTA do the VERPing for us -- we're pretty sure that's > supported by some MTAs (e.g., at least some versions of Exim), and we > know it's faster for at least some of them (e.g., Exim). Probably, yes. I don't konw if postfix can do it "on demand", though there is http://www.postfix.org/VERP_README.html -- Fil From fil at rezo.net Tue Jul 13 14:32:51 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 14:31:47 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> Message-ID: <20040713123251.GF26991@rezo.net> > For example, it might be faster/lower overall load on the server if we had > the MTA do the VERPing for us -- we're pretty sure that's supported by > some MTAs (e.g., at least some versions of Exim), and we know it's faster > for at least some of them (e.g., Exim). Sorry, for postfix indeed it might be much easier to do it this way: http://www.postfix.org/VERP_README.html#smtp the only change between non-verp and verp call to the SMTP server is to replace MAIL FROM: by MAIL FROM: XVERP=+= -- Fil From fil at rezo.net Tue Jul 13 14:44:11 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 14:43:06 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040713090837.GH9327@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> Message-ID: <20040713124410.GH26991@rezo.net> > Here's the smtp log line: > Jul 13 02:05:22 2004 (435) <20040712150834.DCA153680BD@alan.rezo.net> smtp > for 152991 recips, completed in 31782.241 seconds .../... > In any case, 2 seconds per VERP message for such a big list is too costly, Someone kindly told me this makes only 0.2s /message, not 2 seconds -- Fil From brad.knowles at skynet.be Tue Jul 13 15:26:58 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 15:30:21 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040713122833.GD26991@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> Message-ID: At 2:28 PM +0200 2004-07-13, Fil wrote: >> > for 152991 recips, completed in 31782.241 seconds >> >> How does this compare to a normal, non-VERPed delivery for this list? > > grep -E "1..... recips" logs/smtp > > May 27 16:43:46 2004 (440) <20040527135407.74A5F368143@alan.rezo.net> smtp > for 151942 recips, completed in 1231.438 seconds 1231.438/151942 = 0.0081046 seconds per recipient (average) > Jun 30 15:39:26 2004 (435) <20040630132741.F1A0836811C@alan.rezo.net> smtp > for 152717 recips, completed in 428.891 seconds 428.891/152717 = 0.0028084 seconds per recipient (average) > Jul 13 02:05:22 2004 (435) <20040712150834.DCA153680BD@alan.rezo.net> smtp > for 152991 recips, completed in 31782.241 seconds 31782.241/152991 = 0.2077392 seconds per recipient (average) So, on average, you're taking somewhere close to 25-75 times as long, if you enable VERP for the entire list. Ouch! >> I ask because Chuq Von Rospach has done some calculations on what >> should theoretically happen to your performance if you enable VERP, >> but I don't know of anyone who has actually timed the performance >> difference on large lists. > > Usually the sending (mailman to postfix to 90% of users) takes a bit more > than two hours ; yesterday it took about 6 hours. But more importantly, the > Mailman -> postfix thing took 5 hours instead of ~ 15 minutes. I will definitely update the VERP performance entry in the FAQ to reference your experience. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad.knowles at skynet.be Tue Jul 13 15:28:13 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 15:30:25 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040713123251.GF26991@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713123251.GF26991@rezo.net> Message-ID: At 2:32 PM +0200 2004-07-13, Fil wrote: > Sorry, for postfix indeed it might be much easier to do it this way: > http://www.postfix.org/VERP_README.html#smtp > > the only change between non-verp and verp call to the SMTP server is to > replace > MAIL FROM: > by > MAIL FROM: XVERP=+= I don't know what this would do for performance with postfix (relative to having Mailman do the VERPing), but it would certainly be interesting to find out. Can you modify your code so as to generate this modified string, and see what happens? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad.knowles at skynet.be Tue Jul 13 15:49:25 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 15:49:33 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> Message-ID: At 3:26 PM +0200 2004-07-13, Brad Knowles wrote: >> Usually the sending (mailman to postfix to 90% of users) takes a bit more >> than two hours ; yesterday it took about 6 hours. But more importantly, the >> Mailman -> postfix thing took 5 hours instead of ~ 15 minutes. > > I will definitely update the VERP performance entry in the FAQ to > reference your experience. Done. See . Please let me know if you think that any other information needs to be added, or if there are any corrections you feel need to be made. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From claw at kanga.nu Tue Jul 13 16:11:32 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 16:11:36 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from Brad Knowles of "Tue, 13 Jul 2004 13:52:16 +0200." References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> Message-ID: <12470.1089727892@kanga.nu> On Tue, 13 Jul 2004 13:52:16 +0200 Brad Knowles wrote: > This is really more of an MTA limitation, although there might be some > things we can do to try to work around it with Mailman. For example, > it might be faster/lower overall load on the server if we had the MTA > do the VERPing for us -- we're pretty sure that's supported by some > MTAs (e.g., at least some versions of Exim), and we know it's faster > for at least some of them (e.g., Exim). s/Exim/QMail/g Exim does have some supports, but not to the degree that QMail does, and not to the performance degree that QMail does. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Tue Jul 13 16:25:10 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 16:25:13 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from Fil of "Tue, 13 Jul 2004 14:28:34 +0200." <20040713122833.GD26991@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> Message-ID: <13600.1089728710@kanga.nu> On Tue, 13 Jul 2004 14:28:34 +0200 fil wrote: >> I ask because Chuq Von Rospach has done some calculations on what >> should theoretically happen to your performance if you enable VERP, >> but I don't know of anyone who has actually timed the performance >> difference on large lists. > Usually the sending (mailman to postfix to 90% of users) takes a bit > more than two hours ; yesterday it took about 6 hours. That's an effective delivery rate of ~1,300 deliveries per minute, which is fairly low assuming moderate hardware. ObNote: I found I could sustain 2,400 deliveries per minute with a quick-poke tuned Postfix on a 512Meg RAM PII-333 with separate spindles for spool and log. Some minor efforts at more disciplined tuning suggested that it could sustain 2,800+, but I could never verify that as I just couldn't keep the spool fed fast enough. > But more importantly, the Mailman -> postfix thing took 5 hours > instead of ~ 15 minutes. What system metrics spiked during this time? 160K/5 hours is a delivery rate of less than 600 per minute. That's one message every 10+ seconds which is quite slow. Even if you double that (receipt and transmission) that's only 1,200 per minute which is still dawdling territory. Your MTA should have been able to keep that spool empty while twiddling its thumbs. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Tue Jul 13 16:27:33 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 16:27:37 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from Fil of "Tue, 13 Jul 2004 14:44:11 +0200." <20040713124410.GH26991@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713124410.GH26991@rezo.net> Message-ID: <13853.1089728853@kanga.nu> On Tue, 13 Jul 2004 14:44:11 +0200 fil wrote: >> Here's the smtp log line: Jul 13 02:05:22 2004 (435) >> <20040712150834.DCA153680BD@alan.rezo.net> smtp for 152991 recips, >> completed in 31782.241 seconds > .../... >> In any case, 2 seconds per VERP message for such a big list is too >> costly, > Someone kindly told me this makes only 0.2s /message, not 2 seconds $ calc "152991 / 31782.241" ~4.81372600503532774797 -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Tue Jul 13 16:31:10 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 16:31:13 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from Brad Knowles of "Tue, 13 Jul 2004 15:26:58 +0200." References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> Message-ID: <14181.1089729070@kanga.nu> On Tue, 13 Jul 2004 15:26:58 +0200 Brad Knowles wrote: > I will definitely update the VERP performance entry in the FAQ to > reference your experience. I wouldn't, not yet. The numbers are too far off from reasonable expectation. I'd bet there are other strongly unknown factors which are impeding performance (no local cacheing name server, spool and log on same ATA spindle, something). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From bob at nleaudio.com Tue Jul 13 16:44:22 2004 From: bob at nleaudio.com (Bob Puff) Date: Tue Jul 13 16:44:32 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <13600.1089728710@kanga.nu> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> <13600.1089728710@kanga.nu> Message-ID: <20040713144338.M47695@bobpuff.com> Hey JC, Any FAQ on your "quick-poke" tunings? Bob ---------- Original Message ----------- From: J C Lawrence > > ObNote: I found I could sustain 2,400 deliveries per minute with a > quick-poke tuned Postfix on a 512Meg RAM PII-333 with separate > spindles for spool and log. Some minor efforts at more disciplined > tuning suggested that it could sustain 2,800+, but I could never > verify that as I just couldn't keep the spool fed fast enough. From terri at zone12.com Tue Jul 13 17:07:18 2004 From: terri at zone12.com (Terri Oda) Date: Tue Jul 13 17:06:22 2004 Subject: [Mailman-Developers] Bug 930819 -- onload focus for admlogin.html In-Reply-To: <20040713002623.GI12694@async.com.br> References: <20040618233842.GD5628@async.com.br> <26726.1088081769@kanga.nu> <20040713002623.GI12694@async.com.br> Message-ID: <5539C622-D4DE-11D8-B97F-000D934FBF38@zone12.com> On Jul 12, 2004, at 8:26 PM, Christian Robottom Reis wrote: > On Thu, Jun 24, 2004 at 08:56:09AM -0400, J C Lawrence wrote: >> On Fri, 18 Jun 2004 20:38:42 -0300 >> Christian Robottom Reis wrote: >> >>> Just a heads-up for bug 930819, which has a patch (two now) that adds >>> onload form focus to the password entry in admlogin.html, a usability >>> improvement for people using graphical browsers and maintaining many >>> lists. >> >> +1 > > Anyone else for/against the patch? > > If it's okay, can someone move towards applying it and notify me? I'd > like to keep it from bitrotting, and I have had it on my TODO list for > ages now, so I want to ensure it goes upstream. +1 Although I haven't checked the patch, I like avoiding my mouse, and it's hard to see how it's going to cause problems. Good for you on trying to keep it in people's minds so it'll get applied! Terri From claw at kanga.nu Tue Jul 13 17:15:32 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 17:15:36 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from "Bob Puff" of "Tue, 13 Jul 2004 10:44:22 EDT." <20040713144338.M47695@bobpuff.com> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> <13600.1089728710@kanga.nu> <20040713144338.M47695@bobpuff.com> Message-ID: <17858.1089731732@kanga.nu> On Tue, 13 Jul 2004 10:44:22 -0400 Bob Puff wrote: > Any FAQ on your "quick-poke" tunings? I don't recall anything off the top of my head that's not in the list archives or the User FAQ (I reported on it at the time in both places IIRC). I've not run Postfix for some years now (I'm currently Exim-everywhere due to UID/GUI control and message rewriting issues) and so would have to re-research the docs to give a more accurate answer. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From fil at rezo.net Tue Jul 13 17:22:26 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 17:22:28 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <13600.1089728710@kanga.nu> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> <13600.1089728710@kanga.nu> Message-ID: <20040713152226.GB30376@rezo.net> > > But more importantly, the Mailman -> postfix thing took 5 hours > > instead of ~ 15 minutes. > > What system metrics spiked during this time? None! > 160K/5 hours is a delivery rate of less than 600 per minute. That's one > message every 10+ seconds which is quite slow. Even if you double that > (receipt and transmission) that's only 1,200 per minute which is still > dawdling territory. Your MTA should have been able to keep that spool > empty while twiddling its thumbs. Yes, the MTA *was* twiddling its thumbs, and the system too... and as Mailman's daemon was sending one VERP msg at a time, it was not processing the usual incoming stuff, and not delivering the other lists. I got a nice spike at the end of the 5 hour period, when all the msgs that were kept waiting suddenly jumped in :-) -- Fil From nick.vdkloor at for-nation.com Tue Jul 13 17:24:11 2004 From: nick.vdkloor at for-nation.com (Nick vd Kloor @ FOR-Nation) Date: Tue Jul 13 17:24:16 2004 Subject: [Mailman-Developers] How to export memberlist to file Message-ID: <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> Hi all, not sure anymore if there is a function or parameter to get your whole memberlist in a textfile. Does anyone know? Thanx in advance, Nick From claw at kanga.nu Tue Jul 13 17:26:32 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 17:26:35 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from Fil of "Tue, 13 Jul 2004 17:22:26 +0200." <20040713152226.GB30376@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> <13600.1089728710@kanga.nu> <20040713152226.GB30376@rezo.net> Message-ID: <18856.1089732392@kanga.nu> On Tue, 13 Jul 2004 17:22:26 +0200 fil wrote: > Yes, the MTA *was* twiddling its thumbs, and the system too... and as > Mailman's daemon was sending one VERP msg at a time, it was not > processing the usual incoming stuff, and not delivering the other > lists. v2.x or v1.x? I thought v2 chunked the queue processing... Hurm, if it doesn't it should and that's an easy enough fix. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From fil at rezo.net Tue Jul 13 17:33:43 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 17:33:44 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <18856.1089732392@kanga.nu> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> <13600.1089728710@kanga.nu> <20040713152226.GB30376@rezo.net> <18856.1089732392@kanga.nu> Message-ID: <20040713153343.GF30376@rezo.net> > > Yes, the MTA *was* twiddling its thumbs, and the system too... and as > > Mailman's daemon was sending one VERP msg at a time, it was not > > processing the usual incoming stuff, and not delivering the other > > lists. > > v2.x or v1.x? version 2.1.5b1 > I thought v2 chunked the queue processing... Hurm, if it > doesn't it should and that's an easy enough fix. >From what I read we're in SMTPDirect.py : def process(mlist, msg, msgdata): this function does process all recipients (in chunks if not VERP) consecutively, before exiting. We spent 5 hours in its main loop for that one message. -- Fil From fil at rezo.net Tue Jul 13 17:39:03 2004 From: fil at rezo.net (Fil) Date: Tue Jul 13 17:39:05 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713123251.GF26991@rezo.net> Message-ID: <20040713153903.GG30376@rezo.net> > > Sorry, for postfix indeed it might be much easier to do it this way: > > http://www.postfix.org/VERP_README.html#smtp > > > > the only change between non-verp and verp call to the SMTP server is to > > replace > > MAIL FROM: > > by > > MAIL FROM: XVERP=+= > > I don't know what this would do for performance with postfix > (relative to having Mailman do the VERPing), but it would certainly > be interesting to find out. > > Can you modify your code so as to generate this modified string, > and see what happens? It's not so easy for me: it's a production server, and I'm bad at python :) Moreover, and more importantly, what needs to be done is first to test the presence of XVERP in the SMTPd server we connect to. Postfix does not enable it by default. Then check if the message wants to be VERP (but not decorated). Then only ask XVERP from the MTA. Too ambitious for me... -- Fil From brad.knowles at skynet.be Tue Jul 13 18:30:06 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 18:49:37 2004 Subject: [Mailman-Developers] How to export memberlist to file In-Reply-To: <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> References: <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> Message-ID: At 5:24 PM +0200 2004-07-13, Nick vd Kloor @ FOR-Nation wrote: > not sure anymore if there is a function or parameter to get your whole > memberlist in a textfile. > Does anyone know? See . -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From darrell at grumblesmurf.net Tue Jul 13 18:54:18 2004 From: darrell at grumblesmurf.net (Darrell Fuhriman) Date: Tue Jul 13 18:54:21 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040713122833.GD26991@rezo.net> (fil@rezo.net's message of "Tue, 13 Jul 2004 14:28:34 +0200") References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> Message-ID: Fil writes: > Probably, yes. I don't konw if postfix can do it "on demand", though there > is http://www.postfix.org/VERP_README.html It does if you pass it the right options. Rather than having mailman do the VERPing, I let postfix handle it. Performance is greatly improved, because at the least you can then have multiple recipients per queue file. There's several things mailman should be letting the MTA handle, as long as it can. VERP and requesting no warning messages, for example. Darrell From Nigel.Metheringham at dev.intechnology.co.uk Tue Jul 13 19:13:35 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Tue Jul 13 19:13:44 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> Message-ID: <1089738815.3415.28.camel@angua.localnet> On Tue, 2004-07-13 at 12:52, Brad Knowles wrote: > At 11:08 AM +0200 2004-07-13, Fil wrote: > > I hope this feedback can be useful, if you have scalability in mind for MM3. > > This is really more of an MTA limitation, although there might be > some things we can do to try to work around it with Mailman. For > example, it might be faster/lower overall load on the server if we > had the MTA do the VERPing for us -- we're pretty sure that's > supported by some MTAs (e.g., at least some versions of Exim), and we > know it's faster for at least some of them (e.g., Exim). If you are doing VERP in MM then you send one message per recipient from MM to your MTA. Thats the think that will cause problems on many systems because you will need almost as much spool space as the message multiplied by the recipient count (almost as much because some of the early messages will have left the box by the time the last ones come in). I guess that the awful performance in this case is probably down to something like the MTA doing verification on sender/recipient inline, which will slaughter performance. We are very very shortly going to convert exim.org to a new platform with new Mailman installation, which I intend to do VERP deliveries on. I can use that box, when in use, to test VERP on MM against VERP within exim, and I'll write up my results. However I am looking at 2K users - not 150K, and it maybe that there are scaling problem As a blatant and unwarranted plug, the Exim/Mailman HOWTO gives information on using VERP with Exim http://www.exim.org/howto/mailman21.html Cheers Nigel. [At an exim conference :-) ] -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From brad.knowles at skynet.be Tue Jul 13 19:22:51 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 13 19:40:53 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> Message-ID: At 9:54 AM -0700 2004-07-13, Darrell Fuhriman wrote: > Rather than having mailman do the VERPing, I let postfix handle > it. Performance is greatly improved, because at the least you > can then have multiple recipients per queue file. Can you tell us what modifications you've made to mailman to make it do this correctly with postfix? > There's several things mailman should be letting the MTA handle, > as long as it can. VERP and requesting no warning messages, for > example. Agreed. Got patches? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From claw at kanga.nu Tue Jul 13 21:18:24 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 21:18:27 2004 Subject: [Mailman-Developers] How to export memberlist to file In-Reply-To: Message from "Nick vd Kloor @ FOR-Nation" of "Tue, 13 Jul 2004 17:24:11 +0200." <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> References: <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> Message-ID: <6976.1089746304@kanga.nu> On Tue, 13 Jul 2004 17:24:11 +0200 Nick vd Kloor <@ FOR-Nation" > wrote: > Hi all, not sure anymore if there is a function or parameter to get > your whole memberlist in a textfile. Does anyone know? ~/bin/list_members. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Tue Jul 13 21:39:19 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 21:39:22 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: Message from Fil of "Tue, 13 Jul 2004 17:33:43 +0200." <20040713153343.GF30376@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713122833.GD26991@rezo.net> <13600.1089728710@kanga.nu> <20040713152226.GB30376@rezo.net> <18856.1089732392@kanga.nu> <20040713153343.GF30376@rezo.net> Message-ID: <8758.1089747559@kanga.nu> On Tue, 13 Jul 2004 17:33:43 +0200 fil wrote: >> I thought v2 chunked the queue processing... Hurm, if it doesn't it >> should and that's an easy enough fix. >> From what I read we're in SMTPDirect.py : > def process(mlist, msg, msgdata): > this function does process all recipients (in chunks if not VERP) > consecutively, before exiting. We spent 5 hours in its main loop for > that one message. The painful bit is in Runner.py which appears to linearly process each message queue. The next optimisation would have queue runners forking off every N minutes, with each one opportunistically handling messages in the queue. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From shaikli at yahoo.com Tue Jul 13 21:58:11 2004 From: shaikli at yahoo.com (Nadim Shaikli) Date: Tue Jul 13 21:58:14 2004 Subject: [Mailman-Developers] How to export memberlist to file In-Reply-To: <6976.1089746304@kanga.nu> Message-ID: <20040713195811.26170.qmail@web14921.mail.yahoo.com> --- J C Lawrence wrote: > On Tue, 13 Jul 2004 17:24:11 +0200 > Nick vd Kloor <@ FOR-Nation" > wrote: > > > Hi all, not sure anymore if there is a function or parameter to get > > your whole memberlist in a textfile. Does anyone know? > > ~/bin/list_members. It would be nice if 'list_members' also listed all the other secondary info to ease exports/imports and/or list moves, - Digest on/off - Members name (if entered) - mod/hide/etc/etc Regards, - Nadim __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From terri at zone12.com Tue Jul 13 22:22:09 2004 From: terri at zone12.com (Terri Oda) Date: Tue Jul 13 22:21:17 2004 Subject: [Mailman-Developers] How to export memberlist to file In-Reply-To: <20040713195811.26170.qmail@web14921.mail.yahoo.com> References: <20040713195811.26170.qmail@web14921.mail.yahoo.com> Message-ID: <516CE0F8-D50A-11D8-B97F-000D934FBF38@zone12.com> On Jul 13, 2004, at 3:58 PM, Nadim Shaikli wrote: > It would be nice if 'list_members' also listed all the other secondary > info to ease exports/imports and/or list moves, > > - Digest on/off > - Members name (if entered) > - mod/hide/etc/etc Sounds good as long as it's optional and can be turned off. I'm pretty sure there are good reasons for wanting a list of only email addresses, and I think some people are using it expecting this output (I seem to recall someone who had a script that got addresses for all subscribers on a site and made an announcement list out of it for urgent side-wide announcements without sending to all lists?) It shouldn't be hard to add to list_members. It can already be done with withlist (If I recall correctly) but it'd be a handy thing to have for backups. I'll take a look at it later if no one else gets to it first. Terri From dan.mick at sun.com Tue Jul 13 22:43:09 2004 From: dan.mick at sun.com (Dan Mick) Date: Tue Jul 13 22:45:18 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: <20040713123251.GF26991@rezo.net> References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713123251.GF26991@rezo.net> Message-ID: <40F4495D.3050702@sun.com> Fil wrote: >>For example, it might be faster/lower overall load on the server if we had >>the MTA do the VERPing for us -- we're pretty sure that's supported by >>some MTAs (e.g., at least some versions of Exim), and we know it's faster >>for at least some of them (e.g., Exim). > > > Sorry, for postfix indeed it might be much easier to do it this way: > http://www.postfix.org/VERP_README.html#smtp > > the only change between non-verp and verp call to the SMTP server is to > replace > MAIL FROM: > by > MAIL FROM: XVERP=+= > > -- Fil I've been doing Postfix VERPing for years. It's a really small change to the sendmail invoker (it already had a variable to hold 'options' or some such.) From mailmandev at waikato.ac.nz Tue Jul 13 23:09:38 2004 From: mailmandev at waikato.ac.nz (Colin Palmer) Date: Tue Jul 13 23:09:48 2004 Subject: [Mailman-Developers] VERPing: ouch! In-Reply-To: References: <20040712211448.GA2098@rezo.net> <20040713090837.GH9327@rezo.net> <20040713123251.GF26991@rezo.net> Message-ID: <1089752977.4265.153.camel@firefox.cc.waikato.ac.nz> On Wed, 2004-07-14 at 01:28, Brad Knowles wrote: > At 2:32 PM +0200 2004-07-13, Fil wrote: > > the only change between non-verp and verp call to the SMTP server is to > > replace > > MAIL FROM: > > by > > MAIL FROM: XVERP=+= > I don't know what this would do for performance with postfix > (relative to having Mailman do the VERPing), but it would certainly > be interesting to find out. > Can you modify your code so as to generate this modified string, > and see what happens? There's already a patch that adds the required options to do this into SMTPDirect.py http://sourceforge.net/tracker/index.php?func=detail&aid=869638&group_id=103&atid=300103 I've got it on a production system here, and it's working great. Though the largest list it's got is just 11000 addresses, which isn't enough to really stress it. -- Colin Palmer University of Waikato From claw at kanga.nu Tue Jul 13 23:47:11 2004 From: claw at kanga.nu (J C Lawrence) Date: Tue Jul 13 23:47:14 2004 Subject: [Mailman-Developers] How to export memberlist to file In-Reply-To: Message from Nadim Shaikli of "Tue, 13 Jul 2004 12:58:11 PDT." <20040713195811.26170.qmail@web14921.mail.yahoo.com> References: <20040713195811.26170.qmail@web14921.mail.yahoo.com> Message-ID: <20724.1089755231@kanga.nu> On Tue, 13 Jul 2004 12:58:11 -0700 (PDT) Nadim Shaikli wrote: > It would be nice if 'list_members' also listed all the other secondary > info to ease exports/imports and/or list moves, You can use with-list for that. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From brad.knowles at skynet.be Wed Jul 14 14:52:13 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed Jul 14 14:55:47 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] How to export memberlist to file In-Reply-To: <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> References: <200407131524.i6DFOBKl009614@smtp-out3.xs4all.nl> Message-ID: At 5:24 PM +0200 2004-07-13, Nick vd Kloor @ FOR-Nation wrote: > not sure anymore if there is a function or parameter to get your whole > memberlist in a textfile. > Does anyone know? See the FAQ. Specifically, . -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From ianb at colorstudy.com Wed Jul 14 23:07:11 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Wed Jul 14 23:07:58 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces Message-ID: <40F5A07F.2090607@colorstudy.com> I've been searching around for people's experiences implementing alternate web interfaces for Mailman, but I've been surprised not to find much. The desire to do this seems obvious to me -- there's a lot of different flavors of mailing list (discussion, announce, correspondance management, and many others). The interface tries to support all of these, and is rather overwhelming as a result. Since I haven't found other people making these interfaces, I'm guessing: (a) I'm not looking in the right places, (b) people are doing this but not sharing their results, (c) and it's so easy they don't even need to ask public questions about it, (d) or it's so hard they give up quickly, (e) or it's easy but fragile, and people create lots of prototypes but nothing serious, (e) or everyone lacks the imagination or interest to try. Now that I list them, (a) seems the most likely, but I swear I've really tried to find them. Are their examples people might suggest? Right now I'm just trying to evaluate the feasibility of creating a trimmed-down interface. Actually a couple interfaces: one for announce list subscribers (*very* minimal), another for announce list administrators (including some posting tools and reports), and another simplified discussion list user interface. Anyway, I just wanted to see if other people are thinking about this, have already done this, or can give any advise. It doesn't look hard from my first investigation, but I'm also not sure how to best implement -- Mailman's web interface confuses me a bit, and I'm guessing that it's an ad hoc application server. If we go ahead to make this, I suspect we'll want to do something more expedient (i.e., not based on Mailman 3.0), but it would be nice to do this in a way that can be shared, and something that isn't just a hack. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From fil at rezo.net Thu Jul 15 00:43:47 2004 From: fil at rezo.net (Fil) Date: Thu Jul 15 00:43:39 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces In-Reply-To: <40F5A07F.2090607@colorstudy.com> References: <40F5A07F.2090607@colorstudy.com> Message-ID: <20040714224347.GB9407@rezo.net> > these, and is rather overwhelming as a result. Since I haven't found > other people making these interfaces, I'm guessing: (a) I'm not looking > in the right places, (b) people are doing this but not sharing their > results, (c) and it's so easy they don't even need to ask public > questions about it, (d) or it's so hard they give up quickly, (e) or > it's easy but fragile, and people create lots of prototypes but nothing > serious, (e) or everyone lacks the imagination or interest to try. I'd say (d). Personnaly I've made a php subscribe/unsuscribe popup page for my site, check it out at http://listes.rezo.net/popup/ -- Fil From adam.steer at alia.org.au Thu Jul 15 01:10:02 2004 From: adam.steer at alia.org.au (Adam Steer) Date: Thu Jul 15 01:06:07 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces Message-ID: have a look at http://lists.alia.org.au It's been alot of work, mainly because I'm not a Python programmer, or really a programmer at all. Our aim was to produce a look-and-feel consistent with the rest of our site, and also try to achieve our advertised levels of HTML/CSS compliance [yeah, still using HTML] - and have the thing integrate with some internal info we keep about our lists. The interface has been made by hacking the templates we use, then digging deeper and making changes to the htmlformatting scripts, and some of the Gui scripts, and more. Our archives are still in the dark ages, but we're messing around with MHonArc to achieve what we want there [and have a config file as long as your arm...] Some people have made patches that allow modification in far better Python than mine, I'm sure [ in fact someone posted here recently about 'skinning mailman']. My aim is to keep chipping away until I understand Mailman well enough to take all the formatting away from Mailman and make it call page components when it needs to. Much more Python study to do! MM 2.1.x seems lots better than 2.0, but it's still not too easy [for a gumby Python hacker] to change the way MM looks. I'm happy to provide more detail for anyone who might be keen to find out what it took. Also, we've got 2.1.5 running on SuSE [8.2 and 9.1]- and we're happy to share config information about getting that done, too. Just a long --config away, really. cheers Adam. -- Adam Steer Web publishing officer Australian Library and Information Association adam.steer@alia.org.au http://alia.org.au +61 2 6215 8234 >>> Ian Bicking - 15/7/04 7:07 AM >>> I've been searching around for people's experiences implementing alternate web interfaces for Mailman, but I've been surprised not to find much. From ml at ancalagon.inka.de Thu Jul 15 07:01:40 2004 From: ml at ancalagon.inka.de (Thomas Hochstein) Date: Thu Jul 15 07:02:16 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces References: <40F5A07F.2090607@colorstudy.com> Message-ID: Ian Bicking schrieb: > Since I haven't found > other people making these interfaces, I'm guessing: (a) I'm not looking > in the right places, (b) people are doing this but not sharing their > results, (c) and it's so easy they don't even need to ask public > questions about it, (d) or it's so hard they give up quickly, (e) or > it's easy but fragile, and people create lots of prototypes but nothing > serious, (e) or everyone lacks the imagination or interest to try. (f) People don't see a need for that because the interface is working just fine for them ... -thh From Nigel.Metheringham at dev.intechnology.co.uk Thu Jul 15 09:46:48 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu Jul 15 09:46:52 2004 Subject: [Mailman-Developers] Relocating a list Message-ID: <1089877607.5059.9.camel@angua.localnet> We are (finally) about to upgrade exim.org to a less obsolete version of Mailman [the excuse up to now has been that the box was overloaded and a Pentium 200 wouldn't handle the upgrades needed to get current!]. In one transition we intend to:- * Move to new hardware (Original pentium to P-IV) * Move to a new OS (Linux (RH7.3) to FreeBSD) * Move to a new Python (1.5.2 to 2.3) * Move to a new directory layout and we would like to keep the change relatively transparent :-) In particular we would like to keep the archive URLs stable, so regenerating the archives from the mboxes is not really an option despite the fact it would give us slightly better handling of the few attachments that have made it to the list. [The archives have had messages removed in the past so a regenerate would not keep numbering stable] I've just been looking at Barry's notes for his list relocation at http://www.mail-archive.com/mailman-developers@python.org/msg03127.html Would the process detailed there work OK for this sort of move - obviously I need to transfer the complete tree for a list from the old machine to the new one, but thats easy enough. The main thing I was wondering about is whether the python saved files (ie the list db file etc) will transfer OK, or whether they have machine/os/python-version dependencies that will preclude doing things this way? Cheers Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From brad.knowles at skynet.be Thu Jul 15 10:31:40 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jul 15 10:31:57 2004 Subject: [Mailman-Developers] Relocating a list In-Reply-To: <1089877607.5059.9.camel@angua.localnet> References: <1089877607.5059.9.camel@angua.localnet> Message-ID: At 8:46 AM +0100 2004-07-15, Nigel Metheringham wrote: > In one transition we intend to:- > * Move to new hardware (Original pentium to P-IV) > * Move to a new OS (Linux (RH7.3) to FreeBSD) > * Move to a new Python (1.5.2 to 2.3) > * Move to a new directory layout Out of curiosity, what version of Mailman are you running now, and will you be upgrading to 2.1.5? > In particular we would like to keep the archive URLs stable, so > regenerating the archives from the mboxes is not really an option > despite the fact it would give us slightly better handling of the few > attachments that have made it to the list. [The archives have had > messages removed in the past so a regenerate would not keep numbering > stable] Ouch. > I've just been looking at Barry's notes for his list relocation at > http://www.mail-archive.com/mailman-developers@python.org/msg03127.html We just moved python.org to a new machine, so perhaps this needs to be revisited and updated. I don't know the specifics for the old hardware, but the new hardware is not bad: Quad Pentium 4 XEON (2.2GHz) CPUs 1GB of RAM Adaptec I2O hardware RAID controller (RAID 1) Ext3fs 135GB total disk space 1.9GB of swap I know we were running Exim on the old machine. However, due to lack of people on the project who are sufficiently familiar with this program, we're instead running postfix on the new machine. Therefore, I can't speak for how those changes may affect things. We're still tuning the anti-spam settings (especially training the SpamBayes stuff), but what we've got now seems to be at least a decent starting point. Since the machine is hosted for us by the very kind folks at XS4ALL, we also have the pleasure of dumping all outbound messages on their mail relay servers, so we don't have to deal with deep queues, etc.... > Would the process detailed there work OK for this sort of move - > obviously I need to transfer the complete tree for a list from the old > machine to the new one, but thats easy enough. I can say that we had the new machine set up for a little while before we tool the old one down, so we had time to test that we had copied over everything correctly, or made appropriate adjustments as necessary. > The main thing I was wondering about is whether the python saved files > (ie the list db file etc) will transfer OK, or whether they have > machine/os/python-version dependencies that will preclude doing things > this way? I would be concerned about the python structures surviving such a big transition intact. I'd want to have a dump of the list configuration in a textual form, which could then be re-imported on the other side. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From fil at rezo.net Thu Jul 15 15:59:24 2004 From: fil at rezo.net (Fil) Date: Thu Jul 15 15:59:12 2004 Subject: [Mailman-Developers] interface dreams Message-ID: <20040715135923.GI24700@rezo.net> As a list admin, I dream of a roster interface that would help me go fast when I have 10 people to subscribe and 10 to remove because they don't know better than "Reply"-ing to me. I can make it up with php, with a box for search, another for "add users", another for "remove users", and so on ("change address"). However there's something that could be very useful, that would be "search fuzzy matches", for instance if writes to me saying that he needs to be unsubscribed, I can't easily locate his subscription if it's under . Any idea on how to do this? -- Fil From claw at kanga.nu Thu Jul 15 16:41:22 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jul 15 16:41:31 2004 Subject: [Mailman-Developers] interface dreams In-Reply-To: Message from Fil of "Thu, 15 Jul 2004 15:59:24 +0200." <20040715135923.GI24700@rezo.net> References: <20040715135923.GI24700@rezo.net> Message-ID: <18499.1089902482@kanga.nu> On Thu, 15 Jul 2004 15:59:24 +0200 fil wrote: > However there's something that could be very useful, that would be > "search fuzzy matches", for instance if writes to > me saying that he needs to be unsubscribed, I can't easily locate his > subscription if it's under . Any idea on how to do > this? When I used to do this it was by a grep against list_members ala $ list_members foo | grep -i "^name@.*dom\\.ain\\$" However a few too many cases of name@xxx.dom.ain turning out to represent a different human from name@yyy.dom.ain persuaded me that this was a Really Bad Idea. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From dgc at uchicago.edu Thu Jul 15 17:59:53 2004 From: dgc at uchicago.edu (David Champion) Date: Thu Jul 15 17:59:59 2004 Subject: [Mailman-Developers] Re: interface dreams In-Reply-To: <20040715135923.GI24700@rezo.net> References: <20040715135923.GI24700@rezo.net> Message-ID: <20040715155953.GD24127@dust.uchicago.edu> * On 2004.07.15, in <20040715135923.GI24700@rezo.net>, * "Fil" wrote: > > As a list admin, I dream of a roster interface that would help me go fast > when I have 10 people to subscribe and 10 to remove because they don't know > better than "Reply"-ing to me. > > I can make it up with php, with a box for search, another for "add users", > another for "remove users", and so on ("change address"). > > However there's something that could be very useful, that would be "search > fuzzy matches", for instance if writes to me saying > that he needs to be unsubscribed, I can't easily locate his subscription if > it's under . Any idea on how to do this? This isn't very webby, but we use it a lot. (With 2500 lists, it really helps deal with those "please remove me from your list" messages.) It's probably terrible python, but it does the job. usage: /opt/bin/grep_members.py [!] regex [list [...]] /opt/bin/grep_members.py [!] = address [list [...]] In your example, I might do: % grep_members.py bean listname Or, to find all lists that mr.bean is on: % grep_members.py bean The second form is to find a precise match among the specified lists, or among all lists. It also DTRT if called as grep_owners.py instead. -- -D. dgc@uchicago.edu NSIT::ENSS -------------- next part -------------- #!/opt/bin/python ## ## $Id: grep_members.py,v 1.6 2003/07/11 01:10:38 dgc Exp $ ## ## grep_members.py greps owners instead of members if argv[0] ## contains "owner". ## import sys import getopt import string import mailman import re from Mailman.MailList import MailList from Mailman.Utils import list_names self = sys.argv[0] members = {} r = None s = None i = 1 check_owners = 0 # otherwise, members show_all = 0 invert = 0 errors = 0 if len(sys.argv) == 1 or sys.argv[1] == "-h" or sys.argv[1] == "--help": print "usage: %s [!] regex [list [...]]" % (sys.argv[0]) print " %s [!] = address [list [...]]" % (sys.argv[0]) sys.exit(4) if (re.search("owner", sys.argv[0])): check_owners = 1 if sys.argv[i] == "!" or sys.argv[1] == '-': invert = 1 i = i + 1 if sys.argv[i] == "=": s = sys.argv[i+1] i = i + 2 elif sys.argv[i] == ".": show_all = 1 i = i + 1 else: r = re.compile(sys.argv[i], re.IGNORECASE) i = i + 1 if len(sys.argv) > i: names = sys.argv[i:] else: names = list_names() names.sort() if (invert and show_all): sys.exit(0) # ! . is no matches all the time for lname in names: try: m = MailList(lname, lock=0) except: print "%s: no list named %s" % (sys.argv[0], lname) errors = 1 continue if (check_owners): namelist = m.owner else: namelist = m.members.keys() + m.digest_members.keys() namelist.sort() for name in namelist: if (show_all): print lname + ": " + name elif (r == None): # use string matching if (invert ^ (name == s)): print lname + ": " + name else: # use regex matching if (r.search(name)): didmatch = 1 else: didmatch = 0 if (invert ^ didmatch): print lname + ": " + name if errors: sys.exit(10) sys.exit(0) From fehwalker at gmail.com Thu Jul 15 21:13:05 2004 From: fehwalker at gmail.com (Bryan Fullerton) Date: Thu Jul 15 21:13:09 2004 Subject: [Mailman-Developers] interface dreams In-Reply-To: <20040715135923.GI24700@rezo.net> References: <20040715135923.GI24700@rezo.net> Message-ID: <35de0c300407151213704dbdcb@mail.gmail.com> On Thu, 15 Jul 2004 15:59:24 +0200, Fil wrote: > > However there's something that could be very useful, that would be "search > fuzzy matches", for instance if writes to me saying > that he needs to be unsubscribed, I can't easily locate his subscription if > it's under . Any idea on how to do this? The Find Member function on the Membership List admin page supports regex, which is likely as fuzzy as you'll get without hacking your own stuff on. If you searched on bean, or even more precisely bean@.*rezo.net, you should get back either address. There's also ~mailman/bin/find_members for site admins, which will do similar matches across some or all lists on a machine. Useful for dealing with users who can't read and insist on sending "TAKE ME OFF YOUR LIST!11!11" messages to majordomo-owner on the 1st of each month. Bryan From John.Airey at rnib.org.uk Fri Jul 16 11:36:17 2004 From: John.Airey at rnib.org.uk (John.Airey@rnib.org.uk) Date: Fri Jul 16 11:37:43 2004 Subject: [Mailman-Developers] interface dreams Message-ID: <9B66BBD37D5DD411B8CE00508B69700F05ADE22D@pborolocal.rnib.org.uk> > -----Original Message----- > From: Bryan Fullerton [mailto:fehwalker@gmail.com] > Sent: Thursday, 15 July 2004 20:13 > To: Mailman Developers > Subject: Re: [Mailman-Developers] interface dreams > > > On Thu, 15 Jul 2004 15:59:24 +0200, Fil wrote: > > > > However there's something that could be very useful, that > would be "search > > fuzzy matches", for instance if writes > to me saying > > that he needs to be unsubscribed, I can't easily locate his > subscription if > > it's under . Any idea on how to do this? > > The Find Member function on the Membership List admin page supports > regex, which is likely as fuzzy as you'll get without hacking your own > stuff on. If you searched on bean, or even more precisely > bean@.*rezo.net, you should get back either address. > > There's also ~mailman/bin/find_members for site admins, which will do > similar matches across some or all lists on a machine. Useful for > dealing with users who can't read and insist on sending "TAKE ME OFF > YOUR LIST!11!11" messages to majordomo-owner on the 1st of each month. > You mean mailman-owner I hope. I get it all the time. Fortunately we don't have big lists and our biggest list (5000+) just left. However, I suspect they'll be back when they realise that their external service is pants. -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey@rnib.org.uk I don't know which is worse. The makers of soap operas thinking they portray real life or those that watch them thinking it is real life! -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk From brad.knowles at skynet.be Sat Jul 17 02:35:17 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Jul 17 02:35:26 2004 Subject: [Mailman-Developers] New command-line tool... Message-ID: Folks, A modified version of the "discard" tool has been created and uploaded to . I believe that this may be useful for other sites who run command-line-only mailing lists. If there is sufficient interest in this tool and people think that this is useful, I'll be glad to create an entry for it in the FAQ and to make an appropriate announcement on the mailman-users mailing list. Either way, I'd be interested to hear any comments anyone may have regarding this tool. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From dgc at uchicago.edu Sat Jul 17 02:55:03 2004 From: dgc at uchicago.edu (David Champion) Date: Sat Jul 17 02:55:10 2004 Subject: [Mailman-Developers] Re: New command-line tool... In-Reply-To: References: Message-ID: <20040717005503.GF2823@dust.uchicago.edu> * On 2004.07.16, in , * "Brad Knowles" wrote: > > A modified version of the "discard" tool has been created and > uploaded to > . > I believe that this may be useful for other sites who run command-line-only > mailing lists. I don't have a new-enough mailman to judge this, and I don't see a link for the full version of it at SF. But it sounds similar to my bulk-vette script. If there's anything additional there, and anyone wants to make it work with a current Mailman, have at it. We use this mostly when a list admin has been negligent of pending posts and he or a replacement admin wants the admindb cleared. Is that a parallel function? http://home.uchicago.edu/~dgc/sw/mailman/bulk-vette.py -- -D. dgc@uchicago.edu NSIT::ENSS From brad.knowles at skynet.be Sat Jul 17 03:01:19 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Jul 17 03:02:50 2004 Subject: [Mailman-Developers] Re: New command-line tool... In-Reply-To: <20040717005503.GF2823@dust.uchicago.edu> References: <20040717005503.GF2823@dust.uchicago.edu> Message-ID: At 7:55 PM -0500 2004-07-16, David Champion wrote: > I don't have a new-enough mailman to judge this, and I don't see a link > for the full version of it at SF. You missed the download link at ? > But it sounds similar to my bulk-vette > script. If there's anything additional there, and anyone wants to make > it work with a current Mailman, have at it. I haven't heard of your bulk-vette script. Is it also on SourceForge? > We use this mostly when a list admin has been negligent of pending posts > and he or a replacement admin wants the admindb cleared. Is that a > parallel function? This is a case where the admin of the list server is frequently unable to log into the web interface to manage the mailing lists, partly due to some performance bugs in the older version of mailman he's using that have been addressed in more recent versions, and partly due to the size and configuration of the server relative to the number of subscribers and amount of traffic he's doing. By using the command-line tool he's now hacked together, he can get a lot of his list admin work done without hitting the web interface. > http://home.uchicago.edu/~dgc/sw/mailman/bulk-vette.py I'll point this one out to him. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From dgc at uchicago.edu Sat Jul 17 03:10:50 2004 From: dgc at uchicago.edu (David Champion) Date: Sat Jul 17 03:10:54 2004 Subject: [Mailman-Developers] Re: New command-line tool... In-Reply-To: References: <20040717005503.GF2823@dust.uchicago.edu> Message-ID: <20040717011050.GG2823@dust.uchicago.edu> * On 2004.07.16, in , * "Brad Knowles" wrote: > At 7:55 PM -0500 2004-07-16, David Champion wrote: > > > I don't have a new-enough mailman to judge this, and I don't see a link > > for the full version of it at SF. > > You missed the download link at > ? I see a download link for a diff, but I can't tell from that whether it implements the same functions. Sorry for the confusion. > I haven't heard of your bulk-vette script. Is it also on > SourceForge? No, I've mostly been keeping to myself for the past couple of years; it seems nobody generally has much use anymore for someone still running 1.0. But it sounded like this might be useful to someone. > By using the command-line tool he's now hacked together, he can > get a lot of his list admin work done without hitting the web > interface. We have cases often enough where it would take measurable time to vette the admindb via the web -- anywhere from a couple of minutes to an hour or more, in some cases. Bulk-vette takes seconds. So the rationale is the same, even if the cause is different. -- -D. dgc@uchicago.edu NSIT::ENSS From jbglaw at lug-owl.de Sat Jul 17 14:25:38 2004 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Sat Jul 17 14:25:40 2004 Subject: [Mailman-Developers] Pre-select defer/accept/discard/reject for all mails Message-ID: <20040717122538.GO2019@lug-owl.de> Hi! I'm managing some Mailman based lists and get "some" spam each day. Actually, > 95% of all emails kept for being revised is Spam, and it takes some time to navigate through all of them and click on their "discard" radio button. But changing the default from "defer" to "discard" isn't all that wise either, it may break other people's setup horribly. That is why I thought about having a small table ontop with the four chooses, which fire up a JScript to equally check the radio buttons for all mails in this admindb session. However, I'm not really a Python (nor a JavaScript) hacker, so I've only done that on the emitted HTML code. But maybe you get the idea and can integrate that into Mailman at some day or the other. It would save me quite some time a day:) I'll attach a patch (but only for the HTLM code, if you like the idea, you'll need to figure out where to place that into the .py scripts), the outline is like this: - Have a small JavaScript in the HTLM HEAD area that chooses the appropriate radio box. - Have an additional small FORM (w/o submit button or the like, only to have one more radio button list) to choose defer/accept/reject/discard. - Spend a name for the hugh FORM (containing all moderated emails) to be able to access it from inside the JavaScript. I'm not a JavaScript expert (in fact, I made this by trial and error, so for sure this can be done more elegant:) please don't blame for that... --- mail.html 2004-07-16 23:52:30.000000000 +0200 +++ mail2.html 2004-07-17 14:21:35.000000000 +0200 @@ -4,6 +4,38 @@ Linux Administrative Database +

Administrative requests for mailing list: Linux

This page contains a summary of the current set of administrative @@ -21,7 +53,27 @@

You can also view the details of all held postings. -

+ +

However, you can do moderation pre-discard all emails here + and accept some later on: + + + + + + + + + + + + + +
DeferAcceptRejectDiscard
+

+
+ +
MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040717/894751a6/attachment.pgp From brad.knowles at skynet.be Sat Jul 17 15:15:27 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Jul 17 15:16:21 2004 Subject: [Mailman-Developers] Pre-select defer/accept/discard/reject for all mails In-Reply-To: <20040717122538.GO2019@lug-owl.de> References: <20040717122538.GO2019@lug-owl.de> Message-ID: At 2:25 PM +0200 2004-07-17, Jan-Benedict Glaw wrote: > I'm not a JavaScript expert (in fact, I made this by trial and error, so > for sure this can be done more elegant:) please don't blame for that... For those who are interested, my understanding is that these issues can also be handled via the "dispose" command-line tool that I recently mentioned here, or the "bulk-vette" program that David Champion recently mentioned. See the archives of the mailman-developers list for more information. Also note that you can incorporate anti-spam/anti-virus filtering programs such as SpamAssassin into your MTA or called via procmail before delivery to Mailman, and then use Mailman's built-in spam processing features to automatically detect and toss the majority of the spam you get. See the Mailman FAQ for more information on these alternative methods. Please note that I'm not saying that what you've provided here is not useful. Indeed, I think that this is a good idea for a web-oriented way to handle the same sorts of things as the "dispose" or "bulk-vette" scripts, and I think it's good to have multiple different ways to solve the same problems. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jbglaw at lug-owl.de Sat Jul 17 16:19:32 2004 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Sat Jul 17 16:19:34 2004 Subject: [Mailman-Developers] Pre-select defer/accept/discard/reject for all mails In-Reply-To: References: <20040717122538.GO2019@lug-owl.de> Message-ID: <20040717141932.GP2019@lug-owl.de> On Sat, 2004-07-17 15:15:27 +0200, Brad Knowles wrote in message : > At 2:25 PM +0200 2004-07-17, Jan-Benedict Glaw wrote: > > I'm not a JavaScript expert (in fact, I made this by trial and error, so > > for sure this can be done more elegant:) please don't blame for that... > > Also note that you can incorporate anti-spam/anti-virus filtering > programs such as SpamAssassin into your MTA or called via procmail > before delivery to Mailman, and then use Mailman's built-in spam > processing features to automatically detect and toss the majority of > the spam you get. Already done:) If that wasn't done, I couldn't do much work besides throwing away spam all the day! > Indeed, I think that this is a good idea for a web-oriented way > to handle the same sorts of things as the "dispose" or "bulk-vette" > scripts, and I think it's good to have multiple different ways to > solve the same problems. As I said, that's just my idea for a (IMHO good) extension of the web frontend. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040717/84453959/attachment.pgp From marc_news at merlins.org Sat Jul 17 17:25:34 2004 From: marc_news at merlins.org (Marc MERLIN) Date: Sat Jul 17 17:25:37 2004 Subject: [Mailman-Developers] membership list count in headers? Message-ID: <20040717152534.GG8315@merlins.org> I got a request for adding the membership count of a list as a header of each message posted, in order to remind posters how many people's time they are potentially wasting :) https://mailmanhost/mailman/admin/misc-mv/?VARHELP=nondigest/msg_header doesn't seem to show such a variable Is there on that is hidden, or could that be added to the wish list? Thanks Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. 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 terri at zone12.com Sat Jul 17 22:32:07 2004 From: terri at zone12.com (Terri Oda) Date: Sat Jul 17 22:31:09 2004 Subject: [Mailman-Developers] Pre-select defer/accept/discard/reject for all mails In-Reply-To: <20040717122538.GO2019@lug-owl.de> References: <20040717122538.GO2019@lug-owl.de> Message-ID: <5F386FB0-D830-11D8-B97F-000D934FBF38@zone12.com> On Jul 17, 2004, at 8:25 AM, Jan-Benedict Glaw wrote: > I'm managing some Mailman based lists and get "some" spam each day. > Actually, > 95% of all emails kept for being revised is Spam, and it > takes some time to navigate through all of them and click on their > "discard" radio button. But changing the default from "defer" to > "discard" isn't all that wise either, it may break other people's setup > horribly. That is why I thought about having a small table ontop with > the four chooses, which fire up a JScript to equally check the radio > buttons for all mails in this admindb session. I love the idea, since this question comes up pretty frequently (link to FAQ and contents of that entry below). This sounds a little nicer than the checkbox we've got in 2.1.5 (again, see below), but is Javascript going to be more of a pain to support? FAQ Entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.026.htp "3.26. Is there an easy way to discard all messages waiting to be reviewed? If you have a list where non members can post but their messages are moderated, you'll have to deal with a lot of spam. After sometime, just a small percentage of them will be good posts. It's boring to click to discard each messages. A better solution is to approve the good ones, and use a javascript link to mark to discard all. First, open your bookmark manager and add the following link as an URL: javascript:var el=document.forms[0].elements;for (var i=0; i References: <20040717122538.GO2019@lug-owl.de> <5F386FB0-D830-11D8-B97F-000D934FBF38@zone12.com> Message-ID: <20040718084353.GZ2019@lug-owl.de> On Sat, 2004-07-17 16:32:07 -0400, Terri Oda wrote in message <5F386FB0-D830-11D8-B97F-000D934FBF38@zone12.com>: > On Jul 17, 2004, at 8:25 AM, Jan-Benedict Glaw wrote: > >I'm managing some Mailman based lists and get "some" spam each day. > >Actually, > 95% of all emails kept for being revised is Spam, and it > >takes some time to navigate through all of them and click on their > >"discard" radio button. But changing the default from "defer" to > >"discard" isn't all that wise either, it may break other people's setup > >horribly. That is why I thought about having a small table ontop with > >the four chooses, which fire up a JScript to equally check the radio > >buttons for all mails in this admindb session. > > I love the idea, since this question comes up pretty frequently (link > to FAQ and contents of that entry below). > > This sounds a little nicer than the checkbox we've got in 2.1.5 (again, > see below), but is Javascript going to be more of a pain to support? For now, my personal opinion is that it isn't really hard to support. If the user has JS activated, he'll get a bonus of saved time here, if not, everything works as it did yesterday. The script I posted is made up so that it can easily be bend to work for other layout of input boxes, as long as all mails get an equal number of input fields. For sure, there are even better methods to do that, but I'm not a JS expert at all:) > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.026.htp > First, open your bookmark manager and add the following link as an URL: > > javascript:var el=document.forms[0].elements;for (var i=0; > i void(el[i].checked=true); That'd work, too, but (German wording, don't know an equivalent English message) that's "durch die Brust in's Auge geschossen". > For Mailman 2.1.5, we find the following update which is mentioned in > the mailman-2.1.5/NEWS file: > > - The admindb page has a checkbox that allows you to discard all > held > messages that are marked Defer. On heavy lists with lots of spam > holds, > this makes clearing them much faster." So you first approve all legitimate emails, get a new legitimate email and discard all spam inclusive the last legitimate mail you just got. Don't really like that idea because of that li'l race... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040718/a3dc6b40/attachment.pgp From my at freexp.de Sun Jul 18 15:55:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Sun Jul 18 16:09:42 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? Message-ID: <9D77G8sKpwB@my.freexp.de> Hi, we are encountering the following "problem" with Mailman 2.1.3: When a subscriber sends a message to one of our lists with an UTF-8 encoded body and CTE "8bit", Mailman obviously recodes the body from "8bit" to "base64" before distributing the mail to the subscribers of the respective list. Although this is perfectly legal it does not really make sense and also creates sometimes hassles for users with MUAs which have difficulties with base64 encoded bodies. A qp-encoding would IMO be more appropriate for text/plain bodies, but I would prefer if Mailman would not recode the body at all. Three strange things in this context: 1. In the Pipermail archive, the message appears in its original "8bit" format. 2. We are using the mail<=>news facility of Mailman, and the newsgroup users are also receiving the message in the original "8bit" format. 3. We have one (non-public) admin mailing list where Mailman does *not* recode the body. This particular list is also *not* gated to a newsgroup (and this is the only difference to all of the other lists we are currently aware of). Any idea or suggestion what might be the reason for the recoding and how we could avoid it? Michael From terri at zone12.com Sun Jul 18 17:23:05 2004 From: terri at zone12.com (Terri Oda) Date: Sun Jul 18 17:22:06 2004 Subject: [Mailman-Developers] Pre-select defer/accept/discard/reject for all mails In-Reply-To: <20040718084353.GZ2019@lug-owl.de> References: <20040717122538.GO2019@lug-owl.de> <5F386FB0-D830-11D8-B97F-000D934FBF38@zone12.com> <20040718084353.GZ2019@lug-owl.de> Message-ID: <5DED2250-D8CE-11D8-B97F-000D934FBF38@zone12.com> On Jul 18, 2004, at 4:43 AM, Jan-Benedict Glaw wrote: >> For Mailman 2.1.5, we find the following update which is mentioned in >> the mailman-2.1.5/NEWS file: >> - The admindb page has a checkbox that allows you to discard all >> held >> messages that are marked Defer. On heavy lists with lots of >> spam >> holds, this makes clearing them much faster." > So you first approve all legitimate emails, get a new legitimate email > and discard all spam inclusive the last legitimate mail you just got. > > Don't really like that idea because of that li'l race... Well, you *could* do it that way... but I would assume that people go through the list, mark all the ones they want to accept/reject, then hit the checkbox so the others are discarded. No race. Terri From listas at hipercortex.com Sun Jul 18 19:00:05 2004 From: listas at hipercortex.com (Felipe Fonseca / izq) Date: Sun Jul 18 19:00:14 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces (Ian Bicking) In-Reply-To: <20040715100039.61EE61E4036@bag.python.org> References: <20040715100039.61EE61E4036@bag.python.org> Message-ID: > 2. Alternate user (and admin) interfaces (Ian Bicking) > 3. Re: Alternate user (and admin) interfaces (Fil) > 4. Re: Alternate user (and admin) interfaces (Adam Steer) > 5. Re: Alternate user (and admin) interfaces (Thomas Hochstein) > 6. Relocating a list (Nigel Metheringham) > 7. Re: Relocating a list (Brad Knowles) > > I've been searching around for people's experiences implementing > alternate web interfaces for Mailman, but I've been surprised not to > find much. I was thinking about a full frontend redesign for discussion lists using mailman, perhaps integrated to a CMS like xoops or alike, allowing people to: * post to the mailing list, fetching the username and sender email with the cms user base. * display list archives using the same layout formatting as the rest of a cms-maintained website. * reply to any message from the list * manage mailing lists: display, subscribe, choose digest mode, unsubscribe, from each available list * search inside the archives. All of it with an integrated, object-oriented, interface design; Yeah, guess I'm trying to create a free egrous.com. Anyone interested? I'm not a coder, so can't do much about it. ffff From Dale at Newfield.org Sun Jul 18 19:26:15 2004 From: Dale at Newfield.org (Dale Newfield) Date: Sun Jul 18 19:26:18 2004 Subject: [Mailman-Developers] Pre-select defer/accept/discard/reject for all mails In-Reply-To: <20040718084353.GZ2019@lug-owl.de> References: <20040717122538.GO2019@lug-owl.de> <5F386FB0-D830-11D8-B97F-000D934FBF38@zone12.com> <20040718084353.GZ2019@lug-owl.de> Message-ID: On Sun, 18 Jul 2004, Jan-Benedict Glaw wrote: > So you first approve all legitimate emails, get a new legitimate email > and discard all spam inclusive the last legitimate mail you just got. > > Don't really like that idea because of that li'l race... I agree. From a user interface perspective, there should be a direct and chronologically linked connection between decisions made and actions that result. The descisions to be made right now are "which of these are worth letting through right now" "which of these do I need to come back to to decide upon later" "which of these do I know right now I want to reject" "which of these do I know right now I want to discard". I haven't looked at the code, so I don't know this will necessarily work, but I bet we could start off that set of radio buttons in none of the states without diseffecting the server-side processing. I propose that we leave the same 4 radio buttons, but have 4 corresponding selections at the bottom for Do THIS (for the four values of THIS: Defer, Accept, Reject, Discard) to all unmarked ones. (or correspondingly at the top "default all answers to THIS.) This makes all the decisions immediate. As you look at an entry, you decide what it's fate should be. Depending on your list you might want any of the actions to happen to "most" messages, and only pick out the oddballs for other actions. It prevents there being potential for other messages coming in inbetween two loads of the page and painting that new message with the wide brush reserved for spam or whatever category you're sweeping with this time via javascript. I propose two ways this can work, and it will work whether or not people have javascript turned on. The buttons at the top/bottom can be javascript that flips all the other radio buttons into the same position (assuming they still are in the "none" default state), and is itself submitted so the python code can know what the user expected the default to be. So the javascript is just making the decision that the python code will already make visible to the end user immediately. This is very similar to what we already have in 2.1.5. Basically I would just expand the "Discard all messages marked Defer" checkbox into a whole additional section with all the choices that can be made for any--this then turns into a "set everything to THIS" global section. So one could do anything from forwarding all messages to someone or banning all posters represented from subscribing to the list. Any decision that can be made on an individual basis can now be made globally (for all the messages/posters/etc. currently presented as being in the admindb). -Dale From claw at kanga.nu Sun Jul 18 21:10:54 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Jul 18 21:10:57 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces (Ian Bicking) In-Reply-To: Message from "Felipe Fonseca / izq" of "Sun, 18 Jul 2004 14:00:05 -0300." References: <20040715100039.61EE61E4036@bag.python.org> Message-ID: <6317.1090177854@kanga.nu> On Sun, 18 Jul 2004 14:00:05 -0300 (BRT) Felipe Fonseca > wrote: > I was thinking about a full frontend redesign for discussion lists > using mailman, perhaps integrated to a CMS like xoops or alike, > allowing people to: ZMailman? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From listas at hipercortex.com Sun Jul 18 22:56:05 2004 From: listas at hipercortex.com (Felipe Fonseca / izq) Date: Sun Jul 18 22:56:07 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces (Ian Bicking) In-Reply-To: <6317.1090177854@kanga.nu> References: <20040715100039.61EE61E4036@bag.python.org> <6317.1090177854@kanga.nu> Message-ID: Good. But I don`t like zope that much... f > On Sun, 18 Jul 2004 14:00:05 -0300 (BRT) > Felipe Fonseca > wrote: > > > I was thinking about a full frontend redesign for discussion lists > > using mailman, perhaps integrated to a CMS like xoops or alike, > > allowing people to: > > ZMailman? From adam.steer at alia.org.au Mon Jul 19 03:31:23 2004 From: adam.steer at alia.org.au (Adam Steer) Date: Mon Jul 19 03:27:30 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces(Ian Bicking) Message-ID: How about CMS independence? An option in MM to say 'leave the interface to some other things, and just do the mail and DB management'? Fil [from rezo.net] - I'm interested in your PHP/Mailman widget - I've never had any success getting PHP and Python to play together, but them I don't really expect too - or just don't know enough... Cheers Adam. -- Adam Steer Web publishing officer Australian Library and Information Association adam.steer@alia.org.au http://alia.org.au +61 2 6215 8234 >>> "Felipe Fonseca / izq" - 19/7/04 6:56 AM >>> Good. But I don`t like zope that much... f > On Sun, 18 Jul 2004 14:00:05 -0300 (BRT) > Felipe Fonseca > wrote: > > > I was thinking about a full frontend redesign for discussion lists > > using mailman, perhaps integrated to a CMS like xoops or alike, > > allowing people to: > > ZMailman? _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/adam.steer%40alia.org.au From claw at kanga.nu Mon Jul 19 04:58:23 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jul 19 04:58:33 2004 Subject: [Mailman-Developers] Alternate user (and admin) interfaces(Ian Bicking) In-Reply-To: Message from "Adam Steer" of "Mon, 19 Jul 2004 11:31:23 +1000." References: Message-ID: <7759.1090205903@kanga.nu> On Mon, 19 Jul 2004 11:31:23 +1000 Adam Steer wrote: > How about CMS independence? An option in MM to say 'leave the > interface to some other things, and just do the mail and DB > management'? There's nothing that mandates you use Mailman's web UI. You're free to replace it with anything else that appropriately modifies the various config files. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chris at jellybaby.net Mon Jul 19 13:02:30 2004 From: chris at jellybaby.net (Chris Boulter) Date: Mon Jul 19 13:02:34 2004 Subject: [Mailman-Developers] Defaults.py and the build process Message-ID: <20040719110230.GA51481@jellybaby.net> Hi, I've added some settings to 'Defaults.py.in' in the hope that these settings will be reflected in /usr/local/mailman/Mailman/Defaults.py following a configure/make/make install [1]. However, Defaults.py ends up containing only the 'normal' lines, finishing with 'del _'. This happens even if I delete Defaults.py before I run the build. Am I doing something wrong? How does the build process generate Defaults.py? Many thanks, Chris [1] of course, site settings should go in mm_cfg.py. However, I've added some stuff to the standard Mailman code and my new features need some config settings - so these aren't really site settings. -- chris@jellybaby.net From Nigel.Metheringham at dev.intechnology.co.uk Mon Jul 19 13:34:24 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon Jul 19 13:34:26 2004 Subject: [Mailman-Developers] Relocating a list In-Reply-To: References: <1089877607.5059.9.camel@angua.localnet> Message-ID: <1090236864.24791.6.camel@angua.localnet> I didn't get to answering this anywhere near as quickly as Brad responded to my queryy :-( On Thu, 2004-07-15 at 09:31, Brad Knowles wrote: > At 8:46 AM +0100 2004-07-15, Nigel Metheringham wrote: > > In one transition we intend to:- [change everything!] > Out of curiosity, what version of Mailman are you running now, > and will you be upgrading to 2.1.5? We currently run 2.0.13 with a few relatively minor modifications (archive html mods for indexing and MIME attachment blocking). We will be going to 2.1.5 (I see the FreeBSD ports tree is older than that so I guess I will install from source distribution instead). > > The main thing I was wondering about is whether the python saved files > > (ie the list db file etc) will transfer OK, or whether they have > > machine/os/python-version dependencies that will preclude doing things > > this way? > > I would be concerned about the python structures surviving such a > big transition intact. I'd want to have a dump of the list > configuration in a textual form, which could then be re-imported on > the other side. This doesn't have to be done in one huge lump, so I can take stuff across, attempt to take it into the new system and see what happens. Obviously if someone has hard data on how things are likely to break it makes it easier to to take a more direct path to the final solution :-) Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From tkikuchi at is.kochi-u.ac.jp Mon Jul 19 13:41:54 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon Jul 19 13:42:20 2004 Subject: [Mailman-Developers] Defaults.py and the build process In-Reply-To: <20040719110230.GA51481@jellybaby.net> References: <20040719110230.GA51481@jellybaby.net> Message-ID: <40FBB382.5080203@is.kochi-u.ac.jp> > I've added some settings to 'Defaults.py.in' in the hope that these > settings will be reflected in /usr/local/mailman/Mailman/Defaults.py > following a configure/make/make install [1]. However, Defaults.py ends up > containing only the 'normal' lines, finishing with 'del _'. This happens > even if I delete Defaults.py before I run the build. You must run 'configure' to generate new Defaults.py. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From bv at opera.no Mon Jul 19 13:56:19 2004 From: bv at opera.no (=?utf-8?Q?Bj=C3=B8rn_Vermo?=) Date: Mon Jul 19 13:51:59 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <9D77G8sKpwB@my.freexp.de> References: <9D77G8sKpwB@my.freexp.de> Message-ID: On 18 Jul 2004 15:55:00 +0200, Michael Heydekamp wrote: > Hi, > > we are encountering the following "problem" with Mailman 2.1.3: > > When a subscriber sends a message to one of our lists with an UTF-8 > encoded body and CTE "8bit", Mailman obviously recodes the body from > "8bit" to "base64" before distributing the mail to the subscribers of > the respective list. > > Although this is perfectly legal it does not really make sense and also > creates sometimes hassles for users with MUAs which have difficulties > with base64 encoded bodies. A qp-encoding would IMO be more appropriate > for text/plain bodies, but I would prefer if Mailman would not recode > the body at all. > ... Yes, I find it quite annoying when a listserver performs that type of recoding. I find it even worse when it garbles the content because it does not sunderstand the encoding. This is mainly a problem with people who reply to digests. I would prefer to have a configuration option where I could set the outgoing encoding to utf-8 with 8bit cte. Others may want to cater to special local needs. In any case, the digester needs to understand more about encoding. It cannot just pass everything through as now, since it is converting headers to body text. It needs to understand enough about MIME-headers to get subjects and names converted into utf-8, and it needs to understand Punycode to convert international domain names. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From my at freexp.de Mon Jul 19 15:49:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Mon Jul 19 15:50:19 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: References: <9D77G8sKpwB@my.freexp.de> Message-ID: <9DB8cf0ppwB@my.freexp.de> Bj?rn Vermo wrote on 19.07.04: > On 18 Jul 2004 15:55:00 +0200, Michael Heydekamp > wrote: >> we are encountering the following "problem" with Mailman 2.1.3: >> When a subscriber sends a message to one of our lists with an UTF-8 >> encoded body and CTE "8bit", Mailman obviously recodes the body from >> "8bit" to "base64" before distributing the mail to the subscribers >> of the respective list. >> Although this is perfectly legal it does not really make sense and >> also creates sometimes hassles for users with MUAs which have >> difficulties with base64 encoded bodies. A qp-encoding would IMO be >> more appropriate for text/plain bodies, but I would prefer if >> Mailman would not recode the body at all. > Yes, I find it quite annoying when a listserver performs that type of > recoding. Thanks for the support. :) > I find it even worse when it garbles the content because it does not > sunderstand the encoding. This is mainly a problem with people who > reply to digests. In our case digesting is not involved at all and the recoded and distributed mail is technically correct. Nonetheless we don't want to distribute base64 encoded bodies if the original mail was correctly produced and sent as 8bit. It's not clear to me if this behaviour is by design (which I doubt because due to some reason we don't see it in our non-public admin list). If somebody would just answer how to avoid the recoding... > I would prefer to have a configuration option where I could set the > outgoing encoding to utf-8 with 8bit cte. Others may want to cater to > special local needs. In any case, the digester needs to understand > more about encoding. It cannot just pass everything through as now, > since it is converting headers to body text. I've never played with digests, but doesn't Mailman produce digests of type "multipart/digest" with subparts of type "message/rfc822" (see RFC2046)? Michael From Nigel.Metheringham at dev.intechnology.co.uk Mon Jul 19 16:05:15 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon Jul 19 16:05:20 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <9DB8cf0ppwB@my.freexp.de> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> Message-ID: <1090245915.25170.20.camel@angua.localnet> There is one serious problem with sending out 8 bit mail. If the receiving MTA does not advertise 8 bit MIME you have to transcode in the MTA. A few MTAs have decided that buggering about with message bodies like this is not in their purview and therefore do not advertise 8 bit MIME by default since then any mail they relay might then have to be transcoded to 7 bit. A case in point here is exim which does not do MIME transcoding (or body hacking in general). If you do have an 8 bit message, and are trying to send to a non 8 bit recipient MTA, and will not transcode, you then have a problem. You can then either just send it (sod you, take this anyway) or bounce it. For this reason a case could be made for all mail initiators, including MLMs, to encode for 7 bit transport. Its a shame SMTP wasn't originally defined as an 8 bit channel. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From brad.knowles at skynet.be Mon Jul 19 16:21:49 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon Jul 19 16:22:46 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <9DB8cf0ppwB@my.freexp.de> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> Message-ID: At 3:49 PM +0200 2004-07-19, Michael Heydekamp wrote: > It's not clear to me if this behaviour is by design (which I doubt > because due to some reason we don't see it in our non-public admin > list). I've been quiet so far on this issue, because I'm not sure that I can help. However, I'm still not convinced that it's Mailman which is doing the translation, as opposed to your MTA. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From claw at kanga.nu Mon Jul 19 16:26:50 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jul 19 16:26:54 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: Message from Michael Heydekamp of "19 Jul 2004 15:49:00 +0200." <9DB8cf0ppwB@my.freexp.de> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> Message-ID: <25342.1090247210@kanga.nu> On 19 Jul 2004 15:49:00 +0200 Michael Heydekamp wrote: > I've never played with digests, but doesn't Mailman produce digests of > type =22multipart/digest=22 with subparts of type =22message/rfc822 > (see RFC2046)? For MIME digests, yes, but not for text digests. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Mon Jul 19 16:59:16 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jul 19 16:59:20 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: Message from Nigel Metheringham of "Mon, 19 Jul 2004 15:05:15 BST." <1090245915.25170.20.camel@angua.localnet> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> Message-ID: <27792.1090249156@kanga.nu> On Mon, 19 Jul 2004 15:05:15 +0100 Nigel Metheringham wrote: > If you do have an 8 bit message, and are trying to send to a non 8 bit > recipient MTA, and will not transcode, you then have a problem. You > can then either just send it (sod you, take this anyway) or bounce it. Which is particularly pernicious in the case of list servers. Given enough 8bit-bouncing MTAs a single post can unsubscribe a poster. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From Nigel.Metheringham at dev.intechnology.co.uk Mon Jul 19 17:05:46 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon Jul 19 17:05:48 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <27792.1090249156@kanga.nu> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> <27792.1090249156@kanga.nu> Message-ID: <1090249546.25170.55.camel@angua.localnet> On Mon, 2004-07-19 at 15:59, J C Lawrence wrote: > On Mon, 19 Jul 2004 15:05:15 +0100 > Nigel Metheringham wrote: > > > If you do have an 8 bit message, and are trying to send to a non 8 bit > > recipient MTA, and will not transcode, you then have a problem. You > > can then either just send it (sod you, take this anyway) or bounce it. > > Which is particularly pernicious in the case of list servers. Given > enough 8bit-bouncing MTAs a single post can unsubscribe a poster. Maybe I'm not on top form today, but how does the *poster* get unsubscribed in this situation? I can see how recipients behind non-8-bit mail paths could get unsubbed given a number of bounces, but the poster?? Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From chris at jellybaby.net Mon Jul 19 17:06:24 2004 From: chris at jellybaby.net (Chris Boulter) Date: Mon Jul 19 17:06:34 2004 Subject: [Mailman-Developers] Defaults.py and the build process In-Reply-To: <40FBB382.5080203@is.kochi-u.ac.jp> References: <20040719110230.GA51481@jellybaby.net> <40FBB382.5080203@is.kochi-u.ac.jp> Message-ID: <20040719150624.GE51481@jellybaby.net> On Mon 2004-07-19 20:41:54 +0900, Tokio Kikuchi wrote: > >I've added some settings to 'Defaults.py.in' in the hope that these > >settings will be reflected in /usr/local/mailman/Mailman/Defaults.py > >following a configure/make/make install [1]. However, Defaults.py ends up > >containing only the 'normal' lines, finishing with 'del _'. This happens > >even if I delete Defaults.py before I run the build. > > You must run 'configure' to generate new Defaults.py. Well, yes, but I *am* doing that (see above)! -- chris@jellybaby.net From bv at opera.no Mon Jul 19 17:27:32 2004 From: bv at opera.no (=?utf-8?Q?Bj=C3=B8rn_Vermo?=) Date: Mon Jul 19 17:22:07 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <27792.1090249156@kanga.nu> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> <27792.1090249156@kanga.nu> Message-ID: On Mon, 19 Jul 2004 10:59:16 -0400, J C Lawrence wrote: > On Mon, 19 Jul 2004 15:05:15 +0100 > Nigel Metheringham wrote: > >> If you do have an 8 bit message, and are trying to send to a non 8 bit >> recipient MTA, and will not transcode, you then have a problem. You >> can then either just send it (sod you, take this anyway) or bounce it. > > Which is particularly pernicious in the case of list servers. Given > enough 8bit-bouncing MTAs a single post can unsubscribe a poster. > I suppose that is why best practices in this area is to transcode when you connect to something which is not 8-bit clean, but never otherwise. Not doing it might of course be a good way to rid the net of a bit of obsolete software... sites which are not able to be 8-bit clean must be really rare these days. I suppose somebody still has a PDP-8 or something running, and it does have a certain historical interest, but most protocols in wide use today assume an 8-bit clean transmission path. You cannot use http on a 7-bit system, for instance. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From claw at kanga.nu Mon Jul 19 17:26:34 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jul 19 17:26:37 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: Message from J C Lawrence of "Mon, 19 Jul 2004 10:59:16 EDT." <27792.1090249156@kanga.nu> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> <27792.1090249156@kanga.nu> Message-ID: <30031.1090250794@kanga.nu> On Mon, 19 Jul 2004 10:59:16 -0400 J C Lawrence wrote: > On Mon, 19 Jul 2004 15:05:15 +0100 Nigel Metheringham > wrote: >> If you do have an 8 bit message, and are trying to send to a non 8 >> bit recipient MTA, and will not transcode, you then have a problem. >> You can then either just send it (sod you, take this anyway) or >> bounce it. > Which is particularly pernicious in the case of list servers. Given > enough 8bit-bouncing MTAs a single post can unsubscribe a poster. Err, rephrasing so as to actually be correct: Which is particularly pernicious in the cast of list servers. Given an 8bit bouncing MTA upstream of a member (perhaps as a secondary MX) the member can easily find himself unsubscribed without notice. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From my at freexp.de Mon Jul 19 18:14:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Mon Jul 19 18:15:15 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: References: Message-ID: <9DB8t464pwB@my.freexp.de> Brad Knowles wrote on 19.07.04: > At 3:49 PM +0200 2004-07-19, Michael Heydekamp wrote: >> It's not clear to me if this behaviour is by design (which I doubt >> because due to some reason we don't see it in our non-public admin >> list). > I've been quiet so far on this issue, because I'm not sure that I > can help. This seems to be my destiny whenever I'm raising a question here. ;) > However, I'm still not convinced that it's Mailman which is doing the > translation, as opposed to your MTA. Hmm, to my best knowledge Exim is known to not mangle the body at all. Michael From my at freexp.de Mon Jul 19 18:13:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Mon Jul 19 18:15:16 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <1090245915.25170.20.camel@angua.localnet> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> Message-ID: <9DB8slBKpwB@my.freexp.de> Nigel Metheringham wrote on 19.07.04: > There is one serious problem with sending out 8 bit mail. [...] I'm aware of all of these problems but that still doesn't explain ... a) why Mailman recodes the UTF-8 body to base64 rather than qp (which would be the recommended and much better option for text/plain). I suspect that it must have to do something with UTF-8, but I still have to check what Mailman is doing with an 8bit mail in say ISO-8859-1. b) why Mailman does not always do that (as I mentioned, we are not seeing this behaviour with our non-public admin-list). So there must be a way (or a config setting) to prevent Mailman from recoding to base64 - if somebody could just tell me how, pleeez? :) > A case in point here is exim which does not do MIME transcoding (or > body hacking in general). We are indeed using Exim but that applies also to the admin-list. So why the heck are mails to this particular list distributed in 8bit? > For this reason a case could be made for all mail initiators, > including MLMs, to encode for 7 bit transport. Right. That's what I'm doing anyway, but this doesn't apply to all of our subscribers. Michael From my at freexp.de Mon Jul 19 18:12:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Mon Jul 19 18:15:19 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <25342.1090247210@kanga.nu> References: <25342.1090247210@kanga.nu> Message-ID: <9DB8sauKpwB@my.freexp.de> J C Lawrence wrote on 19.07.04: > On 19 Jul 2004 15:49:00 +0200 > Michael Heydekamp wrote: >> I've never played with digests, but doesn't Mailman produce digests >> of type =22multipart/digest=22 with subparts of type >> =22message/rfc822 (see RFC2046)? ^^^ Something's wrong with your qp decoding. > For MIME digests, yes, but not for text digests. Of course not, as multipart/digest is part of the MIME specs. In terms of text digests, I'm not sure what Mailman is doing and what it should do instead. Michael From claw at kanga.nu Mon Jul 19 19:16:16 2004 From: claw at kanga.nu (J C Lawrence) Date: Mon Jul 19 19:16:20 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: Message from Michael Heydekamp of "19 Jul 2004 18:12:00 +0200." <9DB8sauKpwB@my.freexp.de> References: <25342.1090247210@kanga.nu> <9DB8sauKpwB@my.freexp.de> Message-ID: <6334.1090257376@kanga.nu> On 19 Jul 2004 18:12:00 +0200 Michael Heydekamp wrote: > J C Lawrence wrote on 19.07.04: >> On 19 Jul 2004 15:49:00 +0200 Michael Heydekamp >> wrote: > Something's wrong with your qp decoding. Yeah, I disabled it. >> For MIME digests, yes, but not for text digests. > Of course not, as multipart/digest is part of the MIME specs. In > terms of text digests, I'm not sure what Mailman is doing and what it > should do instead. RFC 1153. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From brad.knowles at skynet.be Mon Jul 19 20:37:12 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon Jul 19 20:39:17 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <9DB8t464pwB@my.freexp.de> References: <9DB8t464pwB@my.freexp.de> Message-ID: At 6:14 PM +0200 2004-07-19, Michael Heydekamp wrote: >> However, I'm still not convinced that it's Mailman which is doing the >> translation, as opposed to your MTA. > > Hmm, to my best knowledge Exim is known to not mangle the body at all. In which case, Exim could be a potential reason that might cause unknowing recipients to get unceremoniously tossed off the list. I can't speak for other MTAs, but I know that sendmail can do translation, and will do so by default under certain circumstances (e.g., it has 8-bit input and the output is not indicated as being 8-bit clean). I believe that the same can be said for postfix, and I would have said the same for Exim. This seems to me to be a more MTA-like thing to do, whereas I would expect Mailman to just take whatever it's given and not perform any translation. Have you found actual code within Mailman to perform this translation? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From my at freexp.de Mon Jul 19 22:55:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Mon Jul 19 22:56:02 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: References: Message-ID: <9DB9OssKpwB@my.freexp.de> Brad Knowles wrote on 19.07.04: > At 6:14 PM +0200 2004-07-19, Michael Heydekamp wrote: >>> However, I'm still not convinced that it's Mailman which is doing >>> the translation, as opposed to your MTA. >> Hmm, to my best knowledge Exim is known to not mangle the body at >> all. > In which case, Exim could be a potential reason that might cause > unknowing recipients to get unceremoniously tossed off the list. Which is not really clear to me how that could happen (and which did not happen in real life here), but that's another issue. > I can't speak for other MTAs, but I know that sendmail can do > translation, and will do so by default under certain circumstances > (e.g., it has 8-bit input and the output is not indicated as being > 8-bit clean). I believe that the same can be said for postfix, > and I would have said the same for Exim. Exim is 8bit clean, but AFAIK as an receiving MTA Exim is telling the sending MTA that it is not. Which causes the sending MTA to say "well, then I'll have to recode all 8bit mails". Exim does that because it does not do any recoding on its own. This is what I've been told by folks who know these things better than me. And probably this is the reason why Mailman does also recode 8bit mails upon handing them to Exim (again, but not in the case of our non-public admin list, which is still strange). And I wouldn't even complain if Mailman would use qp encoding rather than base64 encoding. > This seems to me to be a more MTA-like thing to do, whereas I > would expect Mailman to just take whatever it's given and not perform > any translation. Have you found actual code within Mailman to > perform this translation? As this is the Mailman developer's list, I was hoping that the developers would confirm or deny that. ;) And probably point me at the right place in the code. Where should I look? Michael From tkikuchi at is.kochi-u.ac.jp Tue Jul 20 01:28:43 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Jul 20 01:28:57 2004 Subject: [Mailman-Developers] Defaults.py and the build process In-Reply-To: <20040719150624.GE51481@jellybaby.net> References: <20040719110230.GA51481@jellybaby.net> <40FBB382.5080203@is.kochi-u.ac.jp> <20040719150624.GE51481@jellybaby.net> Message-ID: <40FC592B.6030307@is.kochi-u.ac.jp> Chris Boulter wrote: > On Mon 2004-07-19 20:41:54 +0900, Tokio Kikuchi wrote: > >>>following a configure/make/make install [1]. However, Defaults.py ends up >>>containing only the 'normal' lines, finishing with 'del _'. This happens >>>even if I delete Defaults.py before I run the build. >> >>You must run 'configure' to generate new Defaults.py. > > > Well, yes, but I *am* doing that (see above)! > Oh, Yeah. So, you have to check step by step if Defaults.py was upgraded by configure, then make install. ;-) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From nick.vdkloor at for-nation.com Tue Jul 20 13:50:05 2004 From: nick.vdkloor at for-nation.com (Nick vd Kloor @ FOR-Nation) Date: Tue Jul 20 13:50:34 2004 Subject: [Mailman-Developers] Limiting send messages Message-ID: <200407201150.i6KBo5TZ086165@smtp-vbr7.xs4all.nl> Hi all, can anyone tell me how I can force mailman to send a specific number of mails at one time? So that it won't send the whole bunge in one time? Thanx in advance, Nick From brad.knowles at skynet.be Tue Jul 20 14:30:52 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Tue Jul 20 14:31:46 2004 Subject: [Mailman-Developers] Limiting send messages In-Reply-To: <200407201150.i6KBo5TZ086165@smtp-vbr7.xs4all.nl> References: <200407201150.i6KBo5TZ086165@smtp-vbr7.xs4all.nl> Message-ID: At 1:50 PM +0200 2004-07-20, Nick vd Kloor @ FOR-Nation wrote: > can anyone tell me how I can force mailman to send a specific number of > mails at one time? So that it won't send the whole bunge in one time? You can change the source code. Short of that, I don't think there's a way to limit this within Mailman. If this is causing you problems, you may be able to fix this issue within your MTA, or you should work to find a different place to host your mailing lists so that this doesn't cause problems. If you choose to fix this problem from within the MTA, you should go to a mailing list that is specific to your OS and/or MTA. This is not something we can help you with. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From stephen at xemacs.org Thu Jul 22 05:40:28 2004 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu Jul 22 05:40:41 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <9DB8slBKpwB@my.freexp.de> (Michael Heydekamp's message of "19 Jul 2004 18:13:00 +0200") References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> <9DB8slBKpwB@my.freexp.de> Message-ID: <87oem84slv.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Michael" == Michael Heydekamp writes: Michael> I'm aware of all of these problems but that still doesn't Michael> explain ... Michael> a) why Mailman recodes the UTF-8 body to base64 rather Michael> than qp (which would be the recommended and much better Michael> option for text/plain). Probably because the people who wrote the code were Arabic or Korean speakers, where pretty much everything but citation prefixes and line endings is 8-bit. QP is no more recommended than BASE64. QP is preferred if-and-only-if the body would be basically readable in QP, which of course depends on the content. So choosing intelligently would involve a count of the entire part to be encoded. Yuck. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From brad.knowles at skynet.be Thu Jul 22 10:19:07 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jul 22 10:55:21 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: <87oem84slv.fsf@tleepslib.sk.tsukuba.ac.jp> References: <9D77G8sKpwB@my.freexp.de> <9DB8cf0ppwB@my.freexp.de> <1090245915.25170.20.camel@angua.localnet> <9DB8slBKpwB@my.freexp.de> <87oem84slv.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: At 12:40 PM +0900 2004-07-22, Stephen J. Turnbull wrote: > So choosing intelligently would involve a count of the entire part to > be encoded. Yuck. Which is not far from what is done by sendmail when deciding to convert 8bit to either QP or Base64. It doesn't look at the entire bodypart, but it does look at a good-size chunk of the first part, and compare how many characters have the high bit set versus those that don't. If only a very few characters have the high bit set, then it chooses QP. If many of the characters have the high bit set, then it chooses Base64. I'm still not convinced that Mailman is actually doing the conversion here, but there are ways to try to address this subject. As is typical for most open-source projects, patches are welcomed. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From ulisavi at tin.it Thu Jul 22 11:48:37 2004 From: ulisavi at tin.it (ulisavi@tin.it) Date: Thu Jul 22 11:48:29 2004 Subject: [Mailman-Developers] Somebody can help me ? Message-ID: <004d01c46fd1$0fff63e0$02e7fea9@utente> Pardon my english. I'm italian. I would like to allow users of my future sites to create a owner mailing list, by becoming moderator of the list created. With Plesk 7 and Mailman i have the capability to choose a password and to give it to all member of my sites or to all anonymous visitors. With this Password each user can create a New "owner" mailing list and becoming moderator of the mailing list created. The problem is that with this system each user can modify the header and the footer of each message sent and he can choose also to include in the messages sent by mailing list members images and allegates. I will, in fact, that each member can create, in freedom, a "owner mailing list" with this system. It is good. But i hate that each moderator/creator can modify the footer and the header of the messages (pre definite) sent by the owner mailing list created and i do not will that he member insert in the message sent images and allegates but only pure text or external link. I also like to deny the possibility to change the html pages type archive html, member sign up and so on (because i would like to predefine it by myself with my logo and banners). I would like that. ... Each man can create and moderate thier "owner" mailing list created but Not to change the html pages or modify the header and footer of the messages sent and not allow the sending of images or allegates (only text pure and links). Here : http://lists.forum99.com/mailman/create each user with a email address can create a NEW mailing list, by becoming moderotor of the list created. List creator's (authentication) password is : "new" . For example i have just created, using this creator password ("new"), the list : "test22jul04" password of mailing list admin : "tester". http://lists.forum99.com/mailman/admin/test22jul04 password tester The problem is that in the admin panel each administrator can modify "Non-digest options" and "Digest options" (header and footer). He can change the "Content filtering" and he can "Edit the public HTML pages" . THIS IS THE MENU ADMIN : Test22jul04 mailing list administration General Options Section Configuration Categories Other Administrative Activities [General Options] Passwords Language options Membership Management Non-digest options Digest options Privacy options Bounce processing Archiving Options Mail<->News gateways Auto-responder Content filtering Topics Tend to pending moderator requests Go to the general list information page Edit the public HTML pages Go to list archives Logout ----------- IS IT POSSIBLE TO ELIMINATE FROM THE ADMIN MENU THESE VOICES : Non-digest options Digest options Content filtering Edit the public HTML pages And to fix (pre define) it in a configuration file on the server ? On the server i have in the mailgate directory a template directory : /var/mailman/templates/ different file html that i can customize but this general menu is not present. Is it possible to eliminate these voices from the general option admin page ? Or to disable the admin capability to change these 4 voices ? When i have to specify the password in mailman to give it to the user i have to write the command : [root@air421 templates]# /var/mailman/bin/mmsitepass -h This command have also a "list ONLY CREATOR password". The list creator is authorized to create and remove lists, but does not have the total power of the site administrator. Exist a system to disable these voices using this command option ? I have used this option "only creator" but the 4 voices in the menu' continue to exist. .... Somebody can help me to disable these voices from the User Admin Option Menu' ??? Usage: /var/mailman/bin/mmsitepass [options] [password] Options: -c/--listcreator Set the list creator password instead of the site password. The list creator is authorized to create and remove lists, but does not have the total power of the site administrator. -h/--help Print this help message and exit. If password is not given on the command line, it will be prompted for. [root@air421 templates]# From brad.knowles at skynet.be Thu Jul 22 12:04:41 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jul 22 12:05:13 2004 Subject: [Mailman-Developers] Somebody can help me ? In-Reply-To: <004d01c46fd1$0fff63e0$02e7fea9@utente> References: <004d01c46fd1$0fff63e0$02e7fea9@utente> Message-ID: At 11:48 AM +0200 2004-07-22, wrote: > IS IT POSSIBLE TO ELIMINATE FROM THE ADMIN MENU THESE VOICES : > Non-digest options > Digest options > Content filtering > Edit the public HTML pages Sure. You can modify the source code which creates the web admin interface which the list owners would be using. > And to fix (pre define) it in a configuration file on the server ? In a configuration file? No. This is related to the issue of providing extensive customization of outgoing messages, only from the perspective of preventing any kind of customization as opposed to allowing more customization. See also . -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad.knowles at skynet.be Thu Jul 22 15:00:32 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jul 22 15:00:33 2004 Subject: [Mailman-Users] Re: [Mailman-Developers] Somebody can help me ? In-Reply-To: <004d01c46fd1$0fff63e0$02e7fea9@utente> References: <004d01c46fd1$0fff63e0$02e7fea9@utente> Message-ID: <000601c46feb$df31ff50$0100000a@intellecthr.local> At 11:48 AM +0200 2004-07-22, wrote: > IS IT POSSIBLE TO ELIMINATE FROM THE ADMIN MENU THESE VOICES : > Non-digest options > Digest options > Content filtering > Edit the public HTML pages Sure. You can modify the source code which creates the web admin interface which the list owners would be using. > And to fix (pre define) it in a configuration file on the server ? In a configuration file? No. This is related to the issue of providing extensive customization of outgoing messages, only from the perspective of preventing any kind of customization as opposed to allowing more customization. See also . -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ From my at freexp.de Thu Jul 22 19:56:00 2004 From: my at freexp.de (Michael Heydekamp) Date: Thu Jul 22 20:15:54 2004 Subject: [Mailman-Developers] CTE "base64" due to UTF-8? In-Reply-To: References: Message-ID: <9DNEeiq$pwB@my.freexp.de> Brad Knowles wrote on 22.07.04: > At 12:40 PM +0900 2004-07-22, Stephen J. Turnbull wrote: >> So choosing intelligently would involve a count of the entire part >> to be encoded. Yuck. [...] > I'm still not convinced that Mailman is actually doing the > conversion here, [...] I'm suprised that no developer in this developer's list does confirm or deny that (or gives a hint where to look). Michael From jp_mailman at gcfl.net Thu Jul 22 22:56:46 2004 From: jp_mailman at gcfl.net (John Price) Date: Thu Jul 22 22:56:49 2004 Subject: [Mailman-Developers] Piping Mailman's HTML through PHP Message-ID: <20040722205646.GA15921@gcfl.net> I'm far from a Python guru, so that's why I'm asking the developer's list. I want to integrate the Mailman web pages into the rest of my web page, but everything else is PHP. I've seen lots of posts about using PHP with Mailman, but not really any solutions (if I missed it, please point me in the right direction). With that in mind, I thought I'd try to see how to do it myself. All I really need Mailman to do is after it generates it's HTML to pipe the output through /usr/bin/php before sending it to stdout where apache will get it. I have a solution, but I but there's a better way within Mailman. Right now I moved all the programs in /usr/local/mailman/cgi-bin to /usr/local/mailman/cgi-bin.orig, then created shell scripts in cgi-bin that look like this: --- start file: listinfo --- #!/bin/sh ../cgi-bin.orig/listinfo | /usr/bin/php --- end file: listinfo --- That's all there is to it. Now I can add PHP directives in Mailman's HTML code, and they get parsed. Is there a better way? Maybe you good folks could add some hooks into later releases so that the user could specify a "filter" program or something that Mailman will pipe all it's HTML output through. That's all that is needed. Thanx for a great program! - John -- "Cat's motto: No matter what you've done wrong, always try to make it look like the dog did it." -- Unknown http://GCFL.net (The Good, Clean Funnies List): Good, clean funnies five times a week, no ads, for free! From ianb at colorstudy.com Thu Jul 22 23:06:18 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Thu Jul 22 23:07:47 2004 Subject: [Mailman-Developers] Piping Mailman's HTML through PHP In-Reply-To: <20040722205646.GA15921@gcfl.net> References: <20040722205646.GA15921@gcfl.net> Message-ID: <41002C4A.1000700@colorstudy.com> John Price wrote: > I'm far from a Python guru, so that's why I'm asking the > developer's list. > > I want to integrate the Mailman web pages into the rest > of my web page, but everything else is PHP. I've seen > lots of posts about using PHP with Mailman, but not really > any solutions (if I missed it, please point me in the > right direction). > > With that in mind, I thought I'd try to see how to do it > myself. All I really need Mailman to do is after it > generates it's HTML to pipe the output through > /usr/bin/php before sending it to stdout where apache will > get it. > > I have a solution, but I but there's a better way within > Mailman. > > Right now I moved all the programs in > /usr/local/mailman/cgi-bin to > /usr/local/mailman/cgi-bin.orig, then created shell > scripts in cgi-bin that look like this: > > --- start file: listinfo --- > #!/bin/sh > > ../cgi-bin.orig/listinfo | /usr/bin/php > --- end file: listinfo --- > > That's all there is to it. Now I can add PHP directives > in Mailman's HTML code, and they get parsed. > > Is there a better way? That seems pretty reasonable to me, though I've never though about it before. At some point it should be possible in Apache 2 to use PHP as a filter, so that Apache will redirect the output of Mailman to PHP (with a little configuration to that effect, of course). I believe using PHP as a filter is considered experimental now, but hopefully that use will mature. This seems like the best long-term solution -- then your PHP is running in the same environment for Mailman as for your other pages. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From claw at kanga.nu Thu Jul 22 23:58:14 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Jul 22 23:58:19 2004 Subject: [Mailman-Developers] Piping Mailman's HTML through PHP In-Reply-To: Message from John Price of "Thu, 22 Jul 2004 15:56:46 CDT." <20040722205646.GA15921@gcfl.net> References: <20040722205646.GA15921@gcfl.net> Message-ID: <26743.1090533494@kanga.nu> On Thu, 22 Jul 2004 15:56:46 -0500 John Price wrote: > I have a solution, but I but there's a better way within Mailman. SSI and suitable use of CSS can go a lone way. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From fil at rezo.net Fri Jul 23 10:05:50 2004 From: fil at rezo.net (Fil) Date: Fri Jul 23 10:04:46 2004 Subject: [Mailman-Developers] Piping Mailman's HTML through PHP In-Reply-To: <20040722205646.GA15921@gcfl.net> References: <20040722205646.GA15921@gcfl.net> Message-ID: <20040723080550.GC14009@rezo.net> > Right now I moved all the programs in > /usr/local/mailman/cgi-bin to > /usr/local/mailman/cgi-bin.orig, then created shell > scripts in cgi-bin that look like this: > > --- start file: listinfo --- > #!/bin/sh > > ../cgi-bin.orig/listinfo | /usr/bin/php > --- end file: listinfo --- > > That's all there is to it. Now I can add PHP directives > in Mailman's HTML code, and they get parsed. And what if I send an HTML file to your list with php code included? You get a security issue here. Better way in my view is to write a wrapper script in php, that does the graphics and such things, then pushes the web page. You get the wrapper to work in lieu of the cgi by configuring Apache to do so (RewriteRule, or Alias). -- Fil From jp_mailman at gcfl.net Fri Jul 23 19:56:20 2004 From: jp_mailman at gcfl.net (John Price) Date: Fri Jul 23 19:56:24 2004 Subject: [Mailman-Developers] Piping Mailman's HTML through PHP In-Reply-To: <20040723080550.GC14009@rezo.net> References: <20040722205646.GA15921@gcfl.net> <20040723080550.GC14009@rezo.net> Message-ID: <20040723175620.GG13850@gcfl.net> On Fri, Jul 23, 2004 at 10:05:50AM +0200, Fil wrote: > And what if I send an HTML file to your list with php code included? You get > a security issue here. This only applies to the archive viewing scripts, right? It's an easy thing to disable PHP code when displaying user-generated text. Still, you bring up a good point when considering adding this feature to the program. > Better way in my view is to write a wrapper script in php, that does the > graphics and such things, then pushes the web page. You get the wrapper to > work in lieu of the cgi by configuring Apache to do so (RewriteRule, or > Alias). This is an idea. Frames is another. But if you want to have access to the Mailman substitution tags as well as PHP then these ideas don't work. -- "A dog is the only thing on earth that loves you more than he loves himself." -- Josh Billings http://GCFL.net (The Good, Clean Funnies List): Good, clean funnies five times a week, no ads, for free! From fil at rezo.net Fri Jul 23 21:03:14 2004 From: fil at rezo.net (Fil) Date: Fri Jul 23 21:02:01 2004 Subject: [Mailman-Developers] Piping Mailman's HTML through PHP In-Reply-To: <20040723175620.GG13850@gcfl.net> References: <20040722205646.GA15921@gcfl.net> <20040723080550.GC14009@rezo.net> <20040723175620.GG13850@gcfl.net> Message-ID: <20040723190314.GA11435@rezo.net> > > Better way in my view is to write a wrapper script in php, that does the > > graphics and such things, then pushes the web page. You get the wrapper to > > work in lieu of the cgi by configuring Apache to do so (RewriteRule, or > > Alias). > > This is an idea. Frames is another. But if you want to > have access to the Mailman substitution tags as well as > PHP then these ideas don't work. Oh yes it can work: just use and you'll get (through http) the file processed by Mailman's CGI, which you can then process by php. I do that, for example, to generate the list of lists at http://listes.rezo.net/listes.php -- Fil From fthommen at inf.ethz.ch Thu Jul 29 12:47:14 2004 From: fthommen at inf.ethz.ch (Frank Thommen) Date: Thu Jul 29 12:47:23 2004 Subject: [Mailman-Developers] Update MM 2.1.2->2.1.5 fails and no help from mailman-users Message-ID: <4108D5B2.C5902E05@inf.ethz.ch> Dear Mailman developers, I dare to post this problem to mailman-developers, because it is critical to us to solve it. I assume that "code insiders" as you can possibly help in this case. While updating MM from 2.1.2 to 2.1.5 (Mailman stopped, MTA stopped, lock directory cleared manually, Apache stopped, 'check_perms -f' done) the process of updating gets stuck at a specific point. I added a 'print mlist' in 'def update_pending()' after 'for listname in Utils.list_names(): mlist = MailList.MailList(listname)' to know where it happens: ------ # bin/update Upgrading from version 0x20102f0 to 0x20105f0 getting rid of old source files Updating mailing list: XXX [...updates all lists with one "could not acquire lock" message...] Updating Usenet watermarks - nothing to update here Updating Mailman 2.1.4 pending.pck database WARNING: Ignoring duplicate pending ID: 7544. [..warns for many more "pending IDs"..] ------ ...and here the process stalls forever. I ^C-stopped the update several times, but it gets always stuck at the same list. If I nevertheless start 2.1.5, I get around 20 of the following errors; ------ # mailmanctl start Starting Mailman's master qrunner. # Traceback (most recent call last): File "/usr/pack/mailman-2.1.5-inf/bin/qrunner", line 270, in ? main() File "/usr/pack/mailman-2.1.5-inf/bin/qrunner", line 230, in main qrunner.run() File "/usr/pack/mailman-2.1.5-inf/Mailman/Queue/Runner.py", line 70, in run filecnt = self._oneloop() File "/usr/pack/mailman-2.1.5-inf/Mailman/Queue/Runner.py", line 99, in _oneloop msg, msgdata = self._switchboard.dequeue(filebase) File "/usr/pack/mailman-2.1.5-inf/Mailman/Queue/Switchboard.py", line 147, in dequeue data = cPickle.load(fp) EOFError [...] # ------ After that, MM 2.1.5 does not deliver any mails. I can go back to 2.1.2 and mail delivery continues (even for mails posted in the meantime, i.d. when 2.1.5 was running), after having given me a about a dozen errors of the following type: ------ Jun 26 21:43:27 2004 (1204) lost data files for filebase: 1088195523.0786779+4c5e6189f5cc4ba967f1556ffb911c03c84d6174 ------ If I then go back to bin/update, the process stopps within the same procedure as above, but at an other maillist (see above). An other obervation is, that when doing bin/update, I get errors like the following with some maillists: ------ # bin/update [...] Updating mailing list: XXXX Updating the held requests database. - updating old private mbox file looks like you have a really recent CVS installation... you're either one brave soul, or you already ran me - updating old public mbox file - This list looks like it might have <= b4 list templates around Traceback (most recent call last): File "/usr/pack/mailman-2.1.5-inf/bin/update", line 782, in ? errors = main() File "/usr/pack/mailman-2.1.5-inf/bin/update", line 672, in main errors = errors + dolist(listname) File "/usr/pack/mailman-2.1.5-inf/bin/update", line 357, in dolist os.rename(o_tmpl, n_tmpl) OSError: [Errno 2] No such file or directory # ------ After that, bin/update exits and I have to restart it. The next run it will give the error with an other list. This happens three times, so the fourth time bin/update runs through and finally stopps at the error described at the beginning of this posting. I'm running Python 2.2.2 on a Solaris 9 host. Do you need more information to track down this problem? Please reply to my personal address (fthommen@inf.ethz.ch), since I am not member of this list and please be very specific if it comes to coding, as I dont really speak Python. Thanks a lot in advance from me and my 70 maillists :-) frank ---------- Frank Thommen, IT Support Group, D-INFK, ETH Zuerich Mail: fthommen@inf.ethz.ch; Phone: +41-1-63 27208 (Mon-Thu) Web: http://www.isg.inf.ethz.ch ---------- From brad.knowles at skynet.be Thu Jul 29 14:26:51 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Jul 29 14:30:24 2004 Subject: [Mailman-Developers] Update MM 2.1.2->2.1.5 fails and no help from mailman-users In-Reply-To: <4108D5B2.C5902E05@inf.ethz.ch> References: <4108D5B2.C5902E05@inf.ethz.ch> Message-ID: At 12:47 PM +0200 2004-07-29, Frank Thommen wrote: > I'm running Python 2.2.2 on a Solaris 9 host. See and . -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From kasal at ucw.cz Fri Jul 30 15:52:04 2004 From: kasal at ucw.cz (Stepan Kasal) Date: Fri Jul 30 15:51:56 2004 Subject: [Mailman-Developers] a bug in 2.1.5 moderation web interface Message-ID: <20040730135204.GA25980@matsrv.math.cas.cz> Hello, the moderator page "with details" doesn't have a "Submit" button at the top, only at the bottom. This looks weird, as the "Discard all deferred" checkbox is on the top (without the button). I've filed a bugzilla report on sourceforge. I'm not on this list, cc to me, please. Have a nice day, Stepan Kasal From iv.longhi at tiscali.it Fri Jul 30 17:21:06 2004 From: iv.longhi at tiscali.it (iv.longhi@tiscali.it) Date: Fri Jul 30 17:21:10 2004 Subject: [Mailman-Developers] disabling some feature control to list-owners Message-ID: <4104BFCF0000F375@mail-8.tiscali.it> I manage a virtual community and I have installed mailman on my system in order to give the users the ability to create their own lists and manage them by themselves. For this pourpose I think that mailman is almost perfect, but I would like to avoid that list owners be able to change the default for some features, for example because I'm worry about that low skilled people can make changes that can make the list not usable (for example making a invalid host_name, etc.) Is there a way to avoid list owners change those values? Thanx, Ivan __________________________________________________________________ Tiscali ADSL Senza Canone, paga solo quello che consumi! Non perdere la promozione valida fino al 3 agosto. Per te gratis il modem in comodato e l'attivazione. In piu' navighi a soli 1,5 euro l'ora per i primi tre mesi. Cosa aspetti? Attivala subito! http://abbonati.tiscali.it/adsl/prodotti/640Kbps/ From terri at zone12.com Thu Jul 29 17:20:34 2004 From: terri at zone12.com (Terri Oda) Date: Sat Jul 31 02:47:17 2004 Subject: [Mailman-Developers] Update MM 2.1.2->2.1.5 fails and no help from mailman-users In-Reply-To: <4108D5B2.C5902E05@inf.ethz.ch> References: <4108D5B2.C5902E05@inf.ethz.ch> Message-ID: If I recall correctly, Mailman still doesn't always deal gracefully with old pending stuff, so you may have to clear out those files before doing the upgrade (as well as upgrade python, as was already mentioned). This used to be mentioned in the README or INSTALL files, and I'd assume it's still buried in there somewhere, although it's hard to blame you for missing it. From silviu_marin-caea at genesys.ro Fri Jul 9 08:15:41 2004 From: silviu_marin-caea at genesys.ro (Silviu Marin-Caea) Date: Wed Sep 8 23:52:06 2004 Subject: [Mailman-Developers] Major Bug (stop all lists) in mailman 2.0.14 Message-ID: <2940162.1089353739465.SLOX.WebMail.wwwrun@mail.genesys.ro> Upon receiving a message like bellow (and similar messages) that are virus social engineering without the viral payload, mailman, specifically qrunner, chokes for good, and does not deliver any message that follows, on any list. There's the relevant excerpt from error log bellow. I still have the .msg and .db files that, if moved to /var/lib/mailman/qfiles, can reproduce the error, always. They're here: ftp://ftp.genesys.ro/upload/mailman-error System is SUSE Openexchange Server 8, but it happened on SUSE LINUX 8.0 Professional too, which used mailman 2.0.x. From zoltank67@hotmail.com Thu Jun 24 22:42:00 2004 Return-Path: Delivered-To: networking-request@genesys.ro Received: from mail.genesys.ro (localhost [127.0.0.1]) by mail.genesys.ro (Postfix) with ESMTP id 373B96BA85 for ; Thu, 24 Jun 2004 22:42:00 +0300 (EEST) Received: by mail.genesys.ro (Postfix, from userid 65534) id 24F906E21E; Thu, 24 Jun 2004 22:42:00 +0300 (EEST) Received: from hotmail.com (bay8-f8.bay8.hotmail.com [64.4.27.8]) by mail.genesys.ro (Postfix) with ESMTP id D1D926E21A for ; Thu, 24 Jun 2004 22:41:58 +0300 (EEST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Jun 2004 12:41:55 -0700 Received: from 80.97.222.9 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 24 Jun 2004 19:41:55 GMT X-Originating-IP: [80.97.222.9] X-Originating-Email: [zoltank67@hotmail.com] X-Sender: zoltank67@hotmail.com From: "Keresztes Zoltan" To: networking-request@genesys.ro Date: Thu, 24 Jun 2004 22:41:55 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jun 2004 19:41:55.0660 (UTC) FILETIME=[4E4338C0:01C45A23] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.genesys.ro X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=BAYES_01,FROM_ENDS_IN_NUMS autolearn=no version=2.63 X-BitDefender-Scanner: Clean, Agent: BitDefender POSTFIX 1.5.7 on mail confirm 641541 _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Jun 25 13:18:55 2004 qrunner(9964): Traceback (most recent call last): Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/cron/qrunner", line 283, in ? Jun 25 13:18:55 2004 qrunner(9964): kids = main(lock) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/cron/qrunner", line 253, in main Jun 25 13:18:55 2004 qrunner(9964): keepqueued = dispose_message(mlist, msg , msgdata) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/cron/qrunner", line 157, in dispose_message Jun 25 13:18:55 2004 qrunner(9964): mlist.ParseMailCommands(msg) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/Mailman/MailCommand Handler.py", line 163, in ParseMailCommands Jun 25 13:18:55 2004 qrunner(9964): splitsubj = string.split(subject) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/python2.2/string.py", line 117, in split Jun 25 13:18:55 2004 qrunner(9964): return s.split(sep, maxsplit) Jun 25 13:18:55 2004 qrunner(9964): AttributeError : 'NoneType' object has no a ttribute 'split' From silviu_marin-caea at genesys.ro Thu Jul 15 10:35:03 2004 From: silviu_marin-caea at genesys.ro (Silviu Marin-Caea) Date: Wed Sep 8 23:52:08 2004 Subject: [Mailman-Developers] Bug (stop delivery on all lists) in 2.0.14 Message-ID: <449210.1089880499317.SLOX.WebMail.wwwrun@mail.genesys.ro> Upon receiving a message like bellow (and similar messages) that are virus social engineering without the viral payload, mailman, specifically qrunner, chokes for good, and does not deliver any message that follows, on any list. There's the relevant excerpt from error log bellow. I still have the .msg and .db files that, if moved to /var/lib/mailman/qfiles, can reproduce the error, always. They're here: ftp://ftp.genesys.ro/upload/mailman-error System is SUSE Openexchange Server 8, but it happened on SUSE LINUX 8.0 Professional too, which used mailman 2.0.x. From zoltank67@hotmail.com Thu Jun 24 22:42:00 2004 Return-Path: Delivered-To: networking-request@genesys.ro Received: from mail.genesys.ro (localhost [127.0.0.1]) by mail.genesys.ro (Postfix) with ESMTP id 373B96BA85 for ; Thu, 24 Jun 2004 22:42:00 +0300 (EEST) Received: by mail.genesys.ro (Postfix, from userid 65534) id 24F906E21E; Thu, 24 Jun 2004 22:42:00 +0300 (EEST) Received: from hotmail.com (bay8-f8.bay8.hotmail.com [64.4.27.8]) by mail.genesys.ro (Postfix) with ESMTP id D1D926E21A for ; Thu, 24 Jun 2004 22:41:58 +0300 (EEST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Jun 2004 12:41:55 -0700 Received: from 80.97.222.9 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 24 Jun 2004 19:41:55 GMT X-Originating-IP: [80.97.222.9] X-Originating-Email: [zoltank67@hotmail.com] X-Sender: zoltank67@hotmail.com From: "Keresztes Zoltan" To: networking-request@genesys.ro Date: Thu, 24 Jun 2004 22:41:55 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jun 2004 19:41:55.0660 (UTC) FILETIME=[4E4338C0:01C45A23] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.genesys.ro X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=BAYES_01,FROM_ENDS_IN_NUMS autolearn=no version=2.63 X-BitDefender-Scanner: Clean, Agent: BitDefender POSTFIX 1.5.7 on mail confirm 641541 _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Jun 25 13:18:55 2004 qrunner(9964): Traceback (most recent call last): Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/cron/qrunner", line 283, in ? Jun 25 13:18:55 2004 qrunner(9964): kids = main(lock) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/cron/qrunner", line 253, in main Jun 25 13:18:55 2004 qrunner(9964): keepqueued = dispose_message(mlist, msg , msgdata) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/cron/qrunner", line 157, in dispose_message Jun 25 13:18:55 2004 qrunner(9964): mlist.ParseMailCommands(msg) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/mailman/Mailman/MailCommand Handler.py", line 163, in ParseMailCommands Jun 25 13:18:55 2004 qrunner(9964): splitsubj = string.split(subject) Jun 25 13:18:55 2004 qrunner(9964): File "/usr/lib/python2.2/string.py", line 117, in split Jun 25 13:18:55 2004 qrunner(9964): return s.split(sep, maxsplit) Jun 25 13:18:55 2004 qrunner(9964): AttributeError : 'NoneType' object has no a ttribute 'split'