From noreply at sourceforge.net Thu Mar 2 14:48:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 05:48:07 -0800 Subject: [ mailman-Feature Requests-1441723 ] privacy hole in password reminder Message-ID: Feature Requests item #1441723, was opened at 2006-03-03 00:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1441723&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: dmvianna (dmvianna) Assigned to: Nobody/Anonymous (nobody) Summary: privacy hole in password reminder Initial Comment: Mailman sends me password reminders in plain text. I can disable this feature, but other users can manually make it send a reminder just as if I had forgot the password, with no other question being asked. If smart enough to intercept that message, the attacker could: 1) Get my password; 2) get my IP in the mail header. Possible solutions: 1) Some sites and programs use a "secret question" which right answer would give the user the chance to get a password reminder. 2) The password could be prompted in a secure html page. I find this safer, as compared to plain text mails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1441723&group_id=103 From noreply at sourceforge.net Thu Mar 2 21:32:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 12:32:18 -0800 Subject: [ mailman-Patches-1442025 ] List Specialisation for Support Groups Message-ID: Patches item #1442025, was opened at 2006-03-02 20:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1442025&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: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: List Specialisation for Support Groups Initial Comment: This patch modifies Mailman to address the following scenario: 1. A Mailman list to be used as the means by which a closed set of list subcribers (support staff) can provide responses to requests for support made by non-subscribers (customers) posting messages to the list. 2. Requirement that the incoming posts from customers (both original and follow up) and consequential responses from support staff should be entirely list-centric: a. The customer should see the response to a posting to the list as coming from the list, not the support person that responded. b. Any subsequent reply by the customer to a message from the list should go back to the list. c. Replies to customers by support staff should automatically be distributed to the the list. d. This should all happen by use of the basic features of typical MUAs by both support staff and customers; use of the MUA GUI's "Reply" button should do all that is necessary. e. Using the list in the way described should require no or minimal explanation to support staff and absolutely no explanation to customers. f. The e-mail addresses of support staff should remain hidden behind the list address. For more detail of implementation see: http://www.openinfo.co.uk/mm/patches/supportlist/index.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1442025&group_id=103 From noreply at sourceforge.net Thu Mar 2 22:17:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 13:17:02 -0800 Subject: [ mailman-Patches-820723 ] Mailman/pipermail/MHonArc integration patch Message-ID: Patches item #820723, was opened at 2003-10-09 16:19 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=820723&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: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman/pipermail/MHonArc integration patch Initial Comment: This patch tightly integrates the MHonArc mail-to-HTML convertor with Mailman and its internal pipermail archiving code. The purpose of the patch is to produce a fusion of (hopefully) the best features of pipermail and MHonArc for handling Mailman mailing list archives. For more detail see patch content or http://www.openinfo.co.uk/mailman/patches/mhonarc/index.html ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-03-02 21:17 Message: Logged In: YES user_id=75166 mhonarc-2.1.6-0.3.patch.gz corrects a long standing omission in the code of Mailman/Cgi/create.py which fails to get the initial setup of lists created through the web quite right. This leads to spurious errors being logged on message archiving until bin/arch --wipe is run for such a list affected. Lists created with bin/newlist did not have this problem. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-09-23 21:45 Message: Logged In: YES user_id=75166 mhonarc-2.1.6-0.2.patch.gz corrects an error in the modified code of $prefix/bin/arch introduced by the mhonarc-2.1.6-0.1.patch.gz - the problem was not present in patches for previous MM versions. In some circumstances, after running $prefix/bin/arch --wipe, subsequent post to a list my be generated using the wrong archiver. Examining index pages in the archives of a list will show if this problem has affected that list. Reinstallation with this revised patch and rerunning $prefix/bin/arch --wipe should resolve the problem. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-08-23 17:43 Message: Logged In: YES user_id=75166 mhonarc-2.1.6-0.1.patch.gz is a MM 2.1.6 compatible version of the patch ---------------------------------------------------------------------- Comment By: dfragos (dfragos) Date: 2005-07-21 15:24 Message: Logged In: YES user_id=1310569 what about MM 2.1.6? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-08-03 10:04 Message: Logged In: YES user_id=75166 mhonarc-2.1.5-0.1.patch.gz is a MM 2.1.5 compatible version of the patch ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2004-04-19 23:53 Message: Logged In: YES user_id=696559 I've applied this patch(mhonarc-2.1.4-0.1.patch.gz) and it works great for me. Would someone apply to offcial cvs tree? Thanks. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-01-02 15:32 Message: Logged In: YES user_id=75166 mhonarc-2.1.4-0.1.patch is a MM 2.1.4 compatible version of this patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-22 14:32 Message: Logged In: YES user_id=75166 mhonarc-2.1.3-0.6.patch better supports the use of MHonArc -saveresources option. Also fixes minor HTML syntax error in mhonarc.mrc and author.mrc that affected generated date and author index pages. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-14 05:49 Message: Logged In: YES user_id=75166 With mhonarc-2.1.3-0.4.patch, the default path to MHonArc itself defined in Defaults.py is the empty string and, until this is changed, the option to select MHonArc instead of pipermail for per-list archiving is not offered on the web admin GUI. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-10 17:51 Message: Logged In: YES user_id=75166 Under some circumstances, when a single message is passed to MHonArc for archiving via a pipe, MHonArc may finish its processing and exit, closing its STDIN before the Mailman process that invoked it has finished output of the message to the pipe. Mistakenly, the patched pipermail code treated this as an error. mhonarc-2.1.3-0.3.patch corrects this mistake. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=820723&group_id=103 From noreply at sourceforge.net Fri Mar 3 01:54:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Mar 2006 16:54:14 -0800 Subject: [ mailman-Feature Requests-1422113 ] Admin notification on address change Message-ID: Feature Requests item #1422113, was opened at 2006-02-01 19:00 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1422113&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: Accepted Priority: 5 Submitted By: Bryan Fullerton (fehwalker) >Assigned to: Mark Sapiro (msapiro) Summary: Admin notification on address change Initial Comment: Currently when a user changes their address on the options page there is no notification email sent to the list owner or moderators of affected lists. It would be more consistent to have this function generate email according to the admin_notify_mchanges list setting, though perhaps the content of the email should be different to distinguish between the two actions. Thanks, Bryan ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-02 16:54 Message: Logged In: YES user_id=1123998 I have implemented this and committed it to the CVS trunk for Mailman 2.2. It affects MailList.py and a new adminaddrchgack.txt template in case you want to get it from CVS. The change unconditionally logs the address change to the 'subscribe' log and sends the admin notice based on admin_notify_mchanges. It won't be in Mailman 2.1.8 because of i18n considerations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1422113&group_id=103 From noreply at sourceforge.net Fri Mar 3 19:27:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 10:27:31 -0800 Subject: [ mailman-Bugs-1442639 ] attachments archived even when archiving disabled Message-ID: Bugs item #1442639, was opened at 2006-03-03 13:27 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=1442639&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: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: R. Scott Bailey (rscottbailey) Assigned to: Nobody/Anonymous (nobody) Summary: attachments archived even when archiving disabled Initial Comment: I just noticed disappearing disk space under /var on my Debian system running mailman 2.1.7... :-) Investigation reveals lots of space tied up under /var/lib/mailman/archives/private//attachm ents// -- it appears that any message containing an attachment causes the attachment to be stashed here in the archive tree, even when archiving is disabled (and nothing else in the archives tree is getting updated). I do not believe it is correct behavior for attachments to be saved in these circumstances. Thanks, Scott Bailey scott.bailey at eds.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&group_id=103 From noreply at sourceforge.net Fri Mar 3 19:45:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 10:45:23 -0800 Subject: [ mailman-Bugs-1442639 ] attachments archived even when archiving disabled Message-ID: Bugs item #1442639, was opened at 2006-03-03 10:27 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&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: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: R. Scott Bailey (rscottbailey) Assigned to: Nobody/Anonymous (nobody) Summary: attachments archived even when archiving disabled Initial Comment: I just noticed disappearing disk space under /var on my Debian system running mailman 2.1.7... :-) Investigation reveals lots of space tied up under /var/lib/mailman/archives/private//attachm ents// -- it appears that any message containing an attachment causes the attachment to be stashed here in the archive tree, even when archiving is disabled (and nothing else in the archives tree is getting updated). I do not believe it is correct behavior for attachments to be saved in these circumstances. Thanks, Scott Bailey scott.bailey at eds.com ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=1123998 This is expected behavior. The scrubber saves attachments in the archives/private//attachments/ directory. This happens for all messages if scrub_nondigest is Yes, and for all plain digests in any case even if the list does not do archiving. If you allow attachments at all, the only way to avoid this is to set both scrub_nondigest and digestable to No. I.e, don't scrub individual messages and don't allow digests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&group_id=103 From noreply at sourceforge.net Sat Mar 4 00:42:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 15:42:49 -0800 Subject: [ mailman-Bugs-1442801 ] ToDigest failing with missing attribute error Message-ID: Bugs item #1442801, was opened at 2006-03-03 18:42 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=1442801&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: Open Resolution: None Priority: 5 Submitted By: David Carter (grandcross) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest failing with missing attribute error Initial Comment: One of my list queues has stopped sending messages due to a missing method: Mar 03 18:11:02 2006 (16865) Uncaught runner exception: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 91, in process send_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 217, in send_i18n_digests msgsubj = msg.get('subject', _('(no subject)')) AttributeError: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) SHUNTING: 1141426524.2579081+81281f03f202e0386d5044adcef5083568986f9a Digest mailbox has now gotten very large (> 4MB) so I cant attach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&group_id=103 From noreply at sourceforge.net Sat Mar 4 01:09:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 16:09:13 -0800 Subject: [ mailman-Bugs-1442801 ] ToDigest failing with missing attribute error Message-ID: Bugs item #1442801, was opened at 2006-03-03 15:42 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&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: Open Resolution: None Priority: 5 Submitted By: David Carter (grandcross) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest failing with missing attribute error Initial Comment: One of my list queues has stopped sending messages due to a missing method: Mar 03 18:11:02 2006 (16865) Uncaught runner exception: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 91, in process send_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 217, in send_i18n_digests msgsubj = msg.get('subject', _('(no subject)')) AttributeError: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) SHUNTING: 1141426524.2579081+81281f03f202e0386d5044adcef5083568986f9a Digest mailbox has now gotten very large (> 4MB) so I cant attach. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 16:09 Message: Logged In: YES user_id=1123998 This looks like Mailman 2.1.5 or earlier. This problem was fixed in 2.1.6. At line 210 in your Mailman/Handlers/ToDigest.py you will see while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() msgcount += 1 You need to add a continue so this becomes while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() continue msgcount += 1 In the mean time, if you don't mind having your digest out of sequence, just move the digest.mbox aside. Then you can patch ToDigest.py and straighten out the digest situation. Note that you probably don't want to both run bin/unshunt and replace the digest.mbox as that will result in duplicates, but if messages haven't reached the list, you need to run bin/unshunt to finish processing them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&group_id=103 From noreply at sourceforge.net Sat Mar 4 08:37:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Mar 2006 23:37:25 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 01:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 23:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Sat Mar 4 10:54:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 01:54:35 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 10:24 Message generated for change (Comment added) made by m-a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Matthias Andree (m-a) Date: 2006-03-04 10:54 Message: Logged In: YES user_id=2788 VERP doesn't indicate the bounce status of a message, it is a tool EXCLUSIVELY to determine the actual subscriber address in the face of forwards, DNS aliases and everything, to make sure that the list driver knows which subscriber to attribute the bounce to. Assuming any message sent to an address that looks like VERP were a bounce is a security risk! The message I'd reported was well-formed RFC-1894 and so the parser would not have had any difficulties finding out it should ignore the message. I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-04 08:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Sat Mar 4 15:41:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 06:41:15 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 04:24 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-04 09:41 Message: Logged In: YES user_id=12800 In general, an MTA is misconfigured if it sends a warning to a message labeled Precedence:bulk and all Mailman mailing list copies are so labeled. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-04 04:54 Message: Logged In: YES user_id=2788 VERP doesn't indicate the bounce status of a message, it is a tool EXCLUSIVELY to determine the actual subscriber address in the face of forwards, DNS aliases and everything, to make sure that the list driver knows which subscriber to attribute the bounce to. Assuming any message sent to an address that looks like VERP were a bounce is a security risk! The message I'd reported was well-formed RFC-1894 and so the parser would not have had any difficulties finding out it should ignore the message. I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-04 02:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Sat Mar 4 15:55:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 06:55:43 -0800 Subject: [ mailman-Feature Requests-1443069 ] If an email is filtered with a SPAM filter, do not reply Message-ID: Feature Requests item #1443069, was opened at 2006-03-04 11:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1443069&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: Oliver Schulze (oliversl) Assigned to: Nobody/Anonymous (nobody) Summary: If an email is filtered with a SPAM filter, do not reply Initial Comment: If an email is marked as SPAM using the "SPAM Filter" in mailman: - do not reply to the sender - do not send the body of the email to the owner of the list Maybe related to: Request #1219887 http://sourceforge.net/tracker/index.php?func=detail&aid=1219887&group_id=103&atid=350103 Thanks Oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1443069&group_id=103 From noreply at sourceforge.net Sat Mar 4 16:04:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 07:04:41 -0800 Subject: [ mailman-Feature Requests-669056 ] Archive URL in Email Message-ID: Feature Requests item #669056, was opened at 2003-01-16 11:12 Message generated for change (Comment added) made by oliversl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=669056&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: Grant Bowman (grantbow) Assigned to: Nobody/Anonymous (nobody) Summary: Archive URL in Email Initial Comment: When an email goes out, it should have the assigned URL in the header. This requires you to know what it is as you send it out which can be tricky. I don't know if Mailman is designed to handle such a feature. I hope it is! ---------------------------------------------------------------------- Comment By: Oliver Schulze (oliversl) Date: 2006-03-04 12:04 Message: Logged In: YES user_id=70599 DO you mean a header like X-List-* ---------------------------------------------------------------------- Comment By: Bryan Fullerton (fehwalker) Date: 2005-08-23 11:24 Message: Logged In: YES user_id=660772 Some sort of unique identifier (a hash, or some other permanent ID tag inserted as a header in the .mbox file) for each message would be very useful if the archive is later modified and rebuilt. Currently if a message is removed or added and the archive rebuilt, search engines must reindex the entire archive to get the updated URL for each message based on the new sequence numbers. For large archives this is non-trivial. +1 for a unique and permanent URL per message, +0 for having the message URL included in the message/headers. ---------------------------------------------------------------------- Comment By: Jim C. Nasby (decibel) Date: 2005-08-23 10:39 Message: Logged In: YES user_id=457856 I agree this would be extremely handy. I'd post the URL to a thread about it on mailman-users, but I'm too lazy to find it in the archive. Of course if there was a URL in the emails... FWIW, Brad Knowles posted that right now this isn't possible to do because the archives use a sequence number. If instead they used a hash of the email, then doing this would be easy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=669056&group_id=103 From noreply at sourceforge.net Sat Mar 4 16:53:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Mar 2006 07:53:12 -0800 Subject: [ mailman-Feature Requests-669056 ] Archive URL in Email Message-ID: Feature Requests item #669056, was opened at 2003-01-16 14:12 Message generated for change (Comment added) made by decibel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=669056&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: Grant Bowman (grantbow) Assigned to: Nobody/Anonymous (nobody) Summary: Archive URL in Email Initial Comment: When an email goes out, it should have the assigned URL in the header. This requires you to know what it is as you send it out which can be tricky. I don't know if Mailman is designed to handle such a feature. I hope it is! ---------------------------------------------------------------------- Comment By: Jim C. Nasby (decibel) Date: 2006-03-04 15:53 Message: Logged In: YES user_id=457856 A header would certainly suffice. If you wanted to be really slick I guess you could allow people to add it to the footer sent with every email, though I'd never use that. ---------------------------------------------------------------------- Comment By: Oliver Schulze (oliversl) Date: 2006-03-04 15:04 Message: Logged In: YES user_id=70599 DO you mean a header like X-List-* ---------------------------------------------------------------------- Comment By: Bryan Fullerton (fehwalker) Date: 2005-08-23 15:24 Message: Logged In: YES user_id=660772 Some sort of unique identifier (a hash, or some other permanent ID tag inserted as a header in the .mbox file) for each message would be very useful if the archive is later modified and rebuilt. Currently if a message is removed or added and the archive rebuilt, search engines must reindex the entire archive to get the updated URL for each message based on the new sequence numbers. For large archives this is non-trivial. +1 for a unique and permanent URL per message, +0 for having the message URL included in the message/headers. ---------------------------------------------------------------------- Comment By: Jim C. Nasby (decibel) Date: 2005-08-23 14:39 Message: Logged In: YES user_id=457856 I agree this would be extremely handy. I'd post the URL to a thread about it on mailman-users, but I'm too lazy to find it in the archive. Of course if there was a URL in the emails... FWIW, Brad Knowles posted that right now this isn't possible to do because the archives use a sequence number. If instead they used a hash of the email, then doing this would be easy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=669056&group_id=103 From noreply at sourceforge.net Mon Mar 6 22:43:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 13:43:49 -0800 Subject: [ mailman-Bugs-1444447 ] show_qfiles: 'str' object has no attribute 'as_string' Message-ID: Bugs item #1444447, was opened at 2006-03-06 22:43 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=1444447&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: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Axel Beckert (xtaran) Assigned to: Nobody/Anonymous (nobody) Summary: show_qfiles: 'str' object has no attribute 'as_string' Initial Comment: With mailman 2.1.5 and Python 2.4 on SuSE Linux 9.3, show_qfiles throws an error: python show_qfiles-2.1.7.orig ~/xchange/test.pck ====================> /home/abe/xchange/test.pck Traceback (most recent call last): File "show_qfiles-2.1.7.orig", line 74, in ? main() File "show_qfiles-2.1.7.orig", line 67, in main sys.stdout.write(msg.as_string()) AttributeError: 'str' object has no attribute 'as_string' Removing the ".as_string()" from the source of show_qfiles fixes the problem. show_qfiles is still the same in 2.1.7 and still throws this error. Tested with 2.1.7 and Python 2.4.1 under SuSE Linux 10.0. Patch: --- show_qfiles-2.1.7.orig 2006-03-06 22:38:46.000000000 +0100 +++ show_qfiles-2.1.7 2006-03-06 22:40:27.000000000 +0100 @@ -64,7 +64,7 @@ fp = open(filename) if filename.endswith(".pck"): msg = load(fp) - sys.stdout.write(msg.as_string()) + sys.stdout.write(msg) else: sys.stdout.write(fp.read()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_id=103 From noreply at sourceforge.net Tue Mar 7 00:20:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 15:20:55 -0800 Subject: [ mailman-Bugs-1444447 ] show_qfiles: 'str' object has no attribute 'as_string' Message-ID: Bugs item #1444447, was opened at 2006-03-06 13:43 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&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: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Axel Beckert (xtaran) Assigned to: Nobody/Anonymous (nobody) Summary: show_qfiles: 'str' object has no attribute 'as_string' Initial Comment: With mailman 2.1.5 and Python 2.4 on SuSE Linux 9.3, show_qfiles throws an error: python show_qfiles-2.1.7.orig ~/xchange/test.pck ====================> /home/abe/xchange/test.pck Traceback (most recent call last): File "show_qfiles-2.1.7.orig", line 74, in ? main() File "show_qfiles-2.1.7.orig", line 67, in main sys.stdout.write(msg.as_string()) AttributeError: 'str' object has no attribute 'as_string' Removing the ".as_string()" from the source of show_qfiles fixes the problem. show_qfiles is still the same in 2.1.7 and still throws this error. Tested with 2.1.7 and Python 2.4.1 under SuSE Linux 10.0. Patch: --- show_qfiles-2.1.7.orig 2006-03-06 22:38:46.000000000 +0100 +++ show_qfiles-2.1.7 2006-03-06 22:40:27.000000000 +0100 @@ -64,7 +64,7 @@ fp = open(filename) if filename.endswith(".pck"): msg = load(fp) - sys.stdout.write(msg.as_string()) + sys.stdout.write(msg) else: sys.stdout.write(fp.read()) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-06 15:20 Message: Logged In: YES user_id=1123998 Your patch will fix the show_qfiles for those entries in the 'in' queue that have unparsed message text, but it will break it for all other entries that have a Mailman.Message.Message instance. Try the attached patch and see if it isn't better. Please report back on what does and doesn't work for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_id=103 From noreply at sourceforge.net Tue Mar 7 00:46:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Mar 2006 15:46:47 -0800 Subject: [ mailman-Bugs-863989 ] Postfix delayed notification not recognized. Message-ID: Bugs item #863989, was opened at 2003-12-21 07:49 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&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: bounce detection Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix delayed notification not recognized. Initial Comment: Hi, I am running Mailman 2.1.3 (stable) with Postfix 2.0.16-20031022. It seems to be running fine with the VERP patch (it is comfortably surprising to see how much Mailman has matured since the unusable 1.1 version - I hated 1.1 but I do like 2.1! You've done wonderful work.) However I have one problem that I cannot resolve myself: Mailman apparently does not parse Postfix' delayed notification which is apparently RFC-1894 conformant (Postfix hasn't been updated to RFC-3464 yet). On superficial inspection, it looks as though Mailman's Bouncers/DSN.py should handle it and return "Stop", as but I'm getting this "uncaught bounce" message which I interpret as "haven't figured anything reasonable from this bounce". The unintelligible bounce is attached and has had mail addresses changed (sed) and the delayed mail header removed for privacy reasons. I can provide the full message to a developer on request, but I cat not put it into a public bug tracker. The MIME structure of Postfix' delay notification is: 1 multipart/report 1.1 text/plain 1.2 message/delivery-status 1.3 text/rfc822-headers The message/delivery-status part has "Action: delayed" in the 2nd header block. See for yourself. Am I misunderstanding Mailman or is Mailman misunderstanding Postfix? Thanks in advance. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-06 15:46 Message: Logged In: YES user_id=1123998 m-a's comments from 2003-12-28 are correct. The 'Stop' signal was not being passed from BouncerAPI to the BounceRunner. This has been fixed in CVS and will be correct in Mailman 2.1.8. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2003-12-28 19:40 Message: Logged In: YES user_id=2788 Urgh. Did I say I have these narrow edit forms and line breaking behind my back without preview? Please apologize the awful formatting. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2003-12-28 19:38 Message: Logged In: YES user_id=2788 Hum, looks like this issue isn't Postfix specific, but affects all systems that send a delay notification. "logs/bounce" contains: Dec 27 20:35:45 2003 (2053) bounce message w/no discernable addresses: <mumble> Dec 27 20:35:45 2003 (2053) forwarding unrecognized, message-id: <mumble> If I save exactly this mail (I checked the Message-ID) and feed it to onebounce.py, I'm getting "DSN got Stop", so that part is fine. I've dug a bit deeper, and noticed a difference between onebounce.py and BouncerAPI.ScanMessages. See lines 65ff in BouncerAPI.py: addrs = sys.modules[modname].process(msg) if addrs is Stop: # One of the detectors recognized the bounce, but there were no # addresses to extract. Return the empty list. return [] I wonder if ScanMessages() is doing the right thing, mapping Stop to []. Evidently, the BounceRunner assumes [] is a parse failure (no addresses returned) and ultimately forwards the "delay notification" to the admin contrary to original DSN.py "Stop" intent. To me, it seems as though ScanMessages needed a fix that allows it to propagate both states, "bounce recognized, no addresses" and "bounce unrecognized", back to its caller. I wonder if the "Stop" condition should be exposed to the BounceRunner or some other interface extension in ScanMessages. What do you think? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-26 22:50 Message: Logged In: YES user_id=12800 Hmm, I get Stop when I run this message through the DSN.py bounce processor, so as near as I can tell, this is working properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_id=103 From noreply at sourceforge.net Tue Mar 7 09:19:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 00:19:27 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 10:24 Message generated for change (Comment added) made by m-a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Matthias Andree (m-a) Date: 2006-03-07 09:19 Message: Logged In: YES user_id=2788 An MTA ignoring Precedence: headers is certainly NOT misconfigured. According to RFC-2076 and 3834, this header is non-standard, controversial, its interpretation varies and its use is not encouraged. I doubt Postfix implementors would care about such a non-standard header, and shifting the responsibility for not taking action in response to properly-formatted RFC-1894 DSNs towards MTA authors doesn't positively scale... BTW, is this related to Bug #863989? The message received at the VERP bounce address could be put through the bounce parser the same way as bounces to the generic bounce address to obtain one of three results: 1. an address, 2. a reply "unparsable", 3. a reply "stop". The former two would be subjected to bounce processing, where in case (1) the VERP address would override the address extracted from the message, case (3) last would just discard the message. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-04 15:41 Message: Logged In: YES user_id=12800 In general, an MTA is misconfigured if it sends a warning to a message labeled Precedence:bulk and all Mailman mailing list copies are so labeled. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-04 10:54 Message: Logged In: YES user_id=2788 VERP doesn't indicate the bounce status of a message, it is a tool EXCLUSIVELY to determine the actual subscriber address in the face of forwards, DNS aliases and everything, to make sure that the list driver knows which subscriber to attribute the bounce to. Assuming any message sent to an address that looks like VERP were a bounce is a security risk! The message I'd reported was well-formed RFC-1894 and so the parser would not have had any difficulties finding out it should ignore the message. I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-04 08:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Tue Mar 7 15:32:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 06:32:10 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 10:24 Message generated for change (Comment added) made by m-a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Matthias Andree (m-a) Date: 2006-03-07 15:32 Message: Logged In: YES user_id=2788 The Postfix maintainer's opinion is to continue ignoring the Precedence: header. He writes that Mailman should heed RFC-1894 info. See http://marc.theaimsgroup.com/?l=postfix-users&m=114173451818447&w=1 ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-07 09:19 Message: Logged In: YES user_id=2788 An MTA ignoring Precedence: headers is certainly NOT misconfigured. According to RFC-2076 and 3834, this header is non-standard, controversial, its interpretation varies and its use is not encouraged. I doubt Postfix implementors would care about such a non-standard header, and shifting the responsibility for not taking action in response to properly-formatted RFC-1894 DSNs towards MTA authors doesn't positively scale... BTW, is this related to Bug #863989? The message received at the VERP bounce address could be put through the bounce parser the same way as bounces to the generic bounce address to obtain one of three results: 1. an address, 2. a reply "unparsable", 3. a reply "stop". The former two would be subjected to bounce processing, where in case (1) the VERP address would override the address extracted from the message, case (3) last would just discard the message. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-04 15:41 Message: Logged In: YES user_id=12800 In general, an MTA is misconfigured if it sends a warning to a message labeled Precedence:bulk and all Mailman mailing list copies are so labeled. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-04 10:54 Message: Logged In: YES user_id=2788 VERP doesn't indicate the bounce status of a message, it is a tool EXCLUSIVELY to determine the actual subscriber address in the face of forwards, DNS aliases and everything, to make sure that the list driver knows which subscriber to attribute the bounce to. Assuming any message sent to an address that looks like VERP were a bounce is a security risk! The message I'd reported was well-formed RFC-1894 and so the parser would not have had any difficulties finding out it should ignore the message. I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-04 08:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Tue Mar 7 17:26:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 08:26:12 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 01:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 08:26 Message: Logged In: YES user_id=1123998 It's only distantly related to bug 863989. That that bug has been fixed in CVS, and in a sense, that fix is prerequisite to fixing this bug in the way you suggest. You suggest: "The message received at the VERP bounce address could be put through the bounce parser the same way as bounces to the generic bounce address to obtain one of three results: 1. an address, 2. a reply "unparsable", 3. a reply "stop". The former two would be subjected to bounce processing, where in case (1) the VERP address would override the address extracted from the message, case (3) last would just discard the message." This is very easy to do in code - only a line or two in BounceRunner now that 863989 is fixed - but the overhead is possibly significant considering we already have the address. Also, it is not clear to me whether you would consider your case (2) to be a bounce for the VERP address. I suggest that if you do not, the results of the above would rarely be different from just not doing VERP like addressing in the first place, thus all I would do differently from current CVS is discard the message in case (3). Here is how I would patch the current CVS to do this (note that lines will probably wrap): @@ -197,7 +197,11 @@ return # Try VERP detection first, since it's quick and easy addrs = verp_bounce(mlist, msg) - if not addrs: + if addrs: + # We have an address, but check if the message is non-fatal. + if BouncerAPI.ScanMessages(mlist, msg) is BouncerAPI.Stop: + return + else: # See if this was a probe message. token = verp_probe(mlist, msg) if token: This depends on the fix for bug 863989 which modifies BounceRunner and BouncerAPI. It would help if you could test this, although 2.1.8a1 is imminent. Also, you mention in a comment "I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago." Isn't that what we currently do if VERP_PROBES = Yes, and wouldn't that make a disable in this situation much less likely in the first place? ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-07 06:32 Message: Logged In: YES user_id=2788 The Postfix maintainer's opinion is to continue ignoring the Precedence: header. He writes that Mailman should heed RFC-1894 info. See http://marc.theaimsgroup.com/?l=postfix-users&m=114173451818447&w=1 ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-07 00:19 Message: Logged In: YES user_id=2788 An MTA ignoring Precedence: headers is certainly NOT misconfigured. According to RFC-2076 and 3834, this header is non-standard, controversial, its interpretation varies and its use is not encouraged. I doubt Postfix implementors would care about such a non-standard header, and shifting the responsibility for not taking action in response to properly-formatted RFC-1894 DSNs towards MTA authors doesn't positively scale... BTW, is this related to Bug #863989? The message received at the VERP bounce address could be put through the bounce parser the same way as bounces to the generic bounce address to obtain one of three results: 1. an address, 2. a reply "unparsable", 3. a reply "stop". The former two would be subjected to bounce processing, where in case (1) the VERP address would override the address extracted from the message, case (3) last would just discard the message. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-04 06:41 Message: Logged In: YES user_id=12800 In general, an MTA is misconfigured if it sends a warning to a message labeled Precedence:bulk and all Mailman mailing list copies are so labeled. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-04 01:54 Message: Logged In: YES user_id=2788 VERP doesn't indicate the bounce status of a message, it is a tool EXCLUSIVELY to determine the actual subscriber address in the face of forwards, DNS aliases and everything, to make sure that the list driver knows which subscriber to attribute the bounce to. Assuming any message sent to an address that looks like VERP were a bounce is a security risk! The message I'd reported was well-formed RFC-1894 and so the parser would not have had any difficulties finding out it should ignore the message. I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 23:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Tue Mar 7 18:40:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 09:40:39 -0800 Subject: [ mailman-Bugs-1442801 ] ToDigest failing with missing attribute error Message-ID: Bugs item #1442801, was opened at 2006-03-03 15:42 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&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: David Carter (grandcross) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest failing with missing attribute error Initial Comment: One of my list queues has stopped sending messages due to a missing method: Mar 03 18:11:02 2006 (16865) Uncaught runner exception: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 91, in process send_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 217, in send_i18n_digests msgsubj = msg.get('subject', _('(no subject)')) AttributeError: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) SHUNTING: 1141426524.2579081+81281f03f202e0386d5044adcef5083568986f9a Digest mailbox has now gotten very large (> 4MB) so I cant attach. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 09:40 Message: Logged In: YES user_id=1123998 Absent any response to the contrary, I'm closing this per my previous comment - fixed in 2.1.6. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 16:09 Message: Logged In: YES user_id=1123998 This looks like Mailman 2.1.5 or earlier. This problem was fixed in 2.1.6. At line 210 in your Mailman/Handlers/ToDigest.py you will see while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() msgcount += 1 You need to add a continue so this becomes while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() continue msgcount += 1 In the mean time, if you don't mind having your digest out of sequence, just move the digest.mbox aside. Then you can patch ToDigest.py and straighten out the digest situation. Note that you probably don't want to both run bin/unshunt and replace the digest.mbox as that will result in duplicates, but if messages haven't reached the list, you need to run bin/unshunt to finish processing them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&group_id=103 From noreply at sourceforge.net Tue Mar 7 18:43:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 09:43:04 -0800 Subject: [ mailman-Bugs-1442639 ] attachments archived even when archiving disabled Message-ID: Bugs item #1442639, was opened at 2006-03-03 10:27 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&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: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: R. Scott Bailey (rscottbailey) Assigned to: Nobody/Anonymous (nobody) Summary: attachments archived even when archiving disabled Initial Comment: I just noticed disappearing disk space under /var on my Debian system running mailman 2.1.7... :-) Investigation reveals lots of space tied up under /var/lib/mailman/archives/private//attachm ents// -- it appears that any message containing an attachment causes the attachment to be stashed here in the archive tree, even when archiving is disabled (and nothing else in the archives tree is getting updated). I do not believe it is correct behavior for attachments to be saved in these circumstances. Thanks, Scott Bailey scott.bailey at eds.com ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 09:43 Message: Logged In: YES user_id=1123998 Closing per my previous comment. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 10:45 Message: Logged In: YES user_id=1123998 This is expected behavior. The scrubber saves attachments in the archives/private//attachments/ directory. This happens for all messages if scrub_nondigest is Yes, and for all plain digests in any case even if the list does not do archiving. If you allow attachments at all, the only way to avoid this is to set both scrub_nondigest and digestable to No. I.e, don't scrub individual messages and don't allow digests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&group_id=103 From noreply at sourceforge.net Tue Mar 7 18:45:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 09:45:41 -0800 Subject: [ mailman-Bugs-1433666 ] News to mail gateway: Outlook Express broke uuenc.attachment Message-ID: Bugs item #1433666, was opened at 2006-02-17 08:02 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433666&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: nntp/news Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: D?niel Fraga (danielfraga) Assigned to: Nobody/Anonymous (nobody) Summary: News to mail gateway: Outlook Express broke uuenc.attachment Initial Comment: When someone posts on my nntp server a message with an uuencoded attachment using Outlook Express, the message appears broken in mailman. For example: Original message: news://news.abusar.org/drq50u$gmp$2 at servicos.netuno.com.br Mailman message (corrupted): http://core.abusar.org/pipermail/u-br.lazer.humor/2006-February/000346.html?t I think the problem is related to how mailman handles the end of lines... Thank you. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 09:45 Message: Logged In: YES user_id=1123998 Absent any reply to my previous comment, I'm closing this. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-17 17:22 Message: Logged In: YES user_id=1123998 Are you talking only of archived messages or individual received messages as well? In the case of the archived message you point to, the problem is that you have configured the archiver to obscure email addresses so that every '@' character in the uuencoded data is rewritten as ' em '. The issue is compounded by Outlook Express, because when Outlook Express sends a uuencoded attachment, it does not actually encapsulate the uuencoded attachment in a separate MIME part. If it did, Scrubber would store it separately and put a link to it in the archived message, but in the Outlook Express case, the 'attachment' is not an attachment at all, but rather just a uuencoded file in the body of the message. Thus, it is just more text subject to munging by email address obscuring. I was going to close this report with the above explanation, but I am waiting to hear if you also have a problem with individual messages or digests. I know my explanation is correct for the archives because I took the uuencoded data from your archive page and replaced all the ' em ' with '@', and I was then able to uudecode the file into a valid jpeg. So, do you have a problem with messages or digests from the list, and if so, can you provide an example message for analysis? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433666&group_id=103 From noreply at sourceforge.net Tue Mar 7 20:44:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 11:44:00 -0800 Subject: [ mailman-Bugs-1442801 ] ToDigest failing with missing attribute error Message-ID: Bugs item #1442801, was opened at 2006-03-03 18:42 Message generated for change (Comment added) made by grandcross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&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: David Carter (grandcross) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest failing with missing attribute error Initial Comment: One of my list queues has stopped sending messages due to a missing method: Mar 03 18:11:02 2006 (16865) Uncaught runner exception: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 91, in process send_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 217, in send_i18n_digests msgsubj = msg.get('subject', _('(no subject)')) AttributeError: 'str' object has no attribute 'get' Mar 03 18:11:02 2006 (16865) SHUNTING: 1141426524.2579081+81281f03f202e0386d5044adcef5083568986f9a Digest mailbox has now gotten very large (> 4MB) so I cant attach. ---------------------------------------------------------------------- >Comment By: David Carter (grandcross) Date: 2006-03-07 14:44 Message: Logged In: YES user_id=110987 This fixed the issue. Thanks! I'll upgrade to the later version ASAP. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 12:40 Message: Logged In: YES user_id=1123998 Absent any response to the contrary, I'm closing this per my previous comment - fixed in 2.1.6. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 19:09 Message: Logged In: YES user_id=1123998 This looks like Mailman 2.1.5 or earlier. This problem was fixed in 2.1.6. At line 210 in your Mailman/Handlers/ToDigest.py you will see while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() msgcount += 1 You need to add a continue so this becomes while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() continue msgcount += 1 In the mean time, if you don't mind having your digest out of sequence, just move the digest.mbox aside. Then you can patch ToDigest.py and straighten out the digest situation. Note that you probably don't want to both run bin/unshunt and replace the digest.mbox as that will result in duplicates, but if messages haven't reached the list, you need to run bin/unshunt to finish processing them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442801&group_id=103 From noreply at sourceforge.net Wed Mar 8 05:45:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 20:45:10 -0800 Subject: [ mailman-Bugs-1445366 ] Incorrect HTML generated on Info page Message-ID: Bugs item #1445366, was opened at 2006-03-08 04:45 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=1445366&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: Juergen Heberling (sassa55) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect HTML generated on Info page Initial Comment: I run 2 lists on FreeBSD 4.11 Apache 1.3.26 using Mailman 2.1.5 and Python 2.2.3_3. Both lists are set up for admin_notify_mchanges=Yes >From one list I can successfully submit a request to subscribe via the list info page. From the second list I can not - clicking the "subscribe" button does nothing. A quick look at the html source for the info page for each list shows that a < form > tag is missing for the one that does not work. There are some other rendering differences between the working and non-working version of the info page. You may try this yourself by visiting http://mail.hicom.net/mailman/listinfo and attempting to subscribe to either mailing lists. TIA for your help Juergen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445366&group_id=103 From noreply at sourceforge.net Wed Mar 8 06:23:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Mar 2006 21:23:48 -0800 Subject: [ mailman-Bugs-1445366 ] Incorrect HTML generated on Info page Message-ID: Bugs item #1445366, was opened at 2006-03-07 20:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445366&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Juergen Heberling (sassa55) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect HTML generated on Info page Initial Comment: I run 2 lists on FreeBSD 4.11 Apache 1.3.26 using Mailman 2.1.5 and Python 2.2.3_3. Both lists are set up for admin_notify_mchanges=Yes >From one list I can successfully submit a request to subscribe via the list info page. From the second list I can not - clicking the "subscribe" button does nothing. A quick look at the html source for the info page for each list shows that a < form > tag is missing for the one that does not work. There are some other rendering differences between the working and non-working version of the info page. You may try this yourself by visiting http://mail.hicom.net/mailman/listinfo and attempting to subscribe to either mailing lists. TIA for your help Juergen ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 21:23 Message: Logged In: YES user_id=1123998 This is not a bug. Someone has edited the listinfo.html template for the 'Thekootzlist' list so there is now a list specific, edited template at lists/thekootzlist/en/listinfo.html. In the process of editing, the tag was removed from the edited template, thus breaking the subscribe form. This is easy to do because the tag comes much earlier in the HTML than it is needed. Follow the admin links 'Edit the public HTML pages' and 'General list information page' for the two lists and compare the HTML and replace the tag in the broken HTML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445366&group_id=103 From noreply at sourceforge.net Wed Mar 8 14:06:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Mar 2006 05:06:39 -0800 Subject: [ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute) Message-ID: Bugs item #1445630, was opened at 2006-03-08 14:06 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=1445630&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: Open Resolution: None Priority: 5 Submitted By: chris-taylor (chris-taylor) Assigned to: Nobody/Anonymous (nobody) Summary: /templates/de/verify.txt: encoding of special chars(umlaute) Initial Comment: In the last stable release of mailman-2.1.7 the encoding of the special german characters (umlaute: ????????????) in the file /templates/de/verify.txt is wrong. When a confirm message is sent the recipient gets strange characters for the german umlaute (e.g. ???? instead of ??). I inserted the right characters in the file, now everything seems fine. See attached file... Regards Christian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&group_id=103 From noreply at sourceforge.net Wed Mar 8 16:50:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Mar 2006 07:50:54 -0800 Subject: [ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute) Message-ID: Bugs item #1445630, was opened at 2006-03-08 05:06 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&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: Open Resolution: None Priority: 5 Submitted By: chris-taylor (chris-taylor) Assigned to: Nobody/Anonymous (nobody) Summary: /templates/de/verify.txt: encoding of special chars(umlaute) Initial Comment: In the last stable release of mailman-2.1.7 the encoding of the special german characters (umlaute: ????????????) in the file /templates/de/verify.txt is wrong. When a confirm message is sent the recipient gets strange characters for the german umlaute (e.g. ???? instead of ??). I inserted the right characters in the file, now everything seems fine. See attached file... Regards Christian ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-08 07:50 Message: Logged In: YES user_id=1123998 It looks like the /templates/de/verify.txt template we're distributing is UTF-8 encoded. Is this the only one? I looked at a couple of others and they appear to be iso-8859-1 as they should be since that is Mailman's character set for german language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&group_id=103 From noreply at sourceforge.net Fri Mar 10 01:45:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 16:45:56 -0800 Subject: [ mailman-Bugs-1446859 ] Posters set to Mod, incorrectly Rejected should be Held Message-ID: Bugs item #1446859, was opened at 2006-03-10 00:45 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=1446859&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: Open Resolution: None Priority: 5 Submitted By: Bill Saunders (ws28) Assigned to: Nobody/Anonymous (nobody) Summary: Posters set to Mod, incorrectly Rejected should be Held Initial Comment: Mailman 2.1.6(slightly hacked) SunOS xxx 5.8 Sendmail I've setup a group nis_mailman_test. 1- Privacy options/Sender filters/Action to take when a moderated member posts to the list is set to Hold. 2- /By default, should new list member postings be moderated is set to No 3- I've added my members via a script that calls add_members with the options "-w n -a n". 4- So after adding the members, all members can post. 5- Change this by going into Membership Management/Additional Member tasks/Set everyones moderation... set to On. > To review, before step 5, the mod column for all members "mod" was unchecked. (At that point anyone could post without admin/moderator assistance.) After step 5 the mod column for all members is checked. 6- Checking the Privacy options/Sender filters/Action to take when a moderated member posts to the list we find that it is set to Hold 7- Also checking I thought there was a "should I tell the user that their email is being held?" and if I remember correctly this is set to Yes. > so at this point if a member sends a post they SHOULD get an email saying "I've held your email until the moderator approves it". > unfortunately at this point the member gets an email stating: "The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address." ok so lets try something different 1- delete all users 2- change the Membership Management/Additional Member tasks/Set everyones moderation from No to On 3- Add all of the users 4- attempt a post from a user > this produces the correct behavior, an email is sent to the member stating "hey Im holding this until approved" AND the moderator gets an email "do you want to approve this". So the bug is that changing the users moderation flag from off to on is NOT the same as subscribing a user with the "Action to take when a moderated member posts to the list" set on. Bill bsaunder2002 somwhereat .com read that spammers! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1446859&group_id=103 From noreply at sourceforge.net Fri Mar 10 02:20:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Mar 2006 17:20:23 -0800 Subject: [ mailman-Bugs-1446859 ] Posters set to Mod, incorrectly Rejected should be Held Message-ID: Bugs item #1446859, was opened at 2006-03-09 16:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1446859&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: Open Resolution: None Priority: 5 Submitted By: Bill Saunders (ws28) Assigned to: Nobody/Anonymous (nobody) Summary: Posters set to Mod, incorrectly Rejected should be Held Initial Comment: Mailman 2.1.6(slightly hacked) SunOS xxx 5.8 Sendmail I've setup a group nis_mailman_test. 1- Privacy options/Sender filters/Action to take when a moderated member posts to the list is set to Hold. 2- /By default, should new list member postings be moderated is set to No 3- I've added my members via a script that calls add_members with the options "-w n -a n". 4- So after adding the members, all members can post. 5- Change this by going into Membership Management/Additional Member tasks/Set everyones moderation... set to On. > To review, before step 5, the mod column for all members "mod" was unchecked. (At that point anyone could post without admin/moderator assistance.) After step 5 the mod column for all members is checked. 6- Checking the Privacy options/Sender filters/Action to take when a moderated member posts to the list we find that it is set to Hold 7- Also checking I thought there was a "should I tell the user that their email is being held?" and if I remember correctly this is set to Yes. > so at this point if a member sends a post they SHOULD get an email saying "I've held your email until the moderator approves it". > unfortunately at this point the member gets an email stating: "The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address." ok so lets try something different 1- delete all users 2- change the Membership Management/Additional Member tasks/Set everyones moderation from No to On 3- Add all of the users 4- attempt a post from a user > this produces the correct behavior, an email is sent to the member stating "hey Im holding this until approved" AND the moderator gets an email "do you want to approve this". So the bug is that changing the users moderation flag from off to on is NOT the same as subscribing a user with the "Action to take when a moderated member posts to the list" set on. Bill bsaunder2002 somwhereat .com read that spammers! ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-09 17:20 Message: Logged In: YES user_id=1123998 > unfortunately at this point the member gets an email stating: "The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address." This doesn't come from Mailman. It comes from the MTA. Unless the MTA is actually checking list membership before accepting posts, the poster sent the post to the wrong address. 1- delete all users 2- change the Membership Management/Additional Member tasks/Set everyones moderation from No to On Which does absolutely nothing at this point besause there are no members to set to 'moderated'. 3- Add all of the users 4- attempt a post from a user > this produces the correct behavior, an email is sent to the member stating "hey Im holding this until approved" AND the moderator gets an email "do you want to approve this". And how did steps 1 - 4 produce a moderated member? So the bug is that changing the users moderation flag from off to on is NOT the same as subscribing a user with the "Action to take when a moderated member posts to the list" set on. I don't see how the above statement follows from your tests, notwithstanding the fact that it is an apples/oranges type of statement. I.e., the moderation flag and the action are not an either/or situation. They are two independent settings that work in concert. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1446859&group_id=103 From noreply at sourceforge.net Fri Mar 10 20:09:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Mar 2006 11:09:33 -0800 Subject: [ mailman-Bugs-1444447 ] show_qfiles: 'str' object has no attribute 'as_string' Message-ID: Bugs item #1444447, was opened at 2006-03-06 13:43 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&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: command line scripts Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Axel Beckert (xtaran) Assigned to: Nobody/Anonymous (nobody) Summary: show_qfiles: 'str' object has no attribute 'as_string' Initial Comment: With mailman 2.1.5 and Python 2.4 on SuSE Linux 9.3, show_qfiles throws an error: python show_qfiles-2.1.7.orig ~/xchange/test.pck ====================> /home/abe/xchange/test.pck Traceback (most recent call last): File "show_qfiles-2.1.7.orig", line 74, in ? main() File "show_qfiles-2.1.7.orig", line 67, in main sys.stdout.write(msg.as_string()) AttributeError: 'str' object has no attribute 'as_string' Removing the ".as_string()" from the source of show_qfiles fixes the problem. show_qfiles is still the same in 2.1.7 and still throws this error. Tested with 2.1.7 and Python 2.4.1 under SuSE Linux 10.0. Patch: --- show_qfiles-2.1.7.orig 2006-03-06 22:38:46.000000000 +0100 +++ show_qfiles-2.1.7 2006-03-06 22:40:27.000000000 +0100 @@ -64,7 +64,7 @@ fp = open(filename) if filename.endswith(".pck"): msg = load(fp) - sys.stdout.write(msg.as_string()) + sys.stdout.write(msg) else: sys.stdout.write(fp.read()) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-10 11:09 Message: Logged In: YES user_id=1123998 Patch included in 2.1.8a1. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-06 15:20 Message: Logged In: YES user_id=1123998 Your patch will fix the show_qfiles for those entries in the 'in' queue that have unparsed message text, but it will break it for all other entries that have a Mailman.Message.Message instance. Try the attached patch and see if it isn't better. Please report back on what does and doesn't work for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1444447&group_id=103 From noreply at sourceforge.net Fri Mar 10 20:10:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Mar 2006 11:10:48 -0800 Subject: [ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce Message-ID: Bugs item #1421285, was opened at 2006-02-01 01:24 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&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: bounce detection Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.7 (VERP) mistakes delay notice for bounce Initial Comment: Greetings, I just got the bounce action notice specified below. I am running Mailman 2.1.7 with SF Patch #1405790 on Python 2.3.4, SUSE Linux 9.2 i586, Postfix 2.2.9. It appears as though Mailman 2.1.7 were not properly detecting this apparently RFC-1894 compliant notice as a "delayed" notice which is definitely a "soft bounce", if it is supposed to contribute to the bounce score at all. I looked at Mailman 2.1.4 or so which appeared to make efforts to not count "delayed"/deferral notices at all, but that didn't work at the time for Postfix deferral notices and was IIRC fixed later. My setup is VERP enabled, uses VERP for almost everything and uses monthly reminders for this list. Jan 27 20:33:47 2006 (6794) leafnode-list: admin at example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin at example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin at example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin at example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin at example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin at example.com residual bounce received I masked the list host by ... and the subscriber's domain by example.com and the last two components of the IPv4 address by X, without loss of accuracy I hope, to protect the site from spammers. Can anyone shed any light why Mailman 2.1.7 with said patch considers the delay notice a "hard" bounce? I don't have time to do debugging right now (end of the month might work), but applying a patch will probably work. ----------- This is a Mailman mailing list bounce action notice: List: leafnode-list Member: admin at example.com Action: Subscription deaktiviert. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at ... From: MAILER-DAEMON at ... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com at ... Date: Wed, 1 Feb 2006 02:47:07 +0100 (CET) This is the Postfix program at host ... #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 4.2 hours. It will be retried until it is 7.0 days old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : connect to mail.example.com[60.234.X.X]: Connection timed out Reporting-MTA: dns; ... X-Postfix-Queue-ID: C9BC24415A X-Postfix-Sender: rfc822; leafnode-list-bounces+admin=example.com at ... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin at example.com Action: delayed Status: 4.0.0 Diagnostic-Code: X-Postfix; connect to mail.example.com[60.234.X.X]: Connection timed out Will-Retry-Until: Tue, 7 Feb 2006 21:55:44 +0100 (CET) [5. Undelivered Message Headers --- text/rfc822-headers] (elided) ------------------------- I pasted from Emacs/Gnus, and this is the mime structure as seen by Gnus, it looks intact. . 20060201T030141 [ 150: mailman at dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman at dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman at dt.e-tec] <2 rfc822> . 20060201T024707 [ 111: Mail Delivery Sy] <2.* report> Delayed Mail (still being retried) . 20060201T024707 [ 19: Mail Delivery Sy] <2.1 text> . 20060201T024707 [ 13: Mail Delivery Sy] <2.2 delivery-status> . 20060201T024707 [ 63: Mail Delivery Sy] <2.3 rfc822-headers> ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-10 11:10 Message: Logged In: YES user_id=1123998 Patch is included in 2.1.8a1. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-07 08:26 Message: Logged In: YES user_id=1123998 It's only distantly related to bug 863989. That that bug has been fixed in CVS, and in a sense, that fix is prerequisite to fixing this bug in the way you suggest. You suggest: "The message received at the VERP bounce address could be put through the bounce parser the same way as bounces to the generic bounce address to obtain one of three results: 1. an address, 2. a reply "unparsable", 3. a reply "stop". The former two would be subjected to bounce processing, where in case (1) the VERP address would override the address extracted from the message, case (3) last would just discard the message." This is very easy to do in code - only a line or two in BounceRunner now that 863989 is fixed - but the overhead is possibly significant considering we already have the address. Also, it is not clear to me whether you would consider your case (2) to be a bounce for the VERP address. I suggest that if you do not, the results of the above would rarely be different from just not doing VERP like addressing in the first place, thus all I would do differently from current CVS is discard the message in case (3). Here is how I would patch the current CVS to do this (note that lines will probably wrap): @@ -197,7 +197,11 @@ return # Try VERP detection first, since it's quick and easy addrs = verp_bounce(mlist, msg) - if not addrs: + if addrs: + # We have an address, but check if the message is non-fatal. + if BouncerAPI.ScanMessages(mlist, msg) is BouncerAPI.Stop: + return + else: # See if this was a probe message. token = verp_probe(mlist, msg) if token: This depends on the fix for bug 863989 which modifies BounceRunner and BouncerAPI. It would help if you could test this, although 2.1.8a1 is imminent. Also, you mention in a comment "I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago." Isn't that what we currently do if VERP_PROBES = Yes, and wouldn't that make a disable in this situation much less likely in the first place? ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-07 06:32 Message: Logged In: YES user_id=2788 The Postfix maintainer's opinion is to continue ignoring the Precedence: header. He writes that Mailman should heed RFC-1894 info. See http://marc.theaimsgroup.com/?l=postfix-users&m=114173451818447&w=1 ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-07 00:19 Message: Logged In: YES user_id=2788 An MTA ignoring Precedence: headers is certainly NOT misconfigured. According to RFC-2076 and 3834, this header is non-standard, controversial, its interpretation varies and its use is not encouraged. I doubt Postfix implementors would care about such a non-standard header, and shifting the responsibility for not taking action in response to properly-formatted RFC-1894 DSNs towards MTA authors doesn't positively scale... BTW, is this related to Bug #863989? The message received at the VERP bounce address could be put through the bounce parser the same way as bounces to the generic bounce address to obtain one of three results: 1. an address, 2. a reply "unparsable", 3. a reply "stop". The former two would be subjected to bounce processing, where in case (1) the VERP address would override the address extracted from the message, case (3) last would just discard the message. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-04 06:41 Message: Logged In: YES user_id=12800 In general, an MTA is misconfigured if it sends a warning to a message labeled Precedence:bulk and all Mailman mailing list copies are so labeled. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2006-03-04 01:54 Message: Logged In: YES user_id=2788 VERP doesn't indicate the bounce status of a message, it is a tool EXCLUSIVELY to determine the actual subscriber address in the face of forwards, DNS aliases and everything, to make sure that the list driver knows which subscriber to attribute the bounce to. Assuming any message sent to an address that looks like VERP were a bounce is a security risk! The message I'd reported was well-formed RFC-1894 and so the parser would not have had any difficulties finding out it should ignore the message. I am aware that this isn't bullet-proof, that's why I suggested sending a probe message with secret hash before disabling/unsubscribing a user a long time ago. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-03 23:37 Message: Logged In: YES user_id=1123998 Unfortunately, this is the way VERP bounce processing is handled. When a message is sent/returned to listname-bounces+user=example.com at ... it is scored as a bounce for user at example.com (the VERPed address), and the content of the message is never examined. The theory is that the VERP address identifies the bouncing address regardles of the recognizability of the notice itself, so there is no attempt to recognize the type of notice. It would be possible to run the returned message through the recognizers and accept a recognizers determination that the notice was non-fatal while still keeping the VERP address as the address to use for the bounce report in the event that the notice was not determined to be non-fatal, but that wouldn't solve the problem for an unrecognized non-fatal notice, and the whole idea behind VERP bounce processing is that it allows skiping the recognition process. It does seem wrong that a bounce is scored for a notice that could be recognized as non-fatal, but there will always be a grey area with notices that wouldn't be recognized as fatal or non-fatal. If one decides to give the benefit of the doubt in this grey area and not score a bounce, then we revert to the non-VERP case in which only recognized bounces are scored. It seems that the real problem is that VERP bounce processing isn't that good of an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1421285&group_id=103 From noreply at sourceforge.net Fri Mar 10 20:13:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Mar 2006 11:13:11 -0800 Subject: [ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute) Message-ID: Bugs item #1445630, was opened at 2006-03-08 05:06 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&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: chris-taylor (chris-taylor) Assigned to: Nobody/Anonymous (nobody) Summary: /templates/de/verify.txt: encoding of special chars(umlaute) Initial Comment: In the last stable release of mailman-2.1.7 the encoding of the special german characters (umlaute: ????????????) in the file /templates/de/verify.txt is wrong. When a confirm message is sent the recipient gets strange characters for the german umlaute (e.g. ???? instead of ??). I inserted the right characters in the file, now everything seems fine. See attached file... Regards Christian ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-10 11:13 Message: Logged In: YES user_id=1123998 The template has been properly iso-8859-1 encoded for 2.1.8a1. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-08 07:50 Message: Logged In: YES user_id=1123998 It looks like the /templates/de/verify.txt template we're distributing is UTF-8 encoded. Is this the only one? I looked at a couple of others and they appear to be iso-8859-1 as they should be since that is Mailman's character set for german language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&group_id=103 From noreply at sourceforge.net Sat Mar 11 19:36:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Mar 2006 10:36:17 -0800 Subject: [ mailman-Feature Requests-403066 ] Auto Approval of subscriptions for certain domains Message-ID: Feature Requests item #403066, was opened at 2001-01-01 06:27 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&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: Pending >Resolution: Accepted Priority: 3 Submitted By: Mark Tearle (mtearle) >Assigned to: Mark Sapiro (msapiro) Summary: Auto Approval of subscriptions for certain domains Initial Comment: A patch to enable automatic approval for certain domains, eg people in the example.com are automatically approved all others have to wait for the moderator ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-11 10:36 Message: Logged In: YES user_id=1123998 The attached patch is against a 2.1.8a1 installed base (installed because it patches Defaults.py and not Defaults.py.in). It is a modification and extension of the original patch. It implements a new list attribute 'subscribe_auto_approval' which is a list of email addresses and regular expressions matching email addresses whose subscriptions are exempt from admin approval. It implements the original intent if one just uses regexps that match domains. This will go in Mailman 2.2, but it would be nice to get some feedback from people who are interested in this feature and are willing to try the patch. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-11 05:31 Message: Logged In: YES user_id=34209 Is this still necessary with Mailman 2.1, which has more 'automatic' options (as well as 'memberadaptors') ? In any case, the patch is likely heavily out of date by now, I'm moving this to Feature Requests for now. Feel free to respond if you (still) have a need. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&group_id=103 From noreply at sourceforge.net Sat Mar 11 19:58:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Mar 2006 10:58:17 -0800 Subject: [ mailman-Patches-1447948 ] Focus password field on load Message-ID: Patches item #1447948, was opened at 2006-03-11 13:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1447948&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 UI Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jamie (fractalvisionz) Assigned to: Nobody/Anonymous (nobody) Summary: Focus password field on load Initial Comment: This patch focuses the password field when the login page is loaded, a very simple and time saving feature. File should be placed in the templates/en directory. DIFF: 5,6c5,12 < <
--- > > > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1447948&group_id=103 From noreply at sourceforge.net Sat Mar 11 19:59:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Mar 2006 10:59:41 -0800 Subject: [ mailman-Patches-1447948 ] Focus password field on admin login page load Message-ID: Patches item #1447948, was opened at 2006-03-11 13:58 Message generated for change (Settings changed) made by fractalvisionz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1447948&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 UI Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jamie (fractalvisionz) Assigned to: Nobody/Anonymous (nobody) >Summary: Focus password field on admin login page load Initial Comment: This patch focuses the password field when the login page is loaded, a very simple and time saving feature. File should be placed in the templates/en directory. DIFF: 5,6c5,12 < < --- > > > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1447948&group_id=103 From noreply at sourceforge.net Sun Mar 12 19:11:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 10:11:11 -0800 Subject: [ mailman-Bugs-1275856 ] Utils.get_domain() wrong if VIRTUAL_HOST_OVERVIEW off Message-ID: Bugs item #1275856, was opened at 2005-08-29 10:26 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1275856&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Utils.get_domain() wrong if VIRTUAL_HOST_OVERVIEW off Initial Comment: Part of the code in get_domain() in Utils.py is: if mm_cfg.VIRTUAL_HOST_OVERVIEW and host: return host.lower() else: # See the note in Defaults.py concerning DEFAULT_HOST_NAME # vs. DEFAULT_EMAIL_HOST. hostname = mm_cfg.DEFAULT_HOST_NAME or mm_cfg.DEFAULT_EMAIL_HOST return hostname.lower() It is clear that get_domain() should return the web host, not the e-mail host. This code should be: if mm_cfg.VIRTUAL_HOST_OVERVIEW and host: return host.lower() else: # See the note in Defaults.py concerning DEFAULT_URL # vs. DEFAULT_URL_HOST. hostname = mm_cfg.DEFAULT_URL or mm_cfg.DEFAULT_URL_HOST return hostname.lower() ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-12 10:11 Message: Logged In: YES user_id=1123998 Fixed in CVS for releases above 2.1.8a1. hostname = mm_cfg.DEFAULT_URL or mm_cfg.DEFAULT_URL_HOST is not the correct fix as DEFAULT_URL is a URL, not a domain, so I changed it to hostname = mm_cfg.DEFAULT_HOST_NAME or mm_cfg.DEFAULT_URL_HOST ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1275856&group_id=103 From noreply at sourceforge.net Sun Mar 12 21:35:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 12:35:06 -0800 Subject: [ mailman-Bugs-1080943 ] Private archive specific message URL lost in authorization Message-ID: Bugs item #1080943, was opened at 2004-12-07 14:49 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1080943&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Private archive specific message URL lost in authorization Initial Comment: If a user without an authorization cookie goes to a URL such as http://www.example.com/mailman/private/list-name/yyyy-Month/nnnnnn.html the user will get the private archives authorization page and after filling in e-mail address and password and clicking Let me in... will be taken to the main index for the list at http://www.example.com/mailman/private/list-name/ instead of to the original URL. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-12 12:35 Message: Logged In: YES user_id=1123998 Fixed in 2.1.7. ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2005-03-10 03:21 Message: Logged In: YES user_id=35028 There is a fix for this issue in a debian bug report: http://bugs.debian.org/298842 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1080943&group_id=103 From noreply at sourceforge.net Mon Mar 13 00:30:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 15:30:54 -0800 Subject: [ mailman-Bugs-1448537 ] Limit number of subscribe requests in a period Message-ID: Bugs item #1448537, was opened at 2006-03-12 15:30 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=1448537&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: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: EricB (eric_black) Assigned to: Nobody/Anonymous (nobody) Summary: Limit number of subscribe requests in a period Initial Comment: Add limits (number of requests in a day, and minimum number of days before resetting the counter) to the number of subscribe requests for an email address. Defaults would be 1 request in 1 day. This is needed to prevent malicious mailbombing of an innocent victim by someone repeatedly submitting their address. Currently the victim gets the verify.txt template email for each submission. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&group_id=103 From noreply at sourceforge.net Mon Mar 13 00:47:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 15:47:20 -0800 Subject: [ mailman-Bugs-1448537 ] Limit number of subscribe requests in a period Message-ID: Bugs item #1448537, was opened at 2006-03-12 15:30 Message generated for change (Comment added) made by eric_black You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&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: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: EricB (eric_black) Assigned to: Nobody/Anonymous (nobody) Summary: Limit number of subscribe requests in a period Initial Comment: Add limits (number of requests in a day, and minimum number of days before resetting the counter) to the number of subscribe requests for an email address. Defaults would be 1 request in 1 day. This is needed to prevent malicious mailbombing of an innocent victim by someone repeatedly submitting their address. Currently the victim gets the verify.txt template email for each submission. ---------------------------------------------------------------------- >Comment By: EricB (eric_black) Date: 2006-03-12 15:47 Message: Logged In: YES user_id=1474448 BTW, I've been running 2.1.5 with this problem, and 2.1.7 still exhibits the vulnerability. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&group_id=103 From noreply at sourceforge.net Mon Mar 13 04:12:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 19:12:46 -0800 Subject: [ mailman-Feature Requests-403066 ] Auto Approval of subscriptions for certain domains Message-ID: Feature Requests item #403066, was opened at 2001-01-01 09:27 Message generated for change (Comment added) made by jimpop You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&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: Pending Resolution: Accepted Priority: 3 Submitted By: Mark Tearle (mtearle) Assigned to: Mark Sapiro (msapiro) Summary: Auto Approval of subscriptions for certain domains Initial Comment: A patch to enable automatic approval for certain domains, eg people in the example.com are automatically approved all others have to wait for the moderator ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2006-03-12 22:12 Message: Logged In: YES user_id=3142 I've successfully applied this against a v2.1.8 system and it works well. Thanks!! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-11 13:36 Message: Logged In: YES user_id=1123998 The attached patch is against a 2.1.8a1 installed base (installed because it patches Defaults.py and not Defaults.py.in). It is a modification and extension of the original patch. It implements a new list attribute 'subscribe_auto_approval' which is a list of email addresses and regular expressions matching email addresses whose subscriptions are exempt from admin approval. It implements the original intent if one just uses regexps that match domains. This will go in Mailman 2.2, but it would be nice to get some feedback from people who are interested in this feature and are willing to try the patch. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-11 08:31 Message: Logged In: YES user_id=34209 Is this still necessary with Mailman 2.1, which has more 'automatic' options (as well as 'memberadaptors') ? In any case, the patch is likely heavily out of date by now, I'm moving this to Feature Requests for now. Feel free to respond if you (still) have a need. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&group_id=103 From noreply at sourceforge.net Mon Mar 13 04:19:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 19:19:57 -0800 Subject: [ mailman-Bugs-1448537 ] Limit number of subscribe requests in a period Message-ID: Bugs item #1448537, was opened at 2006-03-12 23:30 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&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: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: EricB (eric_black) Assigned to: Nobody/Anonymous (nobody) Summary: Limit number of subscribe requests in a period Initial Comment: Add limits (number of requests in a day, and minimum number of days before resetting the counter) to the number of subscribe requests for an email address. Defaults would be 1 request in 1 day. This is needed to prevent malicious mailbombing of an innocent victim by someone repeatedly submitting their address. Currently the victim gets the verify.txt template email for each submission. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2006-03-13 03:19 Message: Logged In: YES user_id=67709 You can suppress sending confirmation by putting the victim's email address in ban_list from the admin page (privacy section), if she/he is not willing to be added in your list. This may not work if the malicious user forges the 'From:' header. In this case, the victim may well introduce some mail filter to get junk mails discarded before they reach her/his eyes. ---------------------------------------------------------------------- Comment By: EricB (eric_black) Date: 2006-03-12 23:47 Message: Logged In: YES user_id=1474448 BTW, I've been running 2.1.5 with this problem, and 2.1.7 still exhibits the vulnerability. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&group_id=103 From noreply at sourceforge.net Mon Mar 13 04:30:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Mar 2006 19:30:12 -0800 Subject: [ mailman-Bugs-1448537 ] Limit number of subscribe requests in a period Message-ID: Bugs item #1448537, was opened at 2006-03-12 15:30 Message generated for change (Comment added) made by eric_black You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&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: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: EricB (eric_black) Assigned to: Nobody/Anonymous (nobody) Summary: Limit number of subscribe requests in a period Initial Comment: Add limits (number of requests in a day, and minimum number of days before resetting the counter) to the number of subscribe requests for an email address. Defaults would be 1 request in 1 day. This is needed to prevent malicious mailbombing of an innocent victim by someone repeatedly submitting their address. Currently the victim gets the verify.txt template email for each submission. ---------------------------------------------------------------------- >Comment By: EricB (eric_black) Date: 2006-03-12 19:30 Message: Logged In: YES user_id=1474448 Thanks for the suggestion. That helps if a user complains, but does not help in this scenario: A malicious evil-doer discovers a spamtrap email address used by any of the many RBLs, and repeatedly submits that address in a subscribe request, either by forging email (trivial to do) or by repeatedly submitting the HTML form (also trivial to do). The spamtrap receives multiple confirmation requests. The first confirmation request should be ignored, because typos happen. Subsequent confirmation requests may well be considered to be spam. Especially if there are 5 a day, let alone 100 in the space of an hour. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2006-03-12 19:19 Message: Logged In: YES user_id=67709 You can suppress sending confirmation by putting the victim's email address in ban_list from the admin page (privacy section), if she/he is not willing to be added in your list. This may not work if the malicious user forges the 'From:' header. In this case, the victim may well introduce some mail filter to get junk mails discarded before they reach her/his eyes. ---------------------------------------------------------------------- Comment By: EricB (eric_black) Date: 2006-03-12 15:47 Message: Logged In: YES user_id=1474448 BTW, I've been running 2.1.5 with this problem, and 2.1.7 still exhibits the vulnerability. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1448537&group_id=103 From noreply at sourceforge.net Mon Mar 13 16:53:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 07:53:50 -0800 Subject: [ mailman-Feature Requests-1448931 ] Event driven external scripts Message-ID: Feature Requests item #1448931, was opened at 2006-03-13 07:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1448931&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: Dragon (dragon93) Assigned to: Nobody/Anonymous (nobody) Summary: Event driven external scripts Initial Comment: It would be very useful to have a mechanism built in to Mailman that would run an external script when various events occur. For instance, when a user subscribes or unsubscribes, changes e-mail address or any other event that might require further processing. Ideally, this would be a simple configuration directive pointing to the script to run on each event. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1448931&group_id=103 From noreply at sourceforge.net Mon Mar 13 19:18:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 10:18:58 -0800 Subject: [ mailman-Patches-1449048 ] non-member post failuer Message-ID: Patches item #1449048, was opened at 2006-03-13 13:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1449048&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: bounce processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Linda Betts (llbetts) Assigned to: Nobody/Anonymous (nobody) Summary: non-member post failuer Initial Comment: Running Mailman 2.1.5 on Red Hat Linux 3. Have list configured to discard posts from non-members. Non-member sent in auto reply containing my address has changed information that actually came from the new address which was not registered. List server sent this auto-reply from non-member to the list. Can't find similar problem reported or bug fix. Output list configuration, pertinent info below: # legal values are: # 0 = "Accept" # 1 = "Hold" # 2 = "Reject" # 3 = "Discard" generic_nonmember_action = 3 Please advise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1449048&group_id=103 From noreply at sourceforge.net Mon Mar 13 21:30:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 12:30:30 -0800 Subject: [ mailman-Bugs-1170651 ] Mail Delivery not working Message-ID: Bugs item #1170651, was opened at 2005-03-25 17:49 Message generated for change (Comment added) made by asmig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&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: Open Resolution: None Priority: 5 Submitted By: Chris (ttoolman2000) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Delivery not working Initial Comment: Hello everyone, I am trying to setup an included mailing list which was setup through the Plesk Control Panel as a part of 1and1.com's root server package. Mailman version 2.1.1 I am able to add users both at the Plesk side and the Mailman side, however it never sends e-mail confirmations, and when I try to e-mail the test mailing list I made I never get any replies nor does it get posted or sent to the list. When I tried to view all lists on my host: http://lists.mjtstages.com/mailman/listinfo I received a bug report http://lists.mjtstages.com/mailman/listinfo If anyone has any insight in fixing this problem that would be great, I might also mention suggest viewing the list to see the Bug report for viewing. Thanks, Chris ---------------------------------------------------------------------- Comment By: Kenny (asmig) Date: 2006-03-13 20:30 Message: Logged In: YES user_id=217596 This appears to have been resolved. Please update the status of this ticket, and if you have a moment, add comments detailing what you did to resolve the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&group_id=103 From noreply at sourceforge.net Mon Mar 13 22:00:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 13:00:13 -0800 Subject: [ mailman-Patches-1449048 ] non-member post failuer Message-ID: Patches item #1449048, was opened at 2006-03-13 10:18 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1449048&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: bounce processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Linda Betts (llbetts) Assigned to: Nobody/Anonymous (nobody) Summary: non-member post failuer Initial Comment: Running Mailman 2.1.5 on Red Hat Linux 3. Have list configured to discard posts from non-members. Non-member sent in auto reply containing my address has changed information that actually came from the new address which was not registered. List server sent this auto-reply from non-member to the list. Can't find similar problem reported or bug fix. Output list configuration, pertinent info below: # legal values are: # 0 = "Accept" # 1 = "Hold" # 2 = "Reject" # 3 = "Discard" generic_nonmember_action = 3 Please advise. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:00 Message: Logged In: YES user_id=1123998 In a default installation, post will be determined to be from a list member if the envelope sender or any of the From:, Reply-To: or Sender: headers contain a member address. You could send an off list message to the old address and inspect the returned message to see if Return-Path: (the envelope sender), From:, Reply-To: or Sender: contain the old address. If so, accepting this would be expected behavior. Note that in a situation like this, it may be preferable to discuss the issue on mailman-users at python.org before submitting a bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1449048&group_id=103 From noreply at sourceforge.net Mon Mar 13 22:13:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 13:13:10 -0800 Subject: [ mailman-Bugs-1170651 ] Mail Delivery not working Message-ID: Bugs item #1170651, was opened at 2005-03-25 09:49 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&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: Open Resolution: None Priority: 5 Submitted By: Chris (ttoolman2000) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Delivery not working Initial Comment: Hello everyone, I am trying to setup an included mailing list which was setup through the Plesk Control Panel as a part of 1and1.com's root server package. Mailman version 2.1.1 I am able to add users both at the Plesk side and the Mailman side, however it never sends e-mail confirmations, and when I try to e-mail the test mailing list I made I never get any replies nor does it get posted or sent to the list. When I tried to view all lists on my host: http://lists.mjtstages.com/mailman/listinfo I received a bug report http://lists.mjtstages.com/mailman/listinfo If anyone has any insight in fixing this problem that would be great, I might also mention suggest viewing the list to see the Bug report for viewing. Thanks, Chris ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:13 Message: Logged In: YES user_id=1123998 As in prior comment, http://lists.mjtstages.com/mailman/listinfo works for me. I get the expected listinfo page with five lists. Each of those takes me to the expected listinfo page. Regarding non-delivery, see ---------------------------------------------------------------------- Comment By: Kenny (asmig) Date: 2006-03-13 12:30 Message: Logged In: YES user_id=217596 This appears to have been resolved. Please update the status of this ticket, and if you have a moment, add comments detailing what you did to resolve the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&group_id=103 From noreply at sourceforge.net Mon Mar 13 22:17:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 13:17:36 -0800 Subject: [ mailman-Bugs-1170651 ] Mail Delivery not working Message-ID: Bugs item #1170651, was opened at 2005-03-25 09:49 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&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: Out of Date Priority: 5 Submitted By: Chris (ttoolman2000) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Delivery not working Initial Comment: Hello everyone, I am trying to setup an included mailing list which was setup through the Plesk Control Panel as a part of 1and1.com's root server package. Mailman version 2.1.1 I am able to add users both at the Plesk side and the Mailman side, however it never sends e-mail confirmations, and when I try to e-mail the test mailing list I made I never get any replies nor does it get posted or sent to the list. When I tried to view all lists on my host: http://lists.mjtstages.com/mailman/listinfo I received a bug report http://lists.mjtstages.com/mailman/listinfo If anyone has any insight in fixing this problem that would be great, I might also mention suggest viewing the list to see the Bug report for viewing. Thanks, Chris ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:17 Message: Logged In: YES user_id=1123998 Ooops. the url got lost it was Regarding non-delivery, see . Also, given the age of this report which I also didn't notice before, I'm closing it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:13 Message: Logged In: YES user_id=1123998 As in prior comment, http://lists.mjtstages.com/mailman/listinfo works for me. I get the expected listinfo page with five lists. Each of those takes me to the expected listinfo page. Regarding non-delivery, see ---------------------------------------------------------------------- Comment By: Kenny (asmig) Date: 2006-03-13 12:30 Message: Logged In: YES user_id=217596 This appears to have been resolved. Please update the status of this ticket, and if you have a moment, add comments detailing what you did to resolve the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&group_id=103 From noreply at sourceforge.net Mon Mar 13 22:20:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 13:20:21 -0800 Subject: [ mailman-Bugs-1170651 ] Mail Delivery not working Message-ID: Bugs item #1170651, was opened at 2005-03-25 09:49 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&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: Out of Date Priority: 5 Submitted By: Chris (ttoolman2000) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Delivery not working Initial Comment: Hello everyone, I am trying to setup an included mailing list which was setup through the Plesk Control Panel as a part of 1and1.com's root server package. Mailman version 2.1.1 I am able to add users both at the Plesk side and the Mailman side, however it never sends e-mail confirmations, and when I try to e-mail the test mailing list I made I never get any replies nor does it get posted or sent to the list. When I tried to view all lists on my host: http://lists.mjtstages.com/mailman/listinfo I received a bug report http://lists.mjtstages.com/mailman/listinfo If anyone has any insight in fixing this problem that would be great, I might also mention suggest viewing the list to see the Bug report for viewing. Thanks, Chris ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:20 Message: Logged In: YES user_id=1123998 Well, now I know why I'm losing URLs. They're being mistaken for tags because I put < and > around them. The url is http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.014.htp ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:17 Message: Logged In: YES user_id=1123998 Ooops. the url got lost it was Regarding non-delivery, see . Also, given the age of this report which I also didn't notice before, I'm closing it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:13 Message: Logged In: YES user_id=1123998 As in prior comment, http://lists.mjtstages.com/mailman/listinfo works for me. I get the expected listinfo page with five lists. Each of those takes me to the expected listinfo page. Regarding non-delivery, see ---------------------------------------------------------------------- Comment By: Kenny (asmig) Date: 2006-03-13 12:30 Message: Logged In: YES user_id=217596 This appears to have been resolved. Please update the status of this ticket, and if you have a moment, add comments detailing what you did to resolve the problem. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1170651&group_id=103 From noreply at sourceforge.net Tue Mar 14 00:26:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 15:26:49 -0800 Subject: [ mailman-Patches-1449048 ] non-member post failuer Message-ID: Patches item #1449048, was opened at 2006-03-13 13:18 Message generated for change (Comment added) made by llbetts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1449048&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: bounce processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Linda Betts (llbetts) Assigned to: Nobody/Anonymous (nobody) Summary: non-member post failuer Initial Comment: Running Mailman 2.1.5 on Red Hat Linux 3. Have list configured to discard posts from non-members. Non-member sent in auto reply containing my address has changed information that actually came from the new address which was not registered. List server sent this auto-reply from non-member to the list. Can't find similar problem reported or bug fix. Output list configuration, pertinent info below: # legal values are: # 0 = "Accept" # 1 = "Hold" # 2 = "Reject" # 3 = "Discard" generic_nonmember_action = 3 Please advise. ---------------------------------------------------------------------- >Comment By: Linda Betts (llbetts) Date: 2006-03-13 18:26 Message: Logged In: YES user_id=1063268 Although I agree with the comments that if any of the headers contains the real members email address it will be processed as a member, the real member is moderated and all posts from moderated members are configured to be discarded. Therefore, in this configuration it should not matter who sent the reply. Only the list owner is allowed to send messages to the list and the reply should have been discarded. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 16:00 Message: Logged In: YES user_id=1123998 In a default installation, post will be determined to be from a list member if the envelope sender or any of the From:, Reply-To: or Sender: headers contain a member address. You could send an off list message to the old address and inspect the returned message to see if Return-Path: (the envelope sender), From:, Reply-To: or Sender: contain the old address. If so, accepting this would be expected behavior. Note that in a situation like this, it may be preferable to discuss the issue on mailman-users at python.org before submitting a bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1449048&group_id=103 From noreply at sourceforge.net Tue Mar 14 01:31:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 16:31:58 -0800 Subject: [ mailman-Bugs-1449048 ] non-member post failuer Message-ID: Bugs item #1449048, was opened at 2006-03-13 10:18 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1449048&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: Linda Betts (llbetts) Assigned to: Nobody/Anonymous (nobody) Summary: non-member post failuer Initial Comment: Running Mailman 2.1.5 on Red Hat Linux 3. Have list configured to discard posts from non-members. Non-member sent in auto reply containing my address has changed information that actually came from the new address which was not registered. List server sent this auto-reply from non-member to the list. Can't find similar problem reported or bug fix. Output list configuration, pertinent info below: # legal values are: # 0 = "Accept" # 1 = "Hold" # 2 = "Reject" # 3 = "Discard" generic_nonmember_action = 3 Please advise. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 16:31 Message: Logged In: YES user_id=1123998 Is there anything in accept_these_nonmembers? What is generic_nonmember_action? If one or the other of these settings don't explain the issue, then I'm afraid that without specific information as to the headers of the post as received by Mailman and specific list configuration information, we aren't going to be able to understand what happened or if there is a bug involved. In any case, I am moving this from 'patches' to 'bugs' for the interim as it clearly isn't a patch. ---------------------------------------------------------------------- Comment By: Linda Betts (llbetts) Date: 2006-03-13 15:26 Message: Logged In: YES user_id=1063268 Although I agree with the comments that if any of the headers contains the real members email address it will be processed as a member, the real member is moderated and all posts from moderated members are configured to be discarded. Therefore, in this configuration it should not matter who sent the reply. Only the list owner is allowed to send messages to the list and the reply should have been discarded. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:00 Message: Logged In: YES user_id=1123998 In a default installation, post will be determined to be from a list member if the envelope sender or any of the From:, Reply-To: or Sender: headers contain a member address. You could send an off list message to the old address and inspect the returned message to see if Return-Path: (the envelope sender), From:, Reply-To: or Sender: contain the old address. If so, accepting this would be expected behavior. Note that in a situation like this, it may be preferable to discuss the issue on mailman-users at python.org before submitting a bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1449048&group_id=103 From noreply at sourceforge.net Tue Mar 14 02:10:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 17:10:04 -0800 Subject: [ mailman-Bugs-1449048 ] non-member post failuer Message-ID: Bugs item #1449048, was opened at 2006-03-13 13:18 Message generated for change (Comment added) made by llbetts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1449048&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: Linda Betts (llbetts) Assigned to: Nobody/Anonymous (nobody) Summary: non-member post failuer Initial Comment: Running Mailman 2.1.5 on Red Hat Linux 3. Have list configured to discard posts from non-members. Non-member sent in auto reply containing my address has changed information that actually came from the new address which was not registered. List server sent this auto-reply from non-member to the list. Can't find similar problem reported or bug fix. Output list configuration, pertinent info below: # legal values are: # 0 = "Accept" # 1 = "Hold" # 2 = "Reject" # 3 = "Discard" generic_nonmember_action = 3 Please advise. ---------------------------------------------------------------------- >Comment By: Linda Betts (llbetts) Date: 2006-03-13 20:10 Message: Logged In: YES user_id=1063268 According to the output from config_list these 2 items are set to: accept_these_nonmembers = [] generic_nonmember_action = 3 I have attached the complete output from the config_list output. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 19:31 Message: Logged In: YES user_id=1123998 Is there anything in accept_these_nonmembers? What is generic_nonmember_action? If one or the other of these settings don't explain the issue, then I'm afraid that without specific information as to the headers of the post as received by Mailman and specific list configuration information, we aren't going to be able to understand what happened or if there is a bug involved. In any case, I am moving this from 'patches' to 'bugs' for the interim as it clearly isn't a patch. ---------------------------------------------------------------------- Comment By: Linda Betts (llbetts) Date: 2006-03-13 18:26 Message: Logged In: YES user_id=1063268 Although I agree with the comments that if any of the headers contains the real members email address it will be processed as a member, the real member is moderated and all posts from moderated members are configured to be discarded. Therefore, in this configuration it should not matter who sent the reply. Only the list owner is allowed to send messages to the list and the reply should have been discarded. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 16:00 Message: Logged In: YES user_id=1123998 In a default installation, post will be determined to be from a list member if the envelope sender or any of the From:, Reply-To: or Sender: headers contain a member address. You could send an off list message to the old address and inspect the returned message to see if Return-Path: (the envelope sender), From:, Reply-To: or Sender: contain the old address. If so, accepting this would be expected behavior. Note that in a situation like this, it may be preferable to discuss the issue on mailman-users at python.org before submitting a bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1449048&group_id=103 From noreply at sourceforge.net Tue Mar 14 03:07:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Mar 2006 18:07:12 -0800 Subject: [ mailman-Bugs-1449048 ] non-member post failuer Message-ID: Bugs item #1449048, was opened at 2006-03-13 10:18 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1449048&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: Linda Betts (llbetts) Assigned to: Nobody/Anonymous (nobody) Summary: non-member post failuer Initial Comment: Running Mailman 2.1.5 on Red Hat Linux 3. Have list configured to discard posts from non-members. Non-member sent in auto reply containing my address has changed information that actually came from the new address which was not registered. List server sent this auto-reply from non-member to the list. Can't find similar problem reported or bug fix. Output list configuration, pertinent info below: # legal values are: # 0 = "Accept" # 1 = "Hold" # 2 = "Reject" # 3 = "Discard" generic_nonmember_action = 3 Please advise. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 18:07 Message: Logged In: YES user_id=1123998 anonymous_list = True no info about original sender left in archives, but there is an entry 'post to hgsa-web-updates from xxx anonymized' in the 'post' log which will at least tell you the From: value, although that isn't guaranteed to be the 'member' that was accepted. But anyway, chack that address in the Membership list and verify that it is moderated. Or you can see FAQ 3.62 at http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.062.htp for a pointer to a script that can screen-scrape the admin web interface and enable you to easily find any unmoderated members. Note that if there are any at all, your list is vulnerable to spoofing, even inadvertently by some half brain dead autoresponder. As one possibility, is the fixed reply-to 'hgsa-web at hgsa.com' an unmoderated member? ---------------------------------------------------------------------- Comment By: Linda Betts (llbetts) Date: 2006-03-13 17:10 Message: Logged In: YES user_id=1063268 According to the output from config_list these 2 items are set to: accept_these_nonmembers = [] generic_nonmember_action = 3 I have attached the complete output from the config_list output. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 16:31 Message: Logged In: YES user_id=1123998 Is there anything in accept_these_nonmembers? What is generic_nonmember_action? If one or the other of these settings don't explain the issue, then I'm afraid that without specific information as to the headers of the post as received by Mailman and specific list configuration information, we aren't going to be able to understand what happened or if there is a bug involved. In any case, I am moving this from 'patches' to 'bugs' for the interim as it clearly isn't a patch. ---------------------------------------------------------------------- Comment By: Linda Betts (llbetts) Date: 2006-03-13 15:26 Message: Logged In: YES user_id=1063268 Although I agree with the comments that if any of the headers contains the real members email address it will be processed as a member, the real member is moderated and all posts from moderated members are configured to be discarded. Therefore, in this configuration it should not matter who sent the reply. Only the list owner is allowed to send messages to the list and the reply should have been discarded. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-13 13:00 Message: Logged In: YES user_id=1123998 In a default installation, post will be determined to be from a list member if the envelope sender or any of the From:, Reply-To: or Sender: headers contain a member address. You could send an off list message to the old address and inspect the returned message to see if Return-Path: (the envelope sender), From:, Reply-To: or Sender: contain the old address. If so, accepting this would be expected behavior. Note that in a situation like this, it may be preferable to discuss the issue on mailman-users at python.org before submitting a bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1449048&group_id=103 From noreply at sourceforge.net Tue Mar 14 10:53:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Mar 2006 01:53:28 -0800 Subject: [ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute) Message-ID: Bugs item #1445630, was opened at 2006-03-08 14:06 Message generated for change (Comment added) made by chris-taylor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&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: chris-taylor (chris-taylor) Assigned to: Nobody/Anonymous (nobody) Summary: /templates/de/verify.txt: encoding of special chars(umlaute) Initial Comment: In the last stable release of mailman-2.1.7 the encoding of the special german characters (umlaute: ????????????) in the file /templates/de/verify.txt is wrong. When a confirm message is sent the recipient gets strange characters for the german umlaute (e.g. ???? instead of ??). I inserted the right characters in the file, now everything seems fine. See attached file... Regards Christian ---------------------------------------------------------------------- >Comment By: chris-taylor (chris-taylor) Date: 2006-03-14 10:53 Message: Logged In: YES user_id=994602 Hello, I looked through all the german template-files and as far as I can say /templates/de/verify.txt is the only file which was encoded in UTF-8.... Additional comment: Thank you very much for this great piece of software !!! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-10 20:13 Message: Logged In: YES user_id=1123998 The template has been properly iso-8859-1 encoded for 2.1.8a1. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-08 16:50 Message: Logged In: YES user_id=1123998 It looks like the /templates/de/verify.txt template we're distributing is UTF-8 encoded. Is this the only one? I looked at a couple of others and they appear to be iso-8859-1 as they should be since that is Mailman's character set for german language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445630&group_id=103 From noreply at sourceforge.net Thu Mar 16 19:42:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Mar 2006 10:42:06 -0800 Subject: [ mailman-Patches-1451544 ] Addition of canonical list name Message-ID: Patches item #1451544, was opened at 2006-03-16 18:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1451544&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: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Andrew D. Clark (beshwa) Assigned to: Nobody/Anonymous (nobody) Summary: Addition of canonical list name Initial Comment: This patch adds MM-List-Name-Canonical to HTMLFormatter.py This is the lower-case list name, provided by the lower() function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1451544&group_id=103 From noreply at sourceforge.net Fri Mar 17 21:39:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Mar 2006 12:39:34 -0800 Subject: [ mailman-Patches-943827 ] true virtual hosting patch for 2.1 Message-ID: Patches item #943827, was opened at 2004-04-28 18:57 Message generated for change (Comment added) made by minfrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&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: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: The Anarcat (anarcat) Assigned to: Nobody/Anonymous (nobody) Summary: true virtual hosting patch for 2.1 Initial Comment: [copy of the mail sent to -developpers@] We developped a reliable solution for running lists with the same name on different domains on the same Mailman installation. I implemented that on top of the Mailman 2.1.1-5.1 Debian stable package. All that is needed is to patch 2 files (bin/newlist, Mailman/MailList.py) in the mailman install, and here is the patch: http://bugs.koumbit.net/file_download.php?file_id=3&type=bug There's only one caveat right now: Mailman/Cgi/create.py might need to get patched too, but I haven't got around looking at it yet, and it "just works", for now. I don't know what's the current status of virtual hosting support on Mailman, but this patch is a simple hack that should bring joy in the homes of all Mailman admins around the world. :) I got my inspiration and part of the code from: http://mithrandr.moria.org/blog/139.html All it does is to add the domain to the internal_name() of a list. The real_name is kept as is, and the getListAddress() does the Right Thing. This makes Mailman generate aliases like: list-example.com: "|/var/lib/mailman/mail/mailman post list-example.com" Care will have to be taken on the MTA side to map those list-example.com to list at example.com. We are using alternc.org to manage our server, so we are using LDAP, so everything went pretty smoothly. :) But I guess it will require some magic on the Postfix side or something... Cheers, A. PS: for those wanting to see more, you can come to our Wiki: http://koumbit.net/wiki/VirtualMailman You'll probably have a little trouble finding your way if you don't read french though. :) Babelfish might help, haven't tried. ---------------------------------------------------------------------- Comment By: Graham Leggett (minfrin) Date: 2006-03-17 21:39 Message: Logged In: YES user_id=129704 I tried the patch at http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch and it applied cleanly to mailman as provided by RHEL4. I tried to create a list called "list at domain1.com", but this failed with the error "Error: List name must not include "@"". Does this patch have any sort of instructions anywhere? ---------------------------------------------------------------------- Comment By: Arnaud Lavrard (arnaudlavrard) Date: 2005-07-20 15:52 Message: Logged In: YES user_id=1315788 I ported the patch to mailman 2.1.5 : http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch ---------------------------------------------------------------------- Comment By: The Anarcat (anarcat) Date: 2005-03-16 21:40 Message: Logged In: YES user_id=246797 I have ported the patch to 2.1.4, no news on 2.1.5 yet. I have also put the patch in a seperate CVS server. Fetch all the goods there: http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-virtual-2.1.1.patch http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-virtual-2.1.4.patch I've also updated the 2.1.1 patch to fix the list-id, so I delete the attachment, fetch the patch straight from our CVS for the latest fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&group_id=103 From noreply at sourceforge.net Sat Mar 18 09:24:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Mar 2006 00:24:16 -0800 Subject: [ mailman-Bugs-1453049 ] Typos in the Mailman 2.1.8a PO file Message-ID: Bugs item #1453049, was opened at 2006-03-18 18: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=1453049&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: Clytie Siddall (clytie) Assigned to: Nobody/Anonymous (nobody) Summary: Typos in the Mailman 2.1.8a PO file Initial Comment: 1. po:670 reference: ??? Mailman/Gui/ContentFilter.py:130 Original: ???0 One of these actions is take when the message matches one of\n the content filtering rules, - is take + is taken 2. po:717 reference: ??? Mailman/Gui/General.py:143 Original: ???0 This text will be prepended to subject lines of messages \n posted to the list, to distinguish mailing list messages in in\n mailbox summaries. Brevity is premium here, it's ok to shorten\n long mailing list names to something more concise, as long as it\n still identifies the mailing list.\n You can also add a sequencial number - messages in in mailbox summaries + messages in mailbox summaries - sequencial + sequential 3. po:785 reference: ??? Mailman/Gui/NonDigest.py:129 Original: ???0 Text prepended to the top of every immediately-delivery \n message. - immediately-delivery + immediate-delivery (OR + immediately-delivered) Also in this string: .po:787 reference: ??? Mailman/Gui/NonDigest.py:134 Original: ???0 Text appended to the bottom of every immediately- delivery\n message. 4. po:789 reference: ??? Mailman/Gui/NonDigest.py:141 Original: ???0 When you scrub attachments, they are stored in archive\n area and links are made in the message so that the member can\n access via web browser. If you want the attachments totally\n disappear, you can use content filter options. + When you scrub attachments, they are stored in the archive and accessible to the member via web-browser links in the message. If you want to get rid of attachments completely, you can use the content filter options. 5. po:828 reference: ??? Mailman/Gui/Privacy.py:244 Original: ???0 Postings from any of these non-members will be automatically\n accepted with no further moderation applied. Add member\n addresses one per line; start the line with a ^ character to\n designate a regular expression match. In several strings about "non-members", the sentence beginning "Add member addresses one per line" still occurs. It should probably be changed, in those strings, to "Add non-member addresses one per line". The other strings are: .po:830 reference: ??? Mailman/Gui/Privacy.py:253 Original: ???0 Postings from any of these non-members will be immediately\n and automatically held for moderation by the list moderators. \n The sender will receive a notification message which will allow\n them to cancel their held message. Add member addresses one per\n line; start the line with a ^ character to designate a regular\n expression match. .po:832 reference: ??? Mailman/Gui/Privacy.py:264 Original: ???0 Postings from any of these non-members will be automatically\n rejected. In other words, their messages will be bounced back to\n the sender with a notification of automatic rejection. This\n option is not appropriate for known spam senders; their messages\n should be\n automatically discarded.\n \n

Add member addresses one per line; start the line with a ^\n character to designate a regular expression match. po:834 reference: ??? Mailman/Gui/Privacy.py:279 Original: ???0 Postings from any of these non-members will be automatically\n discarded. That is, the message will be thrown away with no\n further processing or notification. The sender will not receive\n a notification or a bounce, however the list moderators can\n optionally receive copies of auto-discarded messages..\n \n

Add member addresses one per line; start the line with a ^\n character to designate a regular expression match. 6. Here you create two strings to show plural forms: po:892 reference: ??? Mailman/HTMLFormatter.py:80 Original: ???0 (1 private member not shown) .po:893 reference: ??? Mailman/HTMLFormatter.py:82 Original: ???0 (%(num_concealed)d private members not shown) but this is not effective for translation. The gettext plurals feature makes it possible for translators to input the correct number of plurals for their language. English may need two forms, singular and plural, but my language is one of several which have _no_ plural forms in this sense, and there are European languages which have more than two forms. If you don't use the gettext plurals feature, we can't translate those strings effectively. Gettext will output the correct number of plurals fields for each language, by parsing the plurals string in the PO file header. In my case, that will avoid me inputting the same translation twice in several places in this file. In the case of languages with more plural forms than English, it will avoid incomplete translations or translations that simply don't make sense. Please see the gettext manual for further information: http://www.gnu.org/software/gettext/manual/html_mono/ gettext.html#SEC150 7. po:906 reference: ??? Mailman/HTMLFormatter.py:195 Mailman/ HTMLFormatter.py:202 Original: ???0 also po:908 reference: ??? Mailman/HTMLFormatter.py:206 Original: ???0 This is %(also)sa private list, which means that the\n list of members is not available to non-members. This is likely to cause errors in translation. Although it means translating six strings instead of three, we can cut and paste most of the string, and we can be sure, that way, of correct translations. Please don't take short-cuts on translation, unless you are sure they will not affect the quality of the translation. 8. Original: ???0 Rebuild a list's archive.\n \n -e M\n --end=M\n End indexing at article M. This script is not very efficient with\n respect to memory management, and for large archives, it may not be\n possible to index the mbox entirely. For that reason, you can specify\n the start and end article numbers.\n \n Where is the path to a list's complete mbox archive. Usually this will\n There seems to be something missing here, between "the start and end article numbers" and "Where is the path", because "where" in this context is a conjunction, joining a previous statement to this one. However, there is a full stop and two line breaks in between, indicating a statement well and truly finished. What is missing here? 9. po:1069 reference: ??? bin/b4b5-archfix:19 Original: ???0 Fix the MM2.1b4 archives.\n \n Usage: %(PROGRAM)s [options] file ...\n \n Where options are:\n -h / --help\n Print this help message and exit.\n \n Only use this to `fix' some archive database files that may have gotten \n written in Mailman 2.1b4 with some bogus data. Use like this from your\n $PREFIX directory\n - Use like this + Use it like this OR + Use the command like this (Syntax error: transitive verb must have object.) 10. po:1111 reference: ??? bin/clone_member:19 Original: ???0 Clone a member address.\n Usage:\n clone_member [options] fromoldaddr tonewaddr\n \n Where:\n \n --listname=listname\n -l listname\n - Where + Options Also occurs in these strings: po:1149 reference: ??? bin/find_member:19 Original: ???0 Find all lists that a member's address is on.\n \n Usage:\n find_member [options] regex [regex [...]]\n \n Where:\n --listname=listname\n -l listname\n .po:1161 reference: ??? bin/list_admins:19 Original: ???0 List all the owners of a mailing list.\n \n Usage: %(program)s [options] listname ...\n \n Where:\n \n --all-vhost=vhost\n -v=vhost\n po:1163 reference: ??? bin/list_lists:19 Original: ???0 List all mailing lists.\n \n Usage: %(program)s [options]\n \n Where:\n \n -a / --advertised\n List only those mailing lists that are publically advertised\n .po:1166 reference: ??? bin/list_members:19 Original: ???0 List all the members of a mailing list.\n \n Usage: %(PROGRAM)s [options] listname\n \n Where:\n \n --output file\n -o file\n po:1220 reference: ??? bin/rmlist:19 Original: ???0 Remove the components of a mailing list with impunity - beware!\n \n This removes (almost) all traces of a mailing list. By default, the lists\n archives are not removed, which is very handy for retiring old lists.\n \n Usage:\n rmlist [-a] [-h] listname\n \n Where:\n --archives\n -a\n po:1254 reference: ??? bin/unshunt:19 Original: ???0 Move a message from the shunt queue to the original queue.\n \n Usage: %(PROGRAM)s [options] [directory]\n \n Where:\n \n -h / --help\n Print help and exit.\n 11. po:1142 reference: ??? bin/dumpdb:19 Original: ???0 Dump the contents of any Mailman `database' file.\n \n Usage: %(PROGRAM)s [options] filename\n \n Options:\n \n --marshal/-m\n Assume the file contains a Python marshal, overridding any automatic\n guessing.\n - overridding + overriding 12. (Also from the above string...) The interaction between -l and -x is as follows. If any -l option is given\n then only the named list will be included in the search. If any -x option is\n given but no -l option is given, then all lists will be search except those \n specifically excluded.\n - all lists will be search + all lists will be searched 13. .po:1166 reference: ??? bin/list_members:19 Original: ???0 List all the members of a mailing list.\n Print the members that have delivery disabled. Optional argument can\n be \"byadmin\", \"byuser\", \"bybounce\", or \"unknown\" which prints just the\n users who have delivery disabled for that reason. It can also be\n \"enabled\" which prints just those member for whom delivery is \n enabled.\n - the members that have delivery disabled + the members who have delivery disabled - which prints just those member + which prints just those members 14. po:1170 reference: ??? bin/list_owners:19 Original: ???0 List the owners of a mailing list, or all mailing lists.\n \n Usage: %(PROGRAM)s [options] [listname ...]\n Options:\n \n -w / --with-listnames\n Group the owners by list names and include the list names in the \n output. Otherwise, the owners will be sorted and uniquified based on\n the email address.\n - uniquified + identified There is no such word "uniquify" in common usage. Identification within a group is based on unique qualities, so "identified" is appropriate. 15. .po:1171 reference: ??? bin/mailmanctl:19 Original: ???0 Primary start-up and shutdown script for Mailman's qrunner daemon.\n \n Note though, that if you run with -u and are not in the mailman group,\n you may have permission problems, such as begin unable to delete a\n list's archives through the web. Tough luck!\n - such as begin unable to + such as being unable to 16. po:1200 reference: ??? bin/newlist:19 Original: ???0 Create a new, unpopulated mailing list.\n \n Usage: %(PROGRAM)s [options] [listname [listadmin-addr [admin- password]]]\n \n E.g. with this setting people will view the general list\n overviews at http://www.mydom.ain/mailman/listinfo. Also, www.mydom.ain\n should be a key in the VIRTUAL_HOSTS mapping in mm_cfg.py/ Defaults.py if\n the email hostname to be automatically determined.\n - if the email hostname to be automatically determined.\n + if the email hostname is to be automatically determined.\n 17. Options:\n \n -r runner[:slice:range]\n --runner=runner[:slice:range]\n Run the named qrunner, which must be one of the strings returned by\n the -l option. Optional slice:range if given, is used to assign\n multiple qrunner processes to a queue. range is the total number of\n qrunners for this queue while slice is the number of this qrunner from\n [0..range).\n \n If using the slice:range form, you better make sure that each qrunner\n for the queue is given the same range value. If slice:runner is not\n given, then 1:1 is used.\n - If slice:runner is not given + If slice:range is not given 18. po:1283 reference: ??? bin/update:585 Original: ???0 Ignoring bad pended data: %(key)s: %(val)s - pended data + pending data OR + appended data OR (prepended/suspended etc.) 19. po:1300 reference: ??? bin/withlist:19 Original: ???0 General framework for interacting with a mailing list object.\n Now, from the command line you can print the list's posting address by running\n the following from the command line:\n - Now, from the command line you can print the list's posting address by running\n the following from the command line:\n + Now, you can print the list's posting address by running\n the following from the command line:\n (you've repeated "from the command-line" in this string) from Clytie, Vietnamese translator (I'm about to add the Vietnamese translation) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1453049&group_id=103 From noreply at sourceforge.net Tue Mar 21 11:12:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Mar 2006 02:12:31 -0800 Subject: [ mailman-Patches-1455262 ] A workaround for treating long address splitted into lines Message-ID: Patches item #1455262, was opened at 2006-03-21 19:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1455262&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: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Naoki Fukuta (naoki-fukuta) Assigned to: Nobody/Anonymous (nobody) Summary: A workaround for treating long address splitted into lines Initial Comment: ---Summary:--- Following is a workaround for a problem when processing very long email address field that is splitted into two or more lines. I tested it on Mailman 2.1.8. Please evaluate this patch and feedback to the latest build. I appreciate if this is a duplicate of already reported one. ---Problem Description:--- The mail address parser program (pythonlib/email/_parseaddr.py) has a problem when the field is splitted into two or more lines by using continuations(eg. "\r\n " or "\r\n\t"). For example, following "Cc:" field can be splitted into lines when the mail is sent to the server. Cc: =?ISO-2022-JP?B?IktCU0UbJEI4JjVmMnEbKEIgGyRCNDQ7dkNEGyhC?= =?ISO-2022-JP?B?Ig==?= , =?ISO-2022-JP?B?IhskQkVFO1I+cEpzREw/LjNYMnEbKEIgGyRCOCY1ZhsoQg==?= =?ISO-2022-JP?B?GyRCMnFIL0k9Pz05fiU3JTklRiVgGyhCIg==?= The main problem is there are no actual email address at line 1 and 3. Current code in _parseaddr.py expects there is at least one valid email address in a line. So what will happen? See below. When posting the mail to members, two addresses are newly made, with a default domain name (@mailman.example3.org). Cc: =?ISO-2022-JP?B?Ig==?= , =?ISO-2022-JP?B?IktCU0UbJEI4JjVmMnEbKEIgGyRCNDQ7dkNEGyhC?=@mailman.example3.org, =?ISO-2022-JP?B?IhskQkVFO1I+cEpzREw/LjNYMnEbKEIgGyRCOCY1ZhsoQg==?=@mailman.example3.org, =?ISO-2022-JP?B?GyRCMnFIL0k9Pz05fiU3JTklRiVgGyhCIg==?= ---Patch--- I made a workaroud patch by adding a darty code into getphraselist() method. ---------------------------------------------------- def getphraselist(self): """Parse a sequence of RFC 2822 phrases. A phrase is a sequence of words, which are in turn either RFC 2822 atoms or quoted-strings. Phrases are canonicalized by squeezing all runs of continuous whitespace into one space. """ plist = [] while self.pos < len(self.field): if self.field[self.pos] in self.LWS: self.pos += 1 elif self.field[self.pos] == '"': plist.append(self.getquote()) elif self.field[self.pos] == '(': self.commentlist.append(self.getcomment()) + elif (self.pos + 4) < len(self.field) and self.field[self.pos] in '\r' and self.field[self.pos+1] in '\n' and self.field[self.pos+2] in '\t': + self.pos += 3 + elif (self.pos + 4) < len(self.field) and self.field[self.pos] in '\r' and self.field[self.pos+1] in '\n' and self.field[self.pos+2] in ' ': + self.pos += 3 + elif (self.pos + 4) < len(self.field) and self.field[self.pos] in '\n' and self.field[self.pos+1] in '\t': + self.pos += 2 + elif (self.pos + 4) < len(self.field) and self.field[self.pos] in '\n' and self.field[self.pos+1] in ' ': + self.pos += 2 + elif (self.pos + 4) < len(self.field) and self.field[self.pos] in '\r' and self.field[self.pos+1] in '\t': + self.pos += 2 elif self.field[self.pos] in self.phraseends: break else: plist.append(self.getatom(self.phraseends)) return plist ---------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1455262&group_id=103 From noreply at sourceforge.net Sun Mar 26 05:21:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Mar 2006 19:21:18 -0800 Subject: [ mailman-Feature Requests-403066 ] Auto Approval of subscriptions for certain domains Message-ID: <200603260321.k2Q3LI7W022966@sc8-sf-db2-new-b.sourceforge.net> Feature Requests item #403066, was opened at 01/01/01 06:27 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&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: Accepted Priority: 3 Submitted By: Mark Tearle (mtearle) Assigned to: Mark Sapiro (msapiro) Summary: Auto Approval of subscriptions for certain domains Initial Comment: A patch to enable automatic approval for certain domains, eg people in the example.com are automatically approved all others have to wait for the moderator ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 03/25/06 19:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 03/12/06 19:12 Message: Logged In: YES user_id=3142 I've successfully applied this against a v2.1.8 system and it works well. Thanks!! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 03/11/06 10:36 Message: Logged In: YES user_id=1123998 The attached patch is against a 2.1.8a1 installed base (installed because it patches Defaults.py and not Defaults.py.in). It is a modification and extension of the original patch. It implements a new list attribute 'subscribe_auto_approval' which is a list of email addresses and regular expressions matching email addresses whose subscriptions are exempt from admin approval. It implements the original intent if one just uses regexps that match domains. This will go in Mailman 2.2, but it would be nice to get some feedback from people who are interested in this feature and are willing to try the patch. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 03/11/03 05:31 Message: Logged In: YES user_id=34209 Is this still necessary with Mailman 2.1, which has more 'automatic' options (as well as 'memberadaptors') ? In any case, the patch is likely heavily out of date by now, I'm moving this to Feature Requests for now. Feel free to respond if you (still) have a need. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&group_id=103 From noreply at sourceforge.net Mon Mar 27 04:30:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 18:30:08 -0800 Subject: [ mailman-Bugs-1459022 ] Postfix.py and aliases (#CREATED:xxx) Message-ID: Bugs item #1459022, was opened at 2006-03-26 18:30 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=1459022&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 alpha Status: Open Resolution: None Priority: 5 Submitted By: Bob Holden (eawf) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix.py and aliases (#CREATED:xxx) Initial Comment: CentOS4.2 Installed Mailman2.1.5 via YUM. Postfix Configured Automatic aliases file creation. When creating list from ./newlist, no problems. When creating list from web, got bug page, and discovered an alias entry, "#CREATED:...". While not being a Python programmer, glancing through the Postfix.py file, it looks like when looping through the STANZA section to create the aliases file, the commented #CREATED: line isn't ignored, causing the record to be created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&group_id=103 From noreply at sourceforge.net Mon Mar 27 04:59:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Mar 2006 18:59:17 -0800 Subject: [ mailman-Bugs-1459022 ] Postfix.py and aliases (#CREATED:xxx) Message-ID: Bugs item #1459022, was opened at 2006-03-26 18:30 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&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 alpha Status: Open Resolution: None Priority: 5 Submitted By: Bob Holden (eawf) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix.py and aliases (#CREATED:xxx) Initial Comment: CentOS4.2 Installed Mailman2.1.5 via YUM. Postfix Configured Automatic aliases file creation. When creating list from ./newlist, no problems. When creating list from web, got bug page, and discovered an alias entry, "#CREATED:...". While not being a Python programmer, glancing through the Postfix.py file, it looks like when looping through the STANZA section to create the aliases file, the commented #CREATED: line isn't ignored, causing the record to be created. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-26 18:59 Message: Logged In: YES user_id=1123998 Both bin/newlist and the Cgi create script invoke the exact same Mailman/MTA/Postfix.py module to update the aliases. The only difference is the user/group under which it runs. Thus, this is most likely a problem with the 'mailman' group not having write permission on data/aliases*. Both data/aliases and data/aliases.db should be group owned by the 'mailman' group and be group writable. This may be FAQ 6.9 - http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.009.htp If this is not a permissions issue, please post the traceback from the "bug" from Mailman's error log. Note that the "#CREATED:" line in the aliases file is a comment and is intended to be there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&group_id=103 From noreply at sourceforge.net Tue Mar 28 09:38:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Mar 2006 23:38:25 -0800 Subject: [ mailman-Patches-1459818 ] New Arabic translation Message-ID: Patches item #1459818, was opened at 2006-03-28 10:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1459818&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: internationalization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Munzir Taha (munzirtaha) Assigned to: Nobody/Anonymous (nobody) Summary: New Arabic translation Initial Comment: Attached is an Arabic translation of mailman. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1459818&group_id=103 From noreply at sourceforge.net Tue Mar 28 12:04:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 02:04:42 -0800 Subject: [ mailman-Patches-1459897 ] New Arabic translation Message-ID: Patches item #1459897, was opened at 2006-03-28 13:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1459897&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: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Munzir Taha (munzirtaha) Assigned to: Nobody/Anonymous (nobody) Summary: New Arabic translation Initial Comment: Attached is an Arabic translation of mailman. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1459897&group_id=103 From noreply at sourceforge.net Tue Mar 28 12:21:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 02:21:50 -0800 Subject: [ mailman-Patches-1459818 ] New Arabic translation Message-ID: Patches item #1459818, was opened at 2006-03-28 10:38 Message generated for change (Comment added) made by munzirtaha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1459818&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: internationalization Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Munzir Taha (munzirtaha) Assigned to: Nobody/Anonymous (nobody) Summary: New Arabic translation Initial Comment: Attached is an Arabic translation of mailman. ---------------------------------------------------------------------- >Comment By: Munzir Taha (munzirtaha) Date: 2006-03-28 13:21 Message: Logged In: YES user_id=1044850 I would close it since somehow it posted twice while attaching the translation. Duplicate of http://sourceforge.net/tracker/index.php?func=detail&aid=1459897&group_id=103&atid=300103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1459818&group_id=103 From noreply at sourceforge.net Wed Mar 29 08:31:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Mar 2006 22:31:17 -0800 Subject: [ mailman-Patches-1460471 ] New Vietnamese translation (2.1.8b1) Message-ID: Patches item #1460471, was opened at 2006-03-29 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1460471&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: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Clytie Siddall (clytie) Assigned to: Nobody/Anonymous (nobody) Summary: New Vietnamese translation (2.1.8b1) Initial Comment: Here is the Vietnamese translation of the interface file (/messages) for Mailman 2.1.8b1. I will be working through the html templates gradually. Enjoy! :) Please also add me, as requested, to the Mailman language champions. Thankyou. Clytie, Vietnamese translator ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1460471&group_id=103 From noreply at sourceforge.net Wed Mar 29 15:07:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 05:07:04 -0800 Subject: [ mailman-Patches-1460655 ] Howto info for Internationalization page Message-ID: Patches item #1460655, was opened at 2006-03-29 23:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1460655&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: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Clytie Siddall (clytie) Assigned to: Nobody/Anonymous (nobody) Summary: Howto info for Internationalization page Initial Comment: Here is a basic Howto for translating Mailman. This file is HTML, so I hope you can simply insert it into your Internationalization page at your GNU homepage. The only edit required will be an anchor to the Mailman Language Champions table, unless it is simply below this text. Otherwise, it's basic, but it answers the questions new translators will probably ask. Anyone is welcome to edit it. I hope it is useful. :) from Clytie, Vietnamese translator ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1460655&group_id=103 From noreply at sourceforge.net Wed Mar 29 19:01:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 09:01:24 -0800 Subject: [ mailman-Bugs-1460792 ] Held message for administrivia unclear Message-ID: Bugs item #1460792, was opened at 2006-03-29 12:01 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=1460792&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: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Joshua Ginsberg (jaginsberg) Assigned to: Nobody/Anonymous (nobody) Summary: Held message for administrivia unclear Initial Comment: My employer suggested that the error message: "Message may contain administrivia" presented in a "message held" email is unclear and does not adequately present the poster with his/her options. He suggests it read: > The reason it is being held: > > Message looks like a request to subscribe or unsubscribe > from the list. Such requests should not go to the whole list. > > It could also say how to contact the moderator. Regardless of whether you accept his specific recommendation, this language could certainly be clearer for those unfamiliar with the administrivia filter or even the term administrivia. -jag ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1460792&group_id=103 From noreply at sourceforge.net Wed Mar 29 19:04:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 09:04:56 -0800 Subject: [ mailman-Feature Requests-1460796 ] Add option to remove Sender header Message-ID: Feature Requests item #1460796, was opened at 2006-03-29 12:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&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: Myke Olson (xpl0re) Assigned to: Nobody/Anonymous (nobody) Summary: Add option to remove Sender header Initial Comment: When sending messages through mailman with Postfix, it adds a new header called "Sender" in addition to the Errors-To and Return-Path headers. Outlook (probably mistakenly) sees the Sender header and treats it like gold. All messages show up in the user's mailbox as from list-bounces on behalf of therealperson. What's worse is that the rules/filters will only work on the list-bounces part and not therealperson. If we could selectively turn off the addition of the Sender header (and be able to keep the other two), then we should still be able to use bounces but have Outlook be able to filter messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_id=103 From noreply at sourceforge.net Thu Mar 30 02:44:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 16:44:43 -0800 Subject: [ mailman-Bugs-1461054 ] Wrong domain used in moderation message Message-ID: Bugs item #1461054, was opened at 2006-03-29 16:44 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=1461054&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: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Eric Smith (brouhaha) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong domain used in moderation message Initial Comment: Mailman 2.1.7 is running on host foo.example.com, with a mailing list on virtual domain bar.example.com. If a posting will be moderated, an email is sent to the poster offering a chance to cancel the message. However, the cancel URL is on foo.example.com, rather than bar.example.com. The cancel URL works, but it exposes the real hostname, whereas it should only show the virtual domain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_id=103 From noreply at sourceforge.net Thu Mar 30 03:14:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 17:14:36 -0800 Subject: [ mailman-Bugs-1461054 ] Wrong domain used in moderation message Message-ID: Bugs item #1461054, was opened at 2006-03-29 16:44 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&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: 2.1 (stable) >Status: Pending Resolution: None Priority: 5 Submitted By: Eric Smith (brouhaha) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong domain used in moderation message Initial Comment: Mailman 2.1.7 is running on host foo.example.com, with a mailing list on virtual domain bar.example.com. If a posting will be moderated, an email is sent to the poster offering a chance to cancel the message. However, the cancel URL is on foo.example.com, rather than bar.example.com. The cancel URL works, but it exposes the real hostname, whereas it should only show the virtual domain. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-29 17:14 Message: Logged In: YES user_id=1123998 The most likely cause of this is that the list attribute web_page_url has the foo.example.com host name instead of bar.example.com. This in turn is caused by creating the list with the wrong or the default host. If this is the case, links in the web interface will likely also be to foo.example.com, and the list won't appear on the bar.example.com admin and listinfo overview pages. You can fix this (assuming your VIRTUAL_HOSTS dictionary is correct - add_virtualhost() directives in mm_cfg.py - by running bin/fix_url.py on the list (just run bin/fix_url.py for instructions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_id=103 From noreply at sourceforge.net Thu Mar 30 04:55:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 18:55:07 -0800 Subject: [ mailman-Bugs-1459022 ] Postfix.py and aliases (#CREATED:xxx) Message-ID: Bugs item #1459022, was opened at 2006-03-26 18:30 Message generated for change (Comment added) made by eawf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&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 alpha Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Bob Holden (eawf) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix.py and aliases (#CREATED:xxx) Initial Comment: CentOS4.2 Installed Mailman2.1.5 via YUM. Postfix Configured Automatic aliases file creation. When creating list from ./newlist, no problems. When creating list from web, got bug page, and discovered an alias entry, "#CREATED:...". While not being a Python programmer, glancing through the Postfix.py file, it looks like when looping through the STANZA section to create the aliases file, the commented #CREATED: line isn't ignored, causing the record to be created. ---------------------------------------------------------------------- >Comment By: Bob Holden (eawf) Date: 2006-03-29 18:55 Message: Logged In: YES user_id=483098 Interestingly, when I commented out both of the "CREATED: print statements, the problem went away. Only thing I can figure from that is that programmatically, when creating the aliases file, the commented CREATED: line is not being ignored or skipped over. Again, glancing through the code I see checking for the STANZA lines, but not the CREATED line. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-26 18:59 Message: Logged In: YES user_id=1123998 Both bin/newlist and the Cgi create script invoke the exact same Mailman/MTA/Postfix.py module to update the aliases. The only difference is the user/group under which it runs. Thus, this is most likely a problem with the 'mailman' group not having write permission on data/aliases*. Both data/aliases and data/aliases.db should be group owned by the 'mailman' group and be group writable. This may be FAQ 6.9 - http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.009.htp If this is not a permissions issue, please post the traceback from the "bug" from Mailman's error log. Note that the "#CREATED:" line in the aliases file is a comment and is intended to be there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&group_id=103 From noreply at sourceforge.net Thu Mar 30 05:45:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Mar 2006 19:45:00 -0800 Subject: [ mailman-Bugs-1459022 ] Postfix.py and aliases (#CREATED:xxx) Message-ID: Bugs item #1459022, was opened at 2006-03-26 18:30 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&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 alpha Status: Open Resolution: Works For Me Priority: 5 Submitted By: Bob Holden (eawf) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix.py and aliases (#CREATED:xxx) Initial Comment: CentOS4.2 Installed Mailman2.1.5 via YUM. Postfix Configured Automatic aliases file creation. When creating list from ./newlist, no problems. When creating list from web, got bug page, and discovered an alias entry, "#CREATED:...". While not being a Python programmer, glancing through the Postfix.py file, it looks like when looping through the STANZA section to create the aliases file, the commented #CREATED: line isn't ignored, causing the record to be created. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-29 19:45 Message: Logged In: YES user_id=1123998 I think the line you're referring to is print >> fp, '# CREATED:', time.ctime(time.time()) Which occurs in two places, one for the 'aliases' file and one for the 'virtual-mailman' file if any. It writes a line like # CREATED: Wed Mar 29 19:31:24 2006 (with the current date and time) into the file. This line in the 'aliases' or 'virtual-mailman' file begins with '#' and thus is a comment in that file just as are the lines # STANZA START: listname preceding the # CREATED line and # STANZA END: listname following the actual data. Why is this "# CREATED: ..." line a problem? Going back to your original issue, what is the traceback from the "bug" from Mailman's 'error' log? I don't think this 'bug' has anything to do with the print statements you commented or with the presence or absence of the "# CREATED: ..." line in the resultant file. The "# CREATED: ..." line is documentation. The code that looks at the "# STANZA: ..." lines is figuring out what to delete from the files when you delete a list. ---------------------------------------------------------------------- Comment By: Bob Holden (eawf) Date: 2006-03-29 18:55 Message: Logged In: YES user_id=483098 Interestingly, when I commented out both of the "CREATED: print statements, the problem went away. Only thing I can figure from that is that programmatically, when creating the aliases file, the commented CREATED: line is not being ignored or skipped over. Again, glancing through the code I see checking for the STANZA lines, but not the CREATED line. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-26 18:59 Message: Logged In: YES user_id=1123998 Both bin/newlist and the Cgi create script invoke the exact same Mailman/MTA/Postfix.py module to update the aliases. The only difference is the user/group under which it runs. Thus, this is most likely a problem with the 'mailman' group not having write permission on data/aliases*. Both data/aliases and data/aliases.db should be group owned by the 'mailman' group and be group writable. This may be FAQ 6.9 - http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.009.htp If this is not a permissions issue, please post the traceback from the "bug" from Mailman's error log. Note that the "#CREATED:" line in the aliases file is a comment and is intended to be there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1459022&group_id=103 From noreply at sourceforge.net Thu Mar 30 12:41:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 02:41:36 -0800 Subject: [ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible Message-ID: Bugs item #1461279, was opened at 2006-03-30 12:41 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=1461279&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: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_id=103 From noreply at sourceforge.net Thu Mar 30 16:57:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 06:57:25 -0800 Subject: [ mailman-Feature Requests-1460796 ] Add option to remove Sender header Message-ID: Feature Requests item #1460796, was opened at 2006-03-29 17:04 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&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: Myke Olson (xpl0re) Assigned to: Nobody/Anonymous (nobody) Summary: Add option to remove Sender header Initial Comment: When sending messages through mailman with Postfix, it adds a new header called "Sender" in addition to the Errors-To and Return-Path headers. Outlook (probably mistakenly) sees the Sender header and treats it like gold. All messages show up in the user's mailbox as from list-bounces on behalf of therealperson. What's worse is that the rules/filters will only work on the list-bounces part and not therealperson. If we could selectively turn off the addition of the Sender header (and be able to keep the other two), then we should still be able to use bounces but have Outlook be able to filter messages. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2006-03-30 14:57 Message: Logged In: YES user_id=75166 RFC2822 (Para 3.6.2. - Originator fields) would suggest that simply not using the Sender: header when Mailman is the agent responsible for the actual transmission of the message is a breach of the RFC. The problem with the behaviour of Outlook is discussed in the Mailman FAQ here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.003.htp A suggested code change which cosmetically improves the Outlook presentation by changing the Sender: header value from the listname- bounces alias to the listname alias is described there. Paranthetically: The Error-to: header is deprecated and only inserted for backward compatibilty with old/broken MTAs. The Return-path is not a header that travels with the message and is known as a trace field. It is mandatory and normally inserted at the start of the message, as a header, by the final SMTP delivery MTA and is the value of the SMTP envelope sender. As an aside, Outlook 2003 appears to allow filtering on the contents of From: header wihtout any problems (as opposed to the From field displayed on the GUI) and this does not involve the contents of the Sender: header. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_id=103 From noreply at sourceforge.net Thu Mar 30 17:48:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 07:48:12 -0800 Subject: [ mailman-Feature Requests-1460796 ] Add option to remove Sender header Message-ID: Feature Requests item #1460796, was opened at 2006-03-29 12:04 Message generated for change (Comment added) made by xpl0re You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&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: Myke Olson (xpl0re) Assigned to: Nobody/Anonymous (nobody) Summary: Add option to remove Sender header Initial Comment: When sending messages through mailman with Postfix, it adds a new header called "Sender" in addition to the Errors-To and Return-Path headers. Outlook (probably mistakenly) sees the Sender header and treats it like gold. All messages show up in the user's mailbox as from list-bounces on behalf of therealperson. What's worse is that the rules/filters will only work on the list-bounces part and not therealperson. If we could selectively turn off the addition of the Sender header (and be able to keep the other two), then we should still be able to use bounces but have Outlook be able to filter messages. ---------------------------------------------------------------------- >Comment By: Myke Olson (xpl0re) Date: 2006-03-30 10:48 Message: Logged In: YES user_id=689092 Thanks for that posting. The hack to comment that line out definetly fixes the "problem". While I definetly agree that putting in fixes to correct behavior in MS products sucks, in this case, it would be great to just have it as an option so we don't have to have the hacked code. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2006-03-30 09:57 Message: Logged In: YES user_id=75166 RFC2822 (Para 3.6.2. - Originator fields) would suggest that simply not using the Sender: header when Mailman is the agent responsible for the actual transmission of the message is a breach of the RFC. The problem with the behaviour of Outlook is discussed in the Mailman FAQ here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.003.htp A suggested code change which cosmetically improves the Outlook presentation by changing the Sender: header value from the listname- bounces alias to the listname alias is described there. Paranthetically: The Error-to: header is deprecated and only inserted for backward compatibilty with old/broken MTAs. The Return-path is not a header that travels with the message and is known as a trace field. It is mandatory and normally inserted at the start of the message, as a header, by the final SMTP delivery MTA and is the value of the SMTP envelope sender. As an aside, Outlook 2003 appears to allow filtering on the contents of From: header wihtout any problems (as opposed to the From field displayed on the GUI) and this does not involve the contents of the Sender: header. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_id=103 From noreply at sourceforge.net Fri Mar 31 03:00:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 17:00:14 -0800 Subject: [ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible Message-ID: Bugs item #1461279, was opened at 2006-03-30 02:41 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&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: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-30 17:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_id=103 From noreply at sourceforge.net Fri Mar 31 09:05:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 23:05:00 -0800 Subject: [ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible Message-ID: Bugs item #1461279, was opened at 2006-03-30 12:41 Message generated for change (Comment added) made by psy-q You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&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: 2.1 (stable) Status: Open Resolution: None >Priority: 2 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: - (psy-q) Date: 2006-03-31 09:04 Message: Logged In: YES user_id=244049 Thanks for clearing that up, you've confirmed most of what I've only had vague suspicions about :) I found out about 2.1.5's hardcoded collapse_alternatives behavior about half an hour after posting my bug, but thanks for confirming it. I feel like a fool at the moment. I just retried this so I could give you example messages, and the behavior has stopped. I reproduced the unwanted filtering for over an hour yesterday, I have no idea why it's working correctly now. Yesterday, I tried about a dozen combinations of filter strings and settings, none of which produced the desired result. In the end, I returned to the configuration that I posted here and performed a final test to verify that the behavior is indeed confusing. Today, I switched my test MTA back on, switched Mailman back on and tried the very same test message as yesterday. Amazingly, it went through exactly as expected. Then I removed text/html from pass_mime_types, and again it behaved exactly as advertised: It let the multipart/alternative message through, kept the text/plain part intact but removed the text/html. This is completely different behavior than I saw yesterday. So now I'm even more confused than before -- In theory, this means that an upgrade to 2.1.7 using this list configuration would make everything work as it should at my site, and it would mean that there is no bug. I will test a bit more thoroughly, I'll remove Mailman and do a vanilla install of 2.1.7 to see if I can get the behavior to show again. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 03:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_id=103 From noreply at sourceforge.net Fri Mar 31 09:22:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Mar 2006 23:22:22 -0800 Subject: [ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible Message-ID: Bugs item #1461279, was opened at 2006-03-30 12:41 Message generated for change (Comment added) made by psy-q You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&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: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 2 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: - (psy-q) Date: 2006-03-31 09:22 Message: Logged In: YES user_id=244049 Seems Konqueror messed up the line breaks in my last reply. These last two days are full of cursed software :) I tried a vanilla installation of Mailman 2.1.7, configured the list as described here and everything worked exactly as expected (and advertised). I can't explain where yesterday's behavior came from, and I'm sorry if I caused any confusion. I can only guess: Could it be that that something in the 2.1.5 to 2.1.7 upgrade didn't go right, or that I did something wrong, and somehow 2.1.5's hardcoded collapse_alternatives had taken effect even though 2.1.7's settings said not to collapse? I did restart the qrunner with mailmanctl after the upgrade, but on the other hand, I did install 2.1.7 into the same location where 2.1.5 previously was. Something there might have been the source of the error. ---------------------------------------------------------------------- Comment By: - (psy-q) Date: 2006-03-31 09:04 Message: Logged In: YES user_id=244049 Thanks for clearing that up, you've confirmed most of what I've only had vague suspicions about :) I found out about 2.1.5's hardcoded collapse_alternatives behavior about half an hour after posting my bug, but thanks for confirming it. I feel like a fool at the moment. I just retried this so I could give you example messages, and the behavior has stopped. I reproduced the unwanted filtering for over an hour yesterday, I have no idea why it's working correctly now. Yesterday, I tried about a dozen combinations of filter strings and settings, none of which produced the desired result. In the end, I returned to the configuration that I posted here and performed a final test to verify that the behavior is indeed confusing. Today, I switched my test MTA back on, switched Mailman back on and tried the very same test message as yesterday. Amazingly, it went through exactly as expected. Then I removed text/html from pass_mime_types, and again it behaved exactly as advertised: It let the multipart/alternative message through, kept the text/plain part intact but removed the text/html. This is completely different behavior than I saw yesterday. So now I'm even more confused than before -- In theory, this means that an upgrade to 2.1.7 using this list configuration would make everything work as it should at my site, and it would mean that there is no bug. I will test a bit more thoroughly, I'll remove Mailman and do a vanilla install of 2.1.7 to see if I can get the behavior to show again. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 03:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_id=103 From noreply at sourceforge.net Fri Mar 31 15:24:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 05:24:47 -0800 Subject: [ mailman-Bugs-1462091 ] admin links force me to insecure mode with password Message-ID: Bugs item #1462091, was opened at 2006-03-31 06:24 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=1462091&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: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Trent Larson (trentlarson) Assigned to: Nobody/Anonymous (nobody) Summary: admin links force me to insecure mode with password Initial Comment: I start out in secure mode when I administer my list, but many operations have hard-coded links to HTTP, and then it loses my session information and requires me to login again from that insecure page. In other words, there are many screens that I cannot use without logging in insecurely. Using v 2.1.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_id=103 From noreply at sourceforge.net Fri Mar 31 18:56:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 08:56:26 -0800 Subject: [ mailman-Bugs-1462091 ] admin links force me to insecure mode with password Message-ID: Bugs item #1462091, was opened at 2006-03-31 05:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&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: security/privacy Group: 2.1 (stable) >Status: Pending >Resolution: Invalid Priority: 5 Submitted By: Trent Larson (trentlarson) Assigned to: Nobody/Anonymous (nobody) Summary: admin links force me to insecure mode with password Initial Comment: I start out in secure mode when I administer my list, but many operations have hard-coded links to HTTP, and then it loses my session information and requires me to login again from that insecure page. In other words, there are many screens that I cannot use without logging in insecurely. Using v 2.1.6. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 08:56 Message: Logged In: YES user_id=1123998 This is not a bug. It is a misconfiguration. What you want to do is put DEFAULT_URL_PATTERN = 'https://%s/mailman/' in mm_cfg.py and then run bin/fix_url.py to update your existing lists, e.g. bin/withlist -l -a -r fix_url -- [fix_url options] but first run bin/fix_url.py stand alone for help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_id=103 From noreply at sourceforge.net Fri Mar 31 21:46:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 11:46:48 -0800 Subject: [ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible Message-ID: Bugs item #1461279, was opened at 2006-03-30 02:41 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&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: 2.1 (stable) Status: Closed Resolution: Invalid Priority: 2 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 11:46 Message: Logged In: YES user_id=1123998 "Seems Konqueror messed up the line breaks in my last reply." Actually, it's usually the tracker itself that messes up line breaks. :-( "Could it be that that something in the 2.1.5 to 2.1.7 upgrade didn't go right" When you upgraded from 2.1.5 to 2.1.7 the collapse_alternatives list settings would have been initialized from the DEFAULT_COLLAPSE_ALTERNATIVES in mm_cfg.py/Defaults.py which would have been "Yes" to match pre 2.1.7 behavior unless you had already set it to No in mm_cfg.py, but any subsequent display/change on the admin content filtering page would have shown/set the actual value at that point. ---------------------------------------------------------------------- Comment By: - (psy-q) Date: 2006-03-30 23:22 Message: Logged In: YES user_id=244049 Seems Konqueror messed up the line breaks in my last reply. These last two days are full of cursed software :) I tried a vanilla installation of Mailman 2.1.7, configured the list as described here and everything worked exactly as expected (and advertised). I can't explain where yesterday's behavior came from, and I'm sorry if I caused any confusion. I can only guess: Could it be that that something in the 2.1.5 to 2.1.7 upgrade didn't go right, or that I did something wrong, and somehow 2.1.5's hardcoded collapse_alternatives had taken effect even though 2.1.7's settings said not to collapse? I did restart the qrunner with mailmanctl after the upgrade, but on the other hand, I did install 2.1.7 into the same location where 2.1.5 previously was. Something there might have been the source of the error. ---------------------------------------------------------------------- Comment By: - (psy-q) Date: 2006-03-30 23:04 Message: Logged In: YES user_id=244049 Thanks for clearing that up, you've confirmed most of what I've only had vague suspicions about :) I found out about 2.1.5's hardcoded collapse_alternatives behavior about half an hour after posting my bug, but thanks for confirming it. I feel like a fool at the moment. I just retried this so I could give you example messages, and the behavior has stopped. I reproduced the unwanted filtering for over an hour yesterday, I have no idea why it's working correctly now. Yesterday, I tried about a dozen combinations of filter strings and settings, none of which produced the desired result. In the end, I returned to the configuration that I posted here and performed a final test to verify that the behavior is indeed confusing. Today, I switched my test MTA back on, switched Mailman back on and tried the very same test message as yesterday. Amazingly, it went through exactly as expected. Then I removed text/html from pass_mime_types, and again it behaved exactly as advertised: It let the multipart/alternative message through, kept the text/plain part intact but removed the text/html. This is completely different behavior than I saw yesterday. So now I'm even more confused than before -- In theory, this means that an upgrade to 2.1.7 using this list configuration would make everything work as it should at my site, and it would mean that there is no bug. I will test a bit more thoroughly, I'll remove Mailman and do a vanilla install of 2.1.7 to see if I can get the behavior to show again. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-30 17:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_id=103