From barry at python.org Mon Jun 2 03:50:39 2003 From: barry at python.org (Barry Warsaw) Date: Sun Jun 1 22:50:41 2003 Subject: [Mailman-Developers] PROBLEM with Administrative Requests In-Reply-To: <3EC5B6AA.60708@isu.edu> References: <3EC5B6AA.60708@isu.edu> Message-ID: <1054522233.1619.0.camel@geddy> On Sat, 2003-05-17 at 00:12, Kory Wheatley wrote: > I've sent this email twice and no one has responded to this problem, I would really > appreciate a response. > > I receive this below error when I go into the Administrative Interface and > check "Preserve messsages for the site administrator" and then I check the > discard option. Once I click submit this is what I receive below. > > > BUG in Mailman version 2.1.1 > We're sorry, we hit a bug! > > If you would like to help us identify the problem, please email a copy > of this page to the webmaster for this site with a description of what > happened. Thanks! > > > Traceback: > > Traceback (most recent call last): > File "/home/mailman/scripts/driver", line 87, in run_main > main() > File "/home/mailman/Mailman/Cgi/admindb.py", line 163, in main > process_form(mlist, doc, cgidata) > File "/home/mailman/Mailman/Cgi/admindb.py", line 681, in process_form > forward, forwardaddr) > File "/home/mailman/Mailman/ListAdmin.py", line 184, in HandleRequest > forward, addr) > File "/home/mailman/Mailman/ListAdmin.py", line 262, in __handlepost > msg = cPickle.load(fp) > ValueError: could not convert string to float Hmm, I just tried this under MM 2.1.2+ (cvs) and Python 2.2.3 and it works okay for me. What version of Python are you using? -Barry From barry at python.org Mon Jun 2 04:07:51 2003 From: barry at python.org (Barry Warsaw) Date: Sun Jun 1 23:07:53 2003 Subject: [Mailman-Developers] gpg again In-Reply-To: <20030518111545.GC19785@fractalus.com> References: <20030518111545.GC19785@fractalus.com> Message-ID: <1054523266.1619.9.camel@geddy> On Sun, 2003-05-18 at 07:15, SteveC wrote: > Please don't flame if I'm out of place, I'll go rtfm/etc but I googled > for mailman+gpg and it came up with a bunch of old stuff on this list. > from what I can see periodically someone would come along and say 'we > want gpg support' but things don't happen. > > So, if anyone has a second I'd like to know why? This would have to be a Mailman 3 feature. -Barry From barry at python.org Mon Jun 2 04:13:34 2003 From: barry at python.org (Barry Warsaw) Date: Sun Jun 1 23:13:35 2003 Subject: [Mailman-Developers] semantic errorinmailmanctlline255(Mailman 2.1.2) In-Reply-To: <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> References: <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> Message-ID: <1054523609.1619.12.camel@geddy> On Tue, 2003-05-20 at 04:23, Oliver Egginger wrote: > But further particulars: > > when I comment out the line 126 in mailmanctl the error messages go away. > Here is the line > LogStdErr('error', 'mailmanctl', manual_reprime=0) > > I execute this function call with python -v on command line via: > >>> import paths > >>> from Mailman.Logging.Utils import LogStdErr > >>> LogStdErr('error', 'mailmanctl', manual_reprime=0) > > and receive: > > > > without error messages. > So it seems to work. > > But when I terminate the python session by typing CTRL-D (end of input) > I receive the same error messages as I get from mailmanctl during the start > and stop phase. > I have trailed them at the end of this message. > > Also it seems as if the error messages came from > Mailman.Logging.Utils import LogStdErr. > Maybe by destroying the objects which gets created by > LogStdErr('error', 'mailmanctl', manual_reprime=0). > The function seems to work, none the less the shutdown of the corresponding > objects seems to fail. > But I'am no python expert. To be honest, I'm at a loss. It seems to me like a Python problem, but it's definitely not something I see or can reproduce. The only thing I can recommend is to try to upgrade to Python 2.2.3 and see if that helps at all. Other than that...? -Barry From barry at python.org Mon Jun 2 04:16:56 2003 From: barry at python.org (Barry Warsaw) Date: Sun Jun 1 23:16:58 2003 Subject: [Mailman-Developers] Mass subscription failed / R-sig-QA mailing list In-Reply-To: <16070.19712.507731.680268@gargle.gargle.HOWL> References: <16070.19712.507731.680268@gargle.gargle.HOWL> Message-ID: <1054523102.1619.5.camel@geddy> On Sat, 2003-05-17 at 10:53, Martin Maechler wrote: > I just tried again (needs a tiny bit longer when working from > home), and it didn't work again -- when I tried to "upload a > file" of new member addresses. > > However when I tried (the old way of) pasting the new members > e-mails in to the web-interface form -- it did work. I just tested this with three names in my upload file and it worked fine for both subscribing and unsubscribing. This is with Mailman 2.1.2+ (cvs) and Python 2.2.3. How big was the upload file? Perhaps there's some size limit on your uploads? Then again, if the subscribe page tells you they were successfully subscribed, and the logs/subscribe file shows you what you'd expect, I have no idea what could be going on. You sure you didn't click "Invite"? -Barry From barry at python.org Mon Jun 2 04:17:07 2003 From: barry at python.org (Barry Warsaw) Date: Sun Jun 1 23:17:10 2003 Subject: [Mailman-Developers] Is this a bug? (was semantic error...) In-Reply-To: <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> References: <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> Message-ID: <1054523822.1619.15.camel@geddy> On Wed, 2003-05-28 at 13:27, Oliver Egginger wrote: > meanwhile I set up a debian "woody" with MM 2.1.2, but I receive > the same error messaes like under Mandrake 9.1. BTW, I use RH9 and 7.3, but I really don't think it makes any difference. What /might/ make a difference is using the distro's Python or installing Python from source. Python 2.2.3 was just released; maybe a from-source installation will solve the problem. > Are these error messages normal? > Will they only appear under Mandrake 9.1 and debian woody? > Can they cause any harm? > Can I comment out line 126? > Which linux distribution I should use for Mailman 2.1.2? I think you can actually ignore these messages. They probably won't hurt anything. -Barry From wheakory at isu.edu Mon Jun 2 15:36:08 2003 From: wheakory at isu.edu (Kory Wheatley) Date: Mon Jun 2 16:36:09 2003 Subject: [Mailman-Developers] Global user tool Message-ID: <3EDBB538.2060409@isu.edu> Is there some kind of administrator login I can use to manage subscriptions ... we have so many listservs that adding and removing subscriptions by list is a big hassle - it would be easier if I could manage subscriptions by user name rather by list. -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From fil at rezo.net Tue Jun 3 06:11:34 2003 From: fil at rezo.net (Fil) Date: Mon Jun 2 23:11:39 2003 Subject: [Mailman-Developers] invite/confirm traceback Message-ID: <20030603031134.GC31173@rezo.net> I'm experimenting an "invite_members" command-line script derived from the add_members script. It does send a request for confirmation, but the confirmation email does not get processed, and no traceback show up in the logs. However, if I try the web confirmation, I get this traceback. Bug in Mailman version 2.1.2+ 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 "/usr/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 98, in main content = Pending.confirm(cookie, expunge=0) File "/usr/local/mailman/Mailman/Pending.py", line 111, in confirm db = _load() File "/usr/local/mailman/Mailman/Pending.py", line 163, in _load return cPickle.load(fp) SystemError: Failed to import class UserDesc from module __main__ Python information: Variable Value sys.version 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: Variable Value DOCUMENT_ROOT /var/www/listes.rezo.net SERVER_ADDR 80.67.170.17 SERVER_PORT 80 PATH_TRANSLATED /var/www/listes.rezo.net/test/062c5a8c98ba236594a3edd6092ec2cdfb5737f4 REMOTE_ADDR 62.212.98.121 UNIQUE_ID PtwRIVBDqhEAAEaeBq8 HTTP_ACCEPT_LANGUAGE fr-fr, ja;q=0.62, en-us;q=0.93, en;q=0.90, de-de;q=0.86, de;q=0.83, nl-nl;q=0.79, nl;q=0.76, it-it;q=0.72, it;q=0.69, ja-jp;q=0.66, fr;q=0.97, es-es;q=0.59, es;q=0.55, da-dk;q=0.52, da;q=0.48, fi-fi;q=0.45, fi;q=0.41, ko-kr;q=0.38, ko;q=0.34, no-no;q=0.31, no;q=0.28, pt-pt;q=0.24, pt;q=0.21, sv-se;q=0.17, sv;q=0.14, zh-cn;q=0.10, zh-tw;q=0.07, zh;q=0.03 GATEWAY_INTERFACE CGI/1.1 SERVER_NAME listes.rezo.net HTTP_CONNECTION keep-alive HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-fr) AppleWebKit/74 (KHTML, like Gecko) Safari/74 HTTP_ACCEPT */* REQUEST_URI /mailman/confirm/test/062c5a8c98ba236594a3edd6092ec2cdfb5737f4 QUERY_STRING SCRIPT_FILENAME /home/mailman/cgi-bin/confirm SCRIPT_URL /mailman/confirm/test/062c5a8c98ba236594a3edd6092ec2cdfb5737f4 HTTP_HOST listes.rezo.net REQUEST_METHOD GET SERVER_SIGNATURE SCRIPT_URI http://listes.rezo.net/mailman/confirm/test/062c5a8c98ba236594a3edd6092ec2cdfb5737f4 SCRIPT_NAME /mailman/confirm SERVER_ADMIN fil@rezo.net SERVER_SOFTWARE Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.2.3 mod_fastcgi/2.2.12 mod_perl/1.26 DAV/1.0.3 PYTHONPATH /usr/local/mailman PATH_INFO /test/062c5a8c98ba236594a3edd6092ec2cdfb5737f4 HTTP_COOKIE site=280200000069590cdc3e732800000039303939623930306333386139346564633231373832653532303062643863323134356662303536 SERVER_PROTOCOL HTTP/1.1 REMOTE_PORT 29092 -- Fil From fil at rezo.net Tue Jun 3 15:43:36 2003 From: fil at rezo.net (Fil) Date: Tue Jun 3 08:43:52 2003 Subject: [Mailman-Developers] invite/confirm traceback In-Reply-To: <20030603031134.GC31173@rezo.net> References: <20030603031134.GC31173@rezo.net> Message-ID: <20030603124336.GL19840@rezo.net> > I'm experimenting an "invite_members" command-line script derived from the > add_members script. It does send a request for confirmation, but the > confirmation email does not get processed, and no traceback show up in the > logs. However, if I try the web confirmation, I get this traceback. > > Traceback (most recent call last): > File "/usr/local/mailman/scripts/driver", line 87, in run_main > main() > File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 98, in main > content = Pending.confirm(cookie, expunge=0) > File "/usr/local/mailman/Mailman/Pending.py", line 111, in confirm > db = _load() > File "/usr/local/mailman/Mailman/Pending.py", line 163, in _load > return cPickle.load(fp) > SystemError: Failed to import class UserDesc from module __main__ My script must have played fool: somehow the data/pending.pck file was generating the error. I just removed it from that folder and Mailman is now running fine. -- Fil From Oliver.Egginger at dvz.fh-giessen.de Tue Jun 3 16:14:52 2003 From: Oliver.Egginger at dvz.fh-giessen.de (Oliver Egginger) Date: Tue Jun 3 11:14:53 2003 Subject: [Mailman-Developers] Is this a bug? (was semantic error...) In-Reply-To: <1054523822.1619.15.camel@geddy> References: <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> <1054523822.1619.15.camel@geddy> Message-ID: <1054653289.11645.170.camel@chaos.dvz.fh-giessen.de> Barry Warsaw wrote: > > Python 2.2.3 was just released; maybe > a from-source installation will solve the problem. > Yes! After installing python 2.2.3 from source and let mailman run under this python version the error messages are gone. That solve my case. These error messages occurred under Mandrake 9.1 and Debian Woody, with the standard python 2.2.2 packages of this distributions. Maybe a python 2.2.2 problem as you have supposed. Thank you! - oliver From barry at python.org Tue Jun 3 16:50:10 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 3 11:50:11 2003 Subject: [Mailman-Developers] Is this a bug? (was semantic error...) In-Reply-To: <1054653289.11645.170.camel@chaos.dvz.fh-giessen.de> References: <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> <1054523822.1619.15.camel@geddy> <1054653289.11645.170.camel@chaos.dvz.fh-giessen.de> Message-ID: <1054655377.5714.6.camel@barry> On Tue, 2003-06-03 at 11:14, Oliver Egginger wrote: > Barry Warsaw wrote: > > > > Python 2.2.3 was just released; maybe > > a from-source installation will solve the problem. > > > > Yes! > After installing python 2.2.3 from source > and let mailman run under this python version the > error messages are gone. > That solve my case. > > These error messages occurred under Mandrake 9.1 and Debian Woody, > with the standard python 2.2.2 packages of this distributions. > Maybe a python 2.2.2 problem as you have supposed. It seems we've had no end of trouble with packaged Python distros, especially with folks not installing all the related Python packages. A from-source install of Python usually clears things up because then you /know/ you're getting everything you need. It would be helpful if people running various Linux distros do a little research to figure out which Python packages are required for Mailman to run. I'd be happy to add such information to README.LINUX. -Barry From barry at python.org Tue Jun 3 17:10:33 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 3 12:10:35 2003 Subject: [Mailman-Developers] invite/confirm traceback In-Reply-To: <20030603031134.GC31173@rezo.net> References: <20030603031134.GC31173@rezo.net> Message-ID: <1054656601.5714.17.camel@barry> On Mon, 2003-06-02 at 23:11, Fil wrote: > I'm experimenting an "invite_members" command-line script derived from the > add_members script. It does send a request for confirmation, but the > confirmation email does not get processed, and no traceback show up in the > logs. However, if I try the web confirmation, I get this traceback. Without seeing your code, it's hard for me to tell exactly what the bug is, but let me explain a little about how pickles work. When you pickle an instance, Python really pickles the object's data members and a reference to the object's class -- not the class itself. This reference is in the form of a string such as "Mailman.UserDesc.UserDesc". Upon unpickling, Python will attempt to import e.g. UserDesc from Mailman.UserDesc. Things that can foul this up include pickling a class nested inside a function or another class. In those cases, Python won't be able to write the correct reference, or find the right imports to satisfy the class reference. The moral of the story is to make sure all the classes of the object you want to pickle are defined at global scope. Mailman.UserDesc.UserDesc ought to satisfy that requirement, but maybe you've done something funky in your script? -Barry From Oliver.Egginger at dvz.fh-giessen.de Tue Jun 3 18:52:13 2003 From: Oliver.Egginger at dvz.fh-giessen.de (Oliver Egginger) Date: Tue Jun 3 13:52:15 2003 Subject: [Mailman-Developers] Is this a bug? (was semantic error...) In-Reply-To: <1054655377.5714.6.camel@barry> References: <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> <1054523822.1619.15.camel@geddy> <1054653289.11645.170.camel@chaos.dvz.fh-giessen.de> <1054655377.5714.6.camel@barry> Message-ID: <1054662728.11637.337.camel@chaos.dvz.fh-giessen.de> > It would be helpful if people running various Linux distros do a > little > research to figure out which Python packages are required for Mailman to > run. I'd be happy to add such information to README.LINUX. But it runs! Only during the shutdown and the startup I see these error messages: SystemError: codec module not properly initialized several times (using verbose mode). Meanwhile I have translated, linked and installed python 2.2.2 from the original source tar ball, and I see the same error messages. (I only tested under ML 9.1 yet.) When I go back to python 2.2.3 (installed from source) the error messages disappear. So I think (in this case), it's likely rather a mailman/python (2.2.2) issue than a Mailman/Linux distro topic. Maybe this is specific to my system, cause the configure scripts will produce different results on different systems. But maybe other people see those error messages with Mailman 2.1.2 and python 2.2.2 too. Also the messages are maybe harmless. But I will use in any case python 2.2.3 for this task. Regards Oliver Am Die, 2003-06-03 um 17.49 schrieb Barry Warsaw: > On Tue, 2003-06-03 at 11:14, Oliver Egginger wrote: > > Barry Warsaw wrote: > > > > > > Python 2.2.3 was just released; maybe > > > a from-source installation will solve the problem. > > > > > > > Yes! > > After installing python 2.2.3 from source > > and let mailman run under this python version the > > error messages are gone. > > That solve my case. > > > > These error messages occurred under Mandrake 9.1 and Debian Woody, > > with the standard python 2.2.2 packages of this distributions. > > Maybe a python 2.2.2 problem as you have supposed. > > It seems we've had no end of trouble with packaged Python distros, > especially with folks not installing all the related Python packages. A > from-source install of Python usually clears things up because then you > /know/ you're getting everything you need. > > It would be helpful if people running various Linux distros do a little > research to figure out which Python packages are required for Mailman to > run. I'd be happy to add such information to README.LINUX. > > -Barry > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- Oliver Egginger Fachochschule Giessen-Friedberg From barry at python.org Tue Jun 3 19:34:39 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 3 14:34:40 2003 Subject: [Mailman-Developers] Is this a bug? (was semantic error...) In-Reply-To: <1054662728.11637.337.camel@chaos.dvz.fh-giessen.de> References: <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> <1054523822.1619.15.camel@geddy> <1054653289.11645.170.camel@chaos.dvz.fh-giessen.de> <1054655377.5714.6.camel@barry> <1054662728.11637.337.camel@chaos.dvz.fh-giessen.de> Message-ID: <1054665247.1042.3.camel@barry> On Tue, 2003-06-03 at 13:52, Oliver Egginger wrote: > So I think (in this case), it's likely rather a mailman/python (2.2.2) > issue than a Mailman/Linux distro topic. Good thing Python 2.2.3 is out now, then! :) > Maybe this is specific to my system, cause the configure scripts will > produce different results on different systems. > But maybe other people see those error messages with Mailman 2.1.2 and > python 2.2.2 too. I definitely haven't seen the problem on any RH9 or RH7.3 system with Python 2.2.2 built from scratch. the-gremlins-have-found-another-playmate-for-now-ly y'rs, -Barry From fil at rezo.net Tue Jun 3 22:12:08 2003 From: fil at rezo.net (Fil) Date: Tue Jun 3 15:12:13 2003 Subject: [Mailman-Developers] invite/confirm traceback In-Reply-To: <1054656601.5714.17.camel@barry> References: <20030603031134.GC31173@rezo.net> <1054656601.5714.17.camel@barry> Message-ID: <20030603191208.GD3074@rezo.net> Well well... I just modified bin/add_members to be able to invite them instead of adding them. I need the command line because I wrap it in a php script (don't hit me!)... And obviously I failed! Here it is (mailman-users: don't use it!). Hint: if add_members could grow an 'invite' option... -- Fil @ Barry Warsaw : > On Mon, 2003-06-02 at 23:11, Fil wrote: > > I'm experimenting an "invite_members" command-line script derived from the > > add_members script. It does send a request for confirmation, but the > > confirmation email does not get processed, and no traceback show up in the > > logs. However, if I try the web confirmation, I get this traceback. > > Without seeing your code, it's hard for me to tell exactly what the bug > is, but let me explain a little about how pickles work. > > When you pickle an instance, Python really pickles the object's data > members and a reference to the object's class -- not the class itself. > This reference is in the form of a string such as > "Mailman.UserDesc.UserDesc". Upon unpickling, Python will attempt to > import e.g. UserDesc from Mailman.UserDesc. > > Things that can foul this up include pickling a class nested inside a > function or another class. In those cases, Python won't be able to > write the correct reference, or find the right imports to satisfy the > class reference. > > The moral of the story is to make sure all the classes of the object you > want to pickle are defined at global scope. Mailman.UserDesc.UserDesc > ought to satisfy that requirement, but maybe you've done something funky > in your script? > > -Barry -------------- next part -------------- #! /usr/bin/python # # Copyright (C) 1998-2003 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # argv[1] should be the name of the list. # argv[2] should be the list of non-digested users. # argv[3] should be the list of digested users. # Make sure that the list of email addresses doesn't contain any comments, # like majordomo may throw in. For now, you just have to remove them manually. """Invite members to a list from the command line. Usage: invite_members [options] listname Options: --regular-members-file=file -r file A file containing addresses of the members to be invited, one address per line. This list of people become non-digest members. If file is `-', read addresses from stdin. Note that -n/--non-digest-members-file are deprecated synonyms for this option. --help -h Print this help message and exit. listname The name of the Mailman list you are adding members to. It must already exist. You must supply at least one of -r and -d options. At most one of the files can be `-'. """ import sys import os import getopt from cStringIO import StringIO import paths # Import this /after/ paths so that the sys.path is properly hacked from email.Utils import parseaddr from Mailman import MailList from Mailman import Utils from Mailman import Message from Mailman import Errors from Mailman import mm_cfg from Mailman import i18n _ = i18n._ def usage(status, msg=''): if status: fd = sys.stderr else: fd = sys.stdout print >> fd, _(__doc__) if msg: print >> fd, msg sys.exit(status) def readfile(filename): if filename == '-': fp = sys.stdin closep = 0 else: fp = open(filename) closep = 1 # strip all the lines of whitespace and discard blank lines lines = filter(None, [line.strip() for line in fp.readlines()]) if closep: fp.close() return lines class Tee: def __init__(self, outfp): self.__outfp = outfp def write(self, msg): sys.stdout.write(msg) self.__outfp.write(msg) class UserDesc: pass def addall(mlist, members, digest, ack, outfp): tee = Tee(outfp) for member in members: userdesc = UserDesc() userdesc.fullname, userdesc.address = parseaddr(member) userdesc.digest = digest try: mlist.InviteNewMember(userdesc) except Errors.MMAlreadyAMember: print >> tee, _('Already a member: %(member)s') except Errors.MMBadEmailError: if userdesc.address == '': print >> tee, _('Bad/Invalid email address: blank line') else: print >> tee, _('Bad/Invalid email address: %(member)s') except Errors.MMHostileAddress: print >> tee, _('Hostile address (illegal characters): %(member)s') else: print >> tee, _('Subscribed: %(member)s') def main(): try: opts, args = getopt.getopt(sys.argv[1:], 'a:n:r:d:w:h', ['admin-notify=', 'regular-members-file=', 'non-digest-members-file=', 'digest-members-file=', 'welcome-msg=', 'help']) except getopt.error, msg: usage(1, msg) if len(args) <> 1: usage(1) listname = args[0].lower().strip() nfile = None dfile = None send_welcome_msg = None admin_notif = None for opt, arg in opts: if opt in ('-h', '--help'): usage(0) elif opt in ('-d', '--digest-members-file'): dfile = arg # Deprecate -/--non-digest-members-file or consistency with # list_members elif opt in ('-r', '--regular-members-file'): nfile = arg elif opt in ('-n', '--non-digest-members-file'): nfile = arg # I don't think we need to use the warnings module here. print >> sys.stderr, 'option', opt, \ 'is deprecated, use -r/--regular-members-file' elif opt in ('-w', '--welcome-msg'): if arg.lower()[0] == 'y': send_welcome_msg = 1 elif arg.lower()[0] == 'n': send_welcome_msg = 0 else: usage(1, _('Bad argument to -w/--welcome-msg: %(arg)s')) elif opt in ('-a', '--admin-notify'): if arg.lower()[0] == 'y': admin_notif = 1 elif arg.lower()[0] == 'n': admin_notif = 0 else: usage(1, _('Bad argument to -a/--admin-notify: %(arg)s')) if dfile is None and nfile is None: usage(1) if dfile == "-" and nfile == "-": usage(1, _('Cannot read both digest and normal members ' 'from standard input.')) try: mlist = MailList.MailList(listname) except Errors.MMUnknownListError: usage(1, _('No such list: %(listname)s')) # Set up defaults if send_welcome_msg is None: send_welcome_msg = mlist.send_welcome_msg if admin_notif is None: admin_notif = mlist.admin_notify_mchanges otrans = i18n.get_translation() # Read the regular and digest member files try: dmembers = [] if dfile: dmembers = readfile(dfile) nmembers = [] if nfile: nmembers = readfile(nfile) if not dmembers and not nmembers: usage(0, _('Nothing to do.')) s = StringIO() i18n.set_language(mlist.preferred_language) if nmembers: addall(mlist, nmembers, 0, send_welcome_msg, s) if dmembers: addall(mlist, dmembers, 1, send_welcome_msg, s) if admin_notif: realname = mlist.real_name subject = _('%(realname)s subscription notification') msg = Message.UserNotification( mlist.owner, Utils.get_site_email(), subject, s.getvalue(), mlist.preferred_language) msg.send(mlist) mlist.Save() finally: mlist.Unlock() i18n.set_translation(otrans) if __name__ == '__main__': main() From wes at greenfieldnetworks.com Tue Jun 3 13:36:41 2003 From: wes at greenfieldnetworks.com (Wesley T. Perdue) Date: Tue Jun 3 15:36:50 2003 Subject: [Mailman-Developers] Is this a bug? (was semantic error...) In-Reply-To: <1054662728.11637.337.camel@chaos.dvz.fh-giessen.de> References: <1054655377.5714.6.camel@barry> <7719FDA6-8681-11D7-A437-003065EEFAC8@python.org> <1052987342.26247.77.camel@chaos.dvz.fh-giessen.de> <1053097915.1849.29.camel@barry> <1053329070.5387.17.camel@chaos.dvz.fh-giessen.de> <1053371773.22001.10.camel@barry> <1053418986.23343.72.camel@chaos.dvz.fh-giessen.de> <1054142865.11436.34.camel@chaos.dvz.fh-giessen.de> <1054523822.1619.15.camel@geddy> <1054653289.11645.170.camel@chaos.dvz.fh-giessen.de> <1054655377.5714.6.camel@barry> Message-ID: <5.2.1.1.2.20030603123154.026872f8@mail.greenfieldnetworks-int.com> Oliver, FWIW, I'm running a source-installed Mailman 2.1.2 and source-installed Python 2.2.2 on a maintained Red Hat 7.1 system, and I haven't seen a single message in my Mailman error log. Regards, Wes ---------- Wes Perdue IT Manager, Greenfield Networks At 07:52 PM 6/3/2003 +0200, Oliver Egginger wrote: >So I think (in this case), it's likely rather a mailman/python (2.2.2) >issue than a Mailman/Linux distro topic. > >Maybe this is specific to my system, cause the configure scripts will >produce different results on different systems. >But maybe other people see those error messages with Mailman 2.1.2 and >python 2.2.2 too. From m.hubbard at imperial.ac.uk Fri Jun 6 18:55:25 2003 From: m.hubbard at imperial.ac.uk (Hubbard, Matthew R W) Date: Fri Jun 6 12:55:32 2003 Subject: [Mailman-Developers] email address validation Message-ID: Dear All, I had a quick search and couldn't find much about this. I'm using Mailman 2.1.2. I've been looking through the add member code, specifically the InviteNewMember, AddMember and ApprovedAddMember functions. It has struck me as odd that there is a lot more effort in validating email addresses in the AddMember function than in the ApprovedAddMember and the InviteNewMember doesn't even call Utils.ValidateEmail. Could / should this be consolidated in some fashion? I don't especially trust a vast list of address supplied by an administrator anymore than a user filling in the subscribe form. Cheers, Matt. From barry at python.org Fri Jun 6 19:24:10 2003 From: barry at python.org (Barry Warsaw) Date: Fri Jun 6 14:24:11 2003 Subject: [Mailman-Developers] email address validation In-Reply-To: References: Message-ID: <1054923816.30418.65.camel@barry> On Fri, 2003-06-06 at 12:55, Hubbard, Matthew R W wrote: > Dear All, > > I had a quick search and couldn't find much about this. I'm using Mailman > 2.1.2. > > I've been looking through the add member code, specifically the > InviteNewMember, AddMember and ApprovedAddMember functions. > > It has struck me as odd that there is a lot more effort in validating email > addresses in the AddMember function than in the ApprovedAddMember and the > InviteNewMember doesn't even call Utils.ValidateEmail. The latter is a bug. Note that InviteNewMember is (currently) only called through the admin pages, so it's primary effect should be to prevent bogus addresses from getting into the pending database. Note though that any bogus address wouldn't be confirmable so it should never get into the real member database. Certainly the code in change_options() in admin.py expects ValidateEmail() to be called. I'll check in a fix for that. > Could / should this be consolidated in some fashion? I don't especially > trust a vast list of address supplied by an administrator anymore than a > user filling in the subscribe form. The intent of ApprovedAddMember() is to really add the address after it's been approved and validated. But note that it does call Utils.ValidateEmail() which ought to be the sole interface to email address validation. -Barry From simon at uow.edu.au Sun Jun 8 12:04:43 2003 From: simon at uow.edu.au (Simon Coggins) Date: Sat Jun 7 21:04:56 2003 Subject: [Mailman-Developers] Problems with archiviing mbox's Message-ID: <20030608010443.GG3863@uow.edu.au> Hi, I'm having a problem with the arch. I've tracked it down to the Mailbox class that uses PortableUnixMailbox. The problem is it's picking up "^From " as a new message. Sendmail doesn't escape from lines now so they are throughout my archives. I've managed to fix this by going back to UnixMailbox instead of PortableUnixMailbox, so that it does the regex on the line to ensure it is the correct From line. I'm just wondering why it is set to Portable when the other one works. I've also got a threading problem, where the threads aren't being detected correctly and are being indented when they shouldn't. But I'm still trying to pin down that problem. -- Simon Coggins (SAGE-AU Member) Email: simon@uow.edu.au Network and System Management Officer Phone: +61-2-4221-3775 Information Technology Systems (ITS) Mobile: 0408 115861 University of Wollongong, 2522, Australia Fax: +61-2-4229-1985 From barry at python.org Mon Jun 9 16:09:09 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 11:09:10 2003 Subject: [Mailman-Developers] Problems with archiviing mbox's In-Reply-To: <20030608010443.GG3863@uow.edu.au> References: <20030608010443.GG3863@uow.edu.au> Message-ID: <1055171315.29505.26.camel@barry> On Sat, 2003-06-07 at 21:04, Simon Coggins wrote: > I'm having a problem with the arch. I've tracked it down to the > Mailbox class that uses PortableUnixMailbox. The problem is it's > picking up "^From " as a new message. Sendmail doesn't escape from > lines now so they are throughout my archives. It shouldn't matter what Sendmail does. Mailman 2.1.2 should ensure that From lines in the body are escaped. In order to fix older archives, the script bin/cleanarch is provided. -Barry From barry at python.org Mon Jun 9 16:54:17 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 11:54:18 2003 Subject: [Mailman-Developers] invite/confirm traceback In-Reply-To: <20030603191208.GD3074@rezo.net> References: <20030603031134.GC31173@rezo.net> <1054656601.5714.17.camel@barry> <20030603191208.GD3074@rezo.net> Message-ID: <1055174023.29829.5.camel@barry> On Tue, 2003-06-03 at 15:12, Fil wrote: > Hint: if add_members could grow an 'invite' option... Wanna add that as a feature request? :) -Barry From barry at python.org Mon Jun 9 17:02:56 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 12:02:57 2003 Subject: [Mailman-Developers] Global user tool In-Reply-To: <3EDBB538.2060409@isu.edu> References: <3EDBB538.2060409@isu.edu> Message-ID: <1055174542.29829.7.camel@barry> On Mon, 2003-06-02 at 16:36, Kory Wheatley wrote: > Is there some kind of administrator login I can use to manage > subscriptions ... we have so many listservs that adding and removing > subscriptions by list is a big hassle - it would be easier if I could > manage subscriptions by user name rather by list. Not in Mailman 2. This is one of the most important design goals of Mailman 3. -Barry From barry at python.org Mon Jun 9 17:08:03 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 12:08:04 2003 Subject: [Mailman-Developers] modifying mailman's source In-Reply-To: <5.2.1.1.2.20030528145133.0271b9e8@mail.greenfieldnetworks-int.com> References: <5.2.1.1.2.20030528145133.0271b9e8@mail.greenfieldnetworks-int.com> Message-ID: <1055174847.29829.13.camel@barry> On Wed, 2003-05-28 at 17:53, Wesley T. Perdue wrote: > All, > > I need to call an external script whenever a mailing list's membership changes. Why don't you modify OldStyleMemberships.py? If you want to feel more immune from future Mailman updates, I'd suggest subclassing from OldStyleMemberships, override the few methods you need, and then use the MailList extension mechanisms to make sure your class gets instantiated instead of the default one. -Barry From barry at python.org Mon Jun 9 17:09:03 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 12:09:04 2003 Subject: [Mailman-Developers] Unsubscribe link In-Reply-To: <015b01c3246f$4346a960$b302a8c0@zeus> References: <015b01c3246f$4346a960$b302a8c0@zeus> Message-ID: <1055174909.29829.15.camel@barry> On Tue, 2003-05-27 at 12:44, Tentra List Support wrote: > I would like to generate a link in the footer of each email that would take the user directly to their options page so that, if they want to unsubscribe, they can do so with a maximum of two steps one to click to the page and one to unsubscribe via the web page with no further confirmation steps. Is there a script for this already or should I look into creating one? Use Mailman 2.1 and enable personalization. Check the details of the `personalize' variable for the additional substitutions that get made in the footer. -Barry From barry at python.org Mon Jun 9 17:25:02 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 12:25:02 2003 Subject: [Mailman-Developers] Browser stop button (revisited from 2.0.5??) In-Reply-To: References: Message-ID: <1055175502.29829.19.camel@barry> On Thu, 2003-05-29 at 08:03, Steve Lay wrote: > I have a problem with the Mailman servers I run related to an issue which > was discussed during the 2.0.4 to 2.0.5 transition some time ago. The > problem relates to people who click the stop button on their browser while > Mailman is doing its stuff. If the person in question is the list admin, > making changes to the list, then Mailman just aborts without saving the > list changes. Like the posters in the original discussion on this list > some 2 years ago I can live with these semantics, almost.... > > The problem is that Mailman always returns the content of the page, which > says that everything has been done, before it saves the list. For example, > see lines 236-238 of admindb.py in 2.1: > > print doc.Format() > # Commit all changes > mlist.Save() > > The problem with this is that mlist.Save() is taking quite a while for > large lists so I have to educate my list owners to be really patient and > wait for the browser to finish - with very little visual cue that it is > doing anything. (OK, animated wavy windows, spinning worlds, sparkly N's > apart....) > > What would make much more sense to me (and my users) is if these two lines > were done the other way around. At least the users would then understand > that the system was doing something and shouldn't be interupted because > they would be looking at a blank browser window. They wouldn't be told > that their changes had been successfully carried out until they actually > had! > > What do you all think? Can you see any problems with switching these two > lines (similarly in the other CGI handlers)? It seems reasonable, although I might want to make sure that when an error does occur, or when the stop button is hit, Something Reasonable gets outputted. Care to generate a patch against 2.1 cvs? -Barry From fil at rezo.net Mon Jun 9 19:27:18 2003 From: fil at rezo.net (Fil) Date: Mon Jun 9 12:27:22 2003 Subject: [Mailman-Developers] invite/confirm traceback In-Reply-To: <1055174023.29829.5.camel@barry> References: <20030603031134.GC31173@rezo.net> <1054656601.5714.17.camel@barry> <20030603191208.GD3074@rezo.net> <1055174023.29829.5.camel@barry> Message-ID: <20030609162717.GA11763@rezo.net> @ Barry Warsaw : > On Tue, 2003-06-03 at 15:12, Fil wrote: > > Hint: if add_members could grow an 'invite' option... > Wanna add that as a feature request? :) That's the idea, yes, I think... -- Fil From barry at python.org Mon Jun 9 17:42:23 2003 From: barry at python.org (Barry Warsaw) Date: Mon Jun 9 12:42:26 2003 Subject: [Mailman-Developers] Default link colors In-Reply-To: <014301c323df$5bbe6770$b302a8c0@zeus> References: <014301c323df$5bbe6770$b302a8c0@zeus> Message-ID: <1055175351.29829.17.camel@barry> On Mon, 2003-05-26 at 19:34, Tentra List Support wrote: > I tryed change the default page and link colors by adding relevant fields in > Default.py to mm_cfg.py. Changing all of the directives worked except for > WEB_LINK_COLOR > which did not result in a change. I found the offending error in > htmlformat.py line 326. It should read: > 'link' > when it reads > 'alink' > Changed to 'link' and default web links now change. > > Mailman version 2.1.2 Clearly a typo. Fixed in cvs. Thanks. -Barry From matze at indymedia.org Tue Jun 10 00:41:01 2003 From: matze at indymedia.org (matze) Date: Mon Jun 9 17:41:38 2003 Subject: [Mailman-Developers] ssl for admin pages Message-ID: <20030609214101.GU21064@rantanplan> hi, in indymedia (http://indymedia.org) and sindominio (http://sindomino.net) we saw the necessity to protect the admin part of mailman (above all the password transmission) with a ssl connection. i figured out that vanilla-mailman doesn't support this feature (http://www.mail-archive.com/mailman-users@python.org/msg16301.html) so i dived into the mailman sources and figured out a possible solution. it seems to me that the best way to achieve ssl connections for the admin is putting a condition in ScriptURL() in Utils.py. if((0 !=3D mm_cfg.DEFAULT_ADMIN_USE_SSL) and (target[0:5] =3D=3D 'admin')): web_page_url =3D replace(web_page_url, 'http:', 'https:') as you see a new paramerter DEFAULT_ADMIN_USE_SSL has been added to Default.py. i tested this on the lists of both projects and it's working fine. as i'm sure that there are more ppl out there who would like this feature i ask you whether you are interrested in adding it to the mailman distribution. i uploaded a patch for mailman 2.1 on the sourceforge site of mailman: http://sourceforge.net/tracker/index.php?func=detail&aid=746728&group_id=103&atid=300103 /matze -- ( ( ( i ) ) ) http://barcelona.indymedia.org ( ( ( i ) ) ) * using free software / Debian GNU/Linux | http://debian.org * gpg --keyserver keys.indymedia.org --recv-keys B9A88F6F "La guerra es un acto abominable en el que se matan personas que no se conocen, dirigidas por personas que se conocen y no se matan" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030609/c570f4f7/attachment.bin From donn at u.washington.edu Mon Jun 9 16:55:37 2003 From: donn at u.washington.edu (Donn Cave) Date: Mon Jun 9 18:55:42 2003 Subject: [Mailman-Developers] ssl for admin pages Message-ID: <200306092255.h59Mtbu6027746@mailhost1.u.washington.edu> Quoth matze : ... | so i dived into the mailman sources and figured out a possible | solution. it seems to me that the best way to achieve ssl connections | for the admin is putting a condition in ScriptURL() in Utils.py. | | if((0 != mm_cfg.DEFAULT_ADMIN_USE_SSL) and | (target[0:5] == 'admin')): | web_page_url = replace(web_page_url, 'http:', 'https:') | | as you see a new paramerter DEFAULT_ADMIN_USE_SSL has been added to | Default.py. i tested this on the lists of both projects and it's | working fine. as i'm sure that there are more ppl out there who would | like this feature i ask you whether you are interrested in adding it | to the mailman distribution. i uploaded a patch for mailman 2.1 on the We don't support passwords for admin at all, at our site, so I didn't have exactly the same problem. We do use cookies for authentication, though (as does standard Mailman password authentication), and we needed to make these ``secure'' cookies that only go to the server via SSL. And we need that for everyone, not only admin. I added a parameter to ScriptURL(..., upgrade=0) and a couple of functions to deal with the protocol part of the URL (http vs. https.) The upgrade parameter indicates that the URL must be https. And then I had to change a few modules other than Utils.py - some to specify a "true" value for upgrade, if for example the link is to an archive page that is protected, and some to pass this upgrade parameter through from there to ScriptURL() (GetScriptURL(), for example.) The effect is to present either an http or an https view of the site, depending on the preceding URL. If you get there via https, the links will _all_ be https, even to listinfo etc. This gets a little complicated, but is in my opinion better than making everything https hard coded, which would cause problems for some people, and yet it does support an all-https site as an option for SSL browsers. Following is highlights of the code changes. Donn Cave, University Computing Services, University of Washington donn@u.washington.edu =================================================================== RCS file: RCS/SecurityManager.py,v retrieving revision 1.3 diff -c -r1.3 SecurityManager.py *** 1.3 2003/04/28 22:50:48 --- SecurityManager.py 2003/02/21 00:18:39 *************** *** 239,244 **** --- 239,245 ---- # We use session cookies, so don't set `expires' or `max-age' keys. # Set the RFC 2109 required header. c[key]['version'] = 1 + c[key]['secure'] = 'yes' return c def ZapCookie(self, authcontext, user=None): =================================================================== RCS file: RCS/Utils.py,v retrieving revision 1.3 diff -c -r1.3 Utils.py *** 1.3 2003/04/28 22:50:48 --- Utils.py 2003/06/09 22:23:50 *************** *** 238,254 **** return [p for p in path.split('/') if p] return None ! def ScriptURL(target, web_page_url=None, absolute=0): """target - scriptname only, nothing extra web_page_url - the list's configvar of the same name absolute - a flag which if set, generates an absolute url """ if web_page_url is None: ! web_page_url = mm_cfg.DEFAULT_URL_PATTERN % get_domain() if web_page_url[-1] <> '/': web_page_url = web_page_url + '/' fullpath = os.environ.get('REQUEST_URI') if fullpath is None: fullpath = os.environ.get('SCRIPT_NAME', '') + \ --- 238,288 ---- return [p for p in path.split('/') if p] return None + def CurrentHTTPProtocol(default): + server_port = os.environ.get('SERVER_PORT', None) + if server_port is None: + return default + elif server_port == '443': + return 'https' + else: + return 'http' + + def DefaultURL(host = None): + protocol = CurrentHTTPProtocol('http') + if host is None: + host = mm_cfg.DEFAULT_URL_HOST + return mm_cfg.PROTOCOL_URL_PATTERN % (protocol, host) + + def UpgradeURL(old, force): + if force: + protocol = 'https' + else: + protocol = CurrentHTTPProtocol(None) + if protocol is None: + return old + try: + oldproto, rest = old.split(':', 1) + except ValueError, TypeError: + return old + if protocol == 'http' or oldproto == protocol: + return old + else: + return protocol + ':' + rest ! def ScriptURL(target, web_page_url=None, absolute=0, upgrade=0): """target - scriptname only, nothing extra web_page_url - the list's configvar of the same name absolute - a flag which if set, generates an absolute url """ if web_page_url is None: ! web_page_url = DefaultURL(get_domain()) ! if upgrade: ! web_page_url = UpgradeURL(web_page_url, upgrade) if web_page_url[-1] <> '/': web_page_url = web_page_url + '/' + else: + web_page_url = UpgradeURL(web_page_url, upgrade) fullpath = os.environ.get('REQUEST_URI') if fullpath is None: fullpath = os.environ.get('SCRIPT_NAME', '') + \ =================================================================== RCS file: RCS/HTMLFormatter.py,v retrieving revision 1.3 diff -c -r1.3 HTMLFormatter.py *** 1.3 2003/04/28 22:50:47 --- HTMLFormatter.py 2003/02/20 23:24:57 *************** *** 321,328 **** container.AddItem("") return container ! def FormatFormStart(self, name, extra='', method=None): ! base_url = self.GetScriptURL(name) if extra: full_url = "%s/%s" % (base_url, extra) else: --- 321,328 ---- container.AddItem("") return container ! def FormatFormStart(self, name, extra='', method=None, upgrade=0, absolute=0): ! base_url = self.GetScriptURL(name, upgrade=upgrade, absolute=absolute) if extra: full_url = "%s/%s" % (base_url, extra) else: $ rcsdiff -c listinfo.py =================================================================== RCS file: RCS/listinfo.py,v retrieving revision 1.4 diff -c -r1.4 listinfo.py *** 1.4 2003/05/28 23:18:40 --- listinfo.py 2003/05/28 23:11:45 *************** *** 276,282 **** mm_cfg.AuthListModerator, mm_cfg.AuthListAdmin, mm_cfg.AuthSiteAdmin]) ! replacements[''] = mlist.FormatFormStart('roster') replacements[''] = mlist.FormatRosterOptionForUser(lang, persona) # Options form substitutions replacements[''] = mlist.FormatFormStart('options') --- 276,286 ---- mm_cfg.AuthListModerator, mm_cfg.AuthListAdmin, mm_cfg.AuthSiteAdmin]) ! if mlist.private_roster: ! replacements[''] = mlist.FormatFormStart('roster', ! absolute=1, upgrade=1) ! else: ! replacements[''] = mlist.FormatFormStart('roster') replacements[''] = mlist.FormatRosterOptionForUser(lang, persona) # Options form substitutions replacements[''] = mlist.FormatFormStart('options') From marisa at stat.umn.edu Tue Jun 10 13:23:54 2003 From: marisa at stat.umn.edu (Marisa Riviere) Date: Tue Jun 10 13:23:58 2003 Subject: [Mailman-Developers] alternate root for mailman Message-ID: <20030610172354.886ED4490@muskrat.stat.umn.edu> I am updating mailman to a new version but until I can test all the changes I like to run two versions of the program. I am working in a SuSE Linux 8.0 system. For the old versions I used the default settings and defined: ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ Alias /pipermail/ /var/lib/mailman/archives/public/ For the new version (2.1.2) I am using user "mail_man" and: 1) a "configure" command such as: ./configure --prefix=/usr/local/mail_man --with-var-prefix=/var/mail_man --with-username=mail_man --with-groupname=mail_man --with-mail-gid=65533 --with-cgi-gid=65534 2) a definition of where the Papermail directory will be in ../Mailman/mm_cfg.py (I set this before "configure".) PUBLIC_ARCHIVE_URL = 'http://%(hostname)s/piper_mail/%(listname)s' and 3) an addition to the Apache httpd configuration for the new mail_man: ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ Alias /pipermail/ /var/lib/mailman/archives/public/ Options +FollowSymLinks ScriptAlias /mail_man/ /usr/local/mail_man/cgi-bin/ Alias /piper_mail/ /var/mail_man/archives/public/ Options +FollowSymLinks Things work "up to a certain point"... I can create new lists and the lists are stored in my new paper_mail root OK. I also can locate the lists management entry with the web page entry: http://stat.umn.edu/mail_man/admin. The problem is that when I want to access any one of the new lists that I created to be managed by the new version of the program I can not access the information on those lists. If I look at the information on the configuration of the list by using the unix "strings" command on the binary I see that that list points to a web page in the old root: > strings /var/mail_man/lists/test212b/config.pck . . web_page_urlqNU$http://muskrat.stat.umn.edu/mailman/qOU . . I am so confuse that it is hard to post a question! But some how I wander if 1) I am missing some information for "configure" or 2) Am I right to assume the the problem may be on the "admin" binary that has enough information about the new root (paper_mail) to place the list there but it is not capable of placing that information in the configuration of the list? And finally, two different question that I will need to deal with as well are: How can I eliminate references to "muskrat.stat.umn.edu" and use only "stat.umn.edu"? Muskrat is an alias for our system but we may like to change it to another piece of hardware sometime. I am not telling the name "muskrat" to the configuration files but it seems to pick it somewhere. How do I convert the old lists two the new version of mailman? Thanks for your help! -- Marisa Riviere U of M - Statistics marisa@stat.umn.edu 612-624-5859 "Aun es tarde, si, pero ya vamos" - N. R. From marisa at stat.umn.edu Tue Jun 10 15:22:44 2003 From: marisa at stat.umn.edu (Marisa Riviere) Date: Tue Jun 10 15:22:49 2003 Subject: [Mailman-Developers] alternate root for mailman - part 2 Message-ID: <20030610192245.039534592@muskrat.stat.umn.edu> It seems that I find the answer to the first part of my question. I should include the line: DEFAULT_URL_PATTERN = 'http://%s/mail_man/' in mm_cfg.py as well. Please tell me if I need some thing else. I still need to know how to convert existing lists from one version to other (2.0.8 to 2.1.2) as well as from one system to other. How do I change the host system in each list's configuration? Thanks again. Forwarded message: > From marisa Tue Jun 10 12:23:54 2003 > Subject: alternate root for mailman > To: mailman-developers@python.org > Date: Tue, 10 Jun 2003 12:23:54 -0500 (CDT) > X-Mailer: ELM [version 2.5 PL6] > Content-Length: 2948 > Lines: 98 > > > I am updating mailman to a new version but until I can test > all the changes I like to run two versions of the program. > I am working in a SuSE Linux 8.0 system. > > For the old versions I used the default settings and defined: > > ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ > Alias /pipermail/ /var/lib/mailman/archives/public/ > > For the new version (2.1.2) I am using user "mail_man" and: > > 1) a "configure" command such as: > > ./configure --prefix=/usr/local/mail_man --with-var-prefix=/var/mail_man > --with-username=mail_man --with-groupname=mail_man --with-mail-gid=65533 > --with-cgi-gid=65534 > > 2) a definition of where the Papermail directory will be in > ../Mailman/mm_cfg.py (I set this before "configure".) > > PUBLIC_ARCHIVE_URL = 'http://%(hostname)s/piper_mail/%(listname)s' > > and > > 3) an addition to the Apache httpd configuration for the new > mail_man: > > ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/ > Alias /pipermail/ /var/lib/mailman/archives/public/ > > > Options +FollowSymLinks > > > ScriptAlias /mail_man/ /usr/local/mail_man/cgi-bin/ > Alias /piper_mail/ /var/mail_man/archives/public/ > > > Options +FollowSymLinks > > > > Things work "up to a certain point"... I can create new lists and the > lists are stored in my new paper_mail root OK. I also can locate the > lists management entry with the web page entry: > http://stat.umn.edu/mail_man/admin. > > The problem is that when I want to access any one of the new lists > that I created to be managed by the new version of the program I can not > access the information on those lists. > > If I look at the information on the configuration of the list > by using the unix "strings" command on the binary I see that that > list points to a web page in the old root: > > > strings /var/mail_man/lists/test212b/config.pck > . > . > web_page_urlqNU$http://muskrat.stat.umn.edu/mailman/qOU > > . > . > > I am so confuse that it is hard to post a question! But some how I > wander if > > 1) I am missing some information for "configure" > > or > > 2) Am I right to assume the the problem may be on the "admin" binary > that has enough information about the new root (paper_mail) to place the > list there but it is not capable of placing that information in the > configuration of the list? > > And finally, two different question that I will need to deal with as well > are: > > How can I eliminate references to "muskrat.stat.umn.edu" and use > only "stat.umn.edu"? Muskrat is an alias for our system but we may > like to change it to another piece of hardware sometime. I am not > telling the name "muskrat" to the configuration files but it seems to > pick it somewhere. > > How do I convert the old lists two the new version of mailman? > > > Thanks for your help! > -- Marisa Riviere U of M - Statistics marisa@stat.umn.edu 612-624-5859 "Aun es tarde, si, pero ya vamos" - N. R. From barry at python.org Tue Jun 10 21:00:21 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 10 16:00:22 2003 Subject: [Mailman-Developers] alternate root for mailman - part 2 In-Reply-To: <20030610192245.039534592@muskrat.stat.umn.edu> References: <20030610192245.039534592@muskrat.stat.umn.edu> Message-ID: <1055275186.9634.51.camel@barry> On Tue, 2003-06-10 at 15:22, Marisa Riviere wrote: > It seems that I find the answer to the first part of my question. > I should include the line: > DEFAULT_URL_PATTERN = 'http://%s/mail_man/' > in mm_cfg.py as well. Please tell me if I need some thing else. Yes, this will work for new lists, but not for existing lists (see below). > I still need to know how to convert existing lists from one > version to other (2.0.8 to 2.1.2) as well as from one system > to other. How do I change the host system in each list's > configuration? Upgrading is simple. First move the following directories from the old system to the new: - lists/ - archives/private/ - archives/private/.mbox Then run bin/fix_url.py which updates the list's web_page_url attribute to jive with your new setting of DEFAULT_URL_PATTERN. Everything else will be handled automatically by Mailman (you can ignore the spurious warnings that show up in logs/error). I do this all the time on python.org/zope.org as I'm in the process of moving all our lists from 2.0.13 to 2.1.2. -Barry From barry at python.org Wed Jun 11 00:14:40 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 10 19:14:42 2003 Subject: [Mailman-Developers] ssl for admin pages In-Reply-To: <200306092255.h59Mtbu6027746@mailhost1.u.washington.edu> References: <200306092255.h59Mtbu6027746@mailhost1.u.washington.edu> Message-ID: <1055286846.9634.90.camel@barry> On Mon, 2003-06-09 at 18:55, Donn Cave wrote: > I added a parameter to ScriptURL(..., upgrade=0) and a couple of > functions to deal with the protocol part of the URL (http vs. https.) > The upgrade parameter indicates that the URL must be https. And then > I had to change a few modules other than Utils.py - some to specify a > "true" value for upgrade, if for example the link is to an archive > page that is protected, and some to pass this upgrade parameter through > from there to ScriptURL() (GetScriptURL(), for example.) This seems like a reasonable approach. -Barry From barry at python.org Wed Jun 11 00:18:47 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 10 19:18:48 2003 Subject: [Mailman-Developers] Using the correct host In-Reply-To: <3ED803D6.9000007@nc.rr.com> References: <3ED803D6.9000007@nc.rr.com> Message-ID: <1055287093.9634.94.camel@barry> On Fri, 2003-05-30 at 21:22, Ernest Christley wrote: > I've been trying to set up a list behind my firewall on the local > network. The machine hosting mailman uses 192.168.0.2 as a static IP, > but the world sees me as ernest.isa-geek.org, the DNS entry I got > through dyndns.org. > > If you try to subscribe to the list I created, the subscribe button > sends the request to 192.168.0.2 instead of ernest.isa-geek.org. While > that works fine from here, people out there aren't having any luck. > > How do I make the subscribe button use the dns name vs the IP? > > You can see what I'm talking about by going here and trying to subscribe > to the list: > > http://www.ernest.isa-geek.org/mailman/listinfo/deltaflyers > > I just noticed that the listinfo page says that there "currently are no > publicly-advertised Mailman mailing lists on www.ernest.isa-geek.org". > How do I make the list publicly-advertised? It sounds like you need to fix DEFAULT_URL_HOST and run bin/fix_urls.py -Barry From chk at pobox.com Tue Jun 10 23:18:13 2003 From: chk at pobox.com (Harald Koch) Date: Tue Jun 10 22:18:35 2003 Subject: [Mailman-Developers] Re: ssl for admin pages Message-ID: <25927.1055297893@persephone.cfrq.net> > in indymedia (http://indymedia.org) and sindominio > (http://sindomino.net) we saw the necessity to protect the admin part > of mailman (above all the password transmission) with a ssl > connection. We protect all of mailman with an Apache rewrite rule. This is probably overkill for public archives, but since all of our archives are private: RewriteCond %{HTTPS} !=on RewriteRule ^/mailman/(.*) https://%{SERVER_NAME}/mailman/$1 [R,L] Simple, and survives upgrades :-) -- Harald Koch http://blog.cfrq.net/chk/ When you have accidentally boarded the wrong train, there is no point running down the corridor in the opposite direction. From dereks at realloc.net Sun Jun 1 20:32:31 2003 From: dereks at realloc.net (Derek Simkowiak) Date: Wed Jun 11 08:13:14 2003 Subject: [Mailman-Developers] Virtual Domain update? Message-ID: <3EDAB73F.4090908@realloc.net> What is the current status of virtual domain support? (By "virtual domain support", I am referring to the ability of a single Mailman installation to serve lists in different domains, even if the lists have the same "name"). The only up-to-date information I could find is this from the file NEWS: ---------------------------------------------- 2.1 beta 4 (26-Oct-2002) [...] o bin/fix_url.py grew some command line options to support moving a list to a specific virtual domain. 2.1 alpha 3 (22-Oct-2001) [...] 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). ---------------------------------------------- If one can move a list "to a specific virtual domain", that would imply support for virtual domains. And yet I cannot find any information about this feature. In fact, README.EXIM (I happen to use Exim) specifically states that virtual domains (with overlapping list names) are not yet supported. As an admin trying to find information about virtual domain support, this has been a frustrating experience. (Also, this seems like it would be a feature high on the priority list, but I've been waiting for over a year for it. Why not simply save lists/stuff as lists/domain/stuff?) Thanks, Derek Simkowiak dereks@realloc.net From dereks at realloc.net Tue Jun 3 14:44:16 2003 From: dereks at realloc.net (Derek Simkowiak) Date: Wed Jun 11 08:13:16 2003 Subject: [Mailman-Developers] multiple domain status update (second request) Message-ID: <3EDD08A0.3010402@realloc.net> Hello, I'm looking for a status update on "virtual domain" support. (This is my second request for information.) I would like to know whether the same list name under more than one domain is supported yet. There are some cryptic comments in the file "NEWS". In particular: ------------------------------------ o bin/fix_url.py grew some command line options to support moving a list to a specific virtual domain. ------------------------------------ This seems to imply that a list can now be attached to "a specific virtual domain", but I cannot find any other documentation about this feature. Who wrote that line? Can that developer answer a few basic questions for me? I also have a few hours of programming time to donate and a live test server to get virtual domains support working (if they're not already). If anyone has any information at all (even which .py files to go looking through), please let me know. I have no familiarity with the Mailman code (yet). Thank You, Derek Simkowiak dereks@realloc.net From gustavo at scire.coppe.ufrj.br Mon Jun 9 18:28:29 2003 From: gustavo at scire.coppe.ufrj.br (Gustavo Gouvea) Date: Wed Jun 11 08:13:18 2003 Subject: [Mailman-Developers] Mass subscribe with sync_members... Message-ID: <3EE4EDED.4C8155CD@scire.coppe.ufrj.br> Hi all, Sorry about posting in 2 lists, I just dont know the best list to post in. I?ve just implemented Mailman 2.0.13 in my company and I got some problems: I have a file with 3000 email addr, that is sent through ftp every day to my mail server. Then I used "sync_members -f file-name listname" to keep the list sycronized with that file. I cannot guarantee that all mail addr on the list is valid, and I cannot filter that. If one addr is invalid the script aborts. This is my first problem. Question-1: Can I make Mailman just read the file with email addrs just like sendmail "aliases :include:" files, without using "sync_members"? Question-2: If using "sync_members" can I disable "ValidateMail"? Will Mailman crash with invalid addr like "user@domain.com; user2@other.com" (2 addresses in one line, like some address in my file) if I disable that check? I am not a "full" programmer, so I dont want to mess with the source code... But disabling the ValidateMail seems easy... Any easy solution? Question-3: My 3000 mail list is uploaded only when its changed, so I dont know when it will be uploaded. I realized I?ll have to run "sync_members" every 5 or 1 minute in crontab to guarantee my list is in sync. Is there any way I can tell Mailman to run "sync_members -f filename listname" every time a message arrives for the list? I just like to know yes or no? Thanks a lot! I will apreciate any comments. From romans at yandex.ru Wed Jun 11 15:46:45 2003 From: romans at yandex.ru (Roman Sinelnikov) Date: Wed Jun 11 08:13:19 2003 Subject: [Mailman-Developers] Majordomo-style moderation Message-ID: <000e01c33006$c18546e0$426490d9@mainmshrpc> Dear colleagues, In my opinion the only and very important trait of Mailman is impossibility to moderate the lists in Majordomo style, by adding "approved: password" line at the top of "technical" e-mail message and then sending it to the listserv. The web interface for moderation is extremely inconvenient if the moderator has a dial-up connection to the Internet and need to pay for each minute or if the language of communnication supposes several characters encodings, like Russian. In Majordomo I am able to solve all the problems and prepare the messages for delivery offline, why cannot I do it in Mailman? Sincerely yours, Roman Sinelnikov From romans at yandex.ru Wed Jun 11 15:50:22 2003 From: romans at yandex.ru (Roman Sinelnikov) Date: Wed Jun 11 08:13:21 2003 Subject: [Mailman-Developers] Cutting "Received:" headers Message-ID: <000f01c33007$42b1d1c0$426490d9@mainmshrpc> Dear colleagues, one more idea, it would be very convenient to have an optional cutting of "Received:" headers in any e-mail message before its sending by Mailman to the list members. Sincerely yours, Roman Sinelnikov From jam at jamux.com Wed Jun 11 10:38:39 2003 From: jam at jamux.com (John A. Martin) Date: Wed Jun 11 09:38:44 2003 Subject: [Mailman-Developers] Cutting "Received:" headers In-Reply-To: <000f01c33007$42b1d1c0$426490d9@mainmshrpc> (Roman Sinelnikov's message of "Wed, 11 Jun 2003 14:50:22 +0400") References: <000f01c33007$42b1d1c0$426490d9@mainmshrpc> Message-ID: <87r8607mzk.fsf@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Roman" == Roman Sinelnikov >>>>> "[Mailman-Developers] Cutting "Received:" headers" >>>>> Wed, 11 Jun 2003 14:50:22 +0400 Roman> Dear colleagues, one more idea, it would be very convenient Roman> to have an optional cutting of "Received:" headers in any Roman> e-mail message before its sending by Mailman to the list Roman> members. Rfc2822 Section 3.6.6 jam -----BEGIN PGP SIGNATURE----- iD8DBQE+5zC3UEvv1b/iXy8RArUKAJ99e/5KMuEuk16oAcvh5vs6no+ptACdEVW7 UA5UAJOuy1X8LGhRcD3XOBE= =pYHM -----END PGP SIGNATURE----- From terri at zone12.com Wed Jun 11 13:05:24 2003 From: terri at zone12.com (Terri Oda) Date: Wed Jun 11 12:03:07 2003 Subject: [Mailman-Developers] Majordomo-style moderation In-Reply-To: <000e01c33006$c18546e0$426490d9@mainmshrpc> References: <000e01c33006$c18546e0$426490d9@mainmshrpc> Message-ID: <20030611160524.GD692@ostraya.zone12.com> On Wed, Jun 11, 2003 at 02:46:45PM +0400, Roman Sinelnikov wrote: > In my opinion the only and very important trait of Mailman is > impossibility to moderate the lists in Majordomo style, by adding > "approved: password" line at the top of "technical" e-mail message and > then sending it to the listserv. The web interface for moderation is > extremely inconvenient if the moderator has a dial-up connection to the > Internet and need to pay for each minute or if the language of > communnication supposes several characters encodings, like Russian. In > Majordomo I am able to solve all the problems and prepare the messages > for delivery offline, why cannot I do it in Mailman? >From a post-held notification, I quote: "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." So just go ahead and do as you describe with the Approved: header and everything should work as expected. Terri From tneff at bigfoot.com Wed Jun 11 13:57:09 2003 From: tneff at bigfoot.com (Tom Neff) Date: Wed Jun 11 12:57:15 2003 Subject: [Mailman-Developers] Re: Cutting "Received:" headers (John A. Martin) In-Reply-To: References: Message-ID: <568328765.1055336229@[192.168.0.16]> jam@jamux.com (John A. Martin) wrote: >[Roman Sinelnikov wrote:] >> Dear colleagues, one more idea, it would be very convenient >> to have an optional cutting of "Received:" headers in any >> e-mail message before its sending by Mailman to the list >> members. > > Rfc2822 Section 3.6.6 Concise, but wrong for the following reasons. 1. "Received:" is a Trace field, not a Resent field, and hence is covered in RFC 2821, not 2822: http://www.ietf.org/rfc/rfc2821.txt 2. The rules laid out in RFC2821-2 for preserving Trace and similar fields explicitly apply to SMTP relays and gateways, i.e., nodes whose job is to transport mail from sender to an explicit recipient. A mailing list manager is not an SMTP relay or gateway. It is an automated correspondent -- one that collects the results of one or more successful (RFC2821-2 compliant) mail transactions, and then under controlled (moderated, filtered, digested, etc) circumstances, causes zero or more NEW RFC-compliant mail transactions to be created as a result. Mailing list managers are under no obligation to masquerade themselves as SMTP relays or gateways, and in general they don't try to do so. They make all kinds of changes to envelopes, headers, message bodies, etc, that no SMTP relay or gateway would be permitted to do. The entire concept of a Digest (plain text or MIME) would break RFC2821-2. The entire concept of the List-XXXX: headers would break them. Per-message suffixes break them. And so forth. The purpose of the Received: trace field is to allow a mail administrator to identify and, if necessary, troubleshoot the relay path that a message followed before reaching his or her site (which might not even be the intended destination, mail problems being what they are). The case can be made that once a message has successfully arrived at the listserv/Mailman collector, this information is of no further use and may as well be dropped. (In that case, listmembers would still have Received: headers in their list messages, but only from the path between the posting host and their own machines.) On the other hand, I know of lists where the members are much more net.savvy than the listowner of record, so that if something does come up, their ability to see all the Received: headers can be helpful. I would be in favor of a "clean_headers" per-list option which, if True, would remove all but a minimal, rational set of headers from messages before they are reposted. In the meantime, any site admin who wants to do this kind of cleaning can easily insert "formail" or "reformail" into the alias pipeline for the posting address. These are utilities supplied with "procmail" and "maildrop" respectively, and widely available on the Net. From jam at jamux.com Wed Jun 11 15:49:26 2003 From: jam at jamux.com (John A. Martin) Date: Wed Jun 11 14:49:32 2003 Subject: [Mailman-Developers] Re: Cutting "Received:" headers (John A. Martin) In-Reply-To: <568328765.1055336229@[192.168.0.16]> (Tom Neff's message of "Wed, 11 Jun 2003 12:57:09 -0400") References: <568328765.1055336229@[192.168.0.16]> Message-ID: <87y9085u15.fsf@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Tom" == Tom Neff >>>>> "[Mailman-Developers] Re: Cutting "Received:" headers (John A. Martin)" >>>>> Wed, 11 Jun 2003 12:57:09 -0400 Tom> jam@jamux.com (John A. Martin) wrote: >> [Roman Sinelnikov wrote:] >>> Dear colleagues, one more idea, it would be very convenient to >>> have an optional cutting of "Received:" headers in any e-mail >>> message before its sending by Mailman to the list members. >> >> Rfc2822 Section 3.6.6 Tom> Concise, but wrong for the following reasons. Tom> 1. "Received:" is a Trace field, not a Resent field, and Tom> hence is covered in RFC 2821, not 2822: Indeed. I was too quick and my eyes too dim. Without going back for chapter and verse it is my understanding that if you change the Message-ID field you may start a new trace but that if you do not change the Message-ID you should only add to the trace. Without changing the Message-ID it does not seem that a respectable mailing list should do anything more than append to the end on the body of a mail message. If a moderator edits a message it should be a new message. Some will drop MIME parts. I would reject the mail rather than change it. For example, I PGP sign all non-trivial mail and have done so for years to establish plausible deniability for mail without my PGP signature. If I discover that a PGP signed mail of mine has been altered I will disclaim all responsibility for it. If that were to happen repeatedly on a mailing list I would object to my mail being altered an I would withdraw from the list. I have not known this to happen however. jam -----BEGIN PGP SIGNATURE----- iD8DBQE+53mwUEvv1b/iXy8RApUDAJ9yrrjU3HEX+bDcUp3UEK1D03ImPwCbBoXM f4L3hRmP8w3l7sOYZD09ldU= =hsx8 -----END PGP SIGNATURE----- From pioppo at ferrara.linux.it Wed Jun 11 22:12:27 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Wed Jun 11 15:14:52 2003 Subject: [Mailman-Developers] Majordomo-style moderation In-Reply-To: <20030611160524.GD692@ostraya.zone12.com> References: <000e01c33006$c18546e0$426490d9@mainmshrpc> <20030611160524.GD692@ostraya.zone12.com> Message-ID: <200306112112.27266.pioppo@ferrara.linux.it> On Wednesday 11 June 2003 18:05, Terri Oda wrote: > "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." while we're at it, I've tried to approve this way a couple of times, adding Approved to the 1st line of body, but: 1. message hasn't been posted to the list 2. message got discarded (ugh!) I suspect there's a bug somewhere but I hadn't investigated further. Anyone uses this feature successfully? Regards, Simone -- Adde parvum parvo magnus acervus erit -- Ovidio From mentor at alb-net.com Thu Jun 12 18:27:37 2003 From: mentor at alb-net.com (Mentor Cana) Date: Thu Jun 12 17:27:42 2003 Subject: [Mailman-Developers] ssl for admin pages In-Reply-To: <20030609214101.GU21064@rantanplan> References: <20030609214101.GU21064@rantanplan> Message-ID: I would also like to see this patch as part of Mailman. I tried it and it works just fine. thanks, Mentor -------------- next part -------------- Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers From barry at python.org Fri Jun 13 22:32:53 2003 From: barry at python.org (Barry Warsaw) Date: Fri Jun 13 17:32:54 2003 Subject: [Mailman-Developers] Re: Cutting "Received:" headers (John A. Martin) In-Reply-To: <568328765.1055336229@[192.168.0.16]> References: <568328765.1055336229@[192.168.0.16]> Message-ID: <1055539938.8384.111.camel@barry> On Wed, 2003-06-11 at 12:57, Tom Neff wrote: > The purpose of the Received: trace field is to allow a mail administrator to > identify and, if necessary, troubleshoot the relay path that a message > followed before reaching his or her site (which might not even be the > intended destination, mail problems being what they are). The case can be > made that once a message has successfully arrived at the listserv/Mailman > collector, this information is of no further use and may as well be dropped. > (In that case, listmembers would still have Received: headers in their list > messages, but only from the path between the posting host and their own > machines.) The other case can be made that retaining Received headers has very practical benefits. For example, it occasionally happens that a piece spam sneaks through our filters (I /know/! Imagine that. ;). Then python.org gets blamed for spamming people. Having the Received headers in there has so far proved that the spam did not originate from us. > I would be in favor of a "clean_headers" per-list option which, if True, > would remove all but a minimal, rational set of headers from messages before > they are reposted. Which headers should be removed? I guess you'd need a general mechanism to clean out any header. Personally, I don't think the Received headers are any problem. > In the meantime, any site admin who wants to do this kind of cleaning can > easily insert "formail" or "reformail" into the alias pipeline for the > posting address. These are utilities supplied with "procmail" and "maildrop" > respectively, and widely available on the Net. And of course, it would be easy to edit Cleanse.py or add a new, fancier handler module in the standard Mailman pipeline to get rid of these headers. -Barry From tneff at bigfoot.com Fri Jun 13 20:42:23 2003 From: tneff at bigfoot.com (Tom Neff) Date: Fri Jun 13 19:42:28 2003 Subject: [Mailman-Developers] Re: Cutting "Received:" headers In-Reply-To: <1055539938.8384.111.camel@barry> References: <568328765.1055336229@[192.168.0.16]> <1055539938.8384.111.camel@barry> Message-ID: <765440578.1055533343@[192.168.0.16]> --On Friday, June 13, 2003 5:32 PM -0400 Barry Warsaw wrote: > The other case can be made that retaining Received headers has very > practical benefits. For example, it occasionally happens that a piece > spam sneaks through our filters (I /know/! Imagine that. ;). Then > python.org gets blamed for spamming people. Having the Received headers > in there has so far proved that the spam did not originate from us. Hey, I completely agree that keeping Received: can be very useful, and for my own lists I would probably not select "clean_headers" if it were implemented. But I can see where some people might prefer it, and I don't agree that it is somehow "RFC forbidden" to do such a thing: listservs are not SMTP relays or gateways in the sense of the term used by RFC2821-2. That was the point of my posting. >> I would be in favor of a "clean_headers" per-list option which, if True, >> would remove all but a minimal, rational set of headers from messages >> before they are reposted. > > Which headers should be removed? I guess you'd need a general mechanism > to clean out any header. Personally, I don't think the Received headers > are any problem. It would be more like "which headers are retained." I would suggest From, To, Subject, Reply-To, Message-Id, In-Reply-To, and of course Content-Type and other MIME headers as appropriate. Everything else, including old Spam scores, X-Nostradamus-Lives headers, stale Receiveds, etc, etc, would be gone. Of course you could embed an exact "retain list" somewhere in mm_cfg.py if you wanted, so that tinkerers could add or remove headers to fit their sites' needs. >> In the meantime, any site admin who wants to do this kind of cleaning can >> easily insert "formail" or "reformail" into the alias pipeline for the >> posting address. These are utilities supplied with "procmail" and >> "maildrop" respectively, and widely available on the Net. > > And of course, it would be easy to edit Cleanse.py or add a new, fancier > handler module in the standard Mailman pipeline to get rid of these > headers. Yeah, but that's a lot more forking for a little bit of work... From tneff at bigfoot.com Sat Jun 14 15:07:10 2003 From: tneff at bigfoot.com (Tom Neff) Date: Sat Jun 14 14:07:14 2003 Subject: [Mailman-Developers] Re: Cutting "Received:" headers In-Reply-To: References: Message-ID: <831726906.1055599630@[192.168.0.16]> I had written: > In the meantime, any site admin who wants to do this kind of cleaning can > easily insert "formail" or "reformail" into the alias pipeline for the > posting address. These are utilities supplied with "procmail" and > "maildrop" respectively, and widely available on the Net. to which Barry replied: > And of course, it would be easy to edit Cleanse.py or add a new, fancier > handler module in the standard Mailman pipeline to get rid of these > headers. and then I said: > Yeah, but that's a lot more forking for a little bit of work... and now I want to clarify the above: I thought Barry meant you could throw an exec of 'formail' into the Mailman pipeline. This wouldn't mean more forking than my in-the-alias method, but both methods have a lot more process churn than just stripping the headers in the Mailman code. On rereading it's clear that Barry also means you could do it in code but in a handler. That's great, but I'd think you'd still want a per-list option, and/or an exact list of headers to retain in the mm_cfg. What am I doing reading this digest when the sun finally came out! Bye :) From matze at indymedia.org Sun Jun 15 00:47:48 2003 From: matze at indymedia.org (matze) Date: Sat Jun 14 17:47:57 2003 Subject: [Mailman-Developers] pending posts navigation Message-ID: <20030614214748.GH2804@rantanplan> i just uploaded the following patch to sourceforge: "this patch permits to limit the number of posts shown in the pending admin interface. only mm_cfg.NUM_HELDS_PER_PAGE posts are shown per page, 'prev' and 'next' links are shown on the bottom of the page if needed" https://sourceforge.net/tracker/index.php?func=detail&aid=754661&group_id=103&atid=300103 /mtz -- ( ( ( i ) ) ) http://barcelona.indymedia.org ( ( ( i ) ) ) * using free software / Debian GNU/Linux | http://debian.org * gpg --keyserver keys.indymedia.org --recv-keys B9A88F6F "La guerra es un acto abominable en el que se matan personas que no se conocen, dirigidas por personas que se conocen y no se matan" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030614/6cef783a/attachment.bin From Daniel.Buchmann at bibsys.no Sun Jun 15 00:45:36 2003 From: Daniel.Buchmann at bibsys.no (Daniel Buchmann) Date: Sat Jun 14 19:45:38 2003 Subject: [Mailman-Developers] moving a list to a new version (was: alternate root for mailman - part 2) In-Reply-To: <1055275186.9634.51.camel@barry> References: <20030610192245.039534592@muskrat.stat.umn.edu> <1055275186.9634.51.camel@barry> Message-ID: <1055634298.2219.12.camel@fornax.hjemme.bibsys.no> On Tue, 2003-06-10 at 21:59, Barry Warsaw wrote: > > I still need to know how to convert existing lists from one > > version to other (2.0.8 to 2.1.2) as well as from one system > > to other. How do I change the host system in each list's > > configuration? > > Upgrading is simple. First move the following directories from the old > system to the new: > > - lists/ > - archives/private/ > - archives/private/.mbox It would also be a good idea to make sure no requests are pending for before moving it, though.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030614/2b68c381/attachment.bin From larva at linux.ucla.edu Wed Jun 18 16:38:33 2003 From: larva at linux.ucla.edu (Matt Helsley) Date: Wed Jun 18 18:39:09 2003 Subject: [Mailman-Developers] Indirect Spam Vulnerability Message-ID: I thought I'd describe a spam problem related to mailman I'm having and propose the solution. If anyone can tell me one way or another whether mailman avoids this "spam attack" I would appreciate it. I have two lists: foo@myhost.com moderated@myhost.com The spammer sends forged as foo@myhost.com to moderated@myhost.com. The mail gets held for approval and a message gets sent to foo@myhost.com informing it that the message has been held (often times the subject line is mentioned and contains lewd content which I'd rather not have sent out to subscribers on foo@myhost.com). This is why I used the word 'indirect spam'. Couldn't mailman redirect bounce/moderation notifications in the case where the FROM address is a mailman list and send it to the site/list administrator instead (or maybe drop it completely??)? I think this would avoid spamming the list subscribers while adding a minor load to the administrator's work. Does mailman 2.1.x already do this? If not, would this break something in mailman? Is it unreasonably restrictive on the site/list administrator(s)? I'm running 2.0.x (debian stable iirc) Thanks, -Matt Helsley From barry at python.org Thu Jun 19 00:35:36 2003 From: barry at python.org (Barry Warsaw) Date: Wed Jun 18 19:35:37 2003 Subject: [Mailman-Developers] Indirect Spam Vulnerability In-Reply-To: References: Message-ID: <1055979293.18856.2.camel@anthem> On Wed, 2003-06-18 at 18:38, Matt Helsley wrote: > I have two lists: foo@myhost.com > moderated@myhost.com > > The spammer sends forged as foo@myhost.com to moderated@myhost.com. The > mail gets held for approval and a message gets sent to foo@myhost.com > informing it that the message has been held (often times the subject line > is mentioned and contains lewd content which I'd rather not have sent out > to subscribers on foo@myhost.com). This is why I used the word 'indirect > spam'. Nice. :( > Couldn't mailman redirect bounce/moderation notifications in the case > where the FROM address is a mailman list and send it to the site/list > administrator instead (or maybe drop it completely??)? I think this would > avoid spamming the list subscribers while adding a minor load to the > administrator's work. > > Does mailman 2.1.x already do this? If not, would this break something in > mailman? Is it unreasonably restrictive on the site/list administrator(s)? Mailman doesn't do this, and it's not a bad idea. Of course, the best you can do is prevent indirect spam within the same Mailman instance. Another approach would be to set up a "suspicious header" hold on "Message-ID: Message-ID: On 18 Jun 2003, Barry Warsaw wrote: > > Couldn't mailman redirect bounce/moderation notifications in the case > > where the FROM address is a mailman list and send it to the site/list > > administrator instead (or maybe drop it completely??)? I think this would > > avoid spamming the list subscribers while adding a minor load to the > > administrator's work. > > > > Does mailman 2.1.x already do this? If not, would this break something in > > mailman? Is it unreasonably restrictive on the site/list administrator(s)? > > Mailman doesn't do this, and it's not a bad idea. Of course, the best > you can do is prevent indirect spam within the same Mailman instance. > Another approach would be to set up a "suspicious header" hold on > "Message-ID: Mailman uses to send out mail. IWBNI you could actually configure > Mailman to drop such messages. > > -Barry Would the hold be activated on the notification arriving at the spoofed mailing list, or would it be activated on the post to the moderated list? i.e: 1) -spam-> moderated@myhost.com -notification-> *HOLD* foo@myhost.com or would it be: 2) -spam-> moderated@myhost.com *HOLD* -notification-> foo@myhost.com I guess part of the issue is which list admin (assuming they are separate admins) should have to deal with this problem? I'd say you want the moderated list admin to deal with it because they were the immediate recipient (their policy should not cause others to suffer :), plus they may somehow have better information with which to analyze the spam). OTOH, knowledge of a spammer who intentionally uses this technique to spam foo@myhost.com may be something the admin of list foo should know about... I tend to favor #2 (moderated list admin) Cheers, -Matt Helsley From donal.hunt2 at mail.dcu.ie Fri Jun 20 13:35:14 2003 From: donal.hunt2 at mail.dcu.ie (Donal Hunt) Date: Fri Jun 20 07:38:21 2003 Subject: [Mailman-Developers] Re: Indirect Spam Vulnerability In-Reply-To: References: Message-ID: <3EF2F172.4050606@mail.dcu.ie> I've actually seen this result in a mail loop between two mailing lists on the same server (both moderated). As a result it can cause a DOS attack (slowing down the machine considerably). This was with Mailman 2.0, so 2.1 may resolve the problem... It's only happened once in 5 years (which i guess is fortunate!) but it something that should be looked at for current realeses if it's still possible to recreate... Regards Donal DCU Matt wrote: > I thought I'd describe a spam problem related to mailman I'm having > and propose the solution. If anyone can tell me one way or another > whether mailman avoids this "spam attack" I would appreciate it. > > I have two lists: foo@myhost.com > moderated@myhost.com > > The spammer sends forged as foo@myhost.com to moderated@myhost.com. > Themail gets held for approval and a message gets sent to > foo@myhost.com informing it that the message has been held (often > times the subject line is mentioned and contains lewd content which > I'd rather not have sent out to subscribers on foo@myhost.com). This > is why I used the word 'indirect spam'. > > Couldn't mailman redirect bounce/moderation notifications in the case > where the FROM address is a mailman list and send it to the site/list > administrator instead (or maybe drop it completely??)? I think this > would avoid spamming the list subscribers while adding a minor load to > the administrator's work. > > Does mailman 2.1.x already do this? If not, would this break something > in mailman? Is it unreasonably restrictive on the site/list > administrator(s)? > > I'm running 2.0.x (debian stable iirc) > > Thanks, > -Matt Helsley From pioppo at ferrara.linux.it Sat Jun 21 00:04:30 2003 From: pioppo at ferrara.linux.it (Simone Piunno) Date: Fri Jun 20 17:09:38 2003 Subject: [Mailman-Developers] Indirect Spam Vulnerability In-Reply-To: References: Message-ID: <200306202304.30374.pioppo@ferrara.linux.it> On Thursday 19 June 2003 00:38, Matt Helsley wrote: > I have two lists: foo@myhost.com > moderated@myhost.com > > The spammer sends forged as foo@myhost.com to moderated@myhost.com. The > mail gets held for approval and a message gets sent to foo@myhost.com > informing it that the message has been held (often times the subject line > is mentioned and contains lewd content which I'd rather not have sent out > to subscribers on foo@myhost.com). shouldn't the "held-for-approval" notification be sent as Precedence: bulk and therefore silently discarded by list foo? -- My homepage -> http://www.google.com/search?q=simone%20piunno From pieterb at gewis.nl Sat Jun 21 19:47:15 2003 From: pieterb at gewis.nl (PieterB) Date: Sat Jun 21 12:47:19 2003 Subject: [Mailman-Developers] Links to mailman/python/gnu in footer, data about mailman's use? Message-ID: <20030621164715.A26CA210F8@gewis.win.tue.nl> Hi, I noticed that the icons at the bottom of a mailman page aren't links to resp. Mailman, Python and GNU. Wouldn't it be a good idea to turn them into hyperlinks, so that people can easily find information about the software that's running their mailinglist software. This can also be done in the pipermail footer. BTW Is there any data on the use of mailman and other mailinglist software? (e.g. number of downloads, number of lists, etc). You can see the pageranks of the various mailinglist servers at: http://directory.google.com/Top/Computers/Software/Internet/Servers/Mail/List_Management/?tc=1 I also did a quick lookup of the number of results on several queries: Mailman: about 5,030,000 hits in Google Listserv: about 2,780,000 hits in Google Majordomo: about 3,740,000 hits in Google Mailman+python: about 298,000 hits in Google Mailman+list: about 1,580,000 hits in Google Listserv+list: about 1,230,000 hits in Google Majordomo+list: about 1,140,000 hits in Google Lyris: about 135,000 hits in Google "Mojo Mail": about 9,150. hits in Google PieterB -- http://zwiki.org/PieterB From claw at kanga.nu Tue Jun 24 01:43:29 2003 From: claw at kanga.nu (J C Lawrence) Date: Tue Jun 24 00:43:31 2003 Subject: [Mailman-Developers] TMDA fronted Mailman v2.1 lists In-Reply-To: Message from Barry Warsaw of "02 May 2003 00:02:44 EDT." <1051848164.1655.45.camel@geddy> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> Message-ID: <12736.1056429809@kanga.nu> Things have been a bit busy, but I've finally moved to v2.1.* and Exim4, and in the process have had to adapt my setup for fronting Mailman lists with TMDA and an external optional/controllable MIME processor (MimeFilter, can be turned off on a per-message basis by a custom header). If there's sufficient interest I'll update the HOWTO with the details. There's nothing really hard in the deal, just an excess of details. Interested? ObNote: If you don't know what I'm talking about, please see the UserFAQ and the archives of this list for definitions, implementation details and implications, and prior discussion of same. ObNote2: TMDA as of v0.75 (latest .deb)is not able to read Mailman v2.1 list configurations to extract the membership rosters (the pickle now contains bounce objects so the naive cPickle.load fails). This doesn't create a major problem, just means that you have to comment sections of your TMDA filters until that's fixed. (Jason: If you want example configs and other details, just give me the word and I'll attach them over). -- 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 at python.org Tue Jun 24 13:34:57 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 24 08:34:59 2003 Subject: [Mailman-Developers] TMDA fronted Mailman v2.1 lists In-Reply-To: <12736.1056429809@kanga.nu> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <12736.1056429809@kanga.nu> Message-ID: <1056458063.2667.1.camel@anthem> On Tue, 2003-06-24 at 00:43, J C Lawrence wrote: > ObNote2: TMDA as of v0.75 (latest .deb)is not able to read Mailman > v2.1 list configurations to extract the membership rosters (the pickle > now contains bounce objects so the naive cPickle.load fails). This > doesn't create a major problem, just means that you have to comment > sections of your TMDA filters until that's fixed. (Jason: If you want > example configs and other details, just give me the word and I'll > attach them over). That might be a simple matter of putting $prefix on your PYTHONPATH when you start up TMDA. It needs to find the Mailman.Bouncer module to get the _BounceInfo class. -Barry From barry at python.org Tue Jun 24 13:44:27 2003 From: barry at python.org (Barry Warsaw) Date: Tue Jun 24 08:44:28 2003 Subject: [Mailman-Developers] TMDA fronted Mailman v2.1 lists In-Reply-To: <1056458063.2667.1.camel@anthem> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <12736.1056429809@kanga.nu> <1056458063.2667.1.camel@anthem> Message-ID: <1056458634.2667.5.camel@anthem> On Tue, 2003-06-24 at 08:34, Barry Warsaw wrote: > That might be a simple matter of putting $prefix on your PYTHONPATH when > you start up TMDA. It needs to find the Mailman.Bouncer module to get > the _BounceInfo class. Just in case that didn't make sense (c'mon coffee! go for the brain!): Python's pickler encodes the class of the object in the pickle by named reference, so _BounceInfo objects get their class encoded as Mailman.Bouncer._BounceInfo. So when the unpickler pulls the object's state out of the pickle and tries to instantiate one of these objects, it needs to be able to import the class. I'm guess what's happening is that TMDA can't find the Mailman.Bouncer._BounceInfo class. The easy fix would be to put /usr/local/mailman (or whatever your Mailman $prefix is) on your TMDA Python executable's sys.path. E.g. $PYTHONPATH. -Barry From claw at kanga.nu Tue Jun 24 09:57:44 2003 From: claw at kanga.nu (J C Lawrence) Date: Tue Jun 24 08:57:48 2003 Subject: [Mailman-Developers] TMDA fronted Mailman v2.1 lists In-Reply-To: Message from Barry Warsaw of "24 Jun 2003 08:34:24 EDT." <1056458063.2667.1.camel@anthem> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <12736.1056429809@kanga.nu> <1056458063.2667.1.camel@anthem> Message-ID: <18114.1056459464@kanga.nu> On 24 Jun 2003 08:34:24 -0400 Barry Warsaw wrote: > On Tue, 2003-06-24 at 00:43, J C Lawrence wrote: >> ObNote2: TMDA as of v0.75 (latest .deb)is not able to read Mailman >> v2.1 list configurations to extract the membership rosters (the >> pickle now contains bounce objects so the naive cPickle.load fails). >> This doesn't create a major problem, just means that you have to >> comment sections of your TMDA filters until that's fixed. (Jason: If >> you want example configs and other details, just give me the word and >> I'll attach them over). > That might be a simple matter of putting $prefix on your PYTHONPATH > when you start up TMDA. It needs to find the Mailman.Bouncer module > to get the _BounceInfo class. Quite! I'll give this a quick whack shortly. -- 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 marty at heavyreckoning.com Wed Jun 25 23:21:27 2003 From: marty at heavyreckoning.com (Marty Galyean) Date: Wed Jun 25 18:21:28 2003 Subject: [Mailman-Developers] How hard would it be... Message-ID: <1056579657.29336.149.camel@localhost.localdomain> To put a button next to each message in the archives (labeled 'get'?) that when clicked causes MM to send that message to the logged in archive user as an email just as if it had been sent to them in non-digest mode? This would be a good way for people who have 'no-mail' or 'digest' set to reply occasionally to specific posts. And also to reply to a message the user has already deleted locally. I'm assuming private archives that would require logging in so the email address would be handy, but even so, a detour to the log in form would not be a problem if necessary. I'd like to take a shot at this, but would like some pointers and suggestions so as not to go about it the wrong way. Any suggestions? Comments? Thanks, Marty From claw at kanga.nu Sat Jun 28 13:12:29 2003 From: claw at kanga.nu (J C Lawrence) Date: Sat Jun 28 12:12:32 2003 Subject: [Mailman-Developers] Tracebacks from Mailman v2.1 in Debian/Testing In-Reply-To: Message from Barry Warsaw of "02 May 2003 00:02:44 EDT." <1051848164.1655.45.camel@geddy> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> Message-ID: <22903.1056816749@kanga.nu> Barry, Using the Debian 2.1.2-2 package I get the floowing tracebacks on attempted subscribes: File "/var/lib/mailman/scripts/driver", line 87, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 96, in main process_form(mlist, doc, cgidata, language) File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form mlist.AddMember(userdesc, remote) File "/var/lib/mailman/Mailman/MailList.py", line 831, in AddMember text=text, lang=lang) File "/var/lib/mailman/Mailman/Message.py", line 206, in __init__ errors='replace') TypeError: __init__() got an unexpected keyword argument 'errors' and this when attempting to forward mail from the admindb: File "/var/lib/mailman/scripts/driver", line 87, in run_main main() File "/var/lib/mailman/Mailman/Cgi/admindb.py", line 165, in main process_form(mlist, doc, cgidata) File "/var/lib/mailman/Mailman/Cgi/admindb.py", line 760, in process_form preserve, forward, forwardaddr) File "/var/lib/mailman/Mailman/ListAdmin.py", line 184, in HandleRequest forward, addr) File "/var/lib/mailman/Mailman/ListAdmin.py", line 355, in __handlepost lang=lang) File "/var/lib/mailman/Mailman/Message.py", line 206, in __init__ errors='replace') TypeError: __init__() got an unexpected keyword argument 'errors' -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Sat Jun 28 13:16:37 2003 From: claw at kanga.nu (J C Lawrence) Date: Sat Jun 28 12:16:40 2003 Subject: [Mailman-Developers] Handling of Return-Path headers Message-ID: <22938.1056816997@kanga.nu> Mailman should remove any Return-Path headers found in the messages it broadcasts. I've found that there are a number of MTAs out there that will _preferentially_ send bounces back to the address found in a Return-Path header (if there is one in the message) rather than the address listed in the envelope. Not good. Well behaved systems should not generate non-locally delivered messages with Return-Path headers. This is an area where Mailman should be generous in what it accepts and conservative in what it emits. -- 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 at python.org Sat Jun 28 17:45:20 2003 From: barry at python.org (Barry Warsaw) Date: Sat Jun 28 12:45:21 2003 Subject: [Mailman-Developers] Re: Tracebacks from Mailman v2.1 in Debian/Testing In-Reply-To: <22903.1056816749@kanga.nu> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <22903.1056816749@kanga.nu> Message-ID: <1056818684.6280.36.camel@anthem> On Sat, 2003-06-28 at 12:12, J C Lawrence wrote: > Barry, > > Using the Debian 2.1.2-2 package I get the floowing tracebacks on > attempted subscribes: > > File "/var/lib/mailman/scripts/driver", line 87, in run_main > main() > File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 96, in main > process_form(mlist, doc, cgidata, language) > File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form > mlist.AddMember(userdesc, remote) > File "/var/lib/mailman/Mailman/MailList.py", line 831, in AddMember > text=text, lang=lang) > File "/var/lib/mailman/Mailman/Message.py", line 206, in __init__ > errors='replace') > TypeError: __init__() got an unexpected keyword argument 'errors' Something's wrong with the Mailman installation. I'm suspecting that the email package didn't get installed correctly and Message.py is using the email.Header module from whatever version of Python you're using. Look under /var/lib/mailman/pythonlib to see if email 2.5.x is installed. I've seen this before and it always comes down to some Python rpm/package not being installed, usually a -devel one that contains the distutils package. For this and other reasons, I'm going to try to rework the way the email and codecs packages are bundled in Mailman 2.1.3. I want them (at the very least the email package) to be included as source files, not as tgz's that need to be distutils installed. I hope to have time to spin 2.1.3 tomorrow. -Barry From RossBoylan at stanfordalumni.org Sat Jun 28 14:12:26 2003 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Sat Jun 28 16:12:36 2003 Subject: [Mailman-Developers] Re: Tracebacks from Mailman v2.1 in Debian/Testing In-Reply-To: <1056818684.6280.36.camel@anthem> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <22903.1056816749@kanga.nu> <1056818684.6280.36.camel@anthem> Message-ID: <20030628201226.GG2310@wheat.boylan.org> On Sat, Jun 28, 2003 at 12:44:44PM -0400, Barry Warsaw wrote: > On Sat, 2003-06-28 at 12:12, J C Lawrence wrote: > > Barry, > > > > Using the Debian 2.1.2-2 package I get the floowing tracebacks on > > attempted subscribes: > > > > File "/var/lib/mailman/scripts/driver", line 87, in run_main > > main() > > File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 96, in main > > process_form(mlist, doc, cgidata, language) > > File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form > > mlist.AddMember(userdesc, remote) > > File "/var/lib/mailman/Mailman/MailList.py", line 831, in AddMember > > text=text, lang=lang) > > File "/var/lib/mailman/Mailman/Message.py", line 206, in __init__ > > errors='replace') > > TypeError: __init__() got an unexpected keyword argument 'errors' > > Something's wrong with the Mailman installation. I'm suspecting that > the email package didn't get installed correctly and Message.py is using > the email.Header module from whatever version of Python you're using. > Look under /var/lib/mailman/pythonlib to see if email 2.5.x is > installed. I can confirm that email is not installed properly. My debian/testing installation (apt-get upgrade) failed with Traceback (most recent call last): File "/var/lib/mailman/bin/list_lists", line 47, in ? from Mailman import MailList File "/var/lib/mailman/Mailman/MailList.py", line 39, in ? import email.Iterators ImportError: No module named email.Iterators I thought this was because I've been messing around with mailman locally, but it seems not. I filed a Debian bug about the installation problem, though I haven't got a confirmation back. > > I've seen this before and it always comes down to some Python > rpm/package not being installed, usually a -devel one that contains the > distutils package. For this and other reasons, I'm going to try to > rework the way the email and codecs packages are bundled in Mailman > 2.1.3. I want them (at the very least the email package) to be included > as source files, not as tgz's that need to be distutils installed. I > hope to have time to spin 2.1.3 tomorrow. > > -Barry > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From claw at kanga.nu Sat Jun 28 17:33:18 2003 From: claw at kanga.nu (J C Lawrence) Date: Sat Jun 28 16:33:22 2003 Subject: [Mailman-Developers] Re: Tracebacks from Mailman v2.1 in Debian/Testing In-Reply-To: Message from Barry Warsaw of "28 Jun 2003 12:44:44 EDT." <1056818684.6280.36.camel@anthem> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <22903.1056816749@kanga.nu> <1056818684.6280.36.camel@anthem> Message-ID: <25494.1056832398@kanga.nu> On 28 Jun 2003 12:44:44 -0400 Barry Warsaw wrote: > On Sat, 2003-06-28 at 12:12, J C Lawrence wrote: > Something's wrong with the Mailman installation. I'm suspecting that > the email package didn't get installed correctly and Message.py is > using the email.Header module from whatever version of Python you're > using. Look under /var/lib/mailman/pythonlib to see if email 2.5.x is > installed. > I've seen this before and it always comes down to some Python > rpm/package not being installed.... Excellent analysis Barry -- accurate and revealing. Short version of the results: The 2.1.2-2 Mailman package in /testing is broken in that it uses the floor operator, and yet the Python2.1 package shipped in /testing don't -- which means that the python2.1-email package in /testing fails to install properly due to you use of the floor // operator in _compat22.py. Solution: upgrade python2.1 to /unstable and make sure that the python2.1-email package is installed. Hopefully the Debian mailman maintainer will read this (I'll CC this to him later if he doesn't ack me here). > I hope to have time to spin 2.1.3 tomorrow. It would help me if we could squeeze the Return-Path fix in there. TMDA requires a Return-Path header and the work-arounds for the Mailman/TMDA integration are ungraceful. I won't have time today, and likely not tomorrow either alas. If you could delay a bit I can likely do it in the early days of this week. BTW I may finally be able to buy you some of those beers I owe you. I'm on a consulting gig in Groton CT these days (a long and dismal story). Where are you again? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Sat Jun 28 18:24:07 2003 From: claw at kanga.nu (J C Lawrence) Date: Sat Jun 28 17:24:10 2003 Subject: [Mailman-Developers] Re: Tracebacks from Mailman v2.1 in Debian/Testing In-Reply-To: Message from Ross Boylan of "Sat, 28 Jun 2003 13:12:26 PDT." <20030628201226.GG2310@wheat.boylan.org> References: <5.2.0.9.0.20030430124630.026f9888@jbod.calchiro.com> <1051848164.1655.45.camel@geddy> <22903.1056816749@kanga.nu> <1056818684.6280.36.camel@anthem> <20030628201226.GG2310@wheat.boylan.org> Message-ID: <25912.1056835447@kanga.nu> On Sat, 28 Jun 2003 13:12:26 -0700 Ross Boylan wrote: > On Sat, Jun 28, 2003 at 12:44:44PM -0400, Barry Warsaw wrote: >> On Sat, 2003-06-28 at 12:12, J C Lawrence wrote: > > I can confirm that email is not installed properly. My debian/testing > installation (apt-get upgrade) failed with # apt-get -t unstable python2.1 python2.1-email Solved it for me (see my message to Barry). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw at kanga.nu Sun Jun 29 22:17:21 2003 From: claw at kanga.nu (J C Lawrence) Date: Sun Jun 29 21:17:24 2003 Subject: [Mailman-Developers] Minor comments and a possible bug on MM v2.1 Message-ID: <9824.1056935841@kanga.nu> 1) The sliding/N'th_message pseudo-VERP supports rocks. 2) The new admindb interface is a significant improvement. 3) Forwarding messages from the admindb as message/rfc822 parts needs to be optional. Previously I used that feature support heavily to move messages between lists as a moderator as threads drifted. The use of MIME attachments now makes that a pain. 4) I have HOLD_MESSAGES_AS_PICKLES=0 in mm_cfg.py and seem to get occasional orphaned messages in ~mailman/data. There's a held--* file there, but there's no entry in the appropriate matching data structures. I suspect a race condition as the three times this has happened have all been when I've had over 20 messages delivered to a single list within a couple seconds. 5) MTAs that send bounces to Return-path headers in messages rather than the envelope suck. -- 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 gswallow at www.IN.gov Wed Jun 25 11:43:46 2003 From: gswallow at www.IN.gov (Greg Swallow) Date: Tue Jul 8 09:12:24 2003 Subject: [Mailman-Developers] Question about digests Message-ID: <3EF9C332.7050104@www.IN.gov> Hi, I'm running mailman 2.1.2 on Solaris 9, with Qmail 1.0.3 and Python 2.2.2. I'm testing switching mailing lists from our sendmail/majordomo system to our qmail/mailman system, and this issue is a showstopper for us. The issue is that, occasionally, mailman decides to start discarding posts to a list that we host. The vette log states that messages are discarded, but nothing else. At the same time, if I look at the digest.mbox file for this list, all posts that are being discarded are also appended to the digest.mbox file as they come in. The digest.mbox file never grew past its default maximum size of 30Kb: half an hour after digests were supposed to be sent out, its size was 29330 bytes. Only after the list started discarding posts did the size of the digest.mbox file grow past its maximum size, to 107Kb. If I cp digest.mbox digest.mbox.bak ; cat /dev/null > digest.mbox everything starts working again, as normal. Without good logs of what's going on, I have no idea how to pin this issue down. I've also searched all documentation I can find, including the mailing list archives for mailman-users and mailman-developers, and the only query I can find is my own from 6/1/2003. Does anyone have any ideas? BTW, please reply back to me directly. I'm not subscribed to mailman-developers. Thanks in advance. -- -- "I still think the odds are good that you can make a bet on what will be the odds" -- Tub Ring +--------------+--------------------+---------------+----------------+ | Greg Swallow | System Administrator | accessIndiana | 888.4IN.EGOV | +--------------+--------------------+---------------+----(446.3468)--+ From john at betelgeuse.us Mon Jun 30 10:25:45 2003 From: john at betelgeuse.us (John W. M. Stevens) Date: Tue Jul 8 09:13:21 2003 Subject: [Mailman-Developers] Bugs in Mailman 2.1.2 Message-ID: <20030630152545.GB30853@betelgeuse.us> Mailman 2.1.2, Apache 1.3.27, and Python 2.2.2: On initial configuration, on attempting to create the mailman list itself, the output from newlist mailman is: To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the `newaliases' program: ## mailman mailing list mailman: "|/var/lib/mailman/mail/mailman post mailman" mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman" mailman-bounces: "|/var/lib/mailman/mail/mailman bounces mailman" mailman-confirm: "|/var/lib/mailman/mail/mailman confirm mailman" mailman-join: "|/var/lib/mailman/mail/mailman join mailman" mailman-leave: "|/var/lib/mailman/mail/mailman leave mailman" mailman-owner: "|/var/lib/mailman/mail/mailman owner mailman" mailman-request: "|/var/lib/mailman/mail/mailman request mailman" mailman-subscribe: "|/var/lib/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe mailman" Hit enter to notify mailman owner... Traceback (most recent call last): File "bin/newlist", line 226, in ? main() File "bin/newlist", line 218, in main text, mlist.preferred_language) File "/var/lib/mailman/Mailman/Message.py", line 206, in __init__ errors='replace') TypeError: __init__() got an unexpected keyword argument 'errors' John S. From jonas at freesources.org Sat Jun 28 19:16:55 2003 From: jonas at freesources.org (Jonas Meurer) Date: Tue Jul 8 09:13:56 2003 Subject: [Mailman-Developers] strange behavior with EXTERNAL_PUBLIC_ARCHIVER Message-ID: <20030628161655.GP1205@freesources.org> hello, i realized some strange behavior of mailman with the EXTERNAL_PUBLIC_ARCHIVER option. simply setting it to '/usr/bin/id > /tmp/log 2>&1' gives in /tmp/log: uid=38(list) gid=38(list) groups=0(root),102(lpadmin),109(shutdown) at commandline: $ whoami list $ id uid=38(list) gid=38(list) groups=38(list),106(lurker) why does user list member different lists in the two cases? same uid, same gid, only the lists it members are different. bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030628/c7669aa9/attachment-0001.bin From jonas at freesources.org Sun Jun 29 01:55:27 2003 From: jonas at freesources.org (Jonas Meurer) Date: Tue Jul 8 09:13:59 2003 Subject: [Mailman-Developers] Re: [Mailman-Users] strange behavior with EXTERNAL_PUBLIC_ARCHIVER In-Reply-To: <20030628161655.GP1205@freesources.org> References: <20030628161655.GP1205@freesources.org> Message-ID: <20030628225527.GC7631@freesources.org> On 28/06/2003 To Mailman-Users wrote: > hello, > i realized some strange behavior of mailman with the > EXTERNAL_PUBLIC_ARCHIVER option. simply setting it to > '/usr/bin/id > /tmp/log 2>&1' gives in /tmp/log: > uid=38(list) gid=38(list) groups=0(root),102(lpadmin),109(shutdown) mh, the problem is at the debian package: mailmanctl start is run as root. if i start mailman as list, /tmp/log has the output i expected: uid=38(list) gid=38(list) groups=38(list),106(lurker) bye mejo -- Efficiency and progess is ours one more Now that we have the Neutron bomb It's nice and quick and clean and gets things done Kill kill kill kill kill the poor tonight -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20030629/1931f55b/attachment-0001.bin