Mailman-Developers December 2003

mailman-developers@python.org

35 participants
33 discussions

Calling all Mailman hosting sites
by Barry Warsaw 25 Feb '04

25 Feb '04

I've had a lot of requests recently for information about Mailman hosting. As a general rule I don't like to recommend any particular hosting company. But if you do provide Mailman hosting facilities, please make sure you've added yourself to the PythonHosting wiki: http://www.python.org/cgi-bin/moinmoin/PythonHosting I usually point people here for more information, so please make sure you're on that list. Now to check the FAQ and see if it points here... -Barry

2 2

mailman setup
by Guillaume Rousse 23 Jan '04

23 Jan '04

Hello. I'm one of the guy managing the mailman package for mandrake-linux. I've currently trying to make setup a bit more standard and FHS compliant. I need developpers help however, first to make sure my changes won't cause trouble, second as I think some of these change should get merged upstream, as they would benefit more people. The first issue is file location. We are trying to achieve FHS compliance, so i had to move things a bit. I'm using the --with-var-prefix configure option to have variable files in /var/lib/mailman and non-variables files in /usr/lib/mailman. That is supported by mailman install. Then i move logs from /var/lib/mailman/logs to /var/log/mailman through a symlink. The config file location, however, is still puzzling me. Having a configuration file (mm_cfg.py) under /usr is non-standard, as /usr is supposed to be read-only. Moreover, it is a pain for us packagers, as we have to include everything but this file as normal files, then tag it as config file. I'd really think it should be moved in /etc instead, either by me using a symlink, but much better by an upstream change. The second issue are perms. The default install make everything owned by the uid/gid determined at configure stage (mail/mail for me), and make all directories setgid, even for non-variables files, which is quite really a non-standard practice. So i tried to clean it a bit. I made everything under /usr/lib/mailman owned by root.root, with standard perms (644 for files, 755 for directories) except the binaries in /usr/lib/mailman/cgi-bin and usr/lib/mailman/mail which are setgid, and owned by mail group. I tested, it seems to work. I also made top-level directory for variable files (/var/lib/mailman) owned by root/root with standard 755 perms, but i didn't tried yet further perm modifications there, as mailman need write permissions in subdirectories. You can have a look at the spec file in CVS if you want details (http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/mailman/mailman.spec). Your comments on my changes are welcome, as well as what could get integrated into mailman. -- Those who hesitate under fire usually do not end up KIA, MIA or WIA -- Murphy's Military Laws n°101

3 4

Tweaking Mail->News Gateway
by Michael Heydekamp 06 Jan '04

06 Jan '04

