Mailman-coders March 2006

mailman-coders@python.org

1 participants
83 discussions

[ mailman-Feature Requests-669056 ] Archive URL in Email

by SourceForge.net

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_i… 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_i…

15 years, 9 months

[ mailman-Feature Requests-1443069 ] If an email is filtered with a SPAM filter, do not reply

by SourceForge.net

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_… 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=1… Thanks Oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1443069&group_…

15 years, 9 months

[ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce

by SourceForge.net

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_… 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(a)example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin(a)example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin(a)example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin(a)example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin(a)example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin(a)example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin(a)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(a)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@... From: MAILER-DAEMON@... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com@... 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 <postmaster> If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program <admin(a)example.com>: 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@... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin(a)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(a)dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman(a)dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman(a)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@... it is scored as a bounce for user(a)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_…

15 years, 9 months

[ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce

by SourceForge.net

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_… 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(a)example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin(a)example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin(a)example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin(a)example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin(a)example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin(a)example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin(a)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(a)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@... From: MAILER-DAEMON@... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com@... 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 <postmaster> If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program <admin(a)example.com>: 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@... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin(a)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(a)dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman(a)dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman(a)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@... it is scored as a bounce for user(a)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_…

15 years, 9 months

[ mailman-Bugs-1421285 ] 2.1.7 (VERP) mistakes delay notice for bounce

by SourceForge.net

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_… 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(a)example.com has stale bounce info, resetting Jan 27 21:57:08 2006 (6794) leafnode-list: admin(a)example.com already scored a bounce for date 27-Jan-2006 Jan 30 18:16:47 2006 (6794) leafnode-list: admin(a)example.com current bounce score: 2.0 Jan 30 19:40:06 2006 (6794) leafnode-list: admin(a)example.com already scored a bounce for date 30-Jan-2006 Feb 01 03:01:40 2006 (6794) leafnode-list: admin(a)example.com current bounce score: 3.0 Feb 01 03:01:41 2006 (6794) leafnode-list: admin(a)example.com disabling due to bounce score 3.0 >= 3.0 Feb 01 03:31:41 2006 (6794) leafnode-list: admin(a)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(a)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@... From: MAILER-DAEMON@... (Mail Delivery System) Subject: Delayed Mail (still being retried) To: leafnode-list-bounces+admin=example.com@... 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 <postmaster> If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program <admin(a)example.com>: 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@... Arrival-Date: Tue, 31 Jan 2006 21:55:44 +0100 (CET) Final-Recipient: rfc822; admin(a)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(a)dt.e-tec] <* mixed> Bounce-Benachrichtigung . 20060201T030141 [ 14: mailman(a)dt.e-tec] <1 text> . 20060201T030141 [ 125: mailman(a)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@... it is scored as a bounce for user(a)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_…

15 years, 9 months

[ mailman-Bugs-1442801 ] ToDigest failing with missing attribute error

by SourceForge.net

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_… 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_…

15 years, 9 months

[ mailman-Bugs-1442801 ] ToDigest failing with missing attribute error

by SourceForge.net

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_… 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_…

15 years, 9 months

[ mailman-Bugs-1442639 ] attachments archived even when archiving disabled

by SourceForge.net

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_… 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/<list>/attachm ents/<yyyymmdd>/<blah> -- 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(a)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/<listname>/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_…

15 years, 9 months

[ mailman-Bugs-1442639 ] attachments archived even when archiving disabled

by SourceForge.net

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_… 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/<list>/attachm ents/<yyyymmdd>/<blah> -- 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(a)eds.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1442639&group_…

15 years, 9 months

[ mailman-Feature Requests-1422113 ] Admin notification on address change

by SourceForge.net

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_… 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_…

15 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders March 2006