From sguner@online.emich.edu Mon Oct 1 14:35:59 2001 From: sguner@online.emich.edu (sguner@online.emich.edu) Date: Mon, 01 Oct 2001 09:35:59 -0400 (EDT) Subject: [Mailman-Developers] registered Message-ID: <1001943359.3bb8713fcf0d4@webmail.emich.edu> I have registered under the name Turkiye@list.emich.edu. I was wondering what I do next. How do I retrieve this account? Could you please guide me step by step. Password is eastern. Thank you Sinem Guner Eastern Michigan University From liuk@publinet.it Tue Oct 2 12:29:35 2001 From: liuk@publinet.it (Luca Maranzano) Date: Tue, 2 Oct 2001 13:29:35 +0200 Subject: [Mailman-Developers] Which version of mimelib with latest CVS? Message-ID: <20011002132935.A31409@publinet.it> Hi, just a quick question: which version of mimelib is necessary to use latest (this morning) CVS of MM ? I'm currently using 0.4. TIA, Luca From barry@zope.com Tue Oct 2 14:24:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Oct 2001 09:24:46 -0400 Subject: [Mailman-Developers] Which version of mimelib with latest CVS? References: <20011002132935.A31409@publinet.it> Message-ID: <15289.49182.877382.777080@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> just a quick question: which version of mimelib is necessary LM> to use latest (this morning) CVS of MM ? I'm currently using LM> 0.4. Oops, sorry, I meant to send an email out about this. ;} Go to the misc directory and install the email-0.90.tar.gz distutils package. I will update the INSTALL file asap. mimelib was a prototype and has been integrated into the Python 2.2 standard library. Its name was changed to the "email" package, and the API was made more consistent, but that required changes. If you're running Python 2.2 (who is? :) you don't need to install the standalone email package. For anything else, email-0.90 is a version ported to earlier Python 2.x. -Barry From aturner@pobox.com Tue Oct 2 19:00:14 2001 From: aturner@pobox.com (Aaron D. Turner) Date: Tue, 2 Oct 2001 11:00:14 -0700 (PDT) Subject: [Mailman-Developers] What to do with a corrupt config.db? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems all the config.db's (and their .last's) for all my lists are now corrupt. At least check_db says so. Since there doesn't seem to be anyway to fix this, perhaps there is a way to extract the email addresses/passwords for the lists so I can recover? I'm more than willing/able to write a perl script to parse it out, if I just knew the file format (though i can prolly get the email addresses out without much difficulty). Anyone have any thoughts/suggestions? Thanks. - -- Aaron Turner URI:www.synfin.net They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin pub 1024D/F86EDAE6 Sig: 3167 CCD6 6081 0FFC B749 9A8F 8707 9817 F86E DAE6 All emails by me are PGP signed; a lack of a signature indicates a forgery. I have retired my PGP 2.6.2 key: FBE1 CEED 57E4 AB80 596E 60BF 451B 20E8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Public key at: http://www.synfin.net/aturner/pgpkey.asc iEYEARECAAYFAju6ALQACgkQhweYF/hu2uZ8wACeMzlq++UjA3zuMhSEvsc9McUp HqcAn0gD4ywicbKxyRF4/Ihg2T6bq45I =uSaH -----END PGP SIGNATURE----- From claw@2wire.com Tue Oct 2 21:25:47 2001 From: claw@2wire.com (J C Lawrence) Date: Tue, 02 Oct 2001 13:25:47 -0700 Subject: [Mailman-Developers] What to do with a corrupt config.db? In-Reply-To: Message from "Aaron D. Turner" of "Tue, 02 Oct 2001 11:00:14 PDT." References: Message-ID: <30166.1002054347@2wire.com> On Tue, 2 Oct 2001 11:00:14 -0700 (PDT) Aaron D Turner wrote: > It seems all the config.db's (and their .last's) for all my lists > are now corrupt. At least check_db says so. Since there doesn't > seem to be anyway to fix this, perhaps there is a way to extract > the email addresses/passwords for the lists so I can recover? I'd be far more worried about finding out how and why. You have serious data corruption on your hands. Hunt that down first. config.db files are streamed python objects. If you can't load them under python (which you should be able to) then something is Badly Wrong. About your only recourse at that point is trying to run strings against them. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From aturner@pobox.com Tue Oct 2 22:06:40 2001 From: aturner@pobox.com (Aaron D. Turner) Date: Tue, 2 Oct 2001 14:06:40 -0700 (PDT) Subject: [Mailman-Developers] What to do with a corrupt config.db? In-Reply-To: <30166.1002054347@2wire.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 2 Oct 2001, J C Lawrence wrote: > On Tue, 2 Oct 2001 11:00:14 -0700 (PDT) > Aaron D Turner wrote: > > > It seems all the config.db's (and their .last's) for all my lists > > are now corrupt. At least check_db says so. Since there doesn't > > seem to be anyway to fix this, perhaps there is a way to extract > > the email addresses/passwords for the lists so I can recover? > > I'd be far more worried about finding out how and why. You have > serious data corruption on your hands. Hunt that down first. I'm guessing it has to do with the upgrade I just did. It seems to be mailman related as these seem to be the only corrupted files on the system that I can tell. > config.db files are streamed python objects. If you can't load them > under python (which you should be able to) then something is Badly > Wrong. Well I know nothing about that or Python. > About your only recourse at that point is trying to run > strings against them. Heh, forgot about strings. Yeah, that worked nicely. No way to recover the passwords, but hey, at least I have my subscriber list again. - -- Aaron Turner URI:www.synfin.net They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin pub 1024D/F86EDAE6 Sig: 3167 CCD6 6081 0FFC B749 9A8F 8707 9817 F86E DAE6 All emails by me are PGP signed; a lack of a signature indicates a forgery. I have retired my PGP 2.6.2 key: FBE1 CEED 57E4 AB80 596E 60BF 451B 20E8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Public key at: http://www.synfin.net/aturner/pgpkey.asc iEYEARECAAYFAju6LGUACgkQhweYF/hu2uZLYACfVHM4jLB5wOMVe6wBsInzD8ua i9wAn2OaCsLw0rLRBsX2zmQqWjuNHb/w =Y46c -----END PGP SIGNATURE----- From claw@2wire.com Tue Oct 2 22:19:21 2001 From: claw@2wire.com (J C Lawrence) Date: Tue, 02 Oct 2001 14:19:21 -0700 Subject: [Mailman-Developers] What to do with a corrupt config.db? In-Reply-To: Message from "Aaron D. Turner" of "Tue, 02 Oct 2001 14:06:40 PDT." References: Message-ID: <30694.1002057561@2wire.com> On Tue, 2 Oct 2001 14:06:40 -0700 (PDT) Aaron D Turner wrote: > I'm guessing it has to do with the upgrade I just did. It seems > to be mailman related as these seem to be the only corrupted files > on the system that I can tell. If you upgraded Mailman, ensure that the upgrade process also upgraded the config.db's to the new format. There's a command in ~/bin to do that. > Heh, forgot about strings. Yeah, that worked nicely. No way to > recover the passwords, but hey, at least I have my subscriber list > again. Yeah, I've been there (while tracking a nasty kernel bug that kept whacking my filesystem). Not I have cron jobs that email me the results of ~/bin/dump_config. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From aturner@pobox.com Tue Oct 2 22:25:28 2001 From: aturner@pobox.com (Aaron D. Turner) Date: Tue, 2 Oct 2001 14:25:28 -0700 (PDT) Subject: [Mailman-Developers] What to do with a corrupt config.db? In-Reply-To: <30694.1002057561@2wire.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 2 Oct 2001, J C Lawrence wrote: > On Tue, 2 Oct 2001 14:06:40 -0700 (PDT) > Aaron D Turner wrote: > > > I'm guessing it has to do with the upgrade I just did. It seems > > to be mailman related as these seem to be the only corrupted files > > on the system that I can tell. > > If you upgraded Mailman, ensure that the upgrade process also > upgraded the config.db's to the new format. There's a command in > ~/bin to do that. That's when I got the first error. Basically, I had upgraded from RH 6.2 to 7.1 which included a new version of python which wasn't compatible with the version of Mailman I was running (2.0beta5), so I upgraded mailman at which time my config.db's magically became corrupt. Honestly, it could of been user error- it's been a while since I've done a mailman upgrade, and even though I followed the docs, I could of done something wrong. Of course, maybe there's a bug in 2.4.10/reiserfs which for some reason only effected the config.db and config.db.last. Or maybe the config.db converter doesn't like going between 2.0b5 and 2.0.6. At this point I'm just happy all my subscriber info was restored- and the lists are far from critical in my case anyways. - -- Aaron Turner URI:www.synfin.net They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin pub 1024D/F86EDAE6 Sig: 3167 CCD6 6081 0FFC B749 9A8F 8707 9817 F86E DAE6 All emails by me are PGP signed; a lack of a signature indicates a forgery. I have retired my PGP 2.6.2 key: FBE1 CEED 57E4 AB80 596E 60BF 451B 20E8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Public key at: http://www.synfin.net/aturner/pgpkey.asc iEYEARECAAYFAju6MNEACgkQhweYF/hu2uZu6wCeIGnQMi0F46jJz1YrQPWj6H8m JN0An2W/kGTNgkzCR7cwEUYCAj8QBsld =O38U -----END PGP SIGNATURE----- From claw@2wire.com Tue Oct 2 23:12:39 2001 From: claw@2wire.com (J C Lawrence) Date: Tue, 02 Oct 2001 15:12:39 -0700 Subject: [Mailman-Developers] What to do with a corrupt config.db? In-Reply-To: Message from "Aaron D. Turner" of "Tue, 02 Oct 2001 14:25:28 PDT." References: Message-ID: <31356.1002060759@2wire.com> On Tue, 2 Oct 2001 14:25:28 -0700 (PDT) Aaron D Turner wrote: > That's when I got the first error. Basically, I had upgraded from > RH 6.2 to 7.1 which included a new version of python which wasn't > compatible with the version of Mailman I was running (2.0beta5), > so I upgraded mailman at which time my config.db's magically > became corrupt. Light dawns. I suspect that not only did the new Python version not like your old Mailman install, it also didn't like your old Python version's config.db streamed objects, and that this is the source of the problem. Simple non backward compatibility. Bad, but understandable. Barry may be able to comment on this further (I haven't followed Python in detail for years and I gave up on Red Hat entirely even longer ago). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jra@baylink.com Wed Oct 3 00:27:41 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 2 Oct 2001 19:27:41 -0400 Subject: [Mailman-Developers] What to do with a corrupt config.db? In-Reply-To: <30166.1002054347@2wire.com>; from J C Lawrence on Tue, Oct 02, 2001 at 01:25:47PM -0700 References: <30166.1002054347@2wire.com> Message-ID: <20011002192741.10208@scfn.thpl.lib.fl.us> On Tue, Oct 02, 2001 at 01:25:47PM -0700, J C Lawrence wrote: > Aaron D Turner wrote: > > It seems all the config.db's (and their .last's) for all my lists > > are now corrupt. At least check_db says so. Since there doesn't > > seem to be anyway to fix this, perhaps there is a way to extract > > the email addresses/passwords for the lists so I can recover? > > I'd be far more worried about finding out how and why. You have > serious data corruption on your hands. Hunt that down first. Some people are coders, some people are operators. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From bh@agl.ucl.ac.be Wed Oct 3 17:50:20 2001 From: bh@agl.ucl.ac.be (Henrion Benjamin) Date: Wed, 3 Oct 2001 18:50:20 +0200 Subject: [Mailman-Developers] bug report Message-ID: <20011003185020.A9706@agl.ucl.ac.be> --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've a bug with the newlist binary and it reports a message in the error logs (cfr attachment). Thanks for your help -- BNJ --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=error Oct 03 18:44:49 2001 admin(9650): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(9650): [----- Mailman Version: 2.0.6 -----] admin(9650): [----- Traceback ------] admin(9650): Traceback (innermost last): admin(9650): File "/var/lib/mailman/scripts/driver", line 98, in run_main admin(9650): main() admin(9650): File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 48, in main admin(9650): FormatListListinfo(mlist) admin(9650): File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 180, in FormatListListinfo admin(9650): doc.AddItem(mlist.ParseTags('listinfo.html', replacements)) admin(9650): File "/usr/lib/mailman/Mailman/HTMLFormatter.py", line 333, in ParseTags admin(9650): text = self.SnarfHTMLTemplate(template) admin(9650): File "/usr/lib/mailman/Mailman/HTMLFormatter.py", line 64, in SnarfHTMLTemplate admin(9650): f = open(filename,'r') admin(9650): IOError: [Errno 2] No such file or directory: '/var/lib/mailman/lists/agltest/listinfo.html' admin(9650): [----- Python Information -----] admin(9650): sys.version = 1.5.2 (#0, Apr 10 2001, 10:03:44) [GCC 2.95.3 20010219 (prerelease)] admin(9650): sys.executable = /usr/bin/python admin(9650): sys.prefix = /usr admin(9650): sys.exec_prefix= /usr admin(9650): sys.path = /usr admin(9650): sys.platform = linux2 admin(9650): [----- Environment Variables -----] admin(9650): DOCUMENT_ROOT: /home/agl/www/ admin(9650): SERVER_ADDR: 130.104.19.249 admin(9650): SERVER_PORT: 80 admin(9650): PATH_TRANSLATED: /home/agl/www/agltest admin(9650): REMOTE_ADDR: 10.0.0.107 admin(9650): UNIQUE_ID: O7tAgH8AAAEAACSkBok admin(9650): HTTP_ACCEPT_LANGUAGE: fr-be admin(9650): GATEWAY_INTERFACE: CGI/1.1 admin(9650): SERVER_NAME: www.agl.ucl.ac.be admin(9650): HTTP_CONNECTION: Keep-Alive admin(9650): HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) admin(9650): HTTP_ACCEPT: application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* admin(9650): REQUEST_URI: /cgi-bin/mailman/listinfo/agltest admin(9650): QUERY_STRING: admin(9650): SCRIPT_FILENAME: /usr/lib/cgi-bin/mailman/listinfo admin(9650): PATH_INFO: /agltest admin(9650): HTTP_HOST: www.agl.ucl.ac.be admin(9650): REQUEST_METHOD: GET admin(9650): SERVER_SIGNATURE:
Apache/1.3.20 Server at www.agl.ucl.ac.be Port 80
admin(9650): SCRIPT_NAME: /cgi-bin/mailman/listinfo admin(9650): SERVER_ADMIN: webmaster@agl.ucl.ac.be admin(9650): SERVER_SOFTWARE: Apache/1.3.20 (Unix) Debian/GNU PHP/4.0.6 admin(9650): PYTHONPATH: /var/lib/mailman admin(9650): SERVER_PROTOCOL: HTTP/1.0 admin(9650): REMOTE_PORT: 1218 --zhXaljGHf11kAtnf-- From barry@zope.com Wed Oct 3 16:27:03 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Oct 2001 11:27:03 -0400 Subject: [Mailman-Developers] What to do with a corrupt config.db? References: <31356.1002060759@2wire.com> Message-ID: <15291.11847.83334.663955@geddy.wooz.org> JCL> I suspect that not only did the new Python version not like JCL> your old Mailman install, it also didn't like your old Python JCL> version's config.db streamed objects, and that this is the JCL> source of the problem. Simple non backward compatibility. JCL> Bad, but understandable. Barry may be able to comment on JCL> this further (I haven't followed Python in detail for years JCL> and I gave up on Red Hat entirely even longer ago). I don't remember Aaron saying what version of Python he upgraded from, and what version he upgraded to, but I don't /think/ that should matter. I'm assuming he was using Python 1.5.2 (anything earlier isn't compatible with Mailman 2.0) and that he upgraded to some later Python. The config.db file is a marshalled Python dictionary... [Aside for non-Pythonistas: a dictionary is a mapping between keys and values. Keys can be any immutable type and values can be any Python object. In Mailman's case keys are always strings and values are almost always primitive data structures like lists, tuples, strings, and numbers. "Marshal" is a fairly low level Python protocol for serializing and de-serializing Python objects, implemented in the marshal module. It doesn't handle objects well -- for that use pickle or cPickle. marshal is platform independent, but not guaranteed to be backwards compatible with earlier versions of Python. However, I'm not aware of any incompatibilities between Python 1.5.2's marshal format and later Python's format (although I'm offline at the moment and can't double check.)] I doubt that either the upgrade to Python or to Mailman caused your corruption. config.db should be compatible with both upgrades and Mailman should convert the config.db to the latest file version automatically. In any event, if Mailman cannot load your config.db, it will try to load config.db.last and only rotate them if everything was successful. The fact that your config.db.last file is corrupt indicates to me a problem wit the file system or OS. Like any valuable resource, I recommend backing up your Mailman data files regularly. ;) Musing: it might make sense to change config.db over to a Python pickle to guarantee compatibility with future Python versions. As mentioned, I don't think there are known breakages, but there may be in the future... -Barry From jbglaw@lug-owl.de Thu Oct 4 12:54:41 2001 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 4 Oct 2001 13:54:41 +0200 Subject: [Mailman-Developers] German Umlauts in pipermail Message-ID: <20011004135441.F10037@lug-owl.de> Hi! I tried to get german Umlauts, MIME-embedded in mails, to work properly, and failed: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D8<------------------------------- jbglaw@min:~/debian-pkg$ diff -u mailman-2.0.6/Mailman/Archiver/HyperArch.p= y mailman-2.0.6-jbglaw/Mailman/Archiver/HyperArch.py = --- mailman-2.0.6/Mailman/Archiver/HyperArch.py Mon Nov 13 22:50:05= 2000 +++ mailman-2.0.6-jbglaw/Mailman/Archiver/HyperArch.py Mon Oct 1 16:24:38= 2001 @@ -57,10 +57,28 @@ =20 =20 =20 def html_quote(s): - repls =3D ( ('&', '&'), - ("<", '<'), - (">", '>'), - ('"', '"')) + repls =3D ( ( '&', '&' ), + ( '<', '<' ), + ( '>', '>' ), + ( '=3D20', ' ' ), + ( '=3D3D', '=3D' ), + ( '=3DE4', 'ä' ), + ( '=3DF6', 'ö' ), + ( '=3DFC', 'ü' ), + ( '=3DDF', 'ß' ), + ( '=3DC4', 'Ä' ), + ( '=3DF6', 'Ö' ), + ( '=3DDC', 'Ü' ), + ( '=3DE9', 'é' ), + ( '=E4', 'ä' ), + ( '=F6', 'ö' ), + ( '=FC', 'ü' ), + ( '=DF', 'ß' ), + ( '=C4', 'Ä' ), + ( '=D6', 'Ö' ), + ( '=DC', 'Ü' ), + ( '=E9', 'é' ), + ( '"', '"' )) for thing, repl in repls: s =3D string.replace(s, thing, repl) return s ---------------------------------------------->8=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D After I applied the above patch (and I really have absolutely no clue about python...), mailman archived all mails exactly=20 as it did before... What do I miss? MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 From mikhail.sobolev@transas.com Thu Oct 4 14:11:26 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Thu, 4 Oct 2001 14:11:26 +0100 Subject: [Mailman-Developers] German Umlauts in pipermail In-Reply-To: <20011004135441.F10037@lug-owl.de> References: <20011004135441.F10037@lug-owl.de> Message-ID: <20011004141126.A13313@transas.co.uk> On Thu, Oct 04, 2001 at 01:54:41PM +0200, Jan-Benedict Glaw wrote: > + ( '=E4', 'ä' ), > + ( '=F6', 'ö' ), > > After I applied the above patch (and I really have absolutely > no clue about python...), mailman archived all mails exactly > as it did before... What do I miss? Are you sure this is going to work for other character sets? -- Misha From jbglaw@lug-owl.de Thu Oct 4 14:34:13 2001 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Thu, 4 Oct 2001 15:34:13 +0200 Subject: [Mailman-Developers] German Umlauts in pipermail In-Reply-To: <20011004141126.A13313@transas.co.uk> References: <20011004135441.F10037@lug-owl.de> <20011004141126.A13313@transas.co.uk> Message-ID: <20011004153413.B13844@lug-owl.de> On Thu, 2001-10-04 14:11:26 +0100, Mikhail Sobolev wrote in message <20011004141126.A13313@transas.co.uk>: > On Thu, Oct 04, 2001 at 01:54:41PM +0200, Jan-Benedict Glaw wrote: > > + ( '=E4', 'ä' ), > > + ( '=F6', 'ö' ), > > > > After I applied the above patch (and I really have absolutely > > no clue about python...), mailman archived all mails exactly > > as it did before... What do I miss? > Are you sure this is going to work for other character sets? No. Instead, I'm sure this will only work for iso8859-1. However, that would fit my archive. I'm unsure about a *real* solution to the problem (and I really don't know anything about python and how to code a real solution), but I've searched the code to find the (correctly escaped) "<" and ">" signs. I found them, added my stuff and failed. Does the message (at this point) contain the "=XX" escapes at all? How can I look behind the scene? I'd really love to contribute, but I fear I'll need some hints before... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 From mikhail.sobolev@transas.com Thu Oct 4 21:31:29 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Thu, 4 Oct 2001 21:31:29 +0100 Subject: [Mailman-Developers] A samll patch for HTMLFormatter.py Message-ID: <20011004213129.A29750@transas.co.uk> --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I believe, this patch simplifies the translation of the construct. -- Misha --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hf.patch" Index: HTMLFormatter.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/HTMLFormatter.py,v retrieving revision 2.20 diff -u -b -r2.20 HTMLFormatter.py --- HTMLFormatter.py 2001/10/01 21:59:43 2.20 +++ HTMLFormatter.py 2001/10/04 20:28:44 @@ -44,9 +44,11 @@ '
', Address( Container( - Link(self.GetScriptURL('listinfo'), self.real_name), - _(' list run by '), - Link('mailto:' + self.GetOwnerEmail(), ownertext), + _('%(listinfo_link)s list run by %(owner_link)s') % + { + 'listinfo_link' : Link(self.GetScriptURL('listinfo'), self.real_name).Format (), + 'owner_link' : Link('mailto:' + self.GetOwnerEmail(), ownertext).Format (), + }, '
', Link(self.GetScriptURL('admin'), _('%(realname)s administrative interface')), --VS++wcV0S1rZb1Fb-- From jbglaw@lug-owl.de Fri Oct 5 19:15:08 2001 From: jbglaw@lug-owl.de (Jan-Benedict Glaw) Date: Fri, 5 Oct 2001 20:15:08 +0200 Subject: [Mailman-Developers] German Umlauts in pipermail In-Reply-To: <20011004141126.A13313@transas.co.uk> References: <20011004135441.F10037@lug-owl.de> <20011004141126.A13313@transas.co.uk> Message-ID: <20011005201508.B26010@lug-owl.de> On Thu, 2001-10-04 14:11:26 +0100, Mikhail Sobolev wrote in message <20011004141126.A13313@transas.co.uk>: > On Thu, Oct 04, 2001 at 01:54:41PM +0200, Jan-Benedict Glaw wrote: > > + ( '=E4', 'ä' ), > > + ( '=F6', 'ö' ), > > > > After I applied the above patch (and I really have absolutely > > no clue about python...), mailman archived all mails exactly > > as it did before... What do I miss? > Are you sure this is going to work for other character sets? Despite on the, well, bogus way I'd like to build my archive, does anybody have a helpful hint for me? OTOH, I'd also like to start diskussion about doing all those substitutions of chars/=XX values ---> HTML escales on a per charset base. But - I'm totally new to python... But for a start, I'd really like to know why my extended substitution table doesn't work... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 From benwa@ocentrix.com Fri Oct 5 21:47:57 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Fri, 5 Oct 2001 13:47:57 -0700 Subject: [Mailman-Developers] German Umlauts in pipermail In-Reply-To: <20011005201508.B26010@lug-owl.de> References: <20011004135441.F10037@lug-owl.de> <20011004141126.A13313@transas.co.uk> <20011005201508.B26010@lug-owl.de> Message-ID: <01100513475706.08298@va05> On Friday 05 October 2001 11:15 am, Jan-Benedict Glaw wrote: > On Thu, 2001-10-04 14:11:26 +0100, Mikhail Sobolev > > > wrote in message <20011004141126.A13313@transas.co.uk>: > > On Thu, Oct 04, 2001 at 01:54:41PM +0200, Jan-Benedict Glaw wrote: > > > + ( '=E4', 'ä' ), > > > + ( '=F6', 'ö' ), > > > > > > After I applied the above patch (and I really have absolutely > > > no clue about python...), mailman archived all mails exactly > > > as it did before... What do I miss? > > > > Are you sure this is going to work for other character sets? > > Despite on the, well, bogus way I'd like to build my archive, does > anybody have a helpful hint for me? > > OTOH, I'd also like to start diskussion about doing all those > substitutions of chars/=XX values ---> HTML escales on a per > charset base. But - I'm totally new to python... > You may already know this, but there is a list to discuss Mailman multi- language issues. I believe there are some others on the list that are working on German translations and such. Check it out at: Mailman-i18n@python.org http://mail.python.org/mailman/listinfo/mailman-i18n Good luck, Ben From tkikuchi@is.kochi-u.ac.jp Sat Oct 6 04:35:17 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 06 Oct 2001 12:35:17 +0900 Subject: [Mailman-Developers] bug in Handlers/Tagger.py Message-ID: <3BBE7BF5.550F9B45@is.kochi-u.ac.jp> Hi, There were small typos in Tagger.py and here is the patch. Tokio -------- Original Message -------- Date: Sat, 6 Oct 2001 12:25:16 +0900 (JST) From: Mailman Admin To: tkikuchi@is.kochi-u.ac.jp --- /home/mailman/src/mailman/Mailman/Handlers/Tagger.py Fri Oct 5 16:19:30 2001 +++ Mailman/Handlers/Tagger.py Sat Oct 6 12:19:39 2001 @@ -67,11 +67,11 @@ # or if the outer type is multipart/alternative and there is a text/plain # part. Anything else, and the body is ignored for header-scan purposes. found = None - if msg.gettype('text/plain') == 'text/plain': + if msg.get_type('text/plain') == 'text/plain': found = msg - elif msg.ismultipart() and msg.gettype() == 'multipart/alternative': + elif msg.ismultipart() and msg.get_type() == 'multipart/alternative': for found in msg.get_payload(): - if found.gettype('text/plain') == 'text/plain': + if found.get_type('text/plain') == 'text/plain': break else: found = None @@ -99,4 +99,4 @@ # Concatenate those body text lines with newlines, and then create a new # message object from those lines. msg = email.message_from_string(NL.join(lines)) - return msg.getall('subject', []) + msg.getall('keywords', []) + return msg.get_all('subject', []) + msg.get_all('keywords', []) From tkikuchi@is.kochi-u.ac.jp Sat Oct 6 05:19:08 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 06 Oct 2001 13:19:08 +0900 Subject: [Mailman-Developers] Patch for Archiver/HyperArch.py Message-ID: <3BBE863C.4CF2C973@is.kochi-u.ac.jp> Hi, Some time ago, someone complained about the pipermail not representing proper charset in the Content-Type header. Here is a patch for the latest CVS (2.1a). I am not very sure which is better to use as a default language, mm_cfg.DEFAULT_SERVER_LANGUAGE or maillist.preferred_language. Tokio -------- Original Message -------- Date: Sat, 6 Oct 2001 13:09:35 +0900 (JST) From: Mailman Admin To: tkikuchi@is.kochi-u.ac.jp --- HyperArch.py.orig Thu Jul 26 14:26:48 2001 +++ HyperArch.py Sat Oct 6 12:50:39 2001 @@ -104,7 +104,7 @@ blankpat = re.compile(r'^\s*$') # content-type charset -rx_charset = re.compile('charset="(\w+)"') +rx_charset = re.compile('charset=(\S+)',re.IGNORECASE) # # Starting directive @@ -140,7 +140,7 @@ _last_article_time = time.time() # for compatibility with old archives loaded via pickle - charset = mm_cfg.DEFAULT_CHARSET + x, charset = mm_cfg.LC_DESCRIPTIONS[mm_cfg.DEFAULT_SERVER_LANGUAGE] cenc = None decoded = {} @@ -172,7 +172,9 @@ self.decoded = {} mo = rx_charset.search(self.ctype) if mo: - self.check_header_charsets(string.lower(mo.group(1))) + cset = string.lower(mo.group(1)) + re.sub('"','',cset,2) + self.check_header_charsets(cset) else: self.check_header_charsets() if self.charset and self.charset in mm_cfg.VERBATIM_ENCODING: @@ -194,6 +196,7 @@ header, then an arbitrary charset is chosen. Only those values that match the chosen charset are decoded. """ + self.charset = msg_charset author, a_charset = self.decode_charset(self.author) subject, s_charset = self.decode_charset(self.subject) if author is not None or subject is not None: @@ -527,7 +530,7 @@ self._unlocklist = unlock self._lock_file = None self._charsets = {} - self.charset = None + x, self.charset = mm_cfg.LC_DESCRIPTIONS[maillist.preferred_language] if hasattr(self.maillist,'archive_volume_frequency'): if self.maillist.archive_volume_frequency == 0: From doko@cs.tu-berlin.de Sat Oct 6 10:55:11 2001 From: doko@cs.tu-berlin.de (Matthias Klose) Date: Sat, 6 Oct 2001 11:55:11 +0200 Subject: [Mailman-Developers] "stable" release / 2.1 release status Message-ID: <15294.54527.732462.183504@gargle.gargle.HOWL> Reading the web pages: MM21/index.html: Version (2.1a2, released on 11-Jul-2001) is the current stable GNU release. download.html: Version (2.0.6, released on Jul 25 2001) is the current GNU release. Correct to name 2.1a2 a stable release? Somewhere on the lists Barry Warsaw didn't give a garanty for a smooth upgrade path between the alpha releases. Or is 2.1 on the horizon, so that it's more work to change the web page ;-) Matthias From liuk@publinet.it Sat Oct 6 15:55:37 2001 From: liuk@publinet.it (Luca Maranzano) Date: Sat, 6 Oct 2001 16:55:37 +0200 Subject: [Mailman-Developers] config.pck: config file was corrupt ? Message-ID: <20011006165537.A15500@publinet.it> Hi, I've upgraded to latest CVS (some minutes ago...) and after the upgrade I see in the error log file messages like this: Oct 06 16:50:02 2001 (22966) LISTNAME config file was corrupt, trying fallback: /home/mailman/lists/LISTNAME/config.pck.last However it seems that accessing via Web the data are all preserved, what are config.pck files? Are they new? Thanks, luca From benwa@ocentrix.com Sat Oct 6 22:54:28 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Sat, 06 Oct 2001 14:54:28 -0700 Subject: [Mailman-Developers] "stable" release / 2.1 release status In-Reply-To: <15294.54527.732462.183504@gargle.gargle.HOWL> Message-ID: <5.0.2.1.0.20011006132815.03b653a0@mail.ocentrix.com> At 11:55 AM 10/6/01 +0200, Matthias Klose wrote: >Reading the web pages: > >MM21/index.html: > Version (2.1a2, released on 11-Jul-2001) is the current stable > GNU release. > >download.html: > Version (2.0.6, released on Jul 25 2001) is the current GNU > release. > > >Correct to name 2.1a2 a stable release? Somewhere on the lists Barry >Warsaw didn't give a garanty for a smooth upgrade path between the >alpha releases. Or is 2.1 on the horizon, so that it's more work to >change the web page ;-) > > Matthias You're actually the second person to notice this and report it on this list. http://mail.python.org/pipermail/mailman-developers/2001-September/009557.html Barry's plan was to fix the web page at list.org. http://mail.python.org/pipermail/mailman-developers/2001-September/009558.html If I remember correctly he's also the release manager for the latest version of Python, so I'm sure he's up to his eyeballs currently. IMHO this is a very good reason for not hitting this particular item. Therefore, I have included a patch below against index.ht (yes that's a patch against the template file) for the list.org web-site. The patch should be self-explanatory. --------------------------------------------------- *** index.ht Sat Oct 6 14:18:42 2001 --- index.ht.new Sat Oct 6 14:48:04 2001 *************** *** 36,39 **** --- 36,57 ---- StudlyCaps). +

Latest Stable Release

+ +

The latest stable release of Mailman is the + 2.0.6 version. + This release has undergone considerable testing in production + environments. + +

Version 2.1, which + offers tons of extra features is nearing completion so rapidly that + it's a good idea to check back often. Please download the + current alpha + version 2.1a2 and help us test it. Get news and post comments + on this version via the + + Mailman-Developers discussion list. Please report any bugs in + the SourceForge bug + tracker. +

Acknowledgements

--------------------------------------------------- I haven't actually run it through ht2html so I apologize beforehand if it breaks. I would have provided patches for the index of the MM21 directory but didn't have access to the templates. Barry, I hope this isn't stepping on your toes, and I hope it's useful. Later, - Ben From remove@1980.hu Sun Oct 7 09:34:07 2001 From: remove@1980.hu (remove@1980.hu) Date: Sun, 07 Oct 01 03:34:07 EST Subject: [Mailman-Developers] Obtain your degree from Englsih-language European Universities... Message-ID: <893883.93912991004.32991p1> Dear mailman-developers@python.org, Message If you want to be removed from this mailing list please reply to this email with “REMOVE” in the subject heading or send a blank email to remove@1980.hu WOW!!....It is possible to gain Direct Admission into a Accredited Medical, Dental, Physical Therapy, and Pharmaceutical Universities in Europe! IMEI is a corporation who introduces and promotes you to the European Universities and the American Medical Community. Does this sound unbelievable? Current research shows over 20% of all physicians and of all residents have trained overseas. The changes of recent laws in our government have allowed this opportunity to attend a accredited university, and then return to the United States to complete a residency in your chosen specialty. There’s More! : All courses are Taught in English and fully Qualify for Federal Loans and Grants. Some of these schools have been teaching physicians for over 700 years, and they are not like the recent plethora of several year old Caribbean “Diploma Mills.” The curriculum of the schools in Europe parallels that of the American Medical Schools: The courses are not rushed like the above-mentioned "Diploma Mills." You allowed to take summers off which allows for an excellent investigation examination of all that Europe has to offer. Grab an EuroRail Pass to travel to places you have only dreamed of visiting. The dream is over......you have arrived! The curriculum has been designed with in mind.....Students may enter as young as High School or can have attempted or finished college. Try to find that flexibility anywhere in the world. We know.....we have looked! Please call or email us with the particular questions that you may have. So come and experience the Best Academics that only study in Europe can offer, all the while discovering its’ abundance of culture and history. This is a recipe for your memories that will last your entire medical career. For more information on qualifications, please write, call, or email to the following addresses: medicine@1997.hu 1-801-849-3270 ( Inside USA ) 001-801-849-3270 (Outside USA) 00-36-309839-247 ( International ) You must be 18 years old (or emancipatable), must have a high school diploma (or GED Eligible). Tuition ranges from 7,000 to 9,000 per annum. There is a one time admission fee that varies on program applied for. From remove@1980.hu Sun Oct 7 12:12:29 2001 From: remove@1980.hu (remove@1980.hu) Date: Sun, 07 Oct 01 06:12:29 EST Subject: [Mailman-Developers] Obtain your degree from Englsih-language European Universities... Message-ID: <893883.93912991004.32991p1> Dear mailman-developers@python.org, Message If you want to be removed from this mailing list please reply to this email with “REMOVE” in the subject heading or send a blank email to remove@1980.hu WOW!!....It is possible to gain Direct Admission into a Accredited Medical, Dental, Physical Therapy, and Pharmaceutical Universities in Europe! IMEI is a corporation who introduces and promotes you to the European Universities and the American Medical Community. Does this sound unbelievable? Current research shows over 20% of all physicians and of all residents have trained overseas. The changes of recent laws in our government have allowed this opportunity to attend a accredited university, and then return to the United States to complete a residency in your chosen specialty. There’s More! : All courses are Taught in English and fully Qualify for Federal Loans and Grants. Some of these schools have been teaching physicians for over 700 years, and they are not like the recent plethora of several year old Caribbean “Diploma Mills.” The curriculum of the schools in Europe parallels that of the American Medical Schools: The courses are not rushed like the above-mentioned "Diploma Mills." You allowed to take summers off which allows for an excellent investigation examination of all that Europe has to offer. Grab an EuroRail Pass to travel to places you have only dreamed of visiting. The dream is over......you have arrived! The curriculum has been designed with in mind.....Students may enter as young as High School or can have attempted or finished college. Try to find that flexibility anywhere in the world. We know.....we have looked! Please call or email us with the particular questions that you may have. So come and experience the Best Academics that only study in Europe can offer, all the while discovering its’ abundance of culture and history. This is a recipe for your memories that will last your entire medical career. For more information on qualifications, please write, call, or email to the following addresses: medicine@1997.hu 1-801-849-3270 ( Inside USA ) 001-801-849-3270 (Outside USA) You must be 18 years old (or emancipatable), must have a high school diploma (or GED Eligible). Tuition ranges from 7,000 to 9,000 per annum. There is a one time admission fee that varies on program applied for. From liuk@publinet.it Mon Oct 8 13:30:02 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 8 Oct 2001 14:30:02 +0200 Subject: [Mailman-Developers] 2 new exceptions in logs/error using latest CVS Message-ID: <20011008143002.A5079@publinet.it> Hi all, using latest CVS (yesterday) with the get_type in Tagger.py patch, now I'm getting the following errors: Oct 08 13:36:09 2001 (26619) Uncaught runner exception: readline Oct 08 13:36:09 2001 (26619) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/CommandRunner.py", line 99, in _dispose if mlist.bounce_processing and \ File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 63, in ScanMessages addrs = sys.modules[modname].process(msg) File "/home/mailman/Mailman/Bouncers/Yahoo.py", line 40, in process line = mi.readline() AttributeError: readline Oct 08 13:37:32 2001 (26619) Bouncer exception: not enough arguments; expected 1, got 0 Oct 08 13:37:32 2001 (26619) Traceback (most recent call last): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 71, in ScanMessages mlist.RegisterBounce(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 123, in RegisterBounce self.HandleBouncingAddress(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 214, in HandleBouncingAddress text = text + '\n\n--' + boundary + \ TypeError: not enough arguments; expected 1, got 0 These seems two distinct bugs repeated several time in the error log file. Regards, Luca From liuk@publinet.it Mon Oct 8 13:33:36 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 8 Oct 2001 14:33:36 +0200 Subject: [Mailman-Developers] bug in Handlers/Tagger.py In-Reply-To: <3BBE7BF5.550F9B45@is.kochi-u.ac.jp> References: <3BBE7BF5.550F9B45@is.kochi-u.ac.jp> Message-ID: <20011008143336.A5136@publinet.it> Hi, the typo is present also in Mailman/Bouncers/Caiwireless.py at line 30 :-) Luca On Sat, Oct 06, 2001 at 12:35:17PM +0900, Tokio Kikuchi wrote: > Hi, > > There were small typos in Tagger.py and here is the patch. > > Tokio > > > -------- Original Message -------- > Date: Sat, 6 Oct 2001 12:25:16 +0900 (JST) > From: Mailman Admin > To: tkikuchi@is.kochi-u.ac.jp > > --- /home/mailman/src/mailman/Mailman/Handlers/Tagger.py Fri Oct 5 16:19:30 2001 > +++ Mailman/Handlers/Tagger.py Sat Oct 6 12:19:39 2001 [.... snip ....] From joseroberto@pwr.com.br Mon Oct 8 18:07:08 2001 From: joseroberto@pwr.com.br (José Roberto Kerne) Date: Mon, 8 Oct 2001 14:07:08 -0300 Subject: [Mailman-Developers] Hello... I am subscribing for contribute Message-ID: <20011008140708.7a5e04f5.joseroberto@pwr.com.br> Hello... I am translating the Mailman software for my language! (Porguese-Brazil) Please, sorry my english ok! I am studing english yet! OK... I need for information for translate the mailman.... Anyone help-me ? Thanks! -- José Roberto Kerne Analista de Suporte Profissional Certificado Linux - LPI E-mail: joseroberto@pwr.com.br Power Consultoria e Informatica Ltda Fone: (47) 433-7595 - Celular: 9107-6073 Rede Conectiva de Serviços Oracle Allianses From benwa@ocentrix.com Mon Oct 8 18:19:43 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Mon, 8 Oct 2001 10:19:43 -0700 Subject: [Mailman-Developers] Hello... I am subscribing for contribute In-Reply-To: <20011008140708.7a5e04f5.joseroberto@pwr.com.br> References: <20011008140708.7a5e04f5.joseroberto@pwr.com.br> Message-ID: <01100810194301.18906@va05> On Monday 08 October 2001 10:07 am, Jos=E9 Roberto Kerne wrote: > Hello... > > I am translating the Mailman software for my language! > (Porguese-Brazil) > > Please, sorry my english ok! I am studing english yet! > > OK... I need for information for translate the mailman.... > > Anyone help-me ? > There is another list for talking about Mailman translation issues. I'm = sure=20 someone there can help you get started. You may even find someone there = who=20 has already started a brazillian translation. Mailman-i18n@python.org http://mail.python.org/mailman/listinfo/mailman-i18n Good Luck, - Ben From dmick@utopia.West.Sun.COM Tue Oct 9 00:16:40 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Mon, 08 Oct 2001 16:16:40 -0700 Subject: [Mailman-Developers] bug in Handlers/Tagger.py References: <3BBE7BF5.550F9B45@is.kochi-u.ac.jp> <20011008143336.A5136@publinet.it> Message-ID: <3BC233D8.48E485C6@utopia.west.sun.com> Yeah, these are changes from mimelib to email. There are several; I've sent them off to Barry but I think he's buried in Python 2.2 release hell at the moment. Luca Maranzano wrote: > > Hi, > > the typo is present also in Mailman/Bouncers/Caiwireless.py at line 30 :-) > > Luca > > On Sat, Oct 06, 2001 at 12:35:17PM +0900, Tokio Kikuchi wrote: > > Hi, > > > > There were small typos in Tagger.py and here is the patch. > > > > Tokio > > > > > > -------- Original Message -------- > > Date: Sat, 6 Oct 2001 12:25:16 +0900 (JST) > > From: Mailman Admin > > To: tkikuchi@is.kochi-u.ac.jp > > > > --- /home/mailman/src/mailman/Mailman/Handlers/Tagger.py Fri Oct 5 16:19:30 2001 > > +++ Mailman/Handlers/Tagger.py Sat Oct 6 12:19:39 2001 > [.... snip ....] > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From barry@zope.com Tue Oct 9 04:18:54 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 8 Oct 2001 23:18:54 -0400 Subject: [Mailman-Developers] bug in Handlers/Tagger.py References: <3BBE7BF5.550F9B45@is.kochi-u.ac.jp> <20011008143336.A5136@publinet.it> Message-ID: <15298.27806.681163.676754@anthem.wooz.org> All this and more fixed as soon as I can sync up my laptop w/ cvs. I was on a long weekend, and it was so much more fun to have my new laptop and hack than watch the local Washington DC football team get beat (badly) again. ;) More tomorrow... -Barry From marc_news@valinux.com Tue Oct 9 06:10:38 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 8 Oct 2001 22:10:38 -0700 Subject: [Mailman-Developers] Making the list archive URL configurable Message-ID: <20011008172335.F27744@magic.merlins.org> I had the implement the following patches on SF's mailman: usw-sf-list1:/var/local/src# cat mailman-2.0.geocrawler.patch --- mailman-2.0.3/Mailman/HTMLFormatter.py Sat Sep 9 12:13:58 2000 +++ mailman-2.0.3.sf/Mailman/HTMLFormatter.py Mon Mar 19 15:44:02 2001 @@ -309,7 +309,7 @@ return ('
' % full_url) def FormatArchiveAnchor(self): - return '' % self.GetBaseArchiveURL() + return '' % self._internal_name def FormatFormEnd(self): return '' usw-sf-list1:/var/local/src# cat mailman-2.0.geocrawler2.patch diff -urN mailman-2.0.5.sf.old/Mailman/Handlers/CookHeaders.py mailman-2.0.5.sf/Mailman/Handlers/CookHeaders.py --- mailman-2.0.5.sf.old/Mailman/Handlers/CookHeaders.py Wed Nov 15 20:35:09 2000 +++ mailman-2.0.5.sf/Mailman/Handlers/CookHeaders.py Mon Oct 8 16:00:18 2001 @@ -131,7 +131,8 @@ # Always delete List-Archive header, but only add it back if the list is # actually archiving del msg['List-Archive'] - if mlist.archive: - value = '<%s>' % urlparse.urljoin(mlist.web_page_url, - mlist.GetBaseArchiveURL()) - msg['List-Archive'] = value + #if mlist.archive: + # value = '<%s>' % urlparse.urljoin(mlist.web_page_url, + # mlist.GetBaseArchiveURL()) + value = '' % mlist._internal_name + msg['List-Archive'] = value (I am missing the link in the admin page, but that's ok) Is there a way to add the archive URL in the list options and the UI (I thought about doint it, but I'm not too familiar with the datbase compatibility issues and the problems with adding a new field in the list options) Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From donal.hunt2@mail.dcu.ie Tue Oct 9 13:01:06 2001 From: donal.hunt2@mail.dcu.ie (Donal Hunt) Date: Tue, 09 Oct 2001 13:01:06 +0100 Subject: [Mailman-Developers] Bug: "very low level failure" References: Message-ID: <3BC2E702.1F8D3890@mail.dcu.ie> Hey... For once i'm completely stumped. History: ------- Python 2.1.1 on Solaris 8 (Sparc Edtion). Apache 1.3.20. Installed Mailman 2.0.6 using: configure --prefix=/local/mailman \ --with-cgi-gid=webgroup \ --with-mail-gid=postfix \ --with-python=/usr/local/python Everything seems to work (little problem with missing the python time module, but sorted that). However the web interface doesn't work at all. Just get the following message: "Mailman experienced a very low level failure and could not even generate a useful traceback for you. Please report this to the Mailman administrator at this site." The Apache error log shows: --------------------------------------------------------------- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [----- Mailman Version: 2.0.6 -----] [----- Traceback ------] Traceback (most recent call last): File "/local/mailman/scripts/driver", line 66, in run_main @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [----- Mailman Version: 2.0.6 -----] [----- Traceback ------] Traceback (most recent call last): File "/local/mailman/scripts/driver", line 229, in ? [Mailman: low level unrecoverable exception] --------------------------------------------------------------- Had a quick look through the archives, but didn't find anything. Found something Barry wrote in the comp.lang.python newsgroup that explains why it's happening (it's a comment in : --------------------------------------------------------------- # Some exception percolated all the way back up to the top. This # generally shouldn't happen because the run_main() call is similarly # wrapped, but just in case, we'll give it one last ditch effort to report # problems to *somebody*. Most likely this will end up in the Web server # log file. --------------------------------------------------------------- I had a quick look through src/cgi-wrapper.c, src/common.c and src/vsnprintf.c (they are used to build driver afair) but couldn't see anything wrong there... So... Anyone got an idea why it's breaking?? Anyone had a similar problem with Mailman 2.0.6?? Regards Donal p.s. Cross-posted to mailman-users and mailman-developers. From barry@zope.com Mon Oct 8 04:31:03 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 7 Oct 2001 23:31:03 -0400 Subject: [Mailman-Developers] A samll patch for HTMLFormatter.py References: <20011004213129.A29750@transas.co.uk> Message-ID: <15297.7671.148052.941451@geddy.wooz.org> >>>>> "MS" == Mikhail Sobolev writes: MS> I believe, this patch simplifies the translation of the MS> construct. Cool. I've rewritten it a little for clarity, but thanks for the fix! -Barry From barry@zope.com Mon Oct 8 04:54:02 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 7 Oct 2001 23:54:02 -0400 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists References: <8766anbcdk.fsf@nausicaa.interq.or.jp> Message-ID: <15297.9050.478075.25930@geddy.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> On a massive list (Mailman 2.0.6) I run that regularly gets a BG> few hundred or more emails every day, things begin to slow BG> down to molasses after a week or two each month, with the BG> qrunner process taking literally HUNDREDS of megabytes of RAM, BG> and 100% CPU, all the time. FWIW, the combined {zope,python}.org gets many hundreds of messages a day on the python-list and zope mailing lists alone. I'm not online at the moment, so I can't check, but I know I receive several digests every day from both lists -- they're very high traffic. Needless to say, I haven't noticed any such performance problems... Here are a few things you can do to improve matters. First and foremost, make sure GZIP_ARCHIVE_TXT_FILES is 0 -- this should be the default though. Don't even try to gzip your .txt files in real-time since this will absolutely clobber your system. Use cron/nightly_gzip instead (it doesn't have to be nightly, that's up to your crontab). If your system still can't handle things, then the next step is to set ARCHIVE_TO_MBOX to 1. This way, Mailman will simply append the message to the .mbox file, which ought to be extremely quick, but it won't attempt to run the Pipermail archiver in real time. Then you can use whatever archiving scheme you want (e.g. bin/arch nightly, or an external archiver). In MM2.1, you'll be able to lower the priority of your archive qrunner, so that it processes messages, say once per hour. It also won't be in-line with the normal thru-path of messages, so even if the archiver is slow, it won't gum up delivery of list messages. And yes, the Pipermail stuff is a mess. I don't have time to rewrite it, so it'll have to wait for volunteers. -Barry From barry@zope.com Mon Oct 8 04:41:53 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 7 Oct 2001 23:41:53 -0400 Subject: [Mailman-Developers] CPU Usage References: <20010925151125.77e01be4.rodolfo@linux.org.uy> Message-ID: <15297.8321.928062.891519@geddy.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: RP> Two mails about CPU usage: | Date: Tue, 25 Sep 2001 00:50:33 -0300 | From: Rodolfo Pilas | To: mailman-users@python.org | Subject: [Mailman-Users] CPU Usage in 2.1a2 RP> Hello, RP> Perhaps somebody can explain me why I have a task (mailman) to RP> eat all of my CPU: RP> 60 processes: 56 sleeping, 4 running, 0 zombie, 0 stopped CPU RP> states: 5.1% user, 94.8% system, 0.0% nice, 0.0% idle Mem: RP> 259688K av, 154984K used, 104704K free, 0K shrd, 90484K buff RP> Swap: 385552K av, 12004K used, 373548K free 25160K cached RP> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND RP> 25893 root 14 0 3688 3688 2468 R 99.0 1.4 2:42 python RP> bin/mailmanctl start 25899 root 2 0 924 924 732 R 0.7 0.3 0:01 ------------^^^^^^^^^^ Note, this is a Mailman 2.1 thing. RP> Sometimes I have two python task eating 50% of my CPU each RP> one. RP> It is normal? RP> How many time these task are overload the CPU? | Date: Mon, 24 Sep 2001 23:57:03 -0400 | From: David Ball | To: Rodolfo Pilas | Subject: Re: [Mailman-Users] CPU Usage in 2.1a2 DB> I have experienced the same problem recently (v2.0.6), and DB> ended up having to disable the Mailman web interface as DB> Python2.1 procs were taking down my machine (a mere P75 w/16MB DB> or ram, which may account for the problem). Unless I killed DB> the processes immediately, all daemons would eventually shut DB> down (sshd, apache, even login), requiring me to reboot the DB> machine when I got home. Mailman 2.1 and 2.0.6 use completely different qrunner systems, so it's hard to understand how your two problems could be related. I'm not aware of any infloops in 2.0.6 and haven't seen any big problems on {zope,python}.org. I suppose the usual culprits like stale locks and such could be at the heart of your problem. OTOH, I haven't stress tested the 2.1 qrunner subsystem, so it's possible there are problems there. I'll believe I now have a test framework where it might be possible to create very high loads under control situations, so I should be able to uncover any performance problems with 2.1's qrunner. -Barry From rodolfo@linux.org.uy Tue Oct 9 19:59:59 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 09 Oct 2001 15:59:59 -0300 Subject: [Mailman-Developers] CPU Usage In-Reply-To: <15297.8321.928062.891519@geddy.wooz.org> References: <20010925151125.77e01be4.rodolfo@linux.org.uy> <15297.8321.928062.891519@geddy.wooz.org> Message-ID: <1002654001.2235.16.camel@claudia> --=-QR2lQrwmqvh0F7Gx3vSA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable En Mon, 2001-10-08 a 00:41, Barry A. Warsaw escribio: >=20 > >>>>> "RP" =3D=3D Rodolfo Pilas writes: > RP> bin/mailmanctl start 25899 root 2 0 924 924 732 R 0.7 0.3 0:01 > ------------^^^^^^^^^^ > Note, this is a Mailman 2.1 thing. > OTOH, I haven't stress tested the 2.1 qrunner subsystem, so it's > possible there are problems there. I'll believe I now have a test > framework where it might be possible to create very high loads under > control situations, so I should be able to uncover any performance > problems with 2.1's qrunner. Dear Barry, thank you for your reply. I have this problem every two days. I need to kill -9 the hang python process (the others mailmanctl can be down with mailmanctl stop) and rm the /var/.../locks/* and then restart bin/mailmanctl start. If I do not rm the locks/ directory the mailmanctl start says that I have another daemon pid into /var/.../data/qrunner.pid but this file do not exists. (the problem is the /var/.../locks/ directory!) Please, feel free to contact me if you wish that I test some other version of the qrunner. --=20 Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=3D# Apocalipsis Now % Cuarteto de Nos #=3D- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint =3D DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 --=-QR2lQrwmqvh0F7Gx3vSA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA7w0kv0SDHc1cVM2MRAn78AKDZ81TloyK5wMHrBXv2LsgWS6LqEACfdhWZ 4kMcDOsSErS6hMYn+5A0XzQ= =XrID -----END PGP SIGNATURE----- --=-QR2lQrwmqvh0F7Gx3vSA-- From dmick@utopia.West.Sun.COM Tue Oct 9 20:50:37 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Tue, 09 Oct 2001 12:50:37 -0700 Subject: [Mailman-Developers] CPU Usage References: <20010925151125.77e01be4.rodolfo@linux.org.uy> <15297.8321.928062.891519@geddy.wooz.org> <1002654001.2235.16.camel@claudia> Message-ID: <3BC3550C.2F2D1737@utopia.west.sun.com> > I have this problem every two days. I need to kill -9 the hang python > process (the others mailmanctl can be down with mailmanctl stop) and rm > the /var/.../locks/* and then restart bin/mailmanctl start. > I don't remember if you said, but it would be useful to know what the hung process is doing (truss/strace/whatever) From che@debian.org Wed Oct 10 01:58:58 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 10 Oct 2001 09:58:58 +0900 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists In-Reply-To: <15297.9050.478075.25930@geddy.wooz.org> (barry@zope.com's message of "Sun, 7 Oct 2001 23:54:02 -0400") References: <8766anbcdk.fsf@nausicaa.interq.or.jp> <15297.9050.478075.25930@geddy.wooz.org> Message-ID: <87d73wxqct.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BG> On a massive list (Mailman 2.0.6) I run that regularly gets a BG> few hundred or more emails every day, things begin to slow BG> down to molasses after a week or two each month, with the BG> qrunner process taking literally HUNDREDS of megabytes of RAM, BG> and 100% CPU, all the time. BAW> FWIW, the combined {zope,python}.org gets many hundreds of BAW> messages a day on the python-list and zope mailing lists BAW> alone. I'm not online at the moment, so I can't check, but I BAW> know I receive several digests every day from both lists -- BAW> they're very high traffic. Needless to say, I haven't BAW> noticed any such performance problems... The problem was when the mbox got up to about 200-300 megs; I can send you the traces of the function calls with timestamps, and you can see exactly how slow things get. BAW> If your system still can't handle things, then the next step BAW> is to set ARCHIVE_TO_MBOX to 1. This way, Mailman will BAW> simply append the message to the .mbox file, which ought to BAW> be extremely quick, but it won't attempt to run the Pipermail BAW> archiver in real time. Then you can use whatever archiving BAW> scheme you want (e.g. bin/arch nightly, or an external BAW> archiver). Yes, this is probably the right solution. In fact, I'm actually leaning towards suggesting that Mailman just come with or depend upon hypermail for archiving; we're just re-inventing the wheel by trying to modify pipermail over and over, and it's really not going to scale. Ben -- Brought to you by the letters D and Z and the number 19. "He's like.. some sort of.. non-giving up.. school guy!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From barry@zope.com Wed Oct 10 05:13:55 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 10 Oct 2001 00:13:55 -0400 Subject: [Mailman-Developers] Making the list archive URL configurable References: <20011008172335.F27744@magic.merlins.org> Message-ID: <15299.51971.494731.504152@geddy.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Is there a way to add the archive URL in the list options and MM> the UI (I thought about doint it, but I'm not too familiar MM> with the datbase compatibility issues and the problems with MM> adding a new field in the list options) Does it have to be list specific? I think not, but maybe I'm missing something. The RTTD is probably to make PUBLIC_ARCHIVE_URL a template string, into which the list name will be interpolated, and then change things so they use GetBaseArchiveURL() consistently. That way you could just set PUBLIC_ARCHIVE_URL to "http://www.geocrawler.com/redir-sf.php3?list=%(listname)s" in mm_cfg.py and be done with it. -Barry From barry@zope.com Wed Oct 10 05:04:56 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 10 Oct 2001 00:04:56 -0400 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists References: <8766anbcdk.fsf@nausicaa.interq.or.jp> <15297.9050.478075.25930@geddy.wooz.org> <87d73wxqct.fsf@nausicaa.interq.or.jp> Message-ID: <15299.51432.295921.637638@geddy.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> The problem was when the mbox got up to about 200-300 megs; I BG> can send you the traces of the function calls with timestamps, BG> and you can see exactly how slow things get. My biggest lists are python-list at ~280MB followed by the zope mailing list which is at about 150MB, and I've got a dozen in the 10-100MB range. You're sure you're not gzipping on the fly, right? It would be interesting to see some profiler output. BAW> If your system still can't handle things, then the next step BAW> is to set ARCHIVE_TO_MBOX to 1. This way, Mailman will BAW> simply append the message to the .mbox file, which ought to BAW> be extremely quick, but it won't attempt to run the Pipermail BAW> archiver in real time. Then you can use whatever archiving BAW> scheme you want (e.g. bin/arch nightly, or an external BAW> archiver). BG> Yes, this is probably the right solution. In fact, I'm BG> actually leaning towards suggesting that Mailman just come BG> with or depend upon hypermail for archiving; we're just BG> re-inventing the wheel by trying to modify pipermail over and BG> over, and it's really not going to scale. So far, I've resisted this. I've no problem recommending an external archiver for serious sites, and making it as easy as possible to integrate Mailman with external archivers, but I really don't want to distribute one with Mailman. I feel it'll tie us to closely to some other project, with its own agenda, schedule, compatibility issues, tool chain, etc. etc. I'm under no illusions about making Pipermail a killer archiver, but I also don't think that most sites need much more. I'd rather give folks a moderately useful, bundled archiver and tell them where to go if they're running a high traffic site. -Barry From barry@zope.com Wed Oct 10 04:51:57 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 9 Oct 2001 23:51:57 -0400 Subject: [Mailman-Developers] Bug: "very low level failure" References: <3BC2E702.1F8D3890@mail.dcu.ie> Message-ID: <15299.50653.855946.709462@geddy.wooz.org> >>>>> "DH" == Donal Hunt writes: DH> For once i'm completely stumped. | History: | ------- | Python 2.1.1 on Solaris 8 (Sparc Edtion). | Apache 1.3.20. | Installed Mailman 2.0.6 using: DH> Just get the following message: DH> "Mailman experienced a very low level failure and could not DH> even generate a useful traceback for you. Please report this DH> to the Mailman administrator at this site." I suspect there's something wrong with your Python installation. You'd only get this low level error if you got an exception in the driver script's print_traceback() or print_environment() functions. One thought: are you positive that you're using Python 2.1.1 with the web interface? If the Python you're using doesn't support extended print, that could be your problem. Try running the driver script manually from the install directory. You'll get an exception, but it shouldn't be a low level one (probably an IndexError trying to extract the the cgi program's name from sys.argv). E.g.: % PYTHONPATH=. python -S scripts/driver Make sure `python' is exactly the one you gave on the configure line. If you get some other exception, or error, it should give you an indication of the problem that's occurring. -Barry From che@debian.org Wed Oct 10 06:44:08 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 10 Oct 2001 14:44:08 +0900 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists In-Reply-To: <15299.51432.295921.637638@geddy.wooz.org> (barry@zope.com's message of "Wed, 10 Oct 2001 00:04:56 -0400") References: <8766anbcdk.fsf@nausicaa.interq.or.jp> <15297.9050.478075.25930@geddy.wooz.org> <87d73wxqct.fsf@nausicaa.interq.or.jp> <15299.51432.295921.637638@geddy.wooz.org> Message-ID: <87elocvyl3.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BG> The problem was when the mbox got up to about 200-300 megs; I BG> can send you the traces of the function calls with timestamps, BG> and you can see exactly how slow things get. BAW> My biggest lists are python-list at ~280MB followed by the BAW> zope mailing list which is at about 150MB, and I've got a BAW> dozen in the 10-100MB range. BAW> You're sure you're not gzipping on the fly, right? Absolutely. [ben@yuubin:/usr/lib/mailman/Mailman]% grep -i gzip Defaults.py 2:40PM # Set this to 1 to enable gzipping of the downloadable archive .txt file. # night to generate the txt.gz file. See cron/nightly_gzip for details. GZIP_ARCHIVE_TXT_FILES = 0 [ben@yuubin:/usr/lib/mailman/Mailman]% grep -i gzip mm_cfg.py 2:40PM BAW> It would be interesting to see some profiler output. Here's an example. There are megs and megs where this came from.. Sep 13 19:38:02 2001 (29454) pipelining: ToArchive Sep 13 19:38:02 2001 (29454) forking... Sep 13 19:38:02 2001 (29454) forked, pid 29454. calling handler func ToArchive... Sep 13 19:38:04 2001 (29458) in Message.enqueue() now Sep 13 19:38:04 2001 (29458) opening file: 733417dfede9cc5f09bf35f40d6c3d279830f653 Sep 13 19:38:04 2001 (29458) opening db /var/lib/mailman/qfiles/733417dfede9cc5f09bf35f40d6c3d279830f653.db Sep 13 19:38:04 2001 (29458) exception in msg Sep 13 19:38:04 2001 (29458) msgdata.update newdata Sep 13 19:38:04 2001 (29458) msgdata.update kws Sep 13 19:38:04 2001 (29458) writing data file Sep 13 19:38:04 2001 (29458) done writing data file Sep 13 19:38:04 2001 (29458) writing dirty/new msg to disk Sep 13 19:38:04 2001 (29458) done writing dirty/new msg to disk Sep 13 19:38:06 2001 (29462) in Message.enqueue() now Sep 13 19:38:06 2001 (29462) opening file: 4a2589b46405fdf1691bb83cba6d638e718b932a Sep 13 19:38:06 2001 (29462) opening db /var/lib/mailman/qfiles/4a2589b46405fdf1691bb83cba6d638e718b932a.db Sep 13 19:38:06 2001 (29462) exception in msg Sep 13 19:38:06 2001 (29462) msgdata.update newdata Sep 13 19:38:06 2001 (29462) msgdata.update kws Sep 13 19:38:06 2001 (29462) writing data file Sep 13 19:38:06 2001 (29462) done writing data file Sep 13 19:38:06 2001 (29462) writing dirty/new msg to disk Sep 13 19:38:06 2001 (29462) done writing dirty/new msg to disk Sep 13 19:38:59 2001 (29454) done with handler func ToArchive. I can explain in more detail, but it's pretty obvious that ToArchive starts to thrash pretty badly with a big mbox file. BAW> I feel it'll tie us to closely to some other project, with BAW> its own agenda, schedule, compatibility issues, tool chain, BAW> etc. etc. I'm under no illusions about making Pipermail a BAW> killer archiver, but I also don't think that most sites need BAW> much more. I'd rather give folks a moderately useful, BAW> bundled archiver and tell them where to go if they're running BAW> a high traffic site. If we go this route, we must do a big overhaul on pipermail. It tries to do way too much as it is, and fails spectacularly on systems other than mine when the mbox file gets too big. Ben -- Brought to you by the letters Y and P and the number 12. "Porcoga daisuki!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From a.k.heath@shu.ac.uk Wed Oct 10 11:58:37 2001 From: a.k.heath@shu.ac.uk (Andy Heath) Date: Wed, 10 Oct 2001 11:58:37 +0100 Subject: [Mailman-Developers] multiple mailpeople on same box Message-ID: <3BC429DD.A871A5C@shu.ac.uk> This is a bit "howto" so forgive me for asking here but suspect the knowledge only with the developers and not documented anywhere yet - I'm wanting to get seriously into 2.1a2 (maybe should ask this on the i18n list) and do some hacking - have only one box and need to continue running existing lists - what are the constraints on running multiple mailmans (mailmen ? mailwomen?) concurrently on the same system ? Thoughts: 1. Can I use same UID and GID , use $prefix to another directory, merge the crontabs and tailor some URL path info for apache so the right URL's invoke different mailman instances ? I'm currently using my own hacked version of Archiver.py with hypermail for archiving some lists and pipermail with others on a per-list basis. 2. Must I abandon 1. and use on separate id/group for each (painful to administer) ? 3. Are there other potential clash points than the ones I have identified ? 4. Any resource problems with 2.1a2 that would upset the concurrent running of 2.0.6 (such as memory hogging or crashing and filling device space or similar) - I don't want to upset my list communities running on 2.0.6. andy -- andy From jwblist@olympus.net Wed Oct 10 18:33:19 2001 From: jwblist@olympus.net (John W Baxter) Date: Wed, 10 Oct 2001 10:33:19 -0700 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists In-Reply-To: <87d73wxqct.fsf@nausicaa.interq.or.jp> References: <8766anbcdk.fsf@nausicaa.interq.or.jp> <15297.9050.478075.25930@geddy.wooz.org> <87d73wxqct.fsf@nausicaa.interq.or.jp> Message-ID: At 9:58 +0900 10/10/2001, Ben Gertzfield wrote: >Yes, this is probably the right solution. In fact, I'm actually >leaning towards suggesting that Mailman just come with or depend >upon hypermail for archiving; we're just re-inventing the wheel >by trying to modify pipermail over and over, and it's really not >going to scale. A problem here is that Hypermail is far from the only game in town. I don't know its current state: hopefully much better than when we tossed it out about 5 years ago. Should mailman be picking the outside archiver to use, or should it just make it easy to use SOME outside archiver? (If there is some archiver which is "the GNU archiver" in the sense that Mailman is "the GNU mailing list manager, I suppose that one could reasonably be favored.) --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From marc_news@valinux.com Wed Oct 10 19:12:20 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Wed, 10 Oct 2001 11:12:20 -0700 Subject: [Mailman-Developers] Making the list archive URL configurable In-Reply-To: <15299.51971.494731.504152@geddy.wooz.org>; from barry@zope.com on Wed, Oct 10, 2001 at 12:13:55AM -0400 References: <20011008172335.F27744@magic.merlins.org> <15299.51971.494731.504152@geddy.wooz.org> Message-ID: <20011010111220.Q27744@magic.merlins.org> On Wed, Oct 10, 2001 at 12:13:55AM -0400, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN writes: > > MM> Is there a way to add the archive URL in the list options and > MM> the UI (I thought about doint it, but I'm not too familiar > MM> with the datbase compatibility issues and the problems with > MM> adding a new field in the list options) > > Does it have to be list specific? I think not, but maybe I'm missing > something. In my case probably not, but I can see it as better if list specific (some list admins subscribe their list to an external archiver and would like to point mailman's archives for their list to it) > The RTTD is probably to make PUBLIC_ARCHIVE_URL a template string, > into which the list name will be interpolated, and then change things > so they use GetBaseArchiveURL() consistently. > > That way you could just set PUBLIC_ARCHIVE_URL to > "http://www.geocrawler.com/redir-sf.php3?list=%(listname)s" in > mm_cfg.py and be done with it. In my specific case *right*now*, that would be enough (afterall, that's what I did with my patch). In a more generic case, per list would be better :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jarrell@vt.edu Wed Oct 10 20:06:54 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 10 Oct 2001 15:06:54 -0400 Subject: [Mailman-Developers] importing mailman lists... Message-ID: <5.1.0.14.2.20011010150322.025c2e00@lennier.cc.vt.edu> I've been asked to serve a couple of lists on my production mm server (2.0.5) that are coming from a 1.0 server. If I just accept a tar of the list directories, will a make update do the right thing, or am I screwed by the fact that the other lists have already been upgraded from 1.0 to 2.0.5 over the years? From michael@cmo.uqam.ca Wed Oct 10 22:00:46 2001 From: michael@cmo.uqam.ca (Michael Totschnig) Date: Wed, 10 Oct 2001 17:00:46 -0400 Subject: [Mailman-Developers] error raised by senddigests Message-ID: <86bsjfrz0h.fsf@cmo.uqam.ca> Hello, after updating CVS yesterday, I get the following error. Regards, Michael Traceback (most recent call last): File "/var/Mailman//cron/senddigests", line 52, in ? main() File "/var/Mailman//cron/senddigests", line 44, in main mlist.send_digest_now() File "/var/Mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/Mailman/Mailman/Handlers/ToDigest.py", line 136, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/Mailman/Mailman/Handlers/ToDigest.py", line 256, in send_i18n_digests for field in keeper[keep]: TypeError: loop over non-sequence From liuk@publinet.it Wed Oct 10 22:10:03 2001 From: liuk@publinet.it (Luca Maranzano) Date: Wed, 10 Oct 2001 23:10:03 +0200 Subject: [Mailman-Developers] Handling of Posts held for approval and attachments Message-ID: <20011010231003.A2051@publinet.it> Hi, I've noticed that for a moderated list, when the moderator goes to the Web interface for processing "Posting held for approval", in the "Message Excerpt" box a long message gets truncated; is this a bug or a feature? The word "excerpt" suggests me that this is a feature :) but IMO in this way a moderator would never see a part of the message which could make him decide to not approve the message. Besides, the moderator is not able to see if a message contains an attach (and its relative size), so he/she can eventually post a message with a big attach without knowing this :) Thanks in advance for your comments about this. Regards, Luca From dmick@utopia.West.Sun.COM Wed Oct 10 22:32:35 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Wed, 10 Oct 2001 14:32:35 -0700 Subject: [Mailman-Developers] Handling of Posts held for approval and attachments References: <20011010231003.A2051@publinet.it> Message-ID: <3BC4BE72.C445FD12@utopia.west.sun.com> >From Defaults.py (which, if you want to change it, as always, put something in mm_cfg.py to override the Defaults setting): # how many bytes of a held message post should be displayed in the admindb web # page? Use a negative number to indicate the entire message, regardless of # size (though this will slow down rendering those pages). ADMINDB_PAGE_TEXT_LIMIT = 4096 Really, it's good to read through Defaults.py and see what else is customizable. Luca Maranzano wrote: > > Hi, > > I've noticed that for a moderated list, when the moderator goes > to the Web interface for processing "Posting held for approval", > in the "Message Excerpt" box a long message gets truncated; > is this a bug or a feature? The word "excerpt" suggests me that > this is a feature :) but IMO in this way a moderator would > never see a part of the message which could make him decide > to not approve the message. > > Besides, the moderator is not able to see if a message contains > an attach (and its relative size), so he/she can eventually > post a message with a big attach without knowing this :) > > Thanks in advance for your comments about this. > > Regards, > Luca > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From tneff@bigfoot.com Wed Oct 10 23:47:05 2001 From: tneff@bigfoot.com (tneff@bigfoot.com) Date: Wed, 10 Oct 2001 18:47:05 -0400 Subject: [Mailman-Developers] A 2.0.x patch to edit pending message headers and bodies In-Reply-To: References: Message-ID: <21095062.1002739625@t283742ghzz> I will leave the ethical debates to others, but if you need to clean up messages before approving them through, this patch lets you do it. Works for me on 2.0.6 which means I can finally upgrade from my patched 1.1 on lists that need it. :) *** Mailman/Cgi/admindb.py.orig Wed Oct 10 13:31:46 2001 --- Mailman/Cgi/admindb.py Wed Oct 10 18:30:25 2001 *************** *** 270,275 **** --- 270,277 ---- continue # get the action comment and reasons if present commentkey = 'comment-%d' % request_id + headerskey = 'headers-%d' % request_id + contentskey = 'fulltext-%d' % request_id preservekey = 'preserve-%d' % request_id forwardkey = 'forward-%d' % request_id forwardaddrkey = 'forward-addr-%d' % request_id *************** *** 278,285 **** --- 280,293 ---- preserve = 0 forward = 0 forwardaddr = '' + headers = '' + contents = '' if cgidata.has_key(commentkey): comment = cgidata[commentkey].value + if cgidata.has_key(headerskey): + headers = cgidata[headerskey].value + if cgidata.has_key(contentskey): + contents = cgidata[contentskey].value if cgidata.has_key(preservekey): preserve = cgidata[preservekey].value if cgidata.has_key(forwardkey): *************** *** 290,296 **** # handle the request id try: mlist.HandleRequest(request_id, v, comment, ! preserve, forward, forwardaddr) except (KeyError, Errors.LostHeldMessage): # that's okay, it just means someone else has already updated the # database, so just ignore this id --- 298,304 ---- # handle the request id try: mlist.HandleRequest(request_id, v, comment, ! preserve, forward, forwardaddr, headers, contents) except (KeyError, Errors.LostHeldMessage): # that's okay, it just means someone else has already updated the # database, so just ignore this id *** Mailman/ListAdmin.py.orig Wed Oct 10 13:31:46 2001 --- Mailman/ListAdmin.py Wed Oct 10 18:40:27 2001 *************** *** 122,133 **** return type def HandleRequest(self, id, value, comment=None, preserve=None, ! forward=None, addr=None): self.__opendb() rtype, data = self.__db[id] if rtype == HELDMSG: status = self.__handlepost(data, value, comment, preserve, ! forward, addr) else: assert rtype == SUBSCRIPTION status = self.__handlesubscription(data, value, comment) --- 122,133 ---- return type def HandleRequest(self, id, value, comment=None, preserve=None, ! forward=None, addr=None, headers=None, contents=None): self.__opendb() rtype, data = self.__db[id] if rtype == HELDMSG: status = self.__handlepost(data, value, comment, preserve, ! forward, addr, headers, contents) else: assert rtype == SUBSCRIPTION status = self.__handlesubscription(data, value, comment) *************** *** 172,178 **** data = time.time(), sender, msgsubject, reason, filename, msgdata self.__db[id] = (HELDMSG, data) ! def __handlepost(self, record, value, comment, preserve, forward, addr): # For backwards compatibility with pre 2.0beta3 if len(record) == 5: ptime, sender, subject, reason, filename = record --- 172,178 ---- data = time.time(), sender, msgsubject, reason, filename, msgdata self.__db[id] = (HELDMSG, data) ! def __handlepost(self, record, value, comment, preserve, forward, addr, headers, contents): # For backwards compatibility with pre 2.0beta3 if len(record) == 5: ptime, sender, subject, reason, filename = record *************** *** 181,186 **** --- 181,202 ---- # New format of record ptime, sender, subject, reason, filename, msgdata = record path = os.path.join(mm_cfg.DATA_DIR, filename) + # Handle editing + if len(headers)+len(contents): + fp = open(path) + unixfrom = fp.readline() + rest = fp.read() + # Parse headers and body + parts = string.split(rest,'\n\n') + if len(headers) == 0: + headers = parts[0] + if len(contents) == 0: + contents = parts[1] + fp.close + # Now write the changed result + fp = open(path,'w') + fp.write(unixfrom + headers + '\n\n' + contents) + fp.close # Handle message preservation if preserve: parts = string.split(os.path.split(path)[1], '-') From barry@zope.com Wed Oct 10 04:20:39 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 9 Oct 2001 23:20:39 -0400 Subject: [Mailman-Developers] CPU Usage References: <20010925151125.77e01be4.rodolfo@linux.org.uy> <15297.8321.928062.891519@geddy.wooz.org> <1002654001.2235.16.camel@claudia> Message-ID: <15299.48775.281415.45163@geddy.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: RP> Dear Barry, thank you for your reply. RP> I have this problem every two days. I need to kill -9 the RP> hang python process (the others mailmanctl can be down with RP> mailmanctl stop) and rm the /var/.../locks/* and then restart RP> bin/mailmanctl start. Using some other signal doesn't kill mailmanctl? You have to use -9? RP> If I do not rm the locks/ directory the mailmanctl start says RP> that I have another daemon pid into /var/.../data/qrunner.pid RP> but this file do not exists. (the problem is the RP> /var/.../locks/ directory!) It makes sense that if you kill -9 the process, you'd have to clean up the locks and pid file. Processes can't catch SIGKILL so Mailman can't exit cleanly when this signal is sent. RP> Please, feel free to contact me if you wish that I test some RP> other version of the qrunner. I'm probably going to go through one more round of rewrite of mailmanctl. I don't like the fact that you have to do a stop/start cycle when you (well, really I ;) make a change to the mail processing code. I can't implement a "restart" command given the current code because imports get in the way. I probably need to do an exec after the fork to make this work well. In any event, I'll stress test this after the rewrite. I have also seen some strange stuff with mailmanctl, but I haven't spent the time yet to track them down. -Barry From barry@zope.com Wed Oct 10 04:03:27 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 9 Oct 2001 23:03:27 -0400 Subject: [Mailman-Developers] bug in Handlers/Tagger.py References: <3BBE7BF5.550F9B45@is.kochi-u.ac.jp> <20011008143336.A5136@publinet.it> <3BC233D8.48E485C6@utopia.west.sun.com> Message-ID: <15299.47743.951413.472340@geddy.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Yeah, these are changes from mimelib to email. There are DM> several; I've sent them off to Barry but I think he's buried DM> in Python 2.2 release hell at the moment. The checkins should be caught up now. There may be more mimelib->email changes to be made though. -Barry From barry@zope.com Thu Oct 11 03:56:55 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 10 Oct 2001 22:56:55 -0400 Subject: [Mailman-Developers] error raised by senddigests References: <86bsjfrz0h.fsf@cmo.uqam.ca> Message-ID: <15301.2679.270726.904462@geddy.wooz.org> >>>>> "MT" == Michael Totschnig writes: MT> after updating CVS yesterday, I get the following error. Thanks. Should be fixed now. -Barry From Dale Newfield Thu Oct 11 05:12:04 2001 From: Dale Newfield (Dale Newfield) Date: Thu, 11 Oct 2001 00:12:04 -0400 (EDT) Subject: [Mailman-Developers] A 2.0.x patch to edit pending message headers and bodies In-Reply-To: <21095062.1002739625@t283742ghzz> Message-ID: On Wed, 10 Oct 2001 tneff@bigfoot.com wrote: > I will leave the ethical debates to others, but if you need to clean > up messages before approving them through, this patch lets you do it. > Works for me on 2.0.6 Any chance we can get something like this in 2.1? --- Dale Newfield "My country, right or wrong" is not a cogent argument. It is one step away from "I was only following orders." From tneff@bigfoot.com Thu Oct 11 17:30:07 2001 From: tneff@bigfoot.com (Tom Neff) Date: Thu, 11 Oct 2001 12:30:07 -0400 Subject: [Mailman-Developers] Re: A 2.0.x patch to edit pending message headers and bodies In-Reply-To: References: Message-ID: <52141515.1002803405@[192.168.1.101]> Dale Newfield wrote: > On Wed, 10 Oct 2001 tneff@bigfoot.com wrote: >> I will leave the ethical debates to others, but if you need to clean >> up messages before approving them through, this patch lets you do it. >> Works for me on 2.0.6 > > Any chance we can get something like this in 2.1? Yes, as a patch, after 2.1 goes gold. I don't chase alphas. From barry@zope.com Thu Oct 11 19:24:33 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Oct 2001 14:24:33 -0400 Subject: [Mailman-Developers] Re: some Python announcements are lost (LONG) References: <20011010213802.V11545@xs4all.nl> <15300.42428.723922.910260@slothrop.digicool.com> <20011010225539.W11545@xs4all.nl> <15301.51800.589500.704612@slothrop.digicool.com> Message-ID: <15301.58337.392482.108083@anthem.wooz.org> Background: Mailman 2.0.6 has a problem in its mail->news gateway related to the strictness of the NNTP server being posted to. This bites python.org for the two mailing lists that are gatewayed to/from netnews. python-list@python.org is a simple bi-directional gateway, such that any message originally posted to comp.lang.python is gatewayed to python-list, and vice versa. The comp.lang.python.announce newsgroup is gated to python-announce-list@python.org, but the route is a bit more circuitous because c.l.py.a is a moderated newsgroup. On python.org, we have a MM2.0.6 patch with SF patch #101270 that implements a hack for moderated newsgroup gatewaying. I plan on making this patch more official for MM2.1, but we need to first deal with the following problem. Problem: In the logs/error file on python.org we occasionally see rejections of messages posted to the news server via the ToUsenet.py module. Here are some examples of the reject log entries: Dec 18 07:31:00 2000 (15053) (ToUsenet) NNTP error for list "clpa-moderators": 441 Can't set system "NNTP-Posting-Host" header Dec 20 17:46:04 2000 (10666) (ToUsenet) NNTP error for list "clpa-moderators": 441 Can't set system "X-Complaints-To" header Jan 03 17:21:02 2001 (17750) (ToUsenet) NNTP error for list "clpa-moderators": 441 Duplicate "To" header Jan 05 12:52:06 2001 (32547) (ToUsenet) NNTP error for list "python-list": 441 Duplicate "Cc" header Jan 06 14:43:07 2001 (31278) (ToUsenet) NNTP error for list "python-list": 441 437 Binary in non-binary group Jan 22 07:22:30 2001 (2822) (ToUsenet) NNTP error for list "python-list": 441 Line 201 too long Jan 24 12:45:01 2001 (5285) (ToUsenet) NNTP error for list "clpa-moderators": 441 Can't set system "X-Trace" header Jan 24 15:56:29 2001 (17406) (ToUsenet) NNTP error for list "python-list": 441 No valid newsgroups in "['comp.object.corba', 'comp.object.C++', 'comp.object.C++.moderated', 'comp...." Feb 17 08:17:24 2001 (13293) (ToUsenet) NNTP error for list "python-list": 441 Can't parse "Date" header Feb 23 05:01:02 2001 (25246) (ToUsenet) NNTP error for list "python-list": 441 Article posted in the future Mar 19 00:20:34 2001 (15766) (ToUsenet) NNTP error for list "python-list": 441 From: address not in Internet syntax May 10 15:52:16 2001 (17585) (ToUsenet) NNTP error for list "python-list": 441 Duplicate "Mime-Version" header Jun 12 09:24:01 2001 (772) (ToUsenet) NNTP error for list "python-list": 441 437 Too old -- "Fri, 05 Jan 1996 16:48:56 -0600" When MM2.0.x gets such an exception, it simply drops the message on the floor. It doesn't save it, or bounce it, and this has definitely lead to lost messages. It appears that lossage is more prevalent in the python-list-announce list than in the python-list, or perhaps it's more obvious because patch #101270 sets things up such that the message is never seen by anybody unless it flows first through Usenet. python-list lossages simply won't cross the mail->news boundary, but any message posted on the mailing list will be seen by all list members and messages posted to the newsgroup will be seen by all newsgroup readers and all list members. FTR: our posting host is news.baymountain.com a hosting service that Zope Corporation uses and which gives us a newsfeed for the gatewayed groups on mail.python.org. % telnet news.baymountain.com nntp Trying 63.102.48.11... Connected to news.baymountain.com. Escape character is '^]'. 201 news.baymountain.net InterNetNews NNRP server INN 2.2.2 13-Dec-1999 ready (no posting). I'm looking for a principled way of handling such exceptions, both for MM2.0.x and for MM2.1. There are two sides to this: what can we do to avoid the rejections in the first place, and what to do when we can't avoid rejections. First, it seems like exactly what the news server will reject is not completely guessable, although there are some hints available. AFAICT, there is no standard, or even good documentation available on this subject except the INN source code, and an IETF Internet-Draft called draft-ietf-usefor-article-05. This latter says that an injecting agent (i.e. the nntpd Mailman is posting to), should remove some headers and must remove others. Being a draft though, we can't rely on this and besides, because the injecting agent has the option of not stripping some of the offending headers, and rejecting the message anyway, we've still got to deal with it. >From a post on news.software.nntp, I found a list of "forbidden" headers that a normally configured INN will reject: "NNTP-Posting-Host" "X-Trace" "X-Complaints-To" "NNTP-Posting-Date" "Xref" "Date-Received" "Received" "Posted" "Posting-Version" "Relay-Version" Okay, so that's a start, however INN can apparently be configured to reject or accept other combinations of headers, so we can't rely on this list. That leads me to think that at the least, we want a Mailman configuration variable that lists the headers ToUsenet should strip before attempting to post the message. Now we come to the issue of illegal duplicate headers, like To: and Cc:. Well, I don't think we want to strip these, and I'm not comfortable with folding them (i.e. folding multiple Cc: headers into one big long one), so that leads me to think that we want another configuration variable that will transform duplicates to X-* headers. It's a bit distasteful that you'd have a message posted through that will have one Cc: header and a bunch of X-Original-Cc: headers, and it seems stupid that INN rejects multiple Cc: or To: headers, but it seems we have no choice here. One thing I want to try to avoid, because it seems error prone and too complicated, is to try to grep out the exact problem in the 441 rejection message, then massage the posting and attempt to repost until we're out of options. Now, given the above, we can get rid of probably 90% of the rejections, but we'll still be left with some that are inconvenient to handle programmatically. Like the "No valid newsgroups' or "Binary in non-binary group" rejections. So here comes the second part. In MM2.1 we can take any rejected message, encapsulate it into a MIME document, and send it and the rejection notice to the list moderators. The list moderators can then apply some wetware algorithms to the problem and resend it to the list. We'll have to invent some mechanism that a moderator could use to tell Mailman that this is an approved/munged Usenet post and that it ought not to go to the list membership, but that should be easy (perhaps another list-robot address or a special header for list-request to look at). In MM2.0.x it's harder to craft that message and get it sent to the list moderators correctly, so I propose to write a simple patch that just saves the message on disk some place and then sends a notification to the list moderators. They'll have to coordinate with the site moderators to get the message posted, but at least it won't get lost as it currently does. Hmm, here's another thought: what if the rejected message were held in the pending database? I'm not sure if that'll be possible (the main problem being that all the actual posting stuff happens in a child proc that can't lock the list), but if it were, then the recently posted patch to allow editing of held messages thru-the-web could be used to edit the message and re-approve it for posting. That's an approach that might work in MM2.1 if the edit-held-message patch is accepted. Hopefully someone out there will have some better ideas. I'd also love any other pointers to standards or documentation on this matter. -Barry From jarrell@vt.edu Thu Oct 11 20:40:56 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Oct 2001 15:40:56 -0400 Subject: [Mailman-Developers] importing mailman lists... In-Reply-To: <5.1.0.14.2.20011010150322.025c2e00@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20011011141258.07516a90@lennier.cc.vt.edu> At 03:06 PM 10/10/01 -0400, I wrote: >I've been asked to serve a couple of lists on my production mm server (2.0.5) >that are coming from a 1.0 server. If I just accept a tar of the list directories, >will a make update do the right thing, or am I screwed by the fact that the other >lists have already been upgraded from 1.0 to 2.0.5 over the years? I decided that I could hack update with some work to just forcibly do a 1.0 to 2.0.5 upgrade on just those lists... Or, plan B, which is what I actually ended up doing because I figured it'd be faster, was set up another directory, grap the Release_1_0 cvs image, build and install that, drop the lists into it, then install the Release_2_5 image on top of it, and let update do what it normally does... Since I could do it all in the background it took less of my real time than hacking the python would... From jarrell@vt.edu Thu Oct 11 21:21:41 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 11 Oct 2001 16:21:41 -0400 Subject: [Mailman-Developers] Re: some Python announcements are lost (LONG) In-Reply-To: <15301.58337.392482.108083@anthem.wooz.org> References: <20011010213802.V11545@xs4all.nl> <15300.42428.723922.910260@slothrop.digicool.com> <20011010225539.W11545@xs4all.nl> <15301.51800.589500.704612@slothrop.digicool.com> Message-ID: <5.1.0.14.2.20011011160837.071e2e80@lennier.cc.vt.edu> At 02:24 PM 10/11/01 -0400, Barry A. Warsaw wrote: You should post something to inn-workers@isc.org; Russ Albery, who's working on the new nntp RFC is an INN coder. I'm on that list too. However, you really need a generic solution, since INN isn't the only major news product out there, and they all have their ideas. Plus, you're not just dealing with INN here. From your logs: >Jan 06 14:43:07 2001 (31278) (ToUsenet) NNTP error for list "python-list": 441 437 Binary in non-binary group > >Okay, so that's a start, however INN can apparently be configured to >reject or accept other combinations of headers, so we can't rely on >this list. This isn't a case of INN being configured to reject extra headers; your provider installed CleanFeed, which is an anti-spam filter, which is what issued the 437 Binary in a non-binary group error. CleanFeed can do whatever it wants, and has all sorts of widgets for analyzing messages. Some of the other errors came from situations that shouldn't have happened. Like the gateway should never have let a message get to the news server with a list of groups to post to, of which none exist. That's a configuration error on the admins part. Also, it shouldn't have let multiple To's into the note. The message to old, or in the future, or unparsable also isn't particularly mm's fault - it's the same issue we have with the archives, it's just that news, which actually computes the unix time of a message for expiration purposes, validates the date header more than we do, where, largely, it's just a string to us. INN does have it's own, canonical, stupid, mail to news gateway; you might review it's code to see what it does. Really, it primarily gets cranky about you inserting what's viewed as a "security" header via NNTP. It's less cranky if you inject it directly with inews, because you can, if suffciently trusted, just tell it 'Use these headers' and it believes you. Which is bsaically the same issue as the "deliver mail via sendmail vs. via smtpdirect" thing - talk to the daemon, accept the daemon's restrictions. From peterw@usa.net Thu Oct 11 22:06:23 2001 From: peterw@usa.net (Peter W) Date: Thu, 11 Oct 2001 17:06:23 -0400 Subject: [Mailman-Developers] privacy problems with Web interface Message-ID: <20011011170623.A6625@usa.net> Last month, Federico Grau posted about some privacy leakage concerns with Mailman 1.1. He offered suggestions and suggested he might be willing to submit patches back to the project to handle these issues.[0] Nobody responded to his questions or offer, and it seems that at least Mailman version 2.0.x has the same sort of problems. Two questions: 1) Is anyone working on closing these holes in 2.1 or later? 2) Would this project welcome patches that address these privacy problems into the main branch? Thank you, -Peter [0] see the archived post at http://mail.python.org/pipermail/mailman-developers/2001-September/009619.html From barry@zope.com Thu Oct 11 23:14:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Oct 2001 18:14:46 -0400 Subject: [Mailman-Developers] privacy problems with Web interface References: <20011011170623.A6625@usa.net> Message-ID: <15302.6614.57378.359025@anthem.wooz.org> >>>>> "PW" == Peter W writes: PW> Two questions: PW> 1) Is anyone working on closing these holes in 2.1 or later? Yes. I will follow up to Federico's original message shortly. PW> 2) Would this project welcome patches that address these PW> privacy problems into the main branch? Yes, but be sure you're current with CVS. I'm going to see if I can beat you to it. ;) -Barry From barry@zope.com Thu Oct 11 23:54:04 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Oct 2001 18:54:04 -0400 Subject: [Mailman-Developers] privacy problems with web interface References: <20010922162341.A31731@casagrau.org> Message-ID: <15302.8972.748996.37262@anthem.wooz.org> >>>>> "FG" == Federico Grau writes: FG> As distributed, Mailman makes it trivial to discover FG> if a given address is in fact a subscriber. If you suspect FG> dev@null.com has joined a list, go to the user page and FG> enter his address to subscribe; you'll get back a revealing FG> reply 'You already belong, dummy'.. What we can do for MM2.1 is, if the subscriber list is not public, i.e. private_roster is not "Anyone", then if they attempt to subscribe an already subscribed address, we can show them a results page that looks no different whether they actually are subscribed or not. Then if they are subscribed, we'll send the user a message saying somebody tried to subscribe their address (should we email the admin too?). If they aren't subscribed, then we'll do the normal routine. (I need to make sure the web message you'd see is identical regardless of whether you're subscribed or not. That's a little tricky, but doable.) FG> We looked at modifying the html on the user pages but the FG> python module "handle_opts" seems hard-coded into giving FG> revealing responses. We also glanced at Mailman 2.0.6 but it FG> seemed to offer the same behavior. FG> Has anyone else already looked into this issue, and proposed FG> code to solve it? We are considering writing a patch for FG> "handle_opts" and and submitting it but 1) don't want to fork FG> the code, and 2) don't want to duplicate/waste the effort. In MM2.1, this is done by the options.py cgi script. Here we need to do something similar, but again, it's a little tricky. If the user is subscribed, and a url containing their email address is given, then they are presented with a page prompting only for their password. If the email address is incorrect, or missing in the url, then they are prompted for both their address and password. This needs to change such that if private_roster is not "Anyone", then the same sets of prompts will be given regardless of whether the address is a member or not. That leads me to think that if private_roster <> "Anyone" then if any email address is given, we'll only prompt for the password. Obviously, there'll be no matching password, so the error condition in both cases will be to return them to the options prompt page, asking for both email address and password. This should avoid leaking any membership information. I'll work on getting that into MM2.1. Watch CVS. -Barry From a.k.heath@shu.ac.uk Fri Oct 12 09:15:23 2001 From: a.k.heath@shu.ac.uk (Andy Heath) Date: Fri, 12 Oct 2001 09:15:23 +0100 Subject: [Mailman-Developers] 2.1a2 and 2.0.6 on same box Message-ID: <3BC6A69B.A087B828@shu.ac.uk> No responses so try again with better subject categorisation - must ask here because its about 2.1a2. Someone else *must* be doing this already, surely - I'm wanting to get seriously into 2.1a2 and do some hacking (small quantity of free labour here) - have only one box and need to continue running existing lists on 2.0.6 - what are the constraints on running multiple mailmans (mailmen ? mailwomen?) concurrently on the same system ? Thoughts: 1. Can I use same UID and GID , use $prefix to another directory, merge the crontabs and tailor some URL path info for apache so the right URL's invoke different mailman instances ? I'm currently using my own hacked version of Archiver.py with hypermail for archiving some lists and pipermail with others on a per-list basis. 2. Must I abandon 1. and use on separate id/group for each (more painful to administer) ? 3. Are there other potential clash points than the ones I have identified ? 4. Any resource problems with 2.1a2 that would upset the concurrent running of 2.0.6 (such as memory hogging or crashing and filling device space or similar) - I don't want to upset my list communities running on 2.0.6. I notice posts on here recently about a daemon refusing to restart but don't know the background to this. -- andy From tkikuchi@is.kochi-u.ac.jp Fri Oct 12 11:59:39 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 12 Oct 2001 19:59:39 +0900 Subject: [Mailman-Developers] 2.1a2 and 2.0.6 on same box References: <3BC6A69B.A087B828@shu.ac.uk> Message-ID: <3BC6CD1B.5A66A4C4@is.kochi-u.ac.jp> Hi, Andy Heath wrote: > > No responses so try again with better subject categorisation - > must ask here because its about 2.1a2. Someone else *must* be > doing this already, surely - > I am running both 2.0.6 and 2.1a2 on same box, same UID and same GID but different installation tree. You also need to set up a defferent ScriptAlias in Apache httpd.conf. 2.0.6(Japanized version) as http://mm.tkikuchi.net/mailman/listinfo --prefix=/home/mailman2 ScriptAlias /mailman/ /home/mailman2/cgi-bin/ 2.1a2 as http://mm.tkikuchi.net/mailman-i18n/listinfo --prefix=/home/mailman3 ScriptAlias /mailman-i18n/ /home/mailman3/cgi-bin/ (--prefix=/home/mailman is reserved for another Vhost) Happy hacking ! -- Tokio From barry@zope.com Fri Oct 12 17:26:28 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Oct 2001 12:26:28 -0400 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists References: <8766anbcdk.fsf@nausicaa.interq.or.jp> <15297.9050.478075.25930@geddy.wooz.org> <87d73wxqct.fsf@nausicaa.interq.or.jp> Message-ID: <15303.6580.861595.652040@geddy.wooz.org> >>>>> "JWB" == John W Baxter writes: JWB> Should mailman be picking the outside archiver to use, or JWB> should it just make it easy to use SOME outside archiver? It should, and it does, AFAIK. If there are specific problems with external archive integration, let me know. -Barry From barry@zope.com Fri Oct 12 21:20:49 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Oct 2001 16:20:49 -0400 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists References: <8766anbcdk.fsf@nausicaa.interq.or.jp> <15297.9050.478075.25930@geddy.wooz.org> <87d73wxqct.fsf@nausicaa.interq.or.jp> <15299.51432.295921.637638@geddy.wooz.org> <87elocvyl3.fsf@nausicaa.interq.or.jp> Message-ID: <15303.20641.881755.599527@geddy.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> The problem was when the mbox got up to about 200-300 megs; I BG> can send you the traces of the function calls with timestamps, BG> and you can see exactly how slow things get. >>>>> "BAW" == Barry A Warsaw writes: BAW> My biggest lists are python-list at ~280MB followed by the BAW> zope mailing list which is at about 150MB, and I've got a BAW> dozen in the 10-100MB range. BAW> It would be interesting to see some profiler output. BG> Here's an example. There are megs and megs where this came BG> from.. [profiling deleted] BG> I can explain in more detail, but it's pretty obvious that BG> ToArchive starts to thrash pretty badly with a big mbox file. I think you need to investigate this more. I'd like to see exactly how you instrumented ToArchive.py to get these numbers. I think something else is going on with your system. Here's what I did: I took python-list.mbox from mail.python.org. This is about 280MB. I installed that as the mbox file for a local test list, and ran bin/arch on it to initialize the archive. Then I instrumented MM2.0.6's ToArchive.py like so: # TBD: this needs to be converted to the new pipeline machinery t0 = time.time() mlist.ArchiveMail(msg, msgdata) t1 = time.time() syslog('debug', 'ArchiveMail time: %s seconds' % (t1 - t0)) On an unloaded system, this took 1.08 seconds. Much less than the 53 seconds between these two lines in your output: -------------------- snip snip -------------------- Sep 13 19:38:06 2001 (29462) done writing dirty/new msg to disk Sep 13 19:38:59 2001 (29454) done with handler func ToArchive. -------------------- snip snip -------------------- When I send 3 or 4 messages into the queue at the same time, the average time in ArchiveMail() is 0.2 seconds. I could try instrumenting ToArchive.py on the live site, but I suspect I'll get very similar numbers. Also, your output implies there's some forking going on. Where's that happening? The only forking the MM2.0.6 code base does is in the ToUsenet.py handler (oh and the test cases for LockFile.py but that obviously doesn't count). -Barry From barry@zope.com Fri Oct 12 21:39:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Oct 2001 16:39:25 -0400 Subject: [Mailman-Developers] [PATCH] Port HyperArch/pipermail to mimelib References: <87g09rd1x2.fsf@nausicaa.interq.or.jp> Message-ID: <15303.21757.261400.496234@geddy.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Here's a port of HyperArch and pipermail to mimelib. This BG> allows proper parsing of multipart messages, and will make BG> i18n handling much easier. This is a big step forward, I BG> think, because now we no longer have two very different BG> Message classes in Mailman. I'm still looking at this patch. I have some qualms about it. If I commit this patch, we'll need to further do the mimelib->email conversion, but that shouldn't be hard. First... BG> This also patches pythonlib/mailbox.py to use mimelib instead BG> of rfc822. This is the last use of rfc822 in Mailman, so we BG> can now remove pythonlib/rfc822.py completely from the BG> archives -- now we use mimelib entirely! It also modifies pythonlib/cgi.py to use mimelib. Neither are good ideas because it means our copies get farther out of sync with Python's and we'll always have to carry around our copies. The purpose of the Mailman/pythonlib directory is to allow us to defer requiring newer versions of Python. Right now, Mailman should work with Python 2.0, but some of the modules that have been patched since then have useful stuff we need now. So I put copies of the latest standard library files in Mailman/pythonlib as a form of forward compability. Eventually, I can remove these once I require a version of Python that has these patches in them. An example is Cookie.py. When MM required only Py1.5.2, I had to provide a Cookie.py, but because Py2.0 has its own Cookie.py, we can use that and forget about our own copy. Similarly with cgi.py, rfc822.py, and others (I do need to do a bit of cleaning up here though). Fortunately, I think your changes to cgi.py aren't necessary, and we can accomplish your mailbox.py changes by changing Mailman/Mailbox.py instead. We do still need rfc822.py (I think) because email/mimelib package in some cases just wraps rfc822.py code instead of reimplementing or cutting-and-pasting the source. BG> This patch depends on the mimelib patch I just sent; it uses BG> the get_decoded_payload() function I added to get a nice text BG> representation of even a multi-part message. This will let us BG> even display a message for non-text parts of a message, and BG> eventually will let HyperArch display attachments inline. And BG> of course, as I mentioned in my previous mail, this will BG> prevent base64 gobbeldygook from showing up in the archives. BG> This patch even deals with multiple text/* attachments to a BG> message, and will include them all in the archive even if BG> they're base64 or quoted-printable encoded. I think this is a decent patch, and I'm probably going to commit these, after I rewrite them for the email package. BG> It currently does not deal with replacing high-ASCII BG> characters with HTML entities in HyperArch; I'm going to deal BG> with that next by taking the htmlentitydefs module's hash, BG> inverting it, and using that as a big global BG> search-and-replace, if the charset is undefined or iso-8859-1. My biggest question here is why you took most of the code out of Article._get_body() in HyperArch.py. IIRC, Jeremy added all this stuff so that charset handling would be saner. The idea is that if there is a single charset for the message, that would be the charset used for the web archive page. But if the page had multiple charsets, then it would pick the most common one. AFAIK, there's no way to represent multiple charsets in a single HTML page. An example of the latter is an index page for a list that has Subject: fields with many different charsets. Which one do you pick? In your patch, it seems like everything comes out iso-8859-1, and that doesn't seem right. -Barry From barry@zope.com Fri Oct 12 21:53:05 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Oct 2001 16:53:05 -0400 Subject: [Mailman-Developers] 2.1a2 and 2.0.6 on same box References: <3BC6A69B.A087B828@shu.ac.uk> Message-ID: <15303.22577.733963.844817@geddy.wooz.org> >>>>> "AH" == Andy Heath writes: AH> No responses so try again with better subject categorisation - AH> must ask here because its about 2.1a2. Someone else *must* be AH> doing this already, surely - I do it, 'natch. AH> I'm wanting to get seriously into 2.1a2 and do some hacking AH> (small quantity of free labour here) - have only one box and AH> need to continue running existing lists on 2.0.6 - what are AH> the constraints on running multiple mailmans (mailmen ? AH> mailwomen?) concurrently on the same system ? Plural: "Maildudes" :) AH> 1. Can I use same UID and GID , use $prefix to another AH> directory, merge the crontabs and tailor some URL path info AH> for apache so the right URL's invoke different mailman AH> instances ? I'm currently using my own hacked version of AH> Archiver.py with hypermail for archiving some lists and AH> pipermail with others on a per-list basis. You can use the same uid/gid, but you definitely want to install them in separate trees. E.g. My MM2.0.6 installation is still in /home/mailman but MM2.1 is in /usr/local/mailman. The points of contention will be where the system interacts with the list software, e.g. cron, MTA, and web server. Web server is easy if you accept that you'll need different urls to the two systems. I usually create Alias/ScriptAlias entries that map something like http://mail.python.org/mailman2.1/ to my Mailman 2.1 tree. The MTA is a little trickier because you need to watch out for overlapping aliases. With my installation, I've taught Postfix to use the old `auto' script for MM2.0.6 lists, but to consult /usr/local/mailman/data/aliases.db for the MM2.1 lists. I just can't have a list with the same name in both systems (but you probably could weasel around with virtual domains to achieve this). With cron, you'll need to merge the entries, which I think should be fairly straight forward. I actually don't do this because my MM2.1 lists aren't live yet, and with mailmanctl, you don't need to use cron to get your messages delivered. I just manually invoke senddigests or mailpasswds when I want to test that out. -Barry From lm@bitmover.com Fri Oct 12 22:14:04 2001 From: lm@bitmover.com (Larry McVoy) Date: Fri, 12 Oct 2001 14:14:04 -0700 Subject: [Mailman-Developers] moderate by user? Message-ID: <20011012141404.B24775@work.bitmover.com> Forgive me if this is glaring at me in the docs, but does any mailman version have the ability to have some users be moderated and some be not moderated on the same list? This would rock my world and a lot of other people's as well. I'd love to be able run my lists as "you're trusted until you screw up" and/or "you're untrusted until you prove trustyworthy" and be able to pick and choose on a per person basis. A lot of mailing lists try and maintain a certain tone and this is a decent way to do it. Another coolness feature would be able to let any of the trusted people approve any of the untrusted people's postings, but that's a second order term. Thanks in advance, I love Mailman. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From rodolfo@linux.org.uy Fri Oct 12 22:17:56 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 12 Oct 2001 18:17:56 -0300 Subject: [Mailman-Developers] CPU Usage In-Reply-To: <3BC3550C.2F2D1737@utopia.west.sun.com> References: <20010925151125.77e01be4.rodolfo@linux.org.uy> <15297.8321.928062.891519@geddy.wooz.org> <1002654001.2235.16.camel@claudia> <3BC3550C.2F2D1737@utopia.west.sun.com> Message-ID: <1002921483.17676.66.camel@claudia> --=-etwEXVMmSqYA5Sac1Gve Content-Type: text/plain Content-Transfer-Encoding: 7bit En Tue, 2001-10-09 a 16:50, Dan Mick escribio: > > > I have this problem every two days. I need to kill -9 the hang python > > process (the others mailmanctl can be down with mailmanctl stop) and rm > > the /var/.../locks/* and then restart bin/mailmanctl start. > I don't remember if you said, but it would be useful to know what > the hung process is doing (truss/strace/whatever) Ok I have now another pyton eating all the CPU again. # ps ax 2361 ? S 0:00 python bin/mailmanctl -n start 2362 ? S 0:00 python bin/mailmanctl -n start 2363 ? R 107:03 python bin/mailmanctl -n start 2364 ? S 0:17 python bin/mailmanctl -n start 2365 ? S 0:00 python bin/mailmanctl -n start 2366 ? S 1:19 python bin/mailmanctl -n start 2367 ? R 3087:28 python bin/mailmanctl -n start 2368 ? S 0:05 python bin/mailmanctl -n start # top 8:09pm up 4 days, 7:31, 1 user, load average: 2.01, 2.03, 2.00 66 processes: 62 sleeping, 4 running, 0 zombie, 0 stopped CPU states: 5.3% user, 94.6% system, 0.0% nice, 0.0% idle Mem: 259688K av, 226752K used, 32936K free,0K shrd, 132904K buff Swap: 385552K av, 0K used, 385552K free 21056K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 2367 root 19 0 4384 4384 2144 R 50.1 1.6 3088m python 2363 root 19 0 5200 5200 2076 R 48.7 2.0 108:16 python 10840 root 2 0 924 924 732 R 0.9 0.3 0:00 top # strace bin/mailmanctl stop (see attached strace1) # ps ax 2361 ? R 4:35 python bin/mailmanctl -n start 2363 ? R 115:34 python bin/mailmanctl -n start 2367 ? R 3095:59 python bin/mailmanctl -n start # uptime 8:29pm up 4 days, 7:51, 2 users, load average: 2.99, 2.95, 2.60 The system do not route any message: /var/spool/mailman/qfiles/in # ls -al -rw-rw---- 1 mailman mailman 1656 Oct 12 16:28 1002904109.995445+aa654e5c9dd26e14cd519efea21d3e415812b2ee.msg -rw-rw---- 1 mailman mailman 101 Oct 12 16:28 1002904136.797516+5b8dd6e92bbdd9556e5c7f6176b855ecc6e511ac.db -rw-rw---- 1 mailman mailman 1629823 Oct 12 16:28 1002904136.797516+5b8dd6e92bbdd9556e5c7f6176b855ecc6e511ac.msg -rw-rw---- 1 mailman mailman 101 Oct 12 17:12 1002906779.388226+1b80b9a2035ce7496cc31a4c3dd3ae0b925e520b.db -rw-rw---- 1 mailman mailman 2042 Oct 12 17:12 1002906779.388226+1b80b9a2035ce7496cc31a4c3dd3ae0b925e520b.msg # strace kill 2361 (see strace2) # strace kill 2363 (see strace3) # strace kill 2367 (see strace4) All process are killed but the lock/ directory shows the following: :/var/spool/mailman/locks # ls -al total 21 drwxrwsr-x 2 root mailman 212 Oct 12 20:35 . drwxrwsr-x 10 mailman mailman 206 Aug 9 09:38 .. -rw-rw-r-- 2 root mailman 48 Oct 12 21:27 chischis.lock -rw-rw-r-- 2 root mailman 48 Oct 12 21:27 chischis.lock.guru.2363 -rw-rw-r-- 1 mailman mailman 48 Oct 12 2001 chischis.lock.guru.9598 -rw-rw-r-- 2 root mailman 49 Oct 14 2001 master-qrunner -rw-rw-r-- 2 root mailman 49 Oct 14 2001 master-qrunner.guru.2361 (It is correct that several lock files are ownered by root?) # rm /var/spool/mailman/locks/* /var/spool/mailman/data # ls -al -rw-r----- 1 root mailman 41 Aug 9 10:39 adm.pw -rw-rw---- 1 root mailman 8553 Sep 20 03:09 aliases -rw-rw-r-- 1 mailman mailman 12288 Sep 20 03:09 aliases.db -rw-rw-r-- 1 root mailman 2112 Sep 20 01:31 heldmsg-uylug-demoday-11.txt -rw-rw-r-- 1 root mailman 696 Sep 21 01:49 heldmsg-uylug-demoday-12.txt -rw-rw-r-- 1 root mailman 1475 Oct 11 17:25 heldmsg-uylug-il-10.txt -rw-rw-r-- 1 root mailman 1420 Oct 12 12:47 heldmsg-uylug-il-11.txt -rw-rw-r-- 1 root mailman 1182 Sep 30 13:44 heldmsg-uylug-il-5.txt -rw-rw-r-- 1 root mailman 1487 Oct 8 15:31 heldmsg-uylug-il-6.txt -rw-rw-r-- 1 root mailman 1208 Oct 10 01:53 heldmsg-uylug-il-7.txt -rw-rw-r-- 1 root mailman 1246 Oct 10 01:57 heldmsg-uylug-il-8.txt -rw-rw-r-- 1 root mailman 2969 Oct 10 18:02 heldmsg-uylug-il-9.txt -rw-rw-r-- 1 root mailman 1494 Sep 25 15:16 heldmsg-uylug-noticias-6.txt -rw-rw-r-- 1 root mailman 1539 Sep 25 15:16 heldmsg-uylug-noticias-7.txt -rw-r--r-- 1 root mailman 10 Aug 9 09:51 last_mailman_version -rw-rw---- 1 wwwrun mailman 10162 Oct 12 16:23 pending.db -rw-rw-r-- 1 root mailman 2 Aug 11 04:30 pending_subscriptions.db -rw-rw-rw- 1 root mailman 5 Oct 8 15:31 qrunner.pid You can see the qrunner.pid still here! # rm qrunner.pid # bin/mailmanctl -n python # ps ax 11213 ? S 0:00 python bin/mailmanctl -n start 11214 ? S 0:00 python bin/mailmanctl -n start 11215 ? R 0:02 python bin/mailmanctl -n start 11216 ? R 0:00 python bin/mailmanctl -n start 11217 ? S 0:00 python bin/mailmanctl -n start 11218 ? S 0:01 python bin/mailmanctl -n start 11219 ? R 0:01 python bin/mailmanctl -n start 11220 ? R 0:00 python bin/mailmanctl -n start # uptime 8:49pm up 4 days, 8:11, 2 users, load average: 0.89, 0.42, 1.12 (there are many smtp session oppened ;) OPPPSSS!!! The python is hang again!!! see: # ps ax 11213 ? S 0:00 python bin/mailmanctl -n start 11214 ? S 0:00 python bin/mailmanctl -n start 11215 ? R 7:57 python bin/mailmanctl -n start 11216 ? S 0:01 python bin/mailmanctl -n start 11217 ? S 0:00 python bin/mailmanctl -n start 11218 ? S 0:01 python bin/mailmanctl -n start 11219 ? S 0:01 python bin/mailmanctl -n start 11220 ? S 0:01 python bin/mailmanctl -n start # top 8:57pm up 4 days, 8:20, 2 users, load average: 1.00, 0.90, 1.06 58 processes: 55 sleeping, 3 running, 0 zombie, 0 stopped CPU states: 6.1% user, 93.8% system, 0.0% nice, 0.0% idle Mem: 259688K av, 228368K used, 31320K free, 0K shrd, 133804K buff Swap: 385552K av, 0K used, 385552K free 23536K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 11215 root 11 0 5388 5388 2096 R 98.9 2.0 9:02 python 11327 root 2 0 1024 1024 816 R 1.1 0.3 0:00 top /var/spool/mailman/locks # ls -al -rw-rw-r-- 2 root mailman 49 Oct 13 2001 chischis.lock -rw-rw-r-- 2 root mailman 49 Oct 13 2001 chischis.lock.guru.11215 -rw-rw-r-- 2 root mailman 50 Oct 14 2001 master-qrunner -rw-rw-r-- 2 root mailman 50 Oct 14 2001 master-qrunner.guru.11213 mmmmmm.... some time ago the list chischis was broken..... the chischis/config.db have data from other list and was completely garbaged. I will try to delete chischis group and create again.... (I will notice you if I receive another problem) Ok, hackers, I hope that all of these facts enable you to touch the code! Please, contact me if you require additional information and/or testing. -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 --=-etwEXVMmSqYA5Sac1Gve Content-Type: text/plain Content-Disposition: attachment; filename=strace1 Content-Transfer-Encoding: 7bit guru:/usr/lib/mailman # strace bin/mailmanctl stop execve("bin/mailmanctl", ["bin/mailmanctl", "stop"], [/* 41 vars */]) = 0 uname({sys="Linux", node="guru", ...}) = 0 brk(0) = 0x804a330 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=17794, ...}) = 0 old_mmap(NULL, 17794, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 old_mmap(NULL, 1164516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001c000 mprotect(0x4012f000, 38116, PROT_NONE) = 0 old_mmap(0x4012f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x112000) = 0x4012f000 old_mmap(0x40135000, 13540, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40135000 close(3) = 0 munmap(0x40017000, 17794) = 0 getpid() = 10902 brk(0) = 0x804a330 brk(0x804a358) = 0x804a358 brk(0x804b000) = 0x804b000 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2567, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2567 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40017000, 4096) = 0 open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=110304, ...}) = 0 old_mmap(NULL, 110304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40139000 brk(0x804c000) = 0x804c000 close(3) = 0 execve("/sbin/python", ["python", "bin/mailmanctl", "stop"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) execve("/usr/sbin/python", ["python", "bin/mailmanctl", "stop"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) execve("/usr/local/sbin/python", ["python", "bin/mailmanctl", "stop"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) execve("/root/bin/python", ["python", "bin/mailmanctl", "stop"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) execve("/usr/local/bin/python", ["python", "bin/mailmanctl", "stop"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) execve("/usr/bin/python", ["python", "bin/mailmanctl", "stop"], [/* 41 vars */]) = 0 uname({sys="Linux", node="guru", ...}) = 0 brk(0) = 0x80dc8a0 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=17794, ...}) = 0 old_mmap(NULL, 17794, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 close(3) = 0 open("/usr/lib/libdb-3.1.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \364\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=562544, ...}) = 0 old_mmap(NULL, 508300, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001c000 mprotect(0x40096000, 8588, PROT_NONE) = 0 old_mmap(0x40096000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x79000) = 0x40096000 old_mmap(0x40098000, 396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40098000 close(3) = 0 open("/lib/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0O\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=105664, ...}) = 0 old_mmap(NULL, 88316, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40099000 mprotect(0x400a7000, 30972, PROT_NONE) = 0 old_mmap(0x400a7000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd000) = 0x400a7000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\34"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=14328, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400af000 old_mmap(NULL, 12340, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400b0000 mprotect(0x400b2000, 4148, PROT_NONE) = 0 old_mmap(0x400b2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x400b2000 old_mmap(0x400b3000, 52, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400b3000 close(3) = 0 open("/lib/libutil.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\16\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=11576, ...}) = 0 old_mmap(NULL, 10924, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400b4000 mprotect(0x400b6000, 2732, PROT_NONE) = 0 old_mmap(0x400b6000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x400b6000 close(3) = 0 open("/lib/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320H\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=171762, ...}) = 0 old_mmap(NULL, 125300, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400b7000 mprotect(0x400d5000, 2420, PROT_NONE) = 0 old_mmap(0x400d5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1d000) = 0x400d5000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 old_mmap(NULL, 1164516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400d6000 mprotect(0x401e9000, 38116, PROT_NONE) = 0 old_mmap(0x401e9000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x112000) = 0x401e9000 old_mmap(0x401ef000, 13540, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401ef000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 close(3) = 0 munmap(0x40017000, 17794) = 0 getpid() = 10902 rt_sigaction(SIGRT_0, {0x400a2740, [], 0x4000000}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x400a1d10, [], 0x4000000}, NULL, 8) = 0 rt_sigaction(SIGRT_2, {0x400a27d0, [], 0x4000000}, NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbffff574, 31, (nil), 0}) = 0 getpid() = 10902 brk(0) = 0x80dc8a0 brk(0x80dc8d0) = 0x80dc8d0 brk(0x80dd000) = 0x80dd000 open("bin/mailmanctl", O_RDONLY) = 3 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 brk(0x80de000) = 0x80de000 brk(0x80df000) = 0x80df000 brk(0x80e0000) = 0x80e0000 brk(0x80e1000) = 0x80e1000 stat64("/sbin/python", 0xbfffee1c) = -1 ENOENT (No such file or directory) stat64("/usr/sbin/python", 0xbfffee1c) = -1 ENOENT (No such file or directory) stat64("/usr/local/sbin/python", 0xbfffee1c) = -1 ENOENT (No such file or directory) stat64("/root/bin/python", 0xbfffee1c) = -1 ENOENT (No such file or directory) stat64("/usr/local/bin/python", 0xbfffee1c) = -1 ENOENT (No such file or directory) stat64("/usr/bin/python", {st_mode=S_IFREG|0755, st_size=600164, ...}) = 0 readlink("/usr/bin/python", "python2.0", 1024) = 9 readlink("/usr/bin/python2.0", 0xbfffefc4, 1024) = -1 EINVAL (Invalid argument) stat64("/usr/bin/Modules/Setup", 0xbfffedcc) = -1 ENOENT (No such file or directory) stat64("/usr/bin/lib/python2.0/os.py", 0xbfffedac) = -1 ENOENT (No such file or directory) stat64("/usr/bin/lib/python2.0/os.pyc", 0xbfffed9c) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/os.py", {st_mode=S_IFREG|0644, st_size=15294, ...}) = 0 stat64("/usr/bin/Modules/Setup", 0xbfffeddc) = -1 ENOENT (No such file or directory) stat64("/usr/bin/lib/python2.0/lib-dynload", 0xbfffedec) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-dynload", {st_mode=S_IFDIR|0755, st_size=1256, ...}) = 0 brk(0x80e2000) = 0x80e2000 brk(0x80e3000) = 0x80e3000 brk(0x80e4000) = 0x80e4000 brk(0x80e5000) = 0x80e5000 brk(0x80e6000) = 0x80e6000 brk(0x80e7000) = 0x80e7000 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 getpid() = 10902 rt_sigaction(SIGHUP, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTRAP, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGABRT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGBUS, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGFPE, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGKILL, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSEGV, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUSR2, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGPIPE, NULL, {SIG_IGN}, 8) = 0 rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSTKFLT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGCONT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSTOP, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTSTP, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTTIN, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTTOU, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGURG, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGXCPU, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGXFSZ, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGVTALRM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGPROF, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGWINCH, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGIO, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGPWR, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUNUSED, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_3, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_4, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_5, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_6, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_7, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_8, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_9, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_10, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_11, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_12, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_13, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_14, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_15, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_16, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_17, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_18, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_19, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_20, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_21, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_22, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_23, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_24, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_25, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_26, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_27, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_28, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_29, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_30, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGRT_31, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x400a2cf0, [], 0x4000000}, NULL, 8) = 0 brk(0x80e9000) = 0x80e9000 stat64("/usr/lib/python2.0/site", 0xbfffe98c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/site.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/sitemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/site.py", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=7924, ...}) = 0 open("/usr/lib/python2.0/site.pyc", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=8579, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(5, "\207\306\r\n\205\304\1;c\0\0\0\0\t\0\0\0s\330\3\0\0\177"..., 4096) = 4096 brk(0x80ea000) = 0x80ea000 read(5, "t//usr/lib/python2.0/site.pys\n\0\0"..., 4096) = 4096 brk(0x80eb000) = 0x80eb000 brk(0x80ec000) = 0x80ec000 read(5, "rinters\t\0\0\0copyrights\7\0\0\0credits"..., 4096) = 387 close(5) = 0 munmap(0x40017000, 4096) = 0 stat64("/usr/lib/python2.0/os", 0xbfffda2c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/os.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/osmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/os.py", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=15294, ...}) = 0 open("/usr/lib/python2.0/os.pyc", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=19569, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(6, "\207\306\r\n\203\304\1;c\0\0\0\0\7\0\0\0s&\7\0\0\177\0"..., 4096) = 4096 brk(0x80ed000) = 0x80ed000 brk(0x80ee000) = 0x80ee000 read(6, "None\n\n Super-rmdir; remove a "..., 4096) = 4096 brk(0x80ef000) = 0x80ef000 read(6, "\t\0\177\3\1y\35\0\177\3\1t\6\0|\t\0i\25\0\203\0\0d\2\0"..., 4096) = 4096 brk(0x80f0000) = 0x80f0000 brk(0x80f1000) = 0x80f1000 read(6, "\0\0\0evals\4\0\0\0names\t\0\0\0NameError(\1"..., 4096) = 4096 brk(0x80f2000) = 0x80f2000 brk(0x80f3000) = 0x80f3000 read(6, "python-root//usr/lib/python2.0/o"..., 4096) = 3185 brk(0x80f4000) = 0x80f4000 close(6) = 0 munmap(0x40017000, 4096) = 0 brk(0x80f8000) = 0x80f8000 brk(0x80f9000) = 0x80f9000 brk(0x80fa000) = 0x80fa000 open("/etc/mtab", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=247, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(6, "/dev/hda3 / reiserfs rw 0 0\nproc"..., 4096) = 247 close(6) = 0 munmap(0x40017000, 4096) = 0 open("/proc/meminfo", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(6, " total: used: free:"..., 1024) = 365 close(6) = 0 munmap(0x40017000, 4096) = 0 brk(0x80fb000) = 0x80fb000 brk(0x80fc000) = 0x80fc000 brk(0x80fd000) = 0x80fd000 brk(0x80fe000) = 0x80fe000 brk(0x80ff000) = 0x80ff000 stat64("/usr/lib/python2.0/posixpath", 0xbfffcacc) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/posixpath.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/posixpathmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/posixpath.py", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=10563, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(7, "\207\306\r\n\204\304\1;c\0\0\0\0\1\0\0\0s]\1\0\0\177\0"..., 4096) = 4096 brk(0x8100000) = 0x8100000 read(7, "T_SIZE(\2\0\0\0s\10\0\0\0filenames\2\0\0\0sts"..., 4096) = 4096 brk(0x8101000) = 0x8101000 brk(0x8102000) = 0x8102000 read(7, "ss\5\0\0\0errors\4\0\0\0funcs\3\0\0\0args\4\0\0"..., 4096) = 3371 brk(0x8103000) = 0x8103000 close(7) = 0 munmap(0x40017000, 4096) = 0 stat64("/usr/lib/python2.0/stat", 0xbfffbb6c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/stat.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/statmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/stat.py", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=1640, ...}) = 0 open("/usr/lib/python2.0/stat.pyc", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0644, st_size=2927, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(8, "\207\306\r\n\210\304\1;c\0\0\0\0\1\0\0\0s\300\1\0\0\177"..., 4096) = 2927 brk(0x8104000) = 0x8104000 brk(0x8105000) = 0x8105000 brk(0x810c000) = 0x810c000 close(8) = 0 munmap(0x40017000, 4096) = 0 close(7) = 0 close(6) = 0 stat64("/usr/lib/python2.0/UserDict", 0xbfffcacc) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/UserDict.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/UserDictmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/UserDict.py", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=1515, ...}) = 0 open("/usr/lib/python2.0/UserDict.pyc", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=4152, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(7, "\207\306\r\n{\304\1;c\0\0\0\0\3\0\0\0s&\0\0\0\177\0\0d"..., 4096) = 4096 read(7, "ython-root//usr/lib/python2.0/Us"..., 4096) = 56 close(7) = 0 munmap(0x40017000, 4096) = 0 close(6) = 0 brk(0x810d000) = 0x810d000 brk(0x810e000) = 0x810e000 brk(0x810f000) = 0x810f000 brk(0x8110000) = 0x8110000 brk(0x8111000) = 0x8111000 brk(0x8112000) = 0x8112000 brk(0x8113000) = 0x8113000 brk(0x8114000) = 0x8114000 brk(0x8115000) = 0x8115000 brk(0x8116000) = 0x8116000 brk(0x8117000) = 0x8117000 brk(0x8118000) = 0x8118000 brk(0x811a000) = 0x811a000 close(5) = 0 stat64("/usr/lib/python2.0/site-packages", {st_mode=S_IFDIR|0755, st_size=227, ...}) = 0 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open("/usr/lib/python2.0/site-packages", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=227, ...}) = 0 shmat(5, 0x2, 0x2ptrace: umoven: Input/output error ) = ? ipc_subcall(0x5, 0x8117bf0, 0x1000, 0x2) = 288 ipc_subcall(0x5, 0x8117bf0, 0x1000, 0x2) = 0 close(5) = 0 stat64("/usr/lib/site-python", 0xbfffe64c) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/sitecustomize", 0xbfffda2c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/sitecustomize.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/sitecustomizemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/sitecustomize.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/sitecustomize.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/plat-linux2/sitecustomize", 0xbfffda2c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/sitecustomize.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/sitecustomizemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/sitecustomize.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/sitecustomize.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-tk/sitecustomize", 0xbfffda2c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/sitecustomize.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/sitecustomizemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/sitecustomize.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/sitecustomize.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-dynload/sitecustomize", 0xbfffda2c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/sitecustomize.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/sitecustomizemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/sitecustomize.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/sitecustomize.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/site-packages/sitecustomize", 0xbfffda2c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/site-packages/sitecustomize.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/site-packages/sitecustomizemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/site-packages/sitecustomize.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/site-packages/sitecustomize.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) close(4) = 0 readlink("bin/mailmanctl", 0xbffff458, 1024) = -1 EINVAL (Invalid argument) ioctl(3, TCGETS, 0xbffff768) = -1 ENOTTY (Inappropriate ioctl for device) brk(0x811c000) = 0x811c000 fstat64(3, {st_mode=S_IFREG|0755, st_size=5663, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(3, "#! /usr/bin/env python\n\n# Copyri"..., 4096) = 4096 brk(0x811f000) = 0x811f000 brk(0x8120000) = 0x8120000 brk(0x8121000) = 0x8121000 brk(0x8122000) = 0x8122000 brk(0x8123000) = 0x8123000 brk(0x8124000) = 0x8124000 brk(0x8125000) = 0x8125000 brk(0x8126000) = 0x8126000 brk(0x8127000) = 0x8127000 brk(0x8128000) = 0x8128000 brk(0x8129000) = 0x8129000 brk(0x812a000) = 0x812a000 brk(0x812b000) = 0x812b000 brk(0x812c000) = 0x812c000 read(3, "\'start\', \'stop\', \'restart\'):\n "..., 4096) = 1567 brk(0x812d000) = 0x812d000 brk(0x812e000) = 0x812e000 brk(0x812f000) = 0x812f000 brk(0x8130000) = 0x8130000 brk(0x8131000) = 0x8131000 brk(0x8132000) = 0x8132000 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40017000, 4096) = 0 brk(0x8133000) = 0x8133000 stat64("bin/getopt", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("bin/getopt.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/getoptmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/getopt.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/getopt.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/getopt", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/getopt.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/getoptmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/getopt.py", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=4968, ...}) = 0 open("/usr/lib/python2.0/getopt.pyc", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=6163, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(4, "\207\306\r\n\177\304\1;c\0\0\0\0\6\0\0\0s\262\0\0\0\177"..., 4096) = 4096 read(4, "/python-root//usr/lib/python2.0/"..., 4096) = 2067 close(4) = 0 munmap(0x40017000, 4096) = 0 close(3) = 0 stat64("bin/errno", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("bin/errno.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/errnomodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/errno.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/errno.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/errno", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/errno.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/errnomodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/errno.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/errno.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/plat-linux2/errno", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/errno.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/errnomodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/errno.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/errno.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-tk/errno", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/errno.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/errnomodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/errno.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/errno.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-dynload/errno", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/errno.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/errnomodule.so", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0555, st_size=9735, ...}) = 0 open("/usr/lib/python2.0/lib-dynload/errnomodule.so", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\7\0"..., 1024) = 1024 fstat64(4, {st_mode=S_IFREG|0555, st_size=9735, ...}) = 0 old_mmap(NULL, 10656, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40017000 mprotect(0x40019000, 2464, PROT_NONE) = 0 old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 0x40019000 close(4) = 0 close(3) = 0 stat64("bin/paths", 0xbfffe73c) = -1 ENOENT (No such file or directory) open("bin/paths.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/pathsmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/paths.py", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1534, ...}) = 0 open("bin/paths.pyc", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=261, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(4, "\207\306\r\n\365\264t;c\0\0\0\0\3\0\0\0sX\0\0\0\177\0\0"..., 4096) = 261 close(4) = 0 munmap(0x4001a000, 4096) = 0 close(3) = 0 stat64("/usr/lib/mailman/Mailman", {st_mode=S_IFDIR|S_ISGID|0775, st_size=1763, ...}) = 0 stat64("/usr/lib/mailman/Mailman/__init__.py", {st_mode=S_IFREG|0644, st_size=775, ...}) = 0 stat64("/usr/lib/mailman/Mailman/__init__", 0xbfffe2cc) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/__init__.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/__init__module.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/__init__.py", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=775, ...}) = 0 open("/usr/lib/mailman/Mailman/__init__.pyc", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=99, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(4, "\207\306\r\n\365\264t;c\0\0\0\0\1\0\0\0s\7\0\0\0\177\0"..., 4096) = 99 close(4) = 0 munmap(0x4001a000, 4096) = 0 close(3) = 0 stat64("/usr/lib/mailman/Mailman/mm_cfg", 0xbfffe74c) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/mm_cfg.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/mm_cfgmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/mm_cfg.py", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2057, ...}) = 0 open("/usr/lib/mailman/Mailman/mm_cfg.pyc", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=1207, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(4, "\207\306\r\n\367hr;c\0\0\0\0\2\0\0\0so\0\0\0\177\0\0d\0"..., 4096) = 1207 close(4) = 0 munmap(0x4001a000, 4096) = 0 stat64("/usr/lib/mailman/Mailman/Defaults", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/Defaults.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/Defaultsmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/Defaults.py", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=29651, ...}) = 0 open("/usr/lib/mailman/Mailman/Defaults.pyc", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=9513, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(5, "\207\306\r\n\365\264t;c\0\0\0\0\16\0\0\0s\371\10\0\0\177"..., 4096) = 4096 read(5, "al_name)s\ni\31\0\0\0s\1\0\0\0\ns\6\0\0\0-owner"..., 4096) = 4096 read(5, "ls\t\0\0\0EmailLists\4\0\0\0Hosts\6\0\0\0Num"..., 4096) = 1321 close(5) = 0 munmap(0x4001a000, 4096) = 0 stat64("/usr/lib/mailman/Mailman/os", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/os.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/osmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/os.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/os.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mailman/Mailman/Version", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/Version.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/Versionmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/Version.py", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=1393, ...}) = 0 open("/usr/lib/mailman/Mailman/Version.pyc", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=596, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(6, "\207\306\r\n\365\264t;c\0\0\0\0\3\0\0\0s\262\0\0\0\177"..., 4096) = 596 close(6) = 0 munmap(0x4001a000, 4096) = 0 close(5) = 0 stat64("/usr/lib/mailman/Mailman/sys", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/sys.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/sysmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/sys.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/sys.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) close(4) = 0 close(3) = 0 stat64("/usr/lib/mailman/Mailman/LockFile", 0xbfffe74c) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/LockFile.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/LockFilemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/LockFile.py", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=19927, ...}) = 0 open("/usr/lib/mailman/Mailman/LockFile.pyc", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=19185, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(4, "\207\306\r\n\365\264t;c\0\0\0\0\t\0\0\0s\205\1\0\0\177"..., 4096) = 4096 read(4, "edErrorc\0\0\0\0\1\0\2\0s\16\0\0\0\177n\0d\0\0Z\0\0\177"..., 4096) = 4096 read(4, "s the lifetime of a locked file."..., 4096) = 4096 read(4, "s$\0\0\0/usr/lib/mailman/Mailman/Lo"..., 4096) = 4096 read(4, "hold time:s\17\0\0\0lock was brokens\r"..., 4096) = 2801 close(4) = 0 munmap(0x4001a000, 4096) = 0 stat64("/usr/lib/mailman/Mailman/socket", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mailman/socket", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("bin/socket", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("bin/socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/socket", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/socket.py", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=7307, ...}) = 0 open("/usr/lib/python2.0/socket.pyc", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=9859, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(5, "\207\306\r\n\206\304\1;c\0\0\0\0\5\0\0\0s\345\1\0\0\177"..., 4096) = 4096 read(5, "/tmp/python-root//usr/lib/python"..., 4096) = 4096 read(5, "\0\3\0sy\1\0\0\177\331\0\177\332\0d\1\0}\2\0\177\333\0"..., 4096) = 1667 close(5) = 0 munmap(0x4001a000, 4096) = 0 stat64("/usr/lib/mailman/_socket", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/_socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/_socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/_socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/_socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("bin/_socket", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("bin/_socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/_socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/_socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/_socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/_socket", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/_socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/_socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/_socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/_socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/plat-linux2/_socket", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/_socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/_socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/_socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/_socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-tk/_socket", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/_socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/_socketmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/_socket.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/_socket.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-dynload/_socket", 0xbfffc88c) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/_socket.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/_socketmodule.so", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0555, st_size=38522, ...}) = 0 open("/usr/lib/python2.0/lib-dynload/_socketmodule.so", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\35"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0555, st_size=38522, ...}) = 0 old_mmap(NULL, 33896, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x401f3000 mprotect(0x401f9000, 9320, PROT_NONE) = 0 old_mmap(0x401f9000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x5000) = 0x401f9000 close(6) = 0 open("/etc/ld.so.cache", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=17794, ...}) = 0 old_mmap(NULL, 17794, PROT_READ, MAP_PRIVATE, 6, 0) = 0x401fc000 close(6) = 0 open("/usr/lib/libssl.so.0.9.6", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \214\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=205237, ...}) = 0 old_mmap(NULL, 183808, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40201000 mprotect(0x4022b000, 11776, PROT_NONE) = 0 old_mmap(0x4022b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x29000) = 0x4022b000 close(6) = 0 open("/usr/lib/libcrypto.so.0.9.6", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2607\2"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=883010, ...}) = 0 old_mmap(NULL, 787232, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x4022e000 mprotect(0x402e0000, 58144, PROT_NONE) = 0 old_mmap(0x402e0000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0xb1000) = 0x402e0000 old_mmap(0x402ec000, 8992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x402ec000 close(6) = 0 open("/usr/lib/libcrypto.so.0.9.6", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2607\2"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=883010, ...}) = 0 close(6) = 0 mprotect(0x4022e000, 729088, PROT_READ|PROT_WRITE) = 0 mprotect(0x4022e000, 729088, PROT_READ|PROT_EXEC) = 0 munmap(0x401fc000, 17794) = 0 brk(0x8134000) = 0x8134000 brk(0x8135000) = 0x8135000 brk(0x8136000) = 0x8136000 brk(0x8137000) = 0x8137000 brk(0x8139000) = 0x8139000 brk(0x813a000) = 0x813a000 brk(0x813b000) = 0x813b000 brk(0x813c000) = 0x813c000 close(5) = 0 brk(0x813d000) = 0x813d000 uname({sys="Linux", node="guru", ...}) = 0 brk(0x813f000) = 0x813f000 brk(0x8141000) = 0x8141000 brk(0x8143000) = 0x8143000 close(4) = 0 stat64("/usr/lib/mailman/Mailman/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/time.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mailman/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/time.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("bin/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("bin/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/time.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/time.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/plat-linux2/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/time.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/plat-linux2/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-tk/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/time.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-tk/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/lib-dynload/time", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/time.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/lib-dynload/timemodule.so", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0555, st_size=17088, ...}) = 0 open("/usr/lib/python2.0/lib-dynload/timemodule.so", O_RDONLY) = 5 read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\17"..., 1024) = 1024 fstat64(5, {st_mode=S_IFREG|0555, st_size=17088, ...}) = 0 old_mmap(NULL, 16144, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0x401fc000 mprotect(0x401fe000, 7952, PROT_NONE) = 0 old_mmap(0x401fe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5, 0x1000) = 0x401fe000 close(5) = 0 time(NULL) = 1002917690 open("/etc/localtime", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(5, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0"..., 4096) = 56 close(5) = 0 munmap(0x4001a000, 4096) = 0 close(4) = 0 stat64("/usr/lib/mailman/Mailman/errno", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/errno.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/errnomodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/errno.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/errno.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mailman/Mailman/random", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/random.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/randommodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/random.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/Mailman/random.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mailman/random", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/random.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/randommodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/random.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/mailman/random.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("bin/random", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("bin/random.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/randommodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/random.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("bin/random.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.0/random", 0xbfffd7ec) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/random.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/randommodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.0/random.py", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=9524, ...}) = 0 open("/usr/lib/python2.0/random.pyc", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=11490, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(5, "\207\306\r\n\204\304\1;c\0\0\0\0\4\0\0\0s8\2\0\0\177\0"..., 4096) = 4096 read(5, "i\0\177j\0t\0\0t\1\0|\0\0|\1\0\203\2\0\203\1\0Sd\0\0S("..., 4096) = 4096 read(5, "\0|\3\0\31f\2\0\\\2\0|\0\0|\3\0<|\0\0|\4\0 <20011010213802.V11545@xs4all.nl> <15300.42428.723922.910260@slothrop.digicool.com> <20011010225539.W11545@xs4all.nl> <15301.51800.589500.704612@slothrop.digicool.com> <5.1.0.14.2.20011011160837.071e2e80@lennier.cc.vt.edu> Message-ID: <15303.25100.4580.402074@geddy.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> You should post something to inn-workers@isc.org; Russ Albery, RJ> who's working on the new nntp RFC is an INN coder. I'm on RJ> that list too. Okay cool. Let me see if I can formulate a coherent question... :) RJ> However, you really need a generic solution, since INN isn't RJ> the only major news product out there, and they all have their RJ> ideas. Agreed. That's what standards are for though, right? :) RJ> Plus, you're not just dealing with INN here. From your logs: >> Jan 06 14:43:07 2001 (31278) (ToUsenet) NNTP error for list >> "python-list": 441 437 Binary in non-binary group Okay, so >> that's a start, however INN can apparently be configured to >> reject or accept other combinations of headers, so we can't >> rely on this list. RJ> This isn't a case of INN being configured to reject extra RJ> headers; your provider installed CleanFeed, which is an RJ> anti-spam filter, which is what issued the 437 Binary in a RJ> non-binary group error. RJ> CleanFeed can do whatever it wants, and has all sorts of RJ> widgets for analyzing messages. Ah, I didn't know about CleanFeed. RJ> Some of the other errors came from situations that shouldn't RJ> have happened. Like the gateway should never have let a RJ> message get to the news server with a list of groups to post RJ> to, of which none exist. That's a configuration error on the RJ> admins part. Also, it shouldn't have let multiple To's into RJ> the note. The message to old, or in the future, or unparsable RJ> also isn't particularly mm's fault - it's the same issue we RJ> have with the archives, it's just that news, which actually RJ> computes the unix time of a message for expiration purposes, RJ> validates the date header more than we do, where, largely, RJ> it's just a string to us. Some of these things are just due to the fact that a message shows up on email first, where the rules MTAs impose are much more lenient. So the header rejects are where the NNTP server has stricter rules that don't make much sense for an email message. E.g. email has duplicate To: and Cc: headers all the time. Why an NNTP server would reject duplicate To: and Cc: headers, when it doesn't care about those for Netnews purposes, is confounding. But in general, I can clean up headers, and in fact my quick patch on SF for MM2.0.6 seems to have stopped the bulk of the rejects nicely (header rejects were much more common than binary filters or other issues). RJ> INN does have it's own, canonical, stupid, mail to news RJ> gateway; you might review it's code to see what it does. RJ> Really, it primarily gets cranky about you inserting what's RJ> viewed as a "security" header via NNTP. It's less cranky if RJ> you inject it directly with inews, because you can, if RJ> suffciently trusted, just tell it 'Use these headers' and it RJ> believes you. RJ> Which is bsaically the same issue as the "deliver mail via RJ> sendmail vs. via smtpdirect" thing - talk to the daemon, RJ> accept the daemon's restrictions. Agreed, however it would be nice to have a standard that says "posting hosts may not have these headers", or "must not have more than one of those other headers". What bothers me is that the massaging of the message must rely on implementation quirks instead of standards. So I guess a good question for inn-workers is: what will the draft standard say about required or prohibited headers? -Barry From barry@zope.com Fri Oct 12 22:44:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Oct 2001 17:44:46 -0400 Subject: [Mailman-Developers] importing mailman lists... References: <5.1.0.14.2.20011010150322.025c2e00@lennier.cc.vt.edu> <5.1.0.14.2.20011011141258.07516a90@lennier.cc.vt.edu> Message-ID: <15303.25678.451613.930530@geddy.wooz.org> >>>>> "RJ" == Ron Jarrell writes: >> I've been asked to serve a couple of lists on my production mm >> server (2.0.5) that are coming from a 1.0 server. If I just >> accept a tar of the list directories, will a make update do the >> right thing, or am I screwed by the fact that the other lists >> have already been upgraded from 1.0 to 2.0.5 over the years? RJ> I decided that I could hack update with some work to just RJ> forcibly do a 1.0 to 2.0.5 upgrade on just those lists... Or, RJ> plan B, which is what I actually ended up doing because I RJ> figured it'd be faster, was set up another directory, grap the RJ> Release_1_0 cvs image, build and install that, drop the lists RJ> into it, then install the Release_2_5 image on top of it, and RJ> let update do what it normally does... Since I could do it RJ> all in the background it took less of my real time than RJ> hacking the python would... That was probably the best approach, because bin/update (what "make update" runs), won't do anything if data/last_mailman_version indicates you're already running the current version. MM2.1's bin/update has a -f/--force flag to force the update even if last_mailman_version doesn't indicate that its necessary. Then again, you probably don't need bin/update anyway. This script's most important task is to update things that aren't related to a list's config.db schema, such as new directories that have cropped up, moved files, template duplication removal, changes to qfile schemas, etc. The config.db/config.pck list schema load and store routines are designed to automatically update them if necessary. It does this by comparing an integer in the database file against DATA_FILE_VERSION and then migrating the schema as necessary. So it should be the case that if you have an older list directory, and you unpack it in a newer Mailman installation directory, it'll get upgraded the first time the list is referenced in an email or web hit. You can force this by using bin/withlist: % python -i bin/withlist -l myoldlist Loading list myoldlist (locked) >>> m.Save() >>> m.Unlock() >>> ^D Finalizing One caution is that MM1.0 is really old, and a direct update from it to MM2.0.6 has never been tested, although upgrades along the way dating back to 1.0b8 (I believe) have been tested. It's always a good idea to install a copy of the list and make sure it works before turning off the old list. -Barry From barry@zope.com Fri Oct 12 22:48:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Oct 2001 17:48:06 -0400 Subject: [Mailman-Developers] Making the list archive URL configurable References: <20011008172335.F27744@magic.merlins.org> <15299.51971.494731.504152@geddy.wooz.org> <20011010111220.Q27744@magic.merlins.org> Message-ID: <15303.25878.174193.143141@geddy.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> In my case probably not, but I can see it as better if list MM> specific (some list admins subscribe their list to an external MM> archiver and would like to point mailman's archives for their MM> list to it) >> The RTTD is probably to make PUBLIC_ARCHIVE_URL a template >> string, into which the list name will be interpolated, and then >> change things so they use GetBaseArchiveURL() consistently. >> That way you could just set PUBLIC_ARCHIVE_URL to >> "http://www.geocrawler.com/redir-sf.php3?list=%(listname)s" in >> mm_cfg.py and be done with it. MM> In my specific case *right*now*, that would be enough MM> (afterall, that's what I did with my patch). In a more generic MM> case, per list would be better :-) As always, I'm worried about giving list admins too many knobs to twiddle. So we'll leave it as a per-site configuration until the deluge of requests come in. :) -Barry From liuk@publinet.it Fri Oct 12 23:53:29 2001 From: liuk@publinet.it (Luca Maranzano) Date: Sat, 13 Oct 2001 00:53:29 +0200 Subject: Approving messages with attachments? [was: Re: [Mailman-Developers] Handling of Posts held for approval and attachments In-Reply-To: <3BC4BE72.C445FD12@utopia.west.sun.com> References: <20011010231003.A2051@publinet.it> <3BC4BE72.C445FD12@utopia.west.sun.com> Message-ID: <20011013005329.A22888@publinet.it> On Wed, Oct 10, 2001 at 02:32:35PM -0700, Dan Mick wrote: > >From Defaults.py (which, if you want to change it, as always, put > something in mm_cfg.py to override the Defaults setting): > > # how many bytes of a held message post should be displayed in the admindb web > # page? Use a negative number to indicate the entire message, regardless of > # size (though this will slow down rendering those pages). > ADMINDB_PAGE_TEXT_LIMIT = 4096 Oh thank you for the pointer and sorry for the oversight :) However I'd like to know what do you think about this issue: > > Besides, the moderator is not able to see if a message contains > > an attach (and its relative size), so he/she can eventually > > post a message with a big attach without knowing this :) TIA, luca From Dan Mick Fri Oct 12 23:59:59 2001 From: Dan Mick (Dan Mick) Date: Fri, 12 Oct 2001 15:59:59 -0700 (PDT) Subject: Approving messages with attachments? [was: Re: [Mailman-Developers] Handling of Posts held for approval and attachments Message-ID: <200110122259.PAA28349@utopia.West.Sun.COM> > > >From Defaults.py (which, if you want to change it, as always, put > > something in mm_cfg.py to override the Defaults setting): > > > > # how many bytes of a held message post should be displayed in the admindb web > > # page? Use a negative number to indicate the entire message, regardless of > > # size (though this will slow down rendering those pages). > > ADMINDB_PAGE_TEXT_LIMIT = 4096 > > Oh thank you for the pointer and sorry for the oversight :) > > However I'd like to know what do you think about this issue: > > > > Besides, the moderator is not able to see if a message contains > > > an attach (and its relative size), so he/she can eventually > > > post a message with a big attach without knowing this :) I usually set my ADMINDB_PAGE_TEXT_LIMIT to -1 for exactly this reason (and have a size limit set for messages anyway, and strip all attachments with demime in the first place). From igor@linuxinside.com Sat Oct 13 00:53:58 2001 From: igor@linuxinside.com (Igor Pruchanskiy) Date: Fri, 12 Oct 2001 16:53:58 -0700 Subject: [Mailman-Developers] mimelib, mailman and postfix Message-ID: <20011012165358.B15129@linuxinside.com> Hello all Today i installed Python 2.1.1 mimelib-0.3 AND mimelib-0.6 (more on this later) Mailman 2.1a2 and i already had Postfix installed.... I had to install 2 version of mimelib becasue Mailadmin Makefile was compaining about missing StringableMixin.py with 0.6 which is a part of mimelib-0.3 and with 0.3 it was complaining about missing RFC822.py which is a part of mimelib-0.6... killed 2 hours on that..... Anyway, so no i get this error when user trying to subscribe in my $prefix/logs/error Oct 12 16:44:30 2001 (16115) Uncaught runner exception: write() got an unexpected keyword argument 'unixfrom' Oct 12 16:44:30 2001 (16115) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 102, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 150, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 54, in _dispose func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 57, in process msgtext = msg.get_text() File "/usr/local/lib/python2.1/site-packages/mimelib/StringableMixin.py", line 28, in get_text g.write(self, unixfrom=unixfrom) TypeError: write() got an unexpected keyword argument 'unixfrom' I know nothing about Python, so i can not trace this problem myself. I also searched all over the net and read all the docs, but did not fine anything aobut this problem... igor -- Uptime: 40 days, 17:00 From peterw@usa.net Sat Oct 13 01:33:11 2001 From: peterw@usa.net (Peter W) Date: Fri, 12 Oct 2001 20:33:11 -0400 Subject: [Mailman-Developers] privacy problems with web interface In-Reply-To: <15302.8972.748996.37262@anthem.wooz.org>; from barry@zope.com on Thu, Oct 11, 2001 at 06:54:04PM -0400 References: <20010922162341.A31731@casagrau.org> <15302.8972.748996.37262@anthem.wooz.org> Message-ID: <20011012203311.A25463@usa.net> On Thu, Oct 11, 2001 at 06:54:04PM -0400, Barry A. Warsaw wrote: > What we can do for MM2.1 is, if the subscriber list is not public, > i.e. private_roster is not "Anyone", then if they attempt to subscribe > an already subscribed address, we can show them a results page that > looks no different whether they actually are subscribed or not. > > Then if they are subscribed, we'll send the user a message saying > somebody tried to subscribe their address (should we email the admin > too?). If they aren't subscribed, then we'll do the normal routine. I wouldn't bother the admin. It would be nice if the emails that mailman sends contained something like the Web client's IP address in the headers or message (maybe that already happens; I do not recall) in case some subscriber wants/needs to follow up on a request. > (I need to make sure the web message you'd see is identical regardless > of whether you're subscribed or not. That's a little tricky, but > doable.) Sounds great. > In MM2.1 > If the user is subscribed, and a url containing their email address is > given, then they are presented with a page prompting only for their > password. If the email address is incorrect, or missing in the url, > then they are prompted for both their address and password. > > This needs to change such that if private_roster is not "Anyone", then > the same sets of prompts will be given regardless of whether the > address is a member or not. > This should avoid leaking any membership information. I'll work on > getting that into MM2.1. Watch CVS. Barry, this all sounds great. We'll be setting up a test machine this weekend just for testing out MM CVS code so we can track this and do what we can to help out (and also to work with Postfix and VERP). These changes will be much appreciated! -Peter From claw@kanga.nu Sat Oct 13 08:29:01 2001 From: claw@kanga.nu (J C Lawrence) Date: Sat, 13 Oct 2001 00:29:01 -0700 Subject: [Mailman-Developers] moderate by user? In-Reply-To: Message from Larry McVoy of "Fri, 12 Oct 2001 14:14:04 PDT." <20011012141404.B24775@work.bitmover.com> References: <20011012141404.B24775@work.bitmover.com> Message-ID: <19157.1002958141@kanga.nu> On Fri, 12 Oct 2001 14:14:04 -0700 Larry McVoy wrote: > Forgive me if this is glaring at me in the docs, but does any > mailman version have the ability to have some users be moderated > and some be not moderated on the same list? Not exactly. You can configure a list to be moderated and then manually add subscribers to the "authorised posters" (PrivacyOptions, 7th option) list which will let those poster's messages past without moderation. I do this with my own moderated lists so that I won't have to moderate my own posts. But its not human scalable. Its not a config item that's stored against the subscriber rolls; its just a list of addresses that exists outside of the subscriber list. Previously I ran the sort of system you described and found maintaining the approved poster list was excessively painful given Mailman's supports. Translation: For what you're describing it works fine as long as you keep the list small. > This would rock my world and a lot of other people's as well. Aye, I'd like it as well. What's really needed is a per-subscriber config option which is controllable only by the ListOwner (there are good arguments for it being both invisible and visible to members) and is stored as part of the subscriber list. I wonder if Barry would accept a patch for that? Barry? > I'd love to be able run my lists as "you're trusted until you > screw up" and/or "you're untrusted until you prove trustyworthy" > and be able to pick and choose on a per person basis. Verily. > Thanks in advance, I love Mailman. Mailman is Good Software. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From timduru@timduru.org Sat Oct 13 12:24:53 2001 From: timduru@timduru.org (timduru) Date: Sat, 13 Oct 2001 13:24:53 +0200 Subject: [Mailman-Developers] Reusing mailman login/pass or cookie ? Message-ID: <20011013132453.43d4c58f.timduru@timduru.org> I've developped a few php scripts for the users of some of my lists, what I need is to have only users effectively subscribed and authenticated to the lists to be able to use the scripts. I also need to know what is the user's login in the php scripts. Is there a way to do that , either by reproducing the mailman auth process in php or by reusing the mailman cookie ? Anyone has already done that or knows of a way to do that ? thanks From tim2@timduru.org Sat Oct 13 12:25:31 2001 From: tim2@timduru.org (timduru) Date: Sat, 13 Oct 2001 13:25:31 +0200 Subject: [Mailman-Developers] Fw: Reusing mailman login/pass or cookie ? Message-ID: <20011013132531.0904ab01.tim2@timduru.org> I've developped a few php scripts for the users of some of my lists, what I need is to have only users effectively subscribed and authenticated to the lists to be able to use the scripts. I also need to know what is the user's login in the php scripts. Is there a way to do that , either by reproducing the mailman auth process in php or by reusing the mailman cookie ? Anyone has already done that or knows of a way to do that ? thanks From barry@zope.com Sat Oct 13 15:38:26 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 13 Oct 2001 10:38:26 -0400 Subject: [Mailman-Developers] moderate by user? References: <20011012141404.B24775@work.bitmover.com> <19157.1002958141@kanga.nu> Message-ID: <15304.20962.43080.358542@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> This would rock my world and a lot of other people's as well. JCL> Aye, I'd like it as well. What's really needed is a JCL> per-subscriber config option which is controllable only by JCL> the ListOwner (there are good arguments for it being both JCL> invisible and visible to members) and is stored as part of JCL> the subscriber list. JCL> I wonder if Barry would accept a patch for that? Barry? Probably not... ...but only because I'm almost done implementing it. Hee hee. :) Actually, Larry's suggestion prompted me to overhaul the moderation flow. I'll post about it as soon as I'm finished prototyping it. -Barry From INTERNALANTENNAS.COM"
*NEW CELL PHONE SIGNAL ANTENNA BOOSTER FREE*
 

 

 

 Description
ORDER AT INTERNALANTENNAS.COM OR TOLL FREE 

1-866-225-9067

 
 Description
FREE SAMPLES AT INTERNALANTENNAS.COM...The Internal Booster Antenna is a passive device designed to capture the stray radiation inside the body of the phone and re-direct the signal to improve the phone's performance. Now you can use your cell phone in bank vaults, elevators, cars, boats, mountains, ski resorts, tunnels, buildings and more..... It's like having a FIVE foot antenna on your phone. Help end static and power up your signal. By powering up your cellular phone's signal you will lower static on analog phones (digital phones don't have static) with this easy to install Internal Antenna. This magnetic antenna can work with analog, digital and tri- band phones. Works on any cellular phone. Very easy to install!! Clears up static and make everything clear. The following is an excerpt from 2001 TECHNOLOGY testing laboratories "Each of our tests (for the Power Strip Antenna Booster) was conducted in city and rural environments, various terrain, weather conditions, and distances from cell sites. "Transmission and reception quality was improved up to 30%. "Terrain did effect overall performance, however, there was still a 15%-25% average improvement. "The most improvement was the decrease in lost calls or drop-outs; upwards of 60%."Del Norte products sells over 5000 Version IV antennas a week, for a good reason OUR PRODUCT WORKS! we have technical support FOR CUSTOMERS & 10 years of wireless experience in tower construction for cellular & PCS sites. We don't just sell you the product we stand behind it.... We have thousands of satisfied customers read our testimonials at antennabooster.net ( go to testimonials) and you will see why we are the main supplier of mag internal antennas to local dept stores and wireless retail centers ALL OVER NORTH AMERICA Enjoy our expertise...Brand New ! Version IV exclusive to 2001 Technology Services. To order a free sample go to antennabooster.net OR CALL 915-633-8083Installation Instructions :Turn off your phone.Remove cell phone battery and Internal Booster Antenna from plastic then adhere the Internal Booster Antenna onto your battery. Before removing the adhesive back on the antenna pleas decide where you are going to place the antenna. Make sure not to cover the battery or phone copper contacts Replace battery and turn your cell phone on. That's it! Now wasn't that easy? Enjoy the reduced static and enhanced signal on your cellular phone!! Retails ON TV & web sites for $19.95 to $29.95 Remember these are real antenna boosters so their life expectancy is 45 days they are polarized metal and extended use will depolarize ( but our product works) we will adjust shipping for multiple orders... These antennas are generically packaged so enjoy the savings....also these are version IV not the cheap Japanese or Taiwan stuff .

All our mailings are sent complying to the proposed United States Federal requirements for commercial e-mail: Section 301 Paragraph (a)(2)(C) of S. 618. Please see the bottom of this message for further information and removal instructions.

contact gacosta@constant.com and you will be removed immediately

TITLE YOUR EMAIL REMOVE ME

From nickhill@email.com Mon Oct 15 00:27:55 2001 From: nickhill@email.com (Nick Hill) Date: Mon, 15 Oct 2001 00:27:55 +0100 Subject: [Mailman-Developers] Feature to stop spam mail Message-ID: <20011015002755.5b917ef4.nickhill@email.com> Hello. I have been using a mailman list run by a Linux users group, which I am a member of. Users of the list have started getting spam mail. This is almost certainly caused by a robot trawling the web discussion list for email addresses. We (the group) are loathed to do without the excellent web presentation of historical messages. I originally found the group by hitting upon the message list using a web search engine. We don't want to obfuscate the email addresses on messages to members via email. We don't think the distribution of member's email addresses to members by the mail system is likely to lead to spam. The publication of email addresses on the e-mail list creates useful off-list discussions. What we really need is a way to set mailman to obfuscate email addresses on the web presentation. I have downloaded mailman and installed it on my own machine in the hope of finding a way to set the system to obfuscate email addresses published on the web interface. The control flow through the program and objects for the pipermail section confounds me. I was hoping to insert a ~= s/email_address/not_email_address/ RE somewhere in the code to exchange email addresses for another string whilst the web pages were being written to files. Does anyone here know the code well enough to do this easily? How hard would it be to add the feature to the web administration interface on a per-discussion-group basis? Thanks.. Nick. From marc_news@valinux.com Mon Oct 15 05:25:53 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Sun, 14 Oct 2001 21:25:53 -0700 Subject: [Mailman-Developers] handling duplicate mails Message-ID: <20011014212553.B531@moremagic.merlins.org> There were two patches sent here, by Ben Gertzfield and Mark Tearle. Was one of the two integrated in mailman CVS? If not, any recommendations on which one I should look at today and Barry, if you're reading, whether you're planning to put one in for 2.1 or if this will wait for a later release? Thanks Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Oct 15 05:57:49 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 15 Oct 2001 00:57:49 -0400 Subject: [Mailman-Developers] handling duplicate mails References: <20011014212553.B531@moremagic.merlins.org> Message-ID: <15306.27853.412722.354260@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> There were two patches sent here, by Ben Gertzfield and Mark MM> Tearle. MM> Was one of the two integrated in mailman CVS? MM> If not, any recommendations on which one I should look at MM> today and Barry, if you're reading, whether you're planning to MM> put one in for 2.1 or if this will wait for a later release? I haven't looked at either one yet, but I do plan on getting something like this into 2.1. -Barry From quique@sindominio.net Mon Oct 15 14:57:00 2001 From: quique@sindominio.net (Quique) Date: Mon, 15 Oct 2001 13:57:00 -0000 Subject: [Mailman-Developers] Mailman/Apache problem Message-ID: <20011015135700.CD9D861842@fanelli.sindominio.net> Hi Barry and co. We at sindominio.net are running several mailing lists with GNU Mailman. One of our lists gets quite a lot of spam. Last week, we had 22 messages pending for approval. When we tried to approve/reject/discard them, we got a 413 error message: Request Entity Too Large The requested resource /cgi-bin/mailman/admindb/sd does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit. Apache/1.3.9 Server at www.sindominio.net Port 80 It never happened before, and it doesn't happen with the other lists. So we think it was caused because there were too many messages pending for approval(?). Is this a Mailman or an Apache problem? Should I fill a bug report? Any comment or suggestion will be appreciated. Thanks, Quique -- WAR IS PEACE. FREEDOM IS SLAVERY. IGNORANCE IS STRENGTH. WAR IS PEACE. FREEDOM IS SLAVERY. IGNORANCE IS STRENGTH. WAR IS PEACE. FREEDOM IS SLAVERY. IGNORANCE IS STRENGTH. WAR IS PEACE. FREEDOM IS SLAVERY. IGNORANCE IS STRENGTH. WAR IS PEACE. FREEDOM IS SLAVERY. IGNORANCE IS STRENGTH. If you repeat it enough times does it become the truth? From donal.hunt2@mail.dcu.ie Mon Oct 15 15:26:46 2001 From: donal.hunt2@mail.dcu.ie (donal.hunt2@mail.dcu.ie) Date: Mon, 15 Oct 2001 15:26:46 +0100 Subject: [Mailman-Developers] Bug: "very low level failure" [solved] In-Reply-To: <15299.50653.855946.709462@geddy.wooz.org> Message-ID: <3BCAA81D00000803@hawk.dcu.ie> Just to let you know that we solved the problem below. Turns out it was to do with rlimits causing problems with Apache. All is good now though. :) Donal >-- Original Message -- >Date: Tue, 9 Oct 2001 23:51:57 -0400 >To: Donal Hunt >Cc: mailman-users@python.org, mailman-developers@python.org >Subject: Re: [Mailman-Developers] Bug: "very low level failure" >From: barry@zope.com (Barry A. Warsaw) > > > >>>>>> "DH" =3D=3D Donal Hunt writes: > > DH> For once i'm completely stumped. > > | History: > | ------- > | Python 2.1.1 on Solaris 8 (Sparc Edtion). > | Apache 1.3.20. > | Installed Mailman 2.0.6 using: > > DH> Just get the following message: > > DH> "Mailman experienced a very low level failure and could not > DH> even generate a useful traceback for you. Please report this > DH> to the Mailman administrator at this site." > >I suspect there's something wrong with your Python installation. >You'd only get this low level error if you got an exception in the >driver script's print_traceback() or print_environment() functions. > >One thought: are you positive that you're using Python 2.1.1 with the >web interface? If the Python you're using doesn't support extended >print, that could be your problem. > >Try running the driver script manually from the install directory. >You'll get an exception, but it shouldn't be a low level one (probably >an IndexError trying to extract the the cgi program's name from >sys.argv). E.g.: > >% PYTHONPATH=3D. python -S scripts/driver > >Make sure `python' is exactly the one you gave on the configure line. >If you get some other exception, or error, it should give you an >indication of the problem that's occurring. > >-Barry From barry@zope.com Mon Oct 15 20:14:13 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 15 Oct 2001 15:14:13 -0400 Subject: [Mailman-Developers] New sender-centric moderation rules Message-ID: <15307.13701.248329.887129@anthem.wooz.org> I'm about to checkin a bunch of changes implementing new sender-centric moderation rules. I think this will make moderation based on sender (i.e. From:) more flexible and more understandable. One of the things that I dislike intensely, and I often get negative email about is the overloading of the `posters' attribute, with its semantics dependent on the value of `member_posting_only'. Quick: what are the rules for these two variables? See? :) My changes were inspired by Larry McVoy's recent request, and are now twofold: >>>>> "LM" == Larry McVoy writes: LM> Forgive me if this is glaring at me in the docs, but does any LM> mailman version have the ability to have some users be LM> moderated and some be not moderated on the same list? LM> This would rock my world and a lot of other people's as well. LM> I'd love to be able run my lists as "you're trusted until you LM> screw up" and/or "you're untrusted until you prove LM> trustyworthy" and be able to pick and choose on a per person LM> basis. First, each member has a "moderate" bit associated with their options. If their bit is on, their postings are held for moderation regardless of any other setting. If their bit is off, then the message is passed on to other phases of hold checking. Only list admins can get to a user's moderation bit, so only they can change them. Each list has a default value for the bit, which will be used to initialize new members. Second, I've gotten rid of the following configuration variables, which were previously available in the "Privacy" section: `moderated', `forbidden_posters', `posters', and `member_posting_only'. Now, when a posting is received by a list, it follows these rules (note: see misc/posting-flow-chart.ps in cvs): - If the sender is a member - If the member's moderate bit is on, hold the message - If the member's moderate bit is off, pass on to the next pipeline handler - If the sender is not a member - Check the sender's address against the list in accept_these_nonmembers. If so, pass on to the next pipeline handler - Check against hold_these_nonmembers. If found, hold the message for moderation - Check against reject_these_nonmembers. If found, automatically reject (i.e. bounce) this message. - Check against discard_these_nonmembers. If found, simply discard the posting. Optionally, send the list moderators a copy of the discarded message. - If the sender wasn't found in any of those 4 lists, then apply the generic_nonmember_action, which may be one of accept, hold, reject, discard. I believe this covers all the possibilities and it should be easier to understand how everything interacts. The auto-upgrade feature should map the old configuration variables to the new ones as closely as is possible. Some examples: - A traditional, members-only list: turn off the default member moderate bit, set the generic_nonmember_action to reject or hold. - A completely open list: turn off default member moderate bit, set generic_nonmember_action to accept. - A member-only list, with trust required before unmoderated posting is allowed: turn on default member moderate bit, set generic_nonmember_action to reject or hold. Etc. Some things to think about adding: - A global switch to set or unset the moderate bit of all members. - Make it so list moderators can set or unset the per-user moderate bit (right now only list admins can do that). - Add some hooks to admindb so that held messages can be sorted by sender, and so that you could automatically add the non-member to one of the 4 lists (accept, hold, reject, discard), or automatically un-moderate a moderated member. - Much of the framework to support the sender-centric moderation stuff could be used to automatically dispose of messages based on other criteria. I.e. I could see that we might have a default action for each of the remaining hold criteria, and we might be able to offer a bodytext-based regexp matcher with a default action. One of the other things I've added will hopefully make admin notifications of held messages a little more convenient. With these changes, the admin notification contains the traditional notice, along with two embedded messages (rfc822/message). The first is the original held message, and the second is a confirmation message. What this allows you to do is to approve or discard held messages from email, without having to go through the web. If you simply respond to the confirmation, the held message will be discarded. If you add an "Approved: password" header (or first line of response), then the message will be approved just as if you approved it through the web. I figure these are the two most likely responses, so if you wanted to reject it, forward it, or preserve it, you still need to go through the web. Anyway, comments are welcome. Checkins will follow shortly. -Barry From barry@zope.com Mon Oct 15 20:16:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 15 Oct 2001 15:16:17 -0400 Subject: [Mailman-Developers] moderate by user? References: <20011012141404.B24775@work.bitmover.com> <19157.1002958141@kanga.nu> Message-ID: <15307.13825.482306.392448@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Aye, I'd like it as well. What's really needed is a JCL> per-subscriber config option which is controllable only by JCL> the ListOwner (there are good arguments for it being both JCL> invisible and visible to members) and is stored as part of JCL> the subscriber list. Ah, I hadn't thought about that (making it visible but not modifiable by the user). Right now, it's not even visible, although it's pretty obvious should the user post to a list. -Barry From claw@2wire.com Mon Oct 15 21:34:29 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 15 Oct 2001 13:34:29 -0700 Subject: [Mailman-Developers] moderate by user? In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Mon, 15 Oct 2001 15:16:17 EDT." <15307.13825.482306.392448@anthem.wooz.org> References: <20011012141404.B24775@work.bitmover.com> <19157.1002958141@kanga.nu> <15307.13825.482306.392448@anthem.wooz.org> Message-ID: <12235.1003178069@2wire.com> On Mon, 15 Oct 2001 15:16:17 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Aye, I'd like it as well. What's really needed is a JCL> per-subscriber config option which is controllable only by the JCL> ListOwner (there are good arguments for it being both invisible JCL> and visible to members) and is stored as part of the subscriber JCL> list. > Ah, I hadn't thought about that (making it visible but not > modifiable by the user). Right now, it's not even visible, > although it's pretty obvious should the user post to a list. >From a social engineering aspect there are advantages if "poster" users can be seen to be so flagged. There are similar is smaller advantages if a user can see a flag which says, "You (do not) have unrestricted posting authority to this list." There are also similarly large downsides to both. AdminOnly visibility seems the right starting point. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@2wire.com Mon Oct 15 21:48:56 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 15 Oct 2001 13:48:56 -0700 Subject: [Mailman-Developers] New sender-centric moderation rules In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Mon, 15 Oct 2001 15:14:13 EDT." <15307.13701.248329.887129@anthem.wooz.org> References: <15307.13701.248329.887129@anthem.wooz.org> Message-ID: <12329.1003178936@2wire.com> On Mon, 15 Oct 2001 15:14:13 -0400 Barry A Warsaw wrote: > First, each member has a "moderate" bit associated with their > options. If their bit is on, their postings are held for > moderation regardless of any other setting. If their bit is off, > then the message is passed on to other phases of hold checking. > Only list admins can get to a user's moderation bit, so only they > can change them. Each list has a default value for the bit, which > will be used to initialize new members. Good stuff. It would be good to also have a small notes field attached to each subscriber. > - If the sender is not a member I'd like to insert a level in there of: -- If message matches then auto-post -- If message matches then hold -- If message matches then reject This way we can prefix lists with a procmail recipes (that do whatever) to externally define posting criteria. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From mtearle@tearle.com Tue Oct 16 04:40:31 2001 From: mtearle@tearle.com (Mark Tearle) Date: Tue, 16 Oct 2001 11:40:31 +0800 (WST) Subject: [Mailman-Developers] handling duplicate mails In-Reply-To: <20011014212553.B531@moremagic.merlins.org> Message-ID: On Sun, 14 Oct 2001, Marc MERLIN wrote: > There were two patches sent here, by Ben Gertzfield and Mark Tearle. > > Was one of the two integrated in mailman CVS? > > If not, any recommendations on which one I should look at today and Barry, > if you're reading, whether you're planning to put one in for 2.1 or if this > will wait for a later release? > > Thanks > Marc Hi Marc Our patches tackle the duplicate mail problem in different ways. Mine attacks the problem by enabling lists to be set up which can pull there membership in from other lists. (ie at the who is on the list stage of the pipeline) Ben's attacks the problem by ensuring that an individual only gets delivered one copy of an email (based on the message ID) (ie at the delivery stage) What problem are you trying to tackle? Yours Mark PS. Marc, coming to LCA 2002? http://www.linux.org.au/conf/ -- Mark Tearle - mark@tearle.com "Confucius say: if you think we're going to sum up your whole life on this little bit of paper, you're are crazy." -- fortune cookie From jarrell@vt.edu Tue Oct 16 07:57:26 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 16 Oct 2001 02:57:26 -0400 Subject: [Mailman-Developers] New sender-centric moderation rules In-Reply-To: <15307.13701.248329.887129@anthem.wooz.org> Message-ID: <5.1.0.14.2.20011016024815.00a35c10@lennier.cc.vt.edu> At 03:14 PM 10/15/01 -0400, Barry A. Warsaw wrote: >Make it so list moderators can set or unset the per-user moderate > bit (right now only list admins can do that). Generically, there's a lot of things that should be done with list moderators... Really, I think we need to redesign large chunks of the admin page, and set up multiple access classes. Off the top of my head, I think we need a siteadmin, listmaster, listowner, and list moderator category; siteadmin is the current possessor of the master and can do everything. listmasters can create and delete lists (and potentially get junior siteadmin privs.) listowners can monkey with most, but not all of the settings. For instance, I thnk listowners should be allowed to make their archives private or not. But not be allowed to change whether or not they have archives; that's a site decision. And list moderators should be able to do not only approvals, but be able to get to all the subscribe/unsubscribe things. Perhaps more generically, we need to make a list of all the things people are allowed to do, and set up a user class page, where you can flip the bit for any individual class, so a site admin could let list owners turn on and off archives if he wanted, but the default config might not let them. With a true userdb this could just be applied to a particular person; granting them privileges. Until then, we could just define N categories, and some sane defaults... From barry@zope.com Tue Oct 16 14:47:41 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Oct 2001 09:47:41 -0400 Subject: [Mailman-Developers] New sender-centric moderation rules References: <15307.13701.248329.887129@anthem.wooz.org> <5.1.0.14.2.20011016024815.00a35c10@lennier.cc.vt.edu> Message-ID: <15308.14973.792894.458520@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Really, I think we need to redesign large chunks of the admin RJ> page, and set up multiple access classes. RJ> Perhaps more generically, we need to make a list of all the RJ> things people are allowed to do, and set up a user class page, RJ> where you can flip the bit for any individual class, so a site RJ> admin could let list owners turn on and off archives if he RJ> wanted, but the default config might not let them. With a RJ> true userdb this could just be applied to a particular person; RJ> granting them privileges. Until then, we could just define N RJ> categories, and some sane defaults... I don't disagree with any of this (although I might quibble about the details). However, I believe to do it right requires a unified user database, and that's just not something that's going to happen for MM2.1. So we might have to live with a few inconveniences for now, and keep an eye on fixing things in the next version. -Barry From marc_news@valinux.com Tue Oct 16 16:33:44 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 16 Oct 2001 08:33:44 -0700 Subject: [Mailman-Developers] handling duplicate mails In-Reply-To: ; from mtearle@tearle.com on Tue, Oct 16, 2001 at 11:40:31AM +0800 References: <20011014212553.B531@moremagic.merlins.org> Message-ID: <20011016083343.F8534@magic.merlins.org> On Tue, Oct 16, 2001 at 11:40:31AM +0800, Mark Tearle wrote: > Mine attacks the problem by enabling lists to be set up which > can pull there membership in from other lists. > (ie at the who is on the list stage of the pipeline) I looked at your patch closer and you're right. Sorry for the misunderstanding. > Ben's attacks the problem by ensuring that an individual only > gets delivered one copy of an email (based on the message ID) > (ie at the delivery stage) This is indeed what I need. (it apparently also notices that you are Cced in a mail and doesn't send the post copy to you) > What problem are you trying to tackle? People who are trying to set reply-to munging because they don't want receipients to receive two copies of the posts. While the solution is bad, the initial need is real. (well, there is also that part about "reply to all" being apparently much harder to use than "reply", but I tend to dismiss that) > PS. Marc, coming to LCA 2002? http://www.linux.org.au/conf/ I submitted 5 or 6 papers. Hopefully they'll pick one up :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jra@baylink.com Tue Oct 16 16:41:04 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 16 Oct 2001 11:41:04 -0400 Subject: [Mailman-Developers] handling duplicate mails In-Reply-To: <20011016083343.F8534@magic.merlins.org>; from Marc MERLIN on Tue, Oct 16, 2001 at 08:33:44AM -0700 References: <20011014212553.B531@moremagic.merlins.org> <20011016083343.F8534@magic.merlins.org> Message-ID: <20011016114104.05333@scfn.thpl.lib.fl.us> On Tue, Oct 16, 2001 at 08:33:44AM -0700, Marc MERLIN wrote: > > What problem are you trying to tackle? > > People who are trying to set reply-to munging because they don't want > receipients to receive two copies of the posts. While the solution is bad, > the initial need is real. > (well, there is also that part about "reply to all" being apparently much > harder to use than "reply", but I tend to dismiss that) Yes, but note that (as I mentioned earlier), the fact that you got a copy from the list *carries a meaning* additional to its content: that the rest of the list got to see it also. If I was on a list, and got copies of messages to me that were *not* also carboned to me, but did *not* get messages from the list which it "noticed" *were* carboned to me as well, *I* would assume the list wasn't reliable, and I suspect I'm not alone. People who get duplicate copies because senders don't understand how to deal with mailing lists, or who won't switch to a *mailer* that understands how to deal with mailing lists, should have the pain of the recipients we're trying to protect here transferred to *them*. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From dgc@uchicago.edu Tue Oct 16 17:37:46 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 16 Oct 2001 11:37:46 -0500 Subject: [Mailman-Developers] Re: handling duplicate mails In-Reply-To: <20011016083343.F8534@magic.merlins.org> References: <20011014212553.B531@moremagic.merlins.org> <20011016083343.F8534@magic.merlins.org> Message-ID: <20011016113746.I23544@dust.uchicago.edu> On 2001.10.16, in <20011016083343.F8534@magic.merlins.org>, "Marc MERLIN" wrote: > > Ben's attacks the problem by ensuring that an individual only > > gets delivered one copy of an email (based on the message ID) > > (ie at the delivery stage) > > This is indeed what I need. > (it apparently also notices that you are Cced in a mail and doesn't send the > post copy to you) Please, no. If a message goes to a list, I want to receive it from the list. That's critical to local archiving, and it has some effect on how a recipient perceives the message itself. I'd rather not get the direct cc:, actually, though of course there's no way for Mailman to affect that. -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Tue Oct 16 17:47:42 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 16 Oct 2001 12:47:42 -0400 Subject: [Mailman-Developers] Re: handling duplicate mails In-Reply-To: <20011016113746.I23544@dust.uchicago.edu>; from David Champion on Tue, Oct 16, 2001 at 11:37:46AM -0500 References: <20011014212553.B531@moremagic.merlins.org> <20011016083343.F8534@magic.merlins.org> <20011016113746.I23544@dust.uchicago.edu> Message-ID: <20011016124742.13997@scfn.thpl.lib.fl.us> On Tue, Oct 16, 2001 at 11:37:46AM -0500, David Champion wrote: > On 2001.10.16, in <20011016083343.F8534@magic.merlins.org>, > "Marc MERLIN" wrote: > > > Ben's attacks the problem by ensuring that an individual only > > > gets delivered one copy of an email (based on the message ID) > > > (ie at the delivery stage) > > > > This is indeed what I need. > > (it apparently also notices that you are Cced in a mail and doesn't send the > > post copy to you) > > Please, no. If a message goes to a list, I want to receive it from the > list. That's critical to local archiving, and it has some effect on how > a recipient perceives the message itself. I'd rather not get the direct > cc:, actually, though of course there's no way for Mailman to affect > that. Good; it isn't just me. Note that, in the latter case, it's possible that you could use formail (from the procmail package) to drop the non-list copy, assuming you got the list copy first -- but that rarely happens, for semi-obvious reasons. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From rodolfo@linux.org.uy Tue Oct 16 23:26:41 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 16 Oct 2001 19:26:41 -0300 Subject: [Mailman-Developers] CPU usage again Message-ID: <1003271201.18090.127.camel@claudia> I have the problem again: # uptime 8:43pm up 5:44, 1 user, load average: 1.08, 1.02, 1.01 # ps ax 738 ? S 0:00 python bin/mailmanctl -n start 739 ? S 0:00 python bin/mailmanctl -n start 740 ? S 0:20 python bin/mailmanctl -n start 741 ? S 0:12 python bin/mailmanctl -n start 742 ? S 0:00 python bin/mailmanctl -n start 743 ? D 288:55 python bin/mailmanctl -n start 744 ? S 0:01 python bin/mailmanctl -n start 745 ? S 0:00 python bin/mailmanctl -n start # ls locks/ uylug-directiva.lock.guru.743 (and others) # strace kill 743 execve("/bin/kill", ["kill", "743"], [/* 41 vars */]) = 0 uname({sys="Linux", node="guru", ...}) = 0 brk(0) = 0x804aa20 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=17794, ...}) = 0 old_mmap(NULL, 17794, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40017000 close(4) = 0 open("/lib/libc.so.6", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\315\1"..., 1024) = 1024 fstat64(4, {st_mode=S_IFREG|0755, st_size=1343073, ...}) = 0 old_mmap(NULL, 1164516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x4001c000 mprotect(0x4012f000, 38116, PROT_NONE) = 0 old_mmap(0x4012f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x112000) = 0x4012f000 old_mmap(0x40135000, 13540, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40135000 close(4) = 0 munmap(0x40017000, 17794) = 0 getpid() = 4849 brk(0) = 0x804aa20 brk(0x804aa48) = 0x804aa48 brk(0x804b000) = 0x804b000 open("/usr/share/locale/locale.alias", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=2567, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(4, "# Locale name alias data base.\n#"..., 4096) = 2567 brk(0x804c000) = 0x804c000 read(4, "", 4096) = 0 close(4) = 0 munmap(0x40017000, 4096) = 0 open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=110304, ...}) = 0 old_mmap(NULL, 110304, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40139000 close(4) = 0 kill(743, SIGTERM) = 0 _exit(0) = ? # tail logs/qrunner Oct 16 21:11:00 2001 (738) Master qrunner detected subprocess exit (pid: 743, sig: 15, sts: 0, class: ArchRunner, slice: 1/1) # bin/mailmanctrl restart .... and some time after restart mailmanctrl # ps ax 5244 ? S 0:00 python bin/mailmanctl -n start 5245 ? S 0:00 python bin/mailmanctl -n start 5246 ? S 0:00 python bin/mailmanctl -n start 5247 ? S 0:00 python bin/mailmanctl -n start 5248 ? S 0:00 python bin/mailmanctl -n start 5249 ? R 28:34 python bin/mailmanctl -n start 5250 ? S 0:00 python bin/mailmanctl -n start 5251 ? S 0:00 python bin/mailmanctl -n start Parece joda! (it seems like a joke!) -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From che@debian.org Wed Oct 17 01:40:46 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 17 Oct 2001 09:40:46 +0900 Subject: [Mailman-Developers] Re: handling duplicate mails In-Reply-To: <20011016113746.I23544@dust.uchicago.edu> (David Champion's message of "Tue, 16 Oct 2001 11:37:46 -0500") References: <20011014212553.B531@moremagic.merlins.org> <20011016083343.F8534@magic.merlins.org> <20011016113746.I23544@dust.uchicago.edu> Message-ID: <87d73ngktt.fsf@nausicaa.interq.or.jp> >>>>> "David" == David Champion writes: David> Please, no. If a message goes to a list, I want to receive David> it from the list. That's critical to local archiving, and David> it has some effect on how a recipient perceives the message David> itself. I'd rather not get the direct cc:, actually, though David> of course there's no way for Mailman to affect that. The patch I wrote made the duplicate suppression a per-user option, and it's off by default. Only people who don't know how to set up their mailer to suppress duplicates locally should use it. Ben -- Brought to you by the letters C and X and the number 11. "Wuzzle means to mix." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Wed Oct 17 01:42:33 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 17 Oct 2001 09:42:33 +0900 Subject: [Mailman-Developers] CPU usage again In-Reply-To: <1003271201.18090.127.camel@claudia> (Rodolfo Pilas's message of "16 Oct 2001 19:26:41 -0300") References: <1003271201.18090.127.camel@claudia> Message-ID: <878zebgkqu.fsf@nausicaa.interq.or.jp> >>>>> "Rodolfo" == Rodolfo Pilas writes: Rodolfo> I have the problem again: Rodolfo> load average: 1.08, 1.02, 1.01 Rodolfo> # tail logs/qrunner Oct 16 21:11:00 2001 (738) Master Rodolfo> qrunner detected subprocess exit (pid: 743, sig: 15, sts: Rodolfo> 0, class: ArchRunner, slice: 1/1) How big are your .mbox files in the mailman/archives/private/* directories? I had the exact same problem until I turned off internal archiving; once my .mbox files got too big, the ArchRunner took up 100% of the CPU and took hours to run. Try turning on external archiving and switching to Hypermail. It's a better archiver anyway. Ben -- Brought to you by the letters K and Z and the number 7. "Elate means having wings." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From marc_news@valinux.com Wed Oct 17 09:17:24 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Wed, 17 Oct 2001 01:17:24 -0700 Subject: [Mailman-Developers] handling duplicate mails In-Reply-To: <20011016114104.05333@scfn.thpl.lib.fl.us>; from jra@baylink.com on Tue, Oct 16, 2001 at 11:41:04AM -0400 References: <20011014212553.B531@moremagic.merlins.org> <20011016083343.F8534@magic.merlins.org> <20011016114104.05333@scfn.thpl.lib.fl.us> Message-ID: <20011017011724.K8534@magic.merlins.org> On Tue, Oct 16, 2001 at 11:41:04AM -0400, Jay R. Ashworth wrote: > On Tue, Oct 16, 2001 at 08:33:44AM -0700, Marc MERLIN wrote: > > > What problem are you trying to tackle? > > > > People who are trying to set reply-to munging because they don't want > > receipients to receive two copies of the posts. While the solution is bad, > > the initial need is real. > > (well, there is also that part about "reply to all" being apparently much > > harder to use than "reply", but I tend to dismiss that) > > Yes, but note that (as I mentioned earlier), the fact that you got a > copy from the list *carries a meaning* additional to its content: that > the rest of the list got to see it also. Oh, don't take me wrong, I'm fully aware of that. See: http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1 (second paragraph of "So what does this mean for the list users?" > If I was on a list, and got copies of messages to me that were *not* > also carboned to me, but did *not* get messages from the list which it > "noticed" *were* carboned to me as well, *I* would assume the list > wasn't reliable, and I suspect I'm not alone. That was already answered, but again, the patch makes it a per user option. > People who get duplicate copies because senders don't understand how to > deal with mailing lists, or who won't switch to a *mailer* that > understands how to deal with mailing lists, should have the pain of the > recipients we're trying to protect here transferred to *them*. Can I have you answer the Sourceforge tickets^H^H^H^H^H^Hflames from people who are telling me that their life absolutely ends if they can't have the reply-to munging on their list? :-& Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Wed Oct 17 09:23:05 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Wed, 17 Oct 2001 01:23:05 -0700 Subject: [Mailman-Developers] moderate by user? In-Reply-To: <15307.13825.482306.392448@anthem.wooz.org>; from barry@zope.com on Mon, Oct 15, 2001 at 03:16:17PM -0400 References: <20011012141404.B24775@work.bitmover.com> <19157.1002958141@kanga.nu> <15307.13825.482306.392448@anthem.wooz.org> Message-ID: <20011017012305.L8534@magic.merlins.org> On Mon, Oct 15, 2001 at 03:16:17PM -0400, Barry A. Warsaw wrote: > Ah, I hadn't thought about that (making it visible but not modifiable > by the user). Right now, it's not even visible, although it's pretty > obvious should the user post to a list. Do you also have the "post only" flag so that I can make the difference between an Email that's temporarily not receiving messages due to bounces or the user being on vacation vs an Email that's "post only"? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From liuk@publinet.it Wed Oct 17 11:15:41 2001 From: liuk@publinet.it (Luca Maranzano) Date: Wed, 17 Oct 2001 12:15:41 +0200 Subject: [Mailman-Developers] ADMINDB_PAGE_TEXT_LIMIT = -1 does not work Message-ID: <20011017121541.C5126@publinet.it> Hi, putting ADMINDB_PAGE_TEXT_LIMIT = -1 in mm_cfg.py to view all the message to be approved, seems to not work properly. In the web page for the approvation in the "message excerpts" appears only the first line of the message. I've put ADMINDB_PAGE_TEXT_LIMIT = 12000 hoping it will suffice :) Regards, Luca From jra@baylink.com Wed Oct 17 14:31:21 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Oct 2001 09:31:21 -0400 Subject: [Mailman-Developers] handling duplicate mails In-Reply-To: <20011017011724.K8534@magic.merlins.org>; from Marc MERLIN on Wed, Oct 17, 2001 at 01:17:24AM -0700 References: <20011014212553.B531@moremagic.merlins.org> <20011016083343.F8534@magic.merlins.org> <20011016114104.05333@scfn.thpl.lib.fl.us> <20011017011724.K8534@magic.merlins.org> Message-ID: <20011017093121.00437@scfn.thpl.lib.fl.us> On Wed, Oct 17, 2001 at 01:17:24AM -0700, Marc MERLIN wrote: > http://sourceforge.net/docman/display_doc.php?docid=6693&group_id=1 > (second paragraph of "So what does this mean for the list users?" I will. > > If I was on a list, and got copies of messages to me that were *not* > > also carboned to me, but did *not* get messages from the list which it > > "noticed" *were* carboned to me as well, *I* would assume the list > > wasn't reliable, and I suspect I'm not alone. > > That was already answered, but again, the patch makes it a per user option. Which is fine, with me. > > People who get duplicate copies because senders don't understand how to > > deal with mailing lists, or who won't switch to a *mailer* that > > understands how to deal with mailing lists, should have the pain of the > > recipients we're trying to protect here transferred to *them*. > > Can I have you answer the Sourceforge tickets^H^H^H^H^H^Hflames from people > who are telling me that their life absolutely ends if they can't have the > reply-to munging on their list? :-& You *bet*. With a copy of Chip's paper clutched firmly in my hand. I *love* larting morons. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From rodolfo@linux.org.uy Wed Oct 17 17:01:39 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 17 Oct 2001 13:01:39 -0300 Subject: [Mailman-Developers] CPU usage again In-Reply-To: <878zebgkqu.fsf@nausicaa.interq.or.jp> References: <1003271201.18090.127.camel@claudia> <878zebgkqu.fsf@nausicaa.interq.or.jp> Message-ID: <1003334500.30244.36.camel@claudia> En Tue, 2001-10-16 a 21:42, Ben Gertzfield escribio: > >>>>> "Rodolfo" == Rodolfo Pilas writes: > > Rodolfo> I have the problem again: > Rodolfo> load average: 1.08, 1.02, 1.01 > > Rodolfo> # tail logs/qrunner Oct 16 21:11:00 2001 (738) Master > Rodolfo> qrunner detected subprocess exit (pid: 743, sig: 15, sts: > Rodolfo> 0, class: ArchRunner, slice: 1/1) > > How big are your .mbox files in the mailman/archives/private/* > directories? I had the exact same problem until I turned off internal > archiving; once my .mbox files got too big, the ArchRunner took up > 100% of the CPU and took hours to run. It is not big: # du -h /var/spool/mailman/archives/private/ 9.1M /var/spool/mailman/archives/private but I am thinking that the problem is perhaps in the pipermail system. -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From igor@linuxinside.com Wed Oct 17 19:29:28 2001 From: igor@linuxinside.com (Igor Pruchanskiy) Date: Wed, 17 Oct 2001 11:29:28 -0700 Subject: [Mailman-Developers] Password Question.... Message-ID: <20011017112928.A31009@linuxinside.com> Hello all, I was wondering if there is any way to disable passwords for mailman ? The reason i am asking is i am making a little Mailing List sign up form right on the front page where users can subscribe or unsubscribe to/from the list... There are no problems with subscribtion, since Mailman generates a pasword and sends it to the user, but to unsubscribe user has to enter a password, which requires me to add another input field to the form.... So i was wondering if there is a way to disable the password for UNsubscribing people, requiring them to just reply to the email... that Mailman will send.... igor -- Uptime: 45 days, 11:38 From Dan Mick Wed Oct 17 22:21:48 2001 From: Dan Mick (Dan Mick) Date: Wed, 17 Oct 2001 14:21:48 -0700 (PDT) Subject: [Mailman-Developers] Password Question.... Message-ID: <200110172121.OAA10076@utopia.West.Sun.COM> > I was wondering if there is any way to disable passwords for mailman ? Available in 2.1, which is now in alpha. That feature is working fine. Also, as a bonus, you get "click this URL link to confirm" in the confirmation email. From Dan Mick Wed Oct 17 22:53:08 2001 From: Dan Mick (Dan Mick) Date: Wed, 17 Oct 2001 14:53:08 -0700 (PDT) Subject: [Mailman-Developers] ADMINDB_PAGE_TEXT_LIMIT = -1 does not work Message-ID: <200110172152.OAA12468@utopia.West.Sun.COM> > putting ADMINDB_PAGE_TEXT_LIMIT = -1 in mm_cfg.py to view all the > message to be approved, seems to not work properly. ...in 2.1 CVS. Yup, seems to be the case. I've filed a bug with a fix that works for me (to be made much more elegant by Barry :) From igor@linuxinside.com Thu Oct 18 01:12:17 2001 From: igor@linuxinside.com (Igor Pruchanskiy) Date: Wed, 17 Oct 2001 17:12:17 -0700 Subject: [Mailman-Developers] Another Problem Message-ID: <20011017171217.A8556@linuxinside.com> Hello again, I have been talking about my password problem with Dan Mick, who was kind enough to help me to resolve all the issues and had me update to the CVS version of Mailman. Now i do not need to use passwords to subscribe/unsubscribe users.... However, there is another problem with that.... I can subscribe to the list just fine from my web based form, but when i try to unsubscribe i get 3 e-mail messages One is removal confirmation request Another one says that removal confirmation has been sent And the 3rd one is a little weird On top is says that There were problems with the email commands you sent to Mailman via the administrative address solaris-users-request@sdsug.org. But lower i see ***** confirm d2e1f633d91c94977766c36d2290b6271c9df703 Succeeded Am i missing something ? Why do i get an error message ? You can subscribe/unsubscribe yourself here: http://www.sdsug.org/?show=lists igor -- Uptime: 45 days, 16:53 From Dan Mick Thu Oct 18 01:22:35 2001 From: Dan Mick (Dan Mick) Date: Wed, 17 Oct 2001 17:22:35 -0700 (PDT) Subject: [Mailman-Developers] Another Problem Message-ID: <200110180021.RAA22071@utopia.West.Sun.COM> Yes, I've seen this too. I think the "auto-confirm" message isn't quite right. It's an error you can ignore (and one you don't get if you do the web confirmation dance rather than email); as you can see, the 'confirm' command succeeded. Either the email command parser is too picky, or the format of the confirm message is off (should have 'end' in it or something to stop the command parser from trying to parse). > And the 3rd one is a little weird > > On top is says that > > There were problems with the email commands you sent to Mailman via > the administrative address solaris-users-request@sdsug.org. > > But lower i see > > ***** confirm d2e1f633d91c94977766c36d2290b6271c9df703 > Succeeded > > Am i missing something ? > Why do i get an error message ? From igor@linuxinside.com Thu Oct 18 01:37:41 2001 From: igor@linuxinside.com (Igor Pruchanskiy) Date: Wed, 17 Oct 2001 17:37:41 -0700 Subject: [Mailman-Developers] Another Problem In-Reply-To: <200110180021.RAA22071@utopia.West.Sun.COM> References: <200110180021.RAA22071@utopia.West.Sun.COM> Message-ID: <20011017173741.B8556@linuxinside.com> > Yes, I've seen this too. I think the "auto-confirm" message > isn't quite right. It's an error you can ignore (and one > you don't get if you do the web confirmation dance rather > than email); as you can see, the 'confirm' command succeeded. > > Either the email command parser is too picky, or the format > of the confirm message is off (should have 'end' in it or > something to stop the command parser from trying to parse). Ah... i see... I am fine with that, i just did not want (l)users to get all confused.... We are a Solaris user group, but some members are either really picky or confused :) I put some php code in my .signature just for fun, and someone asked me to remove it, because they we afraid that i wanted to run my code on their machines... go figure :) igor -- Uptime: 45 days, 17:49 From che@debian.org Thu Oct 18 02:42:23 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 18 Oct 2001 10:42:23 +0900 Subject: [Mailman-Developers] CPU usage again In-Reply-To: <1003334500.30244.36.camel@claudia> (Rodolfo Pilas's message of "17 Oct 2001 13:01:39 -0300") References: <1003271201.18090.127.camel@claudia> <878zebgkqu.fsf@nausicaa.interq.or.jp> <1003334500.30244.36.camel@claudia> Message-ID: <87g08h2074.fsf@nausicaa.interq.or.jp> >>>>> "Rodolfo" == Rodolfo Pilas writes: Rodolfo> It is not big: Rodolfo> # du -h /var/spool/mailman/archives/private/ 9.1M Rodolfo> /var/spool/mailman/archives/private Rodolfo> but I am thinking that the problem is perhaps in the Rodolfo> pipermail system. Try turning off internal archiving (only archive to the mbox file) and see if your problem goes away. Ben -- Brought to you by the letters U and J and the number 8. "I don't want the world.. I just want your half." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From claw@2wire.com Fri Oct 19 20:34:05 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 12:34:05 -0700 Subject: [Mailman-Developers] Reply-To: handling Message-ID: <23646.1003520045@2wire.com> I've been reading RFC 2822 on the subject of Reply-To and noticed that the content of Reply-To is a list. ie you can have more than one address listed under a Reply-To: reply-to = "Reply-To:" address-list CRLF address-list = (address *("," address)) / obs-addr-list address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] display-name = phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list eg: Reply-To: list@foo.conm, list@bar.com, claw@kanga.nu This would seem to potentially remove one of the complaints on Reply-To: lists -- that they nix/kill crossposting, and lose the actual semantic value of the original Reply-To header. Ergo, if a given list is configured to do reply-To munging and it receives a message with Reply-To set, then it makes sense to _ADD_ the list's address to the Reply-To: header if present, rather than replacing it. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jra@baylink.com Fri Oct 19 20:39:10 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 19 Oct 2001 15:39:10 -0400 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <23646.1003520045@2wire.com>; from J C Lawrence on Fri, Oct 19, 2001 at 12:34:05PM -0700 References: <23646.1003520045@2wire.com> Message-ID: <20011019153910.08995@scfn.thpl.lib.fl.us> On Fri, Oct 19, 2001 at 12:34:05PM -0700, J C Lawrence wrote: > I've been reading RFC 2822 on the subject of Reply-To and noticed > that the content of Reply-To is a list. ie you can have more than > one address listed under a Reply-To: > > reply-to = "Reply-To:" address-list CRLF > address-list = (address *("," address)) / obs-addr-list > address = mailbox / group > mailbox = name-addr / addr-spec > name-addr = [display-name] angle-addr > angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr > group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] > display-name = phrase > mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list > > eg: > > Reply-To: list@foo.conm, list@bar.com, claw@kanga.nu > > This would seem to potentially remove one of the complaints on > Reply-To: lists -- that they nix/kill crossposting, and lose the > actual semantic value of the original Reply-To header. > > Ergo, if a given list is configured to do reply-To munging and it > receives a message with Reply-To set, then it makes sense to _ADD_ > the list's address to the Reply-To: header if present, rather than > replacing it. Assuming that mailers correctly handle such a Reply-to. And note that this message arrived here with no To: header, FWIW. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From claw@2wire.com Fri Oct 19 20:48:29 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 12:48:29 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from "Jay R. Ashworth" of "Fri, 19 Oct 2001 15:39:10 EDT." <20011019153910.08995@scfn.thpl.lib.fl.us> References: <23646.1003520045@2wire.com> <20011019153910.08995@scfn.thpl.lib.fl.us> Message-ID: <26809.1003520909@2wire.com> On Fri, 19 Oct 2001 15:39:10 -0400 Jay R Ashworth wrote: > On Fri, Oct 19, 2001 at 12:34:05PM -0700, J C Lawrence wrote: >> I've been reading RFC 2822 on the subject of Reply-To and noticed >> that the content of Reply-To is a list. ie you can have more >> than one address listed under a Reply-To: ... >> Ergo, if a given list is configured to do reply-To munging and it >> receives a message with Reply-To set, then it makes sense to >> _ADD_ the list's address to the Reply-To: header if present, >> rather than replacing it. > Assuming that mailers correctly handle such a Reply-to. True. If we insert the list address at the head of the reply-to list then broken MUAs would seem unlikely to change their behaviour (or so quick testing here with a couple such MUAs suggests). BTW: Do Mutt et al correctly handle multi-address Reply-To? > And note that this message arrived here with no To: header, FWIW. My bad. To save myself typing I started the message by doing a group reply to a -dev post and whacking the headers to match (which I then failed to do cleanly). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jra@baylink.com Fri Oct 19 21:21:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 19 Oct 2001 16:21:55 -0400 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <26809.1003520909@2wire.com>; from J C Lawrence on Fri, Oct 19, 2001 at 12:48:29PM -0700 References: <23646.1003520045@2wire.com> <20011019153910.08995@scfn.thpl.lib.fl.us> <26809.1003520909@2wire.com> Message-ID: <20011019162155.22507@scfn.thpl.lib.fl.us> On Fri, Oct 19, 2001 at 12:48:29PM -0700, J C Lawrence wrote: > > Assuming that mailers correctly handle such a Reply-to. > > True. If we insert the list address at the head of the reply-to > list then broken MUAs would seem unlikely to change their behaviour > (or so quick testing here with a couple such MUAs suggests). Indeed. > BTW: Do Mutt et al correctly handle multi-address Reply-To? Unknown. I'll have to try it. > > And note that this message arrived here with no To: header, FWIW. > > My bad. To save myself typing I started the message by doing a > group reply to a -dev post and whacking the headers to match (which > I then failed to do cleanly). ...exposing a bug in Mutt: it will find a list-name in a CC header... as long as there *is* a To header. It couldn't tell the message in question was a mailing list message. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From claw@2wire.com Fri Oct 19 21:54:28 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 13:54:28 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from "Jay R. Ashworth" of "Fri, 19 Oct 2001 16:21:55 EDT." <20011019162155.22507@scfn.thpl.lib.fl.us> References: <23646.1003520045@2wire.com> <20011019153910.08995@scfn.thpl.lib.fl.us> <26809.1003520909@2wire.com> <20011019162155.22507@scfn.thpl.lib.fl.us> Message-ID: <604.1003524868@2wire.com> On Fri, 19 Oct 2001 16:21:55 -0400 Jay R Ashworth wrote: > On Fri, Oct 19, 2001 at 12:48:29PM -0700, J C Lawrence wrote: >> BTW: Do Mutt et al correctly handle multi-address Reply-To? > Unknown. I'll have to try it. FWVLIW nmh/exmh do The Right Thing. Pine didn't seem to. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Fri Oct 19 22:15:29 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Oct 2001 17:15:29 -0400 Subject: [Mailman-Developers] Reply-To: handling References: <23646.1003520045@2wire.com> Message-ID: <15312.38897.589704.813053@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Ergo, if a given list is configured to do reply-To munging JCL> and it receives a message with Reply-To set, then it makes JCL> sense to _ADD_ the list's address to the Reply-To: header if JCL> present, rather than replacing it. VM/XEmacs does the right thing too, with both Reply-To: that contains multiple addresses, and multiple Reply-To: headers in the original message. I'll rework the munging code for the next alpha to augment the header instead of replacing it. It would be easier to simply add a new Reply-To: header. Can you guys check to see if multiple Reply-To: headers are honored too? -Barry From claw@2wire.com Fri Oct 19 22:37:40 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 14:37:40 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 19 Oct 2001 17:15:29 EDT." <15312.38897.589704.813053@anthem.wooz.org> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> Message-ID: <5553.1003527460@2wire.com> On Fri, 19 Oct 2001 17:15:29 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Ergo, if a given list is configured to do reply-To munging and JCL> it receives a message with Reply-To set, then it makes sense to JCL> _ADD_ the list's address to the Reply-To: header if present, JCL> rather than replacing it. > VM/XEmacs does the right thing too, with both Reply-To: that > contains multiple addresses, and multiple Reply-To: headers in the > original message. If I'm reading it correctly, multiple Reply-To headers violates RFC 2822. The fact that VM supports it is fine, but that doesn't mean Mailman should emit it. Be generous in what your accept and conservative and what you emit. > I'll rework the munging code for the next alpha to augment the > header instead of replacing it. It would be easier to simply add > a new Reply-To: header. Can you guys check to see if multiple > Reply-To: headers are honored too? Note: Need to make sure you do duplicate collapsing of the Reply-To header in case the poster has already set Reply-To to the list in effort to nix CC: dupes. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Fri Oct 19 22:44:29 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Oct 2001 17:44:29 -0400 Subject: [Mailman-Developers] Reply-To: handling References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> Message-ID: <15312.40637.81391.220441@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> If I'm reading it correctly, multiple Reply-To headers JCL> violates RFC 2822. The fact that VM supports it is fine, but JCL> that doesn't mean Mailman should emit it. You're right of course, see section 3.6: Field Min number Max number Notes reply-to 0 1 (I'm battling a cold and lack of sleep so apologies for having been lazy about looking it up.) JCL> Note: Need to make sure you do duplicate collapsing of the JCL> Reply-To header in case the poster has already set Reply-To JCL> to the list in effort to nix CC: dupes. Are you suggesting that we collapse Reply-To: even if we don't add one ourselves? I would think that we should only collapse if we're adding a value. -Barry From chuqui@plaidworks.com Fri Oct 19 22:54:32 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Oct 2001 14:54:32 -0700 Subject: [Mailman-Developers] Mailman and cookies. In-Reply-To: <15312.40637.81391.220441@anthem.wooz.org> Message-ID: Ran into a fun one the other day. I came to work, tried to log onto one of my lists, and started getting server errors out of the web server. Mailman was broken. So I immediately went to my assistant to see if he'd changed anything -- and it was working for him. Borrowed a co-worker's computer, and sure enough, the system was working fine, except when I tried to use it. Restarted the browser. Nothing. Cleared the cache. Rebooted my desktop. Restarted the web server. After 20 minutes or so, I finally tracked it down. Some other site at apple had lodged a cookie in my browser. When Mailman tried to read my cookies to validate my browser, it was causing the admin CGI to core dump. This is bad on any number of levels. Mailman 2.0.5 isn't reading cookies right; it seems to be making assumptions about what will be there. The cookie (no, I don't have details about what was IN it) was set to "apple.com". Why that would affect a program reading cookies for www.lists.apple.com, I dunno. But it ALSO bothers me that I can create a cookie that not only affects mailman, but causes the CGI to core-dump. IT seems to me there's a serious opportunity for havoc. Barry, I think you need to take a look at your cookie code, and look for ways to bullet-proof it. It seems to have some assumptions that I found out the hard way aren't safe. From barry@zope.com Fri Oct 19 23:08:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Oct 2001 18:08:46 -0400 Subject: [Mailman-Developers] Mailman and cookies. References: <15312.40637.81391.220441@anthem.wooz.org> Message-ID: <15312.42094.299631.582293@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> After 20 minutes or so, I finally tracked it down. Some other CVR> site at apple had lodged a cookie in my browser. When Mailman CVR> tried to read my cookies to validate my browser, it was CVR> causing the admin CGI to core dump. Core dumped, right? Not caused a traceback? Python's like any other interpreted or byte compiled language: in theory you should never be able to write pure Python code that can crash the interpreter. Such a situation is by definition a bug in the interpreter. Are you running Python 1.5.2? I vaguely recall that it was possible to crash Python with some sequence of cookie data. [quick google search...] Here's an article in the middle of a thread about this on the Python mailing list. It contains a patch (which I can't vouch for). http://mail.python.org/pipermail/python-list/1999-July/006953.html Note the date. :) Suggestions: 1) upgrade Python to 2.1.1 and Mailman to 2.0.6. 2) apply the patch suggested above and see if the crashes go away. -Barry From chuqui@plaidworks.com Fri Oct 19 23:16:23 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Oct 2001 15:16:23 -0700 Subject: [Mailman-Developers] Mailman and cookies. In-Reply-To: <15312.42094.299631.582293@anthem.wooz.org> Message-ID: On 10/19/01 3:08 PM, "Barry A. Warsaw" wrote: > Core dumped, right? Not caused a traceback? Correct. Left a corefile. > Are you running Python 1.5.2? I vaguely recall that it was possible > to crash Python with some sequence of cookie data. Yes. Haven't updated yet. Haven't needed to... > 1) upgrade Python to 2.1.1 and Mailman to 2.0.6. > 2) apply the patch suggested above and see if the crashes go away. Thanks. Ahead of the game again, I see. From claw@2wire.com Fri Oct 19 23:21:09 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 15:21:09 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Fri, 19 Oct 2001 17:44:29 EDT." <15312.40637.81391.220441@anthem.wooz.org> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <15312.40637.81391.220441@anthem.wooz.org> Message-ID: <7644.1003530069@2wire.com> On Fri, 19 Oct 2001 17:44:29 -0400 Barry A Warsaw wrote: > Field Min number Max number Notes reply-to 0 1 Thanks. > Are you suggesting that we collapse Reply-To: even if we don't add > one ourselves? No. I specifically think we should collapse duplicate list addresses in the Reply-To. Duplicate other addresses in the Reply-To are likely not good, but are also not our responsibility. Note: This does expose an abuse vector: I don't like Bubba. I send a troll to a busy list with Reply-To set to Bubba. Bubba is inundated with unwanted mail. There is little/nothing Bubba can do about it. I get away clean. This abuse vector currently exists for non-reply-to munging lists. The only difference is that with the change I'm advocating is that it now also exists for reply-to munging lists where it didn't before. Its easy to view this as either a Good or Bad Thing. I side on adding to any extant Reply-To being a Good Thing in balance. > I would think that we should only collapse if we're adding a > value. Agreed. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@2wire.com Fri Oct 19 23:30:27 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 15:30:27 -0700 Subject: [Mailman-Developers] Mailman and cookies. In-Reply-To: Message from Chuq Von Rospach of "Fri, 19 Oct 2001 15:16:23 PDT." References: Message-ID: <8715.1003530627@2wire.com> On Fri, 19 Oct 2001 15:16:23 -0700 Chuq Von Rospach wrote: >> 1) upgrade Python to 2.1.1 and Mailman to 2.0.6. 2) apply the >> patch suggested above and see if the crashes go away. > Thanks. Ahead of the game again, I see. I'm a little more interested in whether the core happens with an unpatched Python 2.1.1... -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Fri Oct 19 23:32:44 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Oct 2001 15:32:44 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <7644.1003530069@2wire.com> Message-ID: On 10/19/01 3:21 PM, "J C Lawrence" wrote: > Note: This does expose an abuse vector: > > I don't like Bubba. > > I send a troll to a busy list with Reply-To set to Bubba. Aka the "set your followup to /dev/null" on usenet hack. I'm of the opinion, and I don't expect to be in the majority, that "reply-to" should not transport through a mail list. Either the mail list replaces it with a list-centric one, or it deletes it. The only people overtly screwed over by this are the people who insist on mailing from one address and getting you to reply elsewhere. Something like: From: chuq@apple.com Subject: spoofed headers! To: mailman-developers@python.org Reply-to: chuqles-da-clown@hotmail.com Which is a lame attempt (IMHO) to use a single subscribed address from multiple places, which I don't think should be encouraged anyway (instead use the NOMAIL hack, dammit! grin. The real answer are aliases attached to a subscripiton) My argument is that when I send mail to the list, the list processes it and then sends out a new message that my message is the basis of it. At that point, the original reply-to is no longer valid, it's what the list software says should happen that matters. As the bubba-hack shows, to NOT do this opens up lists to abuse in not-necessarily-obvious ways, and worse, you leave things in ambiguous states, depending on factors most users don't understand. Lists act differently based on whether it reply-to coerces and whether the original poster coerces reply-to, and you have the issue of which coerced reply-to 'wins'. How is the typical user to understand how this all works together, and why when they reply to a list, this happens, except when it's fred's message? It seems from a consistency's sake, the MLM ought to handle this stuff unambiguously, which means ONLY mailman's reply-to (or lack of it) ought be be propogated. From claw@2wire.com Sat Oct 20 00:04:22 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 16:04:22 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from Chuq Von Rospach of "Fri, 19 Oct 2001 15:32:44 PDT." References: Message-ID: <16155.1003532662@2wire.com> On Fri, 19 Oct 2001 15:32:44 -0700 Chuq Von Rospach wrote: > On 10/19/01 3:21 PM, "J C Lawrence" wrote: >> Note: This does expose an abuse vector: >> >> I don't like Bubba. >> >> I send a troll to a busy list with Reply-To set to Bubba. > Aka the "set your followup to /dev/null" on usenet hack. > I'm of the opinion, and I don't expect to be in the majority, that > "reply-to" should not transport through a mail list. Either the > mail list replaces it with a list-centric one, or it deletes it. There are three base reasons people set Reply-To: 1) They're rewriting their From: header. 2) They're attempting to move a thread to another forum. 3) They're attempting to kill CC'ed posts to themselves by setting Reply-To to the list they're posting to. I've already addressed the (fourth) abuse vector. Taking the three in order: #1 is not fundamentally affected by the change except that they now starg getting CC's. For reasons not dissimilar to Chuq's I don't have much sympathy for this. #2 Will work, partially. With reply-to replacement replies would never see the other forum. With reply-to extension they'll see both the other forum and the list list. #3 Won't change at all as they'll get dupe collapsed > The real answer are aliases attached to a subscripiton) Agreed. Different problem tho. > My argument is that when I send mail to the list, the list > processes it and then sends out a new message that my message is > the basis of it. The debate then is how much influence a poster should have over the disposition of such a message. Specifically, given that a poster to a non-reply-to list can entirely control the disposition via reply-to, how should those abilities be curtailed for a reply-to list? By doing reply-to extension we're changing practice as follows: -- Posters can _add_ to a posts disposition list via Reply-To. This is different from non-reply-to lists where posters can entirely replace and define disposition via reply-to. -- Posters can attempt to move threads to a different forum. Essentially they can create crossposted threads via reply-to. Unlike non-reply-to setting lists they can't make a thread leave a list, they can only add another disposition. Unlike reply-to replacement, you _CAN_ now have a crossposted thread. -- Under reply-to extension the original poster who sets reply-to has the ability to expose an additional address to all subsequent thread posts. This can be abused, but can also be a Very Good Thing as it allows, for instance, a non-list-member to track and aprticipate in a specific thread. Under reply-to replacement you'd have to be a member of the list to follow the thread (thus all the requests of, "Please CC me I'm not on the list"). > At that point, the original reply-to is no longer valid, it's what > the list software says should happen that matters. As the > bubba-hack shows, to NOT do this opens up lists to abuse in > not-necessarily-obvious ways, and worse, you leave things in > ambiguous states, depending on factors most users don't > understand. Lists act differently based on whether it reply-to > coerces and whether the original poster coerces reply-to... This centers on the old debate: Is a list message an entirely new message or is it a continuation/version of the message which was sent to the list? I tend to the latter version. Yes, the Bubba hack extends an abuse which exists for non reply-to munging lists to reply-to munging lists. > ... and you have the issue of which coerced reply-to 'wins'. Given RFC conformant MUAs this isn't a problem -- they all win. Here it appears that Pine might not be conformant. MH and NMH are just fine. JRA is testing out Mutt. I assume someone with access to Outlook will check that (I don't have access). > How is the typical user to understand how this all works together, > and why when they reply to a list, this happens, except when it's > fred's message? The arbitrary user is not affected. He replies exactly as per normal and, as far as his perception is concerned, it Just Works. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Sat Oct 20 00:04:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Oct 2001 19:04:46 -0400 Subject: [Mailman-Developers] Mailman and cookies. References: <8715.1003530627@2wire.com> Message-ID: <15312.45454.192336.391134@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> I'm a little more interested in whether the core happens with JCL> an unpatched Python 2.1.1... No. The patch to Python's cPickle module that fixed this made it into the code base before Python 1.6, so anything after 1.5.2 should be fine. -Barry From barry@zope.com Sat Oct 20 00:24:52 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 19 Oct 2001 19:24:52 -0400 Subject: [Mailman-Developers] Re: Mailman and cookies. References: <15312.40637.81391.220441@anthem.wooz.org> Message-ID: <15312.46660.471275.986209@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Barry, I think you need to take a look at your cookie code, CVR> and look for ways to bullet-proof it. It seems to have some CVR> assumptions that I found out the hard way aren't safe. This patch against Mailman 2.0.6 should be enough to prevent the core dumps. If you haven't completed your upgrade yet, can you give it a try? -Barry -------------------- snip snip -------------------- Index: SecurityManager.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/SecurityManager.py,v retrieving revision 1.31.2.1 diff -u -r1.31.2.1 SecurityManager.py --- SecurityManager.py 2001/07/25 18:07:51 1.31.2.1 +++ SecurityManager.py 2001/10/19 23:23:12 @@ -118,7 +118,7 @@ cookiedata = os.environ.get('HTTP_COOKIE') if not cookiedata: return 0 - c = Cookie.Cookie(cookiedata) + c = Cookie.Cookie(cookiedata, net_setfunc=lambda x: x) if not c.has_key(key): return 0 # Undo the encoding we performed in MakeCookie() above From bob@nleaudio.com Sat Oct 20 01:05:41 2001 From: bob@nleaudio.com (bob@nleaudio.com) Date: Fri, 19 Oct 2001 20:05:41 -0400 (EDT) Subject: [Mailman-Developers] Reply-To: handling Message-ID: <20011020000541.EA76E13D12C@main.nlenet.net> This is a MIME-encapsulated message. --------------484186484748740099568004 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chuq, I totally agree. I had to "solve" a problem on one of my lists that ended up being a fairly prolific poster had his "Reply-to" set to his own address. The list was set so that replies went to the list, but any reply to his messages on the list did not, due to his "reply-to" being set. IMHO, if you want replies to go to the list, they should ALWAYS go to the list. If they go to the user, then Reply-to could be acceptable to pass on, I suppose. Bob >It seems from a consistency's sake, the MLM ought to handle this stuff >unambiguously, which means ONLY mailman's reply-to (or lack of it) ought be >be propogated. > > > > > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers > --------------484186484748740099568004-- From claw@2wire.com Sat Oct 20 01:30:26 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 17:30:26 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from bob@nleaudio.com of "Fri, 19 Oct 2001 20:05:41 EDT." <20011020000541.EA76E13D12C@main.nlenet.net> References: <20011020000541.EA76E13D12C@main.nlenet.net> Message-ID: <8196.1003537826@2wire.com> On Fri, 19 Oct 2001 20:05:41 -0400 (EDT) bob wrote: > Chuq, I totally agree. I had to "solve" a problem on one of my > lists that ended up being a fairly prolific poster had his > "Reply-to" set to his own address. The list was set so that > replies went to the list, but any reply to his messages on the > list did not, due to his "reply-to" being set. This is a standard feature (and many think a particularly good, valuable, and desirable feature) of lists which don't munge reply-to. Under the current Mailman behaviour (reply-to replacement) this behaviour would not happen in a reply-to muinging list as the poster's reply-to would be deleted and replaced by the list's reply-to. In the advocated case or reply-to extension, it also wouldn't happen, as list's address would be added to the reply-to header resulting in replies going to __BOTH__ the address the poster specifies AND the list. > IMHO, if you want replies to go to the list, they should ALWAYS go > to the list. Which they do with reply-to munging lists for both reply to replacement and reply-to extension. This doesn't change. The choice is whether to munge reply-to or not. > If they go to the user, then Reply-to could be acceptable to pass > on, I suppose. And if the list sets reply-to, why not _extend_ that reply to to enclude not only the list's address, but also the address specified by the poster? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Sat Oct 20 04:31:26 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Oct 2001 20:31:26 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <16155.1003532662@2wire.com> Message-ID: On 10/19/01 4:04 PM, "J C Lawrence" wrote: > > By doing reply-to extension we're changing practice as follows: > > -- Posters can _add_ to a posts disposition list via Reply-To. > -- Posters can attempt to move threads to a different forum. Which, IMHO, should be done via a To: or CC:, with a paragraph in the message saying "we should move this to foobar. Please reply only to that list afte rthis". Reply-to can't replace that form, IMHO, but might help to enforce it (or maybe not. To try without explanation is a covert operation, not one I'm overly enthused to encourage, and if they DO do it this way, reply-to coercion is optional at best. > -- Under reply-to extension the original poster who sets reply-to > has the ability to expose an additional address to all subsequent > thread posts. This can be abused, but can also be a Very Good > Thing as it allows, for instance, a non-list-member to track and > aprticipate in a specific thread. Agreed, but I consider this at best a niche feature/sitaution, and don't feel any real need/interest to support it. > Under reply-to replacement > you'd have to be a member of the list to follow the thread (thus > all the requests of, "Please CC me I'm not on the list"). Which, IMHO, is a feature. > This centers on the old debate: Yes, I know. Which is why I figure we won't solve it this time, iether... (tee hee) > Is a list message an entirely new message or is it a > continuation/version of the message which was sent to the list? > > I tend to the latter version. I tend to the middle ground. It's a continuation, but one which the author has ceded distribution control to the list, so the list's settings/preferences override the users. >> How is the typical user to understand how this all works together, >> and why when they reply to a list, this happens, except when it's >> fred's message? > > The arbitrary user is not affected. He replies exactly as per > normal and, as far as his perception is concerned, it Just Works. Does it? What about the case where a list is not coerced reply-to, but one fo the subscribers feels it should be, so he coerces reply-to covertly, which is propogated out and through the list. The list now operates differently for postings by that one user. And the typical user won't know why, or even necessarily recognize it until they reply privately to that message, and due to the covert reply-to, sees their message splashed all over the list. Which, IMHO, I've seen happen, with truly explosive results, a few times. It can be, frankly, even more destructive than the bubba hack, especially if one of your users gets into a nasty fight with someone, and then starts throwing covert reply-tos at the person to embarrass him in public. Or, as has happened in one case, got an engineer into a private discussion, and then threw in a covert reply-to that forced an untimely message back onto a list, which caused an NDA leak, which caused untold embarassment. If you allow users to override list options, all sorts of mischief can happen. And will. From claw@2wire.com Sat Oct 20 04:50:05 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 19 Oct 2001 20:50:05 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from Chuq Von Rospach of "Fri, 19 Oct 2001 20:31:26 PDT." References: Message-ID: <15317.1003549805@2wire.com> On Fri, 19 Oct 2001 20:31:26 -0700 Chuq Von Rospach wrote: > On 10/19/01 4:04 PM, "J C Lawrence" wrote: >> By doing reply-to extension we're changing practice as follows: >> -- Posters can _add_ to a posts disposition list via Reply-To. >> -- Posters can attempt to move threads to a different forum. > Which, IMHO, should be done via a To: or CC:, with a paragraph in > the message saying "we should move this to foobar. Please reply > only to that list after this". Reply-to can't replace that form, > IMHO, but might help to enforce it (or maybe not. To try without > explanation is a covert operation, not one I'm overly enthused to > encourage, and if they DO do it this way, reply-to coercion is > optional at best. I agree, except that as a moderator who regularly moves threads about, having the abilty to coerce, or minimally force initiation of the thread move as a Good and Useful Thing. >> -- Under reply-to extension the original poster who sets reply-to >> has the ability to expose an additional address to all subsequent >> thread posts. This can be abused, but can also be a Very Good >> Thing as it allows, for instance, a non-list-member to track and >> aprticipate in a specific thread. > Agreed, but I consider this at best a niche feature/sitaution, and > don't feel any real need/interest to support it. True, but its a pleasant windfall even if minor. >> This centers on the old debate: > Yes, I know. Which is why I figure we won't solve it this time, > either... (tee hee) >>> How is the typical user to understand how this all works >>> together, and why when they reply to a list, this happens, >>> except when it's fred's message? >> The arbitrary user is not affected. He replies exactly as per >> normal and, as far as his perception is concerned, it Just Works. > Does it? Yup. > What about the case where a list is not coerced reply-to, but one > fo the subscribers feels it should be, so he coerces reply-to > covertly, which is propogated out and through the list. Which is actually orthogonal to the case under discussion and is thus a red herring. You're asking: What should happen, MLM wise, to a post to a non reply-to munging list when a poster sets Reply-To to something else. That's very different to what is under discussion; How should reply-to munging should be done for lists which coerce reply-to, if a poster sets Reply-To on a posts. > The list now operates differently for postings by that one > user. And the typical user won't know why, or even necessarily > recognize it until they reply privately to that message, and due > to the covert reply-to, sees their message splashed all over the > list. Right. That only affects lists which don't munge reply-to. It explicitly doesn't affect lists which do munge reply-to. What you seem to be asking for is reply-to stripping for lists that don't munge reply-to. I can see the reasoning, but also see considerable danger/pain in that direction. > Which, IMHO, I've seen happen, with truly explosive results, a few > times. It can be, frankly, even more destructive than the bubba > hack, especially if one of your users gets into a nasty fight with > someone, and then starts throwing covert reply-tos at the person > to embarrass him in public. Or, as has happened in one case, got > an engineer into a private discussion, and then threw in a covert > reply-to that forced an untimely message back onto a list, which > caused an NDA leak, which caused untold embarassment. Right. A problem of posters to non-reply-to munging lists having full control over post disposition, and thus the ability to massively change post disposition for their posts outside the norm. BUT, for lists which reply to munge, adding reply to exension allows posters to extend post distribution outside of the list, but does not allow them (directly) to change the base assumed pattern of post disposition for a list post. > If you allow users to override list options, all sorts of mischief > can happen. And will. Right. Please note that that is not being discussed or proposed. What is being proposed is the ability for users to EXTEND list options as regards post disposition, but ONLY for lists which munge reply to. What to do about disposition overrides for lists that don't munge reply to is ratehr another matter, and one I don't know has an easy answer. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Sat Oct 20 05:30:30 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Oct 2001 21:30:30 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <15317.1003549805@2wire.com> Message-ID: On 10/19/01 8:50 PM, "J C Lawrence" wrote: > I agree, except that as a moderator who regularly moves threads > about, having the abilty to coerce, or minimally force initiation of > the thread move as a Good and Useful Thing. Fair 'nuff. Stylistic differences, neither is right or wrong. I do it differently. >> Agreed, but I consider this at best a niche feature/sitaution, and >> don't feel any real need/interest to support it. > > True, but its a pleasant windfall even if minor. Unless implementing it causes other problems elsewhere. >> Does it? > > Yup. But I don't agree.... >> What about the case where a list is not coerced reply-to, but one >> fo the subscribers feels it should be, so he coerces reply-to >> covertly, which is propogated out and through the list. > > Which is actually orthogonal to the case under discussion and is > thus a red herring. I'm not sure I agree, but I won't push the issue. I think the MLM should be consistent to the end-user, which means it does the same thing based on its configuration, no matter what the original poster sets in their headers. That means headers like reply-to much be stripped before processing, not carried through, or you hae inconsistent variations of those headers. > What you seem to be asking for is reply-to stripping for lists that > don't munge reply-to. I can see the reasoning, but also see > considerable danger/pain in that direction. Exactly. And I don't see danger/pain, I see consistency of operations. Wich, I guess, makes me the hobgoblin of small mindedness..... From jra@baylink.com Sat Oct 20 05:56:57 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 20 Oct 2001 00:56:57 -0400 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <5553.1003527460@2wire.com>; from J C Lawrence on Fri, Oct 19, 2001 at 02:37:40PM -0700 References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> Message-ID: <20011020005657.62734@scfn.thpl.lib.fl.us> On Fri, Oct 19, 2001 at 02:37:40PM -0700, J C Lawrence wrote: > > VM/XEmacs does the right thing too, with both Reply-To: that > > contains multiple addresses, and multiple Reply-To: headers in the > > original message. > > If I'm reading it correctly, multiple Reply-To headers violates RFC > 2822. The fact that VM supports it is fine, but that doesn't mean > Mailman should emit it. If multiple headers are not supported, then I submit that we should assume that a multi address Reply-to may well be a bug in the spec; other address headers may appear multiple times, may they not? I'd go read 2822, but I'm too damned tired. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From claw@kanga.nu Sat Oct 20 06:11:49 2001 From: claw@kanga.nu (J C Lawrence) Date: Fri, 19 Oct 2001 22:11:49 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from Chuq Von Rospach of "Fri, 19 Oct 2001 21:30:30 PDT." References: Message-ID: <32286.1003554709@kanga.nu> On Fri, 19 Oct 2001 21:30:30 -0700 Chuq Von Rospach wrote: > On 10/19/01 8:50 PM, "J C Lawrence" wrote: >> I agree, except that as a moderator who regularly moves threads >> about, having the abilty to coerce, or minimally force initiation >> of the thread move as a Good and Useful Thing. > Fair 'nuff. Stylistic differences, neither is right or wrong. I do > it differently. >>> What about the case where a list is not coerced reply-to, but >>> one fo the subscribers feels it should be, so he coerces >>> reply-to covertly, which is propogated out and through the list. >> Which is actually orthogonal to the case under discussion and is >> thus a red herring. > I'm not sure I agree, but I won't push the issue. I think the MLM > should be consistent to the end-user, which means it does the same > thing based on its configuration, no matter what the original > poster sets in their headers. That means headers like reply-to > much be stripped before processing, not carried through, or you > hae inconsistent variations of those headers. Two cases: 1) Reply-To munging off: -- Users can fully control post disposition, which may not involve the list at all, or may be the list (thus preventing simple private replies). They can control whether simple replies go to the list, don't go to the list, go only to the list, etc. 2) Reply-To munging on: -- With Reply-To removal: All replies go back to the list ONLY. There is no way for simple replies to go anywhere else. -- With Reply-To extension: All posts go back to the list and may ALSO go an address the previous poster specified. In both cases simple replies are guaranteed to go the list. I'm of the general mind that the two cases (munging on and off) need separate handling. >> What you seem to be asking for is reply-to stripping for lists >> that don't munge reply-to. I can see the reasoning, but also see >> considerable danger/pain in that direction. > Exactly. And I don't see danger/pain, I see consistency of > operations. The pain bits are the standard/good uses of Reply-To as a dupe prevention technique, use as an address re-writing, use for thread redirection, etc. Depending on your lists and their demographics, these are variously useful/useless. However, conflating the problems on non-reply-to munging lists and the problems of reply-to munging lists seems a mistake. They are distinct problems with different problems related to feature/header overloading. I see value in two options for NON-reply-to munging lists: 1) Strip all poster-set Reply-To headers. 2) Strip all poster-set Reply-To headers which point at the list. I don't think I'd use them, but then my lists have very different public to your lists Chuq. > Which, I guess, makes me the hobgoblin of small mindedness..... Hardly. You're arguing for simplicity and transparency of interface for the end-user, and we all well know, end-users are hob goblins. I'm hardly going to argue with that. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Sat Oct 20 06:15:51 2001 From: claw@kanga.nu (J C Lawrence) Date: Fri, 19 Oct 2001 22:15:51 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from "Jay R. Ashworth" of "Sat, 20 Oct 2001 00:56:57 EDT." <20011020005657.62734@scfn.thpl.lib.fl.us> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> Message-ID: <32314.1003554951@kanga.nu> On Sat, 20 Oct 2001 00:56:57 -0400 Jay R Ashworth wrote: > If multiple headers are not supported, then I submit that we > should assume that a multi address Reply-to may well be a bug in > the spec Nahh. Its quite clear, and further, it also makes sense. > other address headers may appear multiple times, may they not? ---- The following table indicates limits on the number of times each field may occur in a message header as well as any special limitations on the use of those fields. An asterisk next to a value in the minimum or maximum column indicates that a special restriction appears in the Notes column. Field Min number Max number Notes trace 0 unlimited Block prepended - see 3.6.7 resent-date 0* unlimited* One per block, required if other resent fields present - see 3.6.6 resent-from 0 unlimited* One per block - see 3.6.6 resent-sender 0* unlimited* One per block, MUST occur with multi-address resent-from - see 3.6.6 resent-to 0 unlimited* One per block - see 3.6.6 resent-cc 0 unlimited* One per block - see 3.6.6 resent-bcc 0 unlimited* One per block - see 3.6.6 resent-msg-id 0 unlimited* One per block - see 3.6.6 orig-date 1 1 from 1 1 See sender and 3.6.2 sender 0* 1 MUST occur with multi- address from - see 3.6.2 reply-to 0 1 to 0 1 cc 0 1 bcc 0 1 message-id 0* 1 SHOULD be present - see 3.6.4 in-reply-to 0* 1 SHOULD occur in some replies - see 3.6.4 references 0* 1 SHOULD occur in some replies - see 3.6.4 subject 0 1 comments 0 unlimited keywords 0 unlimited optional-field 0 unlimited The exact interpretation of each field is described in subsequent sections. ---- > I'd go read 2822, but I'm too damned tired. See above. BTW: Have you checked Mutt's behaviour yet? Could/would someone check Outlook's behaviour? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Sat Oct 20 06:44:56 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 20 Oct 2001 01:44:56 -0400 Subject: [Mailman-Developers] Reply-To: handling References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> Message-ID: <15313.3928.983053.545246@anthem.wooz.org> It seems to me that there are good arguments for a number of different Reply-To: policies, and that list administrators are going to have to make their own choice based on their membership and the way they want their lists to behave. I guess I'm advocating a typical politician's exit here (some might call it wimping out ;). There are 6 choices: - Hands off: Mailman doesn't touch Reply-To:. If it exists in the original message, it's passed through, though none is added by the software. - Strip: Mailman strips all Reply-To: headers and adds none of its own. - Override to list: Mailman strips any existing Reply-To: and inserts a Reply-To: the list address. - Override to explicit: Mailman strips any existing Reply-To: and inserts a Reply-To: to an address explicitly given by the list admin. - Extend to list: Mailman folds multiple and removes dup Reply-To:'s inserting a single header containing a list of any original Reply-To: addresses, plus one back to the list. - Extend to explicit: Mailman folds multiples and removes dup Reply-To: inserting a single header containing a list of any original Reply-To: addresses, plus one explicitly given by the list admin. Seems complicated, but perhaps this table leads us to the choice of the right knobs: strip add list addr add explicit addr ------------+---------+-----------------+-------------------- hands off | N | N | N +---------+-----------------+-------------------- strip any | Y | N | N existing | | | +---------+-----------------+-------------------- override | Y | Y | N to list | | | +---------+-----------------+-------------------- override | Y | N | Y to explicit | | | +---------+-----------------+-------------------- extend | N | Y | N to list | | | +---------+-----------------+-------------------- extend | N | N | Y to explicit | | | So, we have a binary control that asks "First strip all Reply-To: fields in the original message? No, Yes" A radio button that asks "Then add an a Reply-To: for? Don't Add, This List, Explicit Address (see below)" And finally a text field for the explicit address. We're nearly there as it is (change "Poster" to "Don't Add" since the former makes little sense anyway). We just need to add an option to strip any existing Reply-To: field first. The defaults ought to be "Don't Strip", "Don't Add". What would also be useful, though is a set of guidelines that lay out the issues and help a list admin decide which settings are most appropriate for their list. Is anybody willing to contribute a short, concise write up, say for a List Owner's Manual? -Barry From claw@kanga.nu Sat Oct 20 06:55:18 2001 From: claw@kanga.nu (J C Lawrence) Date: Fri, 19 Oct 2001 22:55:18 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Sat, 20 Oct 2001 01:44:56 EDT." <15313.3928.983053.545246@anthem.wooz.org> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> <15313.3928.983053.545246@anthem.wooz.org> Message-ID: <32735.1003557318@kanga.nu> On Sat, 20 Oct 2001 01:44:56 -0400 Barry A Warsaw wrote: > There are 6 choices: Yup. > What would also be useful, though is a set of guidelines that lay > out the issues and help a list admin decide which settings are > most appropriate for their list. Is anybody willing to contribute > a short, concise write up, say for a List Owner's Manual? I suspect the bullet lists I've been posting recently could/would do it if touched up a bit. Sure, I'll do it. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Sat Oct 20 07:15:28 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Oct 2001 23:15:28 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <15313.3928.983053.545246@anthem.wooz.org> Message-ID: On 10/19/01 10:44 PM, "Barry A. Warsaw" wrote: > their lists to behave. I guess I'm advocating a typical politician's > exit here (some might call it wimping out ;). If the RFCs allow for flexibility, I'm all for it. From Trasnochador@go.com Sat Oct 20 16:40:47 2001 From: Trasnochador@go.com (andres gomez) Date: Sat, 20 Oct 2001 08:40:47 -0700 (PDT) Subject: [Mailman-Developers] unsuscribe webmaster@pymagen.com Message-ID: <1590779.1003592447318.JavaMail.Trasnochador@gomailjtp02> please don=B4t send more messages. Thanks ___________________________________________________ GO.com Mail =20 Get Your Free, Private E-mail at http://mail.go.com From barry@zope.com Sat Oct 20 20:06:44 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 20 Oct 2001 15:06:44 -0400 Subject: [Mailman-Developers] Reply-To: handling References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> <15313.3928.983053.545246@anthem.wooz.org> <32735.1003557318@kanga.nu> Message-ID: <15313.52036.126483.868932@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> I suspect the bullet lists I've been posting recently JCL> could/would do it if touched up a bit. Sure, I'll do it. Great! They should be augmented with the exact variable names and settings to accomplish the goal. Most likely: first_strip_reply_to (new variable - boolean) reply_goes_to_list (existing - multivalue) reply_to_address (existing - string) Thanks, -Barry From barry@zope.com Sat Oct 20 21:26:09 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 20 Oct 2001 16:26:09 -0400 Subject: [Mailman-Developers] Bug in mail->news gateway in 2.0.5 (and *simple* fix) References: <15072001.3@wanderer.local.jae.ddns.org> Message-ID: <15313.56801.991503.552916@anthem.wooz.org> Many months ago... >>>>> "jae" =3D=3D J=FCrgen A Erhard writes: jae> Bug: in Mailman/Handlers/ToUsenet.py, there are spaces jae> inserted after colons where they are missing ("NNTP is strict jae> about spaces after the colon in headers"). jae> If a colon appears in a continuation line, it is treated as a jae> header colon. jae> Fix: skip lines that start with whitespace. This fix should now be on-line. From barry@zope.com Sat Oct 20 21:30:32 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 20 Oct 2001 16:30:32 -0400 Subject: [Mailman-Developers] Bug in mail->news gateway in 2.0.5 (and *simple* fix) References: <15072001.3@wanderer.local.jae.ddns.org> <15313.56801.991503.552916@anthem.wooz.org> Message-ID: <15313.57064.394137.198716@anthem.wooz.org> >>>>> "BAW" =3D=3D Barry A Warsaw writes: BAW> Many months ago... >>>>> "jae" =3D=3D J=FCrgen A Erhard writes: jae> Bug: in Mailman/Handlers/ToUsenet.py, there are spaces jae> inserted after colons where they are missing ("NNTP is strict jae> about spaces after the colon in headers"). jae> If a colon appears in a continuation line, it is treated as a jae> header colon. jae> Fix: skip lines that start with whitespace. BAW> This fix should now be on-line. I should add that MM2.1 won't be affected because it uses the email.Message.Message class which already Does The Right Thing. -Barry From jwblist@olympus.net Sat Oct 20 21:47:54 2001 From: jwblist@olympus.net (John W Baxter) Date: Sat, 20 Oct 2001 13:47:54 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <20011020005657.62734@scfn.thpl.lib.fl.us> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> Message-ID: At 0:56 -0400 10/20/2001, Jay R. Ashworth wrote: >If multiple headers are not supported, then I submit that we should >assume that a multi address Reply-to may well be a bug in the spec; >other address headers may appear multiple times, may they not? No more a bug than the legal multi-address From: header. This was for something like a secretary sending a message "from" her boss and herself, IIRC. > >I'd go read 2822, but I'm too damned tired. At least I think it's still legal (tossed in just in case 2822 changed things). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwblist@olympus.net Sat Oct 20 22:11:33 2001 From: jwblist@olympus.net (John W Baxter) Date: Sat, 20 Oct 2001 14:11:33 -0700 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: <32314.1003554951@kanga.nu> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> Message-ID: At 22:15 -0700 10/19/2001, J C Lawrence wrote: >BTW: Have you checked Mutt's behaviour yet? Could/would someone >check Outlook's behaviour? Eudora 5.1 beta for Mac OS X (wherein I am at the moment) honors multiple address Reply-To: headers. It's highly likely that Eudora has done so from the beginning (Steve believes in standards even though he hasn't been allowed to add the list header handling yet: odd in that Qualcomm was involved in developing the list header RFC). It's likely that the little Windows offshoot from Eudora (called Eudora) also does it right, although it's a largely different team doing the work. I can test if no one else here can easily. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From dgc@uchicago.edu Sat Oct 20 23:59:37 2001 From: dgc@uchicago.edu (David Champion) Date: Sat, 20 Oct 2001 17:59:37 -0500 Subject: [Mailman-Developers] Re: Reply-To: handling In-Reply-To: <32314.1003554951@kanga.nu> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> Message-ID: <20011020175937.Y9588@dust.uchicago.edu> On 2001.10.20, in <32314.1003554951@kanga.nu>, "J C Lawrence" wrote: > > BTW: Have you checked Mutt's behaviour yet? Could/would someone > check Outlook's behaviour? Jay's using a truly old version of mutt, so I'm going to jump in here. Mutt 1.3.23, the current development version (and 1.4 beta) creates replies only to the *first* address in a multi-reply-to message. It does permit sending such messages, though, so internally it minimally supports the multi-address syntax. (The reply-to element of the header structure indeed is of the same multi-address form as other address headers, so fixing this would be just a change to the code that generates draft forms for replies.) -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Sun Oct 21 00:20:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 20 Oct 2001 19:20:15 -0400 Subject: [Mailman-Developers] Reply-To: handling In-Reply-To: ; from John W Baxter on Sat, Oct 20, 2001 at 01:47:54PM -0700 References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> Message-ID: <20011020192015.54020@scfn.thpl.lib.fl.us> On Sat, Oct 20, 2001 at 01:47:54PM -0700, John W Baxter wrote: > At 0:56 -0400 10/20/2001, Jay R. Ashworth wrote: > >If multiple headers are not supported, then I submit that we should > >assume that a multi address Reply-to may well be a bug in the spec; > >other address headers may appear multiple times, may they not? > > No more a bug than the legal multi-address From: header. > This was for something like a secretary sending a message "from" her boss > and herself, IIRC. I had been talking about mulitple headers; it appears *no* (address) header may appear more than once. As it happens, Mutt appears not to deal well at all with it: .88e (which is what I can get mail to) just doesn't reply to anyone. I have 1.2.5 on my laptop, but I can't conveniently get mail to it to test. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From jra@baylink.com Sun Oct 21 00:23:07 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 20 Oct 2001 19:23:07 -0400 Subject: [Mailman-Developers] Re: Reply-To: handling In-Reply-To: <20011020175937.Y9588@dust.uchicago.edu>; from David Champion on Sat, Oct 20, 2001 at 05:59:37PM -0500 References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> <20011020175937.Y9588@dust.uchicago.edu> Message-ID: <20011020192307.62409@scfn.thpl.lib.fl.us> On Sat, Oct 20, 2001 at 05:59:37PM -0500, David Champion wrote: > Jay's using a truly old version of mutt, so I'm going to jump in here. Thanks, David. > Mutt 1.3.23, the current development version (and 1.4 beta) creates > replies only to the *first* address in a multi-reply-to message. It > does permit sending such messages, though, so internally it minimally > supports the multi-address syntax. (The reply-to element of the header > structure indeed is of the same multi-address form as other address > headers, so fixing this would be just a change to the code that > generates draft forms for replies.) I concur, and I also believe that the change should be made. It's been long enough since I was on the devel list that Matt was still running things (obviously); do you think the new maintainer would be receptive...? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From NiLR3M@yahoo.com Sun Oct 21 00:44:59 2001 From: NiLR3M@yahoo.com (Steve) Date: Sat, 20 Oct 2001 16:44:59 -0700 Subject: [Mailman-Developers] Feature request Message-ID: <007101c159c1$c4b3c340$0ac8c80a@System> Hello all, Great job you guys!! Ever since I test use it, I love it, and been using it ever since. I was just wondering if you guru can add one more action button to the menu of "Posting Held for Approval"? This selection button is called "Ban/Spammers" The reason of doing is because I've been setting up my postmaster email to go through mailman. It traps most of the email in there for me to decide whether to defer, approve, reject, or discard it later whenever I have time to skim through the subject line. I don't want to choose reject because they (evil spammers) will know someone actually read it which server their purpose of spamming already. So most of the time, I choose discard but that does not stop mailman from recieving more mail from the same user@host address. So I thought it would be nice if mailman has a "ban" button where it add the user@host to the ban list so that next time when it recieves it again, it just automatically delete it for me. Perhaps the implementation of this should keep the ban list in a file??? so that in the far future, someone will write an interface for sendmail to read off it as part of its secondary blacklist besides the international one. Once every month, I will manually review this file to see which @host appears the most so that I can then manually decide whether or not to completely add it to the deny list in sendmail. What do you guys think about this? Thanx. Steve From claw@kanga.nu Sun Oct 21 00:57:10 2001 From: claw@kanga.nu (J C Lawrence) Date: Sat, 20 Oct 2001 16:57:10 -0700 Subject: [Mailman-Developers] Re: Reply-To: handling In-Reply-To: Message from David Champion of "Sat, 20 Oct 2001 17:59:37 CDT." <20011020175937.Y9588@dust.uchicago.edu> References: <23646.1003520045@2wire.com> <15312.38897.589704.813053@anthem.wooz.org> <5553.1003527460@2wire.com> <20011020005657.62734@scfn.thpl.lib.fl.us> <32314.1003554951@kanga.nu> <20011020175937.Y9588@dust.uchicago.edu> Message-ID: <11023.1003622230@kanga.nu> On Sat, 20 Oct 2001 17:59:37 -0500 David Champion wrote: > Mutt 1.3.23, the current development version (and 1.4 beta) > creates replies only to the *first* address in a multi-reply-to > message. It does permit sending such messages, though, so > internally it minimally supports the multi-address syntax. (The > reply-to element of the header structure indeed is of the same > multi-address form as other address headers, so fixing this would > be just a change to the code that generates draft forms for > replies.) Thanks for the check. Want to submit the bug report to the Mutt guys? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From bob@nleaudio.com Sun Oct 21 20:50:02 2001 From: bob@nleaudio.com (bob@nleaudio.com) Date: Sun, 21 Oct 2001 15:50:02 -0400 (EDT) Subject: [Mailman-Developers] Adding name prefix to "From:" Message-ID: <20011021195002.C741213D126@main.nlenet.net> This is a MIME-encapsulated message. --------------216143221641455123677944 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A quick question... In converting another list over from Lyris, I noticed that Lyris has a way of setting the name of the list so that it appears in the From: address for each message that comes from the list. Example: From: "Mailman Developer's List" Is there a way to do this now in 2.06? 2.1x? Or would it just need a quick hack of CookHeaders.py? Bob --------------216143221641455123677944-- From barry@zope.com Sun Oct 21 20:25:21 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 21 Oct 2001 15:25:21 -0400 Subject: [Mailman-Developers] CPU usage again References: <1003271201.18090.127.camel@claudia> <878zebgkqu.fsf@nausicaa.interq.or.jp> Message-ID: <15315.8481.723648.667918@geddy.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> How big are your .mbox files in the mailman/archives/private/* BG> directories? I had the exact same problem until I turned off BG> internal archiving; once my .mbox files got too big, the BG> ArchRunner took up 100% of the CPU and took hours to run. BG> Try turning on external archiving and switching to Hypermail. BG> It's a better archiver anyway. I can't dispute that there are better archivers than Pipermail, but I'd still like to know why Pipermail/ArchRunner takes up so much cpu, and that only occasionally. Did you see my timing tests on a list with a 280MB .mbox file? It wasn't nearly that bad. -Barry From barry@zope.com Sun Oct 21 20:23:01 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 21 Oct 2001 15:23:01 -0400 Subject: [Mailman-Developers] CPU Usage References: <20010925151125.77e01be4.rodolfo@linux.org.uy> <15297.8321.928062.891519@geddy.wooz.org> <1002654001.2235.16.camel@claudia> <3BC3550C.2F2D1737@utopia.west.sun.com> <1002921483.17676.66.camel@claudia> Message-ID: <15315.8341.172751.781181@geddy.wooz.org> FWIW, alpha3 will have a much better mailmanctl script, so a `ps' should at least tell you which of the qrunners is sucking up all your cpu. (There are lost of other improvements to mailmanctl too, like "restart" actually works now. ;) -Barry From barry@zope.com Sun Oct 21 19:31:32 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 21 Oct 2001 14:31:32 -0400 Subject: [Mailman-Developers] Feature request References: <007101c159c1$c4b3c340$0ac8c80a@System> Message-ID: <15315.5252.680874.622100@geddy.wooz.org> >>>>> "S" == Steve writes: S> Great job you guys!! Ever since I test use it, I love it, and S> been using it ever since. Great! S> I was just wondering if you guru can add one more action button S> to the menu of "Posting Held for Approval"? I have plans after 2.1alpha3 to hook up the admindb pages to the new sender-centric moderation variables. The idea is that you could sort the held messages by sender, and then on the sender-held page do a mass discard as well as add the user (via a "Ban" button) to automatically add that address to the auto-discard list. S> Perhaps the implementation of this should keep the ban S> list in a file??? so that in the far future, someone will write S> an interface for sendmail to read off it as part of its S> secondary blacklist besides the international one. Once every S> month, I will manually review this file to see which @host S> appears the most so that I can then manually decide whether or S> not to completely add it to the deny list in sendmail. What do S> you guys think about this? Thanx. It's an interesting idea, but I doubt I'll implement this. It wouldn't be hard to do though, if someone wants to work out and contribute such code. -Barry From barry@zope.com Mon Oct 22 07:17:35 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 02:17:35 -0400 Subject: [Mailman-Developers] [RELEASED] Mailman 2.1 alpha 3 Message-ID: <15315.47615.891332.994452@anthem.wooz.org> I've finally decided to put a fork in it and release the third, and hopefully last alpha in the Mailman 2.1 series. If you want to see a description of all the new stuff, please see http://sourceforge.net/project/shownotes.php?release_id=58074 There's quite a lot there! Everything should be up on SourceForge now, with updates to www.list.org hopefully tomorrow some time. See also http://mailman.sf.net/MM21/ for updated pages about Mailman 2.1. Note that you no longer need to install the mimelib package. This has been replaced by the email package, which comes with Python 2.2b1, or for Python 2.1.1 or 2.0.1, you'll need to install email-0.93 which is available in the misc/ directory. See the INSTALL file for details. Below is an excerpt from the NEWS file for all the changes since 2.1 alpha 2. I'm hoping that this will be the last alpha release. That means there's one more release in which we have an opportunity for new features, so I suggest that you grab 2.1a3 and give it a good workout (in a non-production environment ). If there are glaring things missing, as always, let me know. Please, all discussion about 2.1 alpha should be conducted on the mailman-developers@python.org mailing list. I will be creating some test lists on python.org an you'll be able to subscribe to them to try things out. I'd like to have a short cycle for alpha3->beta1, with bug fixes only once beta1 comes out. Language translators: I've updated the langpack on SourceForge with the latest catalogs and templates. I've also uploaded the latest README-I18N.en file if you'd like to contribute new languages. If you've been holding off contributing new language files, please consider finishing them off so that I can integrate them in time for beta1. Enjoy, -Barry -------------------- snip snip -------------------- 2.1 alpha 3 (22-Oct-2001) - Realname support o Mailman now tracks a member's Real Name in addition to their email address. o List members can now supply their Real Names when subscribing via the web. Their Real Names are parsed from any thru-email subscriptions. o Members can change their Real Names on their options page, and admins can change members' Real Names on the membership pages. Mass subscribing accepts "email@dom.ain (Real Name)" entries, for both in-text-box and file-upload mass subscriptions. - Filtering and Privacy o Reply-To: munging has been enhanced to allow a wider range of list policies. You can now pre-strip any Reply-To: headers before adding list-specific ones (i.e. you can override or extend existing Reply-To: headers). If stripping, the old headers are no longer saved on X-Reply-To: o New sender moderation rules. The old `posters', `member_only_posting', `moderated' and `forbidden_posters' options have been removed in favor of a new moderation scheme. Each member has a personal moderation bit, and non-member postings can be automatically accepted, held for approval, rejected (bounced) or discarded. o When membership rosters are private, responses to subscription (and other) requests are made more generic so that these processes can't be covertly mined for hidden addresses. If a subscription request comes in for a user who is already subscribed, the user is notified of potential membership mining. o When a held message is approved via the admindb page, an X-Moderated: header is added to the message. o List admins can now set an unsubscribe policy which requires them to approve of member unsubscriptions. - Web U/I o All web confirmations now require a two-click procedure, where the first click gives them a page that allows them to confirm or cancel their subscription. It is bad form for an email click (HTTP GET) to have side effects. o Lots of improvements for clarity. o The Privacy category has grown three subcategories. o The General options page as a number of subsection headers. o The Passwords and Languages categories are now on separate admin pages. o The admin subcategories are now formated as two columns in the top and bottom legends. o When creating a list through the web, you can now specify the initial list of supported languages. o The U/I for unsubscribing a member on the admin's membership page should be more intuitive now. o There is now a separate configuration option for whether the goodbye_msg is sent when a member is unsubscribed. - Performance o misc/mailman is a Unix init script, appropriate for /etc/init.d, and containing chkconfig hooks for systems that support it. o bin/mailmanctl has been rewritten; the `restart' command actually works now. It now also accepts -s, -q, and -u options. o bin/qrunner has been rewritten too; it can serve the role of the old cron/qrunner script for those who want classic cron-invoked mail delivery. o Internally, messages are now stored in the qfiles directory primarily as pickles. List configuration databases are now stored as pickles too (i.e. config.pck). bin/dumpdb knows how to display both pickles and marshals. - Mail delivery o If a user's message is held for approval, they are sent a notification message containing a confirmation cookie. They can use this confirmation cookie to cancel their own postings (if they haven't already been approved). o When held messages are forwarded to an explicit address using the admindb page, it is done so in a message/rfc822 encapsulation. o When a message is first held for approval, the notification sent to the list admin is a 3-part multipart/mixed. The first part holds the notification message, the second part hold the original message, and the third part hold a cookie confirmation message, to which the admin can respond to approve or discard the message via email. o In the mail->news gateway, you can define mail headers that must be modified or deleted before the message can be posted to the nntp server. o The list admin can send an immediate urgent message to the entire list membership, bypassing digest delivery. This is done by adding an Urgent: header with the list password. Urgent messages with an invalid password are rejected. o Lists can now optionally personalize email messages, if the site admin allows it. Personalized messages mean that the To: header includes the recipient's address instead of the list's address, and header and footer messages can contain user-specific information. Note that only regular deliveries can currently be personalized. o Message that come from Usenet but that have broken MIME boundaries are ignored. o If the site administrator agrees, list owners have the ability to disable RFC 2369 List-* headers. - Building/testing/configuration o mimelib is no longer required, but you must install the email package (see the tarball in the misc directory). o An (as yet) incomplete test suite has been added. Don't try running it in a production environment! o Better virtual host support by adding a mapping from the host name given in cgi's HTTP_HOST/SERVER_NAME variable to the email host used in list addresses. (E.g. www.python.org maps to @python.org). o Specifying urls to external public archivers is more flexible. o The filters/ subdirectory has been removed. o There is now a `site list' which is a mailing list that must be created first, and from which all password reminders appear to come from. It is recommended that this list be called "mailman@your.site". o bin/move_list is no longer necessary (see the FAQ for detailed instructions on renaming a list). o A new script bin/fix_url.py can be used with bin/withlist to change a list's web_page_url configuration variable (since it is no longer modifiable through the web). - Internationalization o Support for German, Hungarian, Italian, Japanese, and Norwegian have been added. - Miscellaneous o Lots of new bounce detectors. Bounce detectors can now discard temporary bounce messages by returning a special Stop value. o bin/withlist now sports a -q/--quiet flag. o bin/add_members has a new -a/--admin-notify flag which can be used to inhibit list owner notification for each subscription. - Membership Adaptors o Internally, mailing list memberships are accessed through a MemberAdaptor interface. This would allow for integrating membership databases with external sources (e.g. Zope or LDAP), although the only MemberAdaptor currently implemented is a "classic" adaptor which stores the membership information on the MailList object. o There's a new pipeline handler module called FileRecips.py which could be used to get all regular delivery mailing list recipients from a Sendmail-style :include: file (see List Extensibility bullet below). This work was sponsored by Control.com - List Extensibility o A framework has been added which can be used to specialize and extend specific mailing lists. If there is a file called lists//extend.py, it is execfile()'d after the MailList object is instantiated. The file should contain a function extend() which will be called with the MailList instance. This function can do all sorts of deep things, like modify the handler pipeline just for this list, or even strip out particular admin GUI elements (see below). o All the admin page GUI elements are now separate components. This provides greater flexibility for list customization. Also, each GUI element will be given an opportunity to handle admin CGI form data. This work was sponsored by Control.com - Topic Filters o A new feature has been added called "Topic Filters". A list administrator can create topics, which are essentially regular expression matches against Subject: and Keyword: headers (including such pseudo-headers if they appear in the first few lines of the body of a message). List members can then `subscribe' to various topics, which allows them to filter out any messages that don't match a topic, or to filter out any message that does match a topic. This can be useful for high volume lists where not everyone will be interested in every message. This work was sponsored by Control.com From chuqui@plaidworks.com Mon Oct 22 07:37:02 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 21 Oct 2001 23:37:02 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: <15315.47615.891332.994452@anthem.wooz.org> Message-ID: On 10/21/01 11:17 PM, "Barry A. Warsaw" wrote: > http://sourceforge.net/project/shownotes.php?release_id=58074 (clap clap clap clap) > and admins can change members' Real Names on the membership > pages. Mass subscribing accepts "email@dom.ain (Real Name)" You should also accept Real Name Since that's the other common (perhaps more common) format. > o The list admin can send an immediate urgent message to the > entire list membership, bypassing digest delivery. This is > done by adding an Urgent: header with the list password. > Urgent messages with an invalid password are rejected. Is the Urgent: header stripped as it passes through Mailman? What happens when a regular user tries to put an Urgent: header on a message as a non-admin? > o There is now a `site list' which is a mailing list that must > be created first, and from which all password reminders > appear to come from. It is recommended that this list be > called "mailman@your.site". Is there a plan to set up a bounce returned to mailman@your.site to be considered a global bounce and that user is unsubbed from all lists? Right now, mailman effectively throws away bounces from the password reminders, which can be used very effectively to keep stuff clean. > - Membership Adaptors > o Internally, mailing list memberships are accessed through a > MemberAdaptor interface. This would allow for integrating > membership databases with external sources (e.g. Zope or > LDAP), Given that, if someone wants to write a fully external authenticator, is it possible to completely disable mailman's interface for a given list (or all lists?) Including things like monthly password reminders? I guess what I'm suggesting is Mailman as a slave to a non-attached membership system -- can we really detach it cleanly so it's just a delivery system without rough edges or hacking? Down to the external membership system in headers and footers? > This work was sponsored by Control.com (clap clap clap clap) From claw@kanga.nu Mon Oct 22 08:10:19 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 22 Oct 2001 00:10:19 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message from Chuq Von Rospach of "Sun, 21 Oct 2001 23:37:02 PDT." References: Message-ID: <23817.1003734619@kanga.nu> On Sun, 21 Oct 2001 23:37:02 -0700 Chuq Von Rospach wrote: > On 10/21/01 11:17 PM, "Barry A. Warsaw" wrote: >> http://sourceforge.net/project/shownotes.php?release_id=58074 > (clap clap clap clap) >> and admins can change members' Real Names on the membership >> pages. Mass subscribing accepts "email@dom.ain (Real Name)" > You should also accept > Real Name > Since that's the other common (perhaps more common) format. IIRC the language in 2822, the (form) is mildly deprecated. > Is there a plan to set up a bounce returned to mailman@your.site > to be considered a global bounce and that user is unsubbed from > all lists? Right now, mailman effectively throws away bounces from > the password reminders, which can be used very effectively to keep > stuff clean. Password reminders are (arguably) the ideal VERP opportunity. >> This work was sponsored by Control.com > (clap clap clap clap) Absolutely. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Mon Oct 22 17:39:31 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 12:39:31 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 References: <15315.47615.891332.994452@anthem.wooz.org> Message-ID: <15316.19395.73796.708333@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> http://sourceforge.net/project/shownotes.php?release_id=58074 CVR> (clap clap clap clap) Thanks! >> and admins can change members' Real Names on the membership >> pages. Mass subscribing accepts "email@dom.ain (Real Name)" CVR> You should also accept CVR> Real Name Yup, sorry, it already does. I've updated the NEWS file (for the next release at least). >> o The list admin can send an immediate urgent message to the >> entire list membership, bypassing digest delivery. This is >> done by adding an Urgent: header with the list password. >> Urgent messages with an invalid password are rejected. CVR> Is the Urgent: header stripped as it passes through Mailman? CVR> What happens when a regular user tries to put an Urgent: CVR> header on a message as a non-admin? Just like an Approved: header, it's always stripped because it contains a password. Regardless of who sends it, if the Urgent: header's value doesn't match the list admin or list moderator's password, the message is bounced back to the sender. >> o There is now a `site list' which is a mailing list that must >> be created first, and from which all password reminders appear >> to come from. It is recommended that this list be called >> "mailman@your.site". CVR> Is there a plan to set up a bounce returned to CVR> mailman@your.site to be considered a global bounce and that CVR> user is unsubbed from all lists? Right now, mailman CVR> effectively throws away bounces from the password reminders, CVR> which can be used very effectively to keep stuff clean. Yes, there are plans ;). Whether I actually get to it or not we'll see. >> - Membership Adaptors o Internally, mailing list memberships >> are accessed through a MemberAdaptor interface. This would >> allow for integrating membership databases with external >> sources (e.g. Zope or LDAP), CVR> Given that, if someone wants to write a fully external CVR> authenticator, is it possible to completely disable mailman's CVR> interface for a given list (or all lists?) Including things CVR> like monthly password reminders? CVR> I guess what I'm suggesting is Mailman as a slave to a CVR> non-attached membership system -- can we really detach it CVR> cleanly so it's just a delivery system without rough edges or CVR> hacking? Down to the external membership system in headers CVR> and footers? Hmm, let me try to untangle a couple of issues. First, this adaptor API is only for membership-related information. It doesn't cover other list-related data, such as "what's the subscription policy for this list?". I want to do that eventually, but not for 2.1. But the membership API is complete, in that you can ask for a member's real name, their password, their case-preserved email address, their option flags (do they get MIME digests?), their preferred language, etc. It covers adding new members and removing old members. This means that if you supply a different backend implementation for the API, it's all or nothing: you're responsible for the entire API and managing all the member-related data. So, when Mailman has to authenticate a user for access to their options page, it uses the API, passing in the email address and the response and it should receive a boolean specifying whether the username/passwords matched. One other thing that Control.com sponsored, but which I forgot to add to the NEWS file, was an API for an external process to post messages to a list, and to specify the explicit list of recipients in the posting interaction. What this means is that you could create a list, say "employees@dom.ain". Then when you want to post a message to this list, you simply create the message, and determine what the explicit list of recipients is, then send both to the posting code. With the list-extension mechanism, you could also completely defeat the U/I (I think) so that Mailman would indeed act as a posting slave. >> This work was sponsored by Control.com CVR> (clap clap clap clap) Indeed! -Barry From barry@zope.com Mon Oct 22 17:41:08 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 12:41:08 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 References: <23817.1003734619@kanga.nu> Message-ID: <15316.19492.552451.735523@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> IIRC the language in 2822, the (form) is mildly deprecated. Yes. We get both by virtue of the underlying Python library recognizing both (the key thing wasn't parsing those forms, it was setting up the data structures and u/i's to track real names). JCL> Password reminders are (arguably) the ideal VERP opportunity. I'm hoping to do /something/ here for 2.1 -- we'll see if there's time. -Barry From liuk@publinet.it Mon Oct 22 18:01:34 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 22 Oct 2001 19:01:34 +0200 Subject: [Mailman-Developers] Weird things happen after upgrade to 2.1a3+ CVS :-( Message-ID: <20011022190134.A28606@publinet.it> Hi, just after upgrading to 2.1a3+ (latest CVS) it seems that nothing is working any more. Python 2.0.1, email-0.93. Here is an error message from gate_news and accessing to the Web U/I works only for one list! I'll send the error log in another message. Why make update said "nothing to do"? Are the config.pck files changed after the modifications to the moderation process? Do I have to convert them in some way? Gulp :-( --luca ----- Forwarded message from Cron Daemon ----- Date: Mon, 22 Oct 2001 18:50:02 +0200 From: root@relay.publinet.it (Cron Daemon) Subject: Cron /usr/bin/python2 -S /home/mailman/cron/gate_news To: mailman@relay.publinet.it Traceback (most recent call last): File "/home/mailman/cron/gate_news", line 249, in ? main() File "/home/mailman/cron/gate_news", line 230, in main process_lists(lock) File "/home/mailman/cron/gate_news", line 164, in process_lists mlist = MailList.MailList(listname, lock=0) File "/home/mailman/Mailman/MailList.py", line 98, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 531, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 546, in CheckVersion Update(self, stored_state) File "/home/mailman/Mailman/versions.py", line 50, in Update UpdateOldVars(l, stored_state) File "/home/mailman/Mailman/versions.py", line 153, in UpdateOldVars l.setMemberOption(addr, mm_cfg.Moderate, 1) File "/home/mailman/Mailman/OldStyleMemberships.py", line 231, in setMemberOption assert self.__mlist.Locked() AssertionError ----- End forwarded message ----- From chuqui@plaidworks.com Mon Oct 22 18:01:31 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 22 Oct 2001 10:01:31 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: <15316.19395.73796.708333@anthem.wooz.org> Message-ID: On 10/22/01 9:39 AM, "Barry A. Warsaw" wrote: > CVR> Is the Urgent: header stripped as it passes through Mailman? > CVR> What happens when a regular user tries to put an Urgent: > CVR> header on a message as a non-admin? > > Just like an Approved: header, it's always stripped because it > contains a password. Should these be sent to the admin as well as a possible security breach attempt? > Hmm, let me try to untangle a couple of issues. > > First, this adaptor API is only for membership-related information. I'm actually thinking of moving the membership data completely out of Mailman and having mailman act as a slave to an outside system. Two reasons: - think of a corporate list server, where subscriber lists are created based on organization charts and aren't under the control of the list server completely. - think of an integrated community, where you want a single subscriber interface, but multiple systems, including (but not limited to) a mail list system. > This means that if you supply a different backend implementation for > the API, it's all or nothing: you're responsible for the entire API > and managing all the member-related data. Okay, that's where I'm headed. Except I want to go a little further, which is turn off mailman's interface completely, hopefully on a per-list basis. You could, I suppose, make the list private on the mailman side, but there are still issues, such as header/footer data, etc... > One other thing that Control.com sponsored, but which I forgot to add > to the NEWS file, was an API for an external process to post messages > to a list, and to specify the explicit list of recipients in the > posting interaction. What this means is that you could create a list, > say "employees@dom.ain". Then when you want to post a message to this > list, you simply create the message, and determine what the explicit > list of recipients is, then send both to the posting code. With the > list-extension mechanism, you could also completely defeat the U/I (I > think) so that Mailman would indeed act as a posting slave. Okay, neat. That seems pretty close to what I'm thinking. Close enough for government work, at least. So you could use extend() to gut mailman's interface, and then write an external that would, say, look thing up out of an LDAP that interfaces to the corprate database... From Dale Newfield Mon Oct 22 18:11:02 2001 From: Dale Newfield (Dale Newfield) Date: Mon, 22 Oct 2001 13:11:02 -0400 (EDT) Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message-ID: On Mon, 22 Oct 2001, Chuq Von Rospach wrote: > I'm actually thinking of moving the membership data completely out of > Mailman and having mailman act as a slave to an outside system. > - think of an integrated community, where you want a single subscriber > interface, but multiple systems, including (but not limited to) a mail list > system. I'm going to be building this very thing--we've got an incredibly detailed system for orders/content management/etc, and what mailing lists the individuals are subscribed to should be manageable from inside that system. Really what that means is that I want the functionality of Mailman, but I want the database to be the mysql one that the other system uses. I won't be able to get started on this for another month or so, but knowing that someone has thought about it gives me warm fuzzies. Any pitfalls I should be aware of? --- Dale Newfield "My country, right or wrong" is not a cogent argument. It is one step away from "I was only following orders." From chuqui@plaidworks.com Mon Oct 22 18:31:57 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 22 Oct 2001 10:31:57 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message-ID: On 10/22/01 10:11 AM, "Dale Newfield" wrote: > I won't be able to get started on this for another month or so, but > knowing that someone has thought about it gives me warm fuzzies. Any > pitfalls I should be aware of? It was something I put a fair amount of energy into before I started my sabbatical... You might look at For some history of my stuff. (if you're trying to figure out what the heck I mean by "my sabbatical", look here: ) I basically have three long-term 'things' I'm looking at: 1) an internal list server, currently a custom perl system, that handles all of Apple's internal groups. The management of those groups is fully external to the system. The current system downloads a data dump from the corporate database every couple of hours and does nasty things to it, turning it into a huge sendmail alias file. A future generation will probably replace that with a real-time LDAP interface. I'd really like to avoid writing the whole beast, and add things like digest capability. 2) taking all my apple list stuff, and moving subscription management into a central access point for all things Apple. Which doesn't exist yet, but the first pieces are there. I'd really like it so that there's a single place to manage everything you do in your on-line relationship with Apple, not zillions of different forms, signups, accounts, passwords and "if you're looking for *this*, go to *that* web site, not here" notices. 3) and in my non-apple life, I want to build something similar to (2), but for my own uses. If I decide to return from sabbatical. Or maybe grab an existing thing like php-nuke, and wedge mailman onto the side. But it's really clear (to me) that this stuff all has to get integrated down the road, and giving a user site-wide, consistent administration is a key usability issue -- and there's more to life than mail lists. Tools that don't integrate, are going to find themselves marginalized or replaced. All IMHO (or actually, IMNSHO). From donal.hunt2@mail.dcu.ie Mon Oct 22 18:39:17 2001 From: donal.hunt2@mail.dcu.ie (donal.hunt2@mail.dcu.ie) Date: Mon, 22 Oct 2001 18:39:17 +0100 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message-ID: <3BD442BC000001DA@hawk.dcu.ie> comments from a LDAP POV below... D. --__--__-- Date: Sun, 21 Oct 2001 23:37:02 -0700 From: Chuq Von Rospach To: "Barry A. Warsaw" , Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 >On 10/21/01 11:17 PM, "Barry A. Warsaw" wrote: > > >> http://sourceforge.net/project/shownotes.php?release_id=3D58074 >> - Membership Adaptors >> o Internally, mailing list memberships are accessed through a >> MemberAdaptor interface. This would allow for integrating >> membership databases with external sources (e.g. Zope or >> LDAP), > >Given that, if someone wants to write a fully external authenticator, is= it >possible to completely disable mailman's interface for a given list (or all >lists?) Including things like monthly password reminders? >From working with porting Mailman 2.0.2 to using LDAP for (part) authenti= cation, I found I had to do a quick check and see if the user was being stored in= LDAP or in the Mailman structure. If it was a LDAP authenticated user, the generated webpage told them that the password for the specific user was unavailable (due to being stored in LDAP). The user got a similar re= ply if the request was via email. But users were still able to change options like "nomail", "digest", etc by using their LDAP attributes for authentication/storage. However this involved severe hacking of the Mailman modules (more than I liked) and from what I've read so far Mailman 2.1 won't need this hacking= - I'm still waiting for resources to be assigned so I can start working on an LDAP authenticator for 2.1 (next day or two hopefully). The source for the 2.0.2 hack is available, but I want to finish cleaning= it up before I give it to people (again I'm waiting for resources). :( Hope that gives an insight into what I'ld be looking for. One of these would be the possibilty of authenticating against one or more data sourc= es - eg LDAP for local users and a Python pickle or marshal for remote users= . For example all details for all the users in a university (in my case) would already be in a directory server, but remote users (members of list= s hosted by the university for example) would be stored seperately. Of cou= rse we could make authentication a "per-list" setting. This is rapidly getti= ng into Mailman v3 territory so i'll stop here. Regards Donal Hunt --__--__-- From fil@rezo.net Mon Oct 22 18:47:27 2001 From: fil@rezo.net (Fil) Date: Mon, 22 Oct 2001 19:47:27 +0200 Subject: [Mailman-Developers] how to get the latest .po file to translate? Message-ID: <20011022194727.F26909@orwell.bok.net> how do you get the latests .po file? The french translation in version 2.1-alpha3 currently lacks quite a few sentences... -- Fil From claw@2wire.com Mon Oct 22 20:16:30 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 22 Oct 2001 12:16:30 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message from Chuq Von Rospach of "Mon, 22 Oct 2001 10:31:57 PDT." References: Message-ID: <2873.1003778190@2wire.com> On Mon, 22 Oct 2001 10:31:57 -0700 Chuq Von Rospach wrote: > 3) and in my non-apple life, I want to build something similar to > (2), but for my own uses. If I decide to return from > sabbatical. Or maybe grab an existing thing like php-nuke, and > wedge mailman onto the side. But it's really clear (to me) that > this stuff all has to get integrated down the road, and giving a > user site-wide, consistent administration is a key usability issue > -- and there's more to life than mail lists. Tools that don't > integrate, are going to find themselves marginalized or replaced. I've recently adopted Drupal for my purposes: http://www.drop.org/ http://www.drop.org/node.php?id=411 It has a number of problems, among which ranks horrible navigation. Its all fairly easily fixable -- as always it just needs doing, and I have a fairly long TODO list for Drupal. The Drupal source is fairly clean, easily extensible, and the core development team is willing to listen, especially if you keep chanting "integration!" My biggest challenge is to get them to stop re-inventing the wheel and instead look to turning Drupal into glue which can be used to bind any number of external systems together (eg search engine, bug tracking ticketing, list archives, jabber chat, IRC, polling/survey system, etc) along with a set of base Drupal features. Happily the project is young and flexible enough I think its still possible. PHP-Nute et al are far too entrenched. So far I've gotten them off MySQL only and onto PEAR and thus PostgresQL. I'm currently writing a unified namespace patch with an eye to a) Wikifying the entire thing (all nodes are WikiItems), and b) having the namespace transparently extensible to non-Drupal items (its just a set of string mapping functions between names and URLs), and c) having the namespace transparent inter-Drupal in exactly the same way InterWiki names work (except that I'll likely add an XML/RPC post-change/notify layer). Happily, implementing a unified namespace does a lot to fix the worst navigation problems. After that comes the rest of the TODO list, with the Wikifying project heading the list (which is just messy in the details). Somewhere down the pipe is integrating Mailman. Currently Drupal will auth against its own local DB, another other Drupal it can reach via XML/RPC, or against a JabberID. Auth against LDAP and against Delphi are just about to hit CVS along with an interesting auth abstraction layer. My hope is that once that transition is done I can shove Mailman 2.5's auth and member configs under there (likely via LDAP), as well as integrating Mailman with Jabber-based discussion lists, MHonArc based web archives, web-based posting etc. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Mon Oct 22 20:20:05 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 15:20:05 -0400 Subject: [Mailman-Developers] Weird things happen after upgrade to 2.1a3+ CVS :-( References: <20011022190134.A28606@publinet.it> Message-ID: <15316.29029.951669.646882@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> just after upgrading to 2.1a3+ (latest CVS) it seems that LM> nothing is working any more. Python 2.0.1, email-0.93. LM> Here is an error message from gate_news and accessing to the LM> Web U/I works only for one list! I'll send the error log in LM> another message. Darn, Dan Mick discovered the same problem triggered from senddigests. The problem is both scripts open the list unlocked, and that breaks auto-upgrade of the schemas. Attached is the patch I sent Dan, and I /thought/ I checked in, but now see I didn't. I will now though. Can you give it a try? LM> Why make update said "nothing to do"? Are the config.pck files LM> changed after the modifications to the moderation process? Do LM> I have to convert them in some way? No, you don't have to do anything. Mailman should read both config.db and config.pck and always write config.pck, so it should automatically convert the first time it loads the list in a locked state. Hitting its web page or sending it an email should be all it takes. Or even running senddigest or gate_news the first time -- after application of this patch... -Barry -------------------- snip snip -------------------- Index: MailList.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v retrieving revision 2.45 diff -u -r2.45 MailList.py --- MailList.py 2001/10/21 06:32:36 2.45 +++ MailList.py 2001/10/22 19:18:57 @@ -535,18 +535,25 @@ # Sanity checks # def CheckVersion(self, stored_state): - """Migrate prior version's state to new structure, if changed.""" - if (self.data_version >= mm_cfg.DATA_FILE_VERSION and - type(self.data_version) == type(mm_cfg.DATA_FILE_VERSION)): + """Auto-update schema if necessary.""" + if self.data_version >= mm_cfg.DATA_FILE_VERSION: return else: - self.InitVars() # Init any new variables, - self.Load(check_version = 0) # then reload the file - from versions import Update - Update(self, stored_state) - self.data_version = mm_cfg.DATA_FILE_VERSION - if self.Locked(): - self.Save() + # Initialize any new variables + self.InitVars() + # Then reload the database (but don't recurse) + self.Load(check_version=0) + # We must hold the list lock in order to update the schema + waslocked = self.Locked() + self.Lock() + try: + from versions import Update + Update(self, stored_state) + self.data_version = mm_cfg.DATA_FILE_VERSION + self.Save() + finally: + if not waslocked: + self.Unlock() def CheckValues(self): """Normalize selected values to known formats.""" From claw@2wire.com Mon Oct 22 20:21:03 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 22 Oct 2001 12:21:03 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message from Chuq Von Rospach of "Mon, 22 Oct 2001 10:01:31 PDT." References: Message-ID: <2935.1003778463@2wire.com> On Mon, 22 Oct 2001 10:01:31 -0700 Chuq Von Rospach wrote: > - think of an integrated community, where you want a single > subscriber interface, but multiple systems, including (but not > limited to) a mail list system. I'm more interested in going a step further, toward an auth and config system which is not only external to Mailman, but which is an assembly of fragmented/divers forms which are then unified. Specifically I'd like to build a system which can auth against Jabber, LDAP, other Mailman installations (XML/RPC), anything else that satisfies the same XML/RPC requirements, LDAP, SQL, etc. No more of this single one-source-for-everything deal. I also have a particular interest in doing mixed-mode SMTP/Jabber based lists all run/operated by Mailman. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jra@baylink.com Mon Oct 22 20:26:10 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 22 Oct 2001 15:26:10 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: <2935.1003778463@2wire.com>; from J C Lawrence on Mon, Oct 22, 2001 at 12:21:03PM -0700 References: <2935.1003778463@2wire.com> Message-ID: <20011022152610.46756@scfn.thpl.lib.fl.us> On Mon, Oct 22, 2001 at 12:21:03PM -0700, J C Lawrence wrote: > I'm more interested in going a step further, toward an auth and > config system which is not only external to Mailman, but which is an > assembly of fragmented/divers forms which are then unified. > Specifically I'd like to build a system which can auth against > Jabber, LDAP, other Mailman installations (XML/RPC), anything else > that satisfies the same XML/RPC requirements, LDAP, SQL, etc. No > more of this single one-source-for-everything deal. Have you looked at Liberty? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From Dan Mick Mon Oct 22 20:40:18 2001 From: Dan Mick (Dan Mick) Date: Mon, 22 Oct 2001 12:40:18 -0700 (PDT) Subject: [Mailman-Developers] Weird things happen after upgrade to 2.1a3+ CVS :-( Message-ID: <200110221939.MAA13823@utopia.West.Sun.COM> I seemed to have to *remove* that patch after updating to latest CVS today, else I got "already locked" errors. I'm confused. > >>>>> "LM" == Luca Maranzano writes: > > LM> just after upgrading to 2.1a3+ (latest CVS) it seems that > LM> nothing is working any more. Python 2.0.1, email-0.93. > > LM> Here is an error message from gate_news and accessing to the > LM> Web U/I works only for one list! I'll send the error log in > LM> another message. > > Darn, Dan Mick discovered the same problem triggered from > senddigests. The problem is both scripts open the list unlocked, and > that breaks auto-upgrade of the schemas. Attached is the patch I sent > Dan, and I /thought/ I checked in, but now see I didn't. > > I will now though. Can you give it a try? > > LM> Why make update said "nothing to do"? Are the config.pck files > LM> changed after the modifications to the moderation process? Do > LM> I have to convert them in some way? > > No, you don't have to do anything. Mailman should read both config.db > and config.pck and always write config.pck, so it should automatically > convert the first time it loads the list in a locked state. Hitting > its web page or sending it an email should be all it takes. Or even > running senddigest or gate_news the first time -- after application of > this patch... > > -Barry > > -------------------- snip snip -------------------- > Index: MailList.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v > retrieving revision 2.45 > diff -u -r2.45 MailList.py > --- MailList.py 2001/10/21 06:32:36 2.45 > +++ MailList.py 2001/10/22 19:18:57 > @@ -535,18 +535,25 @@ > # Sanity checks > # > def CheckVersion(self, stored_state): > - """Migrate prior version's state to new structure, if changed.""" > - if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > - type(self.data_version) == type(mm_cfg.DATA_FILE_VERSION)): > + """Auto-update schema if necessary.""" > + if self.data_version >= mm_cfg.DATA_FILE_VERSION: > return > else: > - self.InitVars() # Init any new variables, > - self.Load(check_version = 0) # then reload the file > - from versions import Update > - Update(self, stored_state) > - self.data_version = mm_cfg.DATA_FILE_VERSION > - if self.Locked(): > - self.Save() > + # Initialize any new variables > + self.InitVars() > + # Then reload the database (but don't recurse) > + self.Load(check_version=0) > + # We must hold the list lock in order to update the schema > + waslocked = self.Locked() > + self.Lock() > + try: > + from versions import Update > + Update(self, stored_state) > + self.data_version = mm_cfg.DATA_FILE_VERSION > + self.Save() > + finally: > + if not waslocked: > + self.Unlock() > > def CheckValues(self): > """Normalize selected values to known formats.""" > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From liuk@publinet.it Mon Oct 22 20:50:44 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 22 Oct 2001 21:50:44 +0200 Subject: [Mailman-Developers] Weird things happen after upgrade to 2.1a3+ CVS :-( In-Reply-To: <15316.29029.951669.646882@anthem.wooz.org> References: <20011022190134.A28606@publinet.it> <15316.29029.951669.646882@anthem.wooz.org> Message-ID: <20011022215044.A29975@publinet.it> On Mon, Oct 22, 2001 at 03:20:05PM -0400, Barry A. Warsaw wrote: > > >>>>> "LM" == Luca Maranzano writes: > > LM> just after upgrading to 2.1a3+ (latest CVS) it seems that > LM> nothing is working any more. Python 2.0.1, email-0.93. > > LM> Here is an error message from gate_news and accessing to the > LM> Web U/I works only for one list! I'll send the error log in > LM> another message. > > Darn, Dan Mick discovered the same problem triggered from > senddigests. The problem is both scripts open the list unlocked, and > that breaks auto-upgrade of the schemas. Attached is the patch I sent > Dan, and I /thought/ I checked in, but now see I didn't. I've checked out to latest CVS, your patch has been applied, and now the error is different: /usr/bin/python2 -S /home/mailman/cron/gate_news Traceback (most recent call last): File "/home/mailman/cron/gate_news", line 249, in ? main() File "/home/mailman/cron/gate_news", line 230, in main process_lists(lock) File "/home/mailman/cron/gate_news", line 164, in process_lists mlist = MailList.MailList(listname, lock=0) File "/home/mailman/Mailman/MailList.py", line 98, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 531, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 548, in CheckVersion self.Lock() File "/home/mailman/Mailman/MailList.py", line 151, in Lock self.Load() File "/home/mailman/Mailman/MailList.py", line 531, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 548, in CheckVersion self.Lock() File "/home/mailman/Mailman/MailList.py", line 147, in Lock self.__lock.lock(timeout) File "/home/mailman/Mailman/LockFile.py", line 268, in lock raise AlreadyLockedError Mailman.LockFile.AlreadyLockedError Besides if I access main page via Web (ie: http://my.site.org/mailman/listinfo) I get the *same* error. Let me know if there is something I can do (apart studying Pyton ;-) Thank you. --luca From christopher@schulte.org Mon Oct 22 20:49:33 2001 From: christopher@schulte.org (Christopher Schulte) Date: Mon, 22 Oct 2001 14:49:33 -0500 Subject: [Mailman-Developers] mailman 2.1a3: gate_news requires mimelib, old email package listed Message-ID: <5.1.0.14.0.20011022142725.01c68150@pop.schulte.org> From the installed crontab for user mailman, when it runs gate_news: ------ Traceback (most recent call last): File "/usr/local/mailman/cron/gate_news", line 52, in ? import mimelib.Errors ImportError: No module named mimelib.Errors ------ I thought mimelib was no longer needed? Also, I followed the directions and installed email 0.93 in ./misc , but it shows 0.92 installed. Anyone know what might be causing that? [2:31pm futon:/root]# python Python 2.1 (#1, Jul 3 2001, 20:11:19) [GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import email >>> email.__version__ '0.92' From liuk@publinet.it Mon Oct 22 20:58:22 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 22 Oct 2001 21:58:22 +0200 Subject: [Mailman-Developers] To be more precise on the Web errors... Message-ID: <20011022215822.B29975@publinet.it> Hi, it seems that accessing via Web the main /mailman/listinfo page I get the error below, but if I access directly one (and only this, it seems) list via /mailman/listinfo/listname all works fine :-) I can perform all the administrative operations! :-) I don't know why only for this list, anyway... Here is the Traceback for the lists that don't work: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 96, in run_main main() File "/home/mailman/Mailman/Cgi/admin.py", line 62, in main mlist = MailList.MailList(listname, lock=0) File "/home/mailman/Mailman/MailList.py", line 98, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 531, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 548, in CheckVersion self.Lock() File "/home/mailman/Mailman/MailList.py", line 151, in Lock self.Load() File "/home/mailman/Mailman/MailList.py", line 531, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 548, in CheckVersion self.Lock() File "/home/mailman/Mailman/MailList.py", line 147, in Lock self.__lock.lock(timeout) File "/home/mailman/Mailman/LockFile.py", line 268, in lock raise AlreadyLockedError AlreadyLockedError: --luca From Dan Mick Mon Oct 22 21:02:43 2001 From: Dan Mick (Dan Mick) Date: Mon, 22 Oct 2001 13:02:43 -0700 (PDT) Subject: [Mailman-Developers] mailman 2.1a3: gate_news requires mimelib, old email package listed Message-ID: <200110222001.NAA15159@utopia.West.Sun.COM> Barry, please take note: > From the installed crontab for user mailman, when it runs gate_news: > > ------ > Traceback (most recent call last): > File "/usr/local/mailman/cron/gate_news", line 52, in ? > import mimelib.Errors > ImportError: No module named mimelib.Errors > ------ > > I thought mimelib was no longer needed? Oops. Yes, a bug. > Also, I followed the directions and installed email 0.93 in ./misc , but it > shows 0.92 installed. Anyone know what might be causing that? > > [2:31pm futon:/root]# python > Python 2.1 (#1, Jul 3 2001, 20:11:19) > [GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4 > Type "copyright", "credits" or "license" for more information. > >>> import email > >>> email.__version__ > '0.92' The distutils don't seem to include "uninstall", which is a mistake IMO. But the real reason is that the version number didn't get bumped, another bug. From barry@zope.com Mon Oct 22 21:01:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 16:01:46 -0400 Subject: [Mailman-Developers] To be more precise on the Web errors... References: <20011022215822.B29975@publinet.it> Message-ID: <15316.31530.221493.571023@anthem.wooz.org> Okay, give me a few minutes... From Dan Mick Mon Oct 22 21:05:17 2001 From: Dan Mick (Dan Mick) Date: Mon, 22 Oct 2001 13:05:17 -0700 (PDT) Subject: [Mailman-Developers] To be more precise on the Web errors... Message-ID: <200110222004.NAA15539@utopia.West.Sun.COM> I still seem OK without that latest MailList.py patch. > Hi, > > it seems that accessing via Web the main /mailman/listinfo page I get the error > below, but if I access directly one (and only this, it seems) list > via /mailman/listinfo/listname all works fine :-) I can perform all the > administrative operations! :-) I don't know why only for this list, > anyway... > > Here is the Traceback for the lists that don't work: > > Traceback (most recent call last): > File "/home/mailman/scripts/driver", line 96, in run_main > main() > File "/home/mailman/Mailman/Cgi/admin.py", line 62, in main > mlist = MailList.MailList(listname, lock=0) > File "/home/mailman/Mailman/MailList.py", line 98, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 531, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 548, in CheckVersion > self.Lock() > File "/home/mailman/Mailman/MailList.py", line 151, in Lock > self.Load() > File "/home/mailman/Mailman/MailList.py", line 531, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 548, in CheckVersion > self.Lock() > File "/home/mailman/Mailman/MailList.py", line 147, in Lock > self.__lock.lock(timeout) > File "/home/mailman/Mailman/LockFile.py", line 268, in lock > raise AlreadyLockedError > AlreadyLockedError: > > --luca > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From chuqui@plaidworks.com Mon Oct 22 20:46:48 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 22 Oct 2001 12:46:48 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: <20011022152610.46756@scfn.thpl.lib.fl.us> Message-ID: On 10/22/01 12:26 PM, "Jay R. Ashworth" wrote: > Have you looked at Liberty? URL? I'm tempted to ask JC "why not php-nuke?", but I'm afraid it's a bit too off-topic.... If there's interest in discussing this meta-integration issue, I'll set up a forum on chuqui.com for it... From jra@baylink.com Mon Oct 22 21:19:57 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 22 Oct 2001 16:19:57 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: ; from Chuq Von Rospach on Mon, Oct 22, 2001 at 12:46:48PM -0700 References: <20011022152610.46756@scfn.thpl.lib.fl.us> Message-ID: <20011022161957.52349@scfn.thpl.lib.fl.us> On Mon, Oct 22, 2001 at 12:46:48PM -0700, Chuq Von Rospach wrote: > On 10/22/01 12:26 PM, "Jay R. Ashworth" wrote: > > Have you looked at Liberty? > > URL? > > I'm tempted to ask JC "why not php-nuke?", but I'm afraid it's a bit too > off-topic.... > > If there's interest in discussing this meta-integration issue, I'll set up a > forum on chuqui.com for it... The Liberty Alliance is a consortium of companies and organizations assembling a distributed single-sign-on authentication as, basically, a rebuttal to Hailstorm -- since, as with so many of Microsoft's grand ideas, the only problem with Hailstorm is that it's run by Microsoft. The website is at www.libertyproject.org; the list of participants is impressive (and includes ORA and the Apache Foundation. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From barry@zope.com Mon Oct 22 21:28:01 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 16:28:01 -0400 Subject: [Mailman-Developers] To be more precise on the Web errors... References: <200110222004.NAA15539@utopia.West.Sun.COM> Message-ID: <15316.33105.159361.262753@anthem.wooz.org> I'm a big dummy. MailList.Locked() can't be called on an already locked list. So this should do the trick (apply on top of last patch, or just "cvs up" in a few minutes). -Barry -------------------- snip snip -------------------- Index: MailList.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v retrieving revision 2.46 diff -u -r2.46 MailList.py --- MailList.py 2001/10/22 19:20:37 2.46 +++ MailList.py 2001/10/22 20:27:08 @@ -545,7 +545,8 @@ self.Load(check_version=0) # We must hold the list lock in order to update the schema waslocked = self.Locked() - self.Lock() + if not waslocked: + self.Lock() try: from versions import Update Update(self, stored_state) From barry@zope.com Mon Oct 22 21:37:22 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 16:37:22 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 References: <20011022152610.46756@scfn.thpl.lib.fl.us> <20011022161957.52349@scfn.thpl.lib.fl.us> Message-ID: <15316.33666.195138.192087@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> The website is at www.libertyproject.org; the list of JRA> participants is impressive (and includes ORA and the Apache JRA> Foundation. Dude, are you sure about that URL? It's a pr0n site. -Barry From jra@baylink.com Mon Oct 22 21:40:06 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 22 Oct 2001 16:40:06 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: <15316.33666.195138.192087@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Oct 22, 2001 at 04:37:22PM -0400 References: <20011022152610.46756@scfn.thpl.lib.fl.us> <20011022161957.52349@scfn.thpl.lib.fl.us> <15316.33666.195138.192087@anthem.wooz.org> Message-ID: <20011022164006.28265@scfn.thpl.lib.fl.us> On Mon, Oct 22, 2001 at 04:37:22PM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> The website is at www.libertyproject.org; the list of > JRA> participants is impressive (and includes ORA and the Apache > JRA> Foundation. > > Dude, are you sure about that URL? It's a pr0n site. My abject apologies. www.projectliberty.org Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From barry@zope.com Mon Oct 22 21:44:31 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 16:44:31 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 References: <20011022152610.46756@scfn.thpl.lib.fl.us> <20011022161957.52349@scfn.thpl.lib.fl.us> <15316.33666.195138.192087@anthem.wooz.org> <20011022164006.28265@scfn.thpl.lib.fl.us> Message-ID: <15316.34095.365713.394082@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> My abject apologies. www.projectliberty.org Phew! my-palms-were-getting-sweaty-ly y'rs, -Barry From liuk@publinet.it Mon Oct 22 22:01:53 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 22 Oct 2001 23:01:53 +0200 Subject: Ok, it works! :) Re: [Mailman-Developers] To be more precise on the Web errors... In-Reply-To: <15316.33105.159361.262753@anthem.wooz.org> References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> Message-ID: <20011022230153.A30637@publinet.it> Great Barry! :) It seems that all is OK now, both gate_news and the Web U/I :) I've still to report this: after issuing /etc/init.d/mailman start I got the following to the terminal: Traceback (most recent call last): File "/home/mailman/Mailman/Archiver/Archiver.py", line 183, in ArchiveMail h.processUnixMailbox(f, HyperArch.Article) File "/home/mailman/Mailman/Archiver/pipermail.py", line 525, in processUnixMailbox a = articleClass(m, self.sequence) File "/home/mailman/Mailman/Archiver/HyperArch.py", line 150, in __init__ self.__super_init(message, sequence, keepHeaders) File "/home/mailman/Mailman/Archiver/pipermail.py", line 210, in __init__ s = StringIO(message.get_payload()) TypeError: expected string, list found Hoping to be useful :) --luca From barry@zope.com Mon Oct 22 22:30:43 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 17:30:43 -0400 Subject: [Mailman-Developers] mailman 2.1a3: gate_news requires mimelib, old email package listed References: <5.1.0.14.0.20011022142725.01c68150@pop.schulte.org> Message-ID: <15316.36867.262486.266875@anthem.wooz.org> >>>>> "CS" == Christopher Schulte writes: CS> I thought mimelib was no longer needed? Right. I missed a few. ;) CVS should be updated now. CS> Also, I followed the directions and installed email 0.93 in CS> ./misc , but it shows 0.92 installed. Anyone know what might CS> be causing that? This version should be fine, the version number in __init__.py wasn't bumped (in my defense, I've been sick all week. ;). I have a couple of pending fixes to the email package that I need to finish up on, and then I'll stick a new version in misc/. I guess I should do an alpha4 soon as possible too. -Barry From barry@zope.com Mon Oct 22 22:31:29 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 17:31:29 -0400 Subject: [Mailman-Developers] mailman 2.1a3: gate_news requires mimelib, old email package listed References: <200110222001.NAA15159@utopia.West.Sun.COM> Message-ID: <15316.36913.419260.761362@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> The distutils don't seem to include "uninstall", which is a DM> mistake IMO. I agree. I wish the distutils guys would add an uninstall command. :/ -Barry From liuk@publinet.it Mon Oct 22 22:43:24 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 22 Oct 2001 23:43:24 +0200 Subject: [Mailman-Developers] Questions about moderations Message-ID: <20011022234324.A31051@publinet.it> Hi, I'm testing the new moderation options and I have some questions :) 1. For the lists which have the moderation flag on previuos the MM upgrade do I have to set the moderation bit to On manually? In the member list the mod flag for each member is off. 2. I've tryed to use the confirmation via email for the approvation of a message but something is not very clear to me. In the confirm message I receive this (the 3rd part of the MIME message): ===snip If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. ===snip Well, if I reply to the message with the correct subject and adding this line at the top of the body: Approved: LISTPW Then the message is delivered successfully to the list, but I get also the following: ===snip This is an automated response. There were problems with the email commands you sent to Mailman via the administrative address listname-request@my.site. To obtain instructions on valid Mailman email commands, send email to listname-request@my.site with the word "help" in the subject line or in the body of the message. If you want to reach the human being that manages this mailing list, please send your message to listname-admin@my.site. The following is a detailed description of the problems. ***** confirm 074d33e2275888969f48e2faee2252fe08dd032c Succeeded Command? Approved: LISTPW ===snip Why? BTW, I use mutt as my MUA, but this should be ininfluent. Thank you. --luca From liuk@publinet.it Mon Oct 22 22:51:58 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 22 Oct 2001 23:51:58 +0200 Subject: [Mailman-Developers] Is max_message_size honored? Message-ID: <20011022235158.A31245@publinet.it> Hi again all, I've tryed to post a brief text message with a 350KB attachment to a list which has max_message_size = 40 (KB). The list is moderated, and the message arrives to the moderator with all the attachment (and this may be good), but if the moderator approves the message it is delivered to the list even if its size >40 KB! Besides, should these messages that exceed the max_message_size specific for the list immediately be discarded and eventually notify the moderator or the owner? --luca From wilane@yahoo.com Mon Oct 22 22:56:31 2001 From: wilane@yahoo.com (Ousmane Wilane) Date: Mon, 22 Oct 2001 21:56:31 +0000 Subject: [Mailman-Developers] how to get the latest .po file to translate? In-Reply-To: <20011022194727.F26909@orwell.bok.net> References: <20011022194727.F26909@orwell.bok.net> Message-ID: <15316.38415.48205.993265@localhost.localdomain> >>>>> "F" == Fil writes: F> how do you get the latests .po file? The french translation in F> version 2.1-alpha3 currently lacks quite a few sentences... The french catalog is maintained by me, and an up-to-date version was sent to Barry while he was busy with Python, I don't know where did it went but never in cvs tree... Perhaps I did something wrong! Anyway, the last up-to-date catalog will be sent to Barry again. Sorry If I did something wrong that makes the catalog > /dev/null. I will update the new catalog as soon as I can and send it. Cheers -- Ousmane Wilane From Dan Mick Mon Oct 22 23:30:25 2001 From: Dan Mick (Dan Mick) Date: Mon, 22 Oct 2001 15:30:25 -0700 (PDT) Subject: [Mailman-Developers] Questions about moderations Message-ID: <200110222229.PAA24677@utopia.West.Sun.COM> > I'm testing the new moderation options and I have some questions :) > > 1. For the lists which have the moderation flag on previuos the MM > upgrade do I have to set the moderation bit to On manually? In the > member list the mod flag for each member is off. It looks like upgrade does not set the per-user moderation bits for every user for a previously-moderated list, yes. It could be argued that this is an UpdateOldVars() bug. I suspect 2) below is just another instance of "incredibly snotty email command parsing (honestly, it will complain about whitespace I think..) If the message was approved, then the Approved: header worked. > 2. I've tryed to use the confirmation via email for the approvation > of a message but something is not very clear to me. > In the confirm message I receive this (the 3rd part of the MIME > message): . . . > There were problems with the email commands you sent to Mailman via > the administrative address listname-request@my.site. From jra@baylink.com Tue Oct 23 00:00:50 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 22 Oct 2001 19:00:50 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: <15316.34095.365713.394082@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Oct 22, 2001 at 04:44:31PM -0400 References: <20011022152610.46756@scfn.thpl.lib.fl.us> <20011022161957.52349@scfn.thpl.lib.fl.us> <15316.33666.195138.192087@anthem.wooz.org> <20011022164006.28265@scfn.thpl.lib.fl.us> <15316.34095.365713.394082@anthem.wooz.org> Message-ID: <20011022190050.58457@scfn.thpl.lib.fl.us> On Mon, Oct 22, 2001 at 04:44:31PM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> My abject apologies. www.projectliberty.org > Phew! Indeed. > my-palms-were-getting-sweaty-ly y'rs, Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From barry@zope.com Tue Oct 23 00:18:31 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 22 Oct 2001 19:18:31 -0400 Subject: Ok, it works! :) Re: [Mailman-Developers] To be more precise on the Web errors... References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> Message-ID: <15316.43335.583379.302872@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> It seems that all is OK now, both gate_news and the Web U/I :) LM> I've still to report this: LM> after issuing /etc/init.d/mailman start | "/home/mailman/Mailman/Archiver/pipermail.py", line 210, in | __init__ | s = StringIO(message.get_payload()) | TypeError: expected string, list found Fixing this is a bit more complicated than I thought. Watch CVS tonight (hopefully). I might have to spin an alpha4 in the next couple of days though. -Barry From claw@kanga.nu Tue Oct 23 08:07:21 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 23 Oct 2001 00:07:21 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message from Chuq Von Rospach of "Mon, 22 Oct 2001 12:46:48 PDT." References: Message-ID: <7156.1003820841@kanga.nu> On Mon, 22 Oct 2001 12:46:48 -0700 Chuq Von Rospach wrote: > I'm tempted to ask JC "why not php-nuke?", but I'm afraid it's a > bit too off-topic.... PHPNuke is an older, more mature/ossified project that is headed in a different direction than I'm interested in. It would be politically (and practically) unwelcome if I stepped in and attempted to rework PHPNuke in the manner I want to, especially as many of the changes would not be backward compatible with current installations. <> And yes, this thread, if continued, should be elsewhere. > If there's interest in discussing this meta-integration issue, > I'll set up a forum on chuqui.com for it... 'K. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From liuk@publinet.it Tue Oct 23 09:51:38 2001 From: liuk@publinet.it (Luca Maranzano) Date: Tue, 23 Oct 2001 10:51:38 +0200 Subject: [Mailman-Developers] Errors from Archiver.py in logs/error Message-ID: <20011023105138.A3503@publinet.it> Hi all, I'm periodically watching the logs/error file and this morning I found this message: Oct 23 09:21:18 2001 (3892) Uncaught runner exception: [Errno 5] Input/output error Oct 23 09:21:18 2001 (3892) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/ArchRunner.py", line 70, in _dispose mlist.ArchiveMail(msg) File "/home/mailman/Mailman/Archiver/Archiver.py", line 187, in ArchiveMail traceback.print_exc() File "/usr/lib/python2.0/traceback.py", line 188, in print_exc print_exception(etype, value, tb, limit, file) File "/usr/lib/python2.0/traceback.py", line 108, in print_exception _print(file, 'Traceback (most recent call last):') File "/usr/lib/python2.0/traceback.py", line 9, in _print file.write(str+terminator) IOError: [Errno 5] Input/output error I never seen this kind of error before, and I don't think it's a low level hardware issue since the disks are OK. --luca From tollef@add.no Tue Oct 23 00:12:37 2001 From: tollef@add.no (Tollef Fog Heen) Date: 23 Oct 2001 01:12:37 +0200 Subject: [Mailman-Developers] New sender-centric moderation rules In-Reply-To: <5.1.0.14.2.20011016024815.00a35c10@lennier.cc.vt.edu> References: <5.1.0.14.2.20011016024815.00a35c10@lennier.cc.vt.edu> Message-ID: <87vgh7clqy.fsf@arabella.intern.opera.no> * Ron Jarrell | At 03:14 PM 10/15/01 -0400, Barry A. Warsaw wrote: | >Make it so list moderators can set or unset the per-user moderate | > bit (right now only list admins can do that). | | Generically, there's a lot of things that should be done with list | moderators... Email based moderation. Pretty please? :) -- Tollef Fog Heen Axiom #1: You Can't Win From tkikuchi@is.kochi-u.ac.jp Tue Oct 23 13:52:23 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 23 Oct 2001 21:52:23 +0900 Subject: [Mailman-Developers] admin.py Message-ID: <3BD56807.5E2139C3@is.kochi-u.ac.jp> Hi, Here is a short patch for admin.py. (Or, it will not translate.) --- /home/mailman/src/mailman/Mailman/Cgi/admin.py Tue Oct 23 11:49:27 2001 +++ admin.py Tue Oct 23 20:13:24 2001 @@ -728,7 +728,7 @@ else: varhelp = '/?VARHELP=%s/%s' % (category, varname) link = Link(mlist.GetScriptURL('admin') + varhelp, - _('
(Details for %s)' % varname)).Format() + _('
(Details for %(varname)s)')).Format() text = Label('%s %s' % (descr, link)).Format() else: text = Label(descr).Format() From dan.mick@west.sun.com Tue Oct 23 19:38:26 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Tue, 23 Oct 2001 11:38:26 -0700 Subject: [Mailman-Developers] New sender-centric moderation rules References: <5.1.0.14.2.20011016024815.00a35c10@lennier.cc.vt.edu> <87vgh7clqy.fsf@arabella.intern.opera.no> Message-ID: <3BD5B922.E5E4DA36@west.sun.com> Tollef Fog Heen wrote: > > * Ron Jarrell > > | At 03:14 PM 10/15/01 -0400, Barry A. Warsaw wrote: > | >Make it so list moderators can set or unset the per-user moderate > | > bit (right now only list admins can do that). > | > | Generically, there's a lot of things that should be done with list > | moderators... > > Email based moderation. Pretty please? :) Some of that is already there. Hold messages already come with a moderator cookie so that replies can accept or discard the message. I don't know if it's 100% yet, but it's getting there. From marc_news@valinux.com Wed Oct 24 00:27:34 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 23 Oct 2001 16:27:34 -0700 Subject: [Mailman-Developers] pipermail from cron? In-Reply-To: <87g08h2074.fsf@nausicaa.interq.or.jp>; from che@debian.org on Thu, Oct 18, 2001 at 10:42:23AM +0900 References: <1003271201.18090.127.camel@claudia> <878zebgkqu.fsf@nausicaa.interq.or.jp> <1003334500.30244.36.camel@claudia> <87g08h2074.fsf@nausicaa.interq.or.jp> Message-ID: <20011023162733.Z3054@magic.merlins.org> On Thu, Oct 18, 2001 at 10:42:23AM +0900, Ben Gertzfield wrote: > >>>>> "Rodolfo" == Rodolfo Pilas writes: > > Rodolfo> It is not big: > > Rodolfo> # du -h /var/spool/mailman/archives/private/ 9.1M > Rodolfo> /var/spool/mailman/archives/private > > Rodolfo> but I am thinking that the problem is perhaps in the > Rodolfo> pipermail system. > > Try turning off internal archiving (only archive to the mbox file) > and see if your problem goes away. I don't know pipermail very well, but I know that it can add one message to an archive, or rebuild a whole archive from an mbox file. Can it however update an existing archive with whatever messages have been added to a mailbox in the last X hours (i.e. disable HTML archiving in mailman and run arch from cron) If I have to, I could extract a portion of the mbox file if pipermail can't figure out which messages are new in the mbox and not yet in the HTML archive. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Wed Oct 24 01:10:16 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 23 Oct 2001 17:10:16 -0700 Subject: [Mailman-Developers] Re: Mailman and cookies. In-Reply-To: <15312.46660.471275.986209@anthem.wooz.org>; from barry@zope.com on Fri, Oct 19, 2001 at 07:24:52PM -0400 References: <15312.40637.81391.220441@anthem.wooz.org> <15312.46660.471275.986209@anthem.wooz.org> Message-ID: <20011023171016.A3054@magic.merlins.org> On Fri, Oct 19, 2001 at 07:24:52PM -0400, Barry A. Warsaw wrote: > > >>>>> "CVR" == Chuq Von Rospach writes: > > CVR> Barry, I think you need to take a look at your cookie code, > CVR> and look for ways to bullet-proof it. It seems to have some > CVR> assumptions that I found out the hard way aren't safe. > > This patch against Mailman 2.0.6 should be enough to prevent the core > dumps. If you haven't completed your upgrade yet, can you give it a > try? I've the same cookie problems than chuck except that mm's admin interface returns a 500 error (no core dump, I have python 1.5.2) Would that patch fix the failures in the admin script when a bad cookie shows up? > -------------------- snip snip -------------------- > Index: SecurityManager.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/SecurityManager.py,v > retrieving revision 1.31.2.1 > diff -u -r1.31.2.1 SecurityManager.py > --- SecurityManager.py 2001/07/25 18:07:51 1.31.2.1 > +++ SecurityManager.py 2001/10/19 23:23:12 > @@ -118,7 +118,7 @@ > cookiedata = os.environ.get('HTTP_COOKIE') > if not cookiedata: > return 0 > - c = Cookie.Cookie(cookiedata) > + c = Cookie.Cookie(cookiedata, net_setfunc=lambda x: x) > if not c.has_key(key): > return 0 > # Undo the encoding we performed in MakeCookie() above > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Wed Oct 24 08:08:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 24 Oct 2001 03:08:17 -0400 Subject: Ok, it works! :) Re: [Mailman-Developers] To be more precise on the Web errors... References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> Message-ID: <15318.26849.115454.293921@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> Great Barry! :) LM> It seems that all is OK now, both gate_news and the Web U/I :) If you're watching the CVS log messages, you might see some checkins to address the problems with Pipermail in 2.1a3. Had an all day meeting today, and I'm beat so I'll email more about it tomorrow, but I think I have a neat solution that will also address Ben's patch to clean attachments out of the archives, and may serve as a basis for a built-in de-mimer. More tomorrow, er, later today. -Barry From claw@kanga.nu Thu Oct 25 05:41:27 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 24 Oct 2001 21:41:27 -0700 Subject: [Mailman-Developers] [RELEASED] Mailman 2.1 alpha 3 In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Mon, 22 Oct 2001 02:17:35 EDT." <15315.47615.891332.994452@anthem.wooz.org> References: <15315.47615.891332.994452@anthem.wooz.org> Message-ID: <2842.1003984887@kanga.nu> Barry, We're starting to get inundated with FAQs, especially on the -users list. How about setting up one of the FAQ engines beside the Mailman ZWiki so that we can throw content there and just refer to it? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Thu Oct 25 05:48:34 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Oct 2001 00:48:34 -0400 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> Message-ID: <15319.39330.152220.376629@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> If you're watching the CVS log messages, you might see some BAW> checkins to address the problems with Pipermail in 2.1a3. BAW> Had an all day meeting today, and I'm beat so I'll email more BAW> about it tomorrow, but I think I have a neat solution that BAW> will also address Ben's patch to clean attachments out of the BAW> archives, and may serve as a basis for a built-in de-mimer. So here's the scoop. I've been thinking about Ben Gertzfield's code to sanitize the archives, and I've been mulling about the de-mime stuff. It all came to a head when 2.1a3 broke archiving for multipart messages. Here's what I've now got in cvs and it seems to work fairly well. Only more testing will tell for sure. There's a new handler module called Scrubber.py, but it's not in the primary pipeline. Only Pipermail is going to call it, and that via the new mm_cfg.py/Default.py variable ARCHIVE_SCRUBBER. This module hardcodes the following de-mime decisions: - text/plain parts are passed through unchanged - text/html parts are removed completely. If the outer message is of type text/html then the whole message is discarded (i.e. DiscardMessage is raised). - For all other non-multipart parts, we treat them as "attachments" by pulling the decoded payload out of the message, storing it in a file inside the list's private archive directory (e.g. archives/private/mylist/attachments) and rewriting the payload of the part to include a description of the attachment. Included in this description is a url to the attachment file, which Pipermail will hyperlink. One drawback here is that if archives are switched from public to private, or vice versa, all the attachment urls will break. But you could re-run bin/arch to regenerate the whole thing -- the key being that Scrubber works only on a copy of the message being prepped for the archiver, /not/ on the message being saved in the mbox. - multiparts are ignored for the first pass, but are recursed to perform the above cleaning. Then the entire scrubbed message is converted into a flat message, where only the headers are parsed and the body is slurped in one gulp; it isn't parsed recursively. Along the way, we throw out the headers for any internal parts, and we play games with the inter-part boundary strings so they are move useful (yes, this is a kludge). There's even more kludgery involved to get Pipermail to archive scrubbed message without having to rewrite huge chunks of inscrutable code. But it seems to work. Now, the interesting thing is that Scrubber.py is written so that it /could/ be used in the main pipeline. E.g. it supports the proper signature and semantics for use in the pipeline. But I'm not adding it there for now primarily because it isn't configurable via the web. All its decisions above are hardcoded because getting the u/i right is more work than I want to do right now. But if you were interested in mainlining Scrubber.py, here's how you might do it: Add it to GLOBAL_PIPELINE in your mm_cfg.py. I would suggest sticking it after ToArchives so that the mbox gets the original unscrubbed message (this lets you adjust the scrubber's behavior for archive purposes and regenerate from the raw mbox). In fact, what I'd do is move ToArchive to just after the Hold module, and stick Scrubber just between Hold and Tagger. This is untested. I think this will give us a foothold into providing a cleaner archive with Pipermail, and to experimenting with Mailman supported de-mime-ification. Probably the best that'll happen for MM2.1. Enjoy, -Barry From barry@zope.com Thu Oct 25 06:35:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Oct 2001 01:35:17 -0400 Subject: [Mailman-Developers] [RELEASED] Mailman 2.1 alpha 3 References: <15315.47615.891332.994452@anthem.wooz.org> <2842.1003984887@kanga.nu> Message-ID: <15319.42133.621403.236907@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> We're starting to get inundated with FAQs, especially on the JCL> -users list. How about setting up one of the FAQ engines JCL> beside the Mailman ZWiki so that we can throw content there JCL> and just refer to it? Excellent idea. I'll try to set one up on zope.org tomorrow if possible. Otherwise I'll set one up on python.org like the Python FAQ wizard. Stay tuned... -Barry From barry@zope.com Thu Oct 25 07:12:09 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Oct 2001 02:12:09 -0400 Subject: [Mailman-Developers] Reusing mailman login/pass or cookie ? References: <20011013132453.43d4c58f.timduru@timduru.org> Message-ID: <15319.44345.601587.805357@anthem.wooz.org> >>>>> "timduru" == writes: timduru> I've developped a few php scripts for the users of some timduru> of my lists, what I need is to have only users timduru> effectively subscribed and authenticated to the lists to timduru> be able to use the scripts. timduru> I also need to know what is the user's login in the php timduru> scripts. timduru> Is there a way to do that , either by reproducing the timduru> mailman auth process in php or by reusing the mailman timduru> cookie ? timduru> Anyone has already done that or knows of a way to do that timduru> ? I'm not aware of anybody doing that, but in Mailman 2.1, you could hook into the membership API to extract a given user's password. In Mailman all user passwords are kept in cleartext in the config.pck file. Site admin and list admin passwords are not, so that's why you can't get a reminder for a forgotten list admin password. You could certainly reuse the Mailman cookie code, or protocol. See SecurityManager.py for details of how it works. -Barry From barry@zope.com Thu Oct 25 07:17:35 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Oct 2001 02:17:35 -0400 Subject: [Mailman-Developers] Re: Mailman and cookies. References: <15312.40637.81391.220441@anthem.wooz.org> <15312.46660.471275.986209@anthem.wooz.org> <20011023171016.A3054@magic.merlins.org> Message-ID: <15319.44671.421643.447153@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I've the same cookie problems than chuck except that mm's MM> admin interface returns a 500 error (no core dump, I have MM> python 1.5.2) MM> Would that patch fix the failures in the admin script when a MM> bad cookie shows up? Interesting. I wonder why you don't get a segfault. Could be your platform is a bit more resilient about the corrupted memory? Or maybe you /are/ segfaulting, but you've got core size limits or other restrictions preventing the writing of a core file. Then your web server catches Python's crash and turns it into a 500 error? I forget what an HTTP 500 code is (and can't look it up right now). When bad cookie data shows up, you obviously won't be able to log in. The patch will prevent Cookie.py from trying to unpickle the seemingly random string stored in the cookie value. That string isn't a pickle so there's no need to avail ourself of Cookie.py's, er, convenience here. -Barry From hupp@upl.cs.wisc.edu Thu Oct 25 08:02:34 2001 From: hupp@upl.cs.wisc.edu (Adam Hupp) Date: Thu, 25 Oct 2001 02:02:34 -0500 Subject: [Mailman-Developers] Reusing mailman login/pass or cookie ? In-Reply-To: <15319.44345.601587.805357@anthem.wooz.org>; from barry@zope.com on Thu, Oct 25, 2001 at 02:12:09AM -0400 References: <20011013132453.43d4c58f.timduru@timduru.org> <15319.44345.601587.805357@anthem.wooz.org> Message-ID: <20011025020234.A12379@upl.cs.wisc.edu> On Thu, Oct 25, 2001 at 02:12:09AM -0400, Barry A. Warsaw wrote: > > >>>>> "timduru" == writes: > > timduru> I've developped a few php scripts for the users of some > timduru> of my lists, what I need is to have only users > timduru> effectively subscribed and authenticated to the lists to > timduru> be able to use the scripts. I did something similar to this except I was just checking for list membership instead of authenticating the passwd. I made a small withlist module that returned depending on whether the address was subscribed, and a suid mailman wrapper around withlist. It's not the clean solution but it works. In case anyone is interested, this was done in order to have a web board interface to mailman lists. Mailman gates the lists to a local news server (leafnode). A heavily hacked set of php scripts called phnntp interfaces to the news server. It sends all posts back to the list instead of through the news server (leafnode doesn't do moderated groups), so moderation and other list features work. The previously mentioned withlist script makes sure that groups marked private will only be visible to subscribers of the mailing list. It's convoluted but works well so far. Once I get around to it I would like to rewrite it for Zope, basically as an nntp reader that can authenticate users from Mailman. -Adam From fil@rezo.net Thu Oct 25 13:24:43 2001 From: fil@rezo.net (Fil) Date: Thu, 25 Oct 2001 14:24:43 +0200 Subject: [Mailman-Developers] bug in alpha 3 (bin/syncmembers Message-ID: <20011025142443.A20918@orwell.bok.net> bin/sync_members -w=n --notifyadmin=no -f subscribers.txt list Traceback (most recent call last): File "bin/sync_members", line 250, in ? main() File "bin/sync_members", line 184, in main filemembers = Utils.ParseAddrs(filemembers) AttributeError: 'Mailman.Utils' module has no attribute 'ParseAddrs' -- Fil From barry@zope.com Thu Oct 25 15:17:21 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Oct 2001 10:17:21 -0400 Subject: [Mailman-Developers] Reusing mailman login/pass or cookie ? References: <20011013132453.43d4c58f.timduru@timduru.org> <15319.44345.601587.805357@anthem.wooz.org> <20011025020234.A12379@upl.cs.wisc.edu> Message-ID: <15320.7921.9135.799683@anthem.wooz.org> >>>>> "AH" == Adam Hupp writes: AH> It's convoluted but works well so far. Once I get around to AH> it I would like to rewrite it for Zope, basically as an nntp AH> reader that can authenticate users from Mailman. Neat. You might also be interested in Mailman/Post.py from MM2.1. It provides a cleaner interface for external processes to post messages to Mailman lists (either directly via Python function call, or through a command line interface). -Barry From kaja@daimi.au.dk Thu Oct 25 18:12:11 2001 From: kaja@daimi.au.dk (Kaja P. Christiansen) Date: Thu, 25 Oct 2001 19:12:11 +0200 Subject: [Mailman-Developers] comments on mailman2.1a3 Message-ID: <15320.18411.511153.173440@daimi.au.dk> Thanks for all new stuff in mailman2.1a3; it looks really good. I installed it ~mailman2 and on a different web server than our production version. Here are a few comments: - after the installation of email package, the test - as recommended by INSTALL - returns email.__version__ 0.92 (and not 0.93). - no problems with the compilation (irix6.5) - directory permissions were right, except for ~mailman2/messages and mailman2/templates (no g+w permission). - loading of the pages seems slow, but it may be a local problem - the only real problem was setting the web page url correctly. what happened is that I wanted the test version to use mailman2.domain ^^^^^^^^^^^^^^^ as default url. I created a list, mailman2-test, and everything looked good - messages got posted and archived - except for the urls in the List-* headers which said something like: List-Subscribe: ^^^^^^ (and which pointed to another web server) I tried many things (HOST and URL variables for configure, DEFAULT_URL and DEFAULT_URL_HOST in mm_cfg.py, and add_virtualhost hack (which I don't understand)) but nothing helped. What *did* help was to reread NEWS, find reference to bin/fix_url.py, and find in it a comment which told me to run bin/withlist -l -r fix_url :-) - loading of the pages seems slow, but it may be a local problem. My test setup is at http://mailman2.daimi.au.dk/mailman/listinfo. I'm using it for trying out new options etc. You are welcome to use it for testing as well! Kaja From marc_news@valinux.com Thu Oct 25 19:02:53 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Thu, 25 Oct 2001 11:02:53 -0700 Subject: [Mailman-Developers] Re: Mailman and cookies. In-Reply-To: <15319.44671.421643.447153@anthem.wooz.org>; from barry@zope.com on Thu, Oct 25, 2001 at 02:17:35AM -0400 References: <15312.40637.81391.220441@anthem.wooz.org> <15312.46660.471275.986209@anthem.wooz.org> <20011023171016.A3054@magic.merlins.org> <15319.44671.421643.447153@anthem.wooz.org> Message-ID: <20011025110252.G18096@magic.merlins.org> On Thu, Oct 25, 2001 at 02:17:35AM -0400, Barry A. Warsaw wrote: > Interesting. I wonder why you don't get a segfault. Could be your > platform is a bit more resilient about the corrupted memory? Or maybe > you /are/ segfaulting, but you've got core size limits or other > restrictions preventing the writing of a core file. Then your web You are probably right. > server catches Python's crash and turns it into a 500 error? I forget > what an HTTP 500 code is (and can't look it up right now). Let's see my original report of this problem was: http://mail.python.org/pipermail/mailman-developers/2001-September/009568.html and once I looked in my server logs and found: [Thu Jul 12 15:47:17 2001] [error] [client 171.71.41.31] Premature end of script headers: /var/local/mailman/cgi-bin/admin That would be consistent with python segfaulting. > The patch will prevent Cookie.py from trying to unpickle the seemingly > random string stored in the cookie value. That string isn't a pickle > so there's no need to avail ourself of Cookie.py's, er, convenience > here. It seems that it will solve my problem too. Thanks. (I won't be able to tell right away, because I can't reproduce it myself and I only get a report of this every so often, out of thousands of list admins) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From wheakory@isu.edu Thu Oct 25 20:03:59 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Thu, 25 Oct 2001 13:03:59 -0600 Subject: [Mailman-Developers] mailman 2.0.6 problem Message-ID: <3BD8621F.38D0C3ED@isu.edu> I install Mailman 2.0.6 on a p600 10gb hard drive, 128mb, with RED HAT 7.2. The web interface works fine, I just can't receive email from the lists, when I subscribe a user they do receive a welcome message, but when they try to post a message to the list it's never received by any of the list members. The message does not even show up in the /mailman/qfiles and the /mailman/logs report nothing. The logs will only report when someone subscribes, (which are logs in /home/mailman/logs/smtp and /home/mailman/logs/subscribe, nothing is in the /home/mailman/logs/error log file). I'm using SENDMAIL -8.11.6-3. I have the wrapper set in /etc/smrsh so that's not an issue. There is no error with the MAIL GID being unknown. Here's what I receive in the /mailman/logs/smtp Oct 25 12:22:33 2001 (1888) smtp for 1 recips, completed in 0.058 seconds The /var/log/maillog logfile also does not report any errors. Any solutions? Reply to wheakory@isu.edu -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From jeremy@zope.com Fri Oct 26 02:13:43 2001 From: jeremy@zope.com (Jeremy Hylton) Date: Thu, 25 Oct 2001 21:13:43 -0400 (EDT) Subject: [Mailman-Developers] Re: Mailman-Developers digest, Vol 1 #1052 - 15 msgs In-Reply-To: References: Message-ID: <15320.47303.801456.531987@slothrop.digicool.com> Can you recommend a tool for edit and/or printing the XML document? Jeremy From bob@nleaudio.com Fri Oct 26 04:05:51 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Thu, 25 Oct 2001 23:05:51 -0400 Subject: [Mailman-Developers] Cookie bug in 2.1a3+ Message-ID: <3BD8D30F.D72C6753@nleaudio.com> Just hit this one when I tried to view the private archives: Bug in Mailman version 2.1a3 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/home/csc/mailman/scripts/driver", line 90, in run_main pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname]) File "/home/csc/mailman/Mailman/Cgi/private.py", line 29, in ? from Mailman import Cookie ImportError: cannot import name Cookie Python information: Variable Value sys.version 2.1.1 (#1, Aug 10 2001, 01:32:01) [GCC 2.95.3 19991030 (prerelease)] sys.executable /usr/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform linux2 It should have asked for my email and password. Bob From Dan Mick Fri Oct 26 03:59:28 2001 From: Dan Mick (Dan Mick) Date: Thu, 25 Oct 2001 19:59:28 -0700 (PDT) Subject: [Mailman-Developers] Cookie bug in 2.1a3+ Message-ID: <200110260258.TAA12401@utopia.West.Sun.COM> Yeah, I found this one last night. Fixed in CVS. You can just delete that import line from private.py. > Just hit this one when I tried to view the private archives: > > Bug in Mailman version 2.1a3 > > We're sorry, we hit a bug! > > If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! > > Traceback: > > Traceback (most recent call last): > File "/home/csc/mailman/scripts/driver", line 90, in run_main > pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname]) > File "/home/csc/mailman/Mailman/Cgi/private.py", line 29, in ? > from Mailman import Cookie > ImportError: cannot import name Cookie > > > > > > Python information: > > Variable > Value > sys.version > 2.1.1 (#1, Aug 10 2001, 01:32:01) [GCC 2.95.3 19991030 (prerelease)] > sys.executable > /usr/bin/python > sys.prefix > /usr/local > sys.exec_prefix > /usr/local > sys.path > /usr/local > sys.platform > linux2 > > It should have asked for my email and password. > > Bob > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From che@debian.org Fri Oct 26 04:01:20 2001 From: che@debian.org (Ben Gertzfield) Date: Fri, 26 Oct 2001 12:01:20 +0900 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <15319.39330.152220.376629@anthem.wooz.org> (barry@zope.com's message of "Thu, 25 Oct 2001 00:48:34 -0400") References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> Message-ID: <87vgh3ayv3.fsf@nausicaa.interq.or.jp> Barry, thanks lots for the great work! I love how the email module has turned out, and the function names you chose really ended up making sense. Anyway, I installed the latest mailman CVS and the email module from the misc/ directory, and successfully created a list with the new install. Here's what happened when I posted a message with a GIF, an HTML part, and a JPEG part (in that order) to the list: [root@nausicaa:/usr/local/mailman/archives/private/test]# ls -l attachments total 16 -rw-rw-rw- 1 qmaild qmail 10404 Oct 26 11:27 attachment-0001.gif -rw-rw-rw- 1 qmaild qmail 29 Oct 26 11:27 attachments.pck [^^^^^^^^ NOTE NOTE NOTE: These arguably should *not* be mode 666. :) ] [root@nausicaa:/usr/local/mailman/archives/private/test]# cat index.html [SNIP]

Currently, there are no archives.

[SNIP] The offending message is at: http://nausicaa.interq.or.jp/pipermail/test.mbox/test.mbox I found the bug; you put in code to ignore all HTML attachments (whether this is a good idea or not is up to you ;) but the code in Scrubber.process() suggests that you started coding in an 'outer' attachment detection, but didn't fully implement it. Here's a patch that actually throws out all-HTML emails, but just removes HTML parts. Actually, why don't we just decode HTML attachments like any other, and let the user beware if they want to click on it? There are lots of legitimate reasons to allow HTML attachments. I can't think of any to allow all-HTML messages. *grin* We could treat all-HTML messages in the same way, just provide a link and let the user beware if they click on it. The patch also adds a filename to the replacement payload, so that users can have an idea of what they're going to see if a description was not provided (VERY common). Finally (and this part of the patch, I'm not quite sure if it's the right solution), we add http://mlist.host_name to the beginning of the URL returned by Scrubber.save_attachment. Why? Because pipermail sees the string "/pipermail/listname/attachments/attachment-0001.gif" and doesn't (of course) realize it's a URL! The patch does not address the mode 666 issue. I don't know where it should be set, but you need to make the umask set to make these files not be readable/writable by others.. Anyway, the output should be cleaned up a bit, but Barry, this is a great leap forward for Mailman's MIME handling! I'll be working on this more later. Thanks a lot! Index: Scrubber.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Scrubber.py,v retrieving revision 2.1 diff -u -r2.1 Scrubber.py --- Scrubber.py 2001/10/25 04:10:23 2.1 +++ Scrubber.py 2001/10/26 03:00:41 @@ -60,7 +60,6 @@ def process(mlist, msg, msgdata=None): - outer = 1 for part in msg.walk(): # If the part is text/plain, we leave it alone if part.get_type('text/plain') == 'text/plain': @@ -70,7 +69,7 @@ # whole message is HTML, just discard the entire thing. Otherwise, # just add an indication that the HTML part was removed. if part.get_type() == 'text/html': - if outer: + if not msg.is_multipart(): raise DiscardMessage part.set_payload(_("An HTML attachment was scrubbed and removed")) # If the message isn't a multipart, then we'll strip it out as an @@ -82,9 +81,11 @@ size = len(payload) url = save_attachment(mlist, part) desc = part.get('content-description', _('not available')) + filename = part.get_filename(_('not available')) part.set_payload(_("""\ A non-text attachment was scrubbed... Type: %(ctype)s +Name: %(filename)s Size: %(size)d bytes Desc: %(desc)s Url : %(url)s @@ -155,5 +156,5 @@ fp.write(decodedpayload) fp.close() # Now calculate the url - url = mlist.GetBaseArchiveURL() + '/attachments/' + file + ext + url = 'http://' + mlist.host_name + mlist.GetBaseArchiveURL() + '/attachments/' + file + ext return url -- Brought to you by the letters W and B and the number 14. "It should be illegal to yell 'Y2K' in a crowded economy." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From bob@nleaudio.com Fri Oct 26 04:12:48 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Thu, 25 Oct 2001 23:12:48 -0400 Subject: [Mailman-Developers] Cookie bug in 2.1a3+ References: <200110260258.TAA12401@utopia.West.Sun.COM> Message-ID: <3BD8D4B0.58CA93B8@nleaudio.com> Hi Dan, Thanks for the quick reply. Hmm, I thought I -just- did update everything from the cvs.. Never used CVS before, but I just executed the commands: cvs -z3 -d:pserver:anonymous@cvs.mailman.sourceforge.net:/cvsroot/mailman co mailman (as root, sitting in my $prefix directory) Did I do wrong? Bob From bob@nleaudio.com Fri Oct 26 04:15:12 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Thu, 25 Oct 2001 23:15:12 -0400 Subject: [Mailman-Developers] Lots of dup Rcv: headers? Message-ID: <3BD8D540.25CBAEBC@nleaudio.com> Ok, here's another oddity. In a 2.1a3 list, it looks like the Received: headers are being duplicated: Received: by main.nlenet.net (mbox bob) (with Cubic Circle's cucipop (v1.31 1998/05/13) Thu Oct 25 22:58:50 2001) X-From_: csc-admin@lists.churchsoundcheck.com Thu Oct 25 22:57:57 2001 Return-Path: Delivered-To: bob@nlenet.net Received: from main.nlenet.net (localhost.localdomain [127.0.0.1]) by main.nlenet.net (Postfix) with ESMTP id 2FE1413D126 for ; Thu, 25 Oct 2001 22:57:57 -0400 (EDT) Delivered-To: csc@nlenet.net Received: from ns.nlenet.net (ns.nlenet.net [208.178.159.66]) by main.nlenet.net (Postfix) with ESMTP id C8DEE13D126 Received: from ns.nlenet.net (ns.nlenet.net [208.178.159.66]) by main.nlenet.net (Postfix) with ESMTP id C8DEE13D126 for ; Thu, 25 Oct 2001 22:57:55 -0400 (EDT) Received: from nleaudio.com (nle-m0.nlenet.net [192.168.2.9]) by ns.nlenet.net (Postfix) with ESMTP id 97B72770C Received: from nleaudio.com (nle-m0.nlenet.net [192.168.2.9]) by ns.nlenet.net (Postfix) with ESMTP id 97B72770C for ; Thu, 25 Oct 2001 22:58:17 -0400 (EDT) Message-ID: <3BD8D39D.CA5D4360@nleaudio.com> Date: Thu, 25 Oct 2001 23:08:13 -0400 From: "Bob Puff@NLE" X-Mailer: Mozilla 4.08 [en] (Win95; I) MIME-Version: 1.0 To: csc@lists.churchsoundcheck.com Subject: Re: [Csc] test message #1 References: <3BD8CD75.DABB8C8C@nleaudio.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: csc-admin@lists.churchsoundcheck.com Errors-To: csc-admin@lists.churchsoundcheck.com X-BeenThere: csc@lists.churchsoundcheck.com X-Mailman-Version: 2.1a3 Precedence: bulk ...etc, etc, etc.. Note that the proper order should be: ns.nlenet.net -> main.nlenet.net. Once. Bob From barry@zope.com Fri Oct 26 04:30:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Oct 2001 23:30:06 -0400 Subject: [Mailman-Developers] Cookie bug in 2.1a3+ References: <3BD8D30F.D72C6753@nleaudio.com> Message-ID: <15320.55486.931509.393555@anthem.wooz.org> >>>>> "B" == Bob writes: B> Just hit this one when I tried to view the private archives: Fixed in CVS. From barry@zope.com Fri Oct 26 05:18:32 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 00:18:32 -0400 Subject: [Mailman-Developers] comments on mailman2.1a3 References: <15320.18411.511153.173440@daimi.au.dk> Message-ID: <15320.58392.468350.969304@anthem.wooz.org> >>>>> "KPC" == Kaja P Christiansen writes: KPC> - after the installation of email package, the test - as KPC> recommended by INSTALL - returns email.__version__ 0.92 (and KPC> not 0.93). Yep, I forgot to update that. Fixed in email-0.94 KPC> - no problems with the compilation (irix6.5) Cool! KPC> - directory permissions were right, except for KPC> ~mailman2/messages and mailman2/templates (no g+w KPC> permission). Hmm, works for me: /usr/local/mailman% ls -ld templates drwxrwsr-x 12 barry mailman 4096 Oct 26 00:05 templates/ /usr/local/mailman% ls -ld messages drwxrwsr-x 10 barry mailman 4096 Oct 26 00:05 messages/ KPC> - loading of the pages seems slow, but it may be a local KPC> problem Hmm, must be. It's pretty zippy for me. KPC> - the only real problem was setting the web page url KPC> correctly. KPC> what happened is that I wanted the test version to use KPC> mailman2.domain as default url. I created a list, KPC> mailman2-test, and everything looked good - messages got KPC> posted and archived - except for the urls in the List-* KPC> headers which said something like: List-Subscribe: KPC> (and KPC> which pointed to another web server) KPC> I tried many things (HOST and URL variables for configure, KPC> DEFAULT_URL and DEFAULT_URL_HOST in mm_cfg.py, and KPC> add_virtualhost hack (which I don't understand)) but nothing KPC> helped. What *did* help was to reread NEWS, find reference to KPC> bin/fix_url.py, and find in it a comment which told me to run KPC> bin/withlist -l -r fix_url :-) Right. The issue is that the values for these to important variables are stored in the list's database so you need to make sure that DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST are set properly in mm_cfg.py before you create your first list. Otherwise, you have to go back and modify those list variables using fix_url.py. I see that the INSTALL file is not clear about this, so I'll fix the documentation. KPC> - loading of the pages seems slow, but it may be a local KPC> problem. Maybe it's trying to load the page twice . KPC> My test setup is at KPC> http://mailman2.daimi.au.dk/mailman/listinfo. I'm using it KPC> for trying out new options etc. You are welcome to use it for KPC> testing as well! Awesome! I plan on releasing an alpha4 tomorrow to fix the nastier of the problems in alpha 3. Thanks for the feedback. -Barry From barry@zope.com Fri Oct 26 05:24:56 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 00:24:56 -0400 Subject: [Mailman-Developers] Re: Mailman and cookies. References: <15312.40637.81391.220441@anthem.wooz.org> <15312.46660.471275.986209@anthem.wooz.org> <20011023171016.A3054@magic.merlins.org> <15319.44671.421643.447153@anthem.wooz.org> <20011025110252.G18096@magic.merlins.org> Message-ID: <15320.58776.835735.380072@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> It seems that it will solve my problem too. Thanks. (I won't MM> be able to tell right away, because I can't reproduce it MM> myself and I only get a report of this every so often, out of MM> thousands of list admins) Cool, let me know how it goes. I really don't want to release a MM2.0.7, and Python 1.5.2 is sooo old that I definitely recommend upgrading (if and when your resources allow you to). What I have done though is uploaded a patch to the SF files page http://sourceforge.net/project/showfiles.php?group_id=103&release_id=45268 that contains the fix for crashes under Python 1.5.2. Once the SF file release delay expires I'll send a message out about this patch on the mailman-* lists. -Barry From barry@zope.com Fri Oct 26 05:27:50 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 00:27:50 -0400 Subject: [Mailman-Developers] mailman 2.0.6 problem References: <3BD8621F.38D0C3ED@isu.edu> Message-ID: <15320.58950.61424.670364@anthem.wooz.org> >>>>> "KW" == Kory Wheatley writes: KW> The web interface works fine, I just can't receive email from KW> the lists, KW> The /var/log/maillog logfile also does not report any errors. KW> Any solutions? Are your aliases set up correctly? Here's a way to start to diagnosis this: - edit your crontab to temporarily disable qrunner - send your list a message If you see the message in qfiles, then you know Sendmail is delivering it to Mailman and the problem lies to the right of that step. If you don't see the message in qfiles, then you've got a problem with Sendmail delivering to the Mailman scripts. -Barry From bob@nleaudio.com Fri Oct 26 05:39:10 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 26 Oct 2001 00:39:10 -0400 Subject: [Mailman-Developers] comments on mailman2.1a3 References: <15320.18411.511153.173440@daimi.au.dk> <15320.58392.468350.969304@anthem.wooz.org> Message-ID: <3BD8E8EE.D61AD0C7@nleaudio.com> Hi Barry, ANother thing you might want to fix in the docs is the order of installation. For example, it tells you how to install mailman, then talks about the postfix MTA thing. I had to go back and ./configure again using the recommendation there. Bob From bob@nleaudio.com Fri Oct 26 06:04:06 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 26 Oct 2001 01:04:06 -0400 Subject: [Mailman-Developers] regexp on body checks Message-ID: <3BD8EEC6.A35AD08D@nleaudio.com> I'm searching through the admin area of 2.1a3, and I can't seem to find where the body checks are done. I remember a recent discussion that 2.1 could look for a string in the body of a message (like the footer of a quoted digest), and reject the message if it matched. Bob From bob@nleaudio.com Fri Oct 26 06:10:20 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 26 Oct 2001 01:10:20 -0400 Subject: [Mailman-Developers] Uh oh, import error on ArchiverMailbox with 2.1a3 Message-ID: <3BD8F03C.F8C613A7@nleaudio.com> This just came on my screen: Traceback (most recent call last): File "/home/csc/mailman/Mailman/Archiver/Archiver.py", line 181, in ArchiveMail import HyperArch File "/home/csc/mailman/Mailman/Archiver/HyperArch.py", line 41, in ? import HyperDatabase File "/home/csc/mailman/Mailman/Archiver/HyperDatabase.py", line 30, in ? import pipermail File "/home/csc/mailman/Mailman/Archiver/pipermail.py", line 18, in ? from Mailman.Mailbox import ArchiverMailbox ImportError: cannot import name ArchiverMailbox From barry@zope.com Fri Oct 26 06:21:27 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 01:21:27 -0400 Subject: [Mailman-Developers] comments on mailman2.1a3 References: <15320.18411.511153.173440@daimi.au.dk> <15320.58392.468350.969304@anthem.wooz.org> <3BD8E8EE.D61AD0C7@nleaudio.com> Message-ID: <15320.62167.681370.823913@anthem.wooz.org> >>>>> "B" == Bob writes: B> ANother thing you might want to fix in the docs is the order of B> installation. B> For example, it tells you how to install mailman, then talks B> about the postfix MTA thing. I had to go back and ./configure B> again using the recommendation there. Will do, thanks! From barry@zope.com Fri Oct 26 06:24:41 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 01:24:41 -0400 Subject: [Mailman-Developers] Uh oh, import error on ArchiverMailbox with 2.1a3 References: <3BD8F03C.F8C613A7@nleaudio.com> Message-ID: <15320.62361.811493.357725@anthem.wooz.org> >>>>> "B" == Bob writes: B> ImportError: cannot import name ArchiverMailbox Isn't that class in your Mailman/Mailbox.py file? -Barry From bob@nleaudio.com Fri Oct 26 06:41:32 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 26 Oct 2001 01:41:32 -0400 Subject: [Mailman-Developers] Uh oh, import error on ArchiverMailbox with 2.1a3 References: <3BD8F03C.F8C613A7@nleaudio.com> <15320.62361.811493.357725@anthem.wooz.org> Message-ID: <3BD8F78C.675E248B@nleaudio.com> Barry A. Warsaw wrote: > > >>>>> "B" == Bob writes: > > B> ImportError: cannot import name ArchiverMailbox > > Isn't that class in your Mailman/Mailbox.py file? Looking at Mailbox.py now - yup, seems to be in there. Here's a little more info: Any more messages I post no longer get added to the archive, but generate the following error ON THE CONSOLE: Traceback (most recent call last): File "/home/csc/mailman/Mailman/Archiver/Archiver.py", line 182, in ArchiveMail h = HyperArch.HyperArchive(self) AttributeError: 'Mailman.Archiver.HyperArch' module has no attribute 'HyperArchive' Taking a look at log/errors, all I see is: Oct 26 01:14:10 2001 (32744) CORRUPT ARCHIVE FOR LIST: csc This is a brand new list, only a couple messages. I have done a little tweaking of the headers, and some internal text, but nothing that I haven't done in 2.0.6.. Just diff'd those files to make sure I didn't make any typos. Bob From dgc@uchicago.edu Fri Oct 26 06:34:53 2001 From: dgc@uchicago.edu (David Champion) Date: Fri, 26 Oct 2001 00:34:53 -0500 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <87vgh3ayv3.fsf@nausicaa.interq.or.jp> References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> Message-ID: <20011026003453.E20563@dust.uchicago.edu> On 2001.10.25, in <87vgh3ayv3.fsf@nausicaa.interq.or.jp>, "Ben Gertzfield" wrote: > > Here's a patch that actually throws out all-HTML emails, but just > removes HTML parts. > > Actually, why don't we just decode HTML attachments like any other, > and let the user beware if they want to click on it? There are lots > of legitimate reasons to allow HTML attachments. I can't think of any > to allow all-HTML messages. *grin* We could treat all-HTML messages in > the same way, just provide a link and let the user beware if they > click on it. Unfortunately, I think there are legitimate reasons for allowing HTML messages (as well as parts) into the record. But I don't think that legitimizes passing the HTML through literally -- this poses a big potential threat to archive viewers. I don't care to make a full-blown rendering of HTML; I'd argue that it's not Mailman's job -- but it is Mailman's job (or, more precisely, the archiver's job) to provide any text available to the archive viewer. Whether its display is true to the intentions of the poster is subject to endless debate, but HTML is widely expected to be legible even if it's not rendered per specification -- and it almost always is, if you try hard enough -- so I think that the content should be available. I suggested transliterating the HTML with < and > tokens, to make it harmless but legible, in case there's significant text inside. But, admittedly, that is pretty ugly. What about simply stripping out ALL markup, leaving only bare text -- and perhaps doing some minor interpretation for
and

tags, just to improve readability? Then throw in a link to the original, as Ben suggests, for good measure. > The patch also adds a filename to the replacement payload, so that > users can have an idea of what they're going to see if a description > was not provided (VERY common). Ah, filenames. I'd actually like to see the filename stored on the server as requested in the MIME content-disposition. I don't think the archiver needs to guarantee literalism here; a good-faith effort is sufficient. But I think it's significant in many cases, where the transmission filename is really how the file needs to be saved locally. Minimally I'd like the filename to be shown on the archive display, but it'd be nice if I don't need to change the filename in my browser's "save as..." dialog each time I save an attachment. I'd suggest a very basic sanitizing of the basename of the MIME filename. Something like s!.*[:/\\]!! to remove pathname components for all three major pathname separators, and then (optionally) to either hex-encode the non-alphanumeric symbols, a la HTML, or to replace them with some other token. -- -D. dgc@uchicago.edu NSIT University of Chicago From barry@zope.com Fri Oct 26 06:35:49 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 01:35:49 -0400 Subject: [Mailman-Developers] Uh oh, import error on ArchiverMailbox with 2.1a3 References: <3BD8F03C.F8C613A7@nleaudio.com> <15320.62361.811493.357725@anthem.wooz.org> <3BD8F78C.675E248B@nleaudio.com> Message-ID: <15320.63029.23746.795987@anthem.wooz.org> >>>>> "B" == Bob writes: B> Oct 26 01:14:10 2001 (32744) CORRUPT ARCHIVE FOR LIST: csc You'll get those error messages when an uncaught exception happens during archiving. It generally means you need to re-run bin/arch because the incremental archiver missed some messages. But... B> This is a brand new list, only a couple messages. I have done B> a little tweaking of the headers, and some internal text, but B> nothing that I haven't done in 2.0.6.. Just diff'd those files B> to make sure I didn't make any typos. ...something seems really whacked about your install! I'm definitely sending bunches of messages to test lists and they are getting archived correctly. How could your modules be losing those attributes? Try re-installing. (Are you sure you're not having hardware problems that are corrupting your .pyc's?) -Barry From tkikuchi@is.kochi-u.ac.jp Fri Oct 26 08:58:09 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 26 Oct 2001 16:58:09 +0900 Subject: [Mailman-Developers] another patch Message-ID: <3BD91791.D954BE5D@is.kochi-u.ac.jp> Hi, handle_opts.html no longer exists, I guess. Barry, I hope you can care other patches I have posted before; http://mail.python.org/pipermail/mailman-developers/2001-October/009832.html http://mail.python.org/pipermail/mailman-developers/2001-October/009655.html Tokio -------- Original Message -------- Date: Fri, 26 Oct 2001 16:52:36 +0900 (JST) From: Mailman Admin To: tkikuchi@is.kochi-u.ac.jp --- edithtml.py.orig Wed Jul 11 23:45:09 2001 +++ edithtml.py Fri Oct 26 16:51:45 2001 @@ -42,7 +42,6 @@ ('listinfo.html', _('General list information page')), ('subscribe.html', _('Subscribe results page')), ('options.html', _('User specific options page')), - ('handle_opts.html', _('Changing user options results page')), ) _ = i18n._ From che@debian.org Fri Oct 26 09:12:34 2001 From: che@debian.org (Ben Gertzfield) Date: Fri, 26 Oct 2001 17:12:34 +0900 Subject: [Mailman-Developers] MIME-encoding headers/body for Mailman-generated mails Message-ID: <87lmhybz0t.fsf@nausicaa.interq.or.jp> To finish up the Japanese support for Mailman, I'm going to dive in and start by adding support for MIME-encoding and decoding (either quoted-printable or base64, whichever is appropriate) header lines. Right now, no matter what language is enabled, the localized emails sent out through the virgin queue are sent verbatim. We need to: 1) Encode the message (headers and body) with the encoding that locale uses for email. Needed for EUC-JP to iso-2022-jp. Can be used for Big5 and CN to iso-2022-cn (see http://www.imc.org/rfc1922) but I don't know if any Chinese mail readers actually support iso-2022-cn. 2) MIME-encode the Subject field, specifying the character set appropriate for the list's locale. Use quoted-printable for ASCII-like charsets, base64 for non-ASCII-like charsets. 3) Set the charset in the Content-Type: of the mail, again appropriate for the list's locale. 4) (sometimes) MIME-encode the body with base64, for 8-bit character sets. In a perfect world, all email would be 7-bit, but going by the Taiwanese spam I receive, people don't seem to send Chinese mail in iso-2022-cn. Instead, the common thing to do seems to be sending 8-bit Big5 mail that's base64 encoded (or not! I get 8-bit email directly in Big5 from time to time in my spam folder.) I looked at the email and mimify modules, and neither of them expose a proper interface for MIME-encoding headers. Well, mimify *tries*, really it does, but it forces quoted-printable, which makes no sense for Asian languages, and does line-wrapping incorrectly, a HUGELY important issue with double-byte encodings that will become corrupt if they're line-wrapped in between two bytes of a double-byte character. I think the proper place for this is in the email module, but I don't want to re-invent the wheel. (Though I do understand the issue very well, and have written up code to do this by-hand before, including supporting double-byte charsets properly). Can we get the code from somewhere else, or should I write up encode_header and decode_header methods for the email.Message class? Next, we need to come up with a table mapping languages to the encodings they use for email. Right now, these are the encodings used for our supported languages (from Defaults.py): def add_language(code, description, charset): LC_DESCRIPTIONS[code] = (description, charset) add_language('big5', _('Traditional Chinese'), 'big5') add_language('de', _('German'), 'iso-8859-1') add_language('en', _('English (USA)'), 'us-ascii') add_language('es', _('Spanish (Spain)'), 'iso-8859-1') add_language('fr', _('French'), 'iso-8859-1') add_language('gb', _('Simplified Chinese'), 'gb2312') add_language('hu', _('Hungarian'), 'iso-8859-1') add_language('it', _('Italian'), 'iso-8859-1') add_language('ja', _('Japanese'), 'euc-jp') add_language('no', _('Norwegian'), 'iso-8859-1') add_language('ru', _('Russian'), 'koi8-r') We need another mapping, from 'code' to 'email charset conversion', 'header mime method', and 'body mime method'. (The last one may not be necessary, if we are converting to a 7-bit encoding.) This is what I understand is actually supported by email clients people around the world use, but I could be very wrong. email_charsets = { # code mail conv header enc body enc 'big5': [None, 'base64', 'base64'], 'de': [None, 'qp', 'qp'], 'en': [None, None, None], 'es': [None, 'qp', 'qp'], 'fr': [None, 'qp', 'qp'], 'gb': [None, 'base64', 'base64'], # just a guess! use iso-2022-cn? 'hu': [None, 'qp', 'qp'], # I thought Hungarian was iso-8859-2? 'it': [None, 'qp', 'qp'], 'ja': ['iso-2022-jp', 'base64', None], 'no': [None, 'qp', 'qp'], 'ru': [None, 'base64', None], # I assume koi8-r is 7-bit.. } I was surprised to see that we specify iso-8859-1 for Hungarian; I'm pretty sure sure it uses accented vowels that are only in iso-8859-2. Also, I don't know if people actually use iso-2022-cn in the Real World. The RFCs suggest to use it, but I get the feeling it's not actually supported by Chinese email clients. Anyone know? If we can use it, then we should for both big5 and gb. In any case, there's a wonderful Python 2.0 codec module which I'm testing now, that makes it possible to convert to/from Japanese. I am VERY unhappy with the historically used kconv.py module, which has thrown tracebacks at me whenever it sees encodings it doesn't understand. It should be good for our purposes; we could just ship it in 'misc' for folks who need Japanese. http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/ Ben -- Brought to you by the letters R and Y and the number 9. "Hoosh is a kind of soup." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Fri Oct 26 09:17:30 2001 From: che@debian.org (Ben Gertzfield) Date: Fri, 26 Oct 2001 17:17:30 +0900 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <20011026003453.E20563@dust.uchicago.edu> (David Champion's message of "Fri, 26 Oct 2001 00:34:53 -0500") References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> <20011026003453.E20563@dust.uchicago.edu> Message-ID: <87hesmbysl.fsf@nausicaa.interq.or.jp> >>>>> "David" == David Champion writes: David> Unfortunately, I think there are legitimate reasons for David> allowing HTML messages (as well as parts) into the David> record. But I don't think that legitimizes passing the HTML David> through literally -- this poses a big potential threat to David> archive viewers. Sure. Make it an option, then! I suggest decoding and saving HTML messages and attachments, and making them clickable links, so users are only subjected to their horrors if they click on them. David> Ah, filenames. I'd actually like to see the filename stored David> on the server as requested in the MIME David> content-disposition. Sure, but duplicates will come in quite quickly; it will be pretty useless as soon as 40 people send in "map.gif", don't you think? We'd have to do filename munging in any case, and that's sticky. What do you suggest, prefix the filename with a number if the original filename is taken? 01-map.gif Ben -- Brought to you by the letters M and E and the number 16. "Johnny! Don't go! It's too dangerous!" "I don't care!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From dgc@uchicago.edu Fri Oct 26 09:25:56 2001 From: dgc@uchicago.edu (David Champion) Date: Fri, 26 Oct 2001 03:25:56 -0500 Subject: [Mailman-Developers] Re: New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <87hesmbysl.fsf@nausicaa.interq.or.jp> References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> <20011026003453.E20563@dust.uchicago.edu> <87hesmbysl.fsf@nausicaa.interq.or.jp> Message-ID: <20011026032556.F20563@dust.uchicago.edu> On 2001.10.26, in <87hesmbysl.fsf@nausicaa.interq.or.jp>, "Ben Gertzfield" wrote: > > Sure, but duplicates will come in quite quickly; it will be pretty > useless as soon as 40 people send in "map.gif", don't you think? We'd > have to do filename munging in any case, and that's sticky. What do > you suggest, prefix the filename with a number if the original filename > is taken? Oh, I forgot to mention that part: make a subdirectory of the attachments/ directory, whose name is unique and preferably based on some characteristic of the message (message-id, sequence number, etc.) combined with something unlikely to repeat (a hash, a sequence number, etc.). All that message's attachments would go in there. That might be desirable anyway -- do you suppose a list might see enough attachments and enough activity that all the attachments make readdirs on the attachments/ directory uncomfortably slow? -- -D. dgc@uchicago.edu NSIT University of Chicago From Dale Newfield Fri Oct 26 09:32:51 2001 From: Dale Newfield (Dale Newfield) Date: Fri, 26 Oct 2001 04:32:51 -0400 (EDT) Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <87hesmbysl.fsf@nausicaa.interq.or.jp> Message-ID: On Fri, 26 Oct 2001, Ben Gertzfield wrote: > David> Ah, filenames. I'd actually like to see the filename stored > David> on the server as requested in the MIME > David> content-disposition. > > Sure, but duplicates will come in quite quickly; it will be pretty > useless as soon as 40 people send in "map.gif", don't you think? We'd > have to do filename munging in any case, and that's sticky. What do > you suggest, prefix the filename with a number if the original filename > is taken? > > 01-map.gif How 'bout if there's a directory created for each message that has separate files, and the files are placed inside that directory? -Dale From che@debian.org Fri Oct 26 09:54:33 2001 From: che@debian.org (Ben Gertzfield) Date: Fri, 26 Oct 2001 17:54:33 +0900 Subject: [Mailman-Developers] Re: New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <20011026032556.F20563@dust.uchicago.edu> (David Champion's message of "Fri, 26 Oct 2001 03:25:56 -0500") References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> <20011026003453.E20563@dust.uchicago.edu> <87hesmbysl.fsf@nausicaa.interq.or.jp> <20011026032556.F20563@dust.uchicago.edu> Message-ID: <871yjqaiie.fsf@nausicaa.interq.or.jp> >>>>> "David" == David Champion writes: David> Oh, I forgot to mention that part: make a subdirectory of David> the attachments/ directory, whose name is unique and David> preferably based on some characteristic of the message David> (message-id, sequence number, etc.) combined with David> something unlikely to repeat (a hash, a sequence number, David> etc.). Hm.. It'd need more testing. Either that or *some* kind of hashing based on the message-id will be necessary on any list with a good amount of traffic with attachments. But yes, that's a good idea and we should test it. Ben -- Brought to you by the letters N and L and the number 3. "It should be illegal to yell 'Y2K' in a crowded economy." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From mikhail.sobolev@transas.com Fri Oct 26 10:26:26 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Fri, 26 Oct 2001 10:26:26 +0100 Subject: [Mailman-Developers] MIME-encoding headers/body for Mailman-generated mails In-Reply-To: <87lmhybz0t.fsf@nausicaa.interq.or.jp> References: <87lmhybz0t.fsf@nausicaa.interq.or.jp> Message-ID: <20011026102626.A924@transas.co.uk> On Fri, Oct 26, 2001 at 05:12:34PM +0900, Ben Gertzfield wrote: > 'ru': [None, 'base64', None], # I assume koi8-r is 7-bit.. No. It's not. -- Misha From jra@baylink.com Fri Oct 26 15:56:59 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 26 Oct 2001 10:56:59 -0400 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <20011026003453.E20563@dust.uchicago.edu>; from David Champion on Fri, Oct 26, 2001 at 12:34:53AM -0500 References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> <20011026003453.E20563@dust.uchicago.edu> Message-ID: <20011026105659.39327@scfn.thpl.lib.fl.us> On Fri, Oct 26, 2001 at 12:34:53AM -0500, David Champion wrote: > I don't care to make a full-blown rendering of HTML; I'd argue that it's > not Mailman's job -- but it is Mailman's job (or, more precisely, the > archiver's job) to provide any text available to the archive viewer. > Whether its display is true to the intentions of the poster is subject > to endless debate, but HTML is widely expected to be legible even if > it's not rendered per specification -- and it almost always is, if you > try hard enough -- so I think that the content should be available. You might shell out to Lynx; I believe it has enough switches to render the HTML into ASCII and be restrained from doing anything nasty. You'd then depend on Lynx, of course, but that doesn't seem too hasslacious. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 "Usenet: it's enough to make you loose your mind." -- me From jerry@sandiego.edu Fri Oct 26 16:32:29 2001 From: jerry@sandiego.edu (Jerry Stratton) Date: Fri, 26 Oct 2001 08:32:29 -0700 Subject: [Mailman-Developers] Using pre-existing passwords along with mailman passwords? Message-ID: I posted this to the users group, and they suggested I post it here; I've looked into what might need to be done, and it looks like it will be a lot easier for list members than for list administrators; since list members have 'usernames' (their e-mail address), but list administrators just have their password? Is there a best place to apply such a patch? At our University, we use a special username/password (called a "UNet" account) for all web-related items. We can match the UNet username directly to the user's University e-mail address. I would like to use this username/password for all list members and list owners who have a UNet account, but fall through to the mailman-generated password for those who do not. We do not have access to the actual password--it is stored only as a Unix hash so we can't simply insert it into the mailman password database (and we wouldn't want to send it out via e-mail on a monthly basis in any case). Has anyone else implemented something like this? What I'm looking at as a possibility is setting up an Apache =2Ehtaccess file so that all of the mailman directories are password protected, but allow guest access (Apache has a special module that will do this). If a user logs in using their UNet account, map it to their e-mail address and bypass mailman's login process. If the user logs in as a guest, do not bypass mailman's login process. Has anyone already done this? If so, are there already any instructions somewhere for how to do this? Any foreseeable problems with this method? Jerry -- jerry@sandiego.edu http://www.sandiego.edu/~jerry/ -- The more restrictions there are, the poorer the people become. The greater the government=B9s power, the more chaotic the nation would become. The more the ruler imposes laws and prohibitions on his people, the more frequently evil deeds would occur. --The Silence of the Wise: The Sayings of Lao Zi From che@debian.org Fri Oct 26 16:51:52 2001 From: che@debian.org (Ben Gertzfield) Date: Sat, 27 Oct 2001 00:51:52 +0900 Subject: [Mailman-Developers] MIME-encoding headers/body for Mailman-generated mails In-Reply-To: <20011026102626.A924@transas.co.uk> (Mikhail Sobolev's message of "Fri, 26 Oct 2001 10:26:26 +0100") References: <87lmhybz0t.fsf@nausicaa.interq.or.jp> <20011026102626.A924@transas.co.uk> Message-ID: <87elnq2ycn.fsf@nausicaa.interq.or.jp> >>>>> "Mikhail" == Mikhail Sobolev writes: Ben> 'ru': [None, 'base64', None], # I assume koi8-r is 7-bit.. Mikhail> No. It's not. Thanks for the correction. Then do people send koi8-r mails with base64 encoding? How do Russian folks usually send email in 7 bits? I did some searching for FAQs on Google, but they're hard to find. Ben -- Brought to you by the letters C and F and the number 0. "I wanna be Twist Barbie!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From barry@zope.com Fri Oct 26 22:22:07 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 17:22:07 -0400 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> Message-ID: <15321.54271.401353.127092@anthem.wooz.org> Folks, Thanks for the really great feedback. I'm about to check in a new version of Scrubber.py that addresses the many issues brought up. Apologies for not quoting everything. - permission problems: fixed - problems with multipart/mixed containing gif, html, and jpeg parts: fixed. - text/html decoding: there's now a new global variable ARCHIVE_HTML_SANITIZER which can be 0, 1, or a string. # This variable defines what happens to text/html subparts. They can be # stripped completely, escaped, or filtered through an external program. The # legal values are: # 0 - Strip out text/html parts completely, leaving a notice of the removal in # the message. If the outer part is text/html, the entire message is # discarded. # 1 - Remove any embedded text/html parts, leaving them as HTML-escaped # attachments which can be separately viewed. Outer text/html parts are # simply HTML-escaped. # # The value can also be a string, in which case it is the name of a command to # filter the HTML page through. The resulting output is left in an attachment # or as the entirety of the message when the outer part is text/html. The # format of the string must include a "%(filename)s" which will contain the # name of the temporary file that the program should operate on. It should # write the processed message to stdout. ARCHIVE_HTML_SANITIZER = '/usr/bin/lynx -dump %(filename)s' This seems to work pretty well (will provide examples shortly). As with the rest of Scrubber, it's a bit of a kludge, but perhaps not horrible. It could definitely use more testing by you guys. It's actually rather difficult to get Pipermail to /not/ HTML-escape attachments, so I'm punting on that for now. Plus, I just feel it's way too dangerous to support. - storing in get_filename() if available: fixed, and I've also implemented the idea of sticking each message's attachments in a separate subdir off of archives/private/mylist/attachments. The subdir is based on the Message-ID: and files inside there are uniquified if necessary. - problems with the attachment url: what we really needed was a more elaborate PUBLIC_ARCHIVE_URL format string. It now accepts %(hostname)s as well as %(listname)s, and the former gets interpolated with the list's web host name (as looked up in the inverted VIRTUAL_HOSTS dictionary, and defaulting to DEFAULT_URL_HOST). Watch for checkins shortly. -Barry From barry@zope.com Fri Oct 26 23:08:01 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 18:08:01 -0400 Subject: [Mailman-Developers] Lots of dup Rcv: headers? References: <3BD8D540.25CBAEBC@nleaudio.com> Message-ID: <15321.57025.98793.977004@anthem.wooz.org> >>>>> "B" == Bob writes: B> Ok, here's another oddity. In a 2.1a3 list, it looks like the B> Received: headers are being duplicated: You need to upgrade to email-0.94. -Barry From barry@zope.com Fri Oct 26 23:09:50 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 18:09:50 -0400 Subject: [Mailman-Developers] regexp on body checks References: <3BD8EEC6.A35AD08D@nleaudio.com> Message-ID: <15321.57134.906953.303106@anthem.wooz.org> >>>>> "B" == Bob writes: B> I'm searching through the admin area of 2.1a3, and I can't seem B> to find where the body checks are done. I remember a recent B> discussion that 2.1 could look for a string in the body of a B> message (like the footer of a quoted digest), and reject the B> message if it matched. Sort of. Actually SpamDetect would be the module to do this, but 1) its not configurable through the web, and 2) body searching didn't work so I took it out. We could add it back, but of course the more regexp searches you perform /on each message/ the slower delivery throughput is going to be. -Barry From barry@zope.com Fri Oct 26 23:40:37 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 18:40:37 -0400 Subject: [Mailman-Developers] another patch References: <3BD91791.D954BE5D@is.kochi-u.ac.jp> Message-ID: <15321.58981.871387.719242@anthem.wooz.org> >>>>> "TK" == Tokio Kikuchi writes: TK> handle_opts.html no longer exists, I guess. I think I got them all now, thanks. Please double check the changes to HyperArch.py. I'm (very slowly) moving it to use the email package interface. -Barry From barry@zope.com Fri Oct 26 23:54:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 18:54:17 -0400 Subject: [Mailman-Developers] Using pre-existing passwords along with mailman passwords? References: Message-ID: <15321.59801.979621.285711@anthem.wooz.org> >>>>> "JS" == Jerry Stratton writes: JS> I posted this to the users group, and they suggested I post it JS> here; I've looked into what might need to be done, and it JS> looks like it will be a lot easier for list members than for JS> list administrators; since list members have 'usernames' JS> (their e-mail address), but list administrators just have JS> their password? Correct. JS> Is there a best place to apply such a patch? Assuming Mailman 2.1, there are a couple of places you can hook in. For users, it should be easy: implement your own version of the MemberAdaptor.py interface (see OldStyleMemberships.py for the currently only living example). See also SecurityManager.py List owners are harder because they are identified only by knowledge of a password. Yes this is bogus, and yes it will change, but not for MM2.1. -Barry From barry@zope.com Sat Oct 27 00:03:53 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 19:03:53 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Old Question, New Twist References: <5.1.0.14.0.20011025042807.03f6db38@mail.wombatsweb.com> <20011026132757.B5893@anne.coxcentral.com> Message-ID: <15321.60377.63370.271850@anthem.wooz.org> [Cc: changed to mailman-developers -BAW] >>>>> "PC" == Paul Cox writes: PC> I'm that one that's done the last couple of Mandrake .rpm's PC> for Mandrake. Let me help you out. Maybe we should coordinate to make things easier (or more visible) for RPMs. I definitely don't have the time to support them, and am very glad that you do, but maybe we can make things easier. >> My problem is the age old: Failure to exec script. WANTED gid >> 99, GOT gid 12. (Reconfigure to take 12?) 554 5.3.0 unknown >> mailer error 2 PC> The reason for this is easy. Since Mandrake installs the PC> Postfix MTA by default (you have to go out of your way to use PC> sendmail instead), that's how the .rpm configures Mailman PC> during the build. Postfix delivers mail as gid nobody (99), PC> while sendmail delivers mail as gid 12 (mail). Unfortnately, PC> you can't build an .rpm for both ways. Since Postfix is the PC> default (and recommended) MTA, that's the one I went with. I've been thinking in the background about how to make the compiled in gid a run-time option. I've always considered it difficult and unsafe to do, but here's an idea: What if the mail and cgi wrappers took an optional argument (say -g) on the command line to specify the gid it looked for. No -g and it falls back to the compiled value. We'd have to #ifdef this feature though, and the default would be to disable it, because I believe it would allow untrusted users to defeat this test fairly easily. That might be too big a security hole. On second thought, maybe we allow ifdef'ing out the gid check altogether? On third thought, we could try to put the gid out of a config file, but it's such a pain to handle this in pure-C that I've avoided doing it. Maybe we need to bite the bullet? The other issue here is that by keeping the wrappers as small as possible, we can feel better about their security. The more complexity we introduce, the more exploits we potentially open up. Thoughts? -Barry From marc_news@valinux.com Sat Oct 27 01:59:17 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Fri, 26 Oct 2001 17:59:17 -0700 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <15319.39330.152220.376629@anthem.wooz.org>; from barry@zope.com on Thu, Oct 25, 2001 at 12:48:34AM -0400 References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> Message-ID: <20011026175916.N12632@magic.merlins.org> On Thu, Oct 25, 2001 at 12:48:34AM -0400, Barry A. Warsaw wrote: > Included in this description is a url to the attachment file, which > Pipermail will hyperlink. One drawback here is that if archives are > switched from public to private, or vice versa, all the attachment > urls will break. But you could re-run bin/arch to regenerate the > whole thing -- the key being that Scrubber works only on a copy of > the message being prepped for the archiver, /not/ on the message > being saved in the mbox. I have a solution to this: Reference the private URL. Have the private cgi issue a redirect to the public archive URL if it detects that the list has public archives (after parsing config.db) Your ideas about de-miming and referencing attachments stored on the server are perfect. This will solve many problems I've had and seen. Thanks Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Sat Oct 27 02:12:20 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Fri, 26 Oct 2001 18:12:20 -0700 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: ; from Dale@Newfield.org on Fri, Oct 26, 2001 at 04:32:51AM -0400 References: <87hesmbysl.fsf@nausicaa.interq.or.jp> Message-ID: <20011026181219.O12632@magic.merlins.org> On Fri, Oct 26, 2001 at 04:32:51AM -0400, Dale Newfield wrote: > How 'bout if there's a directory created for each message that has > separate files, and the files are placed inside that directory? Just for the record, Sourceforge just hit the 16,000 lists limit today and broke because ext2fs doesn't support more than 32,000 links to a directory (archives/private had 32,000 archive dirs) I'm told freebsd's UFS has similar problems. Of course, that can be fixed with Residerfs/XFS/name your FS here or archives/private/l/li/listname{,.mbox} but my point was that if you create a directory for each attachment, you're going to hit the 32,000 limit very quickly. As far as I know, most FS don't handle hundreds of thousands of files in the same dir very well, but at least they handle it. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From che@debian.org Sat Oct 27 02:35:20 2001 From: che@debian.org (Ben Gertzfield) Date: Sat, 27 Oct 2001 10:35:20 +0900 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) In-Reply-To: <15321.54271.401353.127092@anthem.wooz.org> (barry@zope.com's message of "Fri, 26 Oct 2001 17:22:07 -0400") References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> <15321.54271.401353.127092@anthem.wooz.org> Message-ID: <874rol27c7.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> - text/html decoding: there's now a new global variable BAW> ARCHIVE_HTML_SANITIZER which can be 0, 1, or a string. BAW> ARCHIVE_HTML_SANITIZER = '/usr/bin/lynx -dump %(filename)s' This is fine, but it's not going to be default, right? I think it should definitely be set to 1 by default. That way, no information is lost. Does it save the payload if the entire message is text/html? Ben -- Brought to you by the letters Z and A and the number 3. "Hoosh is a kind of soup." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From barry@zope.com Sat Oct 27 03:43:54 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 22:43:54 -0400 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) References: <87hesmbysl.fsf@nausicaa.interq.or.jp> <20011026181219.O12632@magic.merlins.org> Message-ID: <15322.8042.967043.536680@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Just for the record, Sourceforge just hit the 16,000 lists MM> limit today and broke because ext2fs doesn't support more than MM> 32,000 links to a directory (archives/private had 32,000 MM> archive dirs) I'm told freebsd's UFS has similar problems. Wow, neat! Not for you, but neat. :) MM> Of course, that can be fixed with Residerfs/XFS/name your FS MM> here or archives/private/l/li/listname{,.mbox} but my point MM> was that if you create a directory for each attachment, you're MM> going to hit the 32,000 limit very quickly. Ah, so /that's/ why we have /home/groups/m/ma/mailman... :) MM> As far as I know, most FS don't handle hundreds of thousands MM> of files in the same dir very well, but at least they handle MM> it. Don't worry, we're not talking about a directory for each attachment, but a directory for each message with an attachment. Hmm, maybe we /should/ worry! 32k messages with attachments sure doesn't seem all that many. Hmm, have to think about it. -Barry From barry@zope.com Sat Oct 27 04:18:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 26 Oct 2001 23:18:06 -0400 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) References: <200110222004.NAA15539@utopia.West.Sun.COM> <15316.33105.159361.262753@anthem.wooz.org> <20011022230153.A30637@publinet.it> <15318.26849.115454.293921@anthem.wooz.org> <15319.39330.152220.376629@anthem.wooz.org> <87vgh3ayv3.fsf@nausicaa.interq.or.jp> <15321.54271.401353.127092@anthem.wooz.org> <874rol27c7.fsf@nausicaa.interq.or.jp> Message-ID: <15322.10094.101557.49654@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> This is fine, but it's not going to be default, right? I BG> think it should definitely be set to 1 by default. That way, BG> no information is lost. Does it save the payload if the BG> entire message is text/html? I realize we need 3 default values: 0 - discard 1 - an html-escaped attachment 2 - an html-escaped inline Unfortunately, #1 and #2 won't escape them the same way. Pipermail's doing #2 and Scrubber's doing #1. Pipermail actually does a better job here, but I've improved Scrubber's default escaping. Still looks ugly as sin to me, so I'd probably just set it to 0 for my lists, but there you have it. 1 will be the default. -Barry From barry@zope.com Sat Oct 27 05:08:57 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 27 Oct 2001 00:08:57 -0400 Subject: [Mailman-Developers] how to get the latest .po file to translate? References: <20011022194727.F26909@orwell.bok.net> <15316.38415.48205.993265@localhost.localdomain> Message-ID: <15322.13145.29554.335324@anthem.wooz.org> >>>>> "OW" == Ousmane Wilane writes: OW> The french catalog is maintained by me, and an up-to-date OW> version was sent to Barry while he was busy with Python, I OW> don't know where did it went but never in cvs tree... Perhaps OW> I did something wrong! Anyway, the last up-to-date catalog OW> will be sent to Barry again. Sorry If I did something wrong OW> that makes the catalog > /dev/null. I will update the new OW> catalog as soon as I can and send it. BTW, the lack of an update was entirely my fault. Ousmane sent me his updates but I was slammed with getting Python 2.2b1 out. I believe (hope!) I've now committed his latest French catalog and README.fr file. Cheers, -Barry From bob@nleaudio.com Sat Oct 27 06:19:29 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Sat, 27 Oct 2001 01:19:29 -0400 Subject: [Mailman-Developers] how to get the latest .po file to translate? References: <20011022194727.F26909@orwell.bok.net> <15316.38415.48205.993265@localhost.localdomain> <15322.13145.29554.335324@anthem.wooz.org> Message-ID: <3BDA43E1.3227168@nleaudio.com> Hi Gang, When changing the URL from http://dom.ain/mailman/ to http://dom.ain/other/ for ALL web-based interaction with Mailman, can this be done simply by adding this into mm_cfg: DEFAULT_URL_PATTERN = 'http://%s/other/' ??? For 2.1?? Bob From a.k.heath@shu.ac.uk Sat Oct 27 09:27:15 2001 From: a.k.heath@shu.ac.uk (Andy Heath) Date: Sat, 27 Oct 2001 09:27:15 +0100 Subject: [Mailman-Developers] advice on external hooks and multi-list member sets Message-ID: <3BDA6FE3.DA5C2818@shu.ac.uk> Hi, two areas I'd appreciate suggestions on how to *best* handle: They are specific but there are general issues hiding behind them. 1. Currently running 2.0.6. I need to plug external code into subscription/usubscription handling, for example so as to be able to call my own non-mailman code when a subscription happens. Where is the best place to do this ? I've been looking at ApprovedAddMembers but without detailed knowledge of the (soft) architecture I'm not completely certain that this is the best place. I need to pass to external code the approved id and password - how would I do this ? 2. Lists with shared member sets. People are going to wonder why I would want this. The reason is for interfacing with external software systems - I'm using my lists membership for access control in web applications (for example, only list members can access this part of the web). There are interesting things one might want to do such as having lists with mailouts disabled, just for membership control or using different lists (separate configurations but common or overlapping membership sets) for different purposes where web events are sent to lists and vice-versa. Easy question - is there an easy way to have two lists with *one* membership set (an obvious unix way to implement this would be a common file with links to it from two places - ok, its not relational database). Harder questions follow. Harder, more general questions. These considerations raise more general ones about external hooks and interoperability. I'm thoroughly in approval of the do-one-thing-well philosophy. Part of doing one thing well is about providing ways to interface that increase the number of contexts in which something can be used. Is there a need here for some general ways to interface with events within mailman ? Changing internal code may not be the best way because it will lock me in to that version. That suggests an API, which wouldn't quite solve my problem though. Is there a need to split out the membership system so as to allow other ways to handle membership (such as LDAP for example) or allow multiple ways to authenticate etc. ? andy From midnight@the-oasis.net Sat Oct 27 14:21:28 2001 From: midnight@the-oasis.net (Phil Barnett) Date: Sat, 27 Oct 2001 09:21:28 -0400 Subject: [Mailman-Developers] html tags in subject Message-ID: Barry, have you done something about people putting html tags in the subject? I have seen them really mess up the look of pipermail. From Oliver.Egginger@dvz.fh-giessen.de Sat Oct 27 19:18:41 2001 From: Oliver.Egginger@dvz.fh-giessen.de (Oliver Egginger) Date: Sat, 27 Oct 2001 18:18:41 +0000 Subject: [Mailman-Developers] DEFAULT_HOST_NAME -- Remark Message-ID: <01102718184105.08156@chaos.dvz.fh-giessen.de> The DEFAULT_HOST_NAME variable (option) should be renamed to DEFAULT_MAIL_DOMAIN (or something similar) Thats what it is. - oliver From barry@zope.com Sat Oct 27 17:17:27 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 27 Oct 2001 12:17:27 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 References: <15316.19395.73796.708333@anthem.wooz.org> Message-ID: <15322.56855.39563.755670@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: Me> Just like an Approved: header, it's always stripped because it Me> contains a password. CVR> Should these be sent to the admin as well as a possible CVR> security breach attempt? I thought about that, but doubt it's worth it. Certainly it could be added with little effort. CVR> Okay, neat. That seems pretty close to what I'm CVR> thinking. Close enough for government work, at least. So you CVR> could use extend() to gut mailman's interface, and then write CVR> an external that would, say, look thing up out of an LDAP CVR> that interfaces to the corprate database... Essentially yes. I did an experiment where a list was getting its membership out of a file via FileRecips.py, and I wanted to disable the membership screens (in fact the whole membership item in the admin menu). It was a little hacky, but it worked. One thing though: while I /think/ the membership api is nicely separated and can be easily replaced, other list configuration variables are not. So you'll still see lots of direct attribute access on MailList objects. Meaning it's much tougher to divert non-membership data to an external source. That won't change for MM2.1, but it'll likely be the bulk of the work for subsequent versions. In fact, some of the developments in Python 2.2 may make that a whole lot easier. I'm still targetting just Python 2.0 for MM2.1, but there's a possibility we'll up that to Py2.2 for later Mailman releases, especially if it makes stuff like this easy. -Barry From barry@zope.com Sat Oct 27 17:20:40 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 27 Oct 2001 12:20:40 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3 References: Message-ID: <15322.57048.831550.905153@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> But it's really clear (to me) that this stuff all has to get CVR> integrated down the road, and giving a user site-wide, CVR> consistent administration is a key usability issue -- and CVR> there's more to life than mail lists. Tools that don't CVR> integrate, are going to find themselves marginalized or CVR> replaced. CVR> All IMHO (or actually, IMNSHO). FWIW, I completely agree. -Barry From barry@zope.com Sat Oct 27 17:30:08 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 27 Oct 2001 12:30:08 -0400 Subject: [Mailman-Developers] DEFAULT_HOST_NAME -- Remark References: <01102718184105.08156@chaos.dvz.fh-giessen.de> Message-ID: <15322.57616.968048.604063@anthem.wooz.org> >>>>> "OE" == Oliver Egginger writes: OE> The DEFAULT_HOST_NAME variable (option) should be renamed OE> to DEFAULT_MAIL_DOMAIN (or something similar) OE> Thats what it is. In MM2.1a3 it's DEFAULT_EMAIL_HOST with DEFAULT_HOST_NAME equivalenced for (dubious) backwards compatibility. -Barry From donal.hunt2@mail.dcu.ie Sun Oct 28 12:34:29 2001 From: donal.hunt2@mail.dcu.ie (Donal Hunt) Date: Sun, 28 Oct 2001 12:34:29 +0000 Subject: [Mailman-Developers] New Pipermail hacks (was Re: Ok, it works! ...) References: Message-ID: <3BDBFB55.CD5B7240@mail.dcu.ie> hey everyone... I was thinking of the security issues behind HTML encoded mail and one of the things that you could do is strip out all "
BCN Ltd
50% Price Reductions On Software Development

BCN Web Site

About Us
BCN builds corporate Intranets and effective Knowledge Management Solutions for small and medium sized organisations. We have delivered solutions to BSI, Unilever, Compaq, Nomura and many small organisations.

What's Up This Month? 
Our team of software developers have successfully developed a major enterprise information portal solution and are now ready to tackle your requirements. This project was developed by our team in India but managed from the UK. This combines the benefit of off-shore pricing with on-shore project management.

The Benefits For You? 
As we know IT development often suffers from time delays and spiraling costs. Outsourcing is a proven model for at least part of your requirements. The cost benefits are outstanding and the quality and dependability are unsurpassed - our programmers work a minimum 6 day week and don't snowboard! That's 24 days a month instead of 20.


BCN Announces the Immediate Availability of Programming Capacity

BCN has recently successfully completed a significant software development project and for a limited period can provide you with software development capability at 50% discount on normal prices.

We can provide short, medium and long term resources or undertake fixed price contracts.

Tick the relevant boxes and we will contact you immediately to discuss your specific requirements.


First Name IIS/Apache WebLogic/Coldfusion
Last Name SQL/ORACLE Unix/Win2000/XP
Company XML/Php3 VB/Asp
Phone JAVA/Jsp Powerbuilder
Email CGI/Perl HTML/Javascript
Comments     
              

Our normal rates are up to £650 per day for senior developers - for contracts placed during the remainder of 2001 we are offering discounts of 50% on this usual daily rate. Prefer a fixed price contract? - no problem.

BCN capabilities will enable you to:

  • Reduce the backlog
  • Reduce programming costs
  • Increase speed of delivery
  • Provide flexibility in resourcing

    Send an email to simon.mercer@bcn3net.com to discuss specific projects.

    •   © Copyright BCN Ltd 1999-2001 - All rights reserved.  

    From joseroberto@pwr.com.br Tue Oct 30 18:39:13 2001 From: joseroberto@pwr.com.br (José Roberto Kerne) Date: Tue, 30 Oct 2001 16:39:13 -0200 Subject: [Mailman-Developers] Oh nooooooooooooo Message-ID: <20011030163913.4298c0ce.joseroberto@pwr.com.br> Here... This Spam no!! no in list!!!!!!!!!!!!!! ---- BCN Web Site About Us BCN builds corporate Intranets and effective Knowledge Management Solutions for small and medium sized organisations. We have delivered solutions to BSI, Unilever, Compaq, Nomura and many small organisations. ______________________________ José Roberto Kerne Network Services Power Consultoria e Informatica Ltda Fones: (47) 433-7595 / 9107-6073 E-Mail: joseroberto@pwr.com.br www.pwr.com.br Oracle Alliances Centro Certificado GNU/LINUX Rede Conectiva de Serviços ---------------- From bob@nleaudio.com Wed Oct 31 06:37:47 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Wed, 31 Oct 2001 01:37:47 -0500 Subject: [Mailman-Developers] Bounce handling Message-ID: <3BDF9C3B.61673BB6@nleaudio.com> Hi Gang, What affects bounce handling? I just set up another list with 2.0.6, and while I see in the bounce log that it is catching some bounces, the admin address is getting a TON of bounces, most of them properly-constructed, with the same exact email addresses as those subscribed. I recently did some editing of some of the modules, and might have somehow messed this up. What modules are used, and in what order? Bob From bob@nleaudio.com Wed Oct 31 06:39:20 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Wed, 31 Oct 2001 01:39:20 -0500 Subject: [Mailman-Developers] Messing with Defaults.py Message-ID: <3BDF9C98.CC2B76D6@nleaudio.com> One more question. I realize the docs say never to mess with Defaults.py, but use the mm_cfg.py. What happens if you do mess with Defaults.py? Are modules somehow linked to certain byte offsets in it that, if modified, makes things go boom? Bob From jwblist@olympus.net Wed Oct 31 07:04:05 2001 From: jwblist@olympus.net (John W Baxter) Date: Tue, 30 Oct 2001 23:04:05 -0800 Subject: [Mailman-Developers] Messing with Defaults.py In-Reply-To: <3BDF9C98.CC2B76D6@nleaudio.com> References: <3BDF9C98.CC2B76D6@nleaudio.com> Message-ID: At 1:39 -0500 10/31/2001, Bob Puff@NLE wrote: >One more question. I realize the docs say never to mess with Defaults.py, >but use the mm_cfg.py. What happens if you do mess with Defaults.py? Are >modules somehow linked to certain byte offsets in it that, if modified, >makes things go boom? When you upgrade Mailman, your edited Defaults.py is replaced. Your mm_cfg.py is left alone. No strange linking...it's just source code. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From bob@nleaudio.com Wed Oct 31 07:16:56 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Wed, 31 Oct 2001 02:16:56 -0500 Subject: [Mailman-Developers] Messing with Defaults.py References: <3BDF9C98.CC2B76D6@nleaudio.com> Message-ID: <3BDFA568.42ECF43@nleaudio.com> Hi John, THanks for the reply, but my question was more like Why not mess with Defaults.py? Will it break anything as long as the data is correct? I ask this because I did modify it, then realized later perhaps I should have followed the docs.. :-) Wondering if that could explain my bounce issue. Bob From Dan Mick Wed Oct 31 07:21:24 2001 From: Dan Mick (Dan Mick) Date: Tue, 30 Oct 2001 23:21:24 -0800 (PST) Subject: [Mailman-Developers] Messing with Defaults.py Message-ID: <200110310720.XAA07695@utopia.West.Sun.COM> > THanks for the reply, but my question was more like Why not mess with Defaults.py? Will it break anything as long as the data is correct? No. As John said: it's just source. The reason for not modifying it, as John said, is because it gets overwritten when you upgrade. You already have your answer. > I ask this because I did modify it, then realized later perhaps I should have followed the docs.. :-) Wondering if that could explain my bounce issue. No. From chuqui@plaidworks.com Wed Oct 31 17:33:58 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 31 Oct 2001 09:33:58 -0800 Subject: [Mailman-Developers] Yet another mailman weirdness.... Message-ID: (guess who? Mr. "karma machine") Found another weirdness in mailman this morning. One of our users mailer got sideways, and we showed up to a really, really large requests.db (something like 500 messages or more). We found it almost impossible to get the admin page to display, and even if we did, processing something that large out of a browser is, well, painful at best. I finally blew away the requests.db file to clean up the problem. While this was an accident, it has the side effect of being a pretty good DoS attack against a list, especially moderated ones. You can't limit the number of requests in the request.db, but you can keep things moving if you limit the number that the admin page attempts to display at one time to 20 or so. Yes, you'd still need to grind through discarding them all (hmm. Maybe a "discard all from this address" meta button?), but you could. As it stands, Mailman tries to create a web page that a browser may or may not be able to display because of memory issues, adn the end user may or may not be able to process if it IS displayed. From javier@cips.nokia.COM Wed Oct 31 19:23:39 2001 From: javier@cips.nokia.COM (Javier Henderson) Date: Wed, 31 Oct 2001 11:23:39 -0800 Subject: [Mailman-Developers] Moving lists from 2.0.x to 2.1a3 Message-ID: <15328.20411.444290.869148@argentum.cips.nokia.com> Hi, On machine A I have many lists, and running Mailman 2.0.something. On machine B I have just installed Mailman 2.1a3. I would like to move some lists from A to B, without having to recreate the lists on B, and manually subscribing everyone. What's the best way to accomplish this? -jav From allan@caldera.com.mx Sat Oct 6 17:39:05 2001 From: allan@caldera.com.mx (Allan Baker) Date: Sat, 6 Oct 2001 11:39:05 -0500 Subject: [Mailman-Developers] List CGI Message-ID: <20011006113905.4143d315.allan@caldera.com.mx> Hello all I ignore the fact if this is the right place to post. If this is not the accurate list I hope this mail can be redirected to a more appropriate one. As a job assignment I'm required to make a script (its highly likely it will be with a CGI script) so that mailman mailing lists can be created using a web page. However my idea is not to reinvent the wheel. Is there anything like it or do I have to start coding? Thanks for any help and any pointers, links or advice will be appreciated Allan Baker -- Allan Baker Ortegon, Technical Support, Caldera International Mexico allan@caldera.com.mx, http://www.caldera.com.mx "La responsabilidad es una virtud, no una carga emocional. El exito es saber actuar responsablemente en la vida." From kadarcs@edasz.hu" Hi! I started a mailman list. When I added a person, I added unfortunatelly with his name. On the member list apear the e-mail address follow by a space and follow by a name. The person couldn't use the list. I, as the owner can't to remove this faild address and replace with the working address. I asked you, if you could suggest me a solution for this problem. I am looking for your answer, Best regards, Csaba From kadarcs@edasz.hu" Hi , I joined this group, because I own a mailman discussion group, and I have a question. When I added a person, I added his e-mail address followed with his name. In the membership page this user apear with e-mail address followed by his name. When I, or he would like to modify anythink in his data, the server answwer, that he aren't user. Please help me in solving this problem, because this man don't receive the messages. Thank in advance for your help, Csaba