Hi Mailman developers, we at freexp.de are setting up Mailman and INN and are trying to get the Mail<->News facility to work. We are neither familiar with Mailman nor with Python, just being poor old Pascal programmers. ;) I have been in touch with Brad Knowles before and he advised me to ask here. We have three mailing lists and three corresponding newsgroups, which shall be gated bidirectional. It even works but what is puzzling us is that in Mail->News direction Mailman always creates an own MsgID. This screws up threading by references: If a newsgroup user replies to a posting that has been gated from the mailing list to the newsgroup, then - from the perspective of the mailing list users - his references point to a "wrong" MsgID when they receive this followup posting being gated from the newsgroup to the mailing list. I found the respective code in Queue/NewsRunner.py and also read the explanation why Mailmain is creating own MsgIDs (I'll come back to this later on). I changed the code as follows: ----------8<---------- # Our Message-ID format is <mailman.secs.pid.listname@hostname> msgid = msg['message-id'] hackmsgid = True if msgid: hackmsgid = False # mo = mcre.search(msgid) # if mo: # lname, hname = mo.group('listname', 'hostname') # if lname == mlist.internal_name() and hname == mlist.host_name: # hackmsgid = False if hackmsgid: del msg['message-id'] msg['Message-ID'] = Utils.unique_message_id(mlist) ----------8<---------- It is not really clear to me how Python can know where a conditional statement such as "if msgid:" ends (just by the indention?), but this piece seems to work: The MsgID is now being left untouched. This is question #1: Is this code OK? I'm also not sure if the variable 'msgid' contains a boolean or a string...? Now to the more important issues: I understand that there are two main reasons why Mailman wants to create an own MsgID upon gating Mail->News, one of them being to avoid loops. Even after I changed the code as above, I still can't see a loop. I first thought Mailman might check the MsgID of a posting upon deciding whether it should be gated from the newsgroup to the mailing list, but this is obviously not the case. I've had a look into cron/gate_news.py but couldn't figure out exactly how Mailman is taking that decision. This is question #2: How does Mailman know if the mailing list has already seen a posting or not? Anyway, the second and more important reason for creating own MsgIDs seems to be the issue of an XPost to two (or more) Usenet-gated mailing lists. This is indeed a problem and I understand the background. Thus we'd like to tweak Mailman in a way that it does the following: 1. Say we have the mailing lists ml-1, ml-2 and ml-3 and the corresponding newsgroups ng-1, ng-2 and ng-3. Now a mail comes in, being addressed to ml-1 and ml-2 (which thus should be gated to ng-1 and ng-2). In fact, two physical mails will come in, and obviously Mailman does now create two physical postings, one addressed to ng-1, the other one addressed to ng-2. This in fact creates the problem of duplicate MsgIDs. But what Mailman should do is to create *one* physical posting, x-posted to ng-1 and ng-2 ("Newsgroups: ng-1,ng-2"). This would mean that upon dealing with the mail to ml-1 it would have to check if the addresses in the To: and Cc: headers contain more than one of "our" mailing lists and if these mailing lists are being gated to "our" Newsgroups. If so, then an x-posting as described shall be created. When Mailman now has to deal with the second mail to ml-2 (with the same MsgID) it shall *not* create another posting anymore. Can this be accomplished (and if yes, how)? 2. Of course, if a mail does not have a MsgID at all, then Mailman should still create its own MsgID. Any hint will be appreciated (and again, please consider that we are newbees with regards to Mailman and Python). Even if we would have to hardcode some strings (of mailing lists and/or newsgroups) this would be a better solution than no solution. Michael

2 5

RELEASED Mailman 2.1.4
by barry＠python.org 04 Jan '04

04 Jan '04

I have released Mailman 2.1.4, a bug fix release that also contains support for four new languages: Catalan, Croatian, Romanian, and Slovenian. This release also contains a fix for a cross-site scripting vulnerability in the 'admin' cgi script (see CAN-2003-0965). There is also an expanded ability to filter message headers, nominally to provide better support when Mailman is used in conjunction with upstream spam and virus filters. The full source tarball has been made available from the usual sites. Sorry, there is no patch available yet, but you should be able to install Mailman 2.1.4 over your existing 2.1.x installation. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to the downloadable files. After installing, be sure you restart your Mailman daemon by doing a "mailmanctl restart". IMPORTANT: You will want to re-run configure before doing a make install. See also: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman Enjoy, and have a Happy New Year. -Barry -------------------- snip snip -------------------- 2.1.4 (31-Dec-2003) - Close some cross-site scripting vulnerabilities in the admin pages (CAN-2003-0965). - New languages: Catalan, Croatian, Romanian, Slovenian. - New mm_cfg.py/Defaults.py variable PUBLIC_MBOX which allows the site administrator to disable public access to all the raw list mbox files (this is not a per-list configuration). - Expanded header filter rules under Privacy -> Spam Filters. Now you can specify regular expression matches against any header, with specific actions tied to those matches. - Rework the SMTP error handling in SMTPDirect.py to avoid scoring bounces for all recipients when a permanent error code is returned by the mail server (e.g. because of content restrictions). - Promoted SYNC_AFTER_WRITE to a Default.py/mm_cfg.py variable and make it control syncing on the config.pck file. Also, we always flush and sync message files. - Reduce archive bloat by not storing the HTML body of Article objects in the Pipermail database. A new script bin/rb-archfix was added to clean up older archives. - Proper RFC quoting for List-ID descriptions. - PKGDIR can be passed to the make command in order to specify a different directory to unpack the distutils packages in misc. (SF bug 784700). - Improved logging of the origin of subscription requests. - Bugs and patches: 832748 (unsubscribe_policy ignored for unsub button on member login page), 846681 (bounce disabled cookie was always out of date), 835870 (check VIRTUAL_HOST_OVERVIEW on through the web list creation), 835036 (global address change when the new address is already a member of one of the lists), 833384 (incorrect admin password on a hold message confirmation attachment would discard the message), 835012 (fix permission on empty archive index), 816410 (confirmation page consistency), 834486 (catch empty charsets in the scrubber), 777444 (set the process's supplemental groups if possible), 860135 (ignore DiscardMessage exceptions during digest scrubbing), 828811 (reduce process size for list and admin overviews), 864674/864676 (problems accessing private archives and rosters with admin password), 865661 (Tokio Kikuchi's i18n patches), 862906 (unicode prefix leak in admindb), 841445 (setting new_member_options via config_list), n/a (fixed email command 'set delivery')

3 2

Help me
by D&J Morley 31 Dec '03

31 Dec '03

http://www.british-genealogy.com/mailman/listinfo/s-arnold As a list owner of the above list can you tell me why my own list is rejecting my mail. It seems your mailman thing says I do not exist? no one will answer my emails from this UK web site. Do I have to delete all my members as well am myself? I do not know what ty do. Jill Morley list owner s-arnold list

2 1

Re: [Mailman-checkins] mailman/messages/de/LC_MESSAGES mailman.po, 2.75, 2.76
by Barry Warsaw 31 Dec '03

31 Dec '03

On Wed, 2003-12-31 at 10:20, pheinlein(a)users.sourceforge.net wrote: > Update of /cvsroot/mailman/mailman/messages/de/LC_MESSAGES > In directory sc8-pr-cvs1:/tmp/cvs-serv5338/messages/de/LC_MESSAGES > > Modified Files: > mailman.po > Log Message: > > Last quick fix for 2.1.4 Peer, you really need to make these changes on the Release_2_1-maint branch tag. These changes are on the trunk and will /not/ make it into 2.1.4 unless you also commit them to the branch! I'm also going to log into irc.freenode.net #mailman now in case anybody wants to chat about stuff. -Barry

1 0

Mailman 2.1.4 tree freeze in 3 hours
by Barry Warsaw 31 Dec '03

31 Dec '03

I'm going to be cutting the 2.1.4 release at noon EST, which is approximately three hours from now. If there are any last minute i18n updates, please get them in now. No other changes are allowed. After 12noon EST, no other i18n updates will be allowed either. Thanks and happy new year to all (including those of you already partying :). -Barry

1 0

Re: [Mailman-checkins] mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
by Tokio Kikuchi 31 Dec '03

31 Dec '03

Hi Barry, I made a mistake on this patch. Hye-Shik Chang's cjkcodecs site has moved from sourceforge to http://cjkpython.i18n.org/ He has updated his codecs to 1.0.2, so please download and update the package and change the package description in Makefile.in accordingly. http://download.berlios.de/cjkpython/cjkcodecs-1.0.2.tar.gz Sorry for the inconvenience. bwarsaw(a)users.sourceforge.net wrote: > Update of /cvsroot/mailman/mailman/misc > In directory sc8-pr-cvs1:/tmp/cvs-serv24964/misc > > Modified Files: > Tag: Release_2_1-maint > .cvsignore Makefile.in paths.py.in > Added Files: > Tag: Release_2_1-maint > CJKCodecs-1.0.tar.gz > Removed Files: > Tag: Release_2_1-maint > JapaneseCodecs-1.4.9.tar.gz KoreanCodecs-2.0.5.tar.gz > Log Message: > TK's patch # 865661 chunk which replaces JapaneseCodecs-1.4.9 and > KoreanCodecs-2.0.5 with CJKCodecs-1.0. > > > --- NEW FILE: CJKCodecs-1.0.tar.gz --- > (This appears to be a binary file; contents omitted.) > > Index: .cvsignore > =================================================================== > RCS file: /cvsroot/mailman/mailman/misc/.cvsignore,v > retrieving revision 2.2 > retrieving revision 2.2.2.1 > diff -u -d -r2.2 -r2.2.2.1 > --- .cvsignore 17 Aug 2001 23:19:22 -0000 2.2 > +++ .cvsignore 26 Dec 2003 21:46:09 -0000 2.2.2.1 > @@ -1,3 +1,5 @@ > Makefile > paths.py > mailman > +CJKCodecs-1.0 > +email-2.5.4 > > Index: Makefile.in > =================================================================== > RCS file: /cvsroot/mailman/mailman/misc/Makefile.in,v > retrieving revision 2.33.2.3 > retrieving revision 2.33.2.4 > diff -u -d -r2.33.2.3 -r2.33.2.4 > --- Makefile.in 1 Dec 2003 00:12:30 -0000 2.33.2.3 > +++ Makefile.in 26 Dec 2003 21:46:09 -0000 2.33.2.4 > @@ -53,10 +53,9 @@ > PKGDIR= $(srcdir) > > EMAILPKG= email-2.5.4 > -JACODECSPKG= JapaneseCodecs-1.4.9 > -KOCODECSPKG= KoreanCodecs-2.0.5 > +CJKCODECSPKG= CJKCodecs-1.0 > > -PACKAGES= $(EMAILPKG) $(JACODECSPKG) $(KOCODECSPKG) > +PACKAGES= $(EMAILPKG) $(CJKCODECSPKG) > > # Modes for directories and executables created by the install > # process. Default to group-writable directories but > > Index: paths.py.in > =================================================================== > RCS file: /cvsroot/mailman/mailman/misc/paths.py.in,v > retrieving revision 2.6 > retrieving revision 2.6.2.1 > diff -u -d -r2.6 -r2.6.2.1 > --- paths.py.in 21 Oct 2002 19:52:05 -0000 2.6 > +++ paths.py.in 26 Dec 2003 21:46:09 -0000 2.6.2.1 > @@ -1,19 +1,19 @@ > # -*- python -*- > > -# Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. > +# 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 > +# along with this program; if not, write to the Free Software > # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > > # This file becomes paths.py which is installed in may directories. By > @@ -49,12 +49,8 @@ > sys.path.append(sitedir) > > > -# In a normal interactive Python environment, the japanese.pth and korean.pth > -# files would be imported automatically. But because we inhibit the importing > -# of the site module, we need to be explicit about importing these codecs. > -import japanese > -# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean > -# codecs installed, however leave the first import in there in case an upgrade > -# changes this. > -import korean > -import korean.aliases > +# We explicitly import CJKCodecs here since we inhibit the importing of the > +# site module. As of CJKCodecs-1.0, you have to do the second import. We may > +# have to re-activate the first line if an upgrade changes this. > +#import cjkcodecs > +import cjkcodecs.aliases > > --- JapaneseCodecs-1.4.9.tar.gz DELETED --- > > --- KoreanCodecs-2.0.5.tar.gz DELETED --- > > > > _______________________________________________ > Mailman-checkins mailing list > Mailman-checkins(a)python.org > Unsubscribe: http://mail.python.org/mailman/options/mailman-checkins/tkikuchi%40is.kochi… > > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

4 25

Password recovery
by Roberto Perez 31 Dec '03

31 Dec '03

Hi, I hope I can get some insights into this problem. I've been using Mailman in our university to administer a number of lists, and the web interface has worked well so far for us. However, in the recent weeks we have learned a spammer has subscribed many of our email accounts to his own mailman system (on a server outside the US), and has disabled the web interface. This means no one can get a reminder of their passwords to unsubscribe via email (since when an administrator subscribes users no password is sent). As it is now, Mailman is being used to keep those accounts "captive" and bombard them with unsolicited email. So the purpose of my email is twofold: ** Development: - I strongly believe now email commands should also include a password reminder/recovery feature, so that in cases like ours users can still get their passwords and unsubscribe via email. Currently a password can only be recovered via the web interface (which a spammer can disable). - I also think when the administrator enrolls users, the passwords should be sent as a default, with no possibility of disabling this feature. This would cut down on misuse of Mailman as the one described above. ** Management: - This is a generic question to all managers: if - a Mailman list does not offer a web interface to recover a password to unsubscribe, - the manager does not reply to unsubscription messages, - the bounce utility has been disabled (so sending fake "Returned mail" messages does not trigger unsubscription), - the monthly password reminder has been disabled, - the Mailman server is outside the US (so reporting to the FCC is useless), - and the list is being used to bombard subscribers who did not subscribe themselves... ...how else could unsubscription be achieved in Mailman? I know that users could put filters, but I'd like for the messages to stop instead of having to put patches here and there on each user's machine... Thanks in advance for any pointers/ideas/suggestion you may have. Roberto Perez rgpg(a)technologist.com

3 2

Re: [Mailman-Developers] python is slow
by Bernhard Kuemel 26 Dec '03

26 Dec '03

Larry Price wrote: > That is not evidence, that is an appeal to authority. > > If you wish to present evidence, you would need to drop a tarball > containing. > > a. a relatively complex test algorithm and data set > b. implementations thereof in ${language} > c. a test script which executes and times each implementation > > You would then need to have a large sample of testers run the tests on a > wide variety of platforms, and then do a linear regression of the > results to see if speed varied independently of the underlying platform. > > and yet it would still not matter. You name the reasons why I will not produce the 'convincing evidence' Richard Barret is interested in. I do however believe ESR is called authority rightly and assume he is has sufficient knowledge of and communication with experts in the languages he writes about so his opinion adds to my experience that python is slow. Some complex things are hard to prove so I thought you might be interested in the opinion of a neural network trained in the subject. > with few exceptions the problems that people use python to solve are not > ones where > speed is paramount, but rather ones where understanding what's happening > and being able to change it quickly is. > > > > > On Tuesday, December 16, 2003, at 02:44 PM, Bernhard Kuemel wrote: > >> Richard Barrett wrote: >> >>> On 25 Nov 2003, at 20:06, Bernhard Kuemel wrote: >>> >>>> Maybe. However, I don't like python as on our old P60 server it >>>> burned up so much CPU time (15 s/min). >>> >>> It would be interesting to see you present convincing evidence that >>> Python runs slower than Perl which you seem happy to rely on. >> >> >> Eric Steven Raymond says in "The Art of Unix Programming" >> (http://www.faqs.org/docs/artu/index.html) on >> http://www.faqs.org/docs/artu/ch14s04.html : >> >> "Python cannot compete with C or C++ on raw execution speed (though >> using a mixed-language strategy on today's fast processors probably >> makes that relatively unimportant). In fact it's generally thought to >> be the least efficient and slowest of the major scripting languages, a >> price it pays for runtime type polymorphism. By. >> eware of rejecting Python on these grounds, however; most applications >> do not actually need better performance than Python offers, and even >> those that appear to are generally limited by external latencies such >> as network or disk waits that entirely swamp the effects of Python's >> interpretive overhead. Also, by way of compensation, Python is >> exceptionally easy to combine with C, so performance-critical Python >> modules can be readily translated into that language for substantial >> speed gains." >> >> Bernhard >> >> -- >> Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at >> Linux Admin/Programmierer: http://bksys.at/bernhard/services.html >> >> >> _______________________________________________ >> Mailman-Developers mailing list >> Mailman-Developers(a)python.org >> http://mail.python.org/mailman/listinfo/mailman-developers >> >> > -- > "You are the eventuality of an anomaly , which despite my sincerest > efforts I have been unable to eliminate from what is otherwise a harmony > of mathematical precision. " -The Architect > "Microsoft has resolved this issue. We have put processes in place to > ensure there is no recurrence of this eventuality." -Microsoft > -- Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at Linux Admin/Programmierer: http://bksys.at/bernhard/services.html

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers December 2003