From noreply at sourceforge.net Tue Dec 6 00:57:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 15:57:10 -0800 Subject: [ mailman-Bugs-1363422 ] Valid E-mails Rejected as Invalid Message-ID: Bugs item #1363422, was opened at 2005-11-21 21:26 Message generated for change (Comment added) made by krellis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1363422&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Tim Wilde (krellis) Assigned to: Nobody/Anonymous (nobody) Summary: Valid E-mails Rejected as Invalid Initial Comment: I ran into a problem recently with sync_members. I was attempting to add a list of addresses that included "---tim--- at krellis.org", but this address was rejected: bin/sync_members -a=no -f /usr/local/mailinglists/lists/system-status.txt system-status Invalid : ---tim--- at krellis.org You must fix the preceding invalid addresses first. While this is an ODD address, it is perfectly legal, per section 3.4 of RFC 2822 (http://www.faqs.org/rfcs/rfc2822.html). Rejecting a valid address like this seems like a pretty major problem to me. This was with MailMan 2.1.6 on FreeBSD 4. If there is any more information I can provide, please let me know. Regards, Tim Wilde ---------------------------------------------------------------------- >Comment By: Tim Wilde (krellis) Date: 2005-12-05 15:57 Message: Logged In: YES user_id=1021966 This appears to be a problem with line 210 of Utils.py, in the ValidateEmail function: if _badchars.search(s) or s[0] == '-': raise Errors.MMHostileAddress, s MailMan is explicitly rejecting e-mails that start with a hyphen. Why? This is a perfectly legal e-mail address. If MailMan is using e-mail addresses in such an unsafe way that they could be interpreted as command line arguments, that's just absurd. I can't see any other reason to forbid a leading hyphen, though. Can anyone tell me if I will be safe removing this check, or if MailMan will blow up elsewhere? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1363422&group_id=103 From noreply at sourceforge.net Thu Dec 8 11:12:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 02:12:03 -0800 Subject: [ mailman-Bugs-971957 ] Uncaught runner exception Message-ID: Bugs item #971957, was opened at 2004-06-13 06:36 Message generated for change (Comment added) made by doctorchd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Distler (jd_waverly) Assigned to: Nobody/Anonymous (nobody) Summary: Uncaught runner exception Initial Comment: In 2.1.5 Apparently some email message characters can crash the Runner.py. I have inserted $mailman in place of my mailman path in the message below from $mailman/logs/error Jun 12 01:25:48 2004 (16604) Uncaught runner exception: ASCII decoding error: ordinal not in range (128) Jun 12 01:25:48 2004 (16604) Traceback (most recent call last): File "$mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File $mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 223, in _dispose res = Results(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 77, in __init__ subj = make_header(decode_header (subj)).__unicode__() File "$mailman/pythonlib/email/Header.py", line 144, in make_header h.append(s, charset) File "$mailman/pythonlib/email/Header.py", line 272, in append ustr = unicode(s, incodec, errors) UnicodeError: ASCII decoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: chd (doctorchd) Date: 2005-12-08 12:12 Message: Logged In: YES user_id=1400126 mailman 2.1.6 on FreeBSD (default installation from ports collection) python-2.4.2 A letter with charset=ISO-2022-JP stopped a maillist. New letters are added to the digest but not get sent. logs/error: Dec 08 11:12:05 2005 (8832) Uncaught runner exception: ISO-2022-JP decoding error: invalid designation Dec 08 11:12:05 2005 (8832) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 92, in process send_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 331, in send_i18n_digests payload = unicode(payload, mcset, 'replace' UnicodeError: ISO-2022-JP decoding error: invalid designation Dec 08 11:12:05 2005 (8832) SHUNTING: 1134033124.1110449+22e27c8eb18c70264c17eb27d07146812a8c656c I can present the letter that causes this error (I didn't find how is it possible to attach a file here). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-23 08:00 Message: Logged In: YES user_id=1123998 gray-john wrote: > >I'm seeing this in 2.1.6 as well. We are running Debian >Sarge. Any word on getting this resolved? This error was fixed in source in 2.1.6 by catching and passing the UnicodeError exception. See bug 909490 which is the same problem. If you are seeing this error in 2.1.6, it must be coming from somewhere other than CommandRunner calling make_header. I suggest you try to get a resolution by posting your specific error trace to mailman-users at python.org. I'm closing this report. ---------------------------------------------------------------------- Comment By: John Gray (gray-john) Date: 2005-11-23 01:31 Message: Logged In: YES user_id=392368 I'm seeing this in 2.1.6 as well. We are running Debian Sarge. Any word on getting this resolved? ---------------------------------------------------------------------- Comment By: Tommi Tervo (tomtervo) Date: 2004-07-30 16:42 Message: Logged In: YES user_id=1094436 Do you need some additional information for debugging this one, I've over 200 mails stuck on shunts. AFAIK this is quite fatal bug, emails just disappear and nobody gets notification. UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 10: ordinal not in range(128) Mailman 2.1.5 and python 2.3.4 on Solaris 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 From noreply at sourceforge.net Thu Dec 8 17:16:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 08:16:38 -0800 Subject: [ mailman-Bugs-971957 ] Uncaught runner exception Message-ID: Bugs item #971957, was opened at 2004-06-12 20:36 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Distler (jd_waverly) Assigned to: Nobody/Anonymous (nobody) Summary: Uncaught runner exception Initial Comment: In 2.1.5 Apparently some email message characters can crash the Runner.py. I have inserted $mailman in place of my mailman path in the message below from $mailman/logs/error Jun 12 01:25:48 2004 (16604) Uncaught runner exception: ASCII decoding error: ordinal not in range (128) Jun 12 01:25:48 2004 (16604) Traceback (most recent call last): File "$mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File $mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 223, in _dispose res = Results(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 77, in __init__ subj = make_header(decode_header (subj)).__unicode__() File "$mailman/pythonlib/email/Header.py", line 144, in make_header h.append(s, charset) File "$mailman/pythonlib/email/Header.py", line 272, in append ustr = unicode(s, incodec, errors) UnicodeError: ASCII decoding error: ordinal not in range (128) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-12-08 08:16 Message: Logged In: YES user_id=1123998 A few remarks with regard to the 2005-12-08 comment from doctorchd: 1) Posting new information to a Closed/Fixed Bug report is not too useful. It would be better to generate a new report. 2) The Traceback and error reported by doctorchd is not at all the same error as the one originnaly reported in this report. The only thing they have in common is they both generate uncaught UnicodeError exceptions. 3) The error reported by doctorchd is fixed by patch 1246003 which has been accepted and is in CVS. ---------------------------------------------------------------------- Comment By: chd (doctorchd) Date: 2005-12-08 02:12 Message: Logged In: YES user_id=1400126 mailman 2.1.6 on FreeBSD (default installation from ports collection) python-2.4.2 A letter with charset=ISO-2022-JP stopped a maillist. New letters are added to the digest but not get sent. logs/error: Dec 08 11:12:05 2005 (8832) Uncaught runner exception: ISO-2022-JP decoding error: invalid designation Dec 08 11:12:05 2005 (8832) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 92, in process send_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 331, in send_i18n_digests payload = unicode(payload, mcset, 'replace' UnicodeError: ISO-2022-JP decoding error: invalid designation Dec 08 11:12:05 2005 (8832) SHUNTING: 1134033124.1110449+22e27c8eb18c70264c17eb27d07146812a8c656c I can present the letter that causes this error (I didn't find how is it possible to attach a file here). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-22 22:00 Message: Logged In: YES user_id=1123998 gray-john wrote: > >I'm seeing this in 2.1.6 as well. We are running Debian >Sarge. Any word on getting this resolved? This error was fixed in source in 2.1.6 by catching and passing the UnicodeError exception. See bug 909490 which is the same problem. If you are seeing this error in 2.1.6, it must be coming from somewhere other than CommandRunner calling make_header. I suggest you try to get a resolution by posting your specific error trace to mailman-users at python.org. I'm closing this report. ---------------------------------------------------------------------- Comment By: John Gray (gray-john) Date: 2005-11-22 15:31 Message: Logged In: YES user_id=392368 I'm seeing this in 2.1.6 as well. We are running Debian Sarge. Any word on getting this resolved? ---------------------------------------------------------------------- Comment By: Tommi Tervo (tomtervo) Date: 2004-07-30 06:42 Message: Logged In: YES user_id=1094436 Do you need some additional information for debugging this one, I've over 200 mails stuck on shunts. AFAIK this is quite fatal bug, emails just disappear and nobody gets notification. UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 10: ordinal not in range(128) Mailman 2.1.5 and python 2.3.4 on Solaris 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 From noreply at sourceforge.net Sat Dec 10 22:43:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 13:43:41 -0800 Subject: [ mailman-Bugs-1152953 ] Cancelling a subscription confirmation throws assertion Message-ID: Bugs item #1152953, was opened at 2005-02-27 09:15 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1152953&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geoff Mottram (gmottram) Assigned to: Nobody/Anonymous (nobody) Summary: Cancelling a subscription confirmation throws assertion Initial Comment: When you use the web interface to confirm a subscription and select the "Cancel my subscription request", Mailman throws an assertion. The problem can be fixed by replacing line 312 in Mailman/Cgi/confirm.py which currently reads: userdesc = mlist.pend_confirm(cookie)[1] With the following code: mlist.Lock() try: userdesc = mlist.pend_confirm(cookie)[1] finally: mlist.Unlock() More detailed information on this fix can be found here: http://www.minaret.biz/tips/mailman2.html Geoff Mottram ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-12-10 13:43 Message: Logged In: YES user_id=1123998 This is a duplicate of 981188, fixed in Mailman 2.1.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1152953&group_id=103 From noreply at sourceforge.net Sun Dec 11 20:54:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 11:54:38 -0800 Subject: [ mailman-Bugs-1378270 ] make check_perms ensure aliases.db is group-writeable Message-ID: Bugs item #1378270, was opened at 2005-12-11 14:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1378270&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Todd (beelzebozo) Assigned to: Nobody/Anonymous (nobody) Summary: make check_perms ensure aliases.db is group-writeable Initial Comment: checkperms in the Postfix module doesn't ensure that both aliases and aliases.db are group writable. The attached patch against CVS (20051211) fixes this by copying the check for aliases to also check aliases.db. It also patches mailman-install.tex to make it clear that both files should be group writable. See Tracker 1204386[1] and Mailman FAQ 6.9[2] for reports on this problem. [1] https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1204386&group_id=103 [2] http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.009.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1378270&group_id=103 From noreply at sourceforge.net Sun Dec 11 20:57:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 11:57:02 -0800 Subject: [ mailman-Bugs-1204386 ] check_perms doesn't ensure aliases.db is group-writeable Message-ID: Bugs item #1204386, was opened at 2005-05-18 12:01 Message generated for change (Comment added) made by beelzebozo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1204386&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Graham Klyne (grahamk) Assigned to: Nobody/Anonymous (nobody) Summary: check_perms doesn't ensure aliases.db is group-writeable Initial Comment: Problem reported for mailman 2.1.6rc4 With postfix 2:2.0.16-14.RHEL3 When installing mailman 2.1.6rc1 using postfix MTA and "Integrating Postfix and Mailman" as described inthe installation document, I encountered a problem that the aliases.db file was created without group write capability. This was not detected by check_perms. (Even on re-reading, it's not obvious to me that g+w permissions are required, though that became pretty obvious when I tracked the error log failure report when attempting to create a new mailing list.) Because I messed around a bit with that installation, I've verified the problem with check_perms on a working 2.1.6rc4 installation, by resetting the groupwrite permission, thus: The following is executed as user mailman in dirtectory /var/mailman/data: [[ bash-2.05b$ ls -al total 60 drwxrwsr-x 2 mailman mailman 4096 May 18 14:31 . drwxrwsr-x 9 mailman mailman 4096 Apr 21 18:36 .. -rw-r----- 1 mailman mailman 41 Apr 29 13:54 adm.pw -rw-rw---- 1 mailman mailman 4922 May 4 16:25 aliases -rw-rw---- 1 mailman mailman 12288 May 4 16:25 aliases.db -rw-r----- 1 mailman mailman 41 Apr 22 15:07 creator.pw -rw-r--r-- 1 mailman mailman 10 May 18 14:32 last_mailman_version -rw-rw---- 1 mailman mailman 6 May 12 09:19 master-qrunner.pid -rw-r--r-- 1 mailman mailman 14110 May 18 14:31 sitelist.cfg bash-2.05b$ bash-2.05b$ /home/mailman/bin/check_perms No problems found (This is a normal working configuration from which I started) bash-2.05b$ chmod g-w aliases* bash-2.05b$ /home/mailman/bin/check_perms /var/mailman/data/aliases permissions must be 066x (got 0100640) Problems found: 1 Re-run as mailman (or root) with -f flag to fix (check_perms notices the problem with aliases, but not with aliases.db) bash-2.05b$ ls -al total 60 drwxrwsr-x 2 mailman mailman 4096 May 18 14:31 . drwxrwsr-x 9 mailman mailman 4096 Apr 21 18:36 .. -rw-r----- 1 mailman mailman 41 Apr 29 13:54 adm.pw -rw-r----- 1 mailman mailman 4922 May 4 16:25 aliases -rw-r----- 1 mailman mailman 12288 May 4 16:25 aliases.db -rw-r----- 1 mailman mailman 41 Apr 22 15:07 creator.pw -rw-r--r-- 1 mailman mailman 10 May 18 14:32 last_mailman_version -rw-rw---- 1 mailman mailman 6 May 12 09:19 master-qrunner.pid -rw-r--r-- 1 mailman mailman 14110 May 18 14:31 sitelist.cfg bash-2.05b$ chmod g+w aliases bash-2.05b$ /home/mailman/bin/check_perms No problems found bash-2.05b$ ls -al total 60 drwxrwsr-x 2 mailman mailman 4096 May 18 14:31 . drwxrwsr-x 9 mailman mailman 4096 Apr 21 18:36 .. -rw-r----- 1 mailman mailman 41 Apr 29 13:54 adm.pw -rw-rw---- 1 mailman mailman 4922 May 4 16:25 aliases -rw-r----- 1 mailman mailman 12288 May 4 16:25 aliases.db -rw-r----- 1 mailman mailman 41 Apr 22 15:07 creator.pw -rw-r--r-- 1 mailman mailman 10 May 18 14:32 last_mailman_version -rw-rw---- 1 mailman mailman 6 May 12 09:19 master-qrunner.pid -rw-r--r-- 1 mailman mailman 14110 May 18 14:31 sitelist.cfg (No report from check_perms despite missing group write permission on aliases.db) ]] ---------------------------------------------------------------------- Comment By: Todd (beelzebozo) Date: 2005-12-11 14:57 Message: Logged In: YES user_id=1386166 Patch against CVS (20051211) created. See https://sourceforge.net/tracker/index.php?func=detail&aid=1378270&group_id=103&atid=100103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1204386&group_id=103 From noreply at sourceforge.net Mon Dec 12 17:33:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 08:33:02 -0800 Subject: [ mailman-Patches-933757 ] fix for [815297] signatures break Message-ID: Patches item #933757, was opened at 2004-04-12 19:15 Message generated for change (Comment added) made by schoinobates You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=933757&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Bernhard Reiter (ber) Assigned to: Nobody/Anonymous (nobody) Summary: fix for [815297] signatures break Initial Comment: Fix attempt for [ 815297 ] Breaking signatures in message/rfc822 attachement! https://sourceforge.net/tracker/?func=detail&aid=815297&group_id=103&atid=100103 The patch introduces a new Mailman specific Generator class and only enables header folding for the top object and Mailbox.py and SMTPDirect.py. ---------------------------------------------------------------------- Comment By: Schoinobates Volans (schoinobates) Date: 2005-12-12 17:33 Message: Logged In: YES user_id=41822 A slightly edited version of this patch is at http://bugs.debian.org/cgi-bin/bugreport.cgi/77_header_folding_in_attachments.dpatch?bug=244673;msg=65;att=1 ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 19:56 Message: Logged In: YES user_id=113859 My patch was tested with python 2.3.3. Thomas K?ster made a patch which also works with python 2.1.x I'll attach it. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-12 19:24 Message: Logged In: YES user_id=113859 A bug fix to a priority 8 bug... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=933757&group_id=103 From noreply at sourceforge.net Tue Dec 13 02:00:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 17:00:23 -0800 Subject: [ mailman-Bugs-1378270 ] make check_perms ensure aliases.db is group-writeable Message-ID: Bugs item #1378270, was opened at 2005-12-11 19:54 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1378270&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Todd (beelzebozo) Assigned to: Nobody/Anonymous (nobody) Summary: make check_perms ensure aliases.db is group-writeable Initial Comment: checkperms in the Postfix module doesn't ensure that both aliases and aliases.db are group writable. The attached patch against CVS (20051211) fixes this by copying the check for aliases to also check aliases.db. It also patches mailman-install.tex to make it clear that both files should be group writable. See Tracker 1204386[1] and Mailman FAQ 6.9[2] for reports on this problem. [1] https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1204386&group_id=103 [2] http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.009.htp ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-12-13 01:00 Message: Logged In: YES user_id=67709 Checked in CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1378270&group_id=103 From noreply at sourceforge.net Tue Dec 13 02:02:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 17:02:12 -0800 Subject: [ mailman-Bugs-1204386 ] check_perms doesn't ensure aliases.db is group-writeable Message-ID: Bugs item #1204386, was opened at 2005-05-18 16:01 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1204386&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configuring/installing Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Graham Klyne (grahamk) Assigned to: Nobody/Anonymous (nobody) Summary: check_perms doesn't ensure aliases.db is group-writeable Initial Comment: Problem reported for mailman 2.1.6rc4 With postfix 2:2.0.16-14.RHEL3 When installing mailman 2.1.6rc1 using postfix MTA and "Integrating Postfix and Mailman" as described inthe installation document, I encountered a problem that the aliases.db file was created without group write capability. This was not detected by check_perms. (Even on re-reading, it's not obvious to me that g+w permissions are required, though that became pretty obvious when I tracked the error log failure report when attempting to create a new mailing list.) Because I messed around a bit with that installation, I've verified the problem with check_perms on a working 2.1.6rc4 installation, by resetting the groupwrite permission, thus: The following is executed as user mailman in dirtectory /var/mailman/data: [[ bash-2.05b$ ls -al total 60 drwxrwsr-x 2 mailman mailman 4096 May 18 14:31 . drwxrwsr-x 9 mailman mailman 4096 Apr 21 18:36 .. -rw-r----- 1 mailman mailman 41 Apr 29 13:54 adm.pw -rw-rw---- 1 mailman mailman 4922 May 4 16:25 aliases -rw-rw---- 1 mailman mailman 12288 May 4 16:25 aliases.db -rw-r----- 1 mailman mailman 41 Apr 22 15:07 creator.pw -rw-r--r-- 1 mailman mailman 10 May 18 14:32 last_mailman_version -rw-rw---- 1 mailman mailman 6 May 12 09:19 master-qrunner.pid -rw-r--r-- 1 mailman mailman 14110 May 18 14:31 sitelist.cfg bash-2.05b$ bash-2.05b$ /home/mailman/bin/check_perms No problems found (This is a normal working configuration from which I started) bash-2.05b$ chmod g-w aliases* bash-2.05b$ /home/mailman/bin/check_perms /var/mailman/data/aliases permissions must be 066x (got 0100640) Problems found: 1 Re-run as mailman (or root) with -f flag to fix (check_perms notices the problem with aliases, but not with aliases.db) bash-2.05b$ ls -al total 60 drwxrwsr-x 2 mailman mailman 4096 May 18 14:31 . drwxrwsr-x 9 mailman mailman 4096 Apr 21 18:36 .. -rw-r----- 1 mailman mailman 41 Apr 29 13:54 adm.pw -rw-r----- 1 mailman mailman 4922 May 4 16:25 aliases -rw-r----- 1 mailman mailman 12288 May 4 16:25 aliases.db -rw-r----- 1 mailman mailman 41 Apr 22 15:07 creator.pw -rw-r--r-- 1 mailman mailman 10 May 18 14:32 last_mailman_version -rw-rw---- 1 mailman mailman 6 May 12 09:19 master-qrunner.pid -rw-r--r-- 1 mailman mailman 14110 May 18 14:31 sitelist.cfg bash-2.05b$ chmod g+w aliases bash-2.05b$ /home/mailman/bin/check_perms No problems found bash-2.05b$ ls -al total 60 drwxrwsr-x 2 mailman mailman 4096 May 18 14:31 . drwxrwsr-x 9 mailman mailman 4096 Apr 21 18:36 .. -rw-r----- 1 mailman mailman 41 Apr 29 13:54 adm.pw -rw-rw---- 1 mailman mailman 4922 May 4 16:25 aliases -rw-r----- 1 mailman mailman 12288 May 4 16:25 aliases.db -rw-r----- 1 mailman mailman 41 Apr 22 15:07 creator.pw -rw-r--r-- 1 mailman mailman 10 May 18 14:32 last_mailman_version -rw-rw---- 1 mailman mailman 6 May 12 09:19 master-qrunner.pid -rw-r--r-- 1 mailman mailman 14110 May 18 14:31 sitelist.cfg (No report from check_perms despite missing group write permission on aliases.db) ]] ---------------------------------------------------------------------- Comment By: Todd (beelzebozo) Date: 2005-12-11 19:57 Message: Logged In: YES user_id=1386166 Patch against CVS (20051211) created. See https://sourceforge.net/tracker/index.php?func=detail&aid=1378270&group_id=103&atid=100103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1204386&group_id=103 From noreply at sourceforge.net Fri Dec 16 01:50:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 16:50:42 -0800 Subject: [ mailman-Patches-1290317 ] add date field to the mail list archive index page Message-ID: Patches item #1290317, was opened at 2005-09-13 10:37 Message generated for change (Comment added) made by elfern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1290317&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Matt Ryanczak (ryanczak) Assigned to: Nobody/Anonymous (nobody) Summary: add date field to the mail list archive index page Initial Comment: I was asked to make the date for each message in a mailman archive be visible in the index for that month. This required that I modify HyperArch.py and the template file archidxentry.html. I thought others might find this useful so here is the relevant patch for the mailman-2.1.6 source tree. Apply the following patch to your mailman-2.1.6 source tree and build as usual. patch -p0 < date-in-archive-index.patch. This patch will modify the following files: mailman-2.1.6/Mailman/Archiver/HyperArch.py mailman-2.1.6/templates/ca/archidxentry.html mailman-2.1.6/templates/en/archidxentry.html mailman-2.1.6/templates/es/archidxentry.html mailman-2.1.6/templates/eu/archidxentry.html mailman-2.1.6/templates/fr/archidxentry.html mailman-2.1.6/templates/hr/archidxentry.html mailman-2.1.6/templates/hu/archidxentry.html mailman-2.1.6/templates/it/archidxentry.html mailman-2.1.6/templates/ja/archidxentry.html mailman-2.1.6/templates/lt/archidxentry.html mailman-2.1.6/templates/pl/archidxentry.html mailman-2.1.6/templates/pt/archidxentry.html mailman-2.1.6/templates/pt_BR/archidxentry.html mailman-2.1.6/templates/ro/archidxentry.html mailman-2.1.6/templates/ru/archidxentry.html mailman-2.1.6/templates/sl/archidxentry.html mailman-2.1.6/templates/sr/archidxentry.html mailman-2.1.6/templates/tr/archidxentry.html mailman-2.1.6/templates/uk/archidxentry.html mailman-2.1.6/templates/zh_CN/archidxentry.html ---------------------------------------------------------------------- Comment By: elfern (elfern) Date: 2005-12-15 16:50 Message: Logged In: YES user_id=1406050 Is it possible to put a tarball of these patches ? I downloaded these patches, and did: patch -p0 < date-in-archive-index.patch This reported: Looks like a unified context diff. File to patch: mailman-2.1.6/Mailman/Archiver/HyperArch.py Reversed (or previously applied) patch detected! Assume -R [yes] Apply anyway? [no] yes Hunk #2 failed at line 1032. Hunk #3 failed at line 1. Hunk #4 failed at line 1. Hunk #5 failed at line 1. Hunk #6 failed at line 1. Hunk #7 failed at line 1. Hunk #8 failed at line 1. Hunk #9 failed at line 1. Hunk #10 failed at line 1. Hunk #11 failed at line 1. Hunk #12 failed at line 1. Hunk #13 failed at line 1. Hunk #14 failed at line 1. Hunk #15 failed at line 1. Hunk #16 failed at line 1. Hunk #17 failed at line 1. Hunk #18 failed at line 1. Hunk #19 failed at line 1. Hunk #20 failed at line 1. Hunk #21 failed at line 1. Hunk #22 failed at line 1. 21 out of 22 hunks failed: saving rejects to mailman- 2.1.6/Mailman/Archiver/HyperArch.py.rej done Now, I am not sure if the patch got applied. The timestamp on HyperArch.py is updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1290317&group_id=103 From noreply at sourceforge.net Fri Dec 16 16:16:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 07:16:41 -0800 Subject: [ mailman-Patches-1287546 ] Remove DomainKeys (and similar) header lines Message-ID: Patches item #1287546, was opened at 2005-09-11 10:08 Message generated for change (Comment added) made by markonen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: Remove DomainKeys (and similar) header lines Initial Comment: This simple patch removes the header lines containing keys used in DomainKeys (Yahoo) and DKIM. The keys, if left in the header, will make the email seem forged or altered to the recipient, since Mailman alters header/body info. If the keys are removed, the MTA will generate new keys (if this is installed on the host). -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 17:16 Message: Logged In: YES user_id=1406492 I think this is problematic. For intra-organizational lists, removing the DomainKeys header works as advertised. However, if a person from a DomainKeys-enabled domain posts onto an external list, there is a potential for error. If the sender's domain's DomainKeys settings specify that the domain does not send unsigned mail, external MTAs can and will drop an email from that domain if the DomainKeys headers are removed. To make DomainKeys work with mailman as expected, admins have two possibilities: 1) Deliver the message as-is, without modifying the Subject header or message body (or any header indicated to be signed). The original DomainKeys signature will then work. 2) If modifying the message is necessary, the mailing list will have to rewrite the From: header in order not to claim that the message originated in the DomainKeys -protected sender domain. Removing the DomainKeys header will only be relevant in the case 2) above. For 1) -- the preferred solution for many lists -- it is actively harmful. Therefore, automatically removing the DomainKeys header is NOT the way to go. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-13 00:59 Message: Logged In: YES user_id=12800 Applied to both Mailman 2.1 branch and trunk (2.2) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-09-11 10:09 Message: Logged In: YES user_id=738814 Attached is the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 From noreply at sourceforge.net Fri Dec 16 18:01:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 09:01:12 -0800 Subject: [ mailman-Patches-1287546 ] Remove DomainKeys (and similar) header lines Message-ID: Patches item #1287546, was opened at 2005-09-11 01:08 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: Remove DomainKeys (and similar) header lines Initial Comment: This simple patch removes the header lines containing keys used in DomainKeys (Yahoo) and DKIM. The keys, if left in the header, will make the email seem forged or altered to the recipient, since Mailman alters header/body info. If the keys are removed, the MTA will generate new keys (if this is installed on the host). -Joe ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-12-16 10:01 Message: Logged In: YES user_id=738814 Markonen, I agree that the whole DKIM/DomainKeys issue is a bit of a mess. It makes me wonder about the future of such email verification schemes. It seems that any mail list mechanism has the potential for breaking them. As to your concern, I believe we are OK in that #2 already happens. Mailman adds a "Sender:" header line, and DKIM/DomainKeys will use this as the source domain to determine if signing is expected, etc. So if the sender host re-signs the email, things should be OK. The problem here, of course, is that the receiver will only know that the email came from the mail list host - not that the original email came from the original author - less than ideal. I was enthusiastic about DKIM, but I am a little less so now due to these shortcomings. Your #1 is probably not possible, since I doubt we could expect Mailman to never modify body/headers... right? -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 08:16 Message: Logged In: YES user_id=1406492 I think this is problematic. For intra-organizational lists, removing the DomainKeys header works as advertised. However, if a person from a DomainKeys-enabled domain posts onto an external list, there is a potential for error. If the sender's domain's DomainKeys settings specify that the domain does not send unsigned mail, external MTAs can and will drop an email from that domain if the DomainKeys headers are removed. To make DomainKeys work with mailman as expected, admins have two possibilities: 1) Deliver the message as-is, without modifying the Subject header or message body (or any header indicated to be signed). The original DomainKeys signature will then work. 2) If modifying the message is necessary, the mailing list will have to rewrite the From: header in order not to claim that the message originated in the DomainKeys -protected sender domain. Removing the DomainKeys header will only be relevant in the case 2) above. For 1) -- the preferred solution for many lists -- it is actively harmful. Therefore, automatically removing the DomainKeys header is NOT the way to go. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-12 15:59 Message: Logged In: YES user_id=12800 Applied to both Mailman 2.1 branch and trunk (2.2) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-09-11 01:09 Message: Logged In: YES user_id=738814 Attached is the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 From noreply at sourceforge.net Fri Dec 16 20:23:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:23:37 -0800 Subject: [ mailman-Patches-1287546 ] Remove DomainKeys (and similar) header lines Message-ID: Patches item #1287546, was opened at 2005-09-11 10:08 Message generated for change (Comment added) made by markonen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: Remove DomainKeys (and similar) header lines Initial Comment: This simple patch removes the header lines containing keys used in DomainKeys (Yahoo) and DKIM. The keys, if left in the header, will make the email seem forged or altered to the recipient, since Mailman alters header/body info. If the keys are removed, the MTA will generate new keys (if this is installed on the host). -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 21:23 Message: Logged In: YES user_id=1406492 I'm currently using mailman 2.1.2, and with it, DomainKeys works OK for plain text messages if we disable any subject mangling, list footers etc. It doesn't work with attachments, but I've understood that this is because of some MIME mangling bugs that have since been fixed. So, I was looking forward to the case 1) working fully (even with attachments) with a current mailman version, but this patch will apparently prevent that. DomainKeys is, of course, more brittle than unprotected email, but I think its impact on intermediate systems is much smaller than with SPF or Sender-ID. Mail forwarders only have to forward messages as-is, not do any SPF-specific path mangling magic. I don't deny that removing the DomainKeys headers is a useful option to have, however -- but I think it should be an option. (Alternatively, we could look at this from the other direction and make the "don't touch anything" an option. i.e. have a single master switch that would turn off subject and body mangling and preserve DomainKeys headers as-is. S/MIME is the other important use case for this.) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-12-16 19:01 Message: Logged In: YES user_id=738814 Markonen, I agree that the whole DKIM/DomainKeys issue is a bit of a mess. It makes me wonder about the future of such email verification schemes. It seems that any mail list mechanism has the potential for breaking them. As to your concern, I believe we are OK in that #2 already happens. Mailman adds a "Sender:" header line, and DKIM/DomainKeys will use this as the source domain to determine if signing is expected, etc. So if the sender host re-signs the email, things should be OK. The problem here, of course, is that the receiver will only know that the email came from the mail list host - not that the original email came from the original author - less than ideal. I was enthusiastic about DKIM, but I am a little less so now due to these shortcomings. Your #1 is probably not possible, since I doubt we could expect Mailman to never modify body/headers... right? -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 17:16 Message: Logged In: YES user_id=1406492 I think this is problematic. For intra-organizational lists, removing the DomainKeys header works as advertised. However, if a person from a DomainKeys-enabled domain posts onto an external list, there is a potential for error. If the sender's domain's DomainKeys settings specify that the domain does not send unsigned mail, external MTAs can and will drop an email from that domain if the DomainKeys headers are removed. To make DomainKeys work with mailman as expected, admins have two possibilities: 1) Deliver the message as-is, without modifying the Subject header or message body (or any header indicated to be signed). The original DomainKeys signature will then work. 2) If modifying the message is necessary, the mailing list will have to rewrite the From: header in order not to claim that the message originated in the DomainKeys -protected sender domain. Removing the DomainKeys header will only be relevant in the case 2) above. For 1) -- the preferred solution for many lists -- it is actively harmful. Therefore, automatically removing the DomainKeys header is NOT the way to go. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-13 00:59 Message: Logged In: YES user_id=12800 Applied to both Mailman 2.1 branch and trunk (2.2) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-09-11 10:09 Message: Logged In: YES user_id=738814 Attached is the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 From noreply at sourceforge.net Sat Dec 17 19:51:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 10:51:15 -0800 Subject: [ mailman-Patches-1287546 ] Remove DomainKeys (and similar) header lines Message-ID: Patches item #1287546, was opened at 2005-09-11 01:08 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: Remove DomainKeys (and similar) header lines Initial Comment: This simple patch removes the header lines containing keys used in DomainKeys (Yahoo) and DKIM. The keys, if left in the header, will make the email seem forged or altered to the recipient, since Mailman alters header/body info. If the keys are removed, the MTA will generate new keys (if this is installed on the host). -Joe ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-12-17 11:51 Message: Logged In: YES user_id=738814 If it's possible to have Mailman pass the message and header through in a way that does not impact DKIM/DomainKeys, that's certainly an interesting idea. I wonder, though, if header changes required when a message is forwarded via a mailing list would always be compatible. Anyway, this as an option is certainly worth exploring. Because of things like mailing lists, I do wonder if things like DKIM and DomainKeys (and even more so SPF - I cannot believe there as been as much adoption as there has been of SPF!) will ever be viable. It seems that to get the benefit, one would need to set up strict policies, but then one risks losing mail through mailing lists, etc. ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 12:23 Message: Logged In: YES user_id=1406492 I'm currently using mailman 2.1.2, and with it, DomainKeys works OK for plain text messages if we disable any subject mangling, list footers etc. It doesn't work with attachments, but I've understood that this is because of some MIME mangling bugs that have since been fixed. So, I was looking forward to the case 1) working fully (even with attachments) with a current mailman version, but this patch will apparently prevent that. DomainKeys is, of course, more brittle than unprotected email, but I think its impact on intermediate systems is much smaller than with SPF or Sender-ID. Mail forwarders only have to forward messages as-is, not do any SPF-specific path mangling magic. I don't deny that removing the DomainKeys headers is a useful option to have, however -- but I think it should be an option. (Alternatively, we could look at this from the other direction and make the "don't touch anything" an option. i.e. have a single master switch that would turn off subject and body mangling and preserve DomainKeys headers as-is. S/MIME is the other important use case for this.) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-12-16 10:01 Message: Logged In: YES user_id=738814 Markonen, I agree that the whole DKIM/DomainKeys issue is a bit of a mess. It makes me wonder about the future of such email verification schemes. It seems that any mail list mechanism has the potential for breaking them. As to your concern, I believe we are OK in that #2 already happens. Mailman adds a "Sender:" header line, and DKIM/DomainKeys will use this as the source domain to determine if signing is expected, etc. So if the sender host re-signs the email, things should be OK. The problem here, of course, is that the receiver will only know that the email came from the mail list host - not that the original email came from the original author - less than ideal. I was enthusiastic about DKIM, but I am a little less so now due to these shortcomings. Your #1 is probably not possible, since I doubt we could expect Mailman to never modify body/headers... right? -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 08:16 Message: Logged In: YES user_id=1406492 I think this is problematic. For intra-organizational lists, removing the DomainKeys header works as advertised. However, if a person from a DomainKeys-enabled domain posts onto an external list, there is a potential for error. If the sender's domain's DomainKeys settings specify that the domain does not send unsigned mail, external MTAs can and will drop an email from that domain if the DomainKeys headers are removed. To make DomainKeys work with mailman as expected, admins have two possibilities: 1) Deliver the message as-is, without modifying the Subject header or message body (or any header indicated to be signed). The original DomainKeys signature will then work. 2) If modifying the message is necessary, the mailing list will have to rewrite the From: header in order not to claim that the message originated in the DomainKeys -protected sender domain. Removing the DomainKeys header will only be relevant in the case 2) above. For 1) -- the preferred solution for many lists -- it is actively harmful. Therefore, automatically removing the DomainKeys header is NOT the way to go. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-12 15:59 Message: Logged In: YES user_id=12800 Applied to both Mailman 2.1 branch and trunk (2.2) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-09-11 01:09 Message: Logged In: YES user_id=738814 Attached is the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 From noreply at sourceforge.net Sun Dec 18 13:42:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 04:42:42 -0800 Subject: [ mailman-Patches-1287546 ] Remove DomainKeys (and similar) header lines Message-ID: Patches item #1287546, was opened at 2005-09-11 10:08 Message generated for change (Comment added) made by markonen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: Remove DomainKeys (and similar) header lines Initial Comment: This simple patch removes the header lines containing keys used in DomainKeys (Yahoo) and DKIM. The keys, if left in the header, will make the email seem forged or altered to the recipient, since Mailman alters header/body info. If the keys are removed, the MTA will generate new keys (if this is installed on the host). -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-18 14:42 Message: Logged In: YES user_id=1406492 Yup, I have DomainKeys working with Mailman. Here's an example DomainKeys header of a message that passed through Mailman just fine: DomainKey-Signature: a=rsa-sha1; s=mail; d=karppinen.fi; c=nofws; q=dns; h=mime-version:in-reply-to:references:content-type:message-id: content-transfer-encoding:from:subject:date:to:x-mailer; b=Jjt8k25KetlHzapxG93zNgC5WmN9UedMi +WrlZGLW2WDhk72WWvj63xM/ LJIZHvx2heeMbm0gxgMdZ8MuUXn8bRIB0STCLEALHBP4Oq2kbDZpcPTweLIxsL iH1h6I123ekPNTsB0LPPzDDlfPBjbHMcCekBiTtF+VcNu2HCbLhs= As you can see, it's possible to add headers like Reply-To without breaking the signature. (The choice of headers to sign in the original message is largely up to the implementation. I have a feeling that the implementations that sign only the absolutely necessary headers will survive better in the marketplace.) I think enterprises will adopt DKIM for the anti-spoofing benefits without much concern for things like their employees' participation on mailing lists external to the organization. In such a scenario, it's the mailing lists' responsibility to try and ensure that people from such protected domains can still participate. Anyway, thanks for looking into this! ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-12-17 20:51 Message: Logged In: YES user_id=738814 If it's possible to have Mailman pass the message and header through in a way that does not impact DKIM/DomainKeys, that's certainly an interesting idea. I wonder, though, if header changes required when a message is forwarded via a mailing list would always be compatible. Anyway, this as an option is certainly worth exploring. Because of things like mailing lists, I do wonder if things like DKIM and DomainKeys (and even more so SPF - I cannot believe there as been as much adoption as there has been of SPF!) will ever be viable. It seems that to get the benefit, one would need to set up strict policies, but then one risks losing mail through mailing lists, etc. ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 21:23 Message: Logged In: YES user_id=1406492 I'm currently using mailman 2.1.2, and with it, DomainKeys works OK for plain text messages if we disable any subject mangling, list footers etc. It doesn't work with attachments, but I've understood that this is because of some MIME mangling bugs that have since been fixed. So, I was looking forward to the case 1) working fully (even with attachments) with a current mailman version, but this patch will apparently prevent that. DomainKeys is, of course, more brittle than unprotected email, but I think its impact on intermediate systems is much smaller than with SPF or Sender-ID. Mail forwarders only have to forward messages as-is, not do any SPF-specific path mangling magic. I don't deny that removing the DomainKeys headers is a useful option to have, however -- but I think it should be an option. (Alternatively, we could look at this from the other direction and make the "don't touch anything" an option. i.e. have a single master switch that would turn off subject and body mangling and preserve DomainKeys headers as-is. S/MIME is the other important use case for this.) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-12-16 19:01 Message: Logged In: YES user_id=738814 Markonen, I agree that the whole DKIM/DomainKeys issue is a bit of a mess. It makes me wonder about the future of such email verification schemes. It seems that any mail list mechanism has the potential for breaking them. As to your concern, I believe we are OK in that #2 already happens. Mailman adds a "Sender:" header line, and DKIM/DomainKeys will use this as the source domain to determine if signing is expected, etc. So if the sender host re-signs the email, things should be OK. The problem here, of course, is that the receiver will only know that the email came from the mail list host - not that the original email came from the original author - less than ideal. I was enthusiastic about DKIM, but I am a little less so now due to these shortcomings. Your #1 is probably not possible, since I doubt we could expect Mailman to never modify body/headers... right? -Joe ---------------------------------------------------------------------- Comment By: Marko Karppinen (markonen) Date: 2005-12-16 17:16 Message: Logged In: YES user_id=1406492 I think this is problematic. For intra-organizational lists, removing the DomainKeys header works as advertised. However, if a person from a DomainKeys-enabled domain posts onto an external list, there is a potential for error. If the sender's domain's DomainKeys settings specify that the domain does not send unsigned mail, external MTAs can and will drop an email from that domain if the DomainKeys headers are removed. To make DomainKeys work with mailman as expected, admins have two possibilities: 1) Deliver the message as-is, without modifying the Subject header or message body (or any header indicated to be signed). The original DomainKeys signature will then work. 2) If modifying the message is necessary, the mailing list will have to rewrite the From: header in order not to claim that the message originated in the DomainKeys -protected sender domain. Removing the DomainKeys header will only be relevant in the case 2) above. For 1) -- the preferred solution for many lists -- it is actively harmful. Therefore, automatically removing the DomainKeys header is NOT the way to go. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-13 00:59 Message: Logged In: YES user_id=12800 Applied to both Mailman 2.1 branch and trunk (2.2) ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-09-11 10:09 Message: Logged In: YES user_id=738814 Attached is the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103 From noreply at sourceforge.net Sun Dec 18 19:46:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 10:46:41 -0800 Subject: [ mailman-Bugs-1384535 ] Mailman CGI Web Pages Inaccessible Message-ID: Bugs item #1384535, was opened at 2005-12-18 13:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1384535&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tibbs (tibbsa) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman CGI Web Pages Inaccessible Initial Comment: The web pages generated by the Mailman GUI and CGI modules do not conform to accessibility standards in any way, shape, or form, and are almost entirely useless from the point of view of a blind or visually impaired user. The primary problem I have, is that the various radio buttons (for defer, accept, reject, etc.) are NOT assigned to their respective labels (using