Mailman 3 August 2002 - Mailman-Developers

[ mailman-Bugs-449677 ] HyperArch.py assumes charsets are in \w+
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #449677, was opened at 2001-08-09 21:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=449677&group_i… Category: Pipermail >Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Ben Gertzfield (che_fox) Assigned to: Nobody/Anonymous (nobody) Summary: HyperArch.py assumes charsets are in \w+ Initial Comment: Using Mailman 2.0.6, I noticed that Japanese messages in charset iso-2022-jp are not archived correctly; their subject lines stay in MIME-encoded format, like Subject: =?ISO-2022-JP?B?WxskQiQqTD5BMBsoQi5jb21dLmNvbS8uag==?= etc. I tracked this down to the following line in HyperArch.py:158 # content-type charset rx_charset = re.compile('charset="(\w+)"') This is incorrect. According to the de-facto list of charsets at http://www.iana.org/assignments/character-sets charsets can have all sorts of characters outside of [a-zA-Z0-9_] , such as - ( ) : . etc. So, we must accept anything between the quotes with a fuzzy .+? match, instead of forcing \w+. Patch attached, against Mailman 2.0.6. ---------------------------------------------------------------------- Comment By: Ben Gertzfield (che_fox) Date: 2001-08-09 22:53 Message: Logged In: YES user_id=89313 Note: this is the solution to the problem in Bug #431511. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=449677&group_i…

1 0

[ mailman-Bugs-517192 ] 2.0.8 borks on dot in local part of addr
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #517192, was opened at 2002-02-13 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=517192&group_i… Category: mail delivery Group: 2.0.x >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: CrackMonkey (monkeymaster) Assigned to: Nobody/Anonymous (nobody) Summary: 2.0.8 borks on dot in local part of addr Initial Comment: In a mail address's local part (the part to the left of the at sign), it is perfectly valid to have periods. However, mailman stops reading the address right at the @, so that "mr.bad(a)pigdog.org" is shown as "mr.bad". this is disastrous for lists where only subscribers are allowed to post, since the system doesn't allow for exceptions that lack an @ and a FQDN. Either allowing exceptions to be of a more forgiving format, or fixing the broken regex that truncates the mail addresses would solve my problem. I'm getting tired of moderating a legitimate user's posts, especially since the system won't even send the warnings to the correct address. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:55 Message: Logged In: YES user_id=12800 I simply can't reproduce this problem with Python 2.2.1 and current cvs of Mailman 2.1 beta 3+ I subscribed an address like barry.warsaw(a)python.org (Barry Warsaw, Jr.) and then sent a message coming from that address and it went through just fine. Unless we can get more information, I'm going to have to close this report. Moving it to Pending status in lieu of follow ups. ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-05-07 00:43 Message: Logged In: YES user_id=76237 Oh, and for what it's worth, I applied that patch as well to my 2.1 copy, so there's no chance that's screwing this up (it's pretty definitely running 2.2.1 now, which doesn't have that 2822 problem) ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-05-06 23:01 Message: Logged In: YES user_id=76237 mr.bad(a)pigdog.org *is* a member of the list, but those headers cause mailman to tell me: List: CrackMonkey(a)crackmonkey.org From: mr.bad Subject: %^$!$^$%!! W32.Elkern and Kin Reason: Post by non-member to a members-only list Note the lack of an @ or FQDN in the From: Yes, I am using python 2.2.1 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-06 22:59 Message: Logged In: YES user_id=12800 I don't quite understand, are you saying that even though "mr.bad(a)pigdog.org" is a member of the list, this message is being not matching as being posted from a member? Under Python 2.2.1? ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-05-06 22:37 Message: Logged In: YES user_id=76237 So when testing the 2.2.1 Python, I see the difference. However, the following headers cause it to reject "mr.bad" as a non-subscriber: Received: from mail15.speakeasy.net (mail.speakeasy.net) [216.254.0.215] by zork.zork.net with esmtp (Exim 3.35 #1 (Debian)) id 174ukJ-0000VO-00; Mon, 06 May 2002 19:30:31 -0700 Received: (qmail 3123 invoked from network); 7 May 2002 02:30:29 -0000 Received: from unknown (HELO tyrell) ([66.217.50.46]) (envelope-sender <mr.bad(a)pigdog.org>) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <crackmonkey(a)crackmonkey.org>; 7 May 2002 02:30:29 -0000 Received: from evan by tyrell with local (Exim 3.35 #1 (Debian)) id 174uii-0002m8-00 for <crackmonkey(a)crackmonkey.org>; Mon, 06 May 2002 22:28:52 -0400 To: crackmonkey(a)crackmonkey.org Subject: %^$!$^$%!! W32.Elkern and Kin From: Mr. Bad <mr.bad(a)pigdog.org> Organization: Pigdog Journal X-PGP-Fingerprint: 91F8 6B2D EBEA 8D7A 3F20 E5B0 6D97 B3BC F498 A1D9 X-Revolutionary-Date: Septidi, 17 Flore'al 210 9:25:94 -20833 Date: Mon, 06 May 2002 22:28:48 -0400 Message-ID: <878z6wofmn.fsf(a)tyrell.bad-people-of-the-future.san-francisco.ca.us> Lines: 27 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-03 00:08 Message: Logged In: YES user_id=12800 monkeymaster, please try the patch, or include a Python 2.2.1 session that shows the bug still exists. I believe this bug report should be marked closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-03 00:07 Message: Logged In: YES user_id=12800 BTW, I'm attaching the patch to Python 2.1.3's rfc822.py that I plan on checking in momentarily. This backports the Python 2.2.1 patch for the problem, and with this, my 2-line example below also succeeds for Python 2.1.3. If there's ever a Python 2.1.4, this patch will be part of it. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-05-02 23:18 Message: Logged In: YES user_id=10725 I can echo that Python 2.2 doesn't have the parseaddr problem. monkeymaster, can you try Barry's two-line experiment and see if that works or fails? ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-04-29 18:21 Message: Logged In: YES user_id=76237 This happens even when I use python 2.2 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-27 12:34 Message: Logged In: YES user_id=12800 This is really a bug with earlier versions of Python, I believe. MM2.0.x uses the standard library function rfc822.parseaddr() to break and address into its realname + email constituent parts. Here are some examples: % python Python 2.2.1 (#1, Apr 22 2002, 17:14:12) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from rfc822 import parseaddr >>> parseaddr('Mr. Bad <mr.bad(a)pigdog.org>') ('Mr. Bad', 'mr.bad(a)pigdog.org') % python2.1 Python 2.1.3 (#1, Apr 22 2002, 18:17:38) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from rfc822 import parseaddr >>> parseaddr('Mr. Bad <mr.bad(a)pigdog.org>') ('', 'Mr.Bad') So this is clearly broken in Python 2.1.3, and works in Python 2.2.1. I'll look at backporting the fix to Python 2.1 in case there's ever a 2.1.4. But if you're using an earlier version of Python, this will still be broken. Consider upgrading to Python 2.2.1. ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-04-26 15:54 Message: Logged In: YES user_id=76237 The bug turns out not to be when there is a period in the address, but in the plain text name. The mail address in question is: Mr. Bad <mr.bad(a)pigdog.org> I realized this when I saw people who had different text names from their e-mail addresses, as in: Jr. Pickle <picklejr(a)someplace.foo> This would show up as the mythical address "jr.pickle" in mailman, and things would b0rk. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-03-14 14:18 Message: Logged In: YES user_id=12800 Either I need more information, or this problem is fixed in MM2.1. Quite often I uses test addresses like "barry.warsaw@<wherever>" and I've had no problems with it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=517192&group_i…

