Mailman-coders March 2006

mailman-coders@python.org

1 participants
83 discussions

[ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute)

by SourceForge.net

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

15 years, 8 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 (Settings changed) 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: 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(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-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@... 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, 8 months

[ mailman-Bugs-1444447 ] show_qfiles: 'str' object has no attribute 'as_string'

by SourceForge.net

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

15 years, 8 months

[ mailman-Bugs-1446859 ] Posters set to Mod, incorrectly Rejected should be Held

by SourceForge.net

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_… 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- <same>/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 <what a cowboy yells, when he sees a pretty cowgirl(unless it's like Brokeback mountain but you get the gist)>.com read that spammers! ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-09 17:20 Message: Logged In: YES user_id=1123998 <quote> > 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." </quote> 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. <quote> 1- delete all users 2- change the Membership Management/Additional Member tasks/Set everyones moderation from No to On </quote> Which does absolutely nothing at this point besause there are no members to set to 'moderated'. <quote> 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". </quote> And how did steps 1 - 4 produce a moderated member? <quote> 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. </quote> 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_…

15 years, 8 months

[ mailman-Bugs-1446859 ] Posters set to Mod, incorrectly Rejected should be Held

by SourceForge.net

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_… 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- <same>/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 <what a cowboy yells, when he sees a pretty cowgirl(unless it's like Brokeback mountain but you get the gist)>.com read that spammers! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1446859&group_…

15 years, 8 months

[ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute)

by SourceForge.net

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

15 years, 8 months

[ mailman-Bugs-1445630 ] /templates/de/verify.txt: encoding of special chars(umlaute)

by SourceForge.net

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

15 years, 8 months

[ mailman-Bugs-1445366 ] Incorrect HTML generated on Info page

by SourceForge.net

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_… 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 <MM-Subscribe-Form-Start> 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 <MM-Subscribe-Form-Start> tag in the broken HTML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1445366&group_…

15 years, 8 months

[ mailman-Bugs-1445366 ] Incorrect HTML generated on Info page

by SourceForge.net

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

15 years, 8 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 (Comment added) made by grandcross 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: 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_…

15 years, 8 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