From davidb@chelsea.net Wed Mar 1 17:00:12 2000 From: davidb@chelsea.net (David Birnbaum) Date: Wed, 1 Mar 2000 12:00:12 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders Message-ID: Folks, We just started converting from Majordomo to Mailman and we couldn't be more pleased; thanks for the good work, dear authors. I do have a couple of questions I did not see an answer to in the documentation anywhere, or listed in Jitterbug, though: 1. The password reminders come out from mailman-owner@masterdomain.com instead of list-admin@virtualdomain.com, which caused a lot of confusion for one of our mailing lists hosted on a virtual domain. Is there any way to change that? 2. Bounces are sent to the poor postmaster instead of a -admin address. I'm not entirely certain, but I think an Errors-To: header or something like that in all Mailman messages might allow one to distribute that load somewhat. Alas, I am only a poor, crippled, Perl hacker, or I might take a crack at fixing these two. In any case, thanks, David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... From jim@cosource.com Wed Mar 1 22:26:25 2000 From: jim@cosource.com (Jim Hebert) Date: Wed, 1 Mar 2000 17:26:25 -0500 (EST) Subject: [Mailman-Developers] Posting to 2 lists breaks newsgating for the second one Message-ID: I filed a jitterbug report about this a couple weeks back... Applix is fairly motivated about using mailman for their internal lists but needs the ability to crosspost on the mail side and have it show up in all the right newsgroups too. (If this doesn't make sense, visit the jitterbug report below.) So, I got them to put some money behind the bug report, if someone will fix it: http://www.python.org/mailman-bugs/incoming?id=202;user=guest http://www.cosource.com/cgi-bin/cos.pl/wish/info/295 (Sorry if this is better posted to the -users list, I just joined both lists and don't have a clear sense of which one would have been better...) All in all, we're loving mailman! =) jim [I work for Cosource / Applix.] From Dan Mick Thu Mar 2 03:52:56 2000 From: Dan Mick (Dan Mick) Date: Wed, 1 Mar 2000 19:52:56 -0800 (PST) Subject: [Mailman-Developers] Mailman password and administrative reminders Message-ID: <200003020353.TAA19329@utopia.West.Sun.COM> ? This very message came to me with the following header: Errors-To: mailman-developers-admin@python.org All my bounces come to the list admin address, set in the admin webpage, in the second field of General Options. Do you have that set to something, and bounces still come to root? > 2. Bounces are sent to the poor postmaster instead of a -admin address. > I'm not entirely certain, but I think an Errors-To: header or something > like that in all Mailman messages might allow one to distribute that load > somewhat. From lindsey@ncsa.uiuc.edu Thu Mar 2 05:02:43 2000 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 1 Mar 2000 23:02:43 -0600 (CST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <200003020353.TAA19329@utopia.West.Sun.COM> from "Dan Mick" at Mar 01, 2000 07:52:56 PM Message-ID: <200003020502.XAA00295@glorfindel.ncsa.uiuc.edu> > Errors-To: mailman-developers-admin@python.org > > All my bounces come to the list admin address, set in > the admin webpage, in the second field of General Options. > Do you have that set to something, and bounces still come to root? > > > 2. Bounces are sent to the poor postmaster instead of a -admin address. > > I'm not entirely certain, but I think an Errors-To: header or something > > like that in all Mailman messages might allow one to distribute that load > > somewhat. Errors-To: is way deprecated anyhow... It was intended to supercede the envelope From address for errors, but it violated RFC1123 and was subsequently ignored by many MTAs. Chris ---------------------------------------------------------------------- Christopher Lindsey, Senior System Engineer National Center for Supercomputing Applications (NCSA) From davidb@chelsea.net Thu Mar 2 12:02:20 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 07:02:20 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <200003020353.TAA19329@utopia.West.Sun.COM> Message-ID: Hmm.... It is the administrative messages that don't have this set, I believe. We had a large list (4500 members) that was just converted from majordomo. Our password reminders went out, and about 500 bounces came to postmaster instead of going to the list admin. We're having the auto-bounce feature turn people off, but the list has only been broadcast once, so people haven't been auto-unsubscribed yet (a more agressive unsubcribe might be helpful for these once-a-month broadcast lists, but perhaps I don't have it tuned right.) The message actually sent to the list (ie, the non-administrative stuff) seemed to work properly and bounce to the list owners. BTW - minor bug. Even if you turn password reminders off, the welcome message that's created still says they are sent out. David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Wed, 1 Mar 2000, Dan Mick wrote: > ? This very message came to me with the following header: > > Errors-To: mailman-developers-admin@python.org > > All my bounces come to the list admin address, set in > the admin webpage, in the second field of General Options. > Do you have that set to something, and bounces still come to root? > > > 2. Bounces are sent to the poor postmaster instead of a -admin address. > > I'm not entirely certain, but I think an Errors-To: header or something > > like that in all Mailman messages might allow one to distribute that load > > somewhat. > > From davidb@chelsea.net Thu Mar 2 12:13:55 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 07:13:55 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <200003020353.TAA19329@utopia.West.Sun.COM> Message-ID: Here's the headers for the reminder: Return-Path: Received: from killian.chelsea.net (localhost [127.0.0.1]) by killian.chelsea.net (8.9.3/8.9.3) with ESMTP id FAA15246 for ; Wed, 1 Mar 2000 05:52:23 -0500 (EST) Date: Wed, 1 Mar 2000 05:52:23 -0500 (EST) Message-Id: <200003011052.FAA15246@killian.chelsea.net> From: mailman-owner@chelsea.net Subject: thebody.com mailing list memberships reminder To: ###A USER### X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: The Test List It should be from (I think), thebody-admin@thebody.com, with an Errors-To: header. Not sure why List-Id: is The Test List...that's odd. David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Wed, 1 Mar 2000, Dan Mick wrote: > ? This very message came to me with the following header: > > Errors-To: mailman-developers-admin@python.org > > All my bounces come to the list admin address, set in > the admin webpage, in the second field of General Options. > Do you have that set to something, and bounces still come to root? > > > 2. Bounces are sent to the poor postmaster instead of a -admin address. > > I'm not entirely certain, but I think an Errors-To: header or something > > like that in all Mailman messages might allow one to distribute that load > > somewhat. > > From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Mar 2 13:55:01 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 2 Mar 2000 08:55:01 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders References: <200003020353.TAA19329@utopia.West.Sun.COM> Message-ID: <14526.29365.432370.248009@anthem.cnri.reston.va.us> Here's the problem in a nutshell (if my quick browse of the thread is correct). When a user is to get the password reminder, Mailman collates the passwords for all the lists that the user is on (for that virtual domain, but let's ignore that). So one password reminder refers to potentially several lists. So which list -owner address (e.g. bounce detecting addr) should get the bounces? As I see it, the right solution is the following: - Mailman has no catch-all address like Majordomo has. I.e. you can't send `help' to mailman@... unless you actually craft a normal Mailman list for this addr. This is bogus, because it just thinks it's a normal list, not something special. Step one of the fix is to write scripts that can handle these over-arching addrs. Then of course, we'd make mailman-owner@... the recipient of all the bounced password reminders. The script on the tail of that would Do The Right Thing. - Unfortunately, the correct solution, IMO requires user databases, because otherwise you need to cycle through all the lists looking for the user address to disable. Imagine for a moment, hundreds of bounces coming back starting at 12:02 the first of every month, each one trying to hit every list on your site. Ouch! I've been seriously thinking about adding support for the first bullet for 1.2 (scratching my own itch, doncha know), but I also just want to start getting the betas out, so it may have to wait. Harald's got stuff in the pipeline to support user databases, but that's defiitely a post 1.2 feature. If you wanted to play with this stuff in the meantime, you could implement #1, and see how bad a hit the touch-all-lists approach would be. -Barry From davidb@chelsea.net Thu Mar 2 14:26:05 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 09:26:05 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <14526.29365.432370.248009@anthem.cnri.reston.va.us> Message-ID: Perhaps I'm missing something at the fundamental architecture level, but wouldn't it make more sense to just cycle through each list and send the reminder using the list owner? It's probably nice to only get one password reminder email, but how big and inconvenience would that be, anyway? This way, each user gets one email per list, and if it bounces, you know what list to take it off of. That won't disable the address server wide, but sooner or later some bounces will happen on the other lists and take care of it. This way you don't have to do the user database thing. I have nothing more than anecdotal evidence (ie, my ISP), but how often is one address on multiple lists at a given site? We've had to turn off password notification, because now all the people on this list who got password notifications are now replying to mailman-owner with list related requests. Sigh.... David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Thu, 2 Mar 2000, Barry A. Warsaw wrote: > > Here's the problem in a nutshell (if my quick browse of the thread is > correct). > > When a user is to get the password reminder, Mailman collates the > passwords for all the lists that the user is on (for that virtual > domain, but let's ignore that). So one password reminder refers to > potentially several lists. So which list -owner address (e.g. bounce > detecting addr) should get the bounces? > > As I see it, the right solution is the following: > > - Mailman has no catch-all address like Majordomo has. I.e. you can't > send `help' to mailman@... unless you actually craft a normal > Mailman list for this addr. This is bogus, because it just thinks > it's a normal list, not something special. Step one of the fix is > to write scripts that can handle these over-arching addrs. Then of > course, we'd make mailman-owner@... the recipient of all the bounced > password reminders. The script on the tail of that would Do The > Right Thing. > > - Unfortunately, the correct solution, IMO requires user databases, > because otherwise you need to cycle through all the lists looking > for the user address to disable. Imagine for a moment, hundreds of > bounces coming back starting at 12:02 the first of every month, each > one trying to hit every list on your site. Ouch! > > I've been seriously thinking about adding support for the first bullet > for 1.2 (scratching my own itch, doncha know), but I also just want to > start getting the betas out, so it may have to wait. Harald's got > stuff in the pipeline to support user databases, but that's defiitely > a post 1.2 feature. > > If you wanted to play with this stuff in the meantime, you could > implement #1, and see how bad a hit the touch-all-lists approach would > be. > > -Barry > From secabeen@pobox.com Thu Mar 2 15:29:23 2000 From: secabeen@pobox.com (Ted Cabeen) Date: Thu, 02 Mar 2000 09:29:23 -0600 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: Your message of "Thu, 02 Mar 2000 08:55:01 EST." <14526.29365.432370.248009@anthem.cnri.reston.va.us> Message-ID: <200003021529.JAA08948@entropy.uchicago.edu> In message <14526.29365.432370.248009@anthem.cnri.reston.va.us>, "Barry A. Wars aw" writes: > >Here's the problem in a nutshell (if my quick browse of the thread is >correct). > >When a user is to get the password reminder, Mailman collates the >passwords for all the lists that the user is on (for that virtual >domain, but let's ignore that). So one password reminder refers to >potentially several lists. So which list -owner address (e.g. bounce >detecting addr) should get the bounces? What about sending the messages out with multiple addresses in the From header? It's a little weird, but is RFC legal, and that way each reminder will bounce to all of the lists whose password is listed in the email. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen@pobox.com Check Website or finger for PGP Public Key secabeen@midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen@aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com From Nigel.Metheringham@VData.co.uk Thu Mar 2 15:34:58 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Thu, 02 Mar 2000 15:34:58 +0000 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: Message from Ted Cabeen of "Thu, 02 Mar 2000 09:29:23 CST." <200003021529.JAA08948@entropy.uchicago.edu> Message-ID: secabeen@pobox.com said: > What about sending the messages out with multiple addresses in the > From header? It's a little weird, but is RFC legal, and that way > each reminder will bounce to all of the lists whose password is > listed in the email. Bounces go to the *envelope* sender address not the From: address. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From bwarsaw@cnri.reston.va.us Thu Mar 2 16:10:10 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Thu, 2 Mar 2000 11:10:10 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders References: <14526.29365.432370.248009@anthem.cnri.reston.va.us> Message-ID: <14526.37474.389793.355286@anthem.cnri.reston.va.us> >>>>> "DB" == David Birnbaum writes: DB> I have nothing more than anecdotal evidence (ie, my ISP), but DB> how often is one address on multiple lists at a given site? It all depends. Some sites might run only a few, or mostly unconnected lists. At Python.Org, such a change would cause a revolt :). DB> We've had to turn off password notification, because now all DB> the people on this list who got password notifications are now DB> replying to mailman-owner with list related requests. Sigh.... Yup, I agree, the current situation is suboptimal. It will be fixed, it's just a matter of when. -Barry From davidb@chelsea.net Thu Mar 2 17:18:46 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 12:18:46 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <14526.37474.389793.355286@anthem.cnri.reston.va.us> Message-ID: Revolt among the Python developers would certainly be a bad thing, given they are doing the development ;) Thanks for the help, looking forward to eventual solution. David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Thu, 2 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > >>>>> "DB" == David Birnbaum writes: > > DB> I have nothing more than anecdotal evidence (ie, my ISP), but > DB> how often is one address on multiple lists at a given site? > > It all depends. Some sites might run only a few, or mostly > unconnected lists. At Python.Org, such a change would cause a revolt > :). > > DB> We've had to turn off password notification, because now all > DB> the people on this list who got password notifications are now > DB> replying to mailman-owner with list related requests. Sigh.... > > Yup, I agree, the current situation is suboptimal. It will be fixed, > it's just a matter of when. > > -Barry > From jam@jamux.com Thu Mar 2 17:31:40 2000 From: jam@jamux.com (John A. Martin) Date: Thu, 02 Mar 2000 12:31:40 -0500 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: (Nigel Metheringham; Thu, 02 Mar 2000 15:34:58 +0000) Message-ID: <20000302173143.3426B481D@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nigel" == Nigel Metheringham >>>>> "Re: [Mailman-Developers] Mailman password and administrative reminders" >>>>> Thu, 02 Mar 2000 15:34:58 +0000 Nigel> secabeen@pobox.com said: >> What about sending the messages out with multiple addresses in >> the From header? It's a little weird, but is RFC legal, and >> that way each reminder will bounce to all of the lists whose >> password is listed in the email. Nigel> Bounces go to the *envelope* sender address not the From: Nigel> address. Why not 'X-From:' header fields, one for each list, to make it easy for a script to do something sensible? Also perhaps also 'X-To' for to be reliable and easy after forwarding and header munging and body replacement. Some "bounces" seem to take the attitude that you better damn well know who you sent the mail to! jam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: By Mailcrypt 3.5.4 and Gnu Privacy Guard iD4DBQE4vqVsUEvv1b/iXy8RAuYnAJYlvOjPMqyokcuz/Hcqtv7wMifuAJ9Y4p1R DmNFtRZO0L5FgK3IsY+VHg== =RFV/ -----END PGP SIGNATURE----- From docwhat@gerf.org Thu Mar 2 18:00:01 2000 From: docwhat@gerf.org (The Doctor What) Date: Thu, 2 Mar 2000 10:00:01 -0800 Subject: [Mailman-Developers] Admin overview page should list number of pending admin requests per list In-Reply-To: ; from Harald.Meland@usit.uio.no on Mon, Feb 07, 2000 at 09:17:50PM +0100 References: <20000119175228.67F911FF03B@perens.com> <14469.62839.700229.701854@anthem.cnri.reston.va.us> Message-ID: <20000302100001.G3332@gerf.org> * Harald Meland (Harald.Meland@usit.uio.no) [000207 14:18]: > [Barry A. Warsaw] > But that means that _anyone_ can see whether there are held messages > in a list -- which really is giving out more info than appropriate (at > least in some cases). > > I think there should be a separate "userinfo" CGI script which, after > proper autentication, shows what lists that user is 1) member of and > 2) admin for. Putting the info you both crave for on that page would > be Good. Another option, using the existing structure is to have a page show all the lists that a password works for... Ciao! -- "Well, given that the universe is infinite, and that God is infinite, and that God created the universe, (pause) would you like a piece of toast?" --Talkie Toaster (Red Dwarf episode: Dimension Jump) The Doctor What: A Holtje Production http://docwhat.gerf.org/ docwhat@gerf.org (finger docwhat@gerf.org for PGP key) KF6VNC From Nigel.Metheringham@VData.co.uk Fri Mar 3 09:12:40 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Fri, 03 Mar 2000 09:12:40 +0000 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: Message from "John A. Martin" of "Thu, 02 Mar 2000 12:31:40 EST." <20000302173143.3426B481D@athene.jamux.com> Message-ID: Loading the headers and/or the body with additional clues as to the original recipients and lists are is good... but some brain dead MTAs will still carefully anonymise the bounce messages - some do it so effectively you feel it has to be deliberate :-( Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From jwt@dskk.co.jp Tue Mar 7 09:23:54 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Tue, 7 Mar 2000 18:23:54 +0900 Subject: [Mailman-Developers] Re: Bogus directory In-Reply-To: <38BFC2F9.9B98ABE1@linux.org.uy>; from rodolfo@linux.org.uy on Fri, Mar 03, 2000 at 10:49:45AM -0300 References: <38BFC2F9.9B98ABE1@linux.org.uy> Message-ID: <20000307182354.A9325@mail.dskk.co.jp> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii On Fri, Mar 03, 2000 at 10:49:45AM -0300, Rodolfo Pilas wrote in mailman-users: [...] > However I am in receipt of a message about bogus directory: [...] > List todos.tecnico has a bogus archive_directory: > /var/spool/mailman/archives/private/todos.tecnico > List todos.sistemas has a bogus archive_directory: > /var/spool/mailman/archives/private/todos.sistemas The "bogus archive directory" issue seems to come up fairly often. Perhaps it would be worthwhile to add a check to cron/nightly_gzip to find out if it is simply a matter of there not yet being any articles to archive. Mailman could check post_id or last_post_time. I've attached one possibility. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nightly_gzip.diff" --- nightly_gzip.orig Wed Sep 1 03:14:04 1999 +++ nightly_gzip Tue Mar 7 18:17:16 2000 @@ -106,7 +106,8 @@ try: allfiles = os.listdir(dir) except os.error: - print 'List', name, 'has a bogus archive_directory:', dir + if mlist.last_post_time: + print 'List', name, 'has a bogus archive_directory:', dir continue files = [] for f in allfiles: --wRRV7LY7NUeQGEoC-- From jwt@dskk.co.jp Thu Mar 9 07:59:35 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Thu, 9 Mar 2000 16:59:35 +0900 Subject: [Mailman-Developers] monthly reminder bounce remedies Message-ID: <20000309165935.B21018@mail.dskk.co.jp> As mailman-owner I get a large number of bounces every month from password reminder messages with Mailman 1.1. The vast majority of these are for people whose subscription state has already been set to nomail. Is there already an automated way of dealing with these? If not... Would it be reasonable to set an (optional?) age limit for how long someone could be in the "nomail" state and still be "subscribed"? The mailpasswords cron job could "age" them and eventually delete them. The only drawback I've thought of is that it would periodically unsubscribe people that had subscribed just to check archives or mailing list membership (which may not be a bad thing :-). (Or visiting the web page resets their aging?) The alternative would seem to be to process the bounces from the reminders and (after a couple) remove the subscriber. Jim -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ From claw@kanga.nu Thu Mar 9 08:44:08 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 00:44:08 -0800 Subject: [Mailman-Developers] Failed authentication Message-ID: <20037.952591448@kanga.nu> I'm suddenly unable to log into the admin interfaces for my lists. Nothing gets posted to the log files on failed attempts. Poking about in ~/Mailman/Cgi/admin.py around the code: global cgi_data cgi_data = cgi.FieldStorage() AFAICT cgi_data is getting set to an empty dictionary (it doesn't seem to be "None"). Ideas? -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Thu Mar 9 09:04:46 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 01:04:46 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Thu, 09 Mar 2000 00:44:08 PST." <20037.952591448@kanga.nu> References: <20037.952591448@kanga.nu> Message-ID: <22817.952592686@kanga.nu> On Thu, 09 Mar 2000 00:44:08 -0800 J C Lawrence wrote: > I'm suddenly unable to log into the admin interfaces for my lists. > Nothing gets posted to the log files on failed attempts. > Poking about in ~/Mailman/Cgi/admin.py around the code: > global cgi_data cgi_data = cgi.FieldStorage() > AFAICT cgi_data is getting set to an empty dictionary (it doesn't > seem to be "None"). Ideas? Okay, not examply an empty dictionary (FieldStorage class), but it is empty per its own keys() and __len__ method. However, snooping the wire shows the POST with the "adminpw" in it set correctly. The apparancy is that for some reason the Cgi module is not getting the FORM variables properly. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Thu Mar 9 10:04:37 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 02:04:37 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Thu, 09 Mar 2000 01:04:46 PST." <22817.952592686@kanga.nu> References: <20037.952591448@kanga.nu> <22817.952592686@kanga.nu> Message-ID: <30727.952596277@kanga.nu> On Thu, 09 Mar 2000 01:04:46 -0800 J C Lawrence wrote: > On Thu, 09 Mar 2000 00:44:08 -0800 J C Lawrence > wrote: >> I'm suddenly unable to log into the admin interfaces for my >> lists. Nothing gets posted to the log files on failed attempts. >> Poking about in ~/Mailman/Cgi/admin.py around the code: >> global cgi_data cgi_data = cgi.FieldStorage() >> AFAICT cgi_data is getting set to an empty dictionary (it doesn't >> seem to be "None"). Ideas? > Okay, not examply an empty dictionary (FieldStorage class), but it > is empty per its own keys() and __len__ method. However, snooping > the wire shows the POST with the "adminpw" in it set correctly. > The apparancy is that for some reason the Cgi module is not > getting the FORM variables properly. Poking around even more: FieldStorage is blank. It is not getting the form variable (adminpw) from the login form. I don't know why. If I put the PW on the URL ala: http://server/mailman/admin/listname/?adminpw=password then everything works just fine up until I try and submit another form. I'm not sure where to go from here. Barry, got any pointers? -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Thu Mar 9 16:12:30 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 9 Mar 2000 11:12:30 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <20037.952591448@kanga.nu> <22817.952592686@kanga.nu> <30727.952596277@kanga.nu> Message-ID: <14535.52590.476700.446176@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> Poking around even more: | FieldStorage is blank. It is not getting the form variable | (adminpw) from the login form. I don't know why. JCL> If I put the PW on the URL ala: JCL> http://server/mailman/admin/listname/?adminpw=password JCL> then everything works just fine up until I try and submit JCL> another form. JCL> I'm not sure where to go from here. Barry, got any pointers? What changed? Did you upgrade Python, your browser, web server (or server config), OS, or anything else? Did you make any changes to Mailman? I've never seen this, but it sounds like there is now a problem somewhere between your server and the Mailman cgi scripts. I've never seen this happen! -Barry From claw@kanga.nu Thu Mar 9 18:43:51 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 10:43:51 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from "Barry A. Warsaw" of "Thu, 09 Mar 2000 11:12:30 EST." <14535.52590.476700.446176@anthem.cnri.reston.va.us> References: <20037.952591448@kanga.nu> <22817.952592686@kanga.nu> <30727.952596277@kanga.nu> <14535.52590.476700.446176@anthem.cnri.reston.va.us> Message-ID: <1540.952627431@kanga.nu> On Thu, 9 Mar 2000 11:12:30 -0500 (EST) Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Poking around even more: > | FieldStorage is blank. It is not getting the form variable > | (adminpw) from the login form. I don't know why. JCL> If I put the PW on the URL ala: JCL> http://server/mailman/admin/listname/?adminpw=password JCL> then everything works just fine up until I try and submit JCL> another form. JCL> I'm not sure where to go from here. Barry, got any pointers? > What changed? Did you upgrade Python, your browser, web server > (or server config), OS, or anything else? Did you make any > changes to Mailman? I've never seen this, but it sounds like > there is now a problem somewhere between your server and the > Mailman cgi scripts. I've never seen this happen! I installed mod_ssl (from a package) and restarted apache. I'm running under *exactly* the same Apache configs as I was before. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From mentor@alb-net.com Thu Mar 9 19:50:44 2000 From: mentor@alb-net.com (Mentor Cana) Date: Thu, 9 Mar 2000 14:50:44 -0500 (EST) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <1540.952627431@kanga.nu> Message-ID: > > changes to Mailman? I've never seen this, but it sounds like > > there is now a problem somewhere between your server and the > > Mailman cgi scripts. I've never seen this happen! > > I installed mod_ssl (from a package) and restarted apache. I'm > running under *exactly* the same Apache configs as I was before. I've installed mod_ssl (compiled it myself) and can do mailman admin via the SSL port with no problem. No password problems. Hope this info helps a bit. later, Mentor From claw@kanga.nu Thu Mar 9 20:14:58 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 12:14:58 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from Mentor Cana of "Thu, 09 Mar 2000 14:50:44 EST." References: Message-ID: <14146.952632898@kanga.nu> On Thu, 9 Mar 2000 14:50:44 -0500 (EST) Mentor Cana wrote: > I've installed mod_ssl (compiled it myself) and can do mailman > admin via the SSL port with no problem. No password problems. Aye, what's especially odd is that forms are process properly elsewhere (PHP for instance). So the Apache side and the modules sides are Okay its just something with the Mailman CGI wrapper. I guess. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Thu Mar 9 20:55:44 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Thu, 9 Mar 2000 15:55:44 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14146.952632898@kanga.nu> Message-ID: <14536.4048.420476.522854@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> Aye, what's especially odd is that forms are process properly JCL> elsewhere (PHP for instance). So the Apache side and the JCL> modules sides are Okay its just something with the Mailman JCL> CGI wrapper. I guess. I still want to know at what point the cgi data is getting corrupted. Is it between Apache and the C wrapper? Is it between the C wrapper and invoking the Python driver script? Is it between the driver script and the specific Mailman/Cgi module? -Barry From claw@kanga.nu Thu Mar 9 21:11:06 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 13:11:06 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Thu, 09 Mar 2000 15:55:44 EST." <14536.4048.420476.522854@anthem.cnri.reston.va.us> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> Message-ID: <21848.952636266@kanga.nu> On Thu, 9 Mar 2000 15:55:44 -0500 (EST) bwarsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Aye, what's especially odd is that forms are process properly JCL> elsewhere (PHP for instance). So the Apache side and the JCL> modules sides are Okay its just something with the Mailman CGI JCL> wrapper. I guess. > I still want to know at what point the cgi data is getting > corrupted. Is it between Apache and the C wrapper? Is it between > the C wrapper and invoking the Python driver script? Is it > between the driver script and the specific Mailman/Cgi module? I'm really not sure, and I'm not too sure how to find out either. Could you give me some hints where to poke this? -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From Harald.Meland@usit.uio.no Fri Mar 10 20:59:19 2000 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 10 Mar 2000 21:59:19 +0100 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: David Birnbaum's message of "Thu, 2 Mar 2000 07:13:55 -0500 (EST)" References: Message-ID: [David Birnbaum] > Here's the headers for the reminder: > > Return-Path: > Received: from killian.chelsea.net (localhost [127.0.0.1]) > by killian.chelsea.net (8.9.3/8.9.3) with ESMTP id FAA15246 > for ; Wed, 1 Mar 2000 05:52:23 -0500 (EST) > Date: Wed, 1 Mar 2000 05:52:23 -0500 (EST) > Message-Id: <200003011052.FAA15246@killian.chelsea.net> > From: mailman-owner@chelsea.net > Subject: thebody.com mailing list memberships reminder > To: ###A USER### > X-No-Archive: yes > Precedence: bulk > X-Mailman-Version: 1.1 > Precedence: bulk > List-Id: The Test List > > It should be from (I think), thebody-admin@thebody.com, with an Errors-To: > header. > > Not sure why List-Id: is The Test List...that's odd. That's because the script, while iterating through all lists, looks for the first "public" list. When found, that list is remembered, and that list's (fasttrack) delivery pipeline is used for sending out all the messages. As the "test" list is usually created pretty early on in any particular Mailman installation, it is not entirely uncommon that this list's List-Id: gets stuck on all password reminders... Normally it is nice that Mailman indicates which list's fasttrack pipeline you received a particular message through, but I can see that it might be confusing in this situation. However, a proper remedy is complicated by the lack of a list-independent Mailman mail address -- and thus, as Barry mentioned, also by the lack of a user database. -- Harald From bwarsaw@cnri.reston.va.us Fri Mar 10 21:01:03 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Fri, 10 Mar 2000 16:01:03 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders References: Message-ID: <14537.25231.104823.795653@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> However, a proper remedy is complicated by the lack of a HM> list-independent Mailman mail address -- and thus, as Barry HM> mentioned, also by the lack of a user database. Both problems which /will/ be remedied at some point. -Barry From Harald.Meland@usit.uio.no Fri Mar 10 21:17:41 2000 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 10 Mar 2000 22:17:41 +0100 Subject: [Mailman-Developers] Posting to 2 lists breaks newsgating for the second one In-Reply-To: Jim Hebert's message of "Wed, 1 Mar 2000 17:26:25 -0500 (EST)" References: Message-ID: [Jim Hebert] > I filed a jitterbug report about this a couple weeks back... > > Applix is fairly motivated about using mailman for their internal lists > but needs the ability to crosspost on the mail side and have it show up in > all the right newsgroups too. (If this doesn't make sense, visit the > jitterbug report below.) I suspect this has something to do with the fact that two separate Usenet messages can't have the same Message-Id. If you could have a look in your logs/post Mailman log, you might actually find some foundation for my suspicion (due to the except: clause around line 125 of Mailman/Handlers/ToUsenet.py). If this indeed is the problem at hand, I'm not sure how best to fix it. The optimal solution would be if mail "crossposts" actually turned into proper Usenet crossposts, and not multiple (nearly) identical posts to different newsgroups. However, I don't know enough about NNTP to say if implementing something like that is at all possible. A quick band-aid solution might be to change the Message-Id a wee bit (in a way that makes the change differ from list to list) before passing the message to the NNTP server. > So, I got them to put some money behind the bug report, if someone will > fix it: > > http://www.python.org/mailman-bugs/incoming?id=202;user=guest > http://www.cosource.com/cgi-bin/cos.pl/wish/info/295 > > (Sorry if this is better posted to the -users list, I just joined > both lists and don't have a clear sense of which one would have been > better...) I haven't had time to read -users for a looooong time, but I think -developers is the proper place to post specific feature requests like this. > All in all, we're loving mailman! =) Great :) -- Harald From claw@kanga.nu Sun Mar 12 08:19:18 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 00:19:18 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Thu, 09 Mar 2000 13:11:06 PST." <21848.952636266@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> Message-ID: <577.952849158@kanga.nu> Background data as this is also going to the Debian Mailman package maintainer: Mailman's web interface suddenly stopped working for me. The forms would display but I am unable authenticate not matter what browser (Netscape 4.05 and 4.7, Lynx, W3M or Mozilla M14) I use. On Thu, 09 Mar 2000 13:11:06 -0800 J C Lawrence wrote: > On Thu, 9 Mar 2000 15:55:44 -0500 (EST) bwarsaw > wrote: >>>>>>> "JCL" == J C Lawrence writes: JCL> Aye, what's especially odd is that forms are process properly JCL> elsewhere (PHP for instance). So the Apache side and the JCL> modules sides are Okay its just something with the Mailman CGI JCL> wrapper. I guess. >> I still want to know at what point the cgi data is getting >> corrupted. Is it between Apache and the C wrapper? Is it >> between the C wrapper and invoking the Python driver script? Is >> it between the driver script and the specific Mailman/Cgi module? > I'm really not sure, and I'm not too sure how to find out either. > Could you give me some hints where to poke this? I've done some more digging, implemented ScriptLog in Apache, inserted sys.exit(1) in the admin script to force a failure right after the FieldStorage call, and then instrumented pythonlib/cgi.py. Findings: read_urlencoded never reads anything from stdin. Zero. Zilch. Nada. There's nothing there. The key edits: ---- def read_urlencoded(self): """Internal: read data in query string format.""" qs = self.fp.read(self.length) qs=str(qs) sys.stderr.write (qs) sys.stderr.write ('=======') sys.stderr.write (str(self.length)) ...etc ---- ---- %% [Sat Mar 11 23:58:57 2000] POST /lists/admin/library/ HTTP/1.0 %% 500 /var/lib/mailman/cgi-bin/admin %request Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Encoding: gzip Accept-Language: en Connection: Keep-Alive Content-length: 40 Content-type: application/x-www-form-urlencoded Cookie: mud-dev:admin="(lp1\012S'216.148.243.2'\012p2\012aI952846157\012aI952856957\012aI-96722254\012a." Host: www.kanga.nu Referer: http://www.kanga.nu/lists/admin/library/ User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.13 i686; Nav) adminpw=xxxxx&request_login=Let+me+in... %response %stderr =======40 ---- According to that Apache is sending all the right data, it just ain't getting there. I've also upgraded libc6 recently (Debian system FWIW with packages libc6_2.1.3-[567]_i386.deb (notice regex range)). I downgraded libc6 to the package versions (5 and 6) that were installed when it did work to no effect. I also rebuilt the Mailman C based CGI programs under the installed version of libc6, and copied them over (in case something odd was going on) to no observed effect. Note: Plopping the cgi.py in as a standalone cgi tests out as working using GET methods (ie encode vars on the URL). I haven't built a framework yet to test POST for that module. I guess the next step is to either build that framework, or test-drive the C CGIs to make sure stdin really has the right bumph sitting there waiting. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From gorgo@caesar.elte.hu Sun Mar 12 14:24:06 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 12 Mar 2000 15:24:06 +0100 (MET) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <577.952849158@kanga.nu> Message-ID: On Sun, 12 Mar 2000, J C Lawrence wrote: > > Background data as this is also going to the Debian Mailman package > maintainer: > > Mailman's web interface suddenly stopped working for me. The > forms would display but I am unable authenticate not matter what > browser (Netscape 4.05 and 4.7, Lynx, W3M or Mozilla M14) I use. Hmm... unable to authenticate ? That means you get to the password screen each time you try to submit a form ? This usually happens if you don't access your admin interface on the Base url set for your list... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From claw@kanga.nu Sun Mar 12 16:54:07 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 08:54:07 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from Gergely Madarasz of "Sun, 12 Mar 2000 15:24:06 +0100." References: Message-ID: <13905.952880047@kanga.nu> On Sun, 12 Mar 2000 15:24:06 +0100 (MET) Gergely Madarasz wrote: > On Sun, 12 Mar 2000, J C Lawrence wrote: >> Background data as this is also going to the Debian Mailman >> package maintainer: >> >> Mailman's web interface suddenly stopped working for me. The >> forms would display but I am unable authenticate not matter what >> browser (Netscape 4.05 and 4.7, Lynx, W3M or Mozilla M14) I use. > Hmm... unable to authenticate ? That means you get to the password > screen each time you try to submit a form ? This usually happens > if you don't access your admin interface on the Base url set for > your list... Nope, that's not the problem (and I'm accessing on the Base Url to boot). The problem is that the Mailman CGIs are not getting the form submission data from Apache. Apache appears to be supplying it (ScriptLog says it is), but by the time the Python code runs its no longer there. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Sun Mar 12 17:50:13 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 09:50:13 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Sun, 12 Mar 2000 00:19:18 PST." <577.952849158@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> Message-ID: <21235.952883413@kanga.nu> On Sun, 12 Mar 2000 00:19:18 -0800 J C Lawrence wrote: > Findings: read_urlencoded never reads anything from stdin. Zero. > Zilch. Nada. There's nothing there. The key edits: ... > According to that Apache is sending all the right data, it just > ain't getting there. I've also upgraded libc6 recently (Debian > system FWIW with packages libc6_2.1.3-[567]_i386.deb (notice regex > range)). I downgraded libc6 to the package versions (5 and 6) > that were installed when it did work to no effect. I also rebuilt > the Mailman C based CGI programs under the installed version of > libc6, and copied them over (in case something odd was going on) > to no observed effect. I changed cgi-wrapper.c to read: #include #include "common.h" /* passed in by configure */ #define SCRIPTNAME SCRIPT #define LOG_IDENT "Mailman cgi-wrapper (" ## SCRIPT ## ")" /* GID that CGI scripts run as. See your Web server's documentation. */ #define LEGAL_PARENT_GID CGI_GID const char* logident = LOG_IDENT; char* script = SCRIPTNAME; const int parentgid = LEGAL_PARENT_GID; int main(int argc, char** argv, char** env) { int status; char* fake_argv[3]; char ac[31]; /* !!!!!!!!!!!edited!!!!!!!!!!!!! */ memset (ac, 0, 31); /* !!!!!!!!!!!edited!!!!!!!!!!!!! */ running_as_cgi = 1; if (getgid()>=100 && getgid()!=65534) check_caller(logident, parentgid)$ /* for these CGI programs, we can ignore argc and argv since they * don't contain anything useful. `script' will always be the driver * program and argv will always just contain the name of the real * script for the driver to import and execute (padded with two dummy * values in argv[0] and argv[1] that are ignored by run_script(). */ fake_argv[0] = NULL; fake_argv[1] = NULL; fake_argv[2] = script; fread (ac, 1, 30, stdin); /* !!!!!!!!!!!!edited!!!!!!!!!!!! */ fprintf (stderr, "---[%s]---",ac); /* !!!!!!!!!!!!edited!!!!!!!!!!!! */ status = run_script("driver", 3, fake_argv, env); fatal(logident, status, "%s", strerror(errno)); return status; } The ~mailman/cgi-bin/admin is not getting anything on stdin. Not good. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Mon Mar 13 02:56:09 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 18:56:09 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Sun, 12 Mar 2000 09:50:13 PST." <21235.952883413@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> Message-ID: <27855.952916169@kanga.nu> On Sun, 12 Mar 2000 09:50:13 -0800 J C Lawrence wrote: > The ~mailman/cgi-bin/admin is not getting anything on stdin. Not > good. Current findings: Installation of the PHP3 apache modules under Debian/potato kills POST methods for MailMan. I don't know why. Problem is, I need both. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Mon Mar 13 03:19:34 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Sun, 12 Mar 2000 22:19:34 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> Message-ID: <14540.24134.895512.923706@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> The ~mailman/cgi-bin/admin is not getting anything on stdin. JCL> Not good. But at least we know it's not Python, or Mailman on up. cgi-wrapper.c /could/ be doing something weird, but I don't see what that could be. You mentioned upgrading libc; maybe you need to rebuild Apache? -Barry From bwarsaw@cnri.reston.va.us Mon Mar 13 03:21:43 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Sun, 12 Mar 2000 22:21:43 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> <27855.952916169@kanga.nu> Message-ID: <14540.24263.343898.575179@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> Installation of the PHP3 apache modules under Debian/potato JCL> kills POST methods for MailMan. I don't know why. Problem JCL> is, I need both. What about other POSTs? If others work, then what's so weird about Mailman's C wrappers? -Barry From bwarsaw@cnri.reston.va.us Mon Mar 13 04:07:21 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Sun, 12 Mar 2000 23:07:21 -0500 (EST) Subject: [Mailman-Developers] a more uniform interface to private and public archives References: Message-ID: <14540.27001.603163.57782@anthem.cnri.reston.va.us> >>>>> "TP" == Todd Pfaff writes: TP> what i'd like to suggest is that we make the interface more TP> uniform by eliminating the 'Alias' path and access both TP> private and public archives via a single cgi-bin interface. TP> if the archive is private we require authentication, if not we TP> simply bypass the authentication. We specifically decided not to do this because we didn't want to take the performance hit for the more common situation of public archives. With the current arrangement, public archives are vended directly (and quickly) by the http server, while public archives are forced to go through the slower cgi for authentication purposes. -Barry From claw@kanga.nu Mon Mar 13 04:30:17 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 20:30:17 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Sun, 12 Mar 2000 22:21:43 EST." <14540.24263.343898.575179@anthem.cnri.reston.va.us> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> <27855.952916169@kanga.nu> <14540.24263.343898.575179@anthem.cnri.reston.va.us> Message-ID: <10982.952921817@kanga.nu> On Sun, 12 Mar 2000 22:21:43 -0500 (EST) bwarsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Installation of the PHP3 apache modules under Debian/potato JCL> kills POST methods for MailMan. I don't know why. Problem is, JCL> I need both. > What about other POSTs? If others work, then what's so weird > about Mailman's C wrappers? I have no bloody idea. POSTS to PHP work just fine. POSTs to Perl CGIs work fine. Once I add the PHP3 module to Apache's config, POSTs to Mailman stop. Colour me confused. As soon as I get few other things resolved, I'm going to see what happens if I backlevel PHP, or even try PHP4... -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Mon Mar 13 08:54:44 2000 From: claw@kanga.nu (J C Lawrence) Date: Mon, 13 Mar 2000 00:54:44 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Sun, 12 Mar 2000 20:30:17 PST." <10982.952921817@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> <27855.952916169@kanga.nu> <14540.24263.343898.575179@anthem.cnri.reston.va.us> <10982.952921817@kanga.nu> Message-ID: <21677.952937684@kanga.nu> On Sun, 12 Mar 2000 20:30:17 -0800 J C Lawrence wrote: > I have no bloody idea. POSTS to PHP work just fine. POSTs to > Perl CGIs work fine. Once I add the PHP3 module to Apache's > config, POSTs to Mailman stop. > Colour me confused. > As soon as I get few other things resolved, I'm going to see what > happens if I backlevel PHP, or even try PHP4... I've identified the exact setup that causes the behaviour under Debian/potato: If I install the following .debs for PHP everything works fine: php3-gd_3%3a3.0.15-1_i386.deb php3_3%3a3.0.15-1_i386.deb php3-mysql_3%3a3.0.15-1_i386.deb If however I install the current Debian/potato set: php3_3%3a3.0.15-1.2_i386.deb php3-gd_3%3a3.0.15-1.2_i386.deb php3-mysql_3%3a3.0.15-1.2_i386.deb with the same Apache configs in both cases (a LoadModule line and two AddTypes as per the default http.conf and srm.conf), or I install the prior the prior 2.0.15-1.1 package set, HTTP POSTs to MailMan CGIs no longer happen due to the fact that nothing reaches the stdin of the CGIs. It doesn't seem to matter whether I'm running: apache_1.3.9-12_i386.deb apache-common_1.3.9-12_i386.deb or: apache_1.3.9-11_i386.deb apache-common_1.3.9-11_i386.deb or the various libc6 packages in that date range. What I havem't tried, and what I'm going to leave up to Gergely Madarasz (CC'ed on this message) the Debian package maintainer for both the PHP3 and MailMan packages, is finding out if rebuilding everything with a current (or even the same) glibc version makes the problem go away (it hopefully being reproducable at his end). I'm willing to supply copies of my config files if there's interest. I'm going to bed. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From gorgo@caesar.elte.hu Mon Mar 13 13:49:53 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 13 Mar 2000 14:49:53 +0100 (MET) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <21677.952937684@kanga.nu> Message-ID: On Mon, 13 Mar 2000, J C Lawrence wrote: > On Sun, 12 Mar 2000 20:30:17 -0800 > J C Lawrence wrote: > > > I have no bloody idea. POSTS to PHP work just fine. POSTs to > > Perl CGIs work fine. Once I add the PHP3 module to Apache's > > config, POSTs to Mailman stop. > > > Colour me confused. > > > As soon as I get few other things resolved, I'm going to see what > > happens if I backlevel PHP, or even try PHP4... > > I've identified the exact setup that causes the behaviour under > Debian/potato: > > If I install the following .debs for PHP everything works fine: > > php3-gd_3%3a3.0.15-1_i386.deb > php3_3%3a3.0.15-1_i386.deb > php3-mysql_3%3a3.0.15-1_i386.deb > > If however I install the current Debian/potato set: > > php3_3%3a3.0.15-1.2_i386.deb > php3-gd_3%3a3.0.15-1.2_i386.deb > php3-mysql_3%3a3.0.15-1.2_i386.deb Please try the 3:3.0.15-2 packages. The 1.2 package set was an NMU, and had some other problems too, probably due to an incomplete or broken build environment. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From bwarsaw@cnri.reston.va.us Mon Mar 13 16:34:30 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Mon, 13 Mar 2000 11:34:30 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <21677.952937684@kanga.nu> Message-ID: <14541.6294.787522.466891@anthem.cnri.reston.va.us> Could one of you possibly send me a blurb summarizing the recommendation for README.LINUX? Thanks. -Barry From bwarsaw@cnri.reston.va.us Mon Mar 13 19:53:33 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 13 Mar 2000 14:53:33 -0500 (EST) Subject: [Mailman-Developers] Re: Bogus directory References: <38BFC2F9.9B98ABE1@linux.org.uy> <20000307182354.A9325@mail.dskk.co.jp> Message-ID: <14541.18237.18165.497054@anthem.cnri.reston.va.us> >>>>> "JT" == Jim Tittsler writes: JT> The "bogus archive directory" issue seems to come up fairly JT> often. Perhaps it would be worthwhile to add a check to JT> cron/nightly_gzip to find out if it is simply a matter of JT> there not yet being any articles to archive. I like this, so I'll check this in. Thanks. -Barry From Gergely Madarasz Tue Mar 14 15:49:49 2000 From: Gergely Madarasz (Gergely Madarasz) Date: Tue, 14 Mar 2000 16:49:49 +0100 (MET) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <14541.6294.787522.466891@anthem.cnri.reston.va.us> Message-ID: On Mon, 13 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > Could one of you possibly send me a blurb summarizing the > recommendation for README.LINUX? If you refer to these php3 + mailman problems, nothing should be summarized... it was just one set of broken php3 packages in a development version of debian which have already been replaced. And I hope the new packages work... :) -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From bwarsaw@cnri.reston.va.us Tue Mar 14 16:13:52 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Tue, 14 Mar 2000 11:13:52 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14541.6294.787522.466891@anthem.cnri.reston.va.us> Message-ID: <14542.25920.587939.9162@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: >> Could one of you possibly send me a blurb summarizing the >> recommendation for README.LINUX? GM> If you refer to these php3 + mailman problems, nothing should GM> be summarized... it was just one set of broken php3 packages GM> in a development version of debian which have already been GM> replaced. And I hope the new packages work... :) I always like solutions where I don't have to do anything :) Thanks, -Barry From hauserma@site-eerie.ema.fr Wed Mar 15 14:03:20 2000 From: hauserma@site-eerie.ema.fr (Hausermann Laurent) Date: Wed, 15 Mar 2000 15:03:20 +0100 Subject: [Mailman-Developers] French Templates. Message-ID: <38CF9828.4B4B2658@site-eerie.ema.fr> Hi, I currently finalizing a communuty web server (for a former student association) in French, and I cannot find any ressources about French Templates for mailman 1.1. Do you now about any translation project ? Thanks a lot Laurent Hausermann From claw@kanga.nu Wed Mar 15 16:39:09 2000 From: claw@kanga.nu (J C Lawrence) Date: Wed, 15 Mar 2000 08:39:09 -0800 Subject: [Mailman-Developers] File handle shortages Message-ID: <19585.953138349@kanga.nu> I'm now getting this, with no other changes in the system, when approving messages held for moderation. Same kernel, same file handle limits as before...: IOError writing outgoing queue exceptions.IOError/[Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10890.13' Traceback (innermost last): File "/var/lib/mailman/scripts/contact_transport", line 58, in ? File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 155, in enqueueMessage File "/usr/lib/mailman/Mailman/Utils.py", line 829, in open_ex File "/usr/lib/mailman/Mailman/Utils.py", line 824, in open_ex IOError: [Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10890.13' IOError writing outgoing queue exceptions.IOError/[Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10918.9' Traceback (innermost last): File "/var/lib/mailman/scripts/contact_transport", line 58, in ? File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 155, in enqueueMessage File "/usr/lib/mailman/Mailman/Utils.py", line 829, in open_ex File "/usr/lib/mailman/Mailman/Utils.py", line 824, in open_ex IOError: [Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10918.9' Content-type: text/html ... Traceback (innermost last): File "/var/lib/mailman/scripts/driver", line 112, in run_main File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 112, in main File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 200, in HandleRequests File "/usr/lib/mailman/Mailman/ListAdmin.py", line 122, in HandleRequest File "/usr/lib/mailman/Mailman/ListAdmin.py", line 131, in HandlePostRequest File "/usr/lib/mailman/Mailman/MailList.py", line 1329, in Post File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 206, in ArchiveMail File "/usr/lib/mailman/Mailman/LockFile.py", line 200, in lock File "/usr/lib/mailman/Mailman/LockFile.py", line 156, in __read IOError: [Errno 23] Too many open files in system: '/var/lib/mailman/locks/mud-dev.archiver.lock.bush.10877' The mail (at least) does seem to get thru. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From ricardo@rixhq.nu Wed Mar 15 19:40:48 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 15 Mar 2000 20:40:48 +0100 Subject: [Mailman-Developers] cookies Message-ID: <20000315204048.B1040@miss-janet.com> Hi, this was just suggested to me by somebody from mailman-users: > Please write a patch which puts the string "Cookie could not be set" on the > web page so that I can see that pressing submit will not work :-) i think thats a good point... it would safe some user questions if MM tells exactly why the authorisation failed. I'm not sure if this subject has been touched already, but what allowing admins to choose between cookies and Basic-Authorization... it should be possible to use Basic-auth, right? Ricardo. -- From granveau@worldnet.fr Thu Mar 16 00:23:49 2000 From: granveau@worldnet.fr (Boris Granveaud) Date: Thu, 16 Mar 2000 01:23:49 +0100 Subject: [Mailman-Developers] Pb with URL sent to modify your options Message-ID: <38D02995.4701E061@worldnet.fr> Hi, I noticed a problem with the URL that is sent with the introduction mail (when you have just subscribed to a list). The URL is like this: http://www.python.org/mailman/options/mailman-developers/granveau@worldnet.fr If you receive with Hotmail and you are using Internet Explorer, the URL doesn't work. The browser tries to open http://www.python.org/mailman/options/mailman-developers/ I think that if you replace granveau@worldnet.fr with granveau__at__worldnet.fr, it would work. Can anybody confirm this and provide a patch? Thank you, Boris. From port22@rnhnet.com Thu Mar 16 19:50:14 2000 From: port22@rnhnet.com (port22@rnhnet.com) Date: Thu, 16 Mar 2000 11:50:14 -0800 Subject: [Mailman-Developers] PC / Internet fax solution Message-ID: <3.0.6.32.20000316115014.009929f0> I stopped by your web site and thought you may be interested in our PC/internet based fax service. You can send 1 to 1,000,000 faxes in just minutes to any destination in the US, Canada, and Europe for as low as 7.4 cents per minute. Our user-friendly submission software lets you queue your job on our server within minutes. Why not try the system for FREE. We will be happy to send 100 Faxes on your behalf to your fax list immediately. Simply go to http://www.efaxcast.com/submit.htm From claw@cp.net Thu Mar 16 22:38:12 2000 From: claw@cp.net (J C Lawrence) Date: Thu, 16 Mar 2000 14:38:12 -0800 Subject: [Mailman-Developers] French Templates. In-Reply-To: Message from Hausermann Laurent of "Wed, 15 Mar 2000 15:03:20 +0100." <38CF9828.4B4B2658@site-eerie.ema.fr> References: <38CF9828.4B4B2658@site-eerie.ema.fr> Message-ID: I'm now getting lock failures upon approving messages held for moderation: Traceback (innermost last): File "/var/lib/mailman/scripts/driver", line 112, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 112, in main HandleRequests(doc) File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 200, in HandleRequests list.HandleRequest(request, v, form[comment_key].value) File "/usr/lib/mailman/Mailman/ListAdmin.py", line 122, in HandleRequest self.HandlePostRequest(request_data[2:], value, comment) File "/usr/lib/mailman/Mailman/ListAdmin.py", line 131, in HandlePostRequest self.Post(msg, 1) File "/usr/lib/mailman/Mailman/MailList.py", line 1329, in Post self.ArchiveMail(msg) File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 206, in ArchiveMail lock.lock() File "/usr/lib/mailman/Mailman/LockFile.py", line 245, in lock os.unlink(self.__tmpfname) OSError: [Errno 2] No such file or directory: '/var/lib/mailman/locks/mud-dev.archiver.lock.bush.16685' check_perms reports clean, Apache (v1.1-4) runs as user www-data.www-data (Debain defaults), but the Mailman user is list.list. $ pwd /var/lib/mailman/locks $ ls -lasp total 36 4 drwxrwsr-x 2 root list 4096 Mar 16 14:35 ./ 4 drwxrwsr-x 6 root list 4096 Mar 12 21:46 ../ 4 -rw-rw-r-- 1 root list 69 Mar 16 09:48 .lock 4 -rw-rw-r-- 1 list list 74 Mar 16 14:12 mmqueue_run.lock 4 -rw-rw-r-- 2 www-data list 79 Mar 16 14:31 mud-dev.archiver.lock 4 -rw-rw-r-- 1 www-data list 79 Mar 16 14:31 mud-dev.archiver.lock.bush.24449 4 -rw-rw-r-- 2 www-data list 79 Mar 16 14:31 mud-dev.archiver.lock.bush.24499 4 -rw-rw-r-- 1 list list 70 Mar 16 14:35 mud-dev.lock This looks fishy to me. Blowing away the contents of the directory doesn't fix the problem. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@cp.net Fri Mar 17 01:15:29 2000 From: claw@cp.net (J C Lawrence) Date: Thu, 16 Mar 2000 17:15:29 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from Gergely Madarasz of "Mon, 13 Mar 2000 23:08:38 +0100." References: Message-ID: On Mon, 13 Mar 2000 23:08:38 +0100 (MET) Gergely Madarasz wrote: > On Mon, 13 Mar 2000 coder@kanga.nu wrote: >> On Mon, 13 Mar 2000 14:49:53 +0100 (MET) Gergely Madarasz >> wrote: >>> Please try the 3:3.0.15-2 packages. The 1.2 package set was an >>> NMU, and had some other problems too, probably due to an >>> incomplete or broken build environment. >> >> Got a set of those for Potato as versus Woody? Potato doesn't >> seem to have anything more recent than -1.2 (and I'm not about to >> roll a production box up to Woody just yet). > Potato should have -2, the packages were installed on master at > 8:41 GMT, some mirrors might be still out of date though... Okay, I just upgraded to the -2 packages, restarted Apache, and everything was heppy. The -1.1 and -1.2 packages are broken. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From bwarsaw@cnri.reston.va.us Tue Mar 21 05:58:21 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 00:58:21 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon Message-ID: <14551.3965.171599.618432@anthem.cnri.reston.va.us> Folks, Okay, I think I solved the last major hurdle before I can start releasing the new betas. Mailman should now lazily update it's old pending requests "database" to the new style external requests.db file. Wasn't as hard as I thought it would be. You will still have to be careful when upgrading from 1.1/1.0 to the new version. Please read/debug my recommendations in the UPGRADING file for details (after I check it in). While I'm pretty sure upgrading will work, I really need feedback from you beta testers. For now, I'd say you should be careful upgrading any operational site, but on the other hand I want to encourage you to test this stuff as much as possible. All feedback is welcome. Now, my questions. 1) Notice I haven't said "upgrade to 1.2" because I'm going to call the new release 2.0. While there aren't that many outwardly visible differences, there are enough architectural and schema changes, that I believe a 2.0 label is warranted. Plus, I want to give a stronger indication that the changes may be, er, significant. This means that if I really screw up 2.0, I can get a few 2.x bug patches out in quick succession. This also means that the i18n'd Mailman will likely be called 3.0. What's in a number anyway? :) 1) I've thought about being really parental about the upgrade, by essentially forcing people to read the UPGRADING file before "make" will succeed. I think I have a trick that will work, but I'm not sure it's a good idea. On the one hand it /might/ (only might) save lazy or novice upgraders some headaches by forcing them to read the manual first. One the other hand, it'll be really annoying either to those who are doing a fresh install, or who are upgrading but know what they're doing. So, do you think it would be a good idea to force everyone to read UPGRADING before "make" succeeds? Watch for the final round of checkins some time (hopefully) this week. After that I'll spin the 2.0beta1 tarball. I'm pretty sure the current CVS snapshot is very close, modulo updating the docs. I still need to get through the email backlog (sigh) and the Jitterbug database, but I can do that while the betas are out on the street. Cheers, -Barry From jwt@dskk.co.jp Tue Mar 21 06:22:44 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Tue, 21 Mar 2000 15:22:44 +0900 Subject: [Mailman-Developers] ToUsenet should use the new nntplib, modereader Message-ID: <20000321152244.A30221@mail.dskk.co.jp> --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Barry, Posting also requires the server to be in 'mode reader' (at least our INN does). I think you only updated the cron/gatenews... Jim -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ToUsenet.diff" --- Mailman/Handlers/ToUsenet.py.orig Mon Feb 14 15:12:39 2000 +++ Mailman/Handlers/ToUsenet.py Tue Mar 21 15:15:57 2000 @@ -23,6 +23,10 @@ from Mailman.pythonlib.StringIO import StringIO +# The version we have is from Python 1.5.2+ and fixes the "mode reader" +# problem. +from Mailman.pythonlib import nntplib + def process(mlist, msg): @@ -123,7 +127,7 @@ # flatten the message object, stick it in a StringIO object and post # that resulting thing to the newsgroup fp = StringIO(str(msg)) - conn = nntplib.NNTP(mlist.nntp_host) + conn = nntplib.NNTP(mlist.nntp_host, readermode=1) try: try: conn.post(fp) --yrj/dFKFPuw6o+aM-- From ricardo@rixhq.nu Tue Mar 21 06:32:02 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Tue, 21 Mar 2000 07:32:02 +0100 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.3965.171599.618432@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 12:58:21AM -0500 References: <14551.3965.171599.618432@anthem.cnri.reston.va.us> Message-ID: <20000321073202.A32359@miss-janet.com> Hi, On Tue, Mar 21, 2000 at 12:58:21AM -0500, Barry A. Warsaw wrote: > releasing the new betas. Mailman should now lazily update it's old > pending requests "database" to the new style external requests.db > file. Wasn't as hard as I thought it would be. ah great :) > While I'm pretty sure upgrading will work, I really need feedback from > you beta testers. For now, I'd say you should be careful upgrading > any operational site, but on the other hand I want to encourage you to > test this stuff as much as possible. All feedback is welcome. I'm using the CVS version already in production so I won't have trouble switching to the beta... > 1) I've thought about being really parental about the upgrade, by > essentially forcing people to read the UPGRADING file before "make" > will succeed. I think I have a trick that will work, but I'm not > sure it's a good idea. On the one hand it /might/ (only might) > save lazy or novice upgraders some headaches by forcing them to > read the manual first. > they're doing. So, do you think it would be a good idea to force > everyone to read UPGRADING before "make" succeeds? I've seen software packages solving this by needing to enter a "magic" key with the make command before being able to do the install... and the key could be found in the install docs... You could also specifically ask the user if he/she read the UPGRADING file with a y/n prompt before proceeding with the actual install. Also, what about including a backup procedure with the install, so you can revert the install with 'make install restore-original'...? BUT all this seems a lot of work, just for being helpful to lazy people who take the risk of not reading the upgrade docs :) I think a y/n prompt could be enough... if the user then decides to ignore the BIG FLASHY WARNING TO READ THE UPGRADING FILE then so be it... > Watch for the final round of checkins some time (hopefully) this week. could you let us know on this list when this has been done? then I can do a CVS update of my version... and then see how much of my own hacks i have to put back in. I'm looking forward to bug squatting the betas... :) Thanks for doing a great job, Barry! Ricardo. -- From bwarsaw@cnri.reston.va.us Tue Mar 21 06:55:23 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Tue, 21 Mar 2000 01:55:23 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: <14551.3965.171599.618432@anthem.cnri.reston.va.us> <20000321073202.A32359@miss-janet.com> Message-ID: <14551.7387.973331.640425@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> I'm using the CVS version already in production so I won't RK> have trouble switching to the beta... You too? Me too! :) RK> I've seen software packages solving this by needing to enter a RK> "magic" key with the make command before being able to do the RK> install... and the key could be found in the install docs... RK> You could also specifically ask the user if he/she read the RK> UPGRADING file with a y/n prompt before proceeding with the RK> actual install. Also, what about including a backup procedure RK> with the install, so you can revert the install with 'make RK> install restore-original'...? BUT all this seems a lot of RK> work, just for being helpful to lazy people who take the risk RK> of not reading the upgrade docs :) I think a y/n prompt could RK> be enough... if the user then decides to ignore the BIG FLASHY RK> WARNING TO READ THE UPGRADING FILE then so be it... I was thinking about playing games with make dependencies, but ya, it seems like a lot of boring work :) Hmm, I'll see how motivated I get before the 2.0 final. Me> Watch for the final round of checkins some time (hopefully) Me> this week. RK> could you let us know on this list when this has been done? RK> then I can do a CVS update of my version... and then see how RK> much of my own hacks i have to put back in. You're lucky I'm feeling insomniatic tonight. I've finished the checkins and will spin the tarball from the current CVS snapshot when I get a bit of free time. RK> I'm looking forward to bug squatting the betas... :) Me too (I think :) RK> Thanks for doing a great job, Barry! You're very welcome! -Barry From elau@ics.uci.edu Tue Mar 21 08:55:30 2000 From: elau@ics.uci.edu (Edmund Lau) Date: Tue, 21 Mar 2000 00:55:30 -0800 (PST) Subject: [Mailman-Developers] Betas coming soon Message-ID: Well, I just read the Emails on the new beta version. I hate to ask it, but was there a timetable on when we might expect it to be fully released? Just wondering cuz I just sent an Email out to my users that I'm installing 1.1 tomorrow and I'm not sure if I should just wait for 2.0. Will the upgrade path be difficult? No pressure whatsoever! ;) -Ed From bwarsaw@cnri.reston.va.us Tue Mar 21 14:15:54 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 09:15:54 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: Message-ID: <14551.33818.104514.373646@anthem.cnri.reston.va.us> >>>>> "EL" == Edmund Lau writes: EL> Well, I just read the Emails on the new beta version. I hate EL> to ask it, but was there a timetable on when we might expect EL> it to be fully released? Just wondering cuz I just sent an EL> Email out to my users that I'm installing 1.1 tomorrow and I'm EL> not sure if I should just wait for 2.0. Will the upgrade path EL> be difficult? Sorry, I can't give a time frame for 2.0 final, but I don't suspect the beta cycle will be longer than a couple of weeks at most. There are already several of us using the current snapshot in production environments. As for upgrading from 1.1 to 2.0, I think it will be fairly straightforward, but that's one of the things I'd really like the mm-devers to exercise. My biggest concern is what happens to messages in Mailman 1.1's mail queue. You really need to have this cleared out before you upgrade. I should mention that on python.org, I didn't do an overlaying upgrade because I started using the new code base before I had all the proper update code in place. You can always create a new installation in a different directory, but moving lists from one directory to another, while possible, is time-consuming and a pain. EL> No pressure whatsoever! ;) Sure, sure, that's what they /all/ say! :) -Barry From jarrell@vt.edu Tue Mar 21 19:08:16 2000 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 21 Mar 2000 14:08:16 -0500 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.33818.104514.373646@anthem.cnri.reston.va.us> References: Message-ID: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> --=====================_67063723==_.ALT Content-Type: text/plain; charset="us-ascii" Upgraded my test machine, which was running a month or two ago cvs snapshot, and so far things are ok. Except for gateing *to* a list, but someone already caught that. If things look ok, I'll put it on my production server later in the week or early next. Note that the images aren't in the cvs repository yet. (Is the python image really a PNG? Yuck.) --=====================_67063723==_.ALT Content-Type: text/html; charset="us-ascii" Upgraded my test machine, which was running a month or two ago cvs snapshot, and
so far things are ok.  Except for gateing *to* a list, but someone already caught that.

If things look ok, I'll put it on my production server later in the week or early next.

Note that the images aren't in the cvs repository yet.  (Is the python image really
a PNG?  Yuck.)
 --=====================_67063723==_.ALT-- From bwarsaw@cnri.reston.va.us Tue Mar 21 19:22:22 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Tue, 21 Mar 2000 14:22:22 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> Message-ID: <14551.52206.999641.515081@anthem.cnri.reston.va.us> >>>>> "RJ" == Ron Jarrell writes: RJ> Upgraded my test machine, which was running a month or two ago RJ> cvs snapshot, and so far things are ok. Except for gateing RJ> *to* a list, but someone already caught that. Right. That change should have been checked in by now, so doing a cvs update should get you the fix to Mailman/Handlers/ToUsenet.py RJ> If things look ok, I'll put it on my production server later RJ> in the week or early next. Cool. RJ> Note that the images aren't in the cvs repository yet. The should be! Take a look at http://cvs.python.org/cgi-bin/viewcvs.cgi/mailman/misc/ and you should find PythonPowered.png, gnu-head-tiny.jpg, and mailman.jpg which are the three logos. RJ> (Is the python image really a PNG? Yuck.) Why yuck? My dilemma was this: PythonPowered.gif is purposefully transparent around the edges of the oval, but we can't use gifs because Mailman is Gnu. I'd have preferred jpegs for consistency, but I couldn't figure out how to make the transparency work (I don't think jpeg supports transparencies). png seemed the only compromise, and converting from gif to png was made easy by Eric Raymond's tool. The downsides I see are support for png in browsers. NS 4.7 and MSIE 5.x both support pngs, but only MSIE supports transparent pngs (so if you change your background to other than white, it won't look nice). I'm open to suggestions, but this seems to me to be the best compromise as long as gifs are verboten. -Barry From ricardo@rixhq.nu Tue Mar 21 20:06:35 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Tue, 21 Mar 2000 21:06:35 +0100 Subject: [Mailman-Developers] beta & smtp Message-ID: <20000321210635.B2014@miss-janet.com> I just upgraded the cvs version i had installed (which is a snapshot from almost a month ago i think) and when i tried to approve 11 posts, I got a mailman error... something about a connection refused (see below)... maybe mailman is trying more connections than postfix allows... but the weird thing is that i never had this problem before, so this has to do with some recent stmp changes. I'll investigate postfix & mailman further to see if i can figure out what exactly is going wrong... Ricardo. admin(32515): mlist.HandleRequest(request_id, v, comment) admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 124, in HandleRequest admin(32515): self.__handlepost(data, value, comment) admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 174, in __handlepost admin(32515): self.Post(msg) admin(32515): File "/usr/local/mailman/Mailman/MailList.py", line 1293, in Post admin(32515): Mailman.Handlers.HandlerAPI.DeliverToList(self, msg) admin(32515): File "/usr/local/mailman/Mailman/Handlers/HandlerAPI.py", line 55, in DeliverToList admin(32515): func(mlist, msg) admin(32515): File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 41, in process admin(32515): conn = smtplib.SMTP(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 182, in __init__ admin(32515): (code, msg) = self.connect(host, port) admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 216, in connect admin(32515): self.sock.connect(host, port) admin(32515): error: (111, 'Connection refused') -- Ricardo. -- From ricardo@rixhq.nu Tue Mar 21 20:34:14 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Tue, 21 Mar 2000 21:34:14 +0100 Subject: [Mailman-Developers] beta & smtp In-Reply-To: <20000321210635.B2014@miss-janet.com>; from ricardo@rixhq.nu on Tue, Mar 21, 2000 at 09:06:35PM +0100 References: <20000321210635.B2014@miss-janet.com> Message-ID: <20000321213414.C2014@miss-janet.com> On Tue, Mar 21, 2000 at 09:06:35PM +0100, Ricardo Kustner wrote: > refused (see below)... maybe mailman is trying more connections > than postfix allows... well i fixed it... it turned out that the default SMTPHOST was set to 'miss-janet.com' in Defaults.py ... I changed this to 'localhost' (in mm_cfg.py) and now it works again... I wonder why it was set to miss-janet.com though... (I'm not sure if it was there already or was changed during the upgrade) It seems like the choice of delivery method has been implemented as was discussed earlier on this list... where can i find some more info anywhere on what the choices are? Ricardo. > admin(32515): mlist.HandleRequest(request_id, v, comment) > admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 124, in HandleRequest > admin(32515): self.__handlepost(data, value, comment) > admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 174, in __handlepost > admin(32515): self.Post(msg) > admin(32515): File "/usr/local/mailman/Mailman/MailList.py", line 1293, in Post > admin(32515): Mailman.Handlers.HandlerAPI.DeliverToList(self, msg) > admin(32515): File "/usr/local/mailman/Mailman/Handlers/HandlerAPI.py", line 55, in DeliverToList > admin(32515): func(mlist, msg) > admin(32515): File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 41, in process > admin(32515): conn = smtplib.SMTP(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) > admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 182, in __init__ > admin(32515): (code, msg) = self.connect(host, port) > admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 216, in connect > admin(32515): self.sock.connect(host, port) > admin(32515): error: (111, 'Connection refused') > > > -- > Ricardo. > > -- > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > -- Ricardo. -- International Janet Jackson fanclub called MISS JANET. For more information write to: Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com Or check out our website: http://miss-janet.com From Benjamin B. Thomas" References: <20000321060210.689621CE3B@dinsdale.python.org> Message-ID: <200003212233.QAA31287@mail.indiansprings.org> I noticed a typo in the NEWS file during the lastest round of cvs commits: Cheers, benjy Index: NEWS =================================================================== RCS file: /projects/cvsroot/mailman/NEWS,v retrieving revision 1.14 diff -C2 -r1.14 NEWS *** NEWS 2000/03/21 06:04:14 1.14 --- NEWS 2000/03/21 21:54:55 *************** *** 30,34 **** this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the ! Mailman host. In practice, mail lossage has not be observed. For this reason cron/run_queue is no longer needed (see the --- 30,34 ---- this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the ! Mailman host. In practice, mail lossage has not been observed. For this reason cron/run_queue is no longer needed (see the From bwarsaw@cnri.reston.va.us Tue Mar 21 23:55:32 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 18:55:32 -0500 (EST) Subject: [Mailman-Developers] beta & smtp References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> Message-ID: <14552.3060.228549.718496@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> well i fixed it... it turned out that the default SMTPHOST was RK> set to 'miss-janet.com' in Defaults.py ... I changed this to RK> 'localhost' (in mm_cfg.py) and now it works again... I wonder RK> why it was set to miss-janet.com though... (I'm not sure if it RK> was there already or was changed during the upgrade) This was likely a result of the upgrade. I set SMTPHOST to the fqdn of the host that you're on. However, if your machine's primary alias was www.miss-janet.com, the SMTPHOST got the "www." stripped off. I'll bet that's what we're seeing here. There's a different configure variable that SMTPHOST should have gotten set to, called `URL'. These two conf variables are really mis-named because URL, in your case, would be www.miss-janet.com. The reason these are different is because in the first case, I'm trying to guess your domain for email purposes (e.g. ricardo@miss-janet.com), but in the second I'm trying to guess the host part of your url (e.g. www.miss-janet.com). For a machine named www.whatever, these will differ, but for a staging machine, it's probably called something like mydevhost.miss-janet.com. In that case, I want both the email part and the url part to be the entire host name. Yes this is all crufty and broken, and probably only useful for a small number of installations that use staging servers. I think I have a not-so-drastic fix though that I'd like you to try. See the patch below. BTW, I remember having some problems when using Postfix and just setting SMTPHOST to 'localhost', but I can't remember the details right now. RK> It seems like the choice of delivery method has been RK> implemented as was discussed earlier on this list... where can RK> i find some more info anywhere on what the choices are? There's currently only two, as described in Mailman/Defaults.py. Search for the variable DELIVERY_MODULE; there's an explanation and the alternative value in a comment. Let me know if this needs more explaining or documenting. -Barry -------------------- snip snip -------------------- Index: Defaults.py.in =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Defaults.py.in,v retrieving revision 1.97 diff -c -r1.97 Defaults.py.in *** Defaults.py.in 2000/03/21 06:24:58 1.97 --- Defaults.py.in 2000/03/21 23:16:09 *************** *** 115,121 **** SENDMAIL_CMD = '/usr/lib/sendmail' # SMTP host and port, when DELIVERY_MODULE is 'SMTPDirect' ! SMTPHOST = '@FQDN@' SMTPPORT = 0 # default from smtplib # 1 to use crypt for passwords instead of md5. --- 115,121 ---- SENDMAIL_CMD = '/usr/lib/sendmail' # SMTP host and port, when DELIVERY_MODULE is 'SMTPDirect' ! SMTPHOST = '@URL@' SMTPPORT = 0 # default from smtplib # 1 to use crypt for passwords instead of md5. Index: configure.in =================================================================== RCS file: /projects/cvsroot/mailman/configure.in,v retrieving revision 1.43 diff -c -r1.43 configure.in *** configure.in 2000/03/21 06:24:52 1.43 --- configure.in 2000/03/21 23:41:45 *************** *** 331,336 **** --- 331,338 ---- www = h elif not fqdn: fqdn = h + if www and fqdn: + break fp = open('conftest.out', 'w') if not www and fqdn: fp.write('%s\n%s\n' % (fqdn, fqdn)) Index: configure =================================================================== RCS file: /projects/cvsroot/mailman/configure,v retrieving revision 1.41 diff -c -r1.41 configure *** configure 2000/03/21 06:24:52 1.41 --- configure 2000/03/21 23:41:52 *************** *** 1,6 **** #! /bin/sh ! # From configure.in Revision: 1.42 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 --- 1,6 ---- #! /bin/sh ! # From configure.in Revision: 1.43 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 *************** *** 1366,1371 **** --- 1366,1373 ---- www = h elif not fqdn: fqdn = h + if www and fqdn: + break fp = open('conftest.out', 'w') if not www and fqdn: fp.write('%s\n%s\n' % (fqdn, fqdn)) *************** *** 1379,1392 **** $PYTHON conftest.py echo $ac_n "checking for default fully qualified host name""... $ac_c" 1>&6 ! echo "configure:1383: checking for default fully qualified host name" >&5 if test -z "$FQDN" then FQDN=`head -1 conftest.out` fi echo "$ac_t""$FQDN" 1>&6 echo $ac_n "checking for default URL host component""... $ac_c" 1>&6 ! echo "configure:1390: checking for default URL host component" >&5 if test -z "$URL" then URL=`tail -1 conftest.out` --- 1381,1394 ---- $PYTHON conftest.py echo $ac_n "checking for default fully qualified host name""... $ac_c" 1>&6 ! echo "configure:1385: checking for default fully qualified host name" >&5 if test -z "$FQDN" then FQDN=`head -1 conftest.out` fi echo "$ac_t""$FQDN" 1>&6 echo $ac_n "checking for default URL host component""... $ac_c" 1>&6 ! echo "configure:1392: checking for default URL host component" >&5 if test -z "$URL" then URL=`tail -1 conftest.out` *************** *** 1398,1409 **** for ac_func in strerror setregid syslog do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:1402: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:1404: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 1428,1434 ---- ; return 0; } EOF ! if { (eval echo configure:1432: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else *************** *** 1457,1473 **** # with the appropriate include. for lib in bsd socket inet; do echo $ac_n "checking for syslog in -l$lib""... $ac_c" 1>&6 ! echo "configure:1461: checking for syslog in -l$lib" >&5 Mailman_LIBS_save="$LIBS"; LIBS="$LIBS -l$lib" cat > conftest.$ac_ext < int main() { syslog(LOG_DEBUG, "Just a test..."); ; return 0; } EOF ! if { (eval echo configure:1471: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* echo "$ac_t""yes" 1>&6 cat >> confdefs.h <<\EOF --- 1459,1475 ---- # with the appropriate include. for lib in bsd socket inet; do echo $ac_n "checking for syslog in -l$lib""... $ac_c" 1>&6 ! echo "configure:1463: checking for syslog in -l$lib" >&5 Mailman_LIBS_save="$LIBS"; LIBS="$LIBS -l$lib" cat > conftest.$ac_ext < int main() { syslog(LOG_DEBUG, "Just a test..."); ; return 0; } EOF ! if { (eval echo configure:1473: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* echo "$ac_t""yes" 1>&6 cat >> confdefs.h <<\EOF *************** *** 1489,1495 **** # Checks for header files. echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 ! echo "configure:1493: checking how to run the C preprocessor" >&5 # On Suns, sometimes $CPP names a directory. if test -n "$CPP" && test -d "$CPP"; then CPP= --- 1491,1497 ---- # Checks for header files. echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 ! echo "configure:1495: checking how to run the C preprocessor" >&5 # On Suns, sometimes $CPP names a directory. if test -n "$CPP" && test -d "$CPP"; then CPP= *************** *** 1504,1516 **** # On the NeXT, cc -E runs the code through the compiler's parser, # not just through cpp. cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1514: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 1506,1518 ---- # On the NeXT, cc -E runs the code through the compiler's parser, # not just through cpp. cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1516: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** *** 1521,1533 **** rm -rf conftest* CPP="${CC-cc} -E -traditional-cpp" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1531: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 1523,1535 ---- rm -rf conftest* CPP="${CC-cc} -E -traditional-cpp" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1533: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** *** 1538,1550 **** rm -rf conftest* CPP="${CC-cc} -nologo -E" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1548: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 1540,1552 ---- rm -rf conftest* CPP="${CC-cc} -nologo -E" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1550: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** *** 1569,1580 **** echo "$ac_t""$CPP" 1>&6 echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 ! echo "configure:1573: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include --- 1571,1582 ---- echo "$ac_t""$CPP" 1>&6 echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 ! echo "configure:1575: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include *************** *** 1582,1588 **** #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1586: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 1584,1590 ---- #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1588: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** *** 1599,1605 **** if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF --- 1601,1607 ---- if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF *************** *** 1617,1623 **** if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF --- 1619,1625 ---- if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF *************** *** 1638,1644 **** : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') --- 1640,1646 ---- : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') *************** *** 1649,1655 **** exit (0); } EOF ! if { (eval echo configure:1653: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else --- 1651,1657 ---- exit (0); } EOF ! if { (eval echo configure:1655: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else *************** *** 1676,1692 **** do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 ! echo "configure:1680: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1690: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 1678,1694 ---- do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 ! echo "configure:1682: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1692: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** *** 1715,1726 **** # Checks for typedefs, structures, and compiler characteristics. echo $ac_n "checking for uid_t in sys/types.h""... $ac_c" 1>&6 ! echo "configure:1719: checking for uid_t in sys/types.h" >&5 if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF --- 1717,1728 ---- # Checks for typedefs, structures, and compiler characteristics. echo $ac_n "checking for uid_t in sys/types.h""... $ac_c" 1>&6 ! echo "configure:1721: checking for uid_t in sys/types.h" >&5 if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF *************** *** 1749,1755 **** fi echo $ac_n "checking type of array argument to getgroups""... $ac_c" 1>&6 ! echo "configure:1753: checking type of array argument to getgroups" >&5 if eval "test \"`echo '$''{'ac_cv_type_getgroups'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1751,1757 ---- fi echo $ac_n "checking type of array argument to getgroups""... $ac_c" 1>&6 ! echo "configure:1755: checking type of array argument to getgroups" >&5 if eval "test \"`echo '$''{'ac_cv_type_getgroups'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** *** 1757,1763 **** ac_cv_type_getgroups=cross else cat > conftest.$ac_ext < conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_type_getgroups=gid_t else --- 1784,1790 ---- } EOF ! if { (eval echo configure:1788: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_type_getgroups=gid_t else *************** *** 1796,1802 **** if test $ac_cv_type_getgroups = cross; then cat > conftest.$ac_ext < EOF --- 1798,1804 ---- if test $ac_cv_type_getgroups = cross; then cat > conftest.$ac_ext < EOF *************** *** 1824,1835 **** for ac_func in vsnprintf do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:1828: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:1830: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 1854,1860 ---- ; return 0; } EOF ! if { (eval echo configure:1858: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else From jwt@dskk.co.jp Wed Mar 22 01:25:12 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Wed, 22 Mar 2000 10:25:12 +0900 Subject: [Mailman-Developers] htmlformat.py missing , quotes on attributes Message-ID: <20000322102512.A803@mail.dskk.co.jp> --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii CVS of 2000-03-21 19:00 EST My /mailman/listinfo page was missing a tag. It looks like it is missing from all pages generated by mailman/htmlformat.py As long as I was looking at the HTML source, I noticed that it quoted the attribute values for some of the tags (like for the BODY tag), but not those for table, table rows, and cells. That led to things like 100% and #99CCFF not being quoted literals. add tag quote all attribute values -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="htmlformat.diff" --- Mailman/htmlformat.py.orig Tue Mar 21 15:58:15 2000 +++ Mailman/htmlformat.py Wed Mar 22 09:19:00 2000 @@ -121,7 +121,7 @@ output = output + ' NOWRAP' continue else: - output = output + ' %s=%s' %(string.upper(key), val) + output = output + ' %s="%s"' %(string.upper(key), val) return output @@ -132,7 +132,7 @@ for (key, val) in info.items(): if not key in valid_mods: continue - output = output + ' %s=%s' %(string.upper(key), val) + output = output + ' %s="%s"' %(string.upper(key), val) return output @@ -149,7 +149,7 @@ output = output + ' BORDER' continue else: - output = output + ' %s=%s' %(string.upper(key), val) + output = output + ' %s="%s"' %(string.upper(key), val) return output @@ -284,7 +284,7 @@ else: output = output + '>\n' output = output + Container.Format(self, indent) - output = output + '%s\n' % spaces + output = output + '%s\n%s\n' % (spaces, spaces) return output class HeadlessDocument(Document): --OgqxwSJOaUobr8KG-- From bwarsaw@cnri.reston.va.us Wed Mar 22 04:53:49 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 23:53:49 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 2.0 beta 1 Message-ID: <14552.20957.516043.218533@anthem.cnri.reston.va.us> I've just uploaded the Mailman 2.0 beta 1 tarball to www.list.org. I decided to name the new version "2.0" because of the architectural changes that have been made. See the excerpt from the NEWS file below for details of what's changed since version 1.1. Two important things to take note of. You will need Python 1.5.2 to run this version of Mailman. Also, if you are upgrading from Mailman 1.x you will need to read the UPGRADING file for instructions. I don't plan to make wider release announcements until 2.0 final is ready to go, but I also don't expect the beta cycle to be very long. We'll see! Enjoy, -Barry -------------------- snip snip -------------------- - A new bundled auto-responder has been added. You can now configure an autoresponse text for each list's primary addresses: listname@yourhost.com -- the general posting address listname-request@... -- the automated "request bot" address listname-admin@... -- the human administrator address - The standard UI now includes three logos at the bottom of the page: Dragon's Mailman logo, the Python Powered logo, and the GNU logo. All point to their respective home pages. - It is now possible to set the Reply-To: field on lists to an arbitrary address. NOTE: Reply-To: munging is generally considered harmful! However for some read-only lists, it is useful to direct replies to a parallel discussion list. - There is a new message delivery architecture which uses a pipeline processor for incoming and internally generated messages. Mailman no longer contains a bundled bulk-mailer; instead message delivery is handled completely by the MTA. Most MTAs give a high enough priority to connections from the localhost that mail will not be lost because of system load, but this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the Mailman host. In practice, mail lossage has not be observed. For this reason cron/run_queue is no longer needed (see the UPGRADING file for details). Also, you can choose whether you want direct smtp delivery, or delivery via the command line to a sendmail-compatible daemon. You can also easily add your own delivery module. See Mailman/Defaults.py for details. - A similar pipeline architecture for the parsing of bounce messages has been added. Most common bounce formats are now handled, including Qmail, Postfix, and DSN. It is now much easier to add new bounce detectors. - The approval pending architecture has also been revamped. Subscription requests and message posts waiting for admin approval are no longer kept in the config.db file, but in a separate requests.db file instead. - Finally made consistent the use of Sender:/From:/From_ in the matching of headers for such things as member-post-only. Now, if USE_ENVELOPE_SENDER is true, Sender: will always be chosen over From:, however the default has been changed to USE_ENVELOPE_SENDER false so that From: is always chosen over Sender:. In both cases, if no header is found, From_ (i.e. the envelope sender is used). Note that the variable is now misnamed! Most people want From: matching anyway and any are easily spoofable. - New scripts bin/move_list, bin/config_list - cron/upvolumes_yearly, cron/upvolumes_monthly, cron/archive, cron/run_queue all removed. Edit your crontab if you used these scripts. Other scripts removed: contact_transport, deliver, dumb_deliver. - Several web UI improvements, especially in the admin page. - Remove X-pmrqc: headers to prevent return reciepts for Pegasus mail users. - Security patch when using external archivers. - Honor "X-Archive: No" header by not putting this message in the archive. - Changes to the log file format. - The usual bug fixes. From jarrell@vt.edu Wed Mar 22 05:41:06 2000 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 22 Mar 2000 00:41:06 -0500 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.52206.999641.515081@anthem.cnri.reston.va.us> References: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> Message-ID: <4.2.0.58.20000322003046.04ba02a0@vtserf.cc.vt.edu> --=====================_106735433==_.ALT Content-Type: text/plain; charset="us-ascii" At 02:22 PM 3/21/00 -0500, you wrote: > >>>>> "RJ" == Ron Jarrell writes: > > RJ> Upgraded my test machine, which was running a month or two ago > RJ> cvs snapshot, and so far things are ok. Except for gateing > RJ> *to* a list, but someone already caught that. > >Right. That change should have been checked in by now, so doing a cvs >update should get you the fix to Mailman/Handlers/ToUsenet.py Will do. Oh, also (which you may have fixed in this latest round of checkins, I haven't grabbed today's yet) the cron Makefile still wanted to install run_queue. > RJ> Note that the images aren't in the cvs repository yet. > >The should be! Take a look at > > http://cvs.python.org/cgi-bin/viewcvs.cgi/mailman/misc/ Ah.. mailman/misc... I found mailman.jpg and dragonlogo.jpg in admin/www/images (which seemed a reasonably place for them), but not the others. Because having found some there, I didn't look in misc... >and you should find PythonPowered.png, gnu-head-tiny.jpg, and >mailman.jpg which are the three logos. > > RJ> (Is the python image really a PNG? Yuck.) > >Why yuck? My dilemma was this: PythonPowered.gif is purposefully >transparent around the edges of the oval, but we can't use gifs As the character on Saturday Night Live would say. "Oh. Never mind." I knew earlier netscapes didn't do pngs. At some point when I installed Plugger into my solaris netscape it picked up PNGs. But handed them to an image program that couldn't display them. I'd seen that my attempts to do some PNG graphs (using a PNG converted GIFgraph, since GD doesn't do gifs) failed miserably... Apparently inline PNGs however, quite transparently to me, were working fine... I just went through and deleted all the variants of the mime type and the external handler, and lo and behold, pngs display right now. Go figure. >because Mailman is Gnu. I'd have preferred jpegs for consistency, but >I couldn't figure out how to make the transparency work (I don't think >jpeg supports transparencies). No, they don't. Shame, really. If they did animation and transparancies, there'd mostly only be one format out there now. --=====================_106735433==_.ALT Content-Type: text/html; charset="us-ascii" At 02:22 PM 3/21/00 -0500, you wrote:

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> Upgraded my test machine, which was running a month or two ago
    RJ> cvs snapshot, and so far things are ok.  Except for gateing
    RJ> *to* a list, but someone already caught that.

Right.  That change should have been checked in by now, so doing a cvs
update should get you the fix to Mailman/Handlers/ToUsenet.py

Will do. 

Oh, also (which you may have fixed in this latest round of checkins, I haven't
grabbed today's yet) the cron Makefile still wanted to install run_queue.


    RJ> Note that the images aren't in the cvs repository yet.

The should be!  Take a look at

    http://cvs.python.org/cgi-bin/viewcvs.cgi/mailman/misc/

Ah.. mailman/misc... I found mailman.jpg and dragonlogo.jpg in admin/www/images
(which seemed a reasonably place for them), but not the others.  Because having found
some there, I didn't look in misc...


and you should find PythonPowered.png, gnu-head-tiny.jpg, and
mailman.jpg which are the three logos.
   
    RJ> (Is the python image really a PNG?  Yuck.)

Why yuck?  My dilemma was this: PythonPowered.gif is purposefully
transparent around the edges of the oval, but we can't use gifs

As the character on Saturday Night Live would say.  "Oh.  Never mind."

I knew earlier netscapes didn't do pngs.  At some point when I installed Plugger
into my solaris netscape it picked up PNGs.  But handed them to an image program
that couldn't display them.  I'd seen that my attempts to do some PNG graphs (using
a PNG converted GIFgraph, since GD doesn't do gifs) failed miserably... Apparently
inline PNGs however, quite transparently to me, were working fine...  I just went through
and deleted all the variants of the mime type and the external handler, and lo and behold,
pngs display right now.  Go figure.

because Mailman is Gnu.  I'd have preferred jpegs for consistency, but
I couldn't figure out how to make the transparency work (I don't think
jpeg supports transparencies).

No, they don't.  Shame, really.  If they did animation and transparancies, there'd
mostly only be one format out there now.
--=====================_106735433==_.ALT-- From rullfig@uchicago.edu Wed Mar 22 14:11:11 2000 From: rullfig@uchicago.edu (Roberto Ullfig) Date: Wed, 22 Mar 2000 08:11:11 -0600 Subject: [Mailman-Developers] Mailman keying on Sender: Field Message-ID: <38D8D47F.219AEA87@uchicago.edu> I noticed that Mailman keys on the Sender: field when you email in a subscription request. Is this really necessary? Is it possible to reconfigure Mailman to key on the From: field instead? Is this more or less desirable? Since confirmations are always in place it seems to me that there's enough protection as it is without using the Sender: field. -- Roberto Ullfig : rullfig@uchicago.edu Systems Administrator Networking Services and Information Technologies University of Chicago From secabeen@pobox.com Wed Mar 22 16:00:47 2000 From: secabeen@pobox.com (Ted Cabeen) Date: Wed, 22 Mar 2000 10:00:47 -0600 Subject: [Mailman-Developers] Mailman keying on Sender: Field In-Reply-To: Your message of "Wed, 22 Mar 2000 08:11:11 CST." <38D8D47F.219AEA87@uchicago.edu> Message-ID: <200003221600.KAA23077@entropy.uchicago.edu> In message <38D8D47F.219AEA87@uchicago.edu>, Roberto Ullfig writes: >I noticed that Mailman keys on the Sender: field when you email >in a subscription request. Is this really necessary? Is it >possible to reconfigure Mailman to key on the From: field >instead? Is this more or less desirable? Since confirmations are >always in place it seems to me that there's enough protection as >it is without using the Sender: field. That will be in the 2.0 release. It's supposed to be supported in 1.1, but it's a little broken. I posted a patch to 1.1 that allows From matching, so you can check the archives and find it if you don't want to wait. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen@pobox.com Check Website or finger for PGP Public Key secabeen@midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen@aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com From bwarsaw@cnri.reston.va.us Wed Mar 22 16:13:48 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 11:13:48 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> <4.2.0.58.20000322003046.04ba02a0@vtserf.cc.vt.edu> Message-ID: <14552.61756.968461.466277@anthem.cnri.reston.va.us> >>>>> "RJ" == Ron Jarrell writes: RJ> Oh, also (which you may have fixed in this latest round of RJ> checkins, I haven't grabbed today's yet) the cron Makefile RJ> still wanted to install run_queue. Well, it's fixed now! Thanks... :) RJ> Ah.. mailman/misc... I found mailman.jpg and dragonlogo.jpg in RJ> admin/www/images (which seemed a reasonably place for them), RJ> but not the others. Because having found some there, I didn't RJ> look in misc... Yeah, that directory is what gets published at www.list.org, but other than that it's pretty separate from the rest of the code. I'd like to reorganize and improve the www tree at some point. RJ> As the character on Saturday Night Live would say. "Oh. RJ> Never mind." :) RJ> No, they don't. Shame, really. If they did animation and RJ> transparancies, there'd mostly only be one format out there RJ> now. Or if Unisys would quit shooting themselves in the foot with LWZ. Still PNG is a nice format, so hopefully it'll start gaining more widespread use. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 16:39:15 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 11:39:15 -0500 (EST) Subject: [Mailman-Developers] Mailman keying on Sender: Field References: <38D8D47F.219AEA87@uchicago.edu> Message-ID: <14552.63283.411277.530643@anthem.cnri.reston.va.us> >>>>> "RU" == Roberto Ullfig writes: RU> I noticed that Mailman keys on the Sender: field when you RU> email in a subscription request. Is this really necessary? Is RU> it possible to reconfigure Mailman to key on the From: field RU> instead? Is this more or less desirable? Since confirmations RU> are always in place it seems to me that there's enough RU> protection as it is without using the Sender: field. In Mailman 2.0 (currently at beta 1), this has been made much more consistent. There's a configuration variable called USE_ENVELOPE_SENDER which controls this; the default is now to use From: followed by Sender: then the envelope sender. -Barry From ricardo@rixhq.nu Wed Mar 22 17:06:07 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 22 Mar 2000 18:06:07 +0100 Subject: [Mailman-Developers] beta & smtp In-Reply-To: <14552.3060.228549.718496@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 06:55:32PM -0500 References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> <14552.3060.228549.718496@anthem.cnri.reston.va.us> Message-ID: <20000322180607.A9914@miss-janet.com> Hi, On Tue, Mar 21, 2000 at 06:55:32PM -0500, Barry A. Warsaw wrote: > RK> set to 'miss-janet.com' in Defaults.py ... I changed this to > RK> 'localhost' (in mm_cfg.py) and now it works again... I wonder > RK> why it was set to miss-janet.com though... (I'm not sure if it > RK> was there already or was changed during the upgrade) > This was likely a result of the upgrade. I set SMTPHOST to the fqdn > of the host that you're on. However, if your machine's primary alias > was www.miss-janet.com, the SMTPHOST got the "www." stripped off. > I'll bet that's what we're seeing here. > Yes this is all crufty and broken, and probably only useful for a > small number of installations that use staging servers. I think I > have a not-so-drastic fix though that I'd like you to try. See the > patch below. in my case, mailman runs on www1.miss-janet.com and the website (including the A record for 'miss-janet.com') is on a entirely different server > BTW, I remember having some problems when using Postfix and just > setting SMTPHOST to 'localhost', but I can't remember the details > right now. it seems to work ok so far so i'm not complaining :) is that the only reason for not choosing localhost as default? > There's currently only two, as described in Mailman/Defaults.py. > Search for the variable DELIVERY_MODULE; there's an explanation and > the alternative value in a comment. Let me know if this needs more > explaining or documenting. later i discovered that it's mentioned in the NEWS file (thanks to the misspelling patch posted on the list :) ) so I had a look at Defaults.py... the info there is clear enough... Ricardo. -- From rullfig@uchicago.edu Wed Mar 22 17:15:55 2000 From: rullfig@uchicago.edu (Roberto Ullfig) Date: Wed, 22 Mar 2000 11:15:55 -0600 Subject: [Mailman-Developers] Mailman keying on Sender: Field References: <38D8D47F.219AEA87@uchicago.edu> <14552.63283.411277.530643@anthem.cnri.reston.va.us> Message-ID: <38D8FFCB.2A23BE0B@uchicago.edu> "Barry A. Warsaw" wrote: > > >>>>> "RU" == Roberto Ullfig writes: > > RU> I noticed that Mailman keys on the Sender: field when you > RU> email in a subscription request. Is this really necessary? Is > RU> it possible to reconfigure Mailman to key on the From: field > RU> instead? Is this more or less desirable? Since confirmations > RU> are always in place it seems to me that there's enough > RU> protection as it is without using the Sender: field. > > In Mailman 2.0 (currently at beta 1), this has been made much more > consistent. There's a configuration variable called > USE_ENVELOPE_SENDER which controls this; the default is now to use > From: followed by Sender: then the envelope sender. That sounds good. I have a related question that perhaps someone on this list can answer. Can the Sender: field be changed by sendmail configuration? For instance would masquerading ever effect this field or is changing the Sender: field verboten? -- Roberto Ullfig : rullfig@uchicago.edu Systems Administrator Networking Services and Information Technologies University of Chicago From bwarsaw@cnri.reston.va.us Wed Mar 22 17:48:15 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 12:48:15 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] confidentiality features References: <20000321174503.O16886@bsd.uchicago.edu> Message-ID: <14553.1887.233014.783985@anthem.cnri.reston.va.us> Please trim followups to mailman-developers@python.org... >>>>> "mjinks" == writes: mjinks> First of all, in testing it appears that although the mjinks> "From:" header is stripped, the "X-Sender:" still comes mjinks> through, as does the sender's IP address. We're in a mjinks> university, so back-tracing an IP address to a nearby mjinks> individual is not that tough, and could certainly be seen mjinks> as a gap for confidentiality. Could X-Sender and IP also mjinks> be stripped? Have I missed some detail? Mailman doesn't know about X-Sender, so it doesn't by default strip those. You'd probably also have to grok through Received: headers and others to truly anonymize the message. mjinks> On the other hand, this user wants to be able to peek mjinks> behind the curtain in those cases where confidentiality mjinks> needs to be violated -- for example if a poster to the mjinks> list claims to be suicidal or otherwise seems dangerous. mjinks> I showed the user that he'd see the real return address if mjinks> we set the list to be moderated, but he didn't like that mjinks> idea. Any clues? Can identifying information be made mjinks> available, say, to the list owner only? Here's the approach I would explore, using the 2.0 code base. Write a message handler module (see Mailman/Handlers/* for examples), calling it Anonymize.py. Put this in the pipeline such that every message passes through it before it's delivered to the archiver, or usenet, or the list. In this module, you'd strip or munge all the headers you want. To support lifting the curtain, you can store (securely, on the file system) whatever information gleaned out of the message is necessary to link the poster with the email message. You might even key both off of a randomly generated ID, which you'd poke into the outgoing message. Now that I think about it, it wouldn't be too hard to extend this idea into a general framework for email anonymizing. Given an MTA that can handle highly dynamic updates to it's alias database, you're "randomly generated ID" above would be used to create a Reply-To: address pointing back to your anonymizing service. Your add-on stuff would handle delivering back to the original user based on the random address. Oooh, what a neat idea! Let me know if you decide to play around with this. It'd be really cool to add some more anonymizing features in a future version. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 17:56:19 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 12:56:19 -0500 (EST) Subject: [Mailman-Developers] beta & smtp References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> <14552.3060.228549.718496@anthem.cnri.reston.va.us> <20000322180607.A9914@miss-janet.com> Message-ID: <14553.2371.220050.697558@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> it seems to work ok so far so i'm not complaining :) is that RK> the only reason for not choosing localhost as default? I think so, but now I'm not so sure. I agree that 'localhost' would be a better default, if it works. I'll do some testing with Postfix, but it would be nice to hear from those of you with other MTAs. -Barry From claw@kanga.nu Wed Mar 22 17:58:53 2000 From: claw@kanga.nu (J C Lawrence) Date: Wed, 22 Mar 2000 09:58:53 -0800 Subject: [Mailman-Developers] Mailman keying on Sender: Field In-Reply-To: Message from Roberto Ullfig of "Wed, 22 Mar 2000 08:11:11 CST." <38D8D47F.219AEA87@uchicago.edu> References: <38D8D47F.219AEA87@uchicago.edu> Message-ID: <1919.953747933@kanga.nu> On Wed, 22 Mar 2000 08:11:11 -0600 Roberto Ullfig wrote: > I noticed that Mailman keys on the Sender: field when you email in > a subscription request. Is this really necessary? Is it possible > to reconfigure Mailman to key on the From: field instead? Is this > more or less desirable? Since confirmations are always in place it > seems to me that there's enough protection as it is without using > the Sender: field. There's a documented value you can edit in mm_cfg.py to change this. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From gorgo@sztaki.hu Wed Mar 22 18:12:42 2000 From: gorgo@sztaki.hu (Gergely Madarasz) Date: Wed, 22 Mar 2000 19:12:42 +0100 (MET) Subject: [Mailman-Developers] mailman 2.0beta1 problem: Mail delivery failed: returning message to sender (fwd) Message-ID: Hello, I've just upgraded my test machine to 2.0beta1 ... I sent a test message to the list, it was delivered correctly to its members and then I got the error message attached below. Anyway it seems quite strange to me... first, why does scripts/post write anything to stdout, second, why does it write "starting" twice ? The logs/post file has the following: Mar 22 19:02:22 2000 (6870) post to test from gorgo@sztaki.hu, size=444, success Additionally in logs/error I have the following: Mar 22 19:02:22 2000 post(6870): starting Mar 22 19:02:22 2000 post(6870): ending -- Madarasz Gergely gorgo@sztaki.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ ---------- Forwarded message ---------- Date: Wed, 22 Mar 2000 19:02:23 +0100 From: Mail Delivery System To: gorgo@sztaki.hu Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: test@thunderchild.aszi.sztaki.hu: generated |/var/lib/mailman/mail/wrapper post test The following text was generated during the delivery attempt: ------ |/var/lib/mailman/mail/wrapper post test ------ starting ending starting ------ This is a copy of the message, including all the headers. ------ Return-path: Received: from lutra.sztaki.hu [193.225.86.1] by thunderchild.aszi.sztaki.hu with esmtp (Exim 3.12 #1 (Debian)) id 12XpSX-0001ml-00; Wed, 22 Mar 2000 19:02:21 +0100 Received: from localhost by sztaki.hu (PMDF V5.2-32 #42635) with ESMTP id <0FRU004014RXGU@sztaki.hu> for test@thunderchild.aszi.sztaki.hu; Wed, 22 Mar 2000 19:02:21 +0100 (MET) Date: Wed, 22 Mar 2000 19:02:21 +0100 (MET) From: Gergely Madarasz Subject: proba To: test@thunderchild.aszi.sztaki.hu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII humm -- Madarasz Gergely gorgo@sztaki.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From Gergely Madarasz Wed Mar 22 18:24:12 2000 From: Gergely Madarasz (Gergely Madarasz) Date: Wed, 22 Mar 2000 19:24:12 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 Message-ID: Hello, Previous versions always put Sender: -admin@ in all mails sent out to the list... it seems that with the new sendmail delivery module it has some issues... with exim the mailman user has to be listed in the trusted_users option for this to work, if it is not listed, the Sender: header becomes mailman@ -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From ricardo@rixhq.nu Wed Mar 22 18:30:38 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 22 Mar 2000 19:30:38 +0100 Subject: [Mailman-Developers] lock lifetime Message-ID: <20000322193038.A10212@miss-janet.com> One of the changes I have to make for my server is to increase the lock lifetime. I suspect that other people who don't have a speedy server either, might get the same problems as me... so maybe it should be mentioned in the install docs and/or moved to a global variable in mm_cfg.py... Below is an excerpt of a message from Thomas who fixed this for me.... For my server I've changed this to 300. "... In any case, you can easily try it out; in Mailman/MailList.py, on or around line 282, there should be a 'lifetime = 60', inside the constructor for the maillists' lockfile. Changing the '60' in, say, '600', should give you better mileage, at least until your machine gets so heavily loaded that a simple admin request takes ten full minutes to process ;) " Ricardo. -- From Nigel.Metheringham@VData.co.uk Wed Mar 22 18:35:43 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Wed, 22 Mar 2000 18:35:43 +0000 Subject: [Mailman-Developers] beta & smtp In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Wed, 22 Mar 2000 12:56:19 EST." <14553.2371.220050.697558@anthem.cnri.reston.va.us> Message-ID: bwarsaw@cnri.reston.va.us said: > I think so, but now I'm not so sure. I agree that 'localhost' would > be a better default, if it works. I'll do some testing with Postfix, > but it would be nice to hear from those of you with other MTAs. Exim will need localhost or 127.0.0.1/32 listing as an allowed relayer - this is already in the exim/mailman HOWTO. gorgo@caesar.elte.hu said: > Previous versions always put Sender: -admin@ in all > mails sent out to the list... it seems that with the new sendmail > delivery module it has some issues... with exim the mailman user has > to be listed in the trusted_users option for this to work, if it is > not listed, the Sender: header becomes mailman@ That will be the case. I would tend to use smtp injection personally, and also prevent exim doing significant lookups on the incoming addresses - ie no recipient verification. RSN I'll put mailman 2beta on the exim site and knock the config into shape for it... and then look at the bouncer module. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From bwarsaw@cnri.reston.va.us Wed Mar 22 18:38:59 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 13:38:59 -0500 (EST) Subject: [Mailman-Developers] beta & smtp References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> <14552.3060.228549.718496@anthem.cnri.reston.va.us> <20000322180607.A9914@miss-janet.com> <14553.2371.220050.697558@anthem.cnri.reston.va.us> Message-ID: <14553.4931.198854.759224@anthem.cnri.reston.va.us> >>>>> "BAW" == writes: BAW> I think so, but now I'm not so sure. I agree that BAW> 'localhost' would be a better default, if it works. I'll do BAW> some testing with Postfix, but it would be nice to hear from BAW> those of you with other MTAs. It seems to work fine for Postfix. I guess I'll make this change. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 19:00:55 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 14:00:55 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: Message-ID: <14553.6247.676809.133555@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Hello, GM> Previous versions always put Sender: -admin@ GM> in all mails sent out to the list... it seems that with the GM> new sendmail delivery module it has some issues... with exim GM> the mailman user has to be listed in the trusted_users option GM> for this to work, if it is not listed, the Sender: header GM> becomes mailman@ Is that also true if you use SMTPDirect? From gorgo@caesar.elte.hu Wed Mar 22 19:04:02 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 22 Mar 2000 20:04:02 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: <14553.6247.676809.133555@anthem.cnri.reston.va.us> Message-ID: On Wed, 22 Mar 2000, Barry A. Warsaw wrote: > >>>>> "GM" == Gergely Madarasz writes: > > GM> Hello, > > GM> Previous versions always put Sender: -admin@ > GM> in all mails sent out to the list... it seems that with the > GM> new sendmail delivery module it has some issues... with exim > GM> the mailman user has to be listed in the trusted_users option > GM> for this to work, if it is not listed, the Sender: header > GM> becomes mailman@ > > Is that also true if you use SMTPDirect? I didn't try but I'm pretty sure that it is not. Exim can check usernames, etc, only if invoked directly, not thru port 25. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From bwarsaw@cnri.reston.va.us Wed Mar 22 19:06:12 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 14:06:12 -0500 (EST) Subject: [Mailman-Developers] lock lifetime References: <20000322193038.A10212@miss-janet.com> Message-ID: <14553.6564.572812.203295@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> "... In any case, you can easily try it out; in RK> Mailman/MailList.py, on or around line 282, there should be a RK> 'lifetime = 60', inside the constructor for the maillists' RK> lockfile. Changing the '60' in, say, '600', should give you RK> better mileage, at least until your machine gets so heavily RK> loaded that a simple admin request takes ten full minutes to RK> process ;) " One other gotcha, if you use bin/withlist to open a locked list and then exit the interpreter without doing an explicit m.Unlock(), you're list will be locked out for the duration. Still, I'm willing to put something in Defaults.py like this: # How long is the default lifetime for the MailList object lock, in seconds? LIST_LOCK_LIFETIME = 120 and then set lifetime at line 282 to use this variable. Will that work for you? -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 19:11:46 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 14:11:46 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: <14553.6247.676809.133555@anthem.cnri.reston.va.us> Message-ID: <14553.6898.288580.184278@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I didn't try but I'm pretty sure that it is not. Exim can GM> check usernames, etc, only if invoked directly, not thru port GM> 25. Gotcha. I agree with Nigel that SMTPDirect is the better way to go (no chance of funky shell tricks leaking through either). That should be the default with 2.0beta1. I consider Sendmail.py a proof-of-concept at best; I hacked it together quickly so that I could make sure the new architecture would work. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 19:21:26 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 14:21:26 -0500 (EST) Subject: [Mailman-Developers] mailman 2.0beta1 problem: Mail delivery failed: returning message to sender (fwd) References: Message-ID: <14553.7478.896273.785720@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I've just upgraded my test machine to 2.0beta1 ... I sent a GM> test message to the list, it was delivered correctly to its GM> members and then I got the error message attached below. GM> Anyway it seems quite strange to me... first, why does GM> scripts/post write anything to stdout, second, why does it GM> write "starting" twice ? The logs/post file has the GM> following: Mar 22 19:02:22 2000 (6870) post to test from GM> gorgo@sztaki.hu, size=444, success | Additionally in logs/error I have the following: | Mar 22 19:02:22 2000 post(6870): starting | Mar 22 19:02:22 2000 post(6870): ending It is normal to see those messages in logs/error. That's useful debugging information that should probably be turned off in 2.0 final. I think I understand why you're getting output to stdout. Look in scripts/post and change LogStdErr("error", "post") to LogStdErr("error", "post", tee_to_stdout=0) The question is, why haven't I seen this with Postfix? Does it just get chucked? I definitely don't see it in my syslog (and I'm logging all mail.* messages in my syslog.conf. Weird. I also understand why you see it twice. It would be possible if there was some kind of permission problem with logs/error, but you're seeing messages in that file, so that can't be it. -Barry From gorgo@caesar.elte.hu Wed Mar 22 19:29:40 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 22 Mar 2000 20:29:40 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: <14553.6898.288580.184278@anthem.cnri.reston.va.us> Message-ID: On Wed, 22 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > >>>>> "GM" == Gergely Madarasz writes: > > GM> I didn't try but I'm pretty sure that it is not. Exim can > GM> check usernames, etc, only if invoked directly, not thru port > GM> 25. > > Gotcha. I agree with Nigel that SMTPDirect is the better way to go > (no chance of funky shell tricks leaking through either). That should > be the default with 2.0beta1. Actually I think that a wrong sender header is more acceptable than the increased possibility of mails getting lost... ;) The first problem can be easily noticed and fixed, while the second is not that easy to discover... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From ricardo@rixhq.nu Wed Mar 22 20:15:25 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 22 Mar 2000 21:15:25 +0100 Subject: [Mailman-Developers] lock lifetime In-Reply-To: <14553.6564.572812.203295@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Wed, Mar 22, 2000 at 02:06:12PM -0500 References: <20000322193038.A10212@miss-janet.com> <14553.6564.572812.203295@anthem.cnri.reston.va.us> Message-ID: <20000322211525.C10212@miss-janet.com> Hi, On Wed, Mar 22, 2000 at 02:06:12PM -0500, Barry A. Warsaw wrote: > One other gotcha, if you use bin/withlist to open a locked list and > then exit the interpreter without doing an explicit m.Unlock(), you're > list will be locked out for the duration. well I haven't used bin/withlist before, but maybe it could issue a warning when it runs? > Still, I'm willing to put something in Defaults.py like this: > # How long is the default lifetime for the MailList object lock, in seconds? > LIST_LOCK_LIFETIME = 120 > and then set lifetime at line 282 to use this variable. > Will that work for you? that would be great... thanks :) Ricardo. -- From bwarsaw@cnri.reston.va.us Wed Mar 22 20:58:36 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 15:58:36 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: <14553.6898.288580.184278@anthem.cnri.reston.va.us> Message-ID: <14553.13308.285211.662001@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Actually I think that a wrong sender header is more acceptable GM> than the increased possibility of mails getting lost... ;) The GM> first problem can be easily noticed and fixed, while the GM> second is not that easy to discover... True. Such lossage should at least get logged in logs/error, and I haven't in practice seen any problems on Python.Org, but you are right (as others have also pointed out). Some fallback mechanism should be implemented so that mail doesn't get lost when using SMTPDirect. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 21:18:48 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 16:18:48 -0500 (EST) Subject: [Mailman-Developers] lock lifetime References: <20000322193038.A10212@miss-janet.com> <14553.6564.572812.203295@anthem.cnri.reston.va.us> <20000322211525.C10212@miss-janet.com> Message-ID: <14553.14520.677676.569943@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> well I haven't used bin/withlist before, but maybe it could RK> issue a warning when it runs? Actually, I just remembered sys.exitfunc! I can set that up to unlock a locked list automatically at interpreter exit. I don't want it to implicitly save the list though -- you'll still have to do that manually if you fiddle with it from the interpreter prompt. Note that this function doesn't run if the interpreter exits because of a signal or os._exit() call. -Barry From sigma@pair.com Wed Mar 22 22:40:20 2000 From: sigma@pair.com (sigma@pair.com) Date: Wed, 22 Mar 2000 17:40:20 -0500 (EST) Subject: [Mailman-Developers] PairList error (fwd) Message-ID: <20000322224020.23969.qmail@smx.pair.com> In the last week or so, we've been seeing the following error and traceback on several pages, including our main listinfo page at http://www.pairlist.net/mailman/listinfo/ I've searched and found nothing about this error. Can someone point me in the right direction, hopefully? Thanks, Kevin Martin sigma@pair.com ----- Forwarded message ----- Bug in Mailman version 1.2 (experimental) We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/usr/mailman/scripts/driver", line 112, in run_main main() File "/usr/mailman/Mailman/Cgi/admin.py", line 67, in main mlist = MailList.MailList(listname) File "/usr/mailman/Mailman/MailList.py", line 69, in __init__ self.Load() File "/usr/mailman/Mailman/MailList.py", line 839, in Load raise Errors.MMBadListError, ('Failed to unmarshal config info: ' TypeError: __add__ nor __radd__ defined for these operands Environment variables: Variable Value DOCUMENT_ROOT /usr/www SERVER_ADDR 216.92.1.92 HTTP_ACCEPT_ENCODING gzip SERVER_PORT 80 PATH_TRANSLATED /usr/www/isc-agent-newsletter GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_LANGUAGE en,zh-CN SERVER_NAME www.pairlist.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.7 [en] (WinNT; U) HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* REQUEST_URI /mailman/admin/isc-agent-newsletter PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin QUERY_STRING SCRIPT_FILENAME /usr/mailman/cgi-bin/admin PATH_INFO /isc-agent-newsletter HTTP_HOST www.pairlist.net REQUEST_METHOD GET SERVER_SIGNATURE SCRIPT_NAME /mailman/admin SERVER_ADMIN webmaster@pairlist.net SERVER_SOFTWARE Apache/1.3.9 (Unix) PYTHONPATH /usr/mailman SERVER_PROTOCOL HTTP/1.0 REMOTE_PORT 1047 From Dan Mick Thu Mar 23 06:24:01 2000 From: Dan Mick (Dan Mick) Date: Wed, 22 Mar 2000 22:24:01 -0800 (PST) Subject: [Mailman-Developers] check_perms bug?... Message-ID: <200003230624.WAA12783@utopia.West.Sun.COM> Somehow, my /home/mailman/lists directory managed to get set with permissions check_perms didn't check for; it was set to d-wx-ws--x/mailman/mailman, which caused mailcmd to be unable to list the directory (no read perms). I fixed it once I figured it out, but I had a lot of check_perms runs in there before I finally figured it out...mostly because I was confused about what 'x' really means on a directory. But check_perms could have saved me time if it had checked for 'owner-and-group-read'; I think it should. From Nigel.Metheringham@VData.co.uk Thu Mar 23 09:33:10 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Thu, 23 Mar 2000 09:33:10 +0000 Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Wed, 22 Mar 2000 15:58:36 EST." <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: >>>>> "GM" == Gergely Madarasz writes: GM> Actually I think that a wrong sender header is more acceptable GM> than the increased possibility of mails getting lost... ;) The GM> first problem can be easily noticed and fixed, while the GM> second is not that easy to discover... bwarsaw@cnri.reston.va.us said: > True. Such lossage should at least get logged in logs/error, and I > haven't in practice seen any problems on Python.Org, but you are right > (as others have also pointed out). Some fallback mechanism should be > implemented so that mail doesn't get lost when using SMTPDirect. We have ended up with a nasty loop here - which means that using SMTP injection I can't stop mail handling (or shut down) on a loaded machine. If I kill the SMTP listener and queue runner, then messages stop being injected into mailman, but any already launched mailman instances will be hit by a brick wall as they try to hand off their messages. A little careful tampering with using an inject to queue only (ie no direct injection into mailman) and a separate queue runner would allow this to be sequenced right, as would some nasty hacks allowing differential handling of smtp coming in from remote addresses and localhost... but all of this is nasty hacking to get round the fact that the MTA and mailman are in a deadly embrace and getting them out of it without losing mail is difficult. On that basis I think on my boxes I am going to have to look at injection through the sendmail CLI which would allow me to kill the smtp listener without mail lossage. The downside of that is it is a harder hit in terms of process starting (at least for exim), error handling is less good, and sendmail CLIs are notoriously strange. One method that may be possible would be to write BSMTP wrapped messages to a directory, and use a (very simple) forked program at the end to feed them to the MTA on localhost, and if successful delete the spooled BSMTP. A cron job could also pick up these spools every so often and attempt to inject them. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From gorgo@caesar.elte.hu Thu Mar 23 11:46:13 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 12:46:13 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: On Wed, 22 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > >>>>> "GM" == Gergely Madarasz writes: > > GM> Actually I think that a wrong sender header is more acceptable > GM> than the increased possibility of mails getting lost... ;) The > GM> first problem can be easily noticed and fixed, while the > GM> second is not that easy to discover... > > True. Such lossage should at least get logged in logs/error, and I > haven't in practice seen any problems on Python.Org, but you are right > (as others have also pointed out). Some fallback mechanism should be > implemented so that mail doesn't get lost when using SMTPDirect. I'm now working on modifying smtplib.py and SMTPDirect to have the possibility to work with a pipe to sendmail -bs, not only a socket. This would fix all the problems listed up there... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From gorgo@caesar.elte.hu Thu Mar 23 13:37:15 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 14:37:15 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message-ID: On Thu, 23 Mar 2000, Gergely Madarasz wrote: > I'm now working on modifying smtplib.py and SMTPDirect to have the > possibility to work with a pipe to sendmail -bs, not only a socket. This > would fix all the problems listed up there... I've got it working... now smtplib can be told to use '/path/to/sendmail -bs' instead of connecting to localhost:25, and talk smtp there (no addresses in the shell, perhaps a bit better error handling). There is still a problem though... the Sender header gets rewritten this way too... but now it becomes nobody@, I haven't got the faintest clue why this happens, no process should run as nobody here... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From Nigel.Metheringham@VData.co.uk Thu Mar 23 13:44:02 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Thu, 23 Mar 2000 13:44:02 +0000 Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message from Gergely Madarasz of "Thu, 23 Mar 2000 14:37:15 +0100." Message-ID: gorgo@caesar.elte.hu said: > I've got it working... now smtplib can be told to use '/path/to/ > sendmail -bs' instead of connecting to localhost:25, and talk smtp > there (no addresses in the shell, perhaps a bit better error > handling). There is still a problem though... the Sender header gets > rewritten this way too... but now it becomes nobody@, I > haven't got the faintest clue why this happens, no process should run > as nobody here... The MTA should still know the UID its invoked under - exim will have the same Sender: problems as a straight CLI, and so the invoking user will still need to be trusted (or your MTA's equivalent). Also any loading issues from command line invocation still apply to an "mta -bs" invocation - although its probable that I am simply overly paranoid about this. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From gorgo@caesar.elte.hu Thu Mar 23 13:47:18 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 14:47:18 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message-ID: On Thu, 23 Mar 2000, Nigel Metheringham wrote: > gorgo@caesar.elte.hu said: > > I've got it working... now smtplib can be told to use '/path/to/ > > sendmail -bs' instead of connecting to localhost:25, and talk smtp > > there (no addresses in the shell, perhaps a bit better error > > handling). There is still a problem though... the Sender header gets > > rewritten this way too... but now it becomes nobody@, I > > haven't got the faintest clue why this happens, no process should run > > as nobody here... > > The MTA should still know the UID its invoked under - exim will have > the same Sender: problems as a straight CLI, and so the invoking user > will still need to be trusted (or your MTA's equivalent). Yeah, so one problem remains... (but why nobody?) > Also any loading issues from command line invocation still apply to an > "mta -bs" invocation - although its probable that I am simply overly > paranoid about this. The Sendmail delivery module passed the recipients in the command line thru a shell. The modified SMTPDirect module passes the recipients in SMTP commands. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From gorgo@caesar.elte.hu Thu Mar 23 14:07:06 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 15:07:06 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1649071771-1683543110-953820426=:31790 Content-Type: TEXT/PLAIN; charset=US-ASCII And here is the patch... I guess it needs a customizable sendmail path in Defaults.py.in, and a bit more error handling, but it works... Please include it in the next beta, even if the default will be not to use this... if SMTPCOMMANDLINE is an empty string, it works just as before -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ ---1649071771-1683543110-953820426=:31790 Content-Type: APPLICATION/octet-stream; name="mailman-smtp.diff.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: H4sICDMk2jgCA21haWxtYW4tc210cC5kaWZmAKVXUXObRhB+Nr9i6zwgjSQM 2HIkZtxxJk4nmcZ2JnafOh0FwUm6CXD0Dqyqnf737t6BQLIkyykPQhx7e3vf fvvtEfPZDAalhDTkSRpmA99xp6wIvbNbM3B2w2ZhmRTKyVcOz57ZDVRa5HuM rcFgcKzjk8dFCbehBP8cvItgOApcD3zXda1er/eqVbc9XQQXI+Pp+hoGnjfq X0KPbp4L19cWPNw+fvl4//B4AnAF9vVvXz9f22b0y/3XR1hfV+DCoesNxCYO mEmRAkWY8KkFVu8NRCLFQGNIeMagEDBnBd3CTK8DRZh859kccinmMkz7EHMl 2TyU8To6tI3J0zouPoNMFMDSvFhZPRp+f397++7u5vOnuw86XPusVPJMTXl2 plgWE4YwmCrb6lkYrEcBlIpBJFc5xiwk5KFSSyFjBTxTBQtjEDNI46FD9u+1 WRqu9LJo9h1EBmGSQL4qFviX5uCj0tY3IrMLiBZhNscNL7iCpzApGU6JGKxE CYvwiSEcqlAgyyzD3TuOY8Uv0vEj4pAwqc5oxzdcsqjAtL9AkN2TDtNz95yT R9yEJpcH7tvAHwbDo2m6z+MmXYeBO27oej7qv4We/iWuVjzj4TwTmLrlghUL JmHJIGMspoxKtpS8qDBPRVwmzAwj9f4suVrgGwN87S0REaZSUlodM1a4yJ6C p8yhn07XGtBoJLIMxyteO7SJTppOotncqUnah9YAsbRr9X506sZAi9pdE6Nk MyRvjF7/+beKWq4Ca12N+ullOhnuYlBndXAvkmnXlMNU2jXj5KHM4E48gT8C bxR4XuBegjcej48g0k5/bRohh9DfeUOjC5dED38NjWwbFc4CnuZCFqCQAKyw etVjLnKW+c3bQmJxrh8la/7OopHvG1W91Dz1LsctorJFIiaSqRyTdCcyZkZj wdSEUeCkqBiGJhdKJ0wmPOPFZNJRLJn1YSFUQSpm90Evh9bdwPDpOOt+Lbta deldt0WQ09PTT+iAhwn/m0GIBbQ0EoYK5RA69fVpBipnEZ9xFvfhGy1kAxYX 1VEWpoxEkv5LlgosPB0IVtxywSMsNmHweTvW+IzcFj5VFM0D7cTR0ExmLCxK xK7Fb7pQ9Ml/YECrr04kYob1ouZdqjLyQhWH+tIha4NIVYqvmrOBYNfaaHcY CrmAn67A993AetYPZchRonT1GscfpBSyta6ZYvAZ+xqf8fmL+MRsWs4T9sQS jLt5aBOp3kjDjCsbVS5MdO520+nYOS+Sqtqsbu+GDNQmYc6fWKa9bJOLuEN2 mkvYpxUsebHAKZFIcGrnW2B3sT0niVii3k1XxNUynTLZ12cCgs/3vP4Yer7n 972LDfzqi/0VsbwuZicsBJ8wSseOvDW5M8LgaMM+nGa4szJlkkd6H6cbtKRD AY0GNVKU+AkJecNVnT9ySowzvs2tUz29+2WCCo/SXz0/3L//dfLw+PXDu9tu 4wZX22bCz+Diwri3AuwqkwEmbYP+z8M4XCWa4OtUB5vls/aT85xoYETT+UK3 805rXt/t7plZAaGVcW3BErV3qR9G7mDkm+v/T4z3B74T6y01IlG40jPwfCxZ nqw6XetgSC7UIZ3WIZ1qcWmmSYZCmrVWMBXjX1JH9M99LJxdBdMETmfnDhbO lv7VFdWqkYMi+MDkE5M3XFWBsrhjmzFdO+tRu9tmQ71pStYhCjqFiBY8iR19 +jPhHmE9S0q1aINs+PeKLeQJC/E1nuHXEopqxSWKJrk1YA+1uvuXXv3NtVPe 6ahw9fsfzzM+43iIxY5LVN1qfc37q1bK0vA7o8GOLaf2FhC1UzLch+irHB6X pLZLnQL6SNRJaPaLRwY08rbwrxrN2osj8cuMBjvPO7Kxpa4UaOSH7iUhP8Sv 3U2ab6Kwr2QT/Mhor/JMtwYbcrkPhGbTy5AjP5q3z4Soao3UkfFrxbTjrQb7 yGTKs1B/4xheohuluMgcotN/TmnHAdIQAAA= ---1649071771-1683543110-953820426=:31790-- From bwarsaw@cnri.reston.va.us Thu Mar 23 14:18:35 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 23 Mar 2000 09:18:35 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: <14554.10171.237683.647143@anthem.cnri.reston.va.us> >>>>> "NM" == Nigel Metheringham writes: NM> from remote addresses and localhost... but all of this is NM> nasty hacking to get round the fact that the MTA and mailman NM> are in a deadly embrace and getting them out of it without NM> losing mail is difficult. I'm convinced. And for weird synchronicity, last night I had to do something very similar on python.org and got frightened out of my mind at the prospects of losing email (and oddly enough, not at the weird sleep-debt driven hallucinations I was having :). I will work on robustifying smtp injection for 2.0 beta 2. -Barry From jae@ilk.de Thu Mar 23 00:58:51 2000 From: jae@ilk.de (Juergen A. Erhard) Date: Thu, 23 Mar 2000 01:58:51 +0100 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.3965.171599.618432@anthem.cnri.reston.va.us> (bwarsaw@cnri.reston.va.us) References: <14551.3965.171599.618432@anthem.cnri.reston.va.us> Message-ID: <23032000.1@sanctum.jae.ddns.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "BAW" =3D=3D Barry A Warsaw writes: [...] BAW> 1) I've thought about being really parental about the upgrade, by BAW> essentially forcing people to read the UPGRADING file before "m= ake" BAW> will succeed. I think I have a trick that will work, but I'm n= ot BAW> sure it's a good idea. On the one hand it /might/ (only might)= BAW> save lazy or novice upgraders some headaches by forcing them to= BAW> read the manual first. BAW> One the other hand, it'll be really annoying either to those wh= o BAW> are doing a fresh install, or who are upgrading but know what BAW> they're doing. So, do you think it would be a good idea to for= ce BAW> everyone to read UPGRADING before "make" succeeds? I don't think it's worth the bother... for one, you can't *really* ensure everybody has read it[1]. And even if you can, you can't really make them *follow* it ;-) *Might* is the word to watch here... it *might* save some folks some trouble. But it *will* annoy many others. So, I'd not do this... I generally don't like mothering software packages ("Are you *really* sure you want to quit?"-like stuff... mostly seen on Windoze, but quite a number of GNOME apps seem to have been infected with this virus (I'd guess KDE is similar, but I can't say)). Bye, J [1] To closest way I can think of[2]: put it on screen, make the user scroll through it, but at a max speed of 1 line per second (which still might be to quick ;-) and make this process *completely* unstoppable. Oh, and keep the user from editing out this part of the Makefile ;-)) [2] And I shudder to think ;-) PS: Of course, I expect the .deb (and .rpm) packagers to show a warning upon or prior to upgrade... - -- = J=FCrgen A. Erhard eMail: jae@ilk.de phone: (GERMANY) 0721 27326 My WebHome: http://members.tripod.com/Juergen_Erhard "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?" -- Michael K. Johnson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Use Mailcrypt and GnuPG iEYEARECAAYFAjjZbEgACgkQN0B+CS56qs2QvQCfR0rrdal9pgIn1r6W+lvd9/0W /YEAn2BmZlVGfkBI2KoLvh14kemqWtgD =3DgUgn -----END PGP SIGNATURE----- From csf@moscow.com Thu Mar 23 18:08:14 2000 From: csf@moscow.com (Michael Yount) Date: Thu, 23 Mar 2000 10:08:14 -0800 Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: ; from Nigel.Metheringham@VData.co.uk on Thu, Mar 23, 2000 at 09:33:10AM +0000 References: <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: <20000323100814.A1943@moscow.com> On Thu, Mar 23, 2000 at 09:33:10AM +0000, Nigel Metheringham wrote: > > bwarsaw@cnri.reston.va.us said: > > True. Such lossage should at least get logged in logs/error, and I > > haven't in practice seen any problems on Python.Org, but you are right > > (as others have also pointed out). Some fallback mechanism should be > > implemented so that mail doesn't get lost when using SMTPDirect. > > We have ended up with a nasty loop here - which means that using SMTP > injection I can't stop mail handling (or shut down) on a loaded > machine. If I kill the SMTP listener and queue runner, then messages > stop being injected into mailman, but any already launched mailman > instances will be hit by a brick wall as they try to hand off their > messages. > > A little careful tampering with using an inject to queue only (ie no > direct injection into mailman) and a separate queue runner would allow > this to be sequenced right, as would some nasty hacks allowing > differential handling of smtp coming in from remote addresses and > localhost... but all of this is nasty hacking to get round the fact > that the MTA and mailman are in a deadly embrace and getting them out > of it without losing mail is difficult. This is similar to how Mj2 handles incoming mail. In queueing mode, incoming mail is written to a queue directory by the mj_enqueue script. mj_enqueue forks an mj_queueserv process (if it isn't already running) to handle the incoming mail. mj_queueserv will fork one or more mj_queuerun processes, which go through each of the queue directories in turn, locking and processing messages. When Mj2 attempts to deliver a message to a mailing list, it consults the delivery rules for the list in question: one or more primary and backup hosts can be specified. The primary hosts are used in round-robin fashion. If an SMTP session with a primary host fails three times, the backup hosts (localhost by default) are used. If the backup hosts fail, the queue runner aborts, and the message is left in the queue. The next queue runner to process a posted message will mark it as having a duplicate message-id, move the message out of the queue, and notify the list owner. We've recently been battling problems when an SMTP session times out during RCPT TO. Originally, Mj2 would attempt to deliver again to the same address (up to 25 times!); we're testing an alternative approach, which defers these addresses until the end of the delivery cycle. An address that fails twice during RCPT TO simply won't receive the message. It appears from SMTPDirect and smtplib that mailman doesn't use time limits when issuing SMTP commands. Perhaps that is a better approach. Listar and Mj2 use select(). Mj2 doesn't have a way to avoid the "deadly embrace," but it would be fairly easy to modify the queue server to support a "queue but don't process" mode. The Mj2 implementation is far from perfect, but perhaps mailman could benefit from some of our mistakes. Michael > > > Nigel. > -- > [ - Opinions expressed are personal and may not be shared by VData - ] > [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] > [ Phone: +44 1423 850000 Fax +44 1423 858866 ] > From Dan Mick Fri Mar 24 01:12:46 2000 From: Dan Mick (Dan Mick) Date: Thu, 23 Mar 2000 17:12:46 -0800 (PST) Subject: [Mailman-Developers] Betas coming soon Message-ID: <200003240112.RAA04009@utopia.West.Sun.COM> > [1] To closest way I can think of[2]: put it on screen, . . . > [2] And I shudder to think ;-) Hey, nesting footnotes is illegal. Somebody arrest that guy. ;) From camus@deesse.univ-lemans.fr Fri Mar 24 13:06:44 2000 From: camus@deesse.univ-lemans.fr (Matthieu CAMUS (IUP MIME - 96000937)) Date: Fri, 24 Mar 2000 14:06:44 +0100 (CET) Subject: [Mailman-Developers] French traduction of the templates Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---574402316-824018871-953903204=:17770 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm a frenchy student in Computers Sciences and a true fan of Linux. For the needs of a project I used mailman. I have done the french traduction of the templates files in the /etc/mailman directory. I don't know how to do the traduction in the others files (eg *.py). There is a special function named get-text or something like that for the python's files ? Joined to this email the tar.gz of my traduction. Cordialy, Matthieu Camus e-mail: matthieu.camus@univ-lemans.fr ---574402316-824018871-953903204=:17770 Content-Type: APPLICATION/octet-stream; name="french-templates.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: H4sIANVk2zgAA+xdWXPbSJLuV+FXVHNCQXKXpERRR4xHUrcsyd2K0OG2ZHt3 Ozo8EFAUyw0CbBRAW475cftT9DaGH/ZpX/ZtM7MOFEDK7ulpU9EeVswhkkAd WXl8mZWV9sOxiGV+LYNUXHM/+LmXvc2++n3ben99fXtz86t11er/v74xgN92 1rcHO/3++mAbnh/s7PS/Yuu/8zzmtlxmfsrYV2mSfHTdn/r9D9qepMmYrbbG 4+RNzNO29PCLR5VvrhL87COjvOJjX0Tw3WV+/ZoH2SN2MBWShU3gIWCgSSaS mIUcHo+EzGJ/zOFZz4Pe+PgaO2M+K7KCqccz5k95wGQeBO8lu6u81YPXHpo2 /wqNtjX/vBrgk/K/sV2T/83BYGsp/4tov4/8cxYW8h/UATKfTFIxLurPLiV/ kQ22NUpuRPwZzL5tn5D//mCrLv8b/Y31pfwvou2OsnG07+2OuB/ue4ztZiKL +P5Bno14nInAJ3E+QOEHCU3h45TXJXZ3Tb3k7a6pbnavk/CWXd8ESZSke40/ Dak14IcnF8/O2Nnx1fcXR3tPLy6v2MHh1cnF+V5jtTXxs1FbwkOoKaT0b1Bv wISuDh6fHrOXJ0dX3+81gJNWVxvs8cWzo+Nne431Bjs8Pj29fHpweHL+3V5j U31+enB0RJ+3Grgm7OSZ+gP/PGKHF/gKjLrRqHf8Hfx2AT3/6c9/Pjx88qTB Dk5PvoMnD4/Pr46fQXcru4/3YRnnV8w8qbi4wS5P/ut4r/Hv/cY/Rj3ocQ37 299de2wnuXZ1pGe+Zqa+m6XOGvbZbiimZnbPxM0oa+yzsyTD7ie+lJz5zrBD /DryGQ7LH0Gv8PK+M4zp8+T86fMrdvWfT4/3sJM3SRqy84Oz4z3qbPJGLXKw vu/O0EzMnWEWMth9OfHjvQ3mR+Im3huLMAQuqQxy+fzx2ckVQ0rsNVL+S85l 9ooUUsNboUbdTf0ohwdOfQELe9cdJ4IBfVOe9nq9Rkm0LKxOCSaJzIOMiYy3 v7QrM80HI5xM+edU/5/Ef9ubW3X9D6Bwqf8X0V4kIEagHMZ+DBoCfTAthX4Y AlZ7xDwtXautYBwCePM8Bd/420kRigLfAb0y4alM4pjD10WQZ36cWW3Tg1cO m9AjA0679q8jPgbZBR2VBpzBUGya5JKhxr/l71BNSfgMQDLFrnPoknphzSFP xwVvYncv8I2UB3yawitR01dOKIFTrejCIhCSkGiO4wLSLDJf0FLtzJifM0/m rzkpzWmFEmHTv8YF4VxxyKskz7hkEfyXyANdS3zfvo5ESCKRCVzSvEFpRC+E OfsCCfCBhhOpuCmg0ykQ0CU26Vu1B+xzqq3rJI+Dzyv+n5T/nZ16/Ke/vb65 lP9FtEPONNpiZydnx0zxp+ZO4FkB8gq2lpFII2tn/C3wsRTjSUSi3e0CtyIX hX56S/rhMIkzYPBudjsBqIHPr00iX8R/YcHITyXP9nLZ9WUghFEMKOVxAijF ICaQvsD4kUpwQLpJ4Zhvz0DUQVKNyJwqXKOFxwFX+MUZOJ6p/hUlC4WKfjig QdQPB1bc4ZmY3xBWa8vVVihCdErxmWeAP8zzzzi8EILiehsA/cRQsiRnQz/z I/0wUCXP0PVFlcpjVHzwCdREdaXoOgcRj4ORGhy+SKlrhpR5nQj4LhDdEAYB rQfO8Q9G/XzDkNJAKKUDS7TH8xQ1kBQZd0hFyp18ekWBHqkVGDb4ObyWD+j/ rW/a+O/mxmB9i+z/zmAp/4top/49AoZc60evlBh9u9oaJYDM1SfmIxoAkc/a IUO48CHjLdn2fskF8zOQfWtNA2BTERap4vU7lNYVa92OHpO6uAiCfAKgnmCA bIIFp79AZfwPSUPAA8FCP1bGd8xFFAGDg70vQKkAF5/CI75kRTAqQEd14HmY Ql3IpDHsEpWZzOWEQ4cSZAE+T5PbAqEIvBKCabZG/6H3ZhENdgigR/aQ+H/Q H/SN/G9u9wcK/28v5X8R7SPyX1pREPjXOT4k82sB1prdpCBLaM7jGy0sxyCV 3jCJyaLG+GSqzXo+5fCbQdyTCY8KjFCkbJyEeVQbuKGNVQPE7xAFPy3A7IUg plKwDDA4m/rsGoSUXXM/Bx00oXgHOBbR+7HC5ojEb5SJVOoD1YGnh4dHCwkT LtCSHiZjMrnwcFf7IqRsSP/4wyEH0/oNaKh+m6GSSfI0FTxFbZKJuFCOj+oX gz3vCec76EkpFtR6ipba7EKHG212otWccqZCoFmBhB1XAjjptQB7jg7EBAZn fDz5APY6RXiUwwjSM26XVA5MLss4PLwkUWlaRRxj8MRHsG8HV/pPOXIMfBN8 Hiah/ChZwCYVndJF86fonxWv79gkhw+JSEH5/z3vsXP9gIjBAhQIRzxYAO4Y fZ3k15GAL4HE7vI6OFRKDOHORhENhvaiJmAfdPpCYZ0o7eMB5+G0xokgeg7a 7FI4k/TpQBG8s5dJGoXspYBXX/LrjrYsyJLvqK9JlNwCPeMmwNkkzTiYMGRs ovYMOS0z0Z531FMB8BB4hikYJ2RofMqT8B3O2D4SZ+n/RvAMsK0PPKQ4Begl Za62zjJSC20oEcILhZwkMeFvf5K+t7ytORm4DKmPQM9yJhi1EHE6EPY1jgyI dBLlst1hHs+CXq/HTgEnAuNIooeeHkdfGtFlin8Cc1s/VPGtiIfJqzyNyFpv lqSOm0Rs3OqS4C9fVqk8pK3DjscfUEADwBHIuCD/M/urNhd0CfIA7pAjdDOR CXV27OWxdsFhrfB3kKQTSRQHxA2UUGorUpzXGPFo0mAtkoubHIHEmGdt4KBq QAH1VloA8VEG8ywZA4qQhREwlCTE6VoG0YXnpPWIFV9w6hd4UNE5Ja01EzlI ckdp0UoMbFHq0oMlDMVNXiKnSkiAYiql56aUCE61e1PERUryY3H/aguDC9AN vvcUtxyZwsND+2GSjtUIqK9RSyc3IhAgkfpl2EyBfsQ75LxRMuYTHM91KrxR lk0era29efOmh9zSS9IbtvavAZ6+gBakSYzq+CHP/7b72xb/bW1t0vnfzvL8 byGNQJaKwWhj3DE2GNXgECysBmtCdioBz2kCmiscFZIUWmgx1iyQRNdRn+0j 9BBxECGQI2CCOqgSbGU88wINzBwTTaYKDQJhTjJtEa+a56YNFtsYsTZCSoel pIOfPzuV2vDprtREyHgnaEwdxQtK0iyxw27R2E9SIWvJDh30VQPsvomUE4CO AZcWpUPpUbewkveZWqKIp34EoKR8pYU05m9xuQgbtB1HkDD1AwRt2oiD3QeP mqLkuVALPY5JnytEgQZ16AdqnVVLXNz4OvRuiWrgFJLDGxqQlfFIOtjeNRqs YjQ0p5DFtLbIu6NglAIZza622c0qyqmsdrXF38JjbdmeY7g9NNxNNNxNEwTQ Rj609g/mkblTMCcBdVTpkaFVdJJZmpdWu4IeQ9dSd+ijtdXqo+ZPJJjEwQFa dTxNiy4ymQ21Icuf8TQQX8MoZ0kmS3RPPLjayqUJyD16CKOJlP280f9P6v+d jcE66f/NTYz/of7vb2wt438LaQfoGynl+msiAY9YGbN35M0XofKP0POJnR41 8nQxKHosnnbQ4+rpmOP9H6I/LkjLYYAck0WN5Kkwnmf9Uq3flPxpS5Fcgx4R yseogtwA4bXsotXLwE+tOmjKFDjGyM/fqrlJF/SqfijADtrjeewunOfmaI+0 FRL1JqYTQeun1PRYbgiJmug8QbD9S07GjMIsFCzJhHIZ1bGIRLpMQU2iauKw ephpqd5xdA88MrQ4givzPeNrzfrGJjo7z+tDG4OTCHLoMa3aldKaKIqUnqWy KGZfPGNnnQjHnaG4thfERTg27RfS46iy6XJSBGKIR6yy5JqWPTDGYIXQCrnN aketng70ShW4+TdjmtzBrQzY1b4nN740V5pl7INNNtZM0eywPBPwLdCkqb80 Y3wLvjedXB+UAIostsEQknVVeJtMhB8rc97YZfsNDKTcxLBq2uWoIJvMvOP/ OPnu+BKZeM57P7KfGiA2cZIRjIKv7ItPDg6fn14dXJ08uYQJnTcJjWk3PirH BDalXtAUYkiEdtyuL3J3Bdd1Wt0my50SRIspsGOPt22uMfsRpt0NeZeY4Sf2 Y0K06BIk6ioU1QoF6oo2/IpWEjZqb1dv2P5P+rScsUsnZWCuHuuxF7PcFyYm VKfib7a7+fEfRHEWMgKFJho+/FASSHMiioW3Uk6lw+bwfolOFO4Gp71IRRIi d+sDiJWmWn1XjdV0tEtECgJRsIpDPGLNOFFPN/HrpvnbW2n5eYAxWxPw+Lrd szEcmPDIJ/++nnVhpIJ6h14o+mSBXdhM/k8nbmgIqOIX+pSlqiFETIsCFbDS qG8i412Ulf0GU9Mk0YPVj97r4Is6y1SATr/csRsVCzazOM1lTk4723X5bB85 icYu+eeoGub7DSxku8JY04exiSZHYMNqAVRiNUeoAvyfD5lCpWjocOPN/jhp MTP8eKe0VKo9H7s1YjgskIRm18jiMbNf0/pw9aio3S1SJ96KcrrGE2Y2v9lT FH4zSuyqX2A0GB7DvUC7jXpVWUkbMK0RU/WBVqbsRMjcRwVTt9uTtIgEBr9s KNzp13SFH2R1QrAMNPZKC+EfxpS7CEdlLKFd8FZQ0aNh5+kUD9G1ve95SjUg VrYDlOE3TQ4JqnhXCeo+/BH/LRkO9+usZ18/gwWgTonX4DGam9YntTBzj506 v2lNSgsqs4UYwIKf4eOKyksIOMXmKRpqjyzoVanI6TCf48Dp9w2ou6skcJmB lFaZNxaXfIyxauv1ViLTtawrQBG57gOZtzroUEf1rTbG5BEz5IUBdlx938X8 EtZys1LaHTJmmM7SVSCIzoVhRqqLipPekjzXuAn8ahvEp2USFyPiGrZhj1fi BJWQmcihiu5SuoamgrPgHnsOtpLbMxBwIMHqK0GegHCGpFNp/SrInTmuvrv4 OEmDqRkT81UAR6tTKpIDkPunB5flFNQRORFTOsl1epdVL+7OnmOIxx7a6VOb +6jgzmsEfGhJ4dOpVBXKKSaLCKGaQ6qU3/hpyCmTqNQRqpM5Em243ls5Syjb l7oDRqbzf5iSFm8djHIEqNKNTWTeBeoCY3arIrlLMXc/794jqYe1MJGr/fmM kMDWsiRl3a6jKIhRgKh4lpeZLB8XL7VyYpY7jZiJaUg74PcUWltR9u81niXY MwkNFFD6hiIYaTlDtOhnObzeRdXvKxbwVoopxsD06alKhIhzIfH4o47fwKpN LW52YHP9CEanRdpoCQIPwBHAnOBSBTyN1WEUL9NDS8hlTkfLs6ZFpTwum9PG vszw0sZDxv/769sm/rO1taHu//SX+R8LaeVZKzkDYyFlRYmSSw6IMpc6GlRN DGN3YBhXWzdJ9goft/cDPQoZlz4FKAYXvxKO+3VhCU8fQFbGKYMTnpfk2kEn R2JuTJrivmiNTQTGBl90ZBm1kO7eXEKxK3EPEjC7TZDxdnPedfzITXp3e6RA cNnfcawOl0NCJYhC0fuq5b0p/a9DR2bi+tKlPgPwCNZTXj1G5svQCKpj7+UI tHzKJ9GtiG/whIL76GzBaOwWt8b0FQlM1kkYfC8wjIDmZ8Kxp4BlYPm8xjOw 86dch+bzmdRAvIGz1NZ/2BbzN3Rq/5D5f+s7O0b/w/+q/N+Npf5fSCvz/1w9 /1c35t/U+SVBWhRcH8zZCFk1Uu+BxlEJdqSFIgrUOp482ZVr1EQyT62Sqw+v jm/nou3ZqTr5SniHVEF9q7cp5HLNZSJ0MmC1SxP+pxNf/tEZld2VkXbdcfkF TjHXrhlgaTHJI5UwWKYfe37lNqjs4HmrSg5q0mW8fKq8Bes7Gx8yGIFjTBcg mYcRDAxb8NS5IgVOW5EWM6ffv2J9+hIX2kqM3pv4bUlYdfvfHAecOs/qg3kT HKbbB7K8T/WpHZs5anBnToE0bWZ1YCigAw30bnHwMgTG7QLQXapmT1XctEOu T9d13CvkmkYx2N2UcsW+vzo71XF+nAj61SaNLRBI3ZOI3aJQ2H3HPbBn78jg heJwhUnuoZHXotS5yr0N2a6R7i+V6Nz8Yy3gBtMx0TdWGEhnAlZAUCUf7q8K /NBptoYYXv14Sp8Lqc2qe38E8sqQJI7mrPDR3O3BbWuaXa+kBXgul3RYECGY eYdwrdAx9TL+rAlLKaHOkGYtAk+bgGxFphJPM3dePe/0DsOhta+BUBl56Bhd m6MmZCXdpEOPoyjOiwvo2zix2VaMHX80E0N14s1RTjr6UIkQ4okhXmlyc1Kq QZsOXjSiChtcGuSeFgHXCSs6G/TedMXSo78z51tdgrHfVrN5lsDvj97i5HNn /336/tcA73xo/Lexs0H3PwfL+98LaSalga4lFlb39/D756APnmpE1WpTMNHY gueumldJTKQT3MuYqy0yiXEZLPCqCg7GxShxBtrRqCFl1hQAqueIyFuZvR/T HWrnTqPOw/h6qYt+U5uANv88Vf/K9mvr/21vD3Z21vH+V38HXMKl/C+gaT9L Y8RMZGlR4j2pgkRO1Qe6cuJW7aMo3lwfslLTC8GiShVzgWulJs2sL/DQtPlX aCT/eTZ60Pvf2xta/jfXB4OByv9fxn8W0pT844liav1HPPN9i2VJlAtCySUT Kt5iSxaYKilOXZNS9OcVZaiog4oXMVNZQcWXJeaK0m9Htg+llPB+uangcAEK KiuHsArL8w7Km49TTCkPuL3LVAtrhNc2+EDrLaMw4HrGGIHBejJqxV+cy4Py P+LRQ57/rW/u9K38b29ukPxvLeu/LKS90EJir1k2laC+srFf9+xsPjQ4lngX lU6HXufyl7xJqJwSBnVQUtckMdpikmMYk3J4fAo6eHRYNc21xnG0TU+FG1PS D2VulBqOV2OJRmvghQ7MM4hKYOPeLXbzMj2JD07n1pOaqSNVLuXLUQOmNM1D yr+p/wvy3+/r+p/L+k+LaW5cEiTQXEtDcXXv5MXKduojbhNnN2UWnGtylCXk nBasqaq/EhPVOd5U8/9OnVAE3CZ48ZhKxRSgM7BAwZciXH+AlnLAbA9c/21r YO1/f3NjneJ//eX9r4W0ev3HT/vyM8dBlfAAgARd3mXW9vtlSrP7k2+uX0TW zpsDSAUHFI+aQxI917lmfzYd0bmqWa3Ooiov0gW12eppnpuvfFfzF+zxVzV2 Au9nwo/oIPxBrnL+pgY47nO7/5+O/2+b+N/m9sY24X/4z1L+F9H+Of/fq9zc n5ug8UjJDh4Vl366PS+QTqBg5d4QAcjaf3/cnV+5x5dXKddftAf/z7XP/E// UPuE/G9s7lj8v7NN+b+DpfwvqD0WHAUq/5jtv7cQ5Nce/PqGR2BkUZRVmQj4 mQIJlVpZJilXCbG6zaft6mqLPlqrelpPGaOSRj4mQNTqLc+ZLN30sh3PJBdd Cvbah9GkvQsX0aR+1U1PSthx6lbMlP4q637VS4u4Vc8w96LdMWnN+pGJvkdf KlO7CD26ynYG1YmJH1Hkw4f5OSXVOh5pcRNRutTcdGuqqEapNN49WUN2Gg4T 2FvN1aqgnmdiRU5ykTlQnk29bsUzd4/LmlwdrHVSDcs4k6JoEV0N1SPOVvR4 MS+3a06qTq0SjLvZZW5NLROn2kOUiy4mqrXrSe7ISj1G1RIMEcv8RKfoiKmP N49Z4pnSevBDR2c3uaTRhfSAA2RuCuqpm5y4oZnidnNP3Ezdu1eOqjsLe2FK 8tQX6N13K3pOjhy7BniuyzBU2N7SHBNJ7Y01wZ28/nl7p26A1dMdyxHH6o7l KAGIb2652Yo7ziUqosOc/qW66G/T1jBDgptizPmXkf6ESOyh638BAND2f2t9 Y2sH8f/GMv63mOZUEaxUATPVXObJvGsfPQvLnYRble9qkzUbCvC3ZcOI1JxD w1q+wJz8b5xfXGC1dZ80q/fi4urZMTu7uGJHx3gN9vIY/6gUrj2+vJqXHW5y V42trNS7cvRTpcqXTtZ8N2MBvJpCQ11hlVo5vP5ibqbzfebbndY8C+45RVG7 ttTKrP2el71rrLW6O93AGj6N++01FdmaMTtaOXtl4a55xvgHt+6lWzzrmzLz K+LSzv+O1atdPrSYfLFtylMxvH3Q+G9/c2DyP7Yw8rvM/1xgq2jLblcpcpuf Vfl3XeFXJ+8D/wWA5GehgP+5uhyDEk4ZYmhGlLZBtQPKEh/TVqH2z0SaqgHK VnjmFueudgvbcr9zr2tqi5MZPfHU3ufBJFKvjPqUHmj9pmWl+kRdSXK8DEDh XK9rEv7vVG1lW9nrkjRlC4PXumYwXZlskL0C1YnVgTk4NNADaD/j8tjXbai7 S6PZahTzHqjczCjrhuH09KKr29IyYJeKbDTpOmhTV8lQqbO2hJsOjf9/e9e6 1DaShX9bT9HjmoFQg+zYDrBLhFKEy8JUDC5gUrW/towtiGpsySvZZCZvnLeY Ppe+6GZjEpitWfXWFhOrpb6c7nPr0+czySBUys0hXC+FaxwgazIZJseb+hYG HOhzxhvKApREmOV6goBt4tPwNqRkDTg0x4wNbxwT5BM0heavwBDg1pZlIlFV zlSEWSqsbEUZR0Mk7d3wHuiMo6T2zEBNcunCPQe1kqTY+T8SOcNk9AmuobUA B/KZ2liJ/2bwX6QAwPy/3d0a//tFisL/BMRO+YeAPIXX77vglHcvpGDwxSEv EqGRPh3vU6ey2r7Xlk9lnbsY0+p8CcSB+LkrP/+DK4XIEe7Xr2h6Y85zAoeT u3oOae7vJsHvkPW+JX7By2pw/JAGUWpChsPbIJnrdG18RIiZZRJ9fe+/i028 Hz9L4jHcTMU8eZJxjtF7NKYTSeIcM0q9SF/7IPuzmH5NYgj4eYgniyko+8B+ DWvOJEaGHOkI6sQ4F8Mo+hq0HDlQOV45PzwpOE8ARAlzAnMjH/ElBvdULq0g gYdMhTYR5SXoL+2L8ST4j7RNno8FrL7/s6fzf+9R/O9evf9fpsCWFD9eBQ8h Re52Wm/EjwIXL3MG2vG5rQ7/vJwFZO/74mojGMJt5LfpYjIfzi1EYF7Rkh+s +wVgIVDpKoCfUv9/Zsv8rYo6IvkL5f9ud3dX2397FP/b69b7/0VKcf93/qkY AAhShFE+OzlUYM835zcfTvJ7Ga/2nMtV5LXpuayL8MvqRe/95fG/LXBtDQhO H5Vfu1bn0HJrJ1P3WhJlzk0ODEQ1QoEDevdBs7MeCngDIcAbS/G/HwX/jR1Z DQGemyHXlT1QPx2bvL++jf3dUMDfDUL9biCgNrVo4WnLXvOv8veZvxHdprO3 XA0hsBsKAbvBmNz07HEDPz09fX382mqhYqz+IULcxniclB1tbkx6VArNnEeU mDYKo2tIquuPwsqSXxvQJ2Y+mfmU73AIL04ChRaaCsrxZ2VBtM64tuEDGtAG 9FmjoPlGyc0NxqrT0j0mwTRPQmncj6l6n1rkgc6IjMcWpLuFQY/UXZ8glcT4 1cr/sJwelX1CepStM/tY3/KWbAzvk+FD8JYOFynxJJxNF2fcysjFHgP1Lo7p UJxdnZweNOHJPN6Hvg9ikEr37uF4nPi0mTI/ee1Dv+XwcsggfdC5J/sGjNso xuh9SKLNnnp41/ZEqWySBmkyDfK51lswewpj3ga+fw6KXm/qYeiZ/q5k9Qa8 /0zy7IqG6LwdEqkCgBwaUuCiWUwoWyVND24N/R6zc8rn3U/vqcXFxGx54uVV LLybY+HdpuQJPJ17MJtnJ+f/Ors5EM1OhxkGUoAZvJnrMRZNip2dn5r+x0yi UlqS+8yj+ANcvdf7iVafEU/v49/1dDesqp2urEq8GB+u2O+9JtMdRYbb8a2A hYCSnebgAJ3GLAkflJqMB+x3cmdG4TxjmooohGym8jWnkarao0USztU/BIS6 ThdTgYEwyvMn6bsRjMJk9DYLMdjIYAzCff6w5HSsJS42dXZ4MOXHgYo1gKzK MM/33HzEfxNM4/8DLwhiqBDBFyRly1mIwlwWiOwfmQxJucnbNwRDel4En12V 2gBJaj1fQkRR1bI2X1wkXlkwh5VsCpzT+R4d0QPdq2KPRLFLanPD6pkoDN3y ZMA5dAPDjCFJuErZ/MpKIbP1jhWJMbcBvfw14oz0V8NxGLvvF/M5WG8XccRS XdY5LqshLhdhnqwW+yxyqR5zqREkE0vym5C+CjqB1+YaDq8V4Cu+1itRmzyJ xuoxsCCjKWX74dnEXpOTe0MBhygHTR1QmaRN9bUlbD7Hac8pJ3tq8XavPbR2 wrEeJ/fVs4VQdad90j+vUIxndGz790tSSg0tzfSRrKXa5co6PjqBrOpSTNOX UuTMBTKUTb/8C/fQqsx8MCDgL9kkf7XV9PcpKl7rGc3/FfZ/Rxr+ezr/x06n g/f/duv7Py9SSuz/vZwDENJDZ/yAA6kXQASH3K4u5AjyxVEx/Cevq+qDgzZ/ r8ol0GDVMMtyK/TE11Wmvq2ZlZv2vod6c7Ud/zM7IC32XDHOwoSApLMYuBLb Rjxpnsi80wHe6ni3vvz3fDFPc0fvbNIV2vHat/52NqkSRO1wOGUO1ss+Oc+O q4X9ORqmATWRPEiblgbikERPoc2xeyEVhVGgu8syD6FW1iPcziPotlMua8vl qFxP/rUcoXYj23gu+bX4Pqu6r93QR4C+JPRfi0rkOTiTklTbZLwGtNpmXDqg UDkDgzNU6Pe2qNYkA4WplKibdhRZ23JepTaSoVTd8RSrGFdMBjllg+SAVrai E+FMNlWeSfj6Q4m1hIfzsAb6to4tSEOUi8EdfEatWrBzSj/I6m8O6jZqNk6W a84KxNPkO8WzQPD10CU+nRnUUcF3aLEQ/DLEJtu0alX1/3IuzZ+M/Zrq0VRW kP+ahpLsMySxvd9ZqfmOXE1peN1VSumy9QtTnONt9lQU169DC1guX1x691JD v7kcwOek0m7tI19zhURbc0qHl6Kk55s8uhj3ro3SItnfSVHRg4bV60ecEZTh 9zianDJGoMFTtlXA96Qb0Q6OPOycY8HOGQARoCcuXb5zofmfGRGovLAj3P4f cpnYvSUVt3J6KLJz9jk3PdVoIzQbT/SeCNt3gg70btE5oZwe2eWkTNxDdKxW WdV2A6gkXE7Gat+sdoMWW7sgUJZHGfErG6k020+iUZysY5lXNKX3uTAFX0Vq 8pvM8zJmalaQxtpoem4d6HEyTieczSgjpdI0L+os1oe7KPS9dJ7E0b3/oRTD By9uIZDCRoxeqInatEHa8tr8rtcOkcni/9fbAz29B/5B+1AK4tyiGMH/rC3a HJPeAz9xB8RVMA8TulCaaO9awNLGArzSXRberdzafYodROAmuYn0bRQlrvkm GufM0V9R138wS43cAw55/DRANHq5ECwQW/GmUynKJ4AR9YdLeV3cW3bAXN7d ZZ/z4EyFCA18FMnIu8gyXzZPaogfddoQughHHqDcFKhYPtJcvpiExebinFBo j5ybW6ohIWJlfWHAIsnlUweRuzRLl/KfgMcyUTkQormtkcaAoQfGMeZov6is qv6TIBevDfoVBCVN5ecy14e2CyHwDgY7Qpp2HgSTotpZhpSo8pNdRvT6egQw qGip7gfMF40EkNDgBGQAgGnixgJMi5MxoeptvctT6zyHiI0Q2BsByc9pkJqr d9rFCO1s22nqJ4GTa0e8Mp3Yagk9Vf1wGvCEaE6J38On+E7hsTUcWrhrTdnV 4yDTtMag7CgzUXrLwWqAEK/4c4TasdlSi5D2nORr1bUu4uibBpBFYh4BN1qG 84c+3+KwRHFc2O3h6DcXDv9Su7/4uPhEjvcpI5F224gg5DL3Eek2rDaMCj2E hQEq5Ch72mT7pNEgk9ymvMZ63S2aCryBM9YB/2YZBObrxsWplURHqZjGQfqy cU4JOn6f1f238v5/73VP3f/vdrt7lP+3vv/xIqXo/9tZO/zHHFo8KfpnoL5d VHmfFOpTeeb6pGiftWN9nEaj5BTnm4JBSoOQ+AzfNoqzVm3Ga1J+37ohsro9 6i7euf8KlPQonqbkhFKYzEr8y48LKRvg9VI9ODACNYxQ39PH1lte+5xjeZZM SHb4H3n883jWLBiMbMlkjWzr4HB5xBbZkYupexXco8czpRiAPoeyRFJcSIYf TkNtj5QEPO0Xorh045aF/N37TLKm0Of1+itKO1xOlTwhVLAZxWrJKVxMhome Ruvo2KrFAjJbSR8K6mPc+jDwZYr2yT6jCrA6/n9Hx/923yD+25tenf/7RUpR /vdyx3+Zm0E5yZ+P2s9KE3MLoBj+v+rNOvq/LnWpS13qUpe61KUudalLXepS l7rUpS51qUtdvq38Ce3tplQAyAAA ---574402316-824018871-953903204=:17770-- From R.Hildebrandt@tu-bs.de Fri Mar 24 13:55:48 2000 From: R.Hildebrandt@tu-bs.de (Ralf Hildebrandt) Date: Fri, 24 Mar 2000 14:55:48 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 In-Reply-To: <14552.20957.516043.218533@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 11:53:49PM -0500 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> Message-ID: <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> On Tue, Mar 21, 2000 at 11:53:49PM -0500, Barry A. Warsaw wrote: > > I've just uploaded the Mailman 2.0 beta 1 tarball to www.list.org. I You know what really bugs me: It's called mailman.tar.gz Why on earth can't you just encode the version in the name like everybody does -- I mean, the subdir is called mailman-2.0beta1, why not call the binary mailman-2.0beta1.tar.gz then? > decided to name the new version "2.0" because of the architectural > changes that have been made. See the excerpt from the NEWS file below > for details of what's changed since version 1.1. What happened to 1.2 ? I've got 1.1 installed, updated via CVS to mailman-1.2b1 and now we have 2.0 ? =:) -- Ralf Hildebrandt www.stahl.bau.tu-bs.de/~hildeb In brightest day, in blackest night no evil shall escape my sight! From R.Hildebrandt@tu-bs.de Fri Mar 24 15:02:09 2000 From: R.Hildebrandt@tu-bs.de (Ralf Hildebrandt) Date: Fri, 24 Mar 2000 16:02:09 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 In-Reply-To: <14552.20957.516043.218533@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 11:53:49PM -0500 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> Message-ID: <20000324160209.L16111@stahlw06.stahl.bau.tu-bs.de> On Tue, Mar 21, 2000 at 11:53:49PM -0500, Barry A. Warsaw wrote: > - cron/upvolumes_yearly, cron/upvolumes_monthly, cron/archive, > cron/run_queue all removed. Edit your crontab if you used these > scripts. Other scripts removed: contact_transport, deliver, > dumb_deliver. I did't see that mentioned in UPGRADING -- Ralf Hildebrandt www.stahl.bau.tu-bs.de/~hildeb "The percentage of users running Windows NT Workstation 4.0 whose PCs stopped working more than once a month was less than half that of Windows 95 users."-- microsoft.com/ntworkstation/overview/Reliability/Highest.asp From tal@research.bell-labs.com Fri Mar 24 17:53:00 2000 From: tal@research.bell-labs.com (Tom Limoncelli) Date: Fri, 24 Mar 2000 12:53:00 -0500 Subject: [Mailman-Developers] Re: Mailman 2.0 beta 1 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> Message-ID: <38DBAB7C.D8544ED2@research.bell-labs.com> Ralf Hildebrandt wrote: > Why on earth can't you just encode the version in the name like everybody > does -- I mean, the subdir is called mailman-2.0beta1, why not call the > [...tar file...] mailman-2.0beta1.tar.gz then? That's yet another reason to prefer GNU software to commericial stuff like mailman. GNU has a standard for the name of tar files: http://www.gnu.org/prep/standards_48.html#SEC48 "Package the distribution of Foo version 69.96 up in a gzipped tar file with the name `foo-69.96.tar.gz'. It should unpack into a subdirectory named `foo-69.96'. Have a great weekend everyone! --tal P.S. YES, I WAS KIDDING WHEN I SAID MAILMAN WAS COMMERCIAL SOFTWARE! From R.Hildebrandt@tu-bs.de Fri Mar 24 17:59:56 2000 From: R.Hildebrandt@tu-bs.de (Ralf Hildebrandt) Date: Fri, 24 Mar 2000 18:59:56 +0100 Subject: [Mailman-Developers] Re: Mailman 2.0 beta 1 In-Reply-To: <38DBAB7C.D8544ED2@research.bell-labs.com>; from tal@research.bell-labs.com on Fri, Mar 24, 2000 at 12:53:00PM -0500 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> <38DBAB7C.D8544ED2@research.bell-labs.com> Message-ID: <20000324185956.D16111@stahlw06.stahl.bau.tu-bs.de> On Fri, Mar 24, 2000 at 12:53:00PM -0500, Tom Limoncelli wrote: > > Why on earth can't you just encode the version in the name like everybody > > does -- I mean, the subdir is called mailman-2.0beta1, why not call the > > [...tar file...] mailman-2.0beta1.tar.gz then? > > http://www.gnu.org/prep/standards_48.html#SEC48 > > > "Package the distribution of Foo version 69.96 up in a gzipped > tar file with the name `foo-69.96.tar.gz'. It should unpack into > a subdirectory named `foo-69.96'. > I rest my case :) -- Ralf Hildebrandt www.stahl.bau.tu-bs.de/~hildeb From bwarsaw@cnri.reston.va.us Fri Mar 24 19:20:56 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Fri, 24 Mar 2000 14:20:56 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> Message-ID: <14555.49176.232075.433045@anthem.cnri.reston.va.us> >>>>> "RH" == Ralf Hildebrandt writes: RH> You know what really bugs me: It's called mailman.tar.gz Try http://www.list.org/mailman-2.0beta1.tgz. mailman.tar.gz is just symlinked to this (or whatever the latest tarball is). This works better for people who have automated scripts that suck distributions down because they don't have to change their script each time. You can even get older tarballs if you decode the naming scheme and guess at a URL. :) RH> What happened to 1.2 ? I've got 1.1 installed, updated via CVS RH> to mailman-1.2b1 and now we have 2.0 ? =:) Sounds like you're not on mailman-developers. Read this. http://www.python.org/pipermail/mailman-developers/2000-March/001911.html -Barry From dan.mick@West.Sun.COM Fri Mar 24 20:42:48 2000 From: dan.mick@West.Sun.COM (Dan Mick) Date: Fri, 24 Mar 2000 12:42:48 -0800 Subject: [Mailman-Developers] Re: [Mailman-Announce] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> <14555.49176.232075.433045@anthem.cnri.reston.va.us> Message-ID: <38DBD348.EA505876@west.sun.com> bwarsaw@cnri.reston.va.us wrote: > > >>>>> "RH" == Ralf Hildebrandt writes: > > RH> You know what really bugs me: It's called mailman.tar.gz > > Try http://www.list.org/mailman-2.0beta1.tgz. mailman.tar.gz is just > symlinked to this (or whatever the latest tarball is). This works > better for people who have automated scripts that suck distributions > down because they don't have to change their script each time. You > can even get older tarballs if you decode the naming scheme and guess > at a URL. :) A gracious response to a pretty ungrateful complaint... Chill, Ralf, and make sure you've got a leg to stand on... From ricardo@rixhq.nu Fri Mar 24 22:36:02 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Fri, 24 Mar 2000 23:36:02 +0100 Subject: [Mailman-Developers] subscription approval Message-ID: <20000324233602.C18958@miss-janet.com> Hi, Today I was subscribing to a list on securityportal.com, which is running LISTSERV... and then I noticed they have a nice way of approving your subscription: you can visit and URL which contains a unique hash that authorizes your request. actually I've been using the same technique for a chatroom signup procedure on our website and it's fairly easy to make... (since i was able to make it ;) ) the big plus of this is that if most of your list subscribers aren't too technical, it's much easier for them to subscribe... anybody can click on the link which their microsoft or AOL browser conviently convert to a hyperlink... (too often I see mails send to the admin with texts like "hi.. my auth code is 923482.. please subscribe me") this could also make unsubscribing very easy... just add a link at the bottom of the mail... and once visited the user gets the choice to unsubscribe (with or without supplying a password?) anyway, i know this wont make it to 2.0, but I hope this could be a nice feature for the next version... Ricardo. -- From thomas@xs4all.net Fri Mar 24 22:57:27 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 24 Mar 2000 23:57:27 +0100 Subject: [Mailman-Developers] admin approval and list archive Message-ID: <20000324235727.K12922@xs4all.nl> --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii There seems to be a bug in the pipermail archiving in combination with admin aproved messages. The bug is that, in the archive mbox, 'From ' lines will be missing from messages which have been passed through admin approval, which means that they will be considered part of the previous message or, if there is no previous message, that the mbox is invalid and no archive will be built. This happens because of one or two buglets, one in the mailbox standard module, and one possibly in the rfc822 module or otherwise in Mailman. When holding a message, the code uses 'str(msg)' (where msg is a rfc822.Message instance) to dump the pending message to a file. Unfortunately, rfc822.Message.__str__() only dumps the normal mail headers and the body, and *not* the 'From ' line, which is stored in rfc822.Message.unixfrom. I dont really think that is a bug in the rfc822 module, as the 'From ' line is not rfc822 but a sendmail (i think) addon for its own use, but it needs to be worked around in any case. The simple fix is attached. In the course of tracking this bug I also found out that the mailbox standard module drops the 'From ' line entirely, before it passes the message to the rfc822.Message constructor. At first I thought that this caused the problem, but now I'm not entirely sure, and I'm not in a position to test it at the moment. This is a bug though, but not in Mailman, and I already sent a fix for it to the python patches list. If anyone is willing to test this, and the above fix doesn't work on its own, grab the mailbox.py fix from the patches mailarchive. And, er, my apologies for this large a rant on this small a bug, it's late and I'm overworked, not spending enough time with python ;) PS: there'll probably be some offset in this patch, my cvs tree is still cluttered with unshared hacks ;) even if it fails, though, I'm confident most people will be able to apply it by hand ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cvsdiff Index: Mailman/ListAdmin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/ListAdmin.py,v retrieving revision 1.28 diff -u -r1.28 ListAdmin.py --- ListAdmin.py 2000/03/21 06:24:59 1.28 +++ ListAdmin.py 2000/03/24 22:51:54 @@ -139,7 +145,7 @@ omask = os.umask(002) try: fp = open(os.path.join(mm_cfg.DATA_DIR, filename), 'w') - fp.write(str(msg)) + fp.write(msg.unixfrom + str(msg)) fp.close() finally: os.umask(omask) --BwCQnh7xodEAoBMC-- From thomas@xs4all.net Fri Mar 24 23:27:01 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 25 Mar 2000 00:27:01 +0100 Subject: [Mailman-Developers] lock lifetime In-Reply-To: <14553.6564.572812.203295@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Wed, Mar 22, 2000 at 02:06:12PM -0500 References: <20000322193038.A10212@miss-janet.com> <14553.6564.572812.203295@anthem.cnri.reston.va.us> Message-ID: <20000325002701.A25139@xs4all.nl> On Wed, Mar 22, 2000 at 02:06:12PM -0500, Barry A. Warsaw wrote: > RK> "... In any case, you can easily try it out; in > RK> Mailman/MailList.py, on or around line 282, there should be a > RK> 'lifetime = 60', inside the constructor for the maillists' > RK> lockfile. Changing the '60' in, say, '600', should give you > RK> better mileage, at least until your machine gets so heavily > RK> loaded that a simple admin request takes ten full minutes to > RK> process ;) " > One other gotcha, if you use bin/withlist to open a locked list and > then exit the interpreter without doing an explicit m.Unlock(), you're > list will be locked out for the duration. Not only if you use that tool, but if you use any tool or script that doesn't clean up after itself ;) Granted, using bin/withlist it's a lot easier, but I think a note on upsides/downsides in either the FAQ or next to the timeout setting would be appropriate. 'set too low, a slow machine might give timeout erors, but set too high, a faulty script can prevent the list from being used for that long.' (But then, i'm all for longer explanations in the FAQ and the online help, i just haven't got the time to write them, yet ;) While i'm on that subject, by the way, what are other peoples' thoughts on this issue ? Should there be more helpfiles and/or online help ? :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jwt@dskk.co.jp Sat Mar 25 08:41:41 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Sat, 25 Mar 2000 17:41:41 +0900 Subject: [Mailman-Developers] Bouncers/Exim.py Message-ID: <20000325174141.A13388@mail.dskk.co.jp> --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Exim adds a header to bounce messages that might be used to catch the bounced addresses, rather than trying to parse the message text. I've been using this trivial bouncer for a while with my 1.2CVS installation and it seems to be doing the right thing. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Exim.py" # Exim bouncer module for Mailman """Parse bounce messages generated by Exim. Exim adds an X-Failed-Recipients: header to bounce messages containing an "addresslist" of failed addresses. """ def process(mlist, msg): # return just the route-address elements of the addresslist addrs = map(lambda x: x[1], msg.getaddrlist('X-Failed-Recipients')) return addrs or None --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="BouncerAPI.diff" *** BouncerAPI.py.orig Sat Mar 25 17:17:54 2000 --- BouncerAPI.py Sat Mar 25 17:32:19 2000 *************** *** 38,41 **** --- 38,42 ---- 'Qmail', 'Postfix', + 'Exim', 'Yahoo', 'Caiwireless', --1yeeQ81UyVL57Vl7-- From ricardo@rixhq.nu Sat Mar 25 11:51:59 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 25 Mar 2000 12:51:59 +0100 Subject: [Mailman-Developers] rfc822.Message In-Reply-To: <20000324235727.K12922@xs4all.nl>; from thomas@xs4all.net on Fri, Mar 24, 2000 at 11:57:27PM +0100 References: <20000324235727.K12922@xs4all.nl> Message-ID: <20000325125159.A20826@miss-janet.com> I've made some changes in my copy of Mailman to split the message body from the header in admindb.py. This makes it much easier to browse through the held messages. It works perfectly, except for the fact that I haven't found a way yet to limit the number of lines displayed to ADMINDB_PAGE_TEXT_LIMIT... can anybody help me with this? the code i'm using is: fp = open(os.path.join(mm_cfg.DATA_DIR, filename)) fullmsg = Message.Message(fp) msg_header = string.join(fullmsg.headers, '') msg_body = fullmsg.body fp.close() You can see a result of how it looks at http://rixhq.nu/mm/admindb.png The "send copy" isn't functional yet though -- I had it working on the previous version of Mailman, but I'm not sure yet how to implement it with the new posting methods in MM. Also, I've made some small changes that move the heldmsg output to a seperate template, so I have more control on the layout of the output and it makes to code a bit more readable :) Ricardo. -- From jcrey@uma.es Mon Mar 27 06:54:39 2000 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Mon, 27 Mar 2000 08:54:39 +0200 Subject: [Mailman-Developers] French traduction of the templates References: Message-ID: <38DF05AF.AF61B69A@uma.es> "Matthieu CAMUS (IUP MIME - 96000937)" wrote: > > For the needs of a project I used mailman. I have done the french > traduction of the templates files in the /etc/mailman directory. > > I don't know how to do the traduction in the others files (eg *.py). > There is a special function named get-text or something like that for > the python's files ? > There is already one person doing translation of mailman in frech but it is true that I have not notice of the actual status of french translation long ago. At any rate, I send apart spanish catalog so you can start translating. > Joined to this email the tar.gz of my traduction. To translate accordingly templates, the i18n version ones must be done. I also send you modified i18n templates. Cheers -- ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de informática | | Universidad de Málaga - España | #----------------------------------------------# # Solo se que cada vez se menos :-| # #----------------------------------------------# From Nigel.Metheringham@VData.co.uk Mon Mar 27 08:45:47 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Mon, 27 Mar 2000 09:45:47 +0100 Subject: [Mailman-Developers] Post to every list, just in case... Message-ID: Having been away for a few days I've experienced a sense of things repeating on a short loop whilst reading my mail this morning. One particular thread was cross posted over 3 different mailman lists, although it appears to have been moderated out of one of them at least. So would it be possible for list people to have a little more discipline regarding the posting of messages across lists. Additionally do we need to consider:- 1. Hierarchical lists - ie moderated announce lists that post into other lists, with decent support for building a union of subscribers - maybe rather than subscribing x-users & x-developers to ax-nnounce, a way of telling the list to pull in these lists' subscribers too. 2. Filtering on lists to detect cross posting and do something... 3. An idea of what "something" should be :-) Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From thomas@xs4all.net Mon Mar 27 18:53:07 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 27 Mar 2000 20:53:07 +0200 Subject: [Mailman-Developers] Re: admin approval and list archive In-Reply-To: <20000324235727.K12922@xs4all.nl>; from thomas@xs4all.net on Fri, Mar 24, 2000 at 11:57:27PM +0100 References: <20000324235727.K12922@xs4all.nl> Message-ID: <20000327205307.E25139@xs4all.nl> --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii On Fri, Mar 24, 2000 at 11:57:27PM +0100, Thomas Wouters wrote: > There seems to be a bug in the pipermail archiving in combination with admin > aproved messages. The bug is that, in the archive mbox, 'From ' lines will > be missing from messages which have been passed through admin approval, > which means that they will be considered part of the previous message or, if > there is no previous message, that the mbox is invalid and no archive will > be built. I've been able to test it properly now... the mailbox.py bug wrt unixfrom is unrelated (but still a bug, imho) and just this diff (attached again) is enough to fix Mailman. Since msg.unixfrom is '' if unixfrom isn't set, this shouldn't break a thing. Regards, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cvsdiff Index: Mailman/ListAdmin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/ListAdmin.py,v retrieving revision 1.28 diff -u -r1.28 ListAdmin.py --- ListAdmin.py 2000/03/21 06:24:59 1.28 +++ ListAdmin.py 2000/03/24 22:51:54 @@ -139,7 +145,7 @@ omask = os.umask(002) try: fp = open(os.path.join(mm_cfg.DATA_DIR, filename), 'w') - fp.write(str(msg)) + fp.write(msg.unixfrom + str(msg)) fp.close() finally: os.umask(omask) --sdtB3X0nJg68CQEu-- From thomas@xs4all.net Mon Mar 27 19:15:02 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 27 Mar 2000 21:15:02 +0200 Subject: [Mailman-Developers] pipermail/hypermail mbox-archive Message-ID: <20000327211501.F25139@xs4all.nl> --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii There was a short discussion a month or so ago about the hyperarch 'mbox' archives having the wrong kind of date in the 'From ' lines... 'unixfrom' lines should have a very specific dateformat, namely that which 'time.ctime' returns. The following patch fixes Archiver/HyperArch.py. However, I'm not entirely sure if it will work correctly in other locales... can anyone test that, and propose a locale-independant way of producing this format ? Grtz, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="HyperArch.py.diff" Index: Mailman/Archiver/HyperArch.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Archiver/HyperArch.py,v retrieving revision 1.16 diff -u -r1.16 HyperArch.py --- HyperArch.py 2000/03/21 06:25:10 1.16 +++ HyperArch.py 2000/03/27 19:08:04 @@ -64,7 +64,7 @@ article_text_template="""\ -From %(email)s %(datestr)s +From %(email)s %(fromdate)s Date: %(datestr)s From: %(author)s %(email)s Subject: %(subject)s @@ -154,6 +154,7 @@ # subject : Subject # datestr : The posting date, in human-readable format # date : The posting date, in purely numeric format +# fromdate : The posting date, in 'unixfrom' format # headers : Any other headers of interest # author : The author's name (and possibly organization) # email : The author's e-mail address @@ -242,7 +243,7 @@ date=time.mktime(date)-tzoffset else: date=self.__last_article_time+1 - + self.fromdate = time.ctime(date) self.__last_article_time=date self.date='%011i' % (date,) --i9LlY+UWpKt15+FH-- From bwarsaw@cnri.reston.va.us Tue Mar 28 17:12:00 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 28 Mar 2000 12:12:00 -0500 (EST) Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries Message-ID: <14560.59360.933438.313871@anthem.cnri.reston.va.us> Last night, I added some code to queue messages that fail delivery when using SMTPDirect. What happens is this: If a message either totally fails delivery (e.g. the smtp socket connect fails) or partial delivery fails for some, but not all, recipients, then the message is stored on the file system for a re-try later. For every failed message, two files are created. The base name of these files is the SHA hexdigest dump of the message text. This should be nearly guaranteed unique. A new directory contains these files, called `qfiles'. The first file created is the complete plain text of the failed message. The second file is a marshal of useful information related to the failed delivery. This contains the listname and the failed recip list along with a few other moderately useful bits of info. There's a new cron script called `qrunner' which cruise the files in qfiles. It claims a lock (to prevent multiple qrunner processes) and then goes through each file it finds, attempting redelivery. If there are any problems reading a qfile file, it skips it for next time (assumes it's a transient problem with the file, but logs a message). When qrunner notices that the message has been handed off the the smtp daemon for all outstanding recipients, it deletes the two message files. I've moderately tested this stuff with total delivery failure by shutting off my smtp daemon, attempting some deliveries, turning it back on and running qrunner. I don't have the time right now to test partial delivery failures, but I still claim that without DSN support, these will be unlikely. Hopefully some of you can help look at this. I'm about to check all this stuff in. Let me know what you think. -Barry From thomas@xs4all.net Tue Mar 28 19:36:35 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 28 Mar 2000 21:36:35 +0200 Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries In-Reply-To: <14560.59360.933438.313871@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 28, 2000 at 12:12:00PM -0500 References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> Message-ID: <20000328213635.A8665@xs4all.nl> On Tue, Mar 28, 2000 at 12:12:00PM -0500, Barry A. Warsaw wrote: > I'm about to check all this stuff in. Let me know what you think. I'll see if I can do some checks on partial delivery failure tomorrow. (I really need to get myself a seperate box for testing ;) But, assides from delivery, it might be useful to store messages which failed elsewhere in the pipeline too; messages in the archive pipe, for instance, or the usenet pipe. It can currently happen, for instance because of a deadlock, that messages just get lost. I haven't looked at the new code yet, but imho it shouldn't be too hard to push messages back into those pipelines, assuming they fail 'cleanly' (and not with files half-written or some such.) (Then again, I haven't seen failures at all, yet, so I'm not too worried for myself.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@cnri.reston.va.us Tue Mar 28 20:00:18 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 28 Mar 2000 15:00:18 -0500 (EST) Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> Message-ID: <14561.3922.358917.646194@anthem.cnri.reston.va.us> >>>>> "TW" == Thomas Wouters writes: TW> But, assides from delivery, it might be useful to store TW> messages which failed elsewhere in the pipeline too; messages TW> in the archive pipe, for instance, or the usenet pipe. It can TW> currently happen, for instance because of a deadlock, that TW> messages just get lost. I haven't looked at the new code yet, TW> but imho it shouldn't be too hard to push messages back into TW> those pipelines, assuming they fail 'cleanly' (and not with TW> files half-written or some such.) That's actually a good idea. I think a wrapper around the pipeline loop, perhaps using a bare try/except (hmm...) is the way to go. What you'd probably have to do is have a checklist of delivery modules so you know 1) which ones you wanted to send the message through; 2) which ones failed. And then to know what the disposal is for a message that failed at a particular step. Definitely more complicated, but worth thinking about. Robustifying message delivery should be very high on the list, but for 2.0 final we'll have to find a happy compromise. TW> (Then again, I haven't seen failures at all, yet, so I'm not TW> too worried for myself.) Me neither! :) -Barry From thomas@xs4all.net Tue Mar 28 21:14:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 28 Mar 2000 23:14:00 +0200 Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries In-Reply-To: <14561.3922.358917.646194@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 28, 2000 at 03:00:18PM -0500 References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> <14561.3922.358917.646194@anthem.cnri.reston.va.us> Message-ID: <20000328231400.B8665@xs4all.nl> On Tue, Mar 28, 2000 at 03:00:18PM -0500, Barry A. Warsaw wrote: > >>>>> "TW" == Thomas Wouters writes: > TW> But, assides from delivery, it might be useful to store > TW> messages which failed elsewhere in the pipeline too; messages > TW> in the archive pipe, for instance, or the usenet pipe. It can > TW> currently happen, for instance because of a deadlock, that > TW> messages just get lost. I haven't looked at the new code yet, > TW> but imho it shouldn't be too hard to push messages back into > TW> those pipelines, assuming they fail 'cleanly' (and not with > TW> files half-written or some such.) > That's actually a good idea. I think a wrapper around the pipeline > loop, perhaps using a bare try/except (hmm...) is the way to go. What > you'd probably have to do is have a checklist of delivery modules so > you know 1) which ones you wanted to send the message through; 2) > which ones failed. And then to know what the disposal is for a > message that failed at a particular step. Definitely more > complicated, but worth thinking about. Robustifying message delivery > should be very high on the list, but for 2.0 final we'll have to find > a happy compromise. How about a simple try/except in those two areas ? They are pretty isolated, and you can add the try/except and restart-delivery code just after the forks those portions do. (no need for the queuerunner to fork, i guess... but it could, if necessary.) Actually, I think I'll post a diff tomorrow morning, after I have some time to think 'bout it ;) I already see one problem though: the new code eats the unixfrom line the same way moderation does, screwing up the archives: # calculate a unique name for this file text = str(msg) filebase = sha.new(text).hexdigest() msgfile = os.path.join(mm_cfg.QUEUE_DIR, filebase + '.msg') 'str(msg)' will not dump the unixfrom line, (unless you want to fix this in Mailman.Message.Message) so you need to use 'text = msg.unixfrom + str(msg)'. See the patch i sent uhm, sometime this weekend. Also, one of the comments in qrunner seems to be too literally copy/pasted from cron/gate_news ;) Rgdrs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Mar 30 12:08:43 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 30 Mar 2000 14:08:43 +0200 Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries In-Reply-To: <20000328231400.B8665@xs4all.nl>; from thomas@xs4all.net on Tue, Mar 28, 2000 at 11:14:00PM +0200 References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> <14561.3922.358917.646194@anthem.cnri.reston.va.us> <20000328231400.B8665@xs4all.nl> Message-ID: <20000330140842.G13073@xs4all.nl> On Tue, Mar 28, 2000 at 11:14:00PM +0200, Thomas Wouters wrote: > On Tue, Mar 28, 2000 at 03:00:18PM -0500, Barry A. Warsaw wrote: [ about the new queueing of failed message, and implementing that also in ] [ ToArchive and ToUsenet ] > Actually, I think I'll post a diff tomorrow morning, after I have some time > to think 'bout it ;) Well, I didn't make next morning, and I'm still thinking about it. Should it be integrating with the pipeline architecture, or module-specific ? I mean, it could be done two ways: - inside each 'process' function for every module that might want to requeue, in the form of def process(mlist, msg): try: except TemporaryFailure: Utils.queue_message(mlist, msg, re-injection point) and a def reprocess(mlist, msg): most process()es can probably just call reprocess() after some basic checking, forking, message-header-editing, etc. reprocess() should raise TemporaryFailure, but not catch it itself -- the queue runner should catch it, and update the pickled state for that message. - inside the pipeline structure, in the pipeline delivery. This would require all handlers to have a reprocess() function, but most (those that will never raise TemporaryFailure) can have it just 'pass'. (Or perhaps just leave them out... that would raise AttributeError when the impossible happens, instead of silently vanishing messages) The pipeline itself would catch TemporaryFailure, and queue the messages not only with the list, message and what pipeline segment it broke at, but also the rest of the pipeline still to be traversed. Might prove a bit more tricky, but it's a lot more elegant if more than a few modules support the queueing interface :P Comments welcome, but I'm off for a long weekend Rome, I wont be back until tuesday, and I wont read my mail in between ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From elephant@pld.org.pl Thu Mar 30 15:23:26 2000 From: elephant@pld.org.pl (Marek Obuchowicz) Date: Thu, 30 Mar 2000 17:23:26 +0200 (CEST) Subject: [Mailman-Developers] A suggestion Message-ID: Hi! Sorry if i am writing to wrong address, but i couldn't find a better one :) I couldn't find the possibility of removing headers in mailman. Removing 'Recieved' headers is ofen used by majordomo users (like me in the past). I host one list and I'd like to hide senders' Message-Id. How can I do it? Greets, Marek -- __ Marek "Suonik" Obuchowicz, elephant@pld.org.pl /'_)___ Member of GNU generation, PLD project and "H" ( \ ____|\ http://www.projcom.com.pl/ http://www.pld.org.pl/ // || Home Page: http://suonik.art.pl/ (pgp-key is there) From claw@kanga.nu Thu Mar 30 18:27:47 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 30 Mar 2000 10:27:47 -0800 Subject: [Mailman-Developers] A suggestion In-Reply-To: Message from Marek Obuchowicz of "Thu, 30 Mar 2000 17:23:26 +0200." References: Message-ID: <13331.954440867@kanga.nu> On Thu, 30 Mar 2000 17:23:26 +0200 (CEST) Marek Obuchowicz wrote: > I couldn't find the possibility of removing headers in mailman. > Removing 'Recieved' headers is ofen used by majordomo users (like > me in the past). I host one list and I'd like to hide senders' > Message-Id. Eeek! Bad! Bad! > How can I do it? Use a procmail filter inserted before the mailman script invocations. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Thu Mar 30 16:31:26 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 30 Mar 2000 11:31:26 -0500 (EST) Subject: [Mailman-Developers] A suggestion References: Message-ID: <14563.33118.561356.947439@anthem.cnri.reston.va.us> >>>>> "MO" == Marek Obuchowicz writes: MO> I couldn't find the possibility of removing headers in MO> mailman. Removing 'Recieved' headers is ofen used by MO> majordomo users (like me in the past). I host one list and MO> I'd like to hide senders' Message-Id. How can I do it? Header filtering is not supported through the web interface, but Mailman 2.0 (of which beta1 is currently released) will provide a very simple way for you to add such functionality. You can drop a handler module into Mailman/Handlers which will strip out the headers you don't care about. See Mailman/Handlers/Cleanse.py for an example. -Barry From ttsoares@cedep.ifch.ufrgs.br Fri Mar 31 17:51:52 2000 From: ttsoares@cedep.ifch.ufrgs.br (Thomas Tschoepke Soares) Date: Fri, 31 Mar 2000 14:51:52 -0300 (EST) Subject: [Mailman-Developers] About MailMan site... Message-ID: Hi! I am trying to install mailman here but there are some problems... So, I have been trying to download the newer beta version but the domain www.list.org even resolv at a ping command! Could you provide an alternative place from where to get this prog? Or, even better, how about to include it in the sourceforge portal? Thank you, regards Thomas. | Thomas Tschoepke Soares | // Mate do | ttsoares@cedep.ifch.ufrgs.br |(~~~//~~) estrivo bendito! |--UIN:961141-------------------------------| \ / Amargo que |The fact is a secondary aspect of reality. | `_/' a gente bebe... From dan.mick@West.Sun.COM Fri Mar 31 20:26:16 2000 From: dan.mick@West.Sun.COM (Dan Mick) Date: Fri, 31 Mar 2000 12:26:16 -0800 Subject: [Mailman-Developers] About MailMan site... References: Message-ID: <38E509E8.71ADD992@west.sun.com> Thomas Tschoepke Soares wrote: > I am trying to install mailman here but there are some problems... > > So, I have been trying to download the newer beta version but the domain > www.list.org even resolv at a ping command! This is surely a transient failure; www.list.org has been pretty reliable for me. But you're right; I can't get DNS for it either, and I can't ping its nameservers. The technical contact for the domain is aware and is working on the problem; they have a network outage. From ricardo@rixhq.nu Fri Mar 31 21:13:14 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Fri, 31 Mar 2000 23:13:14 +0200 Subject: [Mailman-Developers] suggestion Message-ID: <20000331231314.B4174@miss-janet.com> Hi, How about moving things like the list welcome message, headers, footers and other multiple line texts out of the database and into seperate text files? And treat/edit them in the same way as the html templates... this would it also make it easier to edit them directly. I remember having a lot of difficulties (when I started using mailman about a year ago) with creating the welcome message because the textarea was too small and strange things happened when i cut/pasted it into the textarea with Netscape on Linux (I had to boot windows just to be able to enter the welcome message properly ;) ) Ricardo. -- From bigdog@dogpound.vnet.net Fri Mar 31 21:28:25 2000 From: bigdog@dogpound.vnet.net (Matt Davis) Date: Fri, 31 Mar 2000 16:28:25 -0500 (EST) Subject: [Mailman-Developers] suggestion In-Reply-To: <20000331231314.B4174@miss-janet.com> Message-ID: On Fri, 31 Mar 2000, Ricardo Kustner wrote: > How about moving things like the list welcome message, headers, footers > and other multiple line texts out of the database and into seperate > text files? And treat/edit them in the same way as the html templates... > this would it also make it easier to edit them directly. > I remember having a lot of difficulties (when I started using mailman > about a year ago) with creating the welcome message because the textarea > was too small and strange things happened when i cut/pasted it into the > textarea with Netscape on Linux (I had to boot windows just to be able > to enter the welcome message properly ;) ) I agree. But maybe have both available. As in, the web page grabs the info from the txt files and allows you to edit via the web interface or directly from the txt files. -- Matt Davis - ICQ# 934680 http://dogpound.vnet.net/ NoWonder UNIX Tech - http://www.nowonder.com Madness takes it's toll, please have exact change From dan.mick@West.Sun.COM Fri Mar 31 22:27:08 2000 From: dan.mick@West.Sun.COM (Dan Mick) Date: Fri, 31 Mar 2000 14:27:08 -0800 Subject: [Mailman-Developers] suggestion References: Message-ID: <38E5263C.8763377F@west.sun.com> Matt Davis wrote: > > On Fri, 31 Mar 2000, Ricardo Kustner wrote: > > > How about moving things like the list welcome message, headers, footers > > and other multiple line texts out of the database and into seperate > > text files? And treat/edit them in the same way as the html templates... > > this would it also make it easier to edit them directly. > > I remember having a lot of difficulties (when I started using mailman > > about a year ago) with creating the welcome message because the textarea > > was too small and strange things happened when i cut/pasted it into the > > textarea with Netscape on Linux (I had to boot windows just to be able > > to enter the welcome message properly ;) ) > > I agree. But maybe have both available. As in, the web page grabs the > info from the txt files and allows you to edit via the web interface or > directly from the txt files. Thirded, bigtime. Such "obvious changers" should be RCSed, for instance, and there's no easy way to do that with the current scheme. I keep threatening, although I haven't yet, to set up a script that will "check out text, allow editing, check it back in, and invoke Python to shove it into config.db". (that's actually pretty easy to do; just open the file and set "m.welcome_msg" from it, for the welcome, for instance..) From ricardo@rixhq.nu Fri Mar 31 22:54:16 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 1 Apr 2000 00:54:16 +0200 Subject: [Mailman-Developers] suggestion In-Reply-To: ; from bigdog@dogpound.vnet.net on Fri, Mar 31, 2000 at 04:28:25PM -0500 References: <20000331231314.B4174@miss-janet.com> Message-ID: <20000401005416.A760@miss-janet.com> On Fri, Mar 31, 2000 at 04:28:25PM -0500, Matt Davis wrote: > > How about moving things like the list welcome message, headers, footers > > and other multiple line texts out of the database and into seperate > > text files? And treat/edit them in the same way as the html templates... > > this would it also make it easier to edit them directly. > I agree. But maybe have both available. As in, the web page grabs the > info from the txt files and allows you to edit via the web interface or > directly from the txt files. Yes that's actually what I was thinking about too... but have it editted in the same way as the html templates (one page with a big textarea to give more editting freedom). Ricardo. -- From davidb@chelsea.net Wed Mar 1 17:00:12 2000 From: davidb@chelsea.net (David Birnbaum) Date: Wed, 1 Mar 2000 12:00:12 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders Message-ID: Folks, We just started converting from Majordomo to Mailman and we couldn't be more pleased; thanks for the good work, dear authors. I do have a couple of questions I did not see an answer to in the documentation anywhere, or listed in Jitterbug, though: 1. The password reminders come out from mailman-owner@masterdomain.com instead of list-admin@virtualdomain.com, which caused a lot of confusion for one of our mailing lists hosted on a virtual domain. Is there any way to change that? 2. Bounces are sent to the poor postmaster instead of a -admin address. I'm not entirely certain, but I think an Errors-To: header or something like that in all Mailman messages might allow one to distribute that load somewhat. Alas, I am only a poor, crippled, Perl hacker, or I might take a crack at fixing these two. In any case, thanks, David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... From jim@cosource.com Wed Mar 1 22:26:25 2000 From: jim@cosource.com (Jim Hebert) Date: Wed, 1 Mar 2000 17:26:25 -0500 (EST) Subject: [Mailman-Developers] Posting to 2 lists breaks newsgating for the second one Message-ID: I filed a jitterbug report about this a couple weeks back... Applix is fairly motivated about using mailman for their internal lists but needs the ability to crosspost on the mail side and have it show up in all the right newsgroups too. (If this doesn't make sense, visit the jitterbug report below.) So, I got them to put some money behind the bug report, if someone will fix it: http://www.python.org/mailman-bugs/incoming?id=202;user=guest http://www.cosource.com/cgi-bin/cos.pl/wish/info/295 (Sorry if this is better posted to the -users list, I just joined both lists and don't have a clear sense of which one would have been better...) All in all, we're loving mailman! =) jim [I work for Cosource / Applix.] From Dan Mick Thu Mar 2 03:52:56 2000 From: Dan Mick (Dan Mick) Date: Wed, 1 Mar 2000 19:52:56 -0800 (PST) Subject: [Mailman-Developers] Mailman password and administrative reminders Message-ID: <200003020353.TAA19329@utopia.West.Sun.COM> ? This very message came to me with the following header: Errors-To: mailman-developers-admin@python.org All my bounces come to the list admin address, set in the admin webpage, in the second field of General Options. Do you have that set to something, and bounces still come to root? > 2. Bounces are sent to the poor postmaster instead of a -admin address. > I'm not entirely certain, but I think an Errors-To: header or something > like that in all Mailman messages might allow one to distribute that load > somewhat. From lindsey@ncsa.uiuc.edu Thu Mar 2 05:02:43 2000 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Wed, 1 Mar 2000 23:02:43 -0600 (CST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <200003020353.TAA19329@utopia.West.Sun.COM> from "Dan Mick" at Mar 01, 2000 07:52:56 PM Message-ID: <200003020502.XAA00295@glorfindel.ncsa.uiuc.edu> > Errors-To: mailman-developers-admin@python.org > > All my bounces come to the list admin address, set in > the admin webpage, in the second field of General Options. > Do you have that set to something, and bounces still come to root? > > > 2. Bounces are sent to the poor postmaster instead of a -admin address. > > I'm not entirely certain, but I think an Errors-To: header or something > > like that in all Mailman messages might allow one to distribute that load > > somewhat. Errors-To: is way deprecated anyhow... It was intended to supercede the envelope From address for errors, but it violated RFC1123 and was subsequently ignored by many MTAs. Chris ---------------------------------------------------------------------- Christopher Lindsey, Senior System Engineer National Center for Supercomputing Applications (NCSA) From davidb@chelsea.net Thu Mar 2 12:02:20 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 07:02:20 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <200003020353.TAA19329@utopia.West.Sun.COM> Message-ID: Hmm.... It is the administrative messages that don't have this set, I believe. We had a large list (4500 members) that was just converted from majordomo. Our password reminders went out, and about 500 bounces came to postmaster instead of going to the list admin. We're having the auto-bounce feature turn people off, but the list has only been broadcast once, so people haven't been auto-unsubscribed yet (a more agressive unsubcribe might be helpful for these once-a-month broadcast lists, but perhaps I don't have it tuned right.) The message actually sent to the list (ie, the non-administrative stuff) seemed to work properly and bounce to the list owners. BTW - minor bug. Even if you turn password reminders off, the welcome message that's created still says they are sent out. David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Wed, 1 Mar 2000, Dan Mick wrote: > ? This very message came to me with the following header: > > Errors-To: mailman-developers-admin@python.org > > All my bounces come to the list admin address, set in > the admin webpage, in the second field of General Options. > Do you have that set to something, and bounces still come to root? > > > 2. Bounces are sent to the poor postmaster instead of a -admin address. > > I'm not entirely certain, but I think an Errors-To: header or something > > like that in all Mailman messages might allow one to distribute that load > > somewhat. > > From davidb@chelsea.net Thu Mar 2 12:13:55 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 07:13:55 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <200003020353.TAA19329@utopia.West.Sun.COM> Message-ID: Here's the headers for the reminder: Return-Path: Received: from killian.chelsea.net (localhost [127.0.0.1]) by killian.chelsea.net (8.9.3/8.9.3) with ESMTP id FAA15246 for ; Wed, 1 Mar 2000 05:52:23 -0500 (EST) Date: Wed, 1 Mar 2000 05:52:23 -0500 (EST) Message-Id: <200003011052.FAA15246@killian.chelsea.net> From: mailman-owner@chelsea.net Subject: thebody.com mailing list memberships reminder To: ###A USER### X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: The Test List It should be from (I think), thebody-admin@thebody.com, with an Errors-To: header. Not sure why List-Id: is The Test List...that's odd. David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Wed, 1 Mar 2000, Dan Mick wrote: > ? This very message came to me with the following header: > > Errors-To: mailman-developers-admin@python.org > > All my bounces come to the list admin address, set in > the admin webpage, in the second field of General Options. > Do you have that set to something, and bounces still come to root? > > > 2. Bounces are sent to the poor postmaster instead of a -admin address. > > I'm not entirely certain, but I think an Errors-To: header or something > > like that in all Mailman messages might allow one to distribute that load > > somewhat. > > From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Mar 2 13:55:01 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 2 Mar 2000 08:55:01 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders References: <200003020353.TAA19329@utopia.West.Sun.COM> Message-ID: <14526.29365.432370.248009@anthem.cnri.reston.va.us> Here's the problem in a nutshell (if my quick browse of the thread is correct). When a user is to get the password reminder, Mailman collates the passwords for all the lists that the user is on (for that virtual domain, but let's ignore that). So one password reminder refers to potentially several lists. So which list -owner address (e.g. bounce detecting addr) should get the bounces? As I see it, the right solution is the following: - Mailman has no catch-all address like Majordomo has. I.e. you can't send `help' to mailman@... unless you actually craft a normal Mailman list for this addr. This is bogus, because it just thinks it's a normal list, not something special. Step one of the fix is to write scripts that can handle these over-arching addrs. Then of course, we'd make mailman-owner@... the recipient of all the bounced password reminders. The script on the tail of that would Do The Right Thing. - Unfortunately, the correct solution, IMO requires user databases, because otherwise you need to cycle through all the lists looking for the user address to disable. Imagine for a moment, hundreds of bounces coming back starting at 12:02 the first of every month, each one trying to hit every list on your site. Ouch! I've been seriously thinking about adding support for the first bullet for 1.2 (scratching my own itch, doncha know), but I also just want to start getting the betas out, so it may have to wait. Harald's got stuff in the pipeline to support user databases, but that's defiitely a post 1.2 feature. If you wanted to play with this stuff in the meantime, you could implement #1, and see how bad a hit the touch-all-lists approach would be. -Barry From davidb@chelsea.net Thu Mar 2 14:26:05 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 09:26:05 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <14526.29365.432370.248009@anthem.cnri.reston.va.us> Message-ID: Perhaps I'm missing something at the fundamental architecture level, but wouldn't it make more sense to just cycle through each list and send the reminder using the list owner? It's probably nice to only get one password reminder email, but how big and inconvenience would that be, anyway? This way, each user gets one email per list, and if it bounces, you know what list to take it off of. That won't disable the address server wide, but sooner or later some bounces will happen on the other lists and take care of it. This way you don't have to do the user database thing. I have nothing more than anecdotal evidence (ie, my ISP), but how often is one address on multiple lists at a given site? We've had to turn off password notification, because now all the people on this list who got password notifications are now replying to mailman-owner with list related requests. Sigh.... David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Thu, 2 Mar 2000, Barry A. Warsaw wrote: > > Here's the problem in a nutshell (if my quick browse of the thread is > correct). > > When a user is to get the password reminder, Mailman collates the > passwords for all the lists that the user is on (for that virtual > domain, but let's ignore that). So one password reminder refers to > potentially several lists. So which list -owner address (e.g. bounce > detecting addr) should get the bounces? > > As I see it, the right solution is the following: > > - Mailman has no catch-all address like Majordomo has. I.e. you can't > send `help' to mailman@... unless you actually craft a normal > Mailman list for this addr. This is bogus, because it just thinks > it's a normal list, not something special. Step one of the fix is > to write scripts that can handle these over-arching addrs. Then of > course, we'd make mailman-owner@... the recipient of all the bounced > password reminders. The script on the tail of that would Do The > Right Thing. > > - Unfortunately, the correct solution, IMO requires user databases, > because otherwise you need to cycle through all the lists looking > for the user address to disable. Imagine for a moment, hundreds of > bounces coming back starting at 12:02 the first of every month, each > one trying to hit every list on your site. Ouch! > > I've been seriously thinking about adding support for the first bullet > for 1.2 (scratching my own itch, doncha know), but I also just want to > start getting the betas out, so it may have to wait. Harald's got > stuff in the pipeline to support user databases, but that's defiitely > a post 1.2 feature. > > If you wanted to play with this stuff in the meantime, you could > implement #1, and see how bad a hit the touch-all-lists approach would > be. > > -Barry > From secabeen@pobox.com Thu Mar 2 15:29:23 2000 From: secabeen@pobox.com (Ted Cabeen) Date: Thu, 02 Mar 2000 09:29:23 -0600 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: Your message of "Thu, 02 Mar 2000 08:55:01 EST." <14526.29365.432370.248009@anthem.cnri.reston.va.us> Message-ID: <200003021529.JAA08948@entropy.uchicago.edu> In message <14526.29365.432370.248009@anthem.cnri.reston.va.us>, "Barry A. Wars aw" writes: > >Here's the problem in a nutshell (if my quick browse of the thread is >correct). > >When a user is to get the password reminder, Mailman collates the >passwords for all the lists that the user is on (for that virtual >domain, but let's ignore that). So one password reminder refers to >potentially several lists. So which list -owner address (e.g. bounce >detecting addr) should get the bounces? What about sending the messages out with multiple addresses in the From header? It's a little weird, but is RFC legal, and that way each reminder will bounce to all of the lists whose password is listed in the email. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen@pobox.com Check Website or finger for PGP Public Key secabeen@midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen@aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com From Nigel.Metheringham@VData.co.uk Thu Mar 2 15:34:58 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Thu, 02 Mar 2000 15:34:58 +0000 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: Message from Ted Cabeen of "Thu, 02 Mar 2000 09:29:23 CST." <200003021529.JAA08948@entropy.uchicago.edu> Message-ID: secabeen@pobox.com said: > What about sending the messages out with multiple addresses in the > From header? It's a little weird, but is RFC legal, and that way > each reminder will bounce to all of the lists whose password is > listed in the email. Bounces go to the *envelope* sender address not the From: address. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From bwarsaw@cnri.reston.va.us Thu Mar 2 16:10:10 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Thu, 2 Mar 2000 11:10:10 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders References: <14526.29365.432370.248009@anthem.cnri.reston.va.us> Message-ID: <14526.37474.389793.355286@anthem.cnri.reston.va.us> >>>>> "DB" == David Birnbaum writes: DB> I have nothing more than anecdotal evidence (ie, my ISP), but DB> how often is one address on multiple lists at a given site? It all depends. Some sites might run only a few, or mostly unconnected lists. At Python.Org, such a change would cause a revolt :). DB> We've had to turn off password notification, because now all DB> the people on this list who got password notifications are now DB> replying to mailman-owner with list related requests. Sigh.... Yup, I agree, the current situation is suboptimal. It will be fixed, it's just a matter of when. -Barry From davidb@chelsea.net Thu Mar 2 17:18:46 2000 From: davidb@chelsea.net (David Birnbaum) Date: Thu, 2 Mar 2000 12:18:46 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: <14526.37474.389793.355286@anthem.cnri.reston.va.us> Message-ID: Revolt among the Python developers would certainly be a bad thing, given they are doing the development ;) Thanks for the help, looking forward to eventual solution. David. ----- ** WARNING ** This message was composed by a temporarily crippled programmer using a speech recognition system. Please don't be alarmed if some extremely strange word usage shows up in the message. Many thanks.... On Thu, 2 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > >>>>> "DB" == David Birnbaum writes: > > DB> I have nothing more than anecdotal evidence (ie, my ISP), but > DB> how often is one address on multiple lists at a given site? > > It all depends. Some sites might run only a few, or mostly > unconnected lists. At Python.Org, such a change would cause a revolt > :). > > DB> We've had to turn off password notification, because now all > DB> the people on this list who got password notifications are now > DB> replying to mailman-owner with list related requests. Sigh.... > > Yup, I agree, the current situation is suboptimal. It will be fixed, > it's just a matter of when. > > -Barry > From jam@jamux.com Thu Mar 2 17:31:40 2000 From: jam@jamux.com (John A. Martin) Date: Thu, 02 Mar 2000 12:31:40 -0500 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: (Nigel Metheringham; Thu, 02 Mar 2000 15:34:58 +0000) Message-ID: <20000302173143.3426B481D@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nigel" == Nigel Metheringham >>>>> "Re: [Mailman-Developers] Mailman password and administrative reminders" >>>>> Thu, 02 Mar 2000 15:34:58 +0000 Nigel> secabeen@pobox.com said: >> What about sending the messages out with multiple addresses in >> the From header? It's a little weird, but is RFC legal, and >> that way each reminder will bounce to all of the lists whose >> password is listed in the email. Nigel> Bounces go to the *envelope* sender address not the From: Nigel> address. Why not 'X-From:' header fields, one for each list, to make it easy for a script to do something sensible? Also perhaps also 'X-To' for to be reliable and easy after forwarding and header munging and body replacement. Some "bounces" seem to take the attitude that you better damn well know who you sent the mail to! jam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: By Mailcrypt 3.5.4 and Gnu Privacy Guard iD4DBQE4vqVsUEvv1b/iXy8RAuYnAJYlvOjPMqyokcuz/Hcqtv7wMifuAJ9Y4p1R DmNFtRZO0L5FgK3IsY+VHg== =RFV/ -----END PGP SIGNATURE----- From docwhat@gerf.org Thu Mar 2 18:00:01 2000 From: docwhat@gerf.org (The Doctor What) Date: Thu, 2 Mar 2000 10:00:01 -0800 Subject: [Mailman-Developers] Admin overview page should list number of pending admin requests per list In-Reply-To: ; from Harald.Meland@usit.uio.no on Mon, Feb 07, 2000 at 09:17:50PM +0100 References: <20000119175228.67F911FF03B@perens.com> <14469.62839.700229.701854@anthem.cnri.reston.va.us> Message-ID: <20000302100001.G3332@gerf.org> * Harald Meland (Harald.Meland@usit.uio.no) [000207 14:18]: > [Barry A. Warsaw] > But that means that _anyone_ can see whether there are held messages > in a list -- which really is giving out more info than appropriate (at > least in some cases). > > I think there should be a separate "userinfo" CGI script which, after > proper autentication, shows what lists that user is 1) member of and > 2) admin for. Putting the info you both crave for on that page would > be Good. Another option, using the existing structure is to have a page show all the lists that a password works for... Ciao! -- "Well, given that the universe is infinite, and that God is infinite, and that God created the universe, (pause) would you like a piece of toast?" --Talkie Toaster (Red Dwarf episode: Dimension Jump) The Doctor What: A Holtje Production http://docwhat.gerf.org/ docwhat@gerf.org (finger docwhat@gerf.org for PGP key) KF6VNC From Nigel.Metheringham@VData.co.uk Fri Mar 3 09:12:40 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Fri, 03 Mar 2000 09:12:40 +0000 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: Message from "John A. Martin" of "Thu, 02 Mar 2000 12:31:40 EST." <20000302173143.3426B481D@athene.jamux.com> Message-ID: Loading the headers and/or the body with additional clues as to the original recipients and lists are is good... but some brain dead MTAs will still carefully anonymise the bounce messages - some do it so effectively you feel it has to be deliberate :-( Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From jwt@dskk.co.jp Tue Mar 7 09:23:54 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Tue, 7 Mar 2000 18:23:54 +0900 Subject: [Mailman-Developers] Re: Bogus directory In-Reply-To: <38BFC2F9.9B98ABE1@linux.org.uy>; from rodolfo@linux.org.uy on Fri, Mar 03, 2000 at 10:49:45AM -0300 References: <38BFC2F9.9B98ABE1@linux.org.uy> Message-ID: <20000307182354.A9325@mail.dskk.co.jp> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii On Fri, Mar 03, 2000 at 10:49:45AM -0300, Rodolfo Pilas wrote in mailman-users: [...] > However I am in receipt of a message about bogus directory: [...] > List todos.tecnico has a bogus archive_directory: > /var/spool/mailman/archives/private/todos.tecnico > List todos.sistemas has a bogus archive_directory: > /var/spool/mailman/archives/private/todos.sistemas The "bogus archive directory" issue seems to come up fairly often. Perhaps it would be worthwhile to add a check to cron/nightly_gzip to find out if it is simply a matter of there not yet being any articles to archive. Mailman could check post_id or last_post_time. I've attached one possibility. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nightly_gzip.diff" --- nightly_gzip.orig Wed Sep 1 03:14:04 1999 +++ nightly_gzip Tue Mar 7 18:17:16 2000 @@ -106,7 +106,8 @@ try: allfiles = os.listdir(dir) except os.error: - print 'List', name, 'has a bogus archive_directory:', dir + if mlist.last_post_time: + print 'List', name, 'has a bogus archive_directory:', dir continue files = [] for f in allfiles: --wRRV7LY7NUeQGEoC-- From jwt@dskk.co.jp Thu Mar 9 07:59:35 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Thu, 9 Mar 2000 16:59:35 +0900 Subject: [Mailman-Developers] monthly reminder bounce remedies Message-ID: <20000309165935.B21018@mail.dskk.co.jp> As mailman-owner I get a large number of bounces every month from password reminder messages with Mailman 1.1. The vast majority of these are for people whose subscription state has already been set to nomail. Is there already an automated way of dealing with these? If not... Would it be reasonable to set an (optional?) age limit for how long someone could be in the "nomail" state and still be "subscribed"? The mailpasswords cron job could "age" them and eventually delete them. The only drawback I've thought of is that it would periodically unsubscribe people that had subscribed just to check archives or mailing list membership (which may not be a bad thing :-). (Or visiting the web page resets their aging?) The alternative would seem to be to process the bounces from the reminders and (after a couple) remove the subscriber. Jim -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ From claw@kanga.nu Thu Mar 9 08:44:08 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 00:44:08 -0800 Subject: [Mailman-Developers] Failed authentication Message-ID: <20037.952591448@kanga.nu> I'm suddenly unable to log into the admin interfaces for my lists. Nothing gets posted to the log files on failed attempts. Poking about in ~/Mailman/Cgi/admin.py around the code: global cgi_data cgi_data = cgi.FieldStorage() AFAICT cgi_data is getting set to an empty dictionary (it doesn't seem to be "None"). Ideas? -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Thu Mar 9 09:04:46 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 01:04:46 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Thu, 09 Mar 2000 00:44:08 PST." <20037.952591448@kanga.nu> References: <20037.952591448@kanga.nu> Message-ID: <22817.952592686@kanga.nu> On Thu, 09 Mar 2000 00:44:08 -0800 J C Lawrence wrote: > I'm suddenly unable to log into the admin interfaces for my lists. > Nothing gets posted to the log files on failed attempts. > Poking about in ~/Mailman/Cgi/admin.py around the code: > global cgi_data cgi_data = cgi.FieldStorage() > AFAICT cgi_data is getting set to an empty dictionary (it doesn't > seem to be "None"). Ideas? Okay, not examply an empty dictionary (FieldStorage class), but it is empty per its own keys() and __len__ method. However, snooping the wire shows the POST with the "adminpw" in it set correctly. The apparancy is that for some reason the Cgi module is not getting the FORM variables properly. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Thu Mar 9 10:04:37 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 02:04:37 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Thu, 09 Mar 2000 01:04:46 PST." <22817.952592686@kanga.nu> References: <20037.952591448@kanga.nu> <22817.952592686@kanga.nu> Message-ID: <30727.952596277@kanga.nu> On Thu, 09 Mar 2000 01:04:46 -0800 J C Lawrence wrote: > On Thu, 09 Mar 2000 00:44:08 -0800 J C Lawrence > wrote: >> I'm suddenly unable to log into the admin interfaces for my >> lists. Nothing gets posted to the log files on failed attempts. >> Poking about in ~/Mailman/Cgi/admin.py around the code: >> global cgi_data cgi_data = cgi.FieldStorage() >> AFAICT cgi_data is getting set to an empty dictionary (it doesn't >> seem to be "None"). Ideas? > Okay, not examply an empty dictionary (FieldStorage class), but it > is empty per its own keys() and __len__ method. However, snooping > the wire shows the POST with the "adminpw" in it set correctly. > The apparancy is that for some reason the Cgi module is not > getting the FORM variables properly. Poking around even more: FieldStorage is blank. It is not getting the form variable (adminpw) from the login form. I don't know why. If I put the PW on the URL ala: http://server/mailman/admin/listname/?adminpw=password then everything works just fine up until I try and submit another form. I'm not sure where to go from here. Barry, got any pointers? -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Thu Mar 9 16:12:30 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 9 Mar 2000 11:12:30 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <20037.952591448@kanga.nu> <22817.952592686@kanga.nu> <30727.952596277@kanga.nu> Message-ID: <14535.52590.476700.446176@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> Poking around even more: | FieldStorage is blank. It is not getting the form variable | (adminpw) from the login form. I don't know why. JCL> If I put the PW on the URL ala: JCL> http://server/mailman/admin/listname/?adminpw=password JCL> then everything works just fine up until I try and submit JCL> another form. JCL> I'm not sure where to go from here. Barry, got any pointers? What changed? Did you upgrade Python, your browser, web server (or server config), OS, or anything else? Did you make any changes to Mailman? I've never seen this, but it sounds like there is now a problem somewhere between your server and the Mailman cgi scripts. I've never seen this happen! -Barry From claw@kanga.nu Thu Mar 9 18:43:51 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 10:43:51 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from "Barry A. Warsaw" of "Thu, 09 Mar 2000 11:12:30 EST." <14535.52590.476700.446176@anthem.cnri.reston.va.us> References: <20037.952591448@kanga.nu> <22817.952592686@kanga.nu> <30727.952596277@kanga.nu> <14535.52590.476700.446176@anthem.cnri.reston.va.us> Message-ID: <1540.952627431@kanga.nu> On Thu, 9 Mar 2000 11:12:30 -0500 (EST) Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Poking around even more: > | FieldStorage is blank. It is not getting the form variable > | (adminpw) from the login form. I don't know why. JCL> If I put the PW on the URL ala: JCL> http://server/mailman/admin/listname/?adminpw=password JCL> then everything works just fine up until I try and submit JCL> another form. JCL> I'm not sure where to go from here. Barry, got any pointers? > What changed? Did you upgrade Python, your browser, web server > (or server config), OS, or anything else? Did you make any > changes to Mailman? I've never seen this, but it sounds like > there is now a problem somewhere between your server and the > Mailman cgi scripts. I've never seen this happen! I installed mod_ssl (from a package) and restarted apache. I'm running under *exactly* the same Apache configs as I was before. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From mentor@alb-net.com Thu Mar 9 19:50:44 2000 From: mentor@alb-net.com (Mentor Cana) Date: Thu, 9 Mar 2000 14:50:44 -0500 (EST) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <1540.952627431@kanga.nu> Message-ID: > > changes to Mailman? I've never seen this, but it sounds like > > there is now a problem somewhere between your server and the > > Mailman cgi scripts. I've never seen this happen! > > I installed mod_ssl (from a package) and restarted apache. I'm > running under *exactly* the same Apache configs as I was before. I've installed mod_ssl (compiled it myself) and can do mailman admin via the SSL port with no problem. No password problems. Hope this info helps a bit. later, Mentor From claw@kanga.nu Thu Mar 9 20:14:58 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 12:14:58 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from Mentor Cana of "Thu, 09 Mar 2000 14:50:44 EST." References: Message-ID: <14146.952632898@kanga.nu> On Thu, 9 Mar 2000 14:50:44 -0500 (EST) Mentor Cana wrote: > I've installed mod_ssl (compiled it myself) and can do mailman > admin via the SSL port with no problem. No password problems. Aye, what's especially odd is that forms are process properly elsewhere (PHP for instance). So the Apache side and the modules sides are Okay its just something with the Mailman CGI wrapper. I guess. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Thu Mar 9 20:55:44 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Thu, 9 Mar 2000 15:55:44 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14146.952632898@kanga.nu> Message-ID: <14536.4048.420476.522854@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> Aye, what's especially odd is that forms are process properly JCL> elsewhere (PHP for instance). So the Apache side and the JCL> modules sides are Okay its just something with the Mailman JCL> CGI wrapper. I guess. I still want to know at what point the cgi data is getting corrupted. Is it between Apache and the C wrapper? Is it between the C wrapper and invoking the Python driver script? Is it between the driver script and the specific Mailman/Cgi module? -Barry From claw@kanga.nu Thu Mar 9 21:11:06 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 09 Mar 2000 13:11:06 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Thu, 09 Mar 2000 15:55:44 EST." <14536.4048.420476.522854@anthem.cnri.reston.va.us> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> Message-ID: <21848.952636266@kanga.nu> On Thu, 9 Mar 2000 15:55:44 -0500 (EST) bwarsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Aye, what's especially odd is that forms are process properly JCL> elsewhere (PHP for instance). So the Apache side and the JCL> modules sides are Okay its just something with the Mailman CGI JCL> wrapper. I guess. > I still want to know at what point the cgi data is getting > corrupted. Is it between Apache and the C wrapper? Is it between > the C wrapper and invoking the Python driver script? Is it > between the driver script and the specific Mailman/Cgi module? I'm really not sure, and I'm not too sure how to find out either. Could you give me some hints where to poke this? -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From Harald.Meland@usit.uio.no Fri Mar 10 20:59:19 2000 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 10 Mar 2000 21:59:19 +0100 Subject: [Mailman-Developers] Mailman password and administrative reminders In-Reply-To: David Birnbaum's message of "Thu, 2 Mar 2000 07:13:55 -0500 (EST)" References: Message-ID: [David Birnbaum] > Here's the headers for the reminder: > > Return-Path: > Received: from killian.chelsea.net (localhost [127.0.0.1]) > by killian.chelsea.net (8.9.3/8.9.3) with ESMTP id FAA15246 > for ; Wed, 1 Mar 2000 05:52:23 -0500 (EST) > Date: Wed, 1 Mar 2000 05:52:23 -0500 (EST) > Message-Id: <200003011052.FAA15246@killian.chelsea.net> > From: mailman-owner@chelsea.net > Subject: thebody.com mailing list memberships reminder > To: ###A USER### > X-No-Archive: yes > Precedence: bulk > X-Mailman-Version: 1.1 > Precedence: bulk > List-Id: The Test List > > It should be from (I think), thebody-admin@thebody.com, with an Errors-To: > header. > > Not sure why List-Id: is The Test List...that's odd. That's because the script, while iterating through all lists, looks for the first "public" list. When found, that list is remembered, and that list's (fasttrack) delivery pipeline is used for sending out all the messages. As the "test" list is usually created pretty early on in any particular Mailman installation, it is not entirely uncommon that this list's List-Id: gets stuck on all password reminders... Normally it is nice that Mailman indicates which list's fasttrack pipeline you received a particular message through, but I can see that it might be confusing in this situation. However, a proper remedy is complicated by the lack of a list-independent Mailman mail address -- and thus, as Barry mentioned, also by the lack of a user database. -- Harald From bwarsaw@cnri.reston.va.us Fri Mar 10 21:01:03 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Fri, 10 Mar 2000 16:01:03 -0500 (EST) Subject: [Mailman-Developers] Mailman password and administrative reminders References: Message-ID: <14537.25231.104823.795653@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> However, a proper remedy is complicated by the lack of a HM> list-independent Mailman mail address -- and thus, as Barry HM> mentioned, also by the lack of a user database. Both problems which /will/ be remedied at some point. -Barry From Harald.Meland@usit.uio.no Fri Mar 10 21:17:41 2000 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 10 Mar 2000 22:17:41 +0100 Subject: [Mailman-Developers] Posting to 2 lists breaks newsgating for the second one In-Reply-To: Jim Hebert's message of "Wed, 1 Mar 2000 17:26:25 -0500 (EST)" References: Message-ID: [Jim Hebert] > I filed a jitterbug report about this a couple weeks back... > > Applix is fairly motivated about using mailman for their internal lists > but needs the ability to crosspost on the mail side and have it show up in > all the right newsgroups too. (If this doesn't make sense, visit the > jitterbug report below.) I suspect this has something to do with the fact that two separate Usenet messages can't have the same Message-Id. If you could have a look in your logs/post Mailman log, you might actually find some foundation for my suspicion (due to the except: clause around line 125 of Mailman/Handlers/ToUsenet.py). If this indeed is the problem at hand, I'm not sure how best to fix it. The optimal solution would be if mail "crossposts" actually turned into proper Usenet crossposts, and not multiple (nearly) identical posts to different newsgroups. However, I don't know enough about NNTP to say if implementing something like that is at all possible. A quick band-aid solution might be to change the Message-Id a wee bit (in a way that makes the change differ from list to list) before passing the message to the NNTP server. > So, I got them to put some money behind the bug report, if someone will > fix it: > > http://www.python.org/mailman-bugs/incoming?id=202;user=guest > http://www.cosource.com/cgi-bin/cos.pl/wish/info/295 > > (Sorry if this is better posted to the -users list, I just joined > both lists and don't have a clear sense of which one would have been > better...) I haven't had time to read -users for a looooong time, but I think -developers is the proper place to post specific feature requests like this. > All in all, we're loving mailman! =) Great :) -- Harald From claw@kanga.nu Sun Mar 12 08:19:18 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 00:19:18 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Thu, 09 Mar 2000 13:11:06 PST." <21848.952636266@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> Message-ID: <577.952849158@kanga.nu> Background data as this is also going to the Debian Mailman package maintainer: Mailman's web interface suddenly stopped working for me. The forms would display but I am unable authenticate not matter what browser (Netscape 4.05 and 4.7, Lynx, W3M or Mozilla M14) I use. On Thu, 09 Mar 2000 13:11:06 -0800 J C Lawrence wrote: > On Thu, 9 Mar 2000 15:55:44 -0500 (EST) bwarsaw > wrote: >>>>>>> "JCL" == J C Lawrence writes: JCL> Aye, what's especially odd is that forms are process properly JCL> elsewhere (PHP for instance). So the Apache side and the JCL> modules sides are Okay its just something with the Mailman CGI JCL> wrapper. I guess. >> I still want to know at what point the cgi data is getting >> corrupted. Is it between Apache and the C wrapper? Is it >> between the C wrapper and invoking the Python driver script? Is >> it between the driver script and the specific Mailman/Cgi module? > I'm really not sure, and I'm not too sure how to find out either. > Could you give me some hints where to poke this? I've done some more digging, implemented ScriptLog in Apache, inserted sys.exit(1) in the admin script to force a failure right after the FieldStorage call, and then instrumented pythonlib/cgi.py. Findings: read_urlencoded never reads anything from stdin. Zero. Zilch. Nada. There's nothing there. The key edits: ---- def read_urlencoded(self): """Internal: read data in query string format.""" qs = self.fp.read(self.length) qs=str(qs) sys.stderr.write (qs) sys.stderr.write ('=======') sys.stderr.write (str(self.length)) ...etc ---- ---- %% [Sat Mar 11 23:58:57 2000] POST /lists/admin/library/ HTTP/1.0 %% 500 /var/lib/mailman/cgi-bin/admin %request Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Encoding: gzip Accept-Language: en Connection: Keep-Alive Content-length: 40 Content-type: application/x-www-form-urlencoded Cookie: mud-dev:admin="(lp1\012S'216.148.243.2'\012p2\012aI952846157\012aI952856957\012aI-96722254\012a." Host: www.kanga.nu Referer: http://www.kanga.nu/lists/admin/library/ User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.13 i686; Nav) adminpw=xxxxx&request_login=Let+me+in... %response %stderr =======40 ---- According to that Apache is sending all the right data, it just ain't getting there. I've also upgraded libc6 recently (Debian system FWIW with packages libc6_2.1.3-[567]_i386.deb (notice regex range)). I downgraded libc6 to the package versions (5 and 6) that were installed when it did work to no effect. I also rebuilt the Mailman C based CGI programs under the installed version of libc6, and copied them over (in case something odd was going on) to no observed effect. Note: Plopping the cgi.py in as a standalone cgi tests out as working using GET methods (ie encode vars on the URL). I haven't built a framework yet to test POST for that module. I guess the next step is to either build that framework, or test-drive the C CGIs to make sure stdin really has the right bumph sitting there waiting. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From gorgo@caesar.elte.hu Sun Mar 12 14:24:06 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 12 Mar 2000 15:24:06 +0100 (MET) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <577.952849158@kanga.nu> Message-ID: On Sun, 12 Mar 2000, J C Lawrence wrote: > > Background data as this is also going to the Debian Mailman package > maintainer: > > Mailman's web interface suddenly stopped working for me. The > forms would display but I am unable authenticate not matter what > browser (Netscape 4.05 and 4.7, Lynx, W3M or Mozilla M14) I use. Hmm... unable to authenticate ? That means you get to the password screen each time you try to submit a form ? This usually happens if you don't access your admin interface on the Base url set for your list... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From claw@kanga.nu Sun Mar 12 16:54:07 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 08:54:07 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from Gergely Madarasz of "Sun, 12 Mar 2000 15:24:06 +0100." References: Message-ID: <13905.952880047@kanga.nu> On Sun, 12 Mar 2000 15:24:06 +0100 (MET) Gergely Madarasz wrote: > On Sun, 12 Mar 2000, J C Lawrence wrote: >> Background data as this is also going to the Debian Mailman >> package maintainer: >> >> Mailman's web interface suddenly stopped working for me. The >> forms would display but I am unable authenticate not matter what >> browser (Netscape 4.05 and 4.7, Lynx, W3M or Mozilla M14) I use. > Hmm... unable to authenticate ? That means you get to the password > screen each time you try to submit a form ? This usually happens > if you don't access your admin interface on the Base url set for > your list... Nope, that's not the problem (and I'm accessing on the Base Url to boot). The problem is that the Mailman CGIs are not getting the form submission data from Apache. Apache appears to be supplying it (ScriptLog says it is), but by the time the Python code runs its no longer there. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Sun Mar 12 17:50:13 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 09:50:13 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Sun, 12 Mar 2000 00:19:18 PST." <577.952849158@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> Message-ID: <21235.952883413@kanga.nu> On Sun, 12 Mar 2000 00:19:18 -0800 J C Lawrence wrote: > Findings: read_urlencoded never reads anything from stdin. Zero. > Zilch. Nada. There's nothing there. The key edits: ... > According to that Apache is sending all the right data, it just > ain't getting there. I've also upgraded libc6 recently (Debian > system FWIW with packages libc6_2.1.3-[567]_i386.deb (notice regex > range)). I downgraded libc6 to the package versions (5 and 6) > that were installed when it did work to no effect. I also rebuilt > the Mailman C based CGI programs under the installed version of > libc6, and copied them over (in case something odd was going on) > to no observed effect. I changed cgi-wrapper.c to read: #include #include "common.h" /* passed in by configure */ #define SCRIPTNAME SCRIPT #define LOG_IDENT "Mailman cgi-wrapper (" ## SCRIPT ## ")" /* GID that CGI scripts run as. See your Web server's documentation. */ #define LEGAL_PARENT_GID CGI_GID const char* logident = LOG_IDENT; char* script = SCRIPTNAME; const int parentgid = LEGAL_PARENT_GID; int main(int argc, char** argv, char** env) { int status; char* fake_argv[3]; char ac[31]; /* !!!!!!!!!!!edited!!!!!!!!!!!!! */ memset (ac, 0, 31); /* !!!!!!!!!!!edited!!!!!!!!!!!!! */ running_as_cgi = 1; if (getgid()>=100 && getgid()!=65534) check_caller(logident, parentgid)$ /* for these CGI programs, we can ignore argc and argv since they * don't contain anything useful. `script' will always be the driver * program and argv will always just contain the name of the real * script for the driver to import and execute (padded with two dummy * values in argv[0] and argv[1] that are ignored by run_script(). */ fake_argv[0] = NULL; fake_argv[1] = NULL; fake_argv[2] = script; fread (ac, 1, 30, stdin); /* !!!!!!!!!!!!edited!!!!!!!!!!!! */ fprintf (stderr, "---[%s]---",ac); /* !!!!!!!!!!!!edited!!!!!!!!!!!! */ status = run_script("driver", 3, fake_argv, env); fatal(logident, status, "%s", strerror(errno)); return status; } The ~mailman/cgi-bin/admin is not getting anything on stdin. Not good. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Mon Mar 13 02:56:09 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 18:56:09 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Sun, 12 Mar 2000 09:50:13 PST." <21235.952883413@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> Message-ID: <27855.952916169@kanga.nu> On Sun, 12 Mar 2000 09:50:13 -0800 J C Lawrence wrote: > The ~mailman/cgi-bin/admin is not getting anything on stdin. Not > good. Current findings: Installation of the PHP3 apache modules under Debian/potato kills POST methods for MailMan. I don't know why. Problem is, I need both. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Mon Mar 13 03:19:34 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Sun, 12 Mar 2000 22:19:34 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> Message-ID: <14540.24134.895512.923706@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> The ~mailman/cgi-bin/admin is not getting anything on stdin. JCL> Not good. But at least we know it's not Python, or Mailman on up. cgi-wrapper.c /could/ be doing something weird, but I don't see what that could be. You mentioned upgrading libc; maybe you need to rebuild Apache? -Barry From bwarsaw@cnri.reston.va.us Mon Mar 13 03:21:43 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Sun, 12 Mar 2000 22:21:43 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> <27855.952916169@kanga.nu> Message-ID: <14540.24263.343898.575179@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> Installation of the PHP3 apache modules under Debian/potato JCL> kills POST methods for MailMan. I don't know why. Problem JCL> is, I need both. What about other POSTs? If others work, then what's so weird about Mailman's C wrappers? -Barry From bwarsaw@cnri.reston.va.us Mon Mar 13 04:07:21 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Sun, 12 Mar 2000 23:07:21 -0500 (EST) Subject: [Mailman-Developers] a more uniform interface to private and public archives References: Message-ID: <14540.27001.603163.57782@anthem.cnri.reston.va.us> >>>>> "TP" == Todd Pfaff writes: TP> what i'd like to suggest is that we make the interface more TP> uniform by eliminating the 'Alias' path and access both TP> private and public archives via a single cgi-bin interface. TP> if the archive is private we require authentication, if not we TP> simply bypass the authentication. We specifically decided not to do this because we didn't want to take the performance hit for the more common situation of public archives. With the current arrangement, public archives are vended directly (and quickly) by the http server, while public archives are forced to go through the slower cgi for authentication purposes. -Barry From claw@kanga.nu Mon Mar 13 04:30:17 2000 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Mar 2000 20:30:17 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Sun, 12 Mar 2000 22:21:43 EST." <14540.24263.343898.575179@anthem.cnri.reston.va.us> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> <27855.952916169@kanga.nu> <14540.24263.343898.575179@anthem.cnri.reston.va.us> Message-ID: <10982.952921817@kanga.nu> On Sun, 12 Mar 2000 22:21:43 -0500 (EST) bwarsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Installation of the PHP3 apache modules under Debian/potato JCL> kills POST methods for MailMan. I don't know why. Problem is, JCL> I need both. > What about other POSTs? If others work, then what's so weird > about Mailman's C wrappers? I have no bloody idea. POSTS to PHP work just fine. POSTs to Perl CGIs work fine. Once I add the PHP3 module to Apache's config, POSTs to Mailman stop. Colour me confused. As soon as I get few other things resolved, I'm going to see what happens if I backlevel PHP, or even try PHP4... -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From claw@kanga.nu Mon Mar 13 08:54:44 2000 From: claw@kanga.nu (J C Lawrence) Date: Mon, 13 Mar 2000 00:54:44 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from J C Lawrence of "Sun, 12 Mar 2000 20:30:17 PST." <10982.952921817@kanga.nu> References: <14146.952632898@kanga.nu> <14536.4048.420476.522854@anthem.cnri.reston.va.us> <21848.952636266@kanga.nu> <577.952849158@kanga.nu> <21235.952883413@kanga.nu> <27855.952916169@kanga.nu> <14540.24263.343898.575179@anthem.cnri.reston.va.us> <10982.952921817@kanga.nu> Message-ID: <21677.952937684@kanga.nu> On Sun, 12 Mar 2000 20:30:17 -0800 J C Lawrence wrote: > I have no bloody idea. POSTS to PHP work just fine. POSTs to > Perl CGIs work fine. Once I add the PHP3 module to Apache's > config, POSTs to Mailman stop. > Colour me confused. > As soon as I get few other things resolved, I'm going to see what > happens if I backlevel PHP, or even try PHP4... I've identified the exact setup that causes the behaviour under Debian/potato: If I install the following .debs for PHP everything works fine: php3-gd_3%3a3.0.15-1_i386.deb php3_3%3a3.0.15-1_i386.deb php3-mysql_3%3a3.0.15-1_i386.deb If however I install the current Debian/potato set: php3_3%3a3.0.15-1.2_i386.deb php3-gd_3%3a3.0.15-1.2_i386.deb php3-mysql_3%3a3.0.15-1.2_i386.deb with the same Apache configs in both cases (a LoadModule line and two AddTypes as per the default http.conf and srm.conf), or I install the prior the prior 2.0.15-1.1 package set, HTTP POSTs to MailMan CGIs no longer happen due to the fact that nothing reaches the stdin of the CGIs. It doesn't seem to matter whether I'm running: apache_1.3.9-12_i386.deb apache-common_1.3.9-12_i386.deb or: apache_1.3.9-11_i386.deb apache-common_1.3.9-11_i386.deb or the various libc6 packages in that date range. What I havem't tried, and what I'm going to leave up to Gergely Madarasz (CC'ed on this message) the Debian package maintainer for both the PHP3 and MailMan packages, is finding out if rebuilding everything with a current (or even the same) glibc version makes the problem go away (it hopefully being reproducable at his end). I'm willing to supply copies of my config files if there's interest. I'm going to bed. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From gorgo@caesar.elte.hu Mon Mar 13 13:49:53 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 13 Mar 2000 14:49:53 +0100 (MET) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <21677.952937684@kanga.nu> Message-ID: On Mon, 13 Mar 2000, J C Lawrence wrote: > On Sun, 12 Mar 2000 20:30:17 -0800 > J C Lawrence wrote: > > > I have no bloody idea. POSTS to PHP work just fine. POSTs to > > Perl CGIs work fine. Once I add the PHP3 module to Apache's > > config, POSTs to Mailman stop. > > > Colour me confused. > > > As soon as I get few other things resolved, I'm going to see what > > happens if I backlevel PHP, or even try PHP4... > > I've identified the exact setup that causes the behaviour under > Debian/potato: > > If I install the following .debs for PHP everything works fine: > > php3-gd_3%3a3.0.15-1_i386.deb > php3_3%3a3.0.15-1_i386.deb > php3-mysql_3%3a3.0.15-1_i386.deb > > If however I install the current Debian/potato set: > > php3_3%3a3.0.15-1.2_i386.deb > php3-gd_3%3a3.0.15-1.2_i386.deb > php3-mysql_3%3a3.0.15-1.2_i386.deb Please try the 3:3.0.15-2 packages. The 1.2 package set was an NMU, and had some other problems too, probably due to an incomplete or broken build environment. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From bwarsaw@cnri.reston.va.us Mon Mar 13 16:34:30 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Mon, 13 Mar 2000 11:34:30 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <21677.952937684@kanga.nu> Message-ID: <14541.6294.787522.466891@anthem.cnri.reston.va.us> Could one of you possibly send me a blurb summarizing the recommendation for README.LINUX? Thanks. -Barry From bwarsaw@cnri.reston.va.us Mon Mar 13 19:53:33 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 13 Mar 2000 14:53:33 -0500 (EST) Subject: [Mailman-Developers] Re: Bogus directory References: <38BFC2F9.9B98ABE1@linux.org.uy> <20000307182354.A9325@mail.dskk.co.jp> Message-ID: <14541.18237.18165.497054@anthem.cnri.reston.va.us> >>>>> "JT" == Jim Tittsler writes: JT> The "bogus archive directory" issue seems to come up fairly JT> often. Perhaps it would be worthwhile to add a check to JT> cron/nightly_gzip to find out if it is simply a matter of JT> there not yet being any articles to archive. I like this, so I'll check this in. Thanks. -Barry From Gergely Madarasz Tue Mar 14 15:49:49 2000 From: Gergely Madarasz (Gergely Madarasz) Date: Tue, 14 Mar 2000 16:49:49 +0100 (MET) Subject: [Mailman-Developers] Failed authentication In-Reply-To: <14541.6294.787522.466891@anthem.cnri.reston.va.us> Message-ID: On Mon, 13 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > Could one of you possibly send me a blurb summarizing the > recommendation for README.LINUX? If you refer to these php3 + mailman problems, nothing should be summarized... it was just one set of broken php3 packages in a development version of debian which have already been replaced. And I hope the new packages work... :) -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From bwarsaw@cnri.reston.va.us Tue Mar 14 16:13:52 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Tue, 14 Mar 2000 11:13:52 -0500 (EST) Subject: [Mailman-Developers] Failed authentication References: <14541.6294.787522.466891@anthem.cnri.reston.va.us> Message-ID: <14542.25920.587939.9162@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: >> Could one of you possibly send me a blurb summarizing the >> recommendation for README.LINUX? GM> If you refer to these php3 + mailman problems, nothing should GM> be summarized... it was just one set of broken php3 packages GM> in a development version of debian which have already been GM> replaced. And I hope the new packages work... :) I always like solutions where I don't have to do anything :) Thanks, -Barry From hauserma@site-eerie.ema.fr Wed Mar 15 14:03:20 2000 From: hauserma@site-eerie.ema.fr (Hausermann Laurent) Date: Wed, 15 Mar 2000 15:03:20 +0100 Subject: [Mailman-Developers] French Templates. Message-ID: <38CF9828.4B4B2658@site-eerie.ema.fr> Hi, I currently finalizing a communuty web server (for a former student association) in French, and I cannot find any ressources about French Templates for mailman 1.1. Do you now about any translation project ? Thanks a lot Laurent Hausermann From claw@kanga.nu Wed Mar 15 16:39:09 2000 From: claw@kanga.nu (J C Lawrence) Date: Wed, 15 Mar 2000 08:39:09 -0800 Subject: [Mailman-Developers] File handle shortages Message-ID: <19585.953138349@kanga.nu> I'm now getting this, with no other changes in the system, when approving messages held for moderation. Same kernel, same file handle limits as before...: IOError writing outgoing queue exceptions.IOError/[Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10890.13' Traceback (innermost last): File "/var/lib/mailman/scripts/contact_transport", line 58, in ? File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 155, in enqueueMessage File "/usr/lib/mailman/Mailman/Utils.py", line 829, in open_ex File "/usr/lib/mailman/Mailman/Utils.py", line 824, in open_ex IOError: [Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10890.13' IOError writing outgoing queue exceptions.IOError/[Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10918.9' Traceback (innermost last): File "/var/lib/mailman/scripts/contact_transport", line 58, in ? File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 155, in enqueueMessage File "/usr/lib/mailman/Mailman/Utils.py", line 829, in open_ex File "/usr/lib/mailman/Mailman/Utils.py", line 824, in open_ex IOError: [Errno 23] Too many open files in system: '/var/lib/mailman/data/mm_q.10918.9' Content-type: text/html ... Traceback (innermost last): File "/var/lib/mailman/scripts/driver", line 112, in run_main File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 112, in main File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 200, in HandleRequests File "/usr/lib/mailman/Mailman/ListAdmin.py", line 122, in HandleRequest File "/usr/lib/mailman/Mailman/ListAdmin.py", line 131, in HandlePostRequest File "/usr/lib/mailman/Mailman/MailList.py", line 1329, in Post File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 206, in ArchiveMail File "/usr/lib/mailman/Mailman/LockFile.py", line 200, in lock File "/usr/lib/mailman/Mailman/LockFile.py", line 156, in __read IOError: [Errno 23] Too many open files in system: '/var/lib/mailman/locks/mud-dev.archiver.lock.bush.10877' The mail (at least) does seem to get thru. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From ricardo@rixhq.nu Wed Mar 15 19:40:48 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 15 Mar 2000 20:40:48 +0100 Subject: [Mailman-Developers] cookies Message-ID: <20000315204048.B1040@miss-janet.com> Hi, this was just suggested to me by somebody from mailman-users: > Please write a patch which puts the string "Cookie could not be set" on the > web page so that I can see that pressing submit will not work :-) i think thats a good point... it would safe some user questions if MM tells exactly why the authorisation failed. I'm not sure if this subject has been touched already, but what allowing admins to choose between cookies and Basic-Authorization... it should be possible to use Basic-auth, right? Ricardo. -- From granveau@worldnet.fr Thu Mar 16 00:23:49 2000 From: granveau@worldnet.fr (Boris Granveaud) Date: Thu, 16 Mar 2000 01:23:49 +0100 Subject: [Mailman-Developers] Pb with URL sent to modify your options Message-ID: <38D02995.4701E061@worldnet.fr> Hi, I noticed a problem with the URL that is sent with the introduction mail (when you have just subscribed to a list). The URL is like this: http://www.python.org/mailman/options/mailman-developers/granveau@worldnet.fr If you receive with Hotmail and you are using Internet Explorer, the URL doesn't work. The browser tries to open http://www.python.org/mailman/options/mailman-developers/ I think that if you replace granveau@worldnet.fr with granveau__at__worldnet.fr, it would work. Can anybody confirm this and provide a patch? Thank you, Boris. From port22@rnhnet.com Thu Mar 16 19:50:14 2000 From: port22@rnhnet.com (port22@rnhnet.com) Date: Thu, 16 Mar 2000 11:50:14 -0800 Subject: [Mailman-Developers] PC / Internet fax solution Message-ID: <3.0.6.32.20000316115014.009929f0> I stopped by your web site and thought you may be interested in our PC/internet based fax service. You can send 1 to 1,000,000 faxes in just minutes to any destination in the US, Canada, and Europe for as low as 7.4 cents per minute. Our user-friendly submission software lets you queue your job on our server within minutes. Why not try the system for FREE. We will be happy to send 100 Faxes on your behalf to your fax list immediately. Simply go to http://www.efaxcast.com/submit.htm From claw@cp.net Thu Mar 16 22:38:12 2000 From: claw@cp.net (J C Lawrence) Date: Thu, 16 Mar 2000 14:38:12 -0800 Subject: [Mailman-Developers] French Templates. In-Reply-To: Message from Hausermann Laurent of "Wed, 15 Mar 2000 15:03:20 +0100." <38CF9828.4B4B2658@site-eerie.ema.fr> References: <38CF9828.4B4B2658@site-eerie.ema.fr> Message-ID: I'm now getting lock failures upon approving messages held for moderation: Traceback (innermost last): File "/var/lib/mailman/scripts/driver", line 112, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 112, in main HandleRequests(doc) File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 200, in HandleRequests list.HandleRequest(request, v, form[comment_key].value) File "/usr/lib/mailman/Mailman/ListAdmin.py", line 122, in HandleRequest self.HandlePostRequest(request_data[2:], value, comment) File "/usr/lib/mailman/Mailman/ListAdmin.py", line 131, in HandlePostRequest self.Post(msg, 1) File "/usr/lib/mailman/Mailman/MailList.py", line 1329, in Post self.ArchiveMail(msg) File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 206, in ArchiveMail lock.lock() File "/usr/lib/mailman/Mailman/LockFile.py", line 245, in lock os.unlink(self.__tmpfname) OSError: [Errno 2] No such file or directory: '/var/lib/mailman/locks/mud-dev.archiver.lock.bush.16685' check_perms reports clean, Apache (v1.1-4) runs as user www-data.www-data (Debain defaults), but the Mailman user is list.list. $ pwd /var/lib/mailman/locks $ ls -lasp total 36 4 drwxrwsr-x 2 root list 4096 Mar 16 14:35 ./ 4 drwxrwsr-x 6 root list 4096 Mar 12 21:46 ../ 4 -rw-rw-r-- 1 root list 69 Mar 16 09:48 .lock 4 -rw-rw-r-- 1 list list 74 Mar 16 14:12 mmqueue_run.lock 4 -rw-rw-r-- 2 www-data list 79 Mar 16 14:31 mud-dev.archiver.lock 4 -rw-rw-r-- 1 www-data list 79 Mar 16 14:31 mud-dev.archiver.lock.bush.24449 4 -rw-rw-r-- 2 www-data list 79 Mar 16 14:31 mud-dev.archiver.lock.bush.24499 4 -rw-rw-r-- 1 list list 70 Mar 16 14:35 mud-dev.lock This looks fishy to me. Blowing away the contents of the directory doesn't fix the problem. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@cp.net Fri Mar 17 01:15:29 2000 From: claw@cp.net (J C Lawrence) Date: Thu, 16 Mar 2000 17:15:29 -0800 Subject: [Mailman-Developers] Failed authentication In-Reply-To: Message from Gergely Madarasz of "Mon, 13 Mar 2000 23:08:38 +0100." References: Message-ID: On Mon, 13 Mar 2000 23:08:38 +0100 (MET) Gergely Madarasz wrote: > On Mon, 13 Mar 2000 coder@kanga.nu wrote: >> On Mon, 13 Mar 2000 14:49:53 +0100 (MET) Gergely Madarasz >> wrote: >>> Please try the 3:3.0.15-2 packages. The 1.2 package set was an >>> NMU, and had some other problems too, probably due to an >>> incomplete or broken build environment. >> >> Got a set of those for Potato as versus Woody? Potato doesn't >> seem to have anything more recent than -1.2 (and I'm not about to >> roll a production box up to Woody just yet). > Potato should have -2, the packages were installed on master at > 8:41 GMT, some mirrors might be still out of date though... Okay, I just upgraded to the -2 packages, restarted Apache, and everything was heppy. The -1.1 and -1.2 packages are broken. -- J C Lawrence Internet: claw@kanga.nu ----------(*) Internet: coder@kanga.nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From bwarsaw@cnri.reston.va.us Tue Mar 21 05:58:21 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 00:58:21 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon Message-ID: <14551.3965.171599.618432@anthem.cnri.reston.va.us> Folks, Okay, I think I solved the last major hurdle before I can start releasing the new betas. Mailman should now lazily update it's old pending requests "database" to the new style external requests.db file. Wasn't as hard as I thought it would be. You will still have to be careful when upgrading from 1.1/1.0 to the new version. Please read/debug my recommendations in the UPGRADING file for details (after I check it in). While I'm pretty sure upgrading will work, I really need feedback from you beta testers. For now, I'd say you should be careful upgrading any operational site, but on the other hand I want to encourage you to test this stuff as much as possible. All feedback is welcome. Now, my questions. 1) Notice I haven't said "upgrade to 1.2" because I'm going to call the new release 2.0. While there aren't that many outwardly visible differences, there are enough architectural and schema changes, that I believe a 2.0 label is warranted. Plus, I want to give a stronger indication that the changes may be, er, significant. This means that if I really screw up 2.0, I can get a few 2.x bug patches out in quick succession. This also means that the i18n'd Mailman will likely be called 3.0. What's in a number anyway? :) 1) I've thought about being really parental about the upgrade, by essentially forcing people to read the UPGRADING file before "make" will succeed. I think I have a trick that will work, but I'm not sure it's a good idea. On the one hand it /might/ (only might) save lazy or novice upgraders some headaches by forcing them to read the manual first. One the other hand, it'll be really annoying either to those who are doing a fresh install, or who are upgrading but know what they're doing. So, do you think it would be a good idea to force everyone to read UPGRADING before "make" succeeds? Watch for the final round of checkins some time (hopefully) this week. After that I'll spin the 2.0beta1 tarball. I'm pretty sure the current CVS snapshot is very close, modulo updating the docs. I still need to get through the email backlog (sigh) and the Jitterbug database, but I can do that while the betas are out on the street. Cheers, -Barry From jwt@dskk.co.jp Tue Mar 21 06:22:44 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Tue, 21 Mar 2000 15:22:44 +0900 Subject: [Mailman-Developers] ToUsenet should use the new nntplib, modereader Message-ID: <20000321152244.A30221@mail.dskk.co.jp> --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Barry, Posting also requires the server to be in 'mode reader' (at least our INN does). I think you only updated the cron/gatenews... Jim -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ToUsenet.diff" --- Mailman/Handlers/ToUsenet.py.orig Mon Feb 14 15:12:39 2000 +++ Mailman/Handlers/ToUsenet.py Tue Mar 21 15:15:57 2000 @@ -23,6 +23,10 @@ from Mailman.pythonlib.StringIO import StringIO +# The version we have is from Python 1.5.2+ and fixes the "mode reader" +# problem. +from Mailman.pythonlib import nntplib + def process(mlist, msg): @@ -123,7 +127,7 @@ # flatten the message object, stick it in a StringIO object and post # that resulting thing to the newsgroup fp = StringIO(str(msg)) - conn = nntplib.NNTP(mlist.nntp_host) + conn = nntplib.NNTP(mlist.nntp_host, readermode=1) try: try: conn.post(fp) --yrj/dFKFPuw6o+aM-- From ricardo@rixhq.nu Tue Mar 21 06:32:02 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Tue, 21 Mar 2000 07:32:02 +0100 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.3965.171599.618432@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 12:58:21AM -0500 References: <14551.3965.171599.618432@anthem.cnri.reston.va.us> Message-ID: <20000321073202.A32359@miss-janet.com> Hi, On Tue, Mar 21, 2000 at 12:58:21AM -0500, Barry A. Warsaw wrote: > releasing the new betas. Mailman should now lazily update it's old > pending requests "database" to the new style external requests.db > file. Wasn't as hard as I thought it would be. ah great :) > While I'm pretty sure upgrading will work, I really need feedback from > you beta testers. For now, I'd say you should be careful upgrading > any operational site, but on the other hand I want to encourage you to > test this stuff as much as possible. All feedback is welcome. I'm using the CVS version already in production so I won't have trouble switching to the beta... > 1) I've thought about being really parental about the upgrade, by > essentially forcing people to read the UPGRADING file before "make" > will succeed. I think I have a trick that will work, but I'm not > sure it's a good idea. On the one hand it /might/ (only might) > save lazy or novice upgraders some headaches by forcing them to > read the manual first. > they're doing. So, do you think it would be a good idea to force > everyone to read UPGRADING before "make" succeeds? I've seen software packages solving this by needing to enter a "magic" key with the make command before being able to do the install... and the key could be found in the install docs... You could also specifically ask the user if he/she read the UPGRADING file with a y/n prompt before proceeding with the actual install. Also, what about including a backup procedure with the install, so you can revert the install with 'make install restore-original'...? BUT all this seems a lot of work, just for being helpful to lazy people who take the risk of not reading the upgrade docs :) I think a y/n prompt could be enough... if the user then decides to ignore the BIG FLASHY WARNING TO READ THE UPGRADING FILE then so be it... > Watch for the final round of checkins some time (hopefully) this week. could you let us know on this list when this has been done? then I can do a CVS update of my version... and then see how much of my own hacks i have to put back in. I'm looking forward to bug squatting the betas... :) Thanks for doing a great job, Barry! Ricardo. -- From bwarsaw@cnri.reston.va.us Tue Mar 21 06:55:23 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Tue, 21 Mar 2000 01:55:23 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: <14551.3965.171599.618432@anthem.cnri.reston.va.us> <20000321073202.A32359@miss-janet.com> Message-ID: <14551.7387.973331.640425@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> I'm using the CVS version already in production so I won't RK> have trouble switching to the beta... You too? Me too! :) RK> I've seen software packages solving this by needing to enter a RK> "magic" key with the make command before being able to do the RK> install... and the key could be found in the install docs... RK> You could also specifically ask the user if he/she read the RK> UPGRADING file with a y/n prompt before proceeding with the RK> actual install. Also, what about including a backup procedure RK> with the install, so you can revert the install with 'make RK> install restore-original'...? BUT all this seems a lot of RK> work, just for being helpful to lazy people who take the risk RK> of not reading the upgrade docs :) I think a y/n prompt could RK> be enough... if the user then decides to ignore the BIG FLASHY RK> WARNING TO READ THE UPGRADING FILE then so be it... I was thinking about playing games with make dependencies, but ya, it seems like a lot of boring work :) Hmm, I'll see how motivated I get before the 2.0 final. Me> Watch for the final round of checkins some time (hopefully) Me> this week. RK> could you let us know on this list when this has been done? RK> then I can do a CVS update of my version... and then see how RK> much of my own hacks i have to put back in. You're lucky I'm feeling insomniatic tonight. I've finished the checkins and will spin the tarball from the current CVS snapshot when I get a bit of free time. RK> I'm looking forward to bug squatting the betas... :) Me too (I think :) RK> Thanks for doing a great job, Barry! You're very welcome! -Barry From elau@ics.uci.edu Tue Mar 21 08:55:30 2000 From: elau@ics.uci.edu (Edmund Lau) Date: Tue, 21 Mar 2000 00:55:30 -0800 (PST) Subject: [Mailman-Developers] Betas coming soon Message-ID: Well, I just read the Emails on the new beta version. I hate to ask it, but was there a timetable on when we might expect it to be fully released? Just wondering cuz I just sent an Email out to my users that I'm installing 1.1 tomorrow and I'm not sure if I should just wait for 2.0. Will the upgrade path be difficult? No pressure whatsoever! ;) -Ed From bwarsaw@cnri.reston.va.us Tue Mar 21 14:15:54 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 09:15:54 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: Message-ID: <14551.33818.104514.373646@anthem.cnri.reston.va.us> >>>>> "EL" == Edmund Lau writes: EL> Well, I just read the Emails on the new beta version. I hate EL> to ask it, but was there a timetable on when we might expect EL> it to be fully released? Just wondering cuz I just sent an EL> Email out to my users that I'm installing 1.1 tomorrow and I'm EL> not sure if I should just wait for 2.0. Will the upgrade path EL> be difficult? Sorry, I can't give a time frame for 2.0 final, but I don't suspect the beta cycle will be longer than a couple of weeks at most. There are already several of us using the current snapshot in production environments. As for upgrading from 1.1 to 2.0, I think it will be fairly straightforward, but that's one of the things I'd really like the mm-devers to exercise. My biggest concern is what happens to messages in Mailman 1.1's mail queue. You really need to have this cleared out before you upgrade. I should mention that on python.org, I didn't do an overlaying upgrade because I started using the new code base before I had all the proper update code in place. You can always create a new installation in a different directory, but moving lists from one directory to another, while possible, is time-consuming and a pain. EL> No pressure whatsoever! ;) Sure, sure, that's what they /all/ say! :) -Barry From jarrell@vt.edu Tue Mar 21 19:08:16 2000 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 21 Mar 2000 14:08:16 -0500 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.33818.104514.373646@anthem.cnri.reston.va.us> References: Message-ID: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> --=====================_67063723==_.ALT Content-Type: text/plain; charset="us-ascii" Upgraded my test machine, which was running a month or two ago cvs snapshot, and so far things are ok. Except for gateing *to* a list, but someone already caught that. If things look ok, I'll put it on my production server later in the week or early next. Note that the images aren't in the cvs repository yet. (Is the python image really a PNG? Yuck.) --=====================_67063723==_.ALT Content-Type: text/html; charset="us-ascii" Upgraded my test machine, which was running a month or two ago cvs snapshot, and
so far things are ok.  Except for gateing *to* a list, but someone already caught that.

If things look ok, I'll put it on my production server later in the week or early next.

Note that the images aren't in the cvs repository yet.  (Is the python image really
a PNG?  Yuck.)
 --=====================_67063723==_.ALT-- From bwarsaw@cnri.reston.va.us Tue Mar 21 19:22:22 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Tue, 21 Mar 2000 14:22:22 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> Message-ID: <14551.52206.999641.515081@anthem.cnri.reston.va.us> >>>>> "RJ" == Ron Jarrell writes: RJ> Upgraded my test machine, which was running a month or two ago RJ> cvs snapshot, and so far things are ok. Except for gateing RJ> *to* a list, but someone already caught that. Right. That change should have been checked in by now, so doing a cvs update should get you the fix to Mailman/Handlers/ToUsenet.py RJ> If things look ok, I'll put it on my production server later RJ> in the week or early next. Cool. RJ> Note that the images aren't in the cvs repository yet. The should be! Take a look at http://cvs.python.org/cgi-bin/viewcvs.cgi/mailman/misc/ and you should find PythonPowered.png, gnu-head-tiny.jpg, and mailman.jpg which are the three logos. RJ> (Is the python image really a PNG? Yuck.) Why yuck? My dilemma was this: PythonPowered.gif is purposefully transparent around the edges of the oval, but we can't use gifs because Mailman is Gnu. I'd have preferred jpegs for consistency, but I couldn't figure out how to make the transparency work (I don't think jpeg supports transparencies). png seemed the only compromise, and converting from gif to png was made easy by Eric Raymond's tool. The downsides I see are support for png in browsers. NS 4.7 and MSIE 5.x both support pngs, but only MSIE supports transparent pngs (so if you change your background to other than white, it won't look nice). I'm open to suggestions, but this seems to me to be the best compromise as long as gifs are verboten. -Barry From ricardo@rixhq.nu Tue Mar 21 20:06:35 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Tue, 21 Mar 2000 21:06:35 +0100 Subject: [Mailman-Developers] beta & smtp Message-ID: <20000321210635.B2014@miss-janet.com> I just upgraded the cvs version i had installed (which is a snapshot from almost a month ago i think) and when i tried to approve 11 posts, I got a mailman error... something about a connection refused (see below)... maybe mailman is trying more connections than postfix allows... but the weird thing is that i never had this problem before, so this has to do with some recent stmp changes. I'll investigate postfix & mailman further to see if i can figure out what exactly is going wrong... Ricardo. admin(32515): mlist.HandleRequest(request_id, v, comment) admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 124, in HandleRequest admin(32515): self.__handlepost(data, value, comment) admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 174, in __handlepost admin(32515): self.Post(msg) admin(32515): File "/usr/local/mailman/Mailman/MailList.py", line 1293, in Post admin(32515): Mailman.Handlers.HandlerAPI.DeliverToList(self, msg) admin(32515): File "/usr/local/mailman/Mailman/Handlers/HandlerAPI.py", line 55, in DeliverToList admin(32515): func(mlist, msg) admin(32515): File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 41, in process admin(32515): conn = smtplib.SMTP(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 182, in __init__ admin(32515): (code, msg) = self.connect(host, port) admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 216, in connect admin(32515): self.sock.connect(host, port) admin(32515): error: (111, 'Connection refused') -- Ricardo. -- From ricardo@rixhq.nu Tue Mar 21 20:34:14 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Tue, 21 Mar 2000 21:34:14 +0100 Subject: [Mailman-Developers] beta & smtp In-Reply-To: <20000321210635.B2014@miss-janet.com>; from ricardo@rixhq.nu on Tue, Mar 21, 2000 at 09:06:35PM +0100 References: <20000321210635.B2014@miss-janet.com> Message-ID: <20000321213414.C2014@miss-janet.com> On Tue, Mar 21, 2000 at 09:06:35PM +0100, Ricardo Kustner wrote: > refused (see below)... maybe mailman is trying more connections > than postfix allows... well i fixed it... it turned out that the default SMTPHOST was set to 'miss-janet.com' in Defaults.py ... I changed this to 'localhost' (in mm_cfg.py) and now it works again... I wonder why it was set to miss-janet.com though... (I'm not sure if it was there already or was changed during the upgrade) It seems like the choice of delivery method has been implemented as was discussed earlier on this list... where can i find some more info anywhere on what the choices are? Ricardo. > admin(32515): mlist.HandleRequest(request_id, v, comment) > admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 124, in HandleRequest > admin(32515): self.__handlepost(data, value, comment) > admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 174, in __handlepost > admin(32515): self.Post(msg) > admin(32515): File "/usr/local/mailman/Mailman/MailList.py", line 1293, in Post > admin(32515): Mailman.Handlers.HandlerAPI.DeliverToList(self, msg) > admin(32515): File "/usr/local/mailman/Mailman/Handlers/HandlerAPI.py", line 55, in DeliverToList > admin(32515): func(mlist, msg) > admin(32515): File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 41, in process > admin(32515): conn = smtplib.SMTP(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) > admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 182, in __init__ > admin(32515): (code, msg) = self.connect(host, port) > admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 216, in connect > admin(32515): self.sock.connect(host, port) > admin(32515): error: (111, 'Connection refused') > > > -- > Ricardo. > > -- > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > -- Ricardo. -- International Janet Jackson fanclub called MISS JANET. For more information write to: Miss Janet. P.O.Box 10016, 1001 EA Amsterdam, The Netherlands Fax/phone: +31-(0)20-7764493 Email: fanclub@miss-janet.com Or check out our website: http://miss-janet.com From Benjamin B. Thomas" References: <20000321060210.689621CE3B@dinsdale.python.org> Message-ID: <200003212233.QAA31287@mail.indiansprings.org> I noticed a typo in the NEWS file during the lastest round of cvs commits: Cheers, benjy Index: NEWS =================================================================== RCS file: /projects/cvsroot/mailman/NEWS,v retrieving revision 1.14 diff -C2 -r1.14 NEWS *** NEWS 2000/03/21 06:04:14 1.14 --- NEWS 2000/03/21 21:54:55 *************** *** 30,34 **** this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the ! Mailman host. In practice, mail lossage has not be observed. For this reason cron/run_queue is no longer needed (see the --- 30,34 ---- this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the ! Mailman host. In practice, mail lossage has not been observed. For this reason cron/run_queue is no longer needed (see the From bwarsaw@cnri.reston.va.us Tue Mar 21 23:55:32 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 18:55:32 -0500 (EST) Subject: [Mailman-Developers] beta & smtp References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> Message-ID: <14552.3060.228549.718496@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> well i fixed it... it turned out that the default SMTPHOST was RK> set to 'miss-janet.com' in Defaults.py ... I changed this to RK> 'localhost' (in mm_cfg.py) and now it works again... I wonder RK> why it was set to miss-janet.com though... (I'm not sure if it RK> was there already or was changed during the upgrade) This was likely a result of the upgrade. I set SMTPHOST to the fqdn of the host that you're on. However, if your machine's primary alias was www.miss-janet.com, the SMTPHOST got the "www." stripped off. I'll bet that's what we're seeing here. There's a different configure variable that SMTPHOST should have gotten set to, called `URL'. These two conf variables are really mis-named because URL, in your case, would be www.miss-janet.com. The reason these are different is because in the first case, I'm trying to guess your domain for email purposes (e.g. ricardo@miss-janet.com), but in the second I'm trying to guess the host part of your url (e.g. www.miss-janet.com). For a machine named www.whatever, these will differ, but for a staging machine, it's probably called something like mydevhost.miss-janet.com. In that case, I want both the email part and the url part to be the entire host name. Yes this is all crufty and broken, and probably only useful for a small number of installations that use staging servers. I think I have a not-so-drastic fix though that I'd like you to try. See the patch below. BTW, I remember having some problems when using Postfix and just setting SMTPHOST to 'localhost', but I can't remember the details right now. RK> It seems like the choice of delivery method has been RK> implemented as was discussed earlier on this list... where can RK> i find some more info anywhere on what the choices are? There's currently only two, as described in Mailman/Defaults.py. Search for the variable DELIVERY_MODULE; there's an explanation and the alternative value in a comment. Let me know if this needs more explaining or documenting. -Barry -------------------- snip snip -------------------- Index: Defaults.py.in =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Defaults.py.in,v retrieving revision 1.97 diff -c -r1.97 Defaults.py.in *** Defaults.py.in 2000/03/21 06:24:58 1.97 --- Defaults.py.in 2000/03/21 23:16:09 *************** *** 115,121 **** SENDMAIL_CMD = '/usr/lib/sendmail' # SMTP host and port, when DELIVERY_MODULE is 'SMTPDirect' ! SMTPHOST = '@FQDN@' SMTPPORT = 0 # default from smtplib # 1 to use crypt for passwords instead of md5. --- 115,121 ---- SENDMAIL_CMD = '/usr/lib/sendmail' # SMTP host and port, when DELIVERY_MODULE is 'SMTPDirect' ! SMTPHOST = '@URL@' SMTPPORT = 0 # default from smtplib # 1 to use crypt for passwords instead of md5. Index: configure.in =================================================================== RCS file: /projects/cvsroot/mailman/configure.in,v retrieving revision 1.43 diff -c -r1.43 configure.in *** configure.in 2000/03/21 06:24:52 1.43 --- configure.in 2000/03/21 23:41:45 *************** *** 331,336 **** --- 331,338 ---- www = h elif not fqdn: fqdn = h + if www and fqdn: + break fp = open('conftest.out', 'w') if not www and fqdn: fp.write('%s\n%s\n' % (fqdn, fqdn)) Index: configure =================================================================== RCS file: /projects/cvsroot/mailman/configure,v retrieving revision 1.41 diff -c -r1.41 configure *** configure 2000/03/21 06:24:52 1.41 --- configure 2000/03/21 23:41:52 *************** *** 1,6 **** #! /bin/sh ! # From configure.in Revision: 1.42 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 --- 1,6 ---- #! /bin/sh ! # From configure.in Revision: 1.43 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 *************** *** 1366,1371 **** --- 1366,1373 ---- www = h elif not fqdn: fqdn = h + if www and fqdn: + break fp = open('conftest.out', 'w') if not www and fqdn: fp.write('%s\n%s\n' % (fqdn, fqdn)) *************** *** 1379,1392 **** $PYTHON conftest.py echo $ac_n "checking for default fully qualified host name""... $ac_c" 1>&6 ! echo "configure:1383: checking for default fully qualified host name" >&5 if test -z "$FQDN" then FQDN=`head -1 conftest.out` fi echo "$ac_t""$FQDN" 1>&6 echo $ac_n "checking for default URL host component""... $ac_c" 1>&6 ! echo "configure:1390: checking for default URL host component" >&5 if test -z "$URL" then URL=`tail -1 conftest.out` --- 1381,1394 ---- $PYTHON conftest.py echo $ac_n "checking for default fully qualified host name""... $ac_c" 1>&6 ! echo "configure:1385: checking for default fully qualified host name" >&5 if test -z "$FQDN" then FQDN=`head -1 conftest.out` fi echo "$ac_t""$FQDN" 1>&6 echo $ac_n "checking for default URL host component""... $ac_c" 1>&6 ! echo "configure:1392: checking for default URL host component" >&5 if test -z "$URL" then URL=`tail -1 conftest.out` *************** *** 1398,1409 **** for ac_func in strerror setregid syslog do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:1402: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:1404: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 1428,1434 ---- ; return 0; } EOF ! if { (eval echo configure:1432: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else *************** *** 1457,1473 **** # with the appropriate include. for lib in bsd socket inet; do echo $ac_n "checking for syslog in -l$lib""... $ac_c" 1>&6 ! echo "configure:1461: checking for syslog in -l$lib" >&5 Mailman_LIBS_save="$LIBS"; LIBS="$LIBS -l$lib" cat > conftest.$ac_ext < int main() { syslog(LOG_DEBUG, "Just a test..."); ; return 0; } EOF ! if { (eval echo configure:1471: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* echo "$ac_t""yes" 1>&6 cat >> confdefs.h <<\EOF --- 1459,1475 ---- # with the appropriate include. for lib in bsd socket inet; do echo $ac_n "checking for syslog in -l$lib""... $ac_c" 1>&6 ! echo "configure:1463: checking for syslog in -l$lib" >&5 Mailman_LIBS_save="$LIBS"; LIBS="$LIBS -l$lib" cat > conftest.$ac_ext < int main() { syslog(LOG_DEBUG, "Just a test..."); ; return 0; } EOF ! if { (eval echo configure:1473: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* echo "$ac_t""yes" 1>&6 cat >> confdefs.h <<\EOF *************** *** 1489,1495 **** # Checks for header files. echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 ! echo "configure:1493: checking how to run the C preprocessor" >&5 # On Suns, sometimes $CPP names a directory. if test -n "$CPP" && test -d "$CPP"; then CPP= --- 1491,1497 ---- # Checks for header files. echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 ! echo "configure:1495: checking how to run the C preprocessor" >&5 # On Suns, sometimes $CPP names a directory. if test -n "$CPP" && test -d "$CPP"; then CPP= *************** *** 1504,1516 **** # On the NeXT, cc -E runs the code through the compiler's parser, # not just through cpp. cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1514: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 1506,1518 ---- # On the NeXT, cc -E runs the code through the compiler's parser, # not just through cpp. cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1516: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** *** 1521,1533 **** rm -rf conftest* CPP="${CC-cc} -E -traditional-cpp" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1531: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 1523,1535 ---- rm -rf conftest* CPP="${CC-cc} -E -traditional-cpp" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1533: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** *** 1538,1550 **** rm -rf conftest* CPP="${CC-cc} -nologo -E" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1548: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 1540,1552 ---- rm -rf conftest* CPP="${CC-cc} -nologo -E" cat > conftest.$ac_ext < Syntax Error EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1550: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** *** 1569,1580 **** echo "$ac_t""$CPP" 1>&6 echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 ! echo "configure:1573: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include --- 1571,1582 ---- echo "$ac_t""$CPP" 1>&6 echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 ! echo "configure:1575: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include *************** *** 1582,1588 **** #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1586: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 1584,1590 ---- #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1588: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** *** 1599,1605 **** if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF --- 1601,1607 ---- if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF *************** *** 1617,1623 **** if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF --- 1619,1625 ---- if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF *************** *** 1638,1644 **** : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') --- 1640,1646 ---- : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') *************** *** 1649,1655 **** exit (0); } EOF ! if { (eval echo configure:1653: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else --- 1651,1657 ---- exit (0); } EOF ! if { (eval echo configure:1655: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else *************** *** 1676,1692 **** do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 ! echo "configure:1680: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1690: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 1678,1694 ---- do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 ! echo "configure:1682: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:1692: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** *** 1715,1726 **** # Checks for typedefs, structures, and compiler characteristics. echo $ac_n "checking for uid_t in sys/types.h""... $ac_c" 1>&6 ! echo "configure:1719: checking for uid_t in sys/types.h" >&5 if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF --- 1717,1728 ---- # Checks for typedefs, structures, and compiler characteristics. echo $ac_n "checking for uid_t in sys/types.h""... $ac_c" 1>&6 ! echo "configure:1721: checking for uid_t in sys/types.h" >&5 if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF *************** *** 1749,1755 **** fi echo $ac_n "checking type of array argument to getgroups""... $ac_c" 1>&6 ! echo "configure:1753: checking type of array argument to getgroups" >&5 if eval "test \"`echo '$''{'ac_cv_type_getgroups'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1751,1757 ---- fi echo $ac_n "checking type of array argument to getgroups""... $ac_c" 1>&6 ! echo "configure:1755: checking type of array argument to getgroups" >&5 if eval "test \"`echo '$''{'ac_cv_type_getgroups'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** *** 1757,1763 **** ac_cv_type_getgroups=cross else cat > conftest.$ac_ext < conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_type_getgroups=gid_t else --- 1784,1790 ---- } EOF ! if { (eval echo configure:1788: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_type_getgroups=gid_t else *************** *** 1796,1802 **** if test $ac_cv_type_getgroups = cross; then cat > conftest.$ac_ext < EOF --- 1798,1804 ---- if test $ac_cv_type_getgroups = cross; then cat > conftest.$ac_ext < EOF *************** *** 1824,1835 **** for ac_func in vsnprintf do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:1828: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:1830: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 1854,1860 ---- ; return 0; } EOF ! if { (eval echo configure:1858: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else From jwt@dskk.co.jp Wed Mar 22 01:25:12 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Wed, 22 Mar 2000 10:25:12 +0900 Subject: [Mailman-Developers] htmlformat.py missing , quotes on attributes Message-ID: <20000322102512.A803@mail.dskk.co.jp> --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii CVS of 2000-03-21 19:00 EST My /mailman/listinfo page was missing a tag. It looks like it is missing from all pages generated by mailman/htmlformat.py As long as I was looking at the HTML source, I noticed that it quoted the attribute values for some of the tags (like for the BODY tag), but not those for table, table rows, and cells. That led to things like 100% and #99CCFF not being quoted literals. add tag quote all attribute values -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="htmlformat.diff" --- Mailman/htmlformat.py.orig Tue Mar 21 15:58:15 2000 +++ Mailman/htmlformat.py Wed Mar 22 09:19:00 2000 @@ -121,7 +121,7 @@ output = output + ' NOWRAP' continue else: - output = output + ' %s=%s' %(string.upper(key), val) + output = output + ' %s="%s"' %(string.upper(key), val) return output @@ -132,7 +132,7 @@ for (key, val) in info.items(): if not key in valid_mods: continue - output = output + ' %s=%s' %(string.upper(key), val) + output = output + ' %s="%s"' %(string.upper(key), val) return output @@ -149,7 +149,7 @@ output = output + ' BORDER' continue else: - output = output + ' %s=%s' %(string.upper(key), val) + output = output + ' %s="%s"' %(string.upper(key), val) return output @@ -284,7 +284,7 @@ else: output = output + '>\n' output = output + Container.Format(self, indent) - output = output + '%s\n' % spaces + output = output + '%s\n%s\n' % (spaces, spaces) return output class HeadlessDocument(Document): --OgqxwSJOaUobr8KG-- From bwarsaw@cnri.reston.va.us Wed Mar 22 04:53:49 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 21 Mar 2000 23:53:49 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 2.0 beta 1 Message-ID: <14552.20957.516043.218533@anthem.cnri.reston.va.us> I've just uploaded the Mailman 2.0 beta 1 tarball to www.list.org. I decided to name the new version "2.0" because of the architectural changes that have been made. See the excerpt from the NEWS file below for details of what's changed since version 1.1. Two important things to take note of. You will need Python 1.5.2 to run this version of Mailman. Also, if you are upgrading from Mailman 1.x you will need to read the UPGRADING file for instructions. I don't plan to make wider release announcements until 2.0 final is ready to go, but I also don't expect the beta cycle to be very long. We'll see! Enjoy, -Barry -------------------- snip snip -------------------- - A new bundled auto-responder has been added. You can now configure an autoresponse text for each list's primary addresses: listname@yourhost.com -- the general posting address listname-request@... -- the automated "request bot" address listname-admin@... -- the human administrator address - The standard UI now includes three logos at the bottom of the page: Dragon's Mailman logo, the Python Powered logo, and the GNU logo. All point to their respective home pages. - It is now possible to set the Reply-To: field on lists to an arbitrary address. NOTE: Reply-To: munging is generally considered harmful! However for some read-only lists, it is useful to direct replies to a parallel discussion list. - There is a new message delivery architecture which uses a pipeline processor for incoming and internally generated messages. Mailman no longer contains a bundled bulk-mailer; instead message delivery is handled completely by the MTA. Most MTAs give a high enough priority to connections from the localhost that mail will not be lost because of system load, but this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the Mailman host. In practice, mail lossage has not be observed. For this reason cron/run_queue is no longer needed (see the UPGRADING file for details). Also, you can choose whether you want direct smtp delivery, or delivery via the command line to a sendmail-compatible daemon. You can also easily add your own delivery module. See Mailman/Defaults.py for details. - A similar pipeline architecture for the parsing of bounce messages has been added. Most common bounce formats are now handled, including Qmail, Postfix, and DSN. It is now much easier to add new bounce detectors. - The approval pending architecture has also been revamped. Subscription requests and message posts waiting for admin approval are no longer kept in the config.db file, but in a separate requests.db file instead. - Finally made consistent the use of Sender:/From:/From_ in the matching of headers for such things as member-post-only. Now, if USE_ENVELOPE_SENDER is true, Sender: will always be chosen over From:, however the default has been changed to USE_ENVELOPE_SENDER false so that From: is always chosen over Sender:. In both cases, if no header is found, From_ (i.e. the envelope sender is used). Note that the variable is now misnamed! Most people want From: matching anyway and any are easily spoofable. - New scripts bin/move_list, bin/config_list - cron/upvolumes_yearly, cron/upvolumes_monthly, cron/archive, cron/run_queue all removed. Edit your crontab if you used these scripts. Other scripts removed: contact_transport, deliver, dumb_deliver. - Several web UI improvements, especially in the admin page. - Remove X-pmrqc: headers to prevent return reciepts for Pegasus mail users. - Security patch when using external archivers. - Honor "X-Archive: No" header by not putting this message in the archive. - Changes to the log file format. - The usual bug fixes. From jarrell@vt.edu Wed Mar 22 05:41:06 2000 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 22 Mar 2000 00:41:06 -0500 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.52206.999641.515081@anthem.cnri.reston.va.us> References: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> Message-ID: <4.2.0.58.20000322003046.04ba02a0@vtserf.cc.vt.edu> --=====================_106735433==_.ALT Content-Type: text/plain; charset="us-ascii" At 02:22 PM 3/21/00 -0500, you wrote: > >>>>> "RJ" == Ron Jarrell writes: > > RJ> Upgraded my test machine, which was running a month or two ago > RJ> cvs snapshot, and so far things are ok. Except for gateing > RJ> *to* a list, but someone already caught that. > >Right. That change should have been checked in by now, so doing a cvs >update should get you the fix to Mailman/Handlers/ToUsenet.py Will do. Oh, also (which you may have fixed in this latest round of checkins, I haven't grabbed today's yet) the cron Makefile still wanted to install run_queue. > RJ> Note that the images aren't in the cvs repository yet. > >The should be! Take a look at > > http://cvs.python.org/cgi-bin/viewcvs.cgi/mailman/misc/ Ah.. mailman/misc... I found mailman.jpg and dragonlogo.jpg in admin/www/images (which seemed a reasonably place for them), but not the others. Because having found some there, I didn't look in misc... >and you should find PythonPowered.png, gnu-head-tiny.jpg, and >mailman.jpg which are the three logos. > > RJ> (Is the python image really a PNG? Yuck.) > >Why yuck? My dilemma was this: PythonPowered.gif is purposefully >transparent around the edges of the oval, but we can't use gifs As the character on Saturday Night Live would say. "Oh. Never mind." I knew earlier netscapes didn't do pngs. At some point when I installed Plugger into my solaris netscape it picked up PNGs. But handed them to an image program that couldn't display them. I'd seen that my attempts to do some PNG graphs (using a PNG converted GIFgraph, since GD doesn't do gifs) failed miserably... Apparently inline PNGs however, quite transparently to me, were working fine... I just went through and deleted all the variants of the mime type and the external handler, and lo and behold, pngs display right now. Go figure. >because Mailman is Gnu. I'd have preferred jpegs for consistency, but >I couldn't figure out how to make the transparency work (I don't think >jpeg supports transparencies). No, they don't. Shame, really. If they did animation and transparancies, there'd mostly only be one format out there now. --=====================_106735433==_.ALT Content-Type: text/html; charset="us-ascii" At 02:22 PM 3/21/00 -0500, you wrote:

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

    RJ> Upgraded my test machine, which was running a month or two ago
    RJ> cvs snapshot, and so far things are ok.  Except for gateing
    RJ> *to* a list, but someone already caught that.

Right.  That change should have been checked in by now, so doing a cvs
update should get you the fix to Mailman/Handlers/ToUsenet.py

Will do. 

Oh, also (which you may have fixed in this latest round of checkins, I haven't
grabbed today's yet) the cron Makefile still wanted to install run_queue.


    RJ> Note that the images aren't in the cvs repository yet.

The should be!  Take a look at

    http://cvs.python.org/cgi-bin/viewcvs.cgi/mailman/misc/

Ah.. mailman/misc... I found mailman.jpg and dragonlogo.jpg in admin/www/images
(which seemed a reasonably place for them), but not the others.  Because having found
some there, I didn't look in misc...


and you should find PythonPowered.png, gnu-head-tiny.jpg, and
mailman.jpg which are the three logos.
   
    RJ> (Is the python image really a PNG?  Yuck.)

Why yuck?  My dilemma was this: PythonPowered.gif is purposefully
transparent around the edges of the oval, but we can't use gifs

As the character on Saturday Night Live would say.  "Oh.  Never mind."

I knew earlier netscapes didn't do pngs.  At some point when I installed Plugger
into my solaris netscape it picked up PNGs.  But handed them to an image program
that couldn't display them.  I'd seen that my attempts to do some PNG graphs (using
a PNG converted GIFgraph, since GD doesn't do gifs) failed miserably... Apparently
inline PNGs however, quite transparently to me, were working fine...  I just went through
and deleted all the variants of the mime type and the external handler, and lo and behold,
pngs display right now.  Go figure.

because Mailman is Gnu.  I'd have preferred jpegs for consistency, but
I couldn't figure out how to make the transparency work (I don't think
jpeg supports transparencies).

No, they don't.  Shame, really.  If they did animation and transparancies, there'd
mostly only be one format out there now.
--=====================_106735433==_.ALT-- From rullfig@uchicago.edu Wed Mar 22 14:11:11 2000 From: rullfig@uchicago.edu (Roberto Ullfig) Date: Wed, 22 Mar 2000 08:11:11 -0600 Subject: [Mailman-Developers] Mailman keying on Sender: Field Message-ID: <38D8D47F.219AEA87@uchicago.edu> I noticed that Mailman keys on the Sender: field when you email in a subscription request. Is this really necessary? Is it possible to reconfigure Mailman to key on the From: field instead? Is this more or less desirable? Since confirmations are always in place it seems to me that there's enough protection as it is without using the Sender: field. -- Roberto Ullfig : rullfig@uchicago.edu Systems Administrator Networking Services and Information Technologies University of Chicago From secabeen@pobox.com Wed Mar 22 16:00:47 2000 From: secabeen@pobox.com (Ted Cabeen) Date: Wed, 22 Mar 2000 10:00:47 -0600 Subject: [Mailman-Developers] Mailman keying on Sender: Field In-Reply-To: Your message of "Wed, 22 Mar 2000 08:11:11 CST." <38D8D47F.219AEA87@uchicago.edu> Message-ID: <200003221600.KAA23077@entropy.uchicago.edu> In message <38D8D47F.219AEA87@uchicago.edu>, Roberto Ullfig writes: >I noticed that Mailman keys on the Sender: field when you email >in a subscription request. Is this really necessary? Is it >possible to reconfigure Mailman to key on the From: field >instead? Is this more or less desirable? Since confirmations are >always in place it seems to me that there's enough protection as >it is without using the Sender: field. That will be in the 2.0 release. It's supposed to be supported in 1.1, but it's a little broken. I posted a patch to 1.1 that allows From matching, so you can check the archives and find it if you don't want to wait. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen@pobox.com Check Website or finger for PGP Public Key secabeen@midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen@aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com From bwarsaw@cnri.reston.va.us Wed Mar 22 16:13:48 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 11:13:48 -0500 (EST) Subject: [Mailman-Developers] Betas coming soon References: <4.2.0.58.20000321135455.05b117a0@vtserf.cc.vt.edu> <4.2.0.58.20000322003046.04ba02a0@vtserf.cc.vt.edu> Message-ID: <14552.61756.968461.466277@anthem.cnri.reston.va.us> >>>>> "RJ" == Ron Jarrell writes: RJ> Oh, also (which you may have fixed in this latest round of RJ> checkins, I haven't grabbed today's yet) the cron Makefile RJ> still wanted to install run_queue. Well, it's fixed now! Thanks... :) RJ> Ah.. mailman/misc... I found mailman.jpg and dragonlogo.jpg in RJ> admin/www/images (which seemed a reasonably place for them), RJ> but not the others. Because having found some there, I didn't RJ> look in misc... Yeah, that directory is what gets published at www.list.org, but other than that it's pretty separate from the rest of the code. I'd like to reorganize and improve the www tree at some point. RJ> As the character on Saturday Night Live would say. "Oh. RJ> Never mind." :) RJ> No, they don't. Shame, really. If they did animation and RJ> transparancies, there'd mostly only be one format out there RJ> now. Or if Unisys would quit shooting themselves in the foot with LWZ. Still PNG is a nice format, so hopefully it'll start gaining more widespread use. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 16:39:15 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 11:39:15 -0500 (EST) Subject: [Mailman-Developers] Mailman keying on Sender: Field References: <38D8D47F.219AEA87@uchicago.edu> Message-ID: <14552.63283.411277.530643@anthem.cnri.reston.va.us> >>>>> "RU" == Roberto Ullfig writes: RU> I noticed that Mailman keys on the Sender: field when you RU> email in a subscription request. Is this really necessary? Is RU> it possible to reconfigure Mailman to key on the From: field RU> instead? Is this more or less desirable? Since confirmations RU> are always in place it seems to me that there's enough RU> protection as it is without using the Sender: field. In Mailman 2.0 (currently at beta 1), this has been made much more consistent. There's a configuration variable called USE_ENVELOPE_SENDER which controls this; the default is now to use From: followed by Sender: then the envelope sender. -Barry From ricardo@rixhq.nu Wed Mar 22 17:06:07 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 22 Mar 2000 18:06:07 +0100 Subject: [Mailman-Developers] beta & smtp In-Reply-To: <14552.3060.228549.718496@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 06:55:32PM -0500 References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> <14552.3060.228549.718496@anthem.cnri.reston.va.us> Message-ID: <20000322180607.A9914@miss-janet.com> Hi, On Tue, Mar 21, 2000 at 06:55:32PM -0500, Barry A. Warsaw wrote: > RK> set to 'miss-janet.com' in Defaults.py ... I changed this to > RK> 'localhost' (in mm_cfg.py) and now it works again... I wonder > RK> why it was set to miss-janet.com though... (I'm not sure if it > RK> was there already or was changed during the upgrade) > This was likely a result of the upgrade. I set SMTPHOST to the fqdn > of the host that you're on. However, if your machine's primary alias > was www.miss-janet.com, the SMTPHOST got the "www." stripped off. > I'll bet that's what we're seeing here. > Yes this is all crufty and broken, and probably only useful for a > small number of installations that use staging servers. I think I > have a not-so-drastic fix though that I'd like you to try. See the > patch below. in my case, mailman runs on www1.miss-janet.com and the website (including the A record for 'miss-janet.com') is on a entirely different server > BTW, I remember having some problems when using Postfix and just > setting SMTPHOST to 'localhost', but I can't remember the details > right now. it seems to work ok so far so i'm not complaining :) is that the only reason for not choosing localhost as default? > There's currently only two, as described in Mailman/Defaults.py. > Search for the variable DELIVERY_MODULE; there's an explanation and > the alternative value in a comment. Let me know if this needs more > explaining or documenting. later i discovered that it's mentioned in the NEWS file (thanks to the misspelling patch posted on the list :) ) so I had a look at Defaults.py... the info there is clear enough... Ricardo. -- From rullfig@uchicago.edu Wed Mar 22 17:15:55 2000 From: rullfig@uchicago.edu (Roberto Ullfig) Date: Wed, 22 Mar 2000 11:15:55 -0600 Subject: [Mailman-Developers] Mailman keying on Sender: Field References: <38D8D47F.219AEA87@uchicago.edu> <14552.63283.411277.530643@anthem.cnri.reston.va.us> Message-ID: <38D8FFCB.2A23BE0B@uchicago.edu> "Barry A. Warsaw" wrote: > > >>>>> "RU" == Roberto Ullfig writes: > > RU> I noticed that Mailman keys on the Sender: field when you > RU> email in a subscription request. Is this really necessary? Is > RU> it possible to reconfigure Mailman to key on the From: field > RU> instead? Is this more or less desirable? Since confirmations > RU> are always in place it seems to me that there's enough > RU> protection as it is without using the Sender: field. > > In Mailman 2.0 (currently at beta 1), this has been made much more > consistent. There's a configuration variable called > USE_ENVELOPE_SENDER which controls this; the default is now to use > From: followed by Sender: then the envelope sender. That sounds good. I have a related question that perhaps someone on this list can answer. Can the Sender: field be changed by sendmail configuration? For instance would masquerading ever effect this field or is changing the Sender: field verboten? -- Roberto Ullfig : rullfig@uchicago.edu Systems Administrator Networking Services and Information Technologies University of Chicago From bwarsaw@cnri.reston.va.us Wed Mar 22 17:48:15 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 12:48:15 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] confidentiality features References: <20000321174503.O16886@bsd.uchicago.edu> Message-ID: <14553.1887.233014.783985@anthem.cnri.reston.va.us> Please trim followups to mailman-developers@python.org... >>>>> "mjinks" == writes: mjinks> First of all, in testing it appears that although the mjinks> "From:" header is stripped, the "X-Sender:" still comes mjinks> through, as does the sender's IP address. We're in a mjinks> university, so back-tracing an IP address to a nearby mjinks> individual is not that tough, and could certainly be seen mjinks> as a gap for confidentiality. Could X-Sender and IP also mjinks> be stripped? Have I missed some detail? Mailman doesn't know about X-Sender, so it doesn't by default strip those. You'd probably also have to grok through Received: headers and others to truly anonymize the message. mjinks> On the other hand, this user wants to be able to peek mjinks> behind the curtain in those cases where confidentiality mjinks> needs to be violated -- for example if a poster to the mjinks> list claims to be suicidal or otherwise seems dangerous. mjinks> I showed the user that he'd see the real return address if mjinks> we set the list to be moderated, but he didn't like that mjinks> idea. Any clues? Can identifying information be made mjinks> available, say, to the list owner only? Here's the approach I would explore, using the 2.0 code base. Write a message handler module (see Mailman/Handlers/* for examples), calling it Anonymize.py. Put this in the pipeline such that every message passes through it before it's delivered to the archiver, or usenet, or the list. In this module, you'd strip or munge all the headers you want. To support lifting the curtain, you can store (securely, on the file system) whatever information gleaned out of the message is necessary to link the poster with the email message. You might even key both off of a randomly generated ID, which you'd poke into the outgoing message. Now that I think about it, it wouldn't be too hard to extend this idea into a general framework for email anonymizing. Given an MTA that can handle highly dynamic updates to it's alias database, you're "randomly generated ID" above would be used to create a Reply-To: address pointing back to your anonymizing service. Your add-on stuff would handle delivering back to the original user based on the random address. Oooh, what a neat idea! Let me know if you decide to play around with this. It'd be really cool to add some more anonymizing features in a future version. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 17:56:19 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 12:56:19 -0500 (EST) Subject: [Mailman-Developers] beta & smtp References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> <14552.3060.228549.718496@anthem.cnri.reston.va.us> <20000322180607.A9914@miss-janet.com> Message-ID: <14553.2371.220050.697558@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> it seems to work ok so far so i'm not complaining :) is that RK> the only reason for not choosing localhost as default? I think so, but now I'm not so sure. I agree that 'localhost' would be a better default, if it works. I'll do some testing with Postfix, but it would be nice to hear from those of you with other MTAs. -Barry From claw@kanga.nu Wed Mar 22 17:58:53 2000 From: claw@kanga.nu (J C Lawrence) Date: Wed, 22 Mar 2000 09:58:53 -0800 Subject: [Mailman-Developers] Mailman keying on Sender: Field In-Reply-To: Message from Roberto Ullfig of "Wed, 22 Mar 2000 08:11:11 CST." <38D8D47F.219AEA87@uchicago.edu> References: <38D8D47F.219AEA87@uchicago.edu> Message-ID: <1919.953747933@kanga.nu> On Wed, 22 Mar 2000 08:11:11 -0600 Roberto Ullfig wrote: > I noticed that Mailman keys on the Sender: field when you email in > a subscription request. Is this really necessary? Is it possible > to reconfigure Mailman to key on the From: field instead? Is this > more or less desirable? Since confirmations are always in place it > seems to me that there's enough protection as it is without using > the Sender: field. There's a documented value you can edit in mm_cfg.py to change this. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From gorgo@sztaki.hu Wed Mar 22 18:12:42 2000 From: gorgo@sztaki.hu (Gergely Madarasz) Date: Wed, 22 Mar 2000 19:12:42 +0100 (MET) Subject: [Mailman-Developers] mailman 2.0beta1 problem: Mail delivery failed: returning message to sender (fwd) Message-ID: Hello, I've just upgraded my test machine to 2.0beta1 ... I sent a test message to the list, it was delivered correctly to its members and then I got the error message attached below. Anyway it seems quite strange to me... first, why does scripts/post write anything to stdout, second, why does it write "starting" twice ? The logs/post file has the following: Mar 22 19:02:22 2000 (6870) post to test from gorgo@sztaki.hu, size=444, success Additionally in logs/error I have the following: Mar 22 19:02:22 2000 post(6870): starting Mar 22 19:02:22 2000 post(6870): ending -- Madarasz Gergely gorgo@sztaki.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ ---------- Forwarded message ---------- Date: Wed, 22 Mar 2000 19:02:23 +0100 From: Mail Delivery System To: gorgo@sztaki.hu Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: test@thunderchild.aszi.sztaki.hu: generated |/var/lib/mailman/mail/wrapper post test The following text was generated during the delivery attempt: ------ |/var/lib/mailman/mail/wrapper post test ------ starting ending starting ------ This is a copy of the message, including all the headers. ------ Return-path: Received: from lutra.sztaki.hu [193.225.86.1] by thunderchild.aszi.sztaki.hu with esmtp (Exim 3.12 #1 (Debian)) id 12XpSX-0001ml-00; Wed, 22 Mar 2000 19:02:21 +0100 Received: from localhost by sztaki.hu (PMDF V5.2-32 #42635) with ESMTP id <0FRU004014RXGU@sztaki.hu> for test@thunderchild.aszi.sztaki.hu; Wed, 22 Mar 2000 19:02:21 +0100 (MET) Date: Wed, 22 Mar 2000 19:02:21 +0100 (MET) From: Gergely Madarasz Subject: proba To: test@thunderchild.aszi.sztaki.hu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII humm -- Madarasz Gergely gorgo@sztaki.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From Gergely Madarasz Wed Mar 22 18:24:12 2000 From: Gergely Madarasz (Gergely Madarasz) Date: Wed, 22 Mar 2000 19:24:12 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 Message-ID: Hello, Previous versions always put Sender: -admin@ in all mails sent out to the list... it seems that with the new sendmail delivery module it has some issues... with exim the mailman user has to be listed in the trusted_users option for this to work, if it is not listed, the Sender: header becomes mailman@ -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From ricardo@rixhq.nu Wed Mar 22 18:30:38 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 22 Mar 2000 19:30:38 +0100 Subject: [Mailman-Developers] lock lifetime Message-ID: <20000322193038.A10212@miss-janet.com> One of the changes I have to make for my server is to increase the lock lifetime. I suspect that other people who don't have a speedy server either, might get the same problems as me... so maybe it should be mentioned in the install docs and/or moved to a global variable in mm_cfg.py... Below is an excerpt of a message from Thomas who fixed this for me.... For my server I've changed this to 300. "... In any case, you can easily try it out; in Mailman/MailList.py, on or around line 282, there should be a 'lifetime = 60', inside the constructor for the maillists' lockfile. Changing the '60' in, say, '600', should give you better mileage, at least until your machine gets so heavily loaded that a simple admin request takes ten full minutes to process ;) " Ricardo. -- From Nigel.Metheringham@VData.co.uk Wed Mar 22 18:35:43 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Wed, 22 Mar 2000 18:35:43 +0000 Subject: [Mailman-Developers] beta & smtp In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Wed, 22 Mar 2000 12:56:19 EST." <14553.2371.220050.697558@anthem.cnri.reston.va.us> Message-ID: bwarsaw@cnri.reston.va.us said: > I think so, but now I'm not so sure. I agree that 'localhost' would > be a better default, if it works. I'll do some testing with Postfix, > but it would be nice to hear from those of you with other MTAs. Exim will need localhost or 127.0.0.1/32 listing as an allowed relayer - this is already in the exim/mailman HOWTO. gorgo@caesar.elte.hu said: > Previous versions always put Sender: -admin@ in all > mails sent out to the list... it seems that with the new sendmail > delivery module it has some issues... with exim the mailman user has > to be listed in the trusted_users option for this to work, if it is > not listed, the Sender: header becomes mailman@ That will be the case. I would tend to use smtp injection personally, and also prevent exim doing significant lookups on the incoming addresses - ie no recipient verification. RSN I'll put mailman 2beta on the exim site and knock the config into shape for it... and then look at the bouncer module. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From bwarsaw@cnri.reston.va.us Wed Mar 22 18:38:59 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 13:38:59 -0500 (EST) Subject: [Mailman-Developers] beta & smtp References: <20000321210635.B2014@miss-janet.com> <20000321213414.C2014@miss-janet.com> <14552.3060.228549.718496@anthem.cnri.reston.va.us> <20000322180607.A9914@miss-janet.com> <14553.2371.220050.697558@anthem.cnri.reston.va.us> Message-ID: <14553.4931.198854.759224@anthem.cnri.reston.va.us> >>>>> "BAW" == writes: BAW> I think so, but now I'm not so sure. I agree that BAW> 'localhost' would be a better default, if it works. I'll do BAW> some testing with Postfix, but it would be nice to hear from BAW> those of you with other MTAs. It seems to work fine for Postfix. I guess I'll make this change. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 19:00:55 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 14:00:55 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: Message-ID: <14553.6247.676809.133555@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Hello, GM> Previous versions always put Sender: -admin@ GM> in all mails sent out to the list... it seems that with the GM> new sendmail delivery module it has some issues... with exim GM> the mailman user has to be listed in the trusted_users option GM> for this to work, if it is not listed, the Sender: header GM> becomes mailman@ Is that also true if you use SMTPDirect? From gorgo@caesar.elte.hu Wed Mar 22 19:04:02 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 22 Mar 2000 20:04:02 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: <14553.6247.676809.133555@anthem.cnri.reston.va.us> Message-ID: On Wed, 22 Mar 2000, Barry A. Warsaw wrote: > >>>>> "GM" == Gergely Madarasz writes: > > GM> Hello, > > GM> Previous versions always put Sender: -admin@ > GM> in all mails sent out to the list... it seems that with the > GM> new sendmail delivery module it has some issues... with exim > GM> the mailman user has to be listed in the trusted_users option > GM> for this to work, if it is not listed, the Sender: header > GM> becomes mailman@ > > Is that also true if you use SMTPDirect? I didn't try but I'm pretty sure that it is not. Exim can check usernames, etc, only if invoked directly, not thru port 25. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From bwarsaw@cnri.reston.va.us Wed Mar 22 19:06:12 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 14:06:12 -0500 (EST) Subject: [Mailman-Developers] lock lifetime References: <20000322193038.A10212@miss-janet.com> Message-ID: <14553.6564.572812.203295@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> "... In any case, you can easily try it out; in RK> Mailman/MailList.py, on or around line 282, there should be a RK> 'lifetime = 60', inside the constructor for the maillists' RK> lockfile. Changing the '60' in, say, '600', should give you RK> better mileage, at least until your machine gets so heavily RK> loaded that a simple admin request takes ten full minutes to RK> process ;) " One other gotcha, if you use bin/withlist to open a locked list and then exit the interpreter without doing an explicit m.Unlock(), you're list will be locked out for the duration. Still, I'm willing to put something in Defaults.py like this: # How long is the default lifetime for the MailList object lock, in seconds? LIST_LOCK_LIFETIME = 120 and then set lifetime at line 282 to use this variable. Will that work for you? -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 19:11:46 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 14:11:46 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: <14553.6247.676809.133555@anthem.cnri.reston.va.us> Message-ID: <14553.6898.288580.184278@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I didn't try but I'm pretty sure that it is not. Exim can GM> check usernames, etc, only if invoked directly, not thru port GM> 25. Gotcha. I agree with Nigel that SMTPDirect is the better way to go (no chance of funky shell tricks leaking through either). That should be the default with 2.0beta1. I consider Sendmail.py a proof-of-concept at best; I hacked it together quickly so that I could make sure the new architecture would work. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 19:21:26 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 22 Mar 2000 14:21:26 -0500 (EST) Subject: [Mailman-Developers] mailman 2.0beta1 problem: Mail delivery failed: returning message to sender (fwd) References: Message-ID: <14553.7478.896273.785720@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I've just upgraded my test machine to 2.0beta1 ... I sent a GM> test message to the list, it was delivered correctly to its GM> members and then I got the error message attached below. GM> Anyway it seems quite strange to me... first, why does GM> scripts/post write anything to stdout, second, why does it GM> write "starting" twice ? The logs/post file has the GM> following: Mar 22 19:02:22 2000 (6870) post to test from GM> gorgo@sztaki.hu, size=444, success | Additionally in logs/error I have the following: | Mar 22 19:02:22 2000 post(6870): starting | Mar 22 19:02:22 2000 post(6870): ending It is normal to see those messages in logs/error. That's useful debugging information that should probably be turned off in 2.0 final. I think I understand why you're getting output to stdout. Look in scripts/post and change LogStdErr("error", "post") to LogStdErr("error", "post", tee_to_stdout=0) The question is, why haven't I seen this with Postfix? Does it just get chucked? I definitely don't see it in my syslog (and I'm logging all mail.* messages in my syslog.conf. Weird. I also understand why you see it twice. It would be possible if there was some kind of permission problem with logs/error, but you're seeing messages in that file, so that can't be it. -Barry From gorgo@caesar.elte.hu Wed Mar 22 19:29:40 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 22 Mar 2000 20:29:40 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: <14553.6898.288580.184278@anthem.cnri.reston.va.us> Message-ID: On Wed, 22 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > >>>>> "GM" == Gergely Madarasz writes: > > GM> I didn't try but I'm pretty sure that it is not. Exim can > GM> check usernames, etc, only if invoked directly, not thru port > GM> 25. > > Gotcha. I agree with Nigel that SMTPDirect is the better way to go > (no chance of funky shell tricks leaking through either). That should > be the default with 2.0beta1. Actually I think that a wrong sender header is more acceptable than the increased possibility of mails getting lost... ;) The first problem can be easily noticed and fixed, while the second is not that easy to discover... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From ricardo@rixhq.nu Wed Mar 22 20:15:25 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Wed, 22 Mar 2000 21:15:25 +0100 Subject: [Mailman-Developers] lock lifetime In-Reply-To: <14553.6564.572812.203295@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Wed, Mar 22, 2000 at 02:06:12PM -0500 References: <20000322193038.A10212@miss-janet.com> <14553.6564.572812.203295@anthem.cnri.reston.va.us> Message-ID: <20000322211525.C10212@miss-janet.com> Hi, On Wed, Mar 22, 2000 at 02:06:12PM -0500, Barry A. Warsaw wrote: > One other gotcha, if you use bin/withlist to open a locked list and > then exit the interpreter without doing an explicit m.Unlock(), you're > list will be locked out for the duration. well I haven't used bin/withlist before, but maybe it could issue a warning when it runs? > Still, I'm willing to put something in Defaults.py like this: > # How long is the default lifetime for the MailList object lock, in seconds? > LIST_LOCK_LIFETIME = 120 > and then set lifetime at line 282 to use this variable. > Will that work for you? that would be great... thanks :) Ricardo. -- From bwarsaw@cnri.reston.va.us Wed Mar 22 20:58:36 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 15:58:36 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: <14553.6898.288580.184278@anthem.cnri.reston.va.us> Message-ID: <14553.13308.285211.662001@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> Actually I think that a wrong sender header is more acceptable GM> than the increased possibility of mails getting lost... ;) The GM> first problem can be easily noticed and fixed, while the GM> second is not that easy to discover... True. Such lossage should at least get logged in logs/error, and I haven't in practice seen any problems on Python.Org, but you are right (as others have also pointed out). Some fallback mechanism should be implemented so that mail doesn't get lost when using SMTPDirect. -Barry From bwarsaw@cnri.reston.va.us Wed Mar 22 21:18:48 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Mar 2000 16:18:48 -0500 (EST) Subject: [Mailman-Developers] lock lifetime References: <20000322193038.A10212@miss-janet.com> <14553.6564.572812.203295@anthem.cnri.reston.va.us> <20000322211525.C10212@miss-janet.com> Message-ID: <14553.14520.677676.569943@anthem.cnri.reston.va.us> >>>>> "RK" == Ricardo Kustner writes: RK> well I haven't used bin/withlist before, but maybe it could RK> issue a warning when it runs? Actually, I just remembered sys.exitfunc! I can set that up to unlock a locked list automatically at interpreter exit. I don't want it to implicitly save the list though -- you'll still have to do that manually if you fiddle with it from the interpreter prompt. Note that this function doesn't run if the interpreter exits because of a signal or os._exit() call. -Barry From sigma@pair.com Wed Mar 22 22:40:20 2000 From: sigma@pair.com (sigma@pair.com) Date: Wed, 22 Mar 2000 17:40:20 -0500 (EST) Subject: [Mailman-Developers] PairList error (fwd) Message-ID: <20000322224020.23969.qmail@smx.pair.com> In the last week or so, we've been seeing the following error and traceback on several pages, including our main listinfo page at http://www.pairlist.net/mailman/listinfo/ I've searched and found nothing about this error. Can someone point me in the right direction, hopefully? Thanks, Kevin Martin sigma@pair.com ----- Forwarded message ----- Bug in Mailman version 1.2 (experimental) We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/usr/mailman/scripts/driver", line 112, in run_main main() File "/usr/mailman/Mailman/Cgi/admin.py", line 67, in main mlist = MailList.MailList(listname) File "/usr/mailman/Mailman/MailList.py", line 69, in __init__ self.Load() File "/usr/mailman/Mailman/MailList.py", line 839, in Load raise Errors.MMBadListError, ('Failed to unmarshal config info: ' TypeError: __add__ nor __radd__ defined for these operands Environment variables: Variable Value DOCUMENT_ROOT /usr/www SERVER_ADDR 216.92.1.92 HTTP_ACCEPT_ENCODING gzip SERVER_PORT 80 PATH_TRANSLATED /usr/www/isc-agent-newsletter GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_LANGUAGE en,zh-CN SERVER_NAME www.pairlist.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.7 [en] (WinNT; U) HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* REQUEST_URI /mailman/admin/isc-agent-newsletter PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin QUERY_STRING SCRIPT_FILENAME /usr/mailman/cgi-bin/admin PATH_INFO /isc-agent-newsletter HTTP_HOST www.pairlist.net REQUEST_METHOD GET SERVER_SIGNATURE SCRIPT_NAME /mailman/admin SERVER_ADMIN webmaster@pairlist.net SERVER_SOFTWARE Apache/1.3.9 (Unix) PYTHONPATH /usr/mailman SERVER_PROTOCOL HTTP/1.0 REMOTE_PORT 1047 From Dan Mick Thu Mar 23 06:24:01 2000 From: Dan Mick (Dan Mick) Date: Wed, 22 Mar 2000 22:24:01 -0800 (PST) Subject: [Mailman-Developers] check_perms bug?... Message-ID: <200003230624.WAA12783@utopia.West.Sun.COM> Somehow, my /home/mailman/lists directory managed to get set with permissions check_perms didn't check for; it was set to d-wx-ws--x/mailman/mailman, which caused mailcmd to be unable to list the directory (no read perms). I fixed it once I figured it out, but I had a lot of check_perms runs in there before I finally figured it out...mostly because I was confused about what 'x' really means on a directory. But check_perms could have saved me time if it had checked for 'owner-and-group-read'; I think it should. From Nigel.Metheringham@VData.co.uk Thu Mar 23 09:33:10 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Thu, 23 Mar 2000 09:33:10 +0000 Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message from bwarsaw@cnri.reston.va.us of "Wed, 22 Mar 2000 15:58:36 EST." <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: >>>>> "GM" == Gergely Madarasz writes: GM> Actually I think that a wrong sender header is more acceptable GM> than the increased possibility of mails getting lost... ;) The GM> first problem can be easily noticed and fixed, while the GM> second is not that easy to discover... bwarsaw@cnri.reston.va.us said: > True. Such lossage should at least get logged in logs/error, and I > haven't in practice seen any problems on Python.Org, but you are right > (as others have also pointed out). Some fallback mechanism should be > implemented so that mail doesn't get lost when using SMTPDirect. We have ended up with a nasty loop here - which means that using SMTP injection I can't stop mail handling (or shut down) on a loaded machine. If I kill the SMTP listener and queue runner, then messages stop being injected into mailman, but any already launched mailman instances will be hit by a brick wall as they try to hand off their messages. A little careful tampering with using an inject to queue only (ie no direct injection into mailman) and a separate queue runner would allow this to be sequenced right, as would some nasty hacks allowing differential handling of smtp coming in from remote addresses and localhost... but all of this is nasty hacking to get round the fact that the MTA and mailman are in a deadly embrace and getting them out of it without losing mail is difficult. On that basis I think on my boxes I am going to have to look at injection through the sendmail CLI which would allow me to kill the smtp listener without mail lossage. The downside of that is it is a harder hit in terms of process starting (at least for exim), error handling is less good, and sendmail CLIs are notoriously strange. One method that may be possible would be to write BSMTP wrapped messages to a directory, and use a (very simple) forked program at the end to feed them to the MTA on localhost, and if successful delete the spooled BSMTP. A cron job could also pick up these spools every so often and attempt to inject them. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From gorgo@caesar.elte.hu Thu Mar 23 11:46:13 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 12:46:13 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: On Wed, 22 Mar 2000 bwarsaw@cnri.reston.va.us wrote: > > >>>>> "GM" == Gergely Madarasz writes: > > GM> Actually I think that a wrong sender header is more acceptable > GM> than the increased possibility of mails getting lost... ;) The > GM> first problem can be easily noticed and fixed, while the > GM> second is not that easy to discover... > > True. Such lossage should at least get logged in logs/error, and I > haven't in practice seen any problems on Python.Org, but you are right > (as others have also pointed out). Some fallback mechanism should be > implemented so that mail doesn't get lost when using SMTPDirect. I'm now working on modifying smtplib.py and SMTPDirect to have the possibility to work with a pipe to sendmail -bs, not only a socket. This would fix all the problems listed up there... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From gorgo@caesar.elte.hu Thu Mar 23 13:37:15 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 14:37:15 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message-ID: On Thu, 23 Mar 2000, Gergely Madarasz wrote: > I'm now working on modifying smtplib.py and SMTPDirect to have the > possibility to work with a pipe to sendmail -bs, not only a socket. This > would fix all the problems listed up there... I've got it working... now smtplib can be told to use '/path/to/sendmail -bs' instead of connecting to localhost:25, and talk smtp there (no addresses in the shell, perhaps a bit better error handling). There is still a problem though... the Sender header gets rewritten this way too... but now it becomes nobody@, I haven't got the faintest clue why this happens, no process should run as nobody here... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From Nigel.Metheringham@VData.co.uk Thu Mar 23 13:44:02 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Thu, 23 Mar 2000 13:44:02 +0000 Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message from Gergely Madarasz of "Thu, 23 Mar 2000 14:37:15 +0100." Message-ID: gorgo@caesar.elte.hu said: > I've got it working... now smtplib can be told to use '/path/to/ > sendmail -bs' instead of connecting to localhost:25, and talk smtp > there (no addresses in the shell, perhaps a bit better error > handling). There is still a problem though... the Sender header gets > rewritten this way too... but now it becomes nobody@, I > haven't got the faintest clue why this happens, no process should run > as nobody here... The MTA should still know the UID its invoked under - exim will have the same Sender: problems as a straight CLI, and so the invoking user will still need to be trusted (or your MTA's equivalent). Also any loading issues from command line invocation still apply to an "mta -bs" invocation - although its probable that I am simply overly paranoid about this. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From gorgo@caesar.elte.hu Thu Mar 23 13:47:18 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 14:47:18 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message-ID: On Thu, 23 Mar 2000, Nigel Metheringham wrote: > gorgo@caesar.elte.hu said: > > I've got it working... now smtplib can be told to use '/path/to/ > > sendmail -bs' instead of connecting to localhost:25, and talk smtp > > there (no addresses in the shell, perhaps a bit better error > > handling). There is still a problem though... the Sender header gets > > rewritten this way too... but now it becomes nobody@, I > > haven't got the faintest clue why this happens, no process should run > > as nobody here... > > The MTA should still know the UID its invoked under - exim will have > the same Sender: problems as a straight CLI, and so the invoking user > will still need to be trusted (or your MTA's equivalent). Yeah, so one problem remains... (but why nobody?) > Also any loading issues from command line invocation still apply to an > "mta -bs" invocation - although its probable that I am simply overly > paranoid about this. The Sendmail delivery module passed the recipients in the command line thru a shell. The modified SMTPDirect module passes the recipients in SMTP commands. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ From gorgo@caesar.elte.hu Thu Mar 23 14:07:06 2000 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Mar 2000 15:07:06 +0100 (MET) Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1649071771-1683543110-953820426=:31790 Content-Type: TEXT/PLAIN; charset=US-ASCII And here is the patch... I guess it needs a customizable sendmail path in Defaults.py.in, and a bit more error handling, but it works... Please include it in the next beta, even if the default will be not to use this... if SMTPCOMMANDLINE is an empty string, it works just as before -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ ---1649071771-1683543110-953820426=:31790 Content-Type: APPLICATION/octet-stream; name="mailman-smtp.diff.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: H4sICDMk2jgCA21haWxtYW4tc210cC5kaWZmAKVXUXObRhB+Nr9i6zwgjSQM 2HIkZtxxJk4nmcZ2JnafOh0FwUm6CXD0Dqyqnf737t6BQLIkyykPQhx7e3vf fvvtEfPZDAalhDTkSRpmA99xp6wIvbNbM3B2w2ZhmRTKyVcOz57ZDVRa5HuM rcFgcKzjk8dFCbehBP8cvItgOApcD3zXda1er/eqVbc9XQQXI+Pp+hoGnjfq X0KPbp4L19cWPNw+fvl4//B4AnAF9vVvXz9f22b0y/3XR1hfV+DCoesNxCYO mEmRAkWY8KkFVu8NRCLFQGNIeMagEDBnBd3CTK8DRZh859kccinmMkz7EHMl 2TyU8To6tI3J0zouPoNMFMDSvFhZPRp+f397++7u5vOnuw86XPusVPJMTXl2 plgWE4YwmCrb6lkYrEcBlIpBJFc5xiwk5KFSSyFjBTxTBQtjEDNI46FD9u+1 WRqu9LJo9h1EBmGSQL4qFviX5uCj0tY3IrMLiBZhNscNL7iCpzApGU6JGKxE CYvwiSEcqlAgyyzD3TuOY8Uv0vEj4pAwqc5oxzdcsqjAtL9AkN2TDtNz95yT R9yEJpcH7tvAHwbDo2m6z+MmXYeBO27oej7qv4We/iWuVjzj4TwTmLrlghUL JmHJIGMspoxKtpS8qDBPRVwmzAwj9f4suVrgGwN87S0REaZSUlodM1a4yJ6C p8yhn07XGtBoJLIMxyteO7SJTppOotncqUnah9YAsbRr9X506sZAi9pdE6Nk MyRvjF7/+beKWq4Ca12N+ullOhnuYlBndXAvkmnXlMNU2jXj5KHM4E48gT8C bxR4XuBegjcej48g0k5/bRohh9DfeUOjC5dED38NjWwbFc4CnuZCFqCQAKyw etVjLnKW+c3bQmJxrh8la/7OopHvG1W91Dz1LsctorJFIiaSqRyTdCcyZkZj wdSEUeCkqBiGJhdKJ0wmPOPFZNJRLJn1YSFUQSpm90Evh9bdwPDpOOt+Lbta deldt0WQ09PTT+iAhwn/m0GIBbQ0EoYK5RA69fVpBipnEZ9xFvfhGy1kAxYX 1VEWpoxEkv5LlgosPB0IVtxywSMsNmHweTvW+IzcFj5VFM0D7cTR0ExmLCxK xK7Fb7pQ9Ml/YECrr04kYob1ouZdqjLyQhWH+tIha4NIVYqvmrOBYNfaaHcY CrmAn67A993AetYPZchRonT1GscfpBSyta6ZYvAZ+xqf8fmL+MRsWs4T9sQS jLt5aBOp3kjDjCsbVS5MdO520+nYOS+Sqtqsbu+GDNQmYc6fWKa9bJOLuEN2 mkvYpxUsebHAKZFIcGrnW2B3sT0niVii3k1XxNUynTLZ12cCgs/3vP4Yer7n 972LDfzqi/0VsbwuZicsBJ8wSseOvDW5M8LgaMM+nGa4szJlkkd6H6cbtKRD AY0GNVKU+AkJecNVnT9ySowzvs2tUz29+2WCCo/SXz0/3L//dfLw+PXDu9tu 4wZX22bCz+Diwri3AuwqkwEmbYP+z8M4XCWa4OtUB5vls/aT85xoYETT+UK3 805rXt/t7plZAaGVcW3BErV3qR9G7mDkm+v/T4z3B74T6y01IlG40jPwfCxZ nqw6XetgSC7UIZ3WIZ1qcWmmSYZCmrVWMBXjX1JH9M99LJxdBdMETmfnDhbO lv7VFdWqkYMi+MDkE5M3XFWBsrhjmzFdO+tRu9tmQ71pStYhCjqFiBY8iR19 +jPhHmE9S0q1aINs+PeKLeQJC/E1nuHXEopqxSWKJrk1YA+1uvuXXv3NtVPe 6ahw9fsfzzM+43iIxY5LVN1qfc37q1bK0vA7o8GOLaf2FhC1UzLch+irHB6X pLZLnQL6SNRJaPaLRwY08rbwrxrN2osj8cuMBjvPO7Kxpa4UaOSH7iUhP8Sv 3U2ab6Kwr2QT/Mhor/JMtwYbcrkPhGbTy5AjP5q3z4Soao3UkfFrxbTjrQb7 yGTKs1B/4xheohuluMgcotN/TmnHAdIQAAA= ---1649071771-1683543110-953820426=:31790-- From bwarsaw@cnri.reston.va.us Thu Mar 23 14:18:35 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 23 Mar 2000 09:18:35 -0500 (EST) Subject: [Mailman-Developers] Sender: header in 2.0beta1 References: <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: <14554.10171.237683.647143@anthem.cnri.reston.va.us> >>>>> "NM" == Nigel Metheringham writes: NM> from remote addresses and localhost... but all of this is NM> nasty hacking to get round the fact that the MTA and mailman NM> are in a deadly embrace and getting them out of it without NM> losing mail is difficult. I'm convinced. And for weird synchronicity, last night I had to do something very similar on python.org and got frightened out of my mind at the prospects of losing email (and oddly enough, not at the weird sleep-debt driven hallucinations I was having :). I will work on robustifying smtp injection for 2.0 beta 2. -Barry From jae@ilk.de Thu Mar 23 00:58:51 2000 From: jae@ilk.de (Juergen A. Erhard) Date: Thu, 23 Mar 2000 01:58:51 +0100 Subject: [Mailman-Developers] Betas coming soon In-Reply-To: <14551.3965.171599.618432@anthem.cnri.reston.va.us> (bwarsaw@cnri.reston.va.us) References: <14551.3965.171599.618432@anthem.cnri.reston.va.us> Message-ID: <23032000.1@sanctum.jae.ddns.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "BAW" =3D=3D Barry A Warsaw writes: [...] BAW> 1) I've thought about being really parental about the upgrade, by BAW> essentially forcing people to read the UPGRADING file before "m= ake" BAW> will succeed. I think I have a trick that will work, but I'm n= ot BAW> sure it's a good idea. On the one hand it /might/ (only might)= BAW> save lazy or novice upgraders some headaches by forcing them to= BAW> read the manual first. BAW> One the other hand, it'll be really annoying either to those wh= o BAW> are doing a fresh install, or who are upgrading but know what BAW> they're doing. So, do you think it would be a good idea to for= ce BAW> everyone to read UPGRADING before "make" succeeds? I don't think it's worth the bother... for one, you can't *really* ensure everybody has read it[1]. And even if you can, you can't really make them *follow* it ;-) *Might* is the word to watch here... it *might* save some folks some trouble. But it *will* annoy many others. So, I'd not do this... I generally don't like mothering software packages ("Are you *really* sure you want to quit?"-like stuff... mostly seen on Windoze, but quite a number of GNOME apps seem to have been infected with this virus (I'd guess KDE is similar, but I can't say)). Bye, J [1] To closest way I can think of[2]: put it on screen, make the user scroll through it, but at a max speed of 1 line per second (which still might be to quick ;-) and make this process *completely* unstoppable. Oh, and keep the user from editing out this part of the Makefile ;-)) [2] And I shudder to think ;-) PS: Of course, I expect the .deb (and .rpm) packagers to show a warning upon or prior to upgrade... - -- = J=FCrgen A. Erhard eMail: jae@ilk.de phone: (GERMANY) 0721 27326 My WebHome: http://members.tripod.com/Juergen_Erhard "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?" -- Michael K. Johnson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Use Mailcrypt and GnuPG iEYEARECAAYFAjjZbEgACgkQN0B+CS56qs2QvQCfR0rrdal9pgIn1r6W+lvd9/0W /YEAn2BmZlVGfkBI2KoLvh14kemqWtgD =3DgUgn -----END PGP SIGNATURE----- From csf@moscow.com Thu Mar 23 18:08:14 2000 From: csf@moscow.com (Michael Yount) Date: Thu, 23 Mar 2000 10:08:14 -0800 Subject: [Mailman-Developers] Sender: header in 2.0beta1 In-Reply-To: ; from Nigel.Metheringham@VData.co.uk on Thu, Mar 23, 2000 at 09:33:10AM +0000 References: <14553.13308.285211.662001@anthem.cnri.reston.va.us> Message-ID: <20000323100814.A1943@moscow.com> On Thu, Mar 23, 2000 at 09:33:10AM +0000, Nigel Metheringham wrote: > > bwarsaw@cnri.reston.va.us said: > > True. Such lossage should at least get logged in logs/error, and I > > haven't in practice seen any problems on Python.Org, but you are right > > (as others have also pointed out). Some fallback mechanism should be > > implemented so that mail doesn't get lost when using SMTPDirect. > > We have ended up with a nasty loop here - which means that using SMTP > injection I can't stop mail handling (or shut down) on a loaded > machine. If I kill the SMTP listener and queue runner, then messages > stop being injected into mailman, but any already launched mailman > instances will be hit by a brick wall as they try to hand off their > messages. > > A little careful tampering with using an inject to queue only (ie no > direct injection into mailman) and a separate queue runner would allow > this to be sequenced right, as would some nasty hacks allowing > differential handling of smtp coming in from remote addresses and > localhost... but all of this is nasty hacking to get round the fact > that the MTA and mailman are in a deadly embrace and getting them out > of it without losing mail is difficult. This is similar to how Mj2 handles incoming mail. In queueing mode, incoming mail is written to a queue directory by the mj_enqueue script. mj_enqueue forks an mj_queueserv process (if it isn't already running) to handle the incoming mail. mj_queueserv will fork one or more mj_queuerun processes, which go through each of the queue directories in turn, locking and processing messages. When Mj2 attempts to deliver a message to a mailing list, it consults the delivery rules for the list in question: one or more primary and backup hosts can be specified. The primary hosts are used in round-robin fashion. If an SMTP session with a primary host fails three times, the backup hosts (localhost by default) are used. If the backup hosts fail, the queue runner aborts, and the message is left in the queue. The next queue runner to process a posted message will mark it as having a duplicate message-id, move the message out of the queue, and notify the list owner. We've recently been battling problems when an SMTP session times out during RCPT TO. Originally, Mj2 would attempt to deliver again to the same address (up to 25 times!); we're testing an alternative approach, which defers these addresses until the end of the delivery cycle. An address that fails twice during RCPT TO simply won't receive the message. It appears from SMTPDirect and smtplib that mailman doesn't use time limits when issuing SMTP commands. Perhaps that is a better approach. Listar and Mj2 use select(). Mj2 doesn't have a way to avoid the "deadly embrace," but it would be fairly easy to modify the queue server to support a "queue but don't process" mode. The Mj2 implementation is far from perfect, but perhaps mailman could benefit from some of our mistakes. Michael > > > Nigel. > -- > [ - Opinions expressed are personal and may not be shared by VData - ] > [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] > [ Phone: +44 1423 850000 Fax +44 1423 858866 ] > From Dan Mick Fri Mar 24 01:12:46 2000 From: Dan Mick (Dan Mick) Date: Thu, 23 Mar 2000 17:12:46 -0800 (PST) Subject: [Mailman-Developers] Betas coming soon Message-ID: <200003240112.RAA04009@utopia.West.Sun.COM> > [1] To closest way I can think of[2]: put it on screen, . . . > [2] And I shudder to think ;-) Hey, nesting footnotes is illegal. Somebody arrest that guy. ;) From camus@deesse.univ-lemans.fr Fri Mar 24 13:06:44 2000 From: camus@deesse.univ-lemans.fr (Matthieu CAMUS (IUP MIME - 96000937)) Date: Fri, 24 Mar 2000 14:06:44 +0100 (CET) Subject: [Mailman-Developers] French traduction of the templates Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---574402316-824018871-953903204=:17770 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm a frenchy student in Computers Sciences and a true fan of Linux. For the needs of a project I used mailman. I have done the french traduction of the templates files in the /etc/mailman directory. I don't know how to do the traduction in the others files (eg *.py). There is a special function named get-text or something like that for the python's files ? Joined to this email the tar.gz of my traduction. Cordialy, Matthieu Camus e-mail: matthieu.camus@univ-lemans.fr ---574402316-824018871-953903204=:17770 Content-Type: APPLICATION/octet-stream; name="french-templates.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: H4sIANVk2zgAA+xdWXPbSJLuV+FXVHNCQXKXpERRR4xHUrcsyd2K0OG2ZHt3 Ozo8EFAUyw0CbBRAW475cftT9DaGH/ZpX/ZtM7MOFEDK7ulpU9EeVswhkkAd WXl8mZWV9sOxiGV+LYNUXHM/+LmXvc2++n3ben99fXtz86t11er/v74xgN92 1rcHO/3++mAbnh/s7PS/Yuu/8zzmtlxmfsrYV2mSfHTdn/r9D9qepMmYrbbG 4+RNzNO29PCLR5VvrhL87COjvOJjX0Tw3WV+/ZoH2SN2MBWShU3gIWCgSSaS mIUcHo+EzGJ/zOFZz4Pe+PgaO2M+K7KCqccz5k95wGQeBO8lu6u81YPXHpo2 /wqNtjX/vBrgk/K/sV2T/83BYGsp/4tov4/8cxYW8h/UATKfTFIxLurPLiV/ kQ22NUpuRPwZzL5tn5D//mCrLv8b/Y31pfwvou2OsnG07+2OuB/ue4ztZiKL +P5Bno14nInAJ3E+QOEHCU3h45TXJXZ3Tb3k7a6pbnavk/CWXd8ESZSke40/ Dak14IcnF8/O2Nnx1fcXR3tPLy6v2MHh1cnF+V5jtTXxs1FbwkOoKaT0b1Bv wISuDh6fHrOXJ0dX3+81gJNWVxvs8cWzo+Nne431Bjs8Pj29fHpweHL+3V5j U31+enB0RJ+3Grgm7OSZ+gP/PGKHF/gKjLrRqHf8Hfx2AT3/6c9/Pjx88qTB Dk5PvoMnD4/Pr46fQXcru4/3YRnnV8w8qbi4wS5P/ut4r/Hv/cY/Rj3ocQ37 299de2wnuXZ1pGe+Zqa+m6XOGvbZbiimZnbPxM0oa+yzsyTD7ie+lJz5zrBD /DryGQ7LH0Gv8PK+M4zp8+T86fMrdvWfT4/3sJM3SRqy84Oz4z3qbPJGLXKw vu/O0EzMnWEWMth9OfHjvQ3mR+Im3huLMAQuqQxy+fzx2ckVQ0rsNVL+S85l 9ooUUsNboUbdTf0ohwdOfQELe9cdJ4IBfVOe9nq9Rkm0LKxOCSaJzIOMiYy3 v7QrM80HI5xM+edU/5/Ef9ubW3X9D6Bwqf8X0V4kIEagHMZ+DBoCfTAthX4Y AlZ7xDwtXautYBwCePM8Bd/420kRigLfAb0y4alM4pjD10WQZ36cWW3Tg1cO m9AjA0679q8jPgbZBR2VBpzBUGya5JKhxr/l71BNSfgMQDLFrnPoknphzSFP xwVvYncv8I2UB3yawitR01dOKIFTrejCIhCSkGiO4wLSLDJf0FLtzJifM0/m rzkpzWmFEmHTv8YF4VxxyKskz7hkEfyXyANdS3zfvo5ESCKRCVzSvEFpRC+E OfsCCfCBhhOpuCmg0ykQ0CU26Vu1B+xzqq3rJI+Dzyv+n5T/nZ16/Ke/vb65 lP9FtEPONNpiZydnx0zxp+ZO4FkB8gq2lpFII2tn/C3wsRTjSUSi3e0CtyIX hX56S/rhMIkzYPBudjsBqIHPr00iX8R/YcHITyXP9nLZ9WUghFEMKOVxAijF ICaQvsD4kUpwQLpJ4Zhvz0DUQVKNyJwqXKOFxwFX+MUZOJ6p/hUlC4WKfjig QdQPB1bc4ZmY3xBWa8vVVihCdErxmWeAP8zzzzi8EILiehsA/cRQsiRnQz/z I/0wUCXP0PVFlcpjVHzwCdREdaXoOgcRj4ORGhy+SKlrhpR5nQj4LhDdEAYB rQfO8Q9G/XzDkNJAKKUDS7TH8xQ1kBQZd0hFyp18ekWBHqkVGDb4ObyWD+j/ rW/a+O/mxmB9i+z/zmAp/4top/49AoZc60evlBh9u9oaJYDM1SfmIxoAkc/a IUO48CHjLdn2fskF8zOQfWtNA2BTERap4vU7lNYVa92OHpO6uAiCfAKgnmCA bIIFp79AZfwPSUPAA8FCP1bGd8xFFAGDg70vQKkAF5/CI75kRTAqQEd14HmY Ql3IpDHsEpWZzOWEQ4cSZAE+T5PbAqEIvBKCabZG/6H3ZhENdgigR/aQ+H/Q H/SN/G9u9wcK/28v5X8R7SPyX1pREPjXOT4k82sB1prdpCBLaM7jGy0sxyCV 3jCJyaLG+GSqzXo+5fCbQdyTCY8KjFCkbJyEeVQbuKGNVQPE7xAFPy3A7IUg plKwDDA4m/rsGoSUXXM/Bx00oXgHOBbR+7HC5ojEb5SJVOoD1YGnh4dHCwkT LtCSHiZjMrnwcFf7IqRsSP/4wyEH0/oNaKh+m6GSSfI0FTxFbZKJuFCOj+oX gz3vCec76EkpFtR6ipba7EKHG212otWccqZCoFmBhB1XAjjptQB7jg7EBAZn fDz5APY6RXiUwwjSM26XVA5MLss4PLwkUWlaRRxj8MRHsG8HV/pPOXIMfBN8 Hiah/ChZwCYVndJF86fonxWv79gkhw+JSEH5/z3vsXP9gIjBAhQIRzxYAO4Y fZ3k15GAL4HE7vI6OFRKDOHORhENhvaiJmAfdPpCYZ0o7eMB5+G0xokgeg7a 7FI4k/TpQBG8s5dJGoXspYBXX/LrjrYsyJLvqK9JlNwCPeMmwNkkzTiYMGRs ovYMOS0z0Z531FMB8BB4hikYJ2RofMqT8B3O2D4SZ+n/RvAMsK0PPKQ4Begl Za62zjJSC20oEcILhZwkMeFvf5K+t7ytORm4DKmPQM9yJhi1EHE6EPY1jgyI dBLlst1hHs+CXq/HTgEnAuNIooeeHkdfGtFlin8Cc1s/VPGtiIfJqzyNyFpv lqSOm0Rs3OqS4C9fVqk8pK3DjscfUEADwBHIuCD/M/urNhd0CfIA7pAjdDOR CXV27OWxdsFhrfB3kKQTSRQHxA2UUGorUpzXGPFo0mAtkoubHIHEmGdt4KBq QAH1VloA8VEG8ywZA4qQhREwlCTE6VoG0YXnpPWIFV9w6hd4UNE5Ja01EzlI ckdp0UoMbFHq0oMlDMVNXiKnSkiAYiql56aUCE61e1PERUryY3H/aguDC9AN vvcUtxyZwsND+2GSjtUIqK9RSyc3IhAgkfpl2EyBfsQ75LxRMuYTHM91KrxR lk0era29efOmh9zSS9IbtvavAZ6+gBakSYzq+CHP/7b72xb/bW1t0vnfzvL8 byGNQJaKwWhj3DE2GNXgECysBmtCdioBz2kCmiscFZIUWmgx1iyQRNdRn+0j 9BBxECGQI2CCOqgSbGU88wINzBwTTaYKDQJhTjJtEa+a56YNFtsYsTZCSoel pIOfPzuV2vDprtREyHgnaEwdxQtK0iyxw27R2E9SIWvJDh30VQPsvomUE4CO AZcWpUPpUbewkveZWqKIp34EoKR8pYU05m9xuQgbtB1HkDD1AwRt2oiD3QeP mqLkuVALPY5JnytEgQZ16AdqnVVLXNz4OvRuiWrgFJLDGxqQlfFIOtjeNRqs YjQ0p5DFtLbIu6NglAIZza622c0qyqmsdrXF38JjbdmeY7g9NNxNNNxNEwTQ Rj609g/mkblTMCcBdVTpkaFVdJJZmpdWu4IeQ9dSd+ijtdXqo+ZPJJjEwQFa dTxNiy4ymQ21Icuf8TQQX8MoZ0kmS3RPPLjayqUJyD16CKOJlP280f9P6v+d jcE66f/NTYz/of7vb2wt438LaQfoGynl+msiAY9YGbN35M0XofKP0POJnR41 8nQxKHosnnbQ4+rpmOP9H6I/LkjLYYAck0WN5Kkwnmf9Uq3flPxpS5Fcgx4R yseogtwA4bXsotXLwE+tOmjKFDjGyM/fqrlJF/SqfijADtrjeewunOfmaI+0 FRL1JqYTQeun1PRYbgiJmug8QbD9S07GjMIsFCzJhHIZ1bGIRLpMQU2iauKw ephpqd5xdA88MrQ4givzPeNrzfrGJjo7z+tDG4OTCHLoMa3aldKaKIqUnqWy KGZfPGNnnQjHnaG4thfERTg27RfS46iy6XJSBGKIR6yy5JqWPTDGYIXQCrnN aketng70ShW4+TdjmtzBrQzY1b4nN740V5pl7INNNtZM0eywPBPwLdCkqb80 Y3wLvjedXB+UAIostsEQknVVeJtMhB8rc97YZfsNDKTcxLBq2uWoIJvMvOP/ OPnu+BKZeM57P7KfGiA2cZIRjIKv7ItPDg6fn14dXJ08uYQJnTcJjWk3PirH BDalXtAUYkiEdtyuL3J3Bdd1Wt0my50SRIspsGOPt22uMfsRpt0NeZeY4Sf2 Y0K06BIk6ioU1QoF6oo2/IpWEjZqb1dv2P5P+rScsUsnZWCuHuuxF7PcFyYm VKfib7a7+fEfRHEWMgKFJho+/FASSHMiioW3Uk6lw+bwfolOFO4Gp71IRRIi d+sDiJWmWn1XjdV0tEtECgJRsIpDPGLNOFFPN/HrpvnbW2n5eYAxWxPw+Lrd szEcmPDIJ/++nnVhpIJ6h14o+mSBXdhM/k8nbmgIqOIX+pSlqiFETIsCFbDS qG8i412Ulf0GU9Mk0YPVj97r4Is6y1SATr/csRsVCzazOM1lTk4723X5bB85 icYu+eeoGub7DSxku8JY04exiSZHYMNqAVRiNUeoAvyfD5lCpWjocOPN/jhp MTP8eKe0VKo9H7s1YjgskIRm18jiMbNf0/pw9aio3S1SJ96KcrrGE2Y2v9lT FH4zSuyqX2A0GB7DvUC7jXpVWUkbMK0RU/WBVqbsRMjcRwVTt9uTtIgEBr9s KNzp13SFH2R1QrAMNPZKC+EfxpS7CEdlLKFd8FZQ0aNh5+kUD9G1ve95SjUg VrYDlOE3TQ4JqnhXCeo+/BH/LRkO9+usZ18/gwWgTonX4DGam9YntTBzj506 v2lNSgsqs4UYwIKf4eOKyksIOMXmKRpqjyzoVanI6TCf48Dp9w2ou6skcJmB lFaZNxaXfIyxauv1ViLTtawrQBG57gOZtzroUEf1rTbG5BEz5IUBdlx938X8 EtZys1LaHTJmmM7SVSCIzoVhRqqLipPekjzXuAn8ahvEp2USFyPiGrZhj1fi BJWQmcihiu5SuoamgrPgHnsOtpLbMxBwIMHqK0GegHCGpFNp/SrInTmuvrv4 OEmDqRkT81UAR6tTKpIDkPunB5flFNQRORFTOsl1epdVL+7OnmOIxx7a6VOb +6jgzmsEfGhJ4dOpVBXKKSaLCKGaQ6qU3/hpyCmTqNQRqpM5Em243ls5Syjb l7oDRqbzf5iSFm8djHIEqNKNTWTeBeoCY3arIrlLMXc/794jqYe1MJGr/fmM kMDWsiRl3a6jKIhRgKh4lpeZLB8XL7VyYpY7jZiJaUg74PcUWltR9u81niXY MwkNFFD6hiIYaTlDtOhnObzeRdXvKxbwVoopxsD06alKhIhzIfH4o47fwKpN LW52YHP9CEanRdpoCQIPwBHAnOBSBTyN1WEUL9NDS8hlTkfLs6ZFpTwum9PG vszw0sZDxv/769sm/rO1taHu//SX+R8LaeVZKzkDYyFlRYmSSw6IMpc6GlRN DGN3YBhXWzdJ9goft/cDPQoZlz4FKAYXvxKO+3VhCU8fQFbGKYMTnpfk2kEn R2JuTJrivmiNTQTGBl90ZBm1kO7eXEKxK3EPEjC7TZDxdnPedfzITXp3e6RA cNnfcawOl0NCJYhC0fuq5b0p/a9DR2bi+tKlPgPwCNZTXj1G5svQCKpj7+UI tHzKJ9GtiG/whIL76GzBaOwWt8b0FQlM1kkYfC8wjIDmZ8Kxp4BlYPm8xjOw 86dch+bzmdRAvIGz1NZ/2BbzN3Rq/5D5f+s7O0b/w/+q/N+Npf5fSCvz/1w9 /1c35t/U+SVBWhRcH8zZCFk1Uu+BxlEJdqSFIgrUOp482ZVr1EQyT62Sqw+v jm/nou3ZqTr5SniHVEF9q7cp5HLNZSJ0MmC1SxP+pxNf/tEZld2VkXbdcfkF TjHXrhlgaTHJI5UwWKYfe37lNqjs4HmrSg5q0mW8fKq8Bes7Gx8yGIFjTBcg mYcRDAxb8NS5IgVOW5EWM6ffv2J9+hIX2kqM3pv4bUlYdfvfHAecOs/qg3kT HKbbB7K8T/WpHZs5anBnToE0bWZ1YCigAw30bnHwMgTG7QLQXapmT1XctEOu T9d13CvkmkYx2N2UcsW+vzo71XF+nAj61SaNLRBI3ZOI3aJQ2H3HPbBn78jg heJwhUnuoZHXotS5yr0N2a6R7i+V6Nz8Yy3gBtMx0TdWGEhnAlZAUCUf7q8K /NBptoYYXv14Sp8Lqc2qe38E8sqQJI7mrPDR3O3BbWuaXa+kBXgul3RYECGY eYdwrdAx9TL+rAlLKaHOkGYtAk+bgGxFphJPM3dePe/0DsOhta+BUBl56Bhd m6MmZCXdpEOPoyjOiwvo2zix2VaMHX80E0N14s1RTjr6UIkQ4okhXmlyc1Kq QZsOXjSiChtcGuSeFgHXCSs6G/TedMXSo78z51tdgrHfVrN5lsDvj97i5HNn /336/tcA73xo/Lexs0H3PwfL+98LaSalga4lFlb39/D756APnmpE1WpTMNHY gueumldJTKQT3MuYqy0yiXEZLPCqCg7GxShxBtrRqCFl1hQAqueIyFuZvR/T HWrnTqPOw/h6qYt+U5uANv88Vf/K9mvr/21vD3Z21vH+V38HXMKl/C+gaT9L Y8RMZGlR4j2pgkRO1Qe6cuJW7aMo3lwfslLTC8GiShVzgWulJs2sL/DQtPlX aCT/eTZ60Pvf2xta/jfXB4OByv9fxn8W0pT844liav1HPPN9i2VJlAtCySUT Kt5iSxaYKilOXZNS9OcVZaiog4oXMVNZQcWXJeaK0m9Htg+llPB+uangcAEK KiuHsArL8w7Km49TTCkPuL3LVAtrhNc2+EDrLaMw4HrGGIHBejJqxV+cy4Py P+LRQ57/rW/u9K38b29ukPxvLeu/LKS90EJir1k2laC+srFf9+xsPjQ4lngX lU6HXufyl7xJqJwSBnVQUtckMdpikmMYk3J4fAo6eHRYNc21xnG0TU+FG1PS D2VulBqOV2OJRmvghQ7MM4hKYOPeLXbzMj2JD07n1pOaqSNVLuXLUQOmNM1D yr+p/wvy3+/r+p/L+k+LaW5cEiTQXEtDcXXv5MXKduojbhNnN2UWnGtylCXk nBasqaq/EhPVOd5U8/9OnVAE3CZ48ZhKxRSgM7BAwZciXH+AlnLAbA9c/21r YO1/f3NjneJ//eX9r4W0ev3HT/vyM8dBlfAAgARd3mXW9vtlSrP7k2+uX0TW zpsDSAUHFI+aQxI917lmfzYd0bmqWa3Ooiov0gW12eppnpuvfFfzF+zxVzV2 Au9nwo/oIPxBrnL+pgY47nO7/5+O/2+b+N/m9sY24X/4z1L+F9H+Of/fq9zc n5ug8UjJDh4Vl366PS+QTqBg5d4QAcjaf3/cnV+5x5dXKddftAf/z7XP/E// UPuE/G9s7lj8v7NN+b+DpfwvqD0WHAUq/5jtv7cQ5Nce/PqGR2BkUZRVmQj4 mQIJlVpZJilXCbG6zaft6mqLPlqrelpPGaOSRj4mQNTqLc+ZLN30sh3PJBdd Cvbah9GkvQsX0aR+1U1PSthx6lbMlP4q637VS4u4Vc8w96LdMWnN+pGJvkdf KlO7CD26ynYG1YmJH1Hkw4f5OSXVOh5pcRNRutTcdGuqqEapNN49WUN2Gg4T 2FvN1aqgnmdiRU5ykTlQnk29bsUzd4/LmlwdrHVSDcs4k6JoEV0N1SPOVvR4 MS+3a06qTq0SjLvZZW5NLROn2kOUiy4mqrXrSe7ISj1G1RIMEcv8RKfoiKmP N49Z4pnSevBDR2c3uaTRhfSAA2RuCuqpm5y4oZnidnNP3Ezdu1eOqjsLe2FK 8tQX6N13K3pOjhy7BniuyzBU2N7SHBNJ7Y01wZ28/nl7p26A1dMdyxHH6o7l KAGIb2652Yo7ziUqosOc/qW66G/T1jBDgptizPmXkf6ESOyh638BAND2f2t9 Y2sH8f/GMv63mOZUEaxUATPVXObJvGsfPQvLnYRble9qkzUbCvC3ZcOI1JxD w1q+wJz8b5xfXGC1dZ80q/fi4urZMTu7uGJHx3gN9vIY/6gUrj2+vJqXHW5y V42trNS7cvRTpcqXTtZ8N2MBvJpCQ11hlVo5vP5ibqbzfebbndY8C+45RVG7 ttTKrP2el71rrLW6O93AGj6N++01FdmaMTtaOXtl4a55xvgHt+6lWzzrmzLz K+LSzv+O1atdPrSYfLFtylMxvH3Q+G9/c2DyP7Yw8rvM/1xgq2jLblcpcpuf Vfl3XeFXJ+8D/wWA5GehgP+5uhyDEk4ZYmhGlLZBtQPKEh/TVqH2z0SaqgHK VnjmFueudgvbcr9zr2tqi5MZPfHU3ufBJFKvjPqUHmj9pmWl+kRdSXK8DEDh XK9rEv7vVG1lW9nrkjRlC4PXumYwXZlskL0C1YnVgTk4NNADaD/j8tjXbai7 S6PZahTzHqjczCjrhuH09KKr29IyYJeKbDTpOmhTV8lQqbO2hJsOjf9/e9e6 1DaShX9bT9HjmoFQg+zYDrBLhFKEy8JUDC5gUrW/towtiGpsySvZZCZvnLeY Ppe+6GZjEpitWfXWFhOrpb6c7nPr0+czySBUys0hXC+FaxwgazIZJseb+hYG HOhzxhvKApREmOV6goBt4tPwNqRkDTg0x4wNbxwT5BM0heavwBDg1pZlIlFV zlSEWSqsbEUZR0Mk7d3wHuiMo6T2zEBNcunCPQe1kqTY+T8SOcNk9AmuobUA B/KZ2liJ/2bwX6QAwPy/3d0a//tFisL/BMRO+YeAPIXX77vglHcvpGDwxSEv EqGRPh3vU6ey2r7Xlk9lnbsY0+p8CcSB+LkrP/+DK4XIEe7Xr2h6Y85zAoeT u3oOae7vJsHvkPW+JX7By2pw/JAGUWpChsPbIJnrdG18RIiZZRJ9fe+/i028 Hz9L4jHcTMU8eZJxjtF7NKYTSeIcM0q9SF/7IPuzmH5NYgj4eYgniyko+8B+ DWvOJEaGHOkI6sQ4F8Mo+hq0HDlQOV45PzwpOE8ARAlzAnMjH/ElBvdULq0g gYdMhTYR5SXoL+2L8ST4j7RNno8FrL7/s6fzf+9R/O9evf9fpsCWFD9eBQ8h Re52Wm/EjwIXL3MG2vG5rQ7/vJwFZO/74mojGMJt5LfpYjIfzi1EYF7Rkh+s +wVgIVDpKoCfUv9/Zsv8rYo6IvkL5f9ud3dX2397FP/b69b7/0VKcf93/qkY AAhShFE+OzlUYM835zcfTvJ7Ga/2nMtV5LXpuayL8MvqRe/95fG/LXBtDQhO H5Vfu1bn0HJrJ1P3WhJlzk0ODEQ1QoEDevdBs7MeCngDIcAbS/G/HwX/jR1Z DQGemyHXlT1QPx2bvL++jf3dUMDfDUL9biCgNrVo4WnLXvOv8veZvxHdprO3 XA0hsBsKAbvBmNz07HEDPz09fX382mqhYqz+IULcxniclB1tbkx6VArNnEeU mDYKo2tIquuPwsqSXxvQJ2Y+mfmU73AIL04ChRaaCsrxZ2VBtM64tuEDGtAG 9FmjoPlGyc0NxqrT0j0mwTRPQmncj6l6n1rkgc6IjMcWpLuFQY/UXZ8glcT4 1cr/sJwelX1CepStM/tY3/KWbAzvk+FD8JYOFynxJJxNF2fcysjFHgP1Lo7p UJxdnZweNOHJPN6Hvg9ikEr37uF4nPi0mTI/ee1Dv+XwcsggfdC5J/sGjNso xuh9SKLNnnp41/ZEqWySBmkyDfK51lswewpj3ga+fw6KXm/qYeiZ/q5k9Qa8 /0zy7IqG6LwdEqkCgBwaUuCiWUwoWyVND24N/R6zc8rn3U/vqcXFxGx54uVV LLybY+HdpuQJPJ17MJtnJ+f/Ors5EM1OhxkGUoAZvJnrMRZNip2dn5r+x0yi UlqS+8yj+ANcvdf7iVafEU/v49/1dDesqp2urEq8GB+u2O+9JtMdRYbb8a2A hYCSnebgAJ3GLAkflJqMB+x3cmdG4TxjmooohGym8jWnkarao0USztU/BIS6 ThdTgYEwyvMn6bsRjMJk9DYLMdjIYAzCff6w5HSsJS42dXZ4MOXHgYo1gKzK MM/33HzEfxNM4/8DLwhiqBDBFyRly1mIwlwWiOwfmQxJucnbNwRDel4En12V 2gBJaj1fQkRR1bI2X1wkXlkwh5VsCpzT+R4d0QPdq2KPRLFLanPD6pkoDN3y ZMA5dAPDjCFJuErZ/MpKIbP1jhWJMbcBvfw14oz0V8NxGLvvF/M5WG8XccRS XdY5LqshLhdhnqwW+yxyqR5zqREkE0vym5C+CjqB1+YaDq8V4Cu+1itRmzyJ xuoxsCCjKWX74dnEXpOTe0MBhygHTR1QmaRN9bUlbD7Hac8pJ3tq8XavPbR2 wrEeJ/fVs4VQdad90j+vUIxndGz790tSSg0tzfSRrKXa5co6PjqBrOpSTNOX UuTMBTKUTb/8C/fQqsx8MCDgL9kkf7XV9PcpKl7rGc3/FfZ/Rxr+ezr/x06n g/f/duv7Py9SSuz/vZwDENJDZ/yAA6kXQASH3K4u5AjyxVEx/Cevq+qDgzZ/ r8ol0GDVMMtyK/TE11Wmvq2ZlZv2vod6c7Ud/zM7IC32XDHOwoSApLMYuBLb Rjxpnsi80wHe6ni3vvz3fDFPc0fvbNIV2vHat/52NqkSRO1wOGUO1ss+Oc+O q4X9ORqmATWRPEiblgbikERPoc2xeyEVhVGgu8syD6FW1iPcziPotlMua8vl qFxP/rUcoXYj23gu+bX4Pqu6r93QR4C+JPRfi0rkOTiTklTbZLwGtNpmXDqg UDkDgzNU6Pe2qNYkA4WplKibdhRZ23JepTaSoVTd8RSrGFdMBjllg+SAVrai E+FMNlWeSfj6Q4m1hIfzsAb6to4tSEOUi8EdfEatWrBzSj/I6m8O6jZqNk6W a84KxNPkO8WzQPD10CU+nRnUUcF3aLEQ/DLEJtu0alX1/3IuzZ+M/Zrq0VRW kP+ahpLsMySxvd9ZqfmOXE1peN1VSumy9QtTnONt9lQU169DC1guX1x691JD v7kcwOek0m7tI19zhURbc0qHl6Kk55s8uhj3ro3SItnfSVHRg4bV60ecEZTh 9zianDJGoMFTtlXA96Qb0Q6OPOycY8HOGQARoCcuXb5zofmfGRGovLAj3P4f cpnYvSUVt3J6KLJz9jk3PdVoIzQbT/SeCNt3gg70btE5oZwe2eWkTNxDdKxW WdV2A6gkXE7Gat+sdoMWW7sgUJZHGfErG6k020+iUZysY5lXNKX3uTAFX0Vq 8pvM8zJmalaQxtpoem4d6HEyTieczSgjpdI0L+os1oe7KPS9dJ7E0b3/oRTD By9uIZDCRoxeqInatEHa8tr8rtcOkcni/9fbAz29B/5B+1AK4tyiGMH/rC3a HJPeAz9xB8RVMA8TulCaaO9awNLGArzSXRberdzafYodROAmuYn0bRQlrvkm GufM0V9R138wS43cAw55/DRANHq5ECwQW/GmUynKJ4AR9YdLeV3cW3bAXN7d ZZ/z4EyFCA18FMnIu8gyXzZPaogfddoQughHHqDcFKhYPtJcvpiExebinFBo j5ybW6ohIWJlfWHAIsnlUweRuzRLl/KfgMcyUTkQormtkcaAoQfGMeZov6is qv6TIBevDfoVBCVN5ecy14e2CyHwDgY7Qpp2HgSTotpZhpSo8pNdRvT6egQw qGip7gfMF40EkNDgBGQAgGnixgJMi5MxoeptvctT6zyHiI0Q2BsByc9pkJqr d9rFCO1s22nqJ4GTa0e8Mp3Yagk9Vf1wGvCEaE6J38On+E7hsTUcWrhrTdnV 4yDTtMag7CgzUXrLwWqAEK/4c4TasdlSi5D2nORr1bUu4uibBpBFYh4BN1qG 84c+3+KwRHFc2O3h6DcXDv9Su7/4uPhEjvcpI5F224gg5DL3Eek2rDaMCj2E hQEq5Ch72mT7pNEgk9ymvMZ63S2aCryBM9YB/2YZBObrxsWplURHqZjGQfqy cU4JOn6f1f238v5/73VP3f/vdrt7lP+3vv/xIqXo/9tZO/zHHFo8KfpnoL5d VHmfFOpTeeb6pGiftWN9nEaj5BTnm4JBSoOQ+AzfNoqzVm3Ga1J+37ohsro9 6i7euf8KlPQonqbkhFKYzEr8y48LKRvg9VI9ODACNYxQ39PH1lte+5xjeZZM SHb4H3n883jWLBiMbMlkjWzr4HB5xBbZkYupexXco8czpRiAPoeyRFJcSIYf TkNtj5QEPO0Xorh045aF/N37TLKm0Of1+itKO1xOlTwhVLAZxWrJKVxMhome Ruvo2KrFAjJbSR8K6mPc+jDwZYr2yT6jCrA6/n9Hx/923yD+25tenf/7RUpR /vdyx3+Zm0E5yZ+P2s9KE3MLoBj+v+rNOvq/LnWpS13qUpe61KUudalLXepS l7rUpS51qUtdvq38Ce3tplQAyAAA ---574402316-824018871-953903204=:17770-- From R.Hildebrandt@tu-bs.de Fri Mar 24 13:55:48 2000 From: R.Hildebrandt@tu-bs.de (Ralf Hildebrandt) Date: Fri, 24 Mar 2000 14:55:48 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 In-Reply-To: <14552.20957.516043.218533@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 11:53:49PM -0500 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> Message-ID: <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> On Tue, Mar 21, 2000 at 11:53:49PM -0500, Barry A. Warsaw wrote: > > I've just uploaded the Mailman 2.0 beta 1 tarball to www.list.org. I You know what really bugs me: It's called mailman.tar.gz Why on earth can't you just encode the version in the name like everybody does -- I mean, the subdir is called mailman-2.0beta1, why not call the binary mailman-2.0beta1.tar.gz then? > decided to name the new version "2.0" because of the architectural > changes that have been made. See the excerpt from the NEWS file below > for details of what's changed since version 1.1. What happened to 1.2 ? I've got 1.1 installed, updated via CVS to mailman-1.2b1 and now we have 2.0 ? =:) -- Ralf Hildebrandt www.stahl.bau.tu-bs.de/~hildeb In brightest day, in blackest night no evil shall escape my sight! From R.Hildebrandt@tu-bs.de Fri Mar 24 15:02:09 2000 From: R.Hildebrandt@tu-bs.de (Ralf Hildebrandt) Date: Fri, 24 Mar 2000 16:02:09 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 In-Reply-To: <14552.20957.516043.218533@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 21, 2000 at 11:53:49PM -0500 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> Message-ID: <20000324160209.L16111@stahlw06.stahl.bau.tu-bs.de> On Tue, Mar 21, 2000 at 11:53:49PM -0500, Barry A. Warsaw wrote: > - cron/upvolumes_yearly, cron/upvolumes_monthly, cron/archive, > cron/run_queue all removed. Edit your crontab if you used these > scripts. Other scripts removed: contact_transport, deliver, > dumb_deliver. I did't see that mentioned in UPGRADING -- Ralf Hildebrandt www.stahl.bau.tu-bs.de/~hildeb "The percentage of users running Windows NT Workstation 4.0 whose PCs stopped working more than once a month was less than half that of Windows 95 users."-- microsoft.com/ntworkstation/overview/Reliability/Highest.asp From tal@research.bell-labs.com Fri Mar 24 17:53:00 2000 From: tal@research.bell-labs.com (Tom Limoncelli) Date: Fri, 24 Mar 2000 12:53:00 -0500 Subject: [Mailman-Developers] Re: Mailman 2.0 beta 1 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> Message-ID: <38DBAB7C.D8544ED2@research.bell-labs.com> Ralf Hildebrandt wrote: > Why on earth can't you just encode the version in the name like everybody > does -- I mean, the subdir is called mailman-2.0beta1, why not call the > [...tar file...] mailman-2.0beta1.tar.gz then? That's yet another reason to prefer GNU software to commericial stuff like mailman. GNU has a standard for the name of tar files: http://www.gnu.org/prep/standards_48.html#SEC48 "Package the distribution of Foo version 69.96 up in a gzipped tar file with the name `foo-69.96.tar.gz'. It should unpack into a subdirectory named `foo-69.96'. Have a great weekend everyone! --tal P.S. YES, I WAS KIDDING WHEN I SAID MAILMAN WAS COMMERCIAL SOFTWARE! From R.Hildebrandt@tu-bs.de Fri Mar 24 17:59:56 2000 From: R.Hildebrandt@tu-bs.de (Ralf Hildebrandt) Date: Fri, 24 Mar 2000 18:59:56 +0100 Subject: [Mailman-Developers] Re: Mailman 2.0 beta 1 In-Reply-To: <38DBAB7C.D8544ED2@research.bell-labs.com>; from tal@research.bell-labs.com on Fri, Mar 24, 2000 at 12:53:00PM -0500 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> <38DBAB7C.D8544ED2@research.bell-labs.com> Message-ID: <20000324185956.D16111@stahlw06.stahl.bau.tu-bs.de> On Fri, Mar 24, 2000 at 12:53:00PM -0500, Tom Limoncelli wrote: > > Why on earth can't you just encode the version in the name like everybody > > does -- I mean, the subdir is called mailman-2.0beta1, why not call the > > [...tar file...] mailman-2.0beta1.tar.gz then? > > http://www.gnu.org/prep/standards_48.html#SEC48 > > > "Package the distribution of Foo version 69.96 up in a gzipped > tar file with the name `foo-69.96.tar.gz'. It should unpack into > a subdirectory named `foo-69.96'. > I rest my case :) -- Ralf Hildebrandt www.stahl.bau.tu-bs.de/~hildeb From bwarsaw@cnri.reston.va.us Fri Mar 24 19:20:56 2000 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Fri, 24 Mar 2000 14:20:56 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> Message-ID: <14555.49176.232075.433045@anthem.cnri.reston.va.us> >>>>> "RH" == Ralf Hildebrandt writes: RH> You know what really bugs me: It's called mailman.tar.gz Try http://www.list.org/mailman-2.0beta1.tgz. mailman.tar.gz is just symlinked to this (or whatever the latest tarball is). This works better for people who have automated scripts that suck distributions down because they don't have to change their script each time. You can even get older tarballs if you decode the naming scheme and guess at a URL. :) RH> What happened to 1.2 ? I've got 1.1 installed, updated via CVS RH> to mailman-1.2b1 and now we have 2.0 ? =:) Sounds like you're not on mailman-developers. Read this. http://www.python.org/pipermail/mailman-developers/2000-March/001911.html -Barry From dan.mick@West.Sun.COM Fri Mar 24 20:42:48 2000 From: dan.mick@West.Sun.COM (Dan Mick) Date: Fri, 24 Mar 2000 12:42:48 -0800 Subject: [Mailman-Developers] Re: [Mailman-Announce] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.0 beta 1 References: <14552.20957.516043.218533@anthem.cnri.reston.va.us> <20000324145548.J16111@stahlw06.stahl.bau.tu-bs.de> <14555.49176.232075.433045@anthem.cnri.reston.va.us> Message-ID: <38DBD348.EA505876@west.sun.com> bwarsaw@cnri.reston.va.us wrote: > > >>>>> "RH" == Ralf Hildebrandt writes: > > RH> You know what really bugs me: It's called mailman.tar.gz > > Try http://www.list.org/mailman-2.0beta1.tgz. mailman.tar.gz is just > symlinked to this (or whatever the latest tarball is). This works > better for people who have automated scripts that suck distributions > down because they don't have to change their script each time. You > can even get older tarballs if you decode the naming scheme and guess > at a URL. :) A gracious response to a pretty ungrateful complaint... Chill, Ralf, and make sure you've got a leg to stand on... From ricardo@rixhq.nu Fri Mar 24 22:36:02 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Fri, 24 Mar 2000 23:36:02 +0100 Subject: [Mailman-Developers] subscription approval Message-ID: <20000324233602.C18958@miss-janet.com> Hi, Today I was subscribing to a list on securityportal.com, which is running LISTSERV... and then I noticed they have a nice way of approving your subscription: you can visit and URL which contains a unique hash that authorizes your request. actually I've been using the same technique for a chatroom signup procedure on our website and it's fairly easy to make... (since i was able to make it ;) ) the big plus of this is that if most of your list subscribers aren't too technical, it's much easier for them to subscribe... anybody can click on the link which their microsoft or AOL browser conviently convert to a hyperlink... (too often I see mails send to the admin with texts like "hi.. my auth code is 923482.. please subscribe me") this could also make unsubscribing very easy... just add a link at the bottom of the mail... and once visited the user gets the choice to unsubscribe (with or without supplying a password?) anyway, i know this wont make it to 2.0, but I hope this could be a nice feature for the next version... Ricardo. -- From thomas@xs4all.net Fri Mar 24 22:57:27 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 24 Mar 2000 23:57:27 +0100 Subject: [Mailman-Developers] admin approval and list archive Message-ID: <20000324235727.K12922@xs4all.nl> --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii There seems to be a bug in the pipermail archiving in combination with admin aproved messages. The bug is that, in the archive mbox, 'From ' lines will be missing from messages which have been passed through admin approval, which means that they will be considered part of the previous message or, if there is no previous message, that the mbox is invalid and no archive will be built. This happens because of one or two buglets, one in the mailbox standard module, and one possibly in the rfc822 module or otherwise in Mailman. When holding a message, the code uses 'str(msg)' (where msg is a rfc822.Message instance) to dump the pending message to a file. Unfortunately, rfc822.Message.__str__() only dumps the normal mail headers and the body, and *not* the 'From ' line, which is stored in rfc822.Message.unixfrom. I dont really think that is a bug in the rfc822 module, as the 'From ' line is not rfc822 but a sendmail (i think) addon for its own use, but it needs to be worked around in any case. The simple fix is attached. In the course of tracking this bug I also found out that the mailbox standard module drops the 'From ' line entirely, before it passes the message to the rfc822.Message constructor. At first I thought that this caused the problem, but now I'm not entirely sure, and I'm not in a position to test it at the moment. This is a bug though, but not in Mailman, and I already sent a fix for it to the python patches list. If anyone is willing to test this, and the above fix doesn't work on its own, grab the mailbox.py fix from the patches mailarchive. And, er, my apologies for this large a rant on this small a bug, it's late and I'm overworked, not spending enough time with python ;) PS: there'll probably be some offset in this patch, my cvs tree is still cluttered with unshared hacks ;) even if it fails, though, I'm confident most people will be able to apply it by hand ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cvsdiff Index: Mailman/ListAdmin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/ListAdmin.py,v retrieving revision 1.28 diff -u -r1.28 ListAdmin.py --- ListAdmin.py 2000/03/21 06:24:59 1.28 +++ ListAdmin.py 2000/03/24 22:51:54 @@ -139,7 +145,7 @@ omask = os.umask(002) try: fp = open(os.path.join(mm_cfg.DATA_DIR, filename), 'w') - fp.write(str(msg)) + fp.write(msg.unixfrom + str(msg)) fp.close() finally: os.umask(omask) --BwCQnh7xodEAoBMC-- From thomas@xs4all.net Fri Mar 24 23:27:01 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 25 Mar 2000 00:27:01 +0100 Subject: [Mailman-Developers] lock lifetime In-Reply-To: <14553.6564.572812.203295@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Wed, Mar 22, 2000 at 02:06:12PM -0500 References: <20000322193038.A10212@miss-janet.com> <14553.6564.572812.203295@anthem.cnri.reston.va.us> Message-ID: <20000325002701.A25139@xs4all.nl> On Wed, Mar 22, 2000 at 02:06:12PM -0500, Barry A. Warsaw wrote: > RK> "... In any case, you can easily try it out; in > RK> Mailman/MailList.py, on or around line 282, there should be a > RK> 'lifetime = 60', inside the constructor for the maillists' > RK> lockfile. Changing the '60' in, say, '600', should give you > RK> better mileage, at least until your machine gets so heavily > RK> loaded that a simple admin request takes ten full minutes to > RK> process ;) " > One other gotcha, if you use bin/withlist to open a locked list and > then exit the interpreter without doing an explicit m.Unlock(), you're > list will be locked out for the duration. Not only if you use that tool, but if you use any tool or script that doesn't clean up after itself ;) Granted, using bin/withlist it's a lot easier, but I think a note on upsides/downsides in either the FAQ or next to the timeout setting would be appropriate. 'set too low, a slow machine might give timeout erors, but set too high, a faulty script can prevent the list from being used for that long.' (But then, i'm all for longer explanations in the FAQ and the online help, i just haven't got the time to write them, yet ;) While i'm on that subject, by the way, what are other peoples' thoughts on this issue ? Should there be more helpfiles and/or online help ? :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jwt@dskk.co.jp Sat Mar 25 08:41:41 2000 From: jwt@dskk.co.jp (Jim Tittsler) Date: Sat, 25 Mar 2000 17:41:41 +0900 Subject: [Mailman-Developers] Bouncers/Exim.py Message-ID: <20000325174141.A13388@mail.dskk.co.jp> --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Exim adds a header to bounce messages that might be used to catch the bounced addresses, rather than trying to parse the message text. I've been using this trivial bouncer for a while with my 1.2CVS installation and it seems to be doing the right thing. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/ --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Exim.py" # Exim bouncer module for Mailman """Parse bounce messages generated by Exim. Exim adds an X-Failed-Recipients: header to bounce messages containing an "addresslist" of failed addresses. """ def process(mlist, msg): # return just the route-address elements of the addresslist addrs = map(lambda x: x[1], msg.getaddrlist('X-Failed-Recipients')) return addrs or None --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="BouncerAPI.diff" *** BouncerAPI.py.orig Sat Mar 25 17:17:54 2000 --- BouncerAPI.py Sat Mar 25 17:32:19 2000 *************** *** 38,41 **** --- 38,42 ---- 'Qmail', 'Postfix', + 'Exim', 'Yahoo', 'Caiwireless', --1yeeQ81UyVL57Vl7-- From ricardo@rixhq.nu Sat Mar 25 11:51:59 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 25 Mar 2000 12:51:59 +0100 Subject: [Mailman-Developers] rfc822.Message In-Reply-To: <20000324235727.K12922@xs4all.nl>; from thomas@xs4all.net on Fri, Mar 24, 2000 at 11:57:27PM +0100 References: <20000324235727.K12922@xs4all.nl> Message-ID: <20000325125159.A20826@miss-janet.com> I've made some changes in my copy of Mailman to split the message body from the header in admindb.py. This makes it much easier to browse through the held messages. It works perfectly, except for the fact that I haven't found a way yet to limit the number of lines displayed to ADMINDB_PAGE_TEXT_LIMIT... can anybody help me with this? the code i'm using is: fp = open(os.path.join(mm_cfg.DATA_DIR, filename)) fullmsg = Message.Message(fp) msg_header = string.join(fullmsg.headers, '') msg_body = fullmsg.body fp.close() You can see a result of how it looks at http://rixhq.nu/mm/admindb.png The "send copy" isn't functional yet though -- I had it working on the previous version of Mailman, but I'm not sure yet how to implement it with the new posting methods in MM. Also, I've made some small changes that move the heldmsg output to a seperate template, so I have more control on the layout of the output and it makes to code a bit more readable :) Ricardo. -- From jcrey@uma.es Mon Mar 27 06:54:39 2000 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Mon, 27 Mar 2000 08:54:39 +0200 Subject: [Mailman-Developers] French traduction of the templates References: Message-ID: <38DF05AF.AF61B69A@uma.es> "Matthieu CAMUS (IUP MIME - 96000937)" wrote: > > For the needs of a project I used mailman. I have done the french > traduction of the templates files in the /etc/mailman directory. > > I don't know how to do the traduction in the others files (eg *.py). > There is a special function named get-text or something like that for > the python's files ? > There is already one person doing translation of mailman in frech but it is true that I have not notice of the actual status of french translation long ago. At any rate, I send apart spanish catalog so you can start translating. > Joined to this email the tar.gz of my traduction. To translate accordingly templates, the i18n version ones must be done. I also send you modified i18n templates. Cheers -- ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de informática | | Universidad de Málaga - España | #----------------------------------------------# # Solo se que cada vez se menos :-| # #----------------------------------------------# From Nigel.Metheringham@VData.co.uk Mon Mar 27 08:45:47 2000 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: Mon, 27 Mar 2000 09:45:47 +0100 Subject: [Mailman-Developers] Post to every list, just in case... Message-ID: Having been away for a few days I've experienced a sense of things repeating on a short loop whilst reading my mail this morning. One particular thread was cross posted over 3 different mailman lists, although it appears to have been moderated out of one of them at least. So would it be possible for list people to have a little more discipline regarding the posting of messages across lists. Additionally do we need to consider:- 1. Hierarchical lists - ie moderated announce lists that post into other lists, with decent support for building a union of subscribers - maybe rather than subscribing x-users & x-developers to ax-nnounce, a way of telling the list to pull in these lists' subscribers too. 2. Filtering on lists to detect cross posting and do something... 3. An idea of what "something" should be :-) Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] From thomas@xs4all.net Mon Mar 27 18:53:07 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 27 Mar 2000 20:53:07 +0200 Subject: [Mailman-Developers] Re: admin approval and list archive In-Reply-To: <20000324235727.K12922@xs4all.nl>; from thomas@xs4all.net on Fri, Mar 24, 2000 at 11:57:27PM +0100 References: <20000324235727.K12922@xs4all.nl> Message-ID: <20000327205307.E25139@xs4all.nl> --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii On Fri, Mar 24, 2000 at 11:57:27PM +0100, Thomas Wouters wrote: > There seems to be a bug in the pipermail archiving in combination with admin > aproved messages. The bug is that, in the archive mbox, 'From ' lines will > be missing from messages which have been passed through admin approval, > which means that they will be considered part of the previous message or, if > there is no previous message, that the mbox is invalid and no archive will > be built. I've been able to test it properly now... the mailbox.py bug wrt unixfrom is unrelated (but still a bug, imho) and just this diff (attached again) is enough to fix Mailman. Since msg.unixfrom is '' if unixfrom isn't set, this shouldn't break a thing. Regards, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cvsdiff Index: Mailman/ListAdmin.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/ListAdmin.py,v retrieving revision 1.28 diff -u -r1.28 ListAdmin.py --- ListAdmin.py 2000/03/21 06:24:59 1.28 +++ ListAdmin.py 2000/03/24 22:51:54 @@ -139,7 +145,7 @@ omask = os.umask(002) try: fp = open(os.path.join(mm_cfg.DATA_DIR, filename), 'w') - fp.write(str(msg)) + fp.write(msg.unixfrom + str(msg)) fp.close() finally: os.umask(omask) --sdtB3X0nJg68CQEu-- From thomas@xs4all.net Mon Mar 27 19:15:02 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 27 Mar 2000 21:15:02 +0200 Subject: [Mailman-Developers] pipermail/hypermail mbox-archive Message-ID: <20000327211501.F25139@xs4all.nl> --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii There was a short discussion a month or so ago about the hyperarch 'mbox' archives having the wrong kind of date in the 'From ' lines... 'unixfrom' lines should have a very specific dateformat, namely that which 'time.ctime' returns. The following patch fixes Archiver/HyperArch.py. However, I'm not entirely sure if it will work correctly in other locales... can anyone test that, and propose a locale-independant way of producing this format ? Grtz, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="HyperArch.py.diff" Index: Mailman/Archiver/HyperArch.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Archiver/HyperArch.py,v retrieving revision 1.16 diff -u -r1.16 HyperArch.py --- HyperArch.py 2000/03/21 06:25:10 1.16 +++ HyperArch.py 2000/03/27 19:08:04 @@ -64,7 +64,7 @@ article_text_template="""\ -From %(email)s %(datestr)s +From %(email)s %(fromdate)s Date: %(datestr)s From: %(author)s %(email)s Subject: %(subject)s @@ -154,6 +154,7 @@ # subject : Subject # datestr : The posting date, in human-readable format # date : The posting date, in purely numeric format +# fromdate : The posting date, in 'unixfrom' format # headers : Any other headers of interest # author : The author's name (and possibly organization) # email : The author's e-mail address @@ -242,7 +243,7 @@ date=time.mktime(date)-tzoffset else: date=self.__last_article_time+1 - + self.fromdate = time.ctime(date) self.__last_article_time=date self.date='%011i' % (date,) --i9LlY+UWpKt15+FH-- From bwarsaw@cnri.reston.va.us Tue Mar 28 17:12:00 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 28 Mar 2000 12:12:00 -0500 (EST) Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries Message-ID: <14560.59360.933438.313871@anthem.cnri.reston.va.us> Last night, I added some code to queue messages that fail delivery when using SMTPDirect. What happens is this: If a message either totally fails delivery (e.g. the smtp socket connect fails) or partial delivery fails for some, but not all, recipients, then the message is stored on the file system for a re-try later. For every failed message, two files are created. The base name of these files is the SHA hexdigest dump of the message text. This should be nearly guaranteed unique. A new directory contains these files, called `qfiles'. The first file created is the complete plain text of the failed message. The second file is a marshal of useful information related to the failed delivery. This contains the listname and the failed recip list along with a few other moderately useful bits of info. There's a new cron script called `qrunner' which cruise the files in qfiles. It claims a lock (to prevent multiple qrunner processes) and then goes through each file it finds, attempting redelivery. If there are any problems reading a qfile file, it skips it for next time (assumes it's a transient problem with the file, but logs a message). When qrunner notices that the message has been handed off the the smtp daemon for all outstanding recipients, it deletes the two message files. I've moderately tested this stuff with total delivery failure by shutting off my smtp daemon, attempting some deliveries, turning it back on and running qrunner. I don't have the time right now to test partial delivery failures, but I still claim that without DSN support, these will be unlikely. Hopefully some of you can help look at this. I'm about to check all this stuff in. Let me know what you think. -Barry From thomas@xs4all.net Tue Mar 28 19:36:35 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 28 Mar 2000 21:36:35 +0200 Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries In-Reply-To: <14560.59360.933438.313871@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 28, 2000 at 12:12:00PM -0500 References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> Message-ID: <20000328213635.A8665@xs4all.nl> On Tue, Mar 28, 2000 at 12:12:00PM -0500, Barry A. Warsaw wrote: > I'm about to check all this stuff in. Let me know what you think. I'll see if I can do some checks on partial delivery failure tomorrow. (I really need to get myself a seperate box for testing ;) But, assides from delivery, it might be useful to store messages which failed elsewhere in the pipeline too; messages in the archive pipe, for instance, or the usenet pipe. It can currently happen, for instance because of a deadlock, that messages just get lost. I haven't looked at the new code yet, but imho it shouldn't be too hard to push messages back into those pipelines, assuming they fail 'cleanly' (and not with files half-written or some such.) (Then again, I haven't seen failures at all, yet, so I'm not too worried for myself.) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From bwarsaw@cnri.reston.va.us Tue Mar 28 20:00:18 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 28 Mar 2000 15:00:18 -0500 (EST) Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> Message-ID: <14561.3922.358917.646194@anthem.cnri.reston.va.us> >>>>> "TW" == Thomas Wouters writes: TW> But, assides from delivery, it might be useful to store TW> messages which failed elsewhere in the pipeline too; messages TW> in the archive pipe, for instance, or the usenet pipe. It can TW> currently happen, for instance because of a deadlock, that TW> messages just get lost. I haven't looked at the new code yet, TW> but imho it shouldn't be too hard to push messages back into TW> those pipelines, assuming they fail 'cleanly' (and not with TW> files half-written or some such.) That's actually a good idea. I think a wrapper around the pipeline loop, perhaps using a bare try/except (hmm...) is the way to go. What you'd probably have to do is have a checklist of delivery modules so you know 1) which ones you wanted to send the message through; 2) which ones failed. And then to know what the disposal is for a message that failed at a particular step. Definitely more complicated, but worth thinking about. Robustifying message delivery should be very high on the list, but for 2.0 final we'll have to find a happy compromise. TW> (Then again, I haven't seen failures at all, yet, so I'm not TW> too worried for myself.) Me neither! :) -Barry From thomas@xs4all.net Tue Mar 28 21:14:00 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 28 Mar 2000 23:14:00 +0200 Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries In-Reply-To: <14561.3922.358917.646194@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Tue, Mar 28, 2000 at 03:00:18PM -0500 References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> <14561.3922.358917.646194@anthem.cnri.reston.va.us> Message-ID: <20000328231400.B8665@xs4all.nl> On Tue, Mar 28, 2000 at 03:00:18PM -0500, Barry A. Warsaw wrote: > >>>>> "TW" == Thomas Wouters writes: > TW> But, assides from delivery, it might be useful to store > TW> messages which failed elsewhere in the pipeline too; messages > TW> in the archive pipe, for instance, or the usenet pipe. It can > TW> currently happen, for instance because of a deadlock, that > TW> messages just get lost. I haven't looked at the new code yet, > TW> but imho it shouldn't be too hard to push messages back into > TW> those pipelines, assuming they fail 'cleanly' (and not with > TW> files half-written or some such.) > That's actually a good idea. I think a wrapper around the pipeline > loop, perhaps using a bare try/except (hmm...) is the way to go. What > you'd probably have to do is have a checklist of delivery modules so > you know 1) which ones you wanted to send the message through; 2) > which ones failed. And then to know what the disposal is for a > message that failed at a particular step. Definitely more > complicated, but worth thinking about. Robustifying message delivery > should be very high on the list, but for 2.0 final we'll have to find > a happy compromise. How about a simple try/except in those two areas ? They are pretty isolated, and you can add the try/except and restart-delivery code just after the forks those portions do. (no need for the queuerunner to fork, i guess... but it could, if necessary.) Actually, I think I'll post a diff tomorrow morning, after I have some time to think 'bout it ;) I already see one problem though: the new code eats the unixfrom line the same way moderation does, screwing up the archives: # calculate a unique name for this file text = str(msg) filebase = sha.new(text).hexdigest() msgfile = os.path.join(mm_cfg.QUEUE_DIR, filebase + '.msg') 'str(msg)' will not dump the unixfrom line, (unless you want to fix this in Mailman.Message.Message) so you need to use 'text = msg.unixfrom + str(msg)'. See the patch i sent uhm, sometime this weekend. Also, one of the comments in qrunner seems to be too literally copy/pasted from cron/gate_news ;) Rgdrs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Thu Mar 30 12:08:43 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 30 Mar 2000 14:08:43 +0200 Subject: [Mailman-Developers] Re-tries for failed SMTPDirect deliveries In-Reply-To: <20000328231400.B8665@xs4all.nl>; from thomas@xs4all.net on Tue, Mar 28, 2000 at 11:14:00PM +0200 References: <14560.59360.933438.313871@anthem.cnri.reston.va.us> <20000328213635.A8665@xs4all.nl> <14561.3922.358917.646194@anthem.cnri.reston.va.us> <20000328231400.B8665@xs4all.nl> Message-ID: <20000330140842.G13073@xs4all.nl> On Tue, Mar 28, 2000 at 11:14:00PM +0200, Thomas Wouters wrote: > On Tue, Mar 28, 2000 at 03:00:18PM -0500, Barry A. Warsaw wrote: [ about the new queueing of failed message, and implementing that also in ] [ ToArchive and ToUsenet ] > Actually, I think I'll post a diff tomorrow morning, after I have some time > to think 'bout it ;) Well, I didn't make next morning, and I'm still thinking about it. Should it be integrating with the pipeline architecture, or module-specific ? I mean, it could be done two ways: - inside each 'process' function for every module that might want to requeue, in the form of def process(mlist, msg): try: except TemporaryFailure: Utils.queue_message(mlist, msg, re-injection point) and a def reprocess(mlist, msg): most process()es can probably just call reprocess() after some basic checking, forking, message-header-editing, etc. reprocess() should raise TemporaryFailure, but not catch it itself -- the queue runner should catch it, and update the pickled state for that message. - inside the pipeline structure, in the pipeline delivery. This would require all handlers to have a reprocess() function, but most (those that will never raise TemporaryFailure) can have it just 'pass'. (Or perhaps just leave them out... that would raise AttributeError when the impossible happens, instead of silently vanishing messages) The pipeline itself would catch TemporaryFailure, and queue the messages not only with the list, message and what pipeline segment it broke at, but also the rest of the pipeline still to be traversed. Might prove a bit more tricky, but it's a lot more elegant if more than a few modules support the queueing interface :P Comments welcome, but I'm off for a long weekend Rome, I wont be back until tuesday, and I wont read my mail in between ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From elephant@pld.org.pl Thu Mar 30 15:23:26 2000 From: elephant@pld.org.pl (Marek Obuchowicz) Date: Thu, 30 Mar 2000 17:23:26 +0200 (CEST) Subject: [Mailman-Developers] A suggestion Message-ID: Hi! Sorry if i am writing to wrong address, but i couldn't find a better one :) I couldn't find the possibility of removing headers in mailman. Removing 'Recieved' headers is ofen used by majordomo users (like me in the past). I host one list and I'd like to hide senders' Message-Id. How can I do it? Greets, Marek -- __ Marek "Suonik" Obuchowicz, elephant@pld.org.pl /'_)___ Member of GNU generation, PLD project and "H" ( \ ____|\ http://www.projcom.com.pl/ http://www.pld.org.pl/ // || Home Page: http://suonik.art.pl/ (pgp-key is there) From claw@kanga.nu Thu Mar 30 18:27:47 2000 From: claw@kanga.nu (J C Lawrence) Date: Thu, 30 Mar 2000 10:27:47 -0800 Subject: [Mailman-Developers] A suggestion In-Reply-To: Message from Marek Obuchowicz of "Thu, 30 Mar 2000 17:23:26 +0200." References: Message-ID: <13331.954440867@kanga.nu> On Thu, 30 Mar 2000 17:23:26 +0200 (CEST) Marek Obuchowicz wrote: > I couldn't find the possibility of removing headers in mailman. > Removing 'Recieved' headers is ofen used by majordomo users (like > me in the past). I host one list and I'd like to hide senders' > Message-Id. Eeek! Bad! Bad! > How can I do it? Use a procmail filter inserted before the mailman script invocations. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=-- From bwarsaw@cnri.reston.va.us Thu Mar 30 16:31:26 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 30 Mar 2000 11:31:26 -0500 (EST) Subject: [Mailman-Developers] A suggestion References: Message-ID: <14563.33118.561356.947439@anthem.cnri.reston.va.us> >>>>> "MO" == Marek Obuchowicz writes: MO> I couldn't find the possibility of removing headers in MO> mailman. Removing 'Recieved' headers is ofen used by MO> majordomo users (like me in the past). I host one list and MO> I'd like to hide senders' Message-Id. How can I do it? Header filtering is not supported through the web interface, but Mailman 2.0 (of which beta1 is currently released) will provide a very simple way for you to add such functionality. You can drop a handler module into Mailman/Handlers which will strip out the headers you don't care about. See Mailman/Handlers/Cleanse.py for an example. -Barry From ttsoares@cedep.ifch.ufrgs.br Fri Mar 31 17:51:52 2000 From: ttsoares@cedep.ifch.ufrgs.br (Thomas Tschoepke Soares) Date: Fri, 31 Mar 2000 14:51:52 -0300 (EST) Subject: [Mailman-Developers] About MailMan site... Message-ID: Hi! I am trying to install mailman here but there are some problems... So, I have been trying to download the newer beta version but the domain www.list.org even resolv at a ping command! Could you provide an alternative place from where to get this prog? Or, even better, how about to include it in the sourceforge portal? Thank you, regards Thomas. | Thomas Tschoepke Soares | // Mate do | ttsoares@cedep.ifch.ufrgs.br |(~~~//~~) estrivo bendito! |--UIN:961141-------------------------------| \ / Amargo que |The fact is a secondary aspect of reality. | `_/' a gente bebe... From dan.mick@West.Sun.COM Fri Mar 31 20:26:16 2000 From: dan.mick@West.Sun.COM (Dan Mick) Date: Fri, 31 Mar 2000 12:26:16 -0800 Subject: [Mailman-Developers] About MailMan site... References: Message-ID: <38E509E8.71ADD992@west.sun.com> Thomas Tschoepke Soares wrote: > I am trying to install mailman here but there are some problems... > > So, I have been trying to download the newer beta version but the domain > www.list.org even resolv at a ping command! This is surely a transient failure; www.list.org has been pretty reliable for me. But you're right; I can't get DNS for it either, and I can't ping its nameservers. The technical contact for the domain is aware and is working on the problem; they have a network outage. From ricardo@rixhq.nu Fri Mar 31 21:13:14 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Fri, 31 Mar 2000 23:13:14 +0200 Subject: [Mailman-Developers] suggestion Message-ID: <20000331231314.B4174@miss-janet.com> Hi, How about moving things like the list welcome message, headers, footers and other multiple line texts out of the database and into seperate text files? And treat/edit them in the same way as the html templates... this would it also make it easier to edit them directly. I remember having a lot of difficulties (when I started using mailman about a year ago) with creating the welcome message because the textarea was too small and strange things happened when i cut/pasted it into the textarea with Netscape on Linux (I had to boot windows just to be able to enter the welcome message properly ;) ) Ricardo. -- From bigdog@dogpound.vnet.net Fri Mar 31 21:28:25 2000 From: bigdog@dogpound.vnet.net (Matt Davis) Date: Fri, 31 Mar 2000 16:28:25 -0500 (EST) Subject: [Mailman-Developers] suggestion In-Reply-To: <20000331231314.B4174@miss-janet.com> Message-ID: On Fri, 31 Mar 2000, Ricardo Kustner wrote: > How about moving things like the list welcome message, headers, footers > and other multiple line texts out of the database and into seperate > text files? And treat/edit them in the same way as the html templates... > this would it also make it easier to edit them directly. > I remember having a lot of difficulties (when I started using mailman > about a year ago) with creating the welcome message because the textarea > was too small and strange things happened when i cut/pasted it into the > textarea with Netscape on Linux (I had to boot windows just to be able > to enter the welcome message properly ;) ) I agree. But maybe have both available. As in, the web page grabs the info from the txt files and allows you to edit via the web interface or directly from the txt files. -- Matt Davis - ICQ# 934680 http://dogpound.vnet.net/ NoWonder UNIX Tech - http://www.nowonder.com Madness takes it's toll, please have exact change From dan.mick@West.Sun.COM Fri Mar 31 22:27:08 2000 From: dan.mick@West.Sun.COM (Dan Mick) Date: Fri, 31 Mar 2000 14:27:08 -0800 Subject: [Mailman-Developers] suggestion References: Message-ID: <38E5263C.8763377F@west.sun.com> Matt Davis wrote: > > On Fri, 31 Mar 2000, Ricardo Kustner wrote: > > > How about moving things like the list welcome message, headers, footers > > and other multiple line texts out of the database and into seperate > > text files? And treat/edit them in the same way as the html templates... > > this would it also make it easier to edit them directly. > > I remember having a lot of difficulties (when I started using mailman > > about a year ago) with creating the welcome message because the textarea > > was too small and strange things happened when i cut/pasted it into the > > textarea with Netscape on Linux (I had to boot windows just to be able > > to enter the welcome message properly ;) ) > > I agree. But maybe have both available. As in, the web page grabs the > info from the txt files and allows you to edit via the web interface or > directly from the txt files. Thirded, bigtime. Such "obvious changers" should be RCSed, for instance, and there's no easy way to do that with the current scheme. I keep threatening, although I haven't yet, to set up a script that will "check out text, allow editing, check it back in, and invoke Python to shove it into config.db". (that's actually pretty easy to do; just open the file and set "m.welcome_msg" from it, for the welcome, for instance..) From ricardo@rixhq.nu Fri Mar 31 22:54:16 2000 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 1 Apr 2000 00:54:16 +0200 Subject: [Mailman-Developers] suggestion In-Reply-To: ; from bigdog@dogpound.vnet.net on Fri, Mar 31, 2000 at 04:28:25PM -0500 References: <20000331231314.B4174@miss-janet.com> Message-ID: <20000401005416.A760@miss-janet.com> On Fri, Mar 31, 2000 at 04:28:25PM -0500, Matt Davis wrote: > > How about moving things like the list welcome message, headers, footers > > and other multiple line texts out of the database and into seperate > > text files? And treat/edit them in the same way as the html templates... > > this would it also make it easier to edit them directly. > I agree. But maybe have both available. As in, the web page grabs the > info from the txt files and allows you to edit via the web interface or > directly from the txt files. Yes that's actually what I was thinking about too... but have it editted in the same way as the html templates (one page with a big textarea to give more editting freedom). Ricardo. --