1 0

[ mailman-Bugs-540978 ] List-* header multiline split bug
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #540978, was opened at 2002-04-08 08:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_i… Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Markus Mandalka (mandalka) Assigned to: Nobody/Anonymous (nobody) >Summary: List-* header multiline split bug Initial Comment: I have a list antiatomforum(a)lists.kommunikationssystem.de and others with long names. It seems that mailman can not handle with such long names, because in the subscribe-mail (which you have to answer to be in the list) the first columns are some things from the header (unsubscribe: xxx(a)lists.xxx and so on). Whith names like atest(a)lists.kommunikationssystem.de it works. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:38 Message: Logged In: YES user_id=12800 Changing the summary ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-15 00:37 Message: Logged In: NO I just installed mailman and can confirm this bug as well. When the list address + hostname is too long (in my case the listname was north-texas-stovebolters- club(a)stovebolt.stovebolt.com -- 52 characters total) the headers overflow into the body of the message. The "break point" was at the List Subscribe line: ******************* This is header: List-Subscribe: <http://stovebolt.stovebolt.com/mailman/listinfo/north- texas-stovebolters-club>, (total of 94 characters before the split) ******************* This is body <mailto:north-texas-stovebolters-club- request(a)stovebolt.stovebolt.com?subject=subscribe> List-Unsubscribe: <http://stovebolt.stovebolt.com/mailman/listinfo/north- texas-stovebolters-club>, <mailto:north-texas-stovebolters-club- request(a)stovebolt.stovebolt.com?subject=unsubscribe> List-Archive: <http://stovebolt.stovebolt.com/pipermail/north-texas- stovebolters-club> List-Help: <mailto:north-texas-stovebolters-club- request(a)stovebolt.stovebolt.com?subject=help> Sender: north-texas-stovebolters-club- bounces(a)stovebolt.stovebolt.com Errors-To: north-texas-stovebolters-club- bounces(a)stovebolt.stovebolt.com ************************ This is the initial text of the message that was posted. I'm sure that I'll be there. :-) **************************** It looks like there's a line break or line limit that's causing the problem. Perhaps it's line 33: MAXLINELEN = 78 The first line that breaks (in my case) is a line that has 94 characters in the first part, none of which can be separated (no spaces or line breaks, just continuous text.) The very next line drops to the body. I believe giuans is correct that the problem is in the wrap section of the code, because the break occurs immediately after a comma, which, if I'm understanding the code correctly, is inserted by the program after an overlength line occurs, to split the line at 78 (or as close to that as it can get.) I think the correct fix would be to add the "h" portion subsequent to the split so that each line in the header would have the required semi-colon to indicate that it's header. If the MTA sees a line with no semicolon, it's going to think that it's body text, not header. ***************** Present code: if len(h) + 2 + len(v) > 78: v = CONTINUATION.join(v.split(', ')) msg[h] = v ****************** Possible fix if len(h) + 2 + len(v) > 78: v=CONTINUATION.join(h + v.split(',')) msg[h] = v or something like that. (I haven't worked with php, so I'm not familiar with its functions and syntax.) The idea is to split a line like this: Line exceeds 78 characters? h+v, h+ rest of v HTH. ---------------------------------------------------------------------- Comment By: Jean Millerat (drsigmund) Date: 2002-07-04 04:13 Message: Logged In: YES user_id=70686 I have reached the same bug with mailing list adresses such as <11 characters>@<30 characters> whereas <8 characters>@<30 characters> works properly. The effect of this bug is that the headers of the subcription annoucement or any further email from the list are "mangled" as was said on [mailman-developers]. As an example when one of the List-* header line is too long, it is broken in two parts (and the second part is indented). Since then, Outlook (and I suppose other email clients) think this second part of the broken header line is the beginning of the body of the message. Therefore the remaining headers are sent as part of the body of the message ! I think this bug does not only occur with too long email adresses but may occur with too long header lines whichever line it is (even with the Subject line especially when this subject line is very long because of quoted-printable characters). See [mailman-developers] for the description of maybe the same bug, in mails dealing with headers being "mangled". My current workarounds : - using short mailing list names. - and not sending quoted-printable characters within subject lines. ---------------------------------------------------------------------- Comment By: Giovanni Lopedote (giuans) Date: 2002-05-02 10:27 Message: Logged In: YES user_id=531451 I've found it. A fast fix for is to comment lines 149-150 in Mailman/Handlers:/CookHeaders.py: --- CookHeaders.py 2002-05-02 14:51:36.000000000 +0200 +++ CookHeaders.py.new 2002-05-02 16:12:09.000000000 +0200 @@ -146,8 +146,8 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded, but is at least text-MUA friendly. The # adding of 2 is for the colon-space separator. - if len(h) + 2 + len(v) > 78: - v = CONTINUATION.join(v.split(', ')) +# if len(h) + 2 + len(v) > 78: +# v = CONTINUATION.join(v.split(', ')) msg[h] = v # Always delete List-Archive header, but only add it back if the list is # actually archiving Tested with Mailman 2.1b1, Source Mage GNU/Linux 2.4.18, Postfix 1.1.7. I know there should be a better way, but I'm not a Python programmer at all. :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-11 18:03 Message: Logged In: YES user_id=12800 I've confirmed this bug, but don't have a fix for it right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_i…

1 0

External subscriber lists in 2.1
by J C Lawrence 23 Aug '02

23 Aug '02

Barry, In 2.1 when used with external subscriber storage (eg SQL), will the new equivalent of qrunner request and load the entire subscriber DB onto the heap prior to broadcast? <<Yeah, I'm cheating and being lazy on not checking the source myself>> Reason: This poses scaling problems for lists with very large numbers of subscribers. I'd suggest paging thru the set in blocks. ObExcuse: Chap on -users asking about millions of subscribers. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

3 4

[ mailman-Bugs-545956 ] digest mode dont recognize latin-1
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #545956, was opened at 2002-04-19 01:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=545956&group_i… Category: None >Group: 2.0.x Status: Open Resolution: Out of Date Priority: 5 Submitted By: Veronica Loell (mindtrader) Assigned to: Nobody/Anonymous (nobody) Summary: digest mode dont recognize latin-1 Initial Comment: We just started a list where we commicate in swedish and hence use åäö from Latin-1. One of the members have choosen digest-mode and we have discovered a problem. All our mails use latin-1, and in the non-digest form and also in the archives all charachters are displayed correctly. In digest form however, the letters äåö are marked as unknown, with their hex-numbers given. I have tested this by having both digest and non-digest delivered to me, using the same mailer etc. --------- Digest --------- Date: Thu, 18 Apr 2002 07:55:22 +0200 (W. Europe Daylight Time) From: Veronica Loell <info(a)nakawe.se> To: <ag-cling- cvs(a)lists.sourceforge.net> Subject: [cvs] =?ISO-8859- 1?Q?test_med_=E5=E4=F6?= Detta =E4r bara ett test f=F6r att utreda problemet med latin-1 i digestversionen. =C5=C4=D6 =E5=E4=F6 --------- Non-digest --------- Date: Thu, 18 Apr 2002 07:55:22 +0200 (W. Europe Daylight Time) From: Veronica Loell <info(a)nakawe.se> To: ag-cling- cvs(a)lists.sourceforge.net Subject: [cvs] test med åäö Detta är bara ett test för att utreda problemet med latin-1 i digestversionen. ÅÄÖ åäö ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-24 01:16 Message: Logged In: YES user_id=156789 It seems that this problem also is present when posts are held for approval. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-19 14:40 Message: Logged In: YES user_id=12800 Well, now I'm not positive. Can you send a message to mailman-developers and see what other people think? ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-19 14:04 Message: Logged In: YES user_id=156789 Actually mailman does handle it perfectly, it only happens in the digest mode. And it is also not the header that is the problem it's the body of the email. But if this has been corrected I'll report it to sourceforge because they apperantly are using an old version. I do get plenty of email where the header is messed up, but the rest of the message is not. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-19 13:53 Message: Logged In: YES user_id=12800 Mailman 2.1 will correctly handle non-ascii characters in headers. The problem is (probably) that the addition of the prefix breaks rfc2047 encoding of the non-ascii characters in the Subject: header. ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-19 01:28 Message: Logged In: YES user_id=156789 I forgot to say. This is the listmanager managed by Sourceforge. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=545956&group_i…

1 0

[ mailman-Bugs-554287 ] smart_address_match and .us
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #554287, was opened at 2002-05-09 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=554287&group_i… Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Christopher Kolar (ckolar) Assigned to: Nobody/Anonymous (nobody) Summary: smart_address_match and .us Initial Comment: I know that it is noted in Defaults.py that the smart address needs to be fixed for international TLDs, but this is also broken for .us TLDs as well. I just wanted it to be in the bug log that this needs to be fixed for all of those people. Thanks, --ck ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:27 Message: Logged In: YES user_id=12800 This seems to fall into the general "I have two email addresses I want to post from", so I think the approach for MM2.1 is going to be, subscribe them both and disable the one you don't want to receive copies at. This just can't be done reliably enough, and eventually <wink> all their posting addresses will be in one subscription record. ---------------------------------------------------------------------- Comment By: Christopher Kolar (ckolar) Date: 2002-05-13 13:06 Message: Logged In: YES user_id=40678 Regardless, it is still a problem that someone(a)cpc.cps.k12.il.us gets bounced when someone(a)cps.k12.il.us is on the subscriber list. --chris ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-12 02:10 Message: Logged In: YES user_id=12800 Near as I can tell, SMART_ADDRESS_MATCH isn't really used any where, except in functions that are also not used any where. Am I missing something or can all this cruft be removed now? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=554287&group_i…

1 0

[ mailman-Bugs-596361 ] rejection-notice not translated
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #596361, was opened at 2002-08-17 02:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_i… Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: rejection-notice not translated Initial Comment: on the admindb screen, detailed description of the held messages include 'rejection-notice' field to be sent to the message sender but the default value in the text form is in english and not translated into the list-preferred language. Following short patch may work: --- admindb.py.orig Fri Aug 16 11:39:53 2002 +++ admindb.py Sat Aug 17 14:57:37 2002 @@ -595,8 +595,8 @@ t.AddRow([ Bold(_('If you reject this post,<br>please explain (optional):')), TextArea('comment-%d' % id, rows=4, cols=80, - text = Utils.wrap(msgdata.get('rejection-notice', - _('[No explanation given]')), + text = Utils.wrap(_(msgdata.get('rejection-notice', + _('[No explanation given]'))), column=80)) ]) row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:16 Message: Logged In: YES user_id=12800 In general it's better to attach patches instead of pasting them in. SF doesn't preserve whitespace :( Updating this one so SF will send me the whitespace preserved patch in an email notification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_i…

1 0

[ mailman-Bugs-596456 ] TypeError: unsubscriptable object
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #596456, was opened at 2002-08-17 11:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596456&group_i… Category: None Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError: unsubscriptable object Initial Comment: Aug 17 16:37:42 2002 (10524) Uncaught runner exception: unsubscriptable object Aug 17 16:37:42 2002 (10524) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 198, in _dispose res.process() File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 93, in process stop = self.do_command(cmd, args) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 117, in do_command return self.do_command(cmd, args) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 119, in do_command return handler.process(self, args) File "/home/mailman21/Mailman/Commands/cmd_confirm.py", line 44, in process results = mlist.ProcessConfirmation(cookie, res.msg) File "/home/mailman21/Mailman/MailList.py", line 1096, in ProcessConfirmation subpart = email.Iterators.typed_subpart_iterator( TypeError: unsubscriptable object I was confirming by email to discard an held spam message. I suspect this problem is similar to #593454, related to python 2.2 compatibility ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596456&group_i…

1 0

Initial Mailman v2.0 with TMDA and Mime filtering
by J C Lawrence 23 Aug '02

23 Aug '02

This is mostly written for the Mailman MLM community, but is CCed to tmda-users as it applies there as well. In general subsequent discussion should happen on mailman-developers, so I've set Reply-To accordingly. I'm writing this now as the discussed configuration appears to work and I'd rather document it now while its still fresh in my mind then later when its not. If any big bugs or required changes surface I'll post on those later to the mailman-developers list. I built the system with Mailman 2.0, TMDA 0.58, Exim v3, mimefilter, mimedecode, and procmail. You don't need mimedecode or mimefilter, but if you want to do mime filtering (even with say strip mime or demime instead) adapting the below is should be simple and obvious. Several aspects and details are going to be specific to the default configurations and installations of the relevant packages under Debian Linux. I will assume that you'll be Linux/Unix savvy enough to both detect those points and work around them as needed. Background: -- I decided to integrate the system via procmail as I also wanted to (easily) add MIME filtering and other forms of message rewriting to my list setup. -- A primary goal is that the system operates without requiring either SysAdm or list owner attention. -- As discussed on-list One of my wishes was that lists maintain whitelists which are private to them and thus not shared across the entire set of lists serviced by that host. I will not detail how I went about that except in passing as current TMDA development initiatives will render that much simpler in future. -- Elegance was not a goal. Workability and were. There are several rough edges left. Some are noted below. How-To: ------- Getting the system working essentially has three steps: 1) Getting Mailman working transparently under Exim without aliases. 2) Getting TMDA configured, installed, and tested. 3) Getting TMDA integrated with Exim and Mailman, using procmail as a glue layer. You'll be wise to check and test each step as you go along. Finding the correct source of faults with the whole system in place can be a confusing and difficult exercise. Its easier to test and retest as you go along so as to limit the set of possible items that need examination for error. Step one is fairly simple: Just configure Exim as per the README.Exim or Nigel's HOW-TO on exim.org. Make sure its all working and that Mailman functions correctly in all regards as regards the MTA. You will have to update and extend these configurations later to suit TMDA, but start out making sure you have the base right. If Mailman doesn't work on your system its hardly worth trying to get TMDA also not working. Install TMDA on your system (Debian uses a $PREFIX of /usr). Make sure you get at least version 0.58. For Debian this means installing from /testing. If you use a later version (such as current CVS) read the changelog carefully as you'll have to make some adaption in your setup to the new features in TMDA. Those changes are left as an exercise for the reader. Under ~list/ creat the following directory hierarchy, with 0700 permissions and owned by list.list (the Debian Mailman user): ~list/.tmda ~list/.tmda/cache ~list/.tmda/lists ~list/.tmda/logs ~list/.tmda/filters ~list/.tmda/pending ~list/.tmda/templates Within that tree creat the following empty files, each of zero length, owned by list.list and with 0600 permissions: ~list/.tmda/lists/released ~list/.tmda/lists/whitelist.auto ~list/.tmda/lists/blacklist ~list/.tmda/lists/whitelist ~list/.tmda/filters/outgoing The above files need to be created as otherwise TMDA will error when it fails to find them. If you have particular scaling or performance issues with regard to these address lists you might want to use the dbm or cdb forms instead (see the TMDA documentation for details). If so, make sure you configure ~list/.tmda/config to match. Next copy the default TMDA message templates to: ~list/.tmda/templates/bounce.txt ~list/.tmda/templates/confirm_request.txt ~list/.tmda/templates/confirm_accept.txt And rewrite them as suitable for your mailing lists. Now create your TMDA crypt key in: ~list/.tmda/crypt_key and your TMDA configuration in: ~list/.tmda/config My ~list/.tmda/config reads: DATADIR = "/var/lib/mailman/.tmda/" MAIL_TRANSFER_AGENT = "exim" DELIVERY = "|/usr/bin/procmail -p -f $SENDER" RECIPIENT_DELIMITER = "+" CRYPT_KEY_FILE = "/var/lib/mailman/.tmda/crypt_key" BARE_APPEND = "/var/lib/mailman/.tmda/lists/whitelist" CONFIRM_APPEND = "/var/lib/mailman/.tmda/lists/whitelist.auto" CONFIRM_MAX_MESSAGE_SIZE = None TEMPLATE_DIR = "/var/lib/mailman/.tmda/templates/" ACTION_INCOMING = "confirm" ACTION_OUTGOING = "bare" FINGERPRINT = ["message-id", "from", "date"] FULLNAME = "List Filter System" HOSTNAME = "kanga.nu" LOGFILE_DEBUG = "/var/lib/mailman/.tmda/logs/tmda_debug.log" LOGFILE_INCOMING = "/var/lib/mailman/.tmda/logs/tmda_incoming.log" PENDING_BLACKLIST_APPEND = "/var/lib/mailman/.tmds/lists/blacklist" PENDING_BLACKLIST_APPEND = "/var/lib/mailman/.tmds/lists/deleted" PENDING_RELEASE_APPEND = "/var/lib/mailman/.tmda/lists/released" PENDING_WHITELIST_APPEND = "/var/lib/mailman/.tmda/lists/whitelist" TIMEOUT = "2w" You'll specifically need to tailor the values of FULLNAME and HOSTNAME from the above cases. Note: I use a RECIPIENT_DELIMITER of "+" as I use "-" in several list names and don't want the two appearing to run together. Make sure you read the caveats on using "+" in the TMDA FAQ before chosing the RECIPIENT_DELIMITER you want to use. In my case ~list/.tmda/logs is actually a symlink to /var/log/TMDA which is owned by list.list and of 0700 permissions and a matching logrotate stanza: /var/log/TMDA/procmail.log { monthly compress missingok } /var/log/TMDA/tmda-debug.log { monthly compress missingok } /var/log/TMDA/tmda-incoming.log { monthly compress missingok } Next, and almost finally is to create the incoming filter with ownership list.list and permissions 0600: ~list/.tmda/filters/incoming The contents should be similar to: # # Note: First match wins, so sequence of rules is significant # # # Bounce blacklisters # from-file ~list/.tmda/lists/blacklist bounce # # Explicitly listed whitelist addresses get thru (explicitly because # this is a hand maintained file) # from-file ~list/.tmda/lists/whitelist ok # # Normal list members get thru. Repeat this line as needed for each # of your lists, replacing "listname" with each listname. # from-mailman -attr=members ~list/lists/listname ok # # Digest members get thru. Repeat this line as needed for each of # your lists, replacing "listname" with each listname # from-mailman -attr=digest_members ~list/lists/listname ok # # Confirmed whitelist addresses get thru (the whitelist.auto file is # built by posters confirming themselves to TMDA) # from-file ~list/.tmda/lists/whitelist.auto ok # # Mail from the list control gets thru. Repeat these lines as needed # for each of your lists, replacing "listname" with each listname. # from listname-admin(a)kanga.nu ok from listname-owner(a)kanga.nu ok Tailor to suit as noted. Soon the complexity (and hand effort of adding the list-specific lines) will no longer be necessary as future versions of TMDA will have a more flexible filter schema that supports variable replacement. At this point you should be able to test your TMDA configuration (not including the Mailman specific bits), manually injecting messages into tmda-inject while having the environment variables SENDER and RECIPIENT appropriately set and seeing that it doesn't error (check the bounces and ~list/.tmda/logs/tmda-debug.log for specifics on errors). Check your TMDA setup carefully and pay particular attention to file permissions and ownership errors. Make sure you do all your testing as the Mailman user ("list" for Debian). You're now ready for the last step: integrating TMDA with Exim via procmail. Place the procmail rc in: ~list/.procmailrc Again, the ownership is list.list and permissions 0600. It should read something like: VERBOSE=off SHELL=/bin/sh PATH=/usr/bin:/usr/local/bin:/usr/lib:/usr/local/lib LOGFILE=/var/log/TMDA/procmail.log MAILDIR=/var/lib/mailman/locks # # Commands don't get filtered # :0 w * ACTION ?? mailcmd |/var/lib/mailman/mail/wrapper $ACTION $TARGET # # Pass bounces thru directly. # :0 w * ACTION ?? mailowner * ^Return-path: <> | /var/lib/mailman/mail/wrapper $ACTION $TARGET # # Mail that has already been filtered by TMDA. This is an added # header that is used to check for messages which have already been # processed by this TMDA/Mailman procmail filter. # :0 w * $^X-Mail-Filter-Recipient: $RECIPIENT { # # Send the message to Mailman for processing. This is a separate # recipe to make the extensions for MIME filter etc below clearer # and simpler. # :0 w * ACTION ?? post | /var/lib/mailman/mail/wrapper $ACTION $TARGET :0 w * ACTION ?? mailowner | /var/lib/mailman/mail/wrapper $ACTION $TARGET } # # Add the flag header so we can detect messages coming out of TMDA, # even as distinct from mail from other TMDA users. # :0 fw | /usr/bin/formail -A "X-Mail-Filter-Recipient: $RECIPIENT" # # Everything else (-admin, -owner, and posts which haven't been # passed by TMDA) get filtered thru tmda-filter. If you want # list-specific inbound filters instead globally shared lists, # insert a small script here which writes a message customised # inbound filter in (say) /tmp/tmda-inbound.$$, call tmda-filter # with a matching -I argument, and then delete the temporary inbound # filter afterwards. # :0 w | /usr/bin/tmda-filter -c /var/lib/mailman/.tmda/config # # Take the exit code from TMDA. This allows procmail to return in # error to the MTA. # EXITCODE=$? Notes: 1) Please use a different loop detection header than X-Mail-Filter-Recipient. Make something up that fits your needs. 2) The added loop detection will not be necessary with TMDA versions after 0.58 as they add their own custom header which you can use for host and recipient specific loop detection. As I do want to do MIME and other message pre-processing, and I want the ability to send messages which bypass the MIME filters, my ~list/.procmailrc is a little more complex. Adapt as appropriate to your installation: VERBOSE=off SHELL=/bin/sh PATH=/usr/bin:/usr/local/bin:/usr/lib:/usr/local/lib LOGFILE=/var/log/TMDA/procmail.log MAILDIR=/var/lib/mailman/locks # # Commands don't get filtered # :0 w * ACTION ?? mailcmd |/var/lib/mailman/mail/wrapper $ACTION $TARGET # # Pass bounces thru directly. # :0 w * ACTION ?? mailowner * ^Return-path: <> | /var/lib/mailman/mail/wrapper $ACTION $TARGET # # Mail that has already been filtered by TMDA. This is an added # header that is used to check for messages which have already been # processed by this TMDA/Mailman procmail filter. # :0 w * $^X-Kanga-Mail-Filter-Recipient: $RECIPIENT { # # Posts sent to a list # :0 w * ACTION ?? post { # # Got an X-MimeStripNo header? Don't MIME strip # :0 w * ^X-MimeStripNo { # # Remove the X-MimeStripNo header # :0 fw | formail -I X-MimeStrip } :0 w * ! ^X-MimeStripNo { # # Mimefilter -- As mimefilter requires that the local directory # be writable and that various environment variables are defined, # we use a wrapper script. # :0 fw | ~archiver/bin/MimeFilter # # Get rid of quoted-printable # :0 fw | /usr/bin/mimedecode } # # If there's nothing left of the message (less than 20 bytes), don't # bother sending it forward to Mailman. # :0 wb * < 20 | /dev/null # # We have a post! # :0 w | /var/lib/mailman/mail/wrapper $ACTION $TARGET } # # Messages to -admin and -ower # :0 w * ACTION ?? mailowner | /var/lib/mailman/mail/wrapper $ACTION $TARGET } # # Add the flag header so we can detect posts coming out of TMDA, # even as distinct from mail from other TMDA users. # :0 fw | /usr/bin/formail -A "X-Kanga-Mail-Filter-Recipient: $RECIPIENT" # # Everything else (-admin, -owner, and posts) get filtered thru TMDA # :0 w | /usr/bin/tmda-filter -c /var/lib/mailman/.tmda/config # # Take the exit code from TMDA. This allows procmail to return in # error to the MTA. # EXITCODE=$? Yeah, I could make that procmailrc cleaner and simpler. It works. Its a 1.0. I don't argue with working 1.0 versions. The contents of ~archiver/bin/MimeFilter are: #!/bin/bash #set -x # # Syntax: # # MimeStrip # # Author: J C Lawrence <claw(a)kanga.nu> # # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Config (Edit this bit to suit your setup!) # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Where is mimefilter? mimefilter="/usr/bin/mimefilter" # Note: Make sure that the value of tmpdir is writeable by the UID or GID # that this script will execute under. tmpdir="/tmp/mimestrip.${$}" # Do you want to save an mbox of the messages before filtering # in $savefile_pre? (0/1) feature_savepre=1 # Do you want to save an mbox of the messages after filtering # in $savefile_post? (0/1) feature_savepost=1 # File to save pre-filtered messages in savefile_pre="/tmp/mimestrip.prefilter" # File to same post filtered messages in savefile_post="/tmp/mimestrip.postfilter" # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # MimeFilter setup (Don't edit from here down) # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # The name of the mailing list this message is intended for. Used # as the return address of the warning issued to the orginal author # if the message is not already clean. export list=${USER} # The address of the mailing list this message is intended for. # Used in the X-Loop field of the warning issued to the original # author if the message is not already clean. export listaddr=${USER}@${DOMAIN} # The administrative (owner) address of the mailing list this # message is inteded for. Used in the return address of the warning # issued to the original author if the message is not already clean. export listreq=${USER}-admin@${DOMAIN} # The email address of the maintainer of the mailing list this # message is inteded for. If it is defined, it is used to send the # maintainer original carbon copies of messages that have been # modified by this filter -- if filter_mime_cc_maintainer is # affermative, of course. export maintainer=${USER}-owner@${DOMAIN} # A boolean flag: if affermative (i.e., if it matches the /y/i Perl # regular expression), the mimefilter script will send carbon copies # of every cleaned (modified) message to the maintainer of the # mailing list the message is intended for. export filter_mime_cc_maintainer=${copy_maintainer} # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Start working # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Build a safe working directory for mimefilter. We need to do this as # postfix by default will execute this script in /var/spool/postfix and # mimefilter will try and create temp directories and files under there, # which will fail on permissions. # Note: Make sure that the value of tmpdir is writeable by the UID or GID # that this script will execute under. /bin/rm -rf ${tmpdir} 2> /dev/null /bin/mkdir ${tmpdir} cd ${tmpdir} /bin/cat | ${mimefilter} # Save copies of the before and after messages off to a temp file for # analysis/debugging if [ ${feature_savepre} -eq 1 ] then /bin/cat ${holdfile} >> ${savefile_pre} echo >> ${savefile_pre} fi if [ ${feature_savepost} -eq 1 ] then /bin/cat ${workfile} >> ${savefile_post} echo >> ${savefile_post} fi # Clean up /bin/rm -rf ${tmpdir} exit Most of all that hassle is to get the environment variables mimefilter needs properly set and get the current working directory set to something I've write permissions to (eg /tmp). I could have done all that inside procmail (and probably should have). I didn't for purely historical reasons. mimedecode is a little tool which flattens quoted-printable into US ASCII. I find it rather useful. Take care here if you have posters posting with other character sets. As always: caveat emptor. At this point you should be able to test your procmail and TMDA configuration my injecting messages into procmail as below: # List posts cat message_file | procmail -mpt ACTION='post' TARGET='listname' ~list/.procmailrc # -request commands cat message_file | procmail -mpt ACTION='mailcmd' TARGET='listname' ~list/.procmailrc # -admin and -owner messages cat message_file | procmail -mpt ACTION='mailowner' TARGET='listname' ~list/.procmailrc Test it all out. Make sure TMDA is properly holding messages. Release, whitelist, blacklist etc them via: tmda-pending -c ~list/.tmda/config and watch the contents of ~list/.tmda/lists to ensure that the right things are happening. Work the whole system until you're certain that everything in the procmailrc and your TMDA configuration has been exercised and shown correct. Don't forget to go back and delete all your test addresses from the files under ~list/.tmda/lists. Remember to NOT delete the files and to do all your testing as the list user (file permissions are critical). You're now ready for the last step: Integrating with your MTA. Before we get to the message details some discussion on why I used Exim for this: I started out wanting and trying to use Postfix. The core problem I hit was making the filter process hung off the alias execute as the right user. I needed it to execute as the list user so it would be able to read the Mailman list configurations to verify subscribers from there. If you want to entirely separate posting rights from list subscription this wouldn't be a problem (just remove the mailman bits from ~list/filters/incoming). Getting the filter process to execute as 'list' under postfix proved a bitch. Its not impossible, but it requires either messing with content filters (which have a high performance overhead for ALL messages) or doing a vtable setup with a custom transport, which requires that you run your lists from a sub-domained virtual host (eg lists.kanga.nu). I am unwilling to make either compromise. YMMV. Exim conversely makes defining the specific effective UID and GID for an alias filter process very easy. I also like, know, and use Exim on other systems, so moving my list server back to Exim was no great pain. I don't like and refuse to use either Sendmail, and so can't comment on how TMDA may be integrated with it. I'm also not a QMail user and so can't comment for similar reasons. For those familiar with those respective MTAs you should be able to base off the below recipes (with the above caveats) successfully. The full set of Mailman-specific sections needed in /etc/exim/exim.conf are as below. Compare them carefully with the Nigel's HOW-TO for basic Exim/Mailman integration. The changes aren't large but you should understand each of them. The documentation at exim.org is excellent. These configurations are mildly Exim v3 specific. Exim v4 is noticeably but not fundamentally different. Use the documentation at exim.org to guide you thru the differences. In the main configuration section: # Add the Mailman user (list) to the value of trusted users so # procmail can use -p to pass environment variables through # (required by TMDA) trusted_users = mail:list # $HOME dir for Mailman MAILMAN_HOME=/var/lib/mailman # Wrapper script for Mailman MAILMAN_WRAP=MAILMAN_HOME/mail/wrapper # UID and GID for Mailman MAILMAN_UID=list MAILMAN_GID=mail In the transports section: list_transport: driver = pipe command = /usr/bin/procmail -mpt ACTION='post' TARGET='${lc:$local_part}' MAILMAN_HOME/.procmailrc # command = MAILMAN_WRAP post ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID return_path_add delivery_date_add envelope_to_add environment = EXTENSION=${substr_1:$local_part_suffix}:\ RECIPIENT=$local_part$local_part_suffix@$domain list_request_transport: driver = pipe command = /usr/bin/procmail -mpt ACTION='mailcmd' TARGET='${lc:$local_part}' MAILMAN_HOME/.procmailrc # command = MAILMAN_WRAP mailcmd ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID return_path_add delivery_date_add envelope_to_add environment = EXTENSION=${substr_1:$local_part_suffix}:\ RECIPIENT=$local_part$local_part_suffix@$domain list_admin_transport: driver = pipe command = /usr/bin/procmail -mpt ACTION='mailowner' TARGET='${lc:$local_part}' MAILMAN_HOME/.procmailrc # command = MAILMAN_WRAP mailowner ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID return_path_add delivery_date_add envelope_to_add environment = EXTENSION=${substr_1:$local_part_suffix}:\ RECIPIENT=$local_part$local_part_suffix@$domain In the directors section: list_owner_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db suffix = "-owner" new_address = "${lc:$local_part}-admin@${domain}" owner_list_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db prefix = "owner-" new_address = "${lc:$local_part}-admin@${domain}" list_admin_director: driver = smartuser suffix = -admin require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db transport = list_admin_transport list_request_director: driver = smartuser suffix = -request require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db transport = list_request_transport list_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db transport = list_transport suffix = +* suffix_optional Pay particular attention to the value of "suffix" in list-director and make sure it agrees with RECIPIENT_DELIMITER in ~list/.tmda/config. You should now be up and running with TMDA integrated as the front face of your Mailman lists. If you want to monitor your TMDA pending queue for your Mailman installation you can periodically run tmda-pending -c ~list/.tmda/config Or just drop the following cronjob in the Mailman user's crontab: * * * * * /usr/bin/tmda-pending -CTb | mail you(a)domain.tld to be emailed regular status updates on new messages in TMDA pending. Enjoy. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

3 3

[ mailman-Bugs-596565 ] mailman should use alphabetic U/GIDs
by noreply＠sourceforge.net 23 Aug '02

23 Aug '02

Bugs item #596565, was opened at 2002-08-17 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_i… Category: configuring/installing Group: 2.1 beta >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Todd Vierling (tvierling) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailman should use alphabetic U/GIDs Initial Comment: In short: "compiling in numeric IDs is Very Evil." The long story: I'm trying to put together a packaging environment for NetBSD's "pkgsrc" to allow easy build and install of Mailman. Unfortunately, this is currently impossible thanks to the fact that alphabetic IDs are resolved to numerics at compile time. (Nearly all packages requiring cutstom IDs resolve them at runtime using get {pw,gr}nam(3)). Thanks to this behavior, it is not currently possible to: * create a prebuilt binary package of Mailman, and install it later on a system without the source tarball; * migrate an existing installation of Mailman to another system that has a uid/gid conflict without recompiling. There are other problems that compiled-in numeric IDs cause, but these two really stick out. I'm not a Pythonhead, so I don't claim to know how to fix this correctly. However, I've attached a diff for configure.in that sets the framework for the start of fixing this problem. In particular, the diff changes the MM_FIND_*_ID macros to report the ID that matched without resolving names to numbers, and allows the build to proceed if forced --with-{user,group}name options are specified and those IDs don't exist at build time. (The latter case helps autopackaging in systems like NetBSD's pkgsrc, where the IDs may be autocreated *between* the "configure" and "make install" phases.) The things that still need to be done include fixing the main scripts, and the checkperms logic, to cope with either numeric or alphabetic IDs; and possibly adding a runtime configuration of IDs (which really helps if the admin needs to reconfigure or change the mail or Web servers, while avoiding to rebuild Mailman). I openly welcome Python gurus to look into what's *really* needed to fix this.... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 16:03 Message: Logged In: YES user_id=12800 I've thought about it more and I am going to apply this patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 18:45 Message: Logged In: YES user_id=12800 I like this idea a lot, even though the patch is far too incomplete. Fortunately, you motivated me to hack the code to support symbolic names instead of numeric ids. Attached is a patch I intend to commit for MM2.1b4. Would you please try it and see if it accomplishes what you need? One minor ugliness is that it retains --with-cgi-gid and --with-mail-gid as the configure switches to set the wrapper group names. Given the communities knowledge about these switches, I'm inclined not to change or deprecate them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_i…

1 0