From noreply at sourceforge.net Mon Mar 3 09:01:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 00:01:46 -0800 Subject: [ mailman-Bugs-1904737 ] ban_list entry breaks bulk member import Message-ID: Bugs item #1904737, was opened at 2008-02-29 16:14 Message generated for change (Comment added) made by wlanguy2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1904737&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 Private: No Submitted By: Lars K?ller (wlanguy2) Assigned to: Mark Sapiro (msapiro) Summary: ban_list entry breaks bulk member import Initial Comment: Mailman 2.1.9 (python 2.4.4) on Solaris 8 SPARC: When an email address, e.g. dummy at example.com is inserted into the ban_list and the same member is tried to become a regular member, an error is triggered. The is really critical, cause automatically generated bulk imports fail. echo "dummy at example.com" | /usr/local/mailman/current/fhbi/bin/add_members -a n -w n -r - verteiler-zv Traceback (most recent call last): File "/usr/local/mailman/current/fhbi/bin/add_members", line 255, in ? main() File "/usr/local/mailman/current/fhbi/bin/add_members", line 235, in main addall(mlist, nmembers, 0, send_welcome_msg, s) File "/usr/local/mailman/current/fhbi/bin/add_members", line 135, in addall mlist.ApprovedAddMember(userdesc, ack, 0) File "/usr/localhost/mailman/current/fhbi/Mailman/MailList.py", line 958, in ApprovedAddMember raise Errors.MembershipIsBanned, pattern Mailman.Errors.MembershipIsBanned: dummy at example.com Please fix as fast as possible. many thanks and best regards Lars ---------------------------------------------------------------------- >Comment By: Lars K?ller (wlanguy2) Date: 2008-03-03 09:01 Message: Logged In: YES user_id=2003250 Originator: YES Hi "mschapiro" :-) many thanks for the fast delivered fix! Best regards Lars ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-02-29 18:35 Message: Logged In: YES user_id=1123998 Originator: NO Fixed by the attached patch which also fixes sync_members and clone_member. File Added: patch.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1904737&group_id=103 From noreply at sourceforge.net Mon Mar 3 14:27:12 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 05:27:12 -0800 Subject: [ mailman-Patches-1463918 ] Make password mailing RFC 3834 compliant Message-ID: Patches item #1463918, was opened at 2006-04-04 02:24 Message generated for change (Comment added) made by lkoeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1463918&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: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kyle VanderBeek (kylev) Assigned to: Nobody/Anonymous (nobody) Summary: Make password mailing RFC 3834 compliant Initial Comment: RFC 3834 specifies that messages generated automatically by periodic automatic jobs should contain an Auto-Submitted header with a 'auto-generated' value; a 1-line patch does this for the cron'ed month membership reminder. This helps avoid loops and potential "sorcerers apprentice mode" when hitting well mannered vaction programs that recognize RFC 3834 headers. There is probably more work to do in mailman related to this RFC, as well. ---------------------------------------------------------------------- Comment By: Lars K?ller (lkoeller) Date: 2008-03-03 14:27 Message: Logged In: YES user_id=412469 Originator: NO Absolutely usefull feature! Should be implemented as soon as possible!! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1463918&group_id=103 From noreply at sourceforge.net Mon Mar 3 14:35:39 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 05:35:39 -0800 Subject: [ mailman-Patches-1906265 ] Make all outgoing mails RFC 3834 compliant Message-ID: Patches item #1906265, was opened at 2008-03-03 14:35 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=1906265&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 Private: No Submitted By: Lars K?ller (lkoeller) Assigned to: Nobody/Anonymous (nobody) Summary: Make all outgoing mails RFC 3834 compliant Initial Comment: Hi, please make all outgoing mail RFC 3834 compliant, to help reasonable processing in an RFC 3834 compliant MTA. Especially the vacation/autoreply functions of all up to date (e.g. SUN JSMS, Sophos PMX) mail servers respect these header tags and helps keeping the list admin free of managing dump reply mails. Details: http://www.ietf.org/rfc/rfc3834.txt Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&group_id=103 From noreply at sourceforge.net Mon Mar 3 17:20:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 08:20:46 -0800 Subject: [ mailman-Bugs-1906368 ] newlist: preferred_language not put into available_languages Message-ID: Bugs item #1906368, was opened at 2008-03-03 17:20 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=1906368&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 Private: No Submitted By: Marcin Owsiany (porridge) Assigned to: Nobody/Anonymous (nobody) Summary: newlist: preferred_language not put into available_languages Initial Comment: When I run newlist with -l pl, then preferred_language does get set to 'pl', but available_languages is set to just ['en']. This causes two problems for me: - editing the default language on the language properties page gets tricky (you need to apply the settings twice, going through a page in english). - the installation scripts logic in the debian package reads available_languages to find out which language message files to install. Not having the preferred language in the available list means I will have to jump through some extra tricky hoops to get it working properly. Also, the comment in the config file does say that the default language should be in the available languages list, so I guess some assumptions are made in other parts of the codebase, which will cause undesired behavior. I guess the best way to fix this is to create a proper mutator method which will contain some logic to also update the available_languages property if need be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_id=103 From noreply at sourceforge.net Mon Mar 3 17:35:30 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 08:35:30 -0800 Subject: [ mailman-Patches-1906265 ] Make all outgoing mails RFC 3834 compliant Message-ID: Patches item #1906265, was opened at 2008-03-03 08:35 Message generated for change (Comment added) made by jimpop You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&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 Private: No Submitted By: Lars K?ller (lkoeller) Assigned to: Nobody/Anonymous (nobody) Summary: Make all outgoing mails RFC 3834 compliant Initial Comment: Hi, please make all outgoing mail RFC 3834 compliant, to help reasonable processing in an RFC 3834 compliant MTA. Especially the vacation/autoreply functions of all up to date (e.g. SUN JSMS, Sophos PMX) mail servers respect these header tags and helps keeping the list admin free of managing dump reply mails. Details: http://www.ietf.org/rfc/rfc3834.txt Thanks! ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2008-03-03 11:35 Message: Logged In: YES user_id=3142 Originator: NO Care to provide any specifics on just what exactly it is that you deem non-compliant? It's been a while since this debate has seen the light of day.... come prepared. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&group_id=103 From noreply at sourceforge.net Mon Mar 3 18:48:00 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 09:48:00 -0800 Subject: [ mailman-Bugs-1906368 ] newlist: preferred_language not put into available_languages Message-ID: Bugs item #1906368, was opened at 2008-03-03 08:20 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&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 Private: No Submitted By: Marcin Owsiany (porridge) >Assigned to: Mark Sapiro (msapiro) Summary: newlist: preferred_language not put into available_languages Initial Comment: When I run newlist with -l pl, then preferred_language does get set to 'pl', but available_languages is set to just ['en']. This causes two problems for me: - editing the default language on the language properties page gets tricky (you need to apply the settings twice, going through a page in english). - the installation scripts logic in the debian package reads available_languages to find out which language message files to install. Not having the preferred language in the available list means I will have to jump through some extra tricky hoops to get it working properly. Also, the comment in the config file does say that the default language should be in the available languages list, so I guess some assumptions are made in other parts of the codebase, which will cause undesired behavior. I guess the best way to fix this is to create a proper mutator method which will contain some logic to also update the available_languages property if need be. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 09:48 Message: Logged In: YES user_id=1123998 Originator: NO This is a bug in newlist fixed by the attached patch which will be in Mailman 2.1.10. The patch will add the selected language to available_languages if it is other than the server default language. As far as the Debian installation scripts logic is concerned, this is not something that the Mailman project has any control over, but I must not understand correctly in any case. It seems that you are saying that the package will not install any templates or message catalogs for languages that are not listed in available_languages of the existing lists, but this would result in a new installation containg support for only those languages listed as available for the packaged site list if that, so you must be saying something else. File Added: newlist.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_id=103 From noreply at sourceforge.net Mon Mar 3 19:45:27 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 10:45:27 -0800 Subject: [ mailman-Bugs-1906368 ] newlist: preferred_language not put into available_languages Message-ID: Bugs item #1906368, was opened at 2008-03-03 17:20 Message generated for change (Comment added) made by porridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&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 Private: No Submitted By: Marcin Owsiany (porridge) Assigned to: Mark Sapiro (msapiro) Summary: newlist: preferred_language not put into available_languages Initial Comment: When I run newlist with -l pl, then preferred_language does get set to 'pl', but available_languages is set to just ['en']. This causes two problems for me: - editing the default language on the language properties page gets tricky (you need to apply the settings twice, going through a page in english). - the installation scripts logic in the debian package reads available_languages to find out which language message files to install. Not having the preferred language in the available list means I will have to jump through some extra tricky hoops to get it working properly. Also, the comment in the config file does say that the default language should be in the available languages list, so I guess some assumptions are made in other parts of the codebase, which will cause undesired behavior. I guess the best way to fix this is to create a proper mutator method which will contain some logic to also update the available_languages property if need be. ---------------------------------------------------------------------- >Comment By: Marcin Owsiany (porridge) Date: 2008-03-03 19:45 Message: Logged In: YES user_id=1349753 Originator: YES Thanks for the patch and the quick response. This is really impressive! My problem with the debian installation scripts is somewhat complicated. What they do on install/upgrade, is first issue an interactive question for the list of languages to install, and then they automagically add to that list any languages that were not given, but are used by the existing mailing lists. This works fine for most users, but for me it would require some configuration preseeding, when building a machine with a pre-existing /var/lib/mailman (e.g. disaster recovery). Luckily, with your patch it should just do the right thing for me now. thanks again! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 18:48 Message: Logged In: YES user_id=1123998 Originator: NO This is a bug in newlist fixed by the attached patch which will be in Mailman 2.1.10. The patch will add the selected language to available_languages if it is other than the server default language. As far as the Debian installation scripts logic is concerned, this is not something that the Mailman project has any control over, but I must not understand correctly in any case. It seems that you are saying that the package will not install any templates or message catalogs for languages that are not listed in available_languages of the existing lists, but this would result in a new installation containg support for only those languages listed as available for the packaged site list if that, so you must be saying something else. File Added: newlist.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_id=103 From noreply at sourceforge.net Mon Mar 3 20:45:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 11:45:40 -0800 Subject: [ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there Message-ID: Patches item #1906479, was opened at 2008-03-03 20:45 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=1906479&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 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 From noreply at sourceforge.net Mon Mar 3 21:37:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 12:37:25 -0800 Subject: [ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there Message-ID: Patches item #1906479, was opened at 2008-03-03 11:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&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 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 12:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user at example.com configures her MUA to add a Reply-To: user at example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user at example.com. Consider that userb at example.com sets all his MUAs to generate Reply-To: userb at example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 From noreply at sourceforge.net Mon Mar 3 22:15:56 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 13:15:56 -0800 Subject: [ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there Message-ID: Patches item #1906479, was opened at 2008-03-03 20:45 Message generated for change (Comment added) made by auvor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&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 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- >Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 22:15 Message: Logged In: YES user_id=1137196 Originator: YES Of course, this behaviour will fail in some cases, but at least in my environment such problems are rare and easily solvable. The user will quickly realize that something is wrong, ask the more experienced users what is going on, and be told how to resolve their problem. Removing their Reply-To header is easy, and it is a one-time operation. It also works in all MUAs. Also, having to repost the message because you replied to an erroneously set Reply-To header is a minor annoyance for a single person (the poster), who has to repost the message to the list. In the opposite case, with unconditional Reply-To header munging, every misdirected post is an annoyance to the entire list. It also happens every time someone requests off-list replies, instead of just a single time before the user removes his explicit Reply-To header. If one is concerned about such clients one could for instance start with setting first_strip_reply_to to off, and then enable reply_to_only_set_if_empty after some period of time. During the transitional period the users with malconfigured clients will quickly ask why they suddenly receive two copies of all replies. They will then be told to remove their Reply-To header from their client, and will probably do so. This is a minor annoyance to a single person, the one with a malconfigured client. Believe me, there is nothing I'd rather do than disable the munging completely. However, this would not solve anything, only cause even more e-mails to be sent in the wrong direction. Therefore I'd like a milder form of munging, which doesn't discriminate users who know what they're doing. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 21:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user at example.com configures her MUA to add a Reply-To: user at example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user at example.com. Consider that userb at example.com sets all his MUAs to generate Reply-To: userb at example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 From noreply at sourceforge.net Mon Mar 3 22:55:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 13:55:36 -0800 Subject: [ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there Message-ID: Patches item #1906479, was opened at 2008-03-03 11:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&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 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 13:55 Message: Logged In: YES user_id=1123998 Originator: NO You miss my point. Perhaps the first paragraph of my prior comment is a configuration error that can be corrected, but your minimizing the consequences seems to me a lot like an argument against reply-to munging. In any case, configuration mistakes aside, there are people who set a meaningful Reply-To: intentionally just because they want replies to go to somewhere other than the From: address. You are asking that these people remember to drop the Reply-To: whenever they make an 'ordinary' post to the list. This seems to me to be exactly discrimination against users who know what they are doing. The fact is that you cannot determine the poster's intent based on the presence or absence of Reply-To: in the incoming post, and trying to do so may 'solve' some problems but will create others. Also, it is my opinion that I, as the poster of a reply, should be the one to determine whether or not my reply goes to the list. Why would I want to give control over (the default for) that decision to the poster of the message to which I'm replying. ---------------------------------------------------------------------- Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 13:15 Message: Logged In: YES user_id=1137196 Originator: YES Of course, this behaviour will fail in some cases, but at least in my environment such problems are rare and easily solvable. The user will quickly realize that something is wrong, ask the more experienced users what is going on, and be told how to resolve their problem. Removing their Reply-To header is easy, and it is a one-time operation. It also works in all MUAs. Also, having to repost the message because you replied to an erroneously set Reply-To header is a minor annoyance for a single person (the poster), who has to repost the message to the list. In the opposite case, with unconditional Reply-To header munging, every misdirected post is an annoyance to the entire list. It also happens every time someone requests off-list replies, instead of just a single time before the user removes his explicit Reply-To header. If one is concerned about such clients one could for instance start with setting first_strip_reply_to to off, and then enable reply_to_only_set_if_empty after some period of time. During the transitional period the users with malconfigured clients will quickly ask why they suddenly receive two copies of all replies. They will then be told to remove their Reply-To header from their client, and will probably do so. This is a minor annoyance to a single person, the one with a malconfigured client. Believe me, there is nothing I'd rather do than disable the munging completely. However, this would not solve anything, only cause even more e-mails to be sent in the wrong direction. Therefore I'd like a milder form of munging, which doesn't discriminate users who know what they're doing. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 12:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user at example.com configures her MUA to add a Reply-To: user at example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user at example.com. Consider that userb at example.com sets all his MUAs to generate Reply-To: userb at example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 From noreply at sourceforge.net Mon Mar 3 23:34:20 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 14:34:20 -0800 Subject: [ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there Message-ID: Patches item #1906479, was opened at 2008-03-03 20:45 Message generated for change (Comment added) made by auvor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&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 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- >Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 23:34 Message: Logged In: YES user_id=1137196 Originator: YES I understand that you do not like header munging. I don't either. However, a lot of people seem to depend on it, and quite a few of them are on my server. Unfortionately, the lists on my server are not only used for general discussion, but also for requests that should be responded to off-list. With my user base, some level of reply-to munging is simply unavoidable, whether I like it or not. I would just like a way to make it less of an obstacle for the remaining parts of the user base. I understand your objections, and I see that they could cause problems in some scenarios. However, they would not cause problems in my case. I don't believe chit-chat lists of this kind are very unusual, so I believe other people than me also could use this feature. Hence the patch. I am only proposing an option. It will be off by default. Please consider it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 22:55 Message: Logged In: YES user_id=1123998 Originator: NO You miss my point. Perhaps the first paragraph of my prior comment is a configuration error that can be corrected, but your minimizing the consequences seems to me a lot like an argument against reply-to munging. In any case, configuration mistakes aside, there are people who set a meaningful Reply-To: intentionally just because they want replies to go to somewhere other than the From: address. You are asking that these people remember to drop the Reply-To: whenever they make an 'ordinary' post to the list. This seems to me to be exactly discrimination against users who know what they are doing. The fact is that you cannot determine the poster's intent based on the presence or absence of Reply-To: in the incoming post, and trying to do so may 'solve' some problems but will create others. Also, it is my opinion that I, as the poster of a reply, should be the one to determine whether or not my reply goes to the list. Why would I want to give control over (the default for) that decision to the poster of the message to which I'm replying. ---------------------------------------------------------------------- Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 22:15 Message: Logged In: YES user_id=1137196 Originator: YES Of course, this behaviour will fail in some cases, but at least in my environment such problems are rare and easily solvable. The user will quickly realize that something is wrong, ask the more experienced users what is going on, and be told how to resolve their problem. Removing their Reply-To header is easy, and it is a one-time operation. It also works in all MUAs. Also, having to repost the message because you replied to an erroneously set Reply-To header is a minor annoyance for a single person (the poster), who has to repost the message to the list. In the opposite case, with unconditional Reply-To header munging, every misdirected post is an annoyance to the entire list. It also happens every time someone requests off-list replies, instead of just a single time before the user removes his explicit Reply-To header. If one is concerned about such clients one could for instance start with setting first_strip_reply_to to off, and then enable reply_to_only_set_if_empty after some period of time. During the transitional period the users with malconfigured clients will quickly ask why they suddenly receive two copies of all replies. They will then be told to remove their Reply-To header from their client, and will probably do so. This is a minor annoyance to a single person, the one with a malconfigured client. Believe me, there is nothing I'd rather do than disable the munging completely. However, this would not solve anything, only cause even more e-mails to be sent in the wrong direction. Therefore I'd like a milder form of munging, which doesn't discriminate users who know what they're doing. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 21:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user at example.com configures her MUA to add a Reply-To: user at example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user at example.com. Consider that userb at example.com sets all his MUAs to generate Reply-To: userb at example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 From noreply at sourceforge.net Tue Mar 4 00:11:38 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 15:11:38 -0800 Subject: [ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there Message-ID: Patches item #1906479, was opened at 2008-03-03 11:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&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 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 15:11 Message: Logged In: YES user_id=1123998 Originator: NO That's the beauty of FOSS. You had a problem and you solved it. I don't think your solution is of sufficient general applicability to warrant adding yet another configuration option. If others disagree, they are encouraged to comment and perhaps convince me that I'm wrong. ---------------------------------------------------------------------- Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 14:34 Message: Logged In: YES user_id=1137196 Originator: YES I understand that you do not like header munging. I don't either. However, a lot of people seem to depend on it, and quite a few of them are on my server. Unfortionately, the lists on my server are not only used for general discussion, but also for requests that should be responded to off-list. With my user base, some level of reply-to munging is simply unavoidable, whether I like it or not. I would just like a way to make it less of an obstacle for the remaining parts of the user base. I understand your objections, and I see that they could cause problems in some scenarios. However, they would not cause problems in my case. I don't believe chit-chat lists of this kind are very unusual, so I believe other people than me also could use this feature. Hence the patch. I am only proposing an option. It will be off by default. Please consider it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 13:55 Message: Logged In: YES user_id=1123998 Originator: NO You miss my point. Perhaps the first paragraph of my prior comment is a configuration error that can be corrected, but your minimizing the consequences seems to me a lot like an argument against reply-to munging. In any case, configuration mistakes aside, there are people who set a meaningful Reply-To: intentionally just because they want replies to go to somewhere other than the From: address. You are asking that these people remember to drop the Reply-To: whenever they make an 'ordinary' post to the list. This seems to me to be exactly discrimination against users who know what they are doing. The fact is that you cannot determine the poster's intent based on the presence or absence of Reply-To: in the incoming post, and trying to do so may 'solve' some problems but will create others. Also, it is my opinion that I, as the poster of a reply, should be the one to determine whether or not my reply goes to the list. Why would I want to give control over (the default for) that decision to the poster of the message to which I'm replying. ---------------------------------------------------------------------- Comment By: Knut Auvor Grythe (auvor) Date: 2008-03-03 13:15 Message: Logged In: YES user_id=1137196 Originator: YES Of course, this behaviour will fail in some cases, but at least in my environment such problems are rare and easily solvable. The user will quickly realize that something is wrong, ask the more experienced users what is going on, and be told how to resolve their problem. Removing their Reply-To header is easy, and it is a one-time operation. It also works in all MUAs. Also, having to repost the message because you replied to an erroneously set Reply-To header is a minor annoyance for a single person (the poster), who has to repost the message to the list. In the opposite case, with unconditional Reply-To header munging, every misdirected post is an annoyance to the entire list. It also happens every time someone requests off-list replies, instead of just a single time before the user removes his explicit Reply-To header. If one is concerned about such clients one could for instance start with setting first_strip_reply_to to off, and then enable reply_to_only_set_if_empty after some period of time. During the transitional period the users with malconfigured clients will quickly ask why they suddenly receive two copies of all replies. They will then be told to remove their Reply-To header from their client, and will probably do so. This is a minor annoyance to a single person, the one with a malconfigured client. Believe me, there is nothing I'd rather do than disable the munging completely. However, this would not solve anything, only cause even more e-mails to be sent in the wrong direction. Therefore I'd like a milder form of munging, which doesn't discriminate users who know what they're doing. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 12:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user at example.com configures her MUA to add a Reply-To: user at example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user at example.com. Consider that userb at example.com sets all his MUAs to generate Reply-To: userb at example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_id=103 From noreply at sourceforge.net Tue Mar 4 07:47:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2008 22:47:15 -0800 Subject: [ mailman-Patches-1906265 ] Make all outgoing mails RFC 3834 compliant Message-ID: Patches item #1906265, was opened at 2008-03-03 14:35 Message generated for change (Comment added) made by lkoeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&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 Private: No Submitted By: Lars K?ller (lkoeller) Assigned to: Nobody/Anonymous (nobody) Summary: Make all outgoing mails RFC 3834 compliant Initial Comment: Hi, please make all outgoing mail RFC 3834 compliant, to help reasonable processing in an RFC 3834 compliant MTA. Especially the vacation/autoreply functions of all up to date (e.g. SUN JSMS, Sophos PMX) mail servers respect these header tags and helps keeping the list admin free of managing dump reply mails. Details: http://www.ietf.org/rfc/rfc3834.txt Thanks! ---------------------------------------------------------------------- >Comment By: Lars K?ller (lkoeller) Date: 2008-03-04 07:47 Message: Logged In: YES user_id=412469 Originator: YES Most of the automatic processing mail engines like autoresponder/vacation/SPAM-digest systems respect RFC 3834 mail header. So it is useful to add the RFC 3834 headers to any auto generated mail Mailman sends out, e.g.: subscribe, unsubscribe messages, password reminders, and perhaps any regular distributed post to the list (see rfc and search for list), cause it makes no sense to send back e.g. a vacation message to the originatin mail list for any of these types of messages. For the right header tags and details see the rfc 3834. The presence of the casual List-..... headers are not sufficient so far. Hope this helps ... :-) ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2008-03-03 17:35 Message: Logged In: YES user_id=3142 Originator: NO Care to provide any specifics on just what exactly it is that you deem non-compliant? It's been a while since this debate has seen the light of day.... come prepared. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&group_id=103 From noreply at sourceforge.net Tue Mar 4 12:33:09 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2008 03:33:09 -0800 Subject: [ mailman-Bugs-1906925 ] Return of bug #835036, Errors.MMAlreadyAMember Message-ID: Bugs item #1906925, was opened at 2008-03-04 12:33 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=1906925&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Nobody/Anonymous (nobody) Summary: Return of bug #835036, Errors.MMAlreadyAMember Initial Comment: This seems to be the same or very similar to bug #835036, which was supposedly fixed in 2.1.4. We got the following running 2.1.9: Mar 02 23:47:25 2008 admin(2617): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(2617): [----- Mailman Version: 2.1.9 -----] admin(2617): [----- Traceback ------] admin(2617): Traceback (most recent call last): admin(2617): File "/usr/lib/mailman/scripts/driver", line 101, in run_main admin(2617): main() admin(2617): File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 138, in main admin(2617): addrchange_confirm(mlist, doc, cookie) admin(2617): File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 521, in addrchange_confirm admin(2617): op, oldaddr, newaddr = mlist.ProcessConfirmation(cookie) admin(2617): File "/usr/lib/mailman/Mailman/MailList.py", line 1217, in ProcessConfirmation admin(2617): self.ApprovedChangeMemberAddress(oldaddr, newaddr, globally) admin(2617): File "/usr/lib/mailman/Mailman/MailList.py", line 1127, in ApprovedChangeMemberAddress admin(2617): self.changeMemberAddress(oldaddr, newaddr) admin(2617): File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 251, in changeMemberAddress admin(2617): password=password, language=lang) admin(2617): File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 175, in addNewMember admin(2617): raise Errors.MMAlreadyAMember, member admin(2617): MMAlreadyAMember: cogel at uni-koeln.de admin(2617): [----- Python Information -----] admin(2617): sys.version = 2.2.3 (#1, Nov 20 2007, 10:35:51) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-58)] admin(2617): sys.executable = /usr/bin/python admin(2617): sys.prefix = /usr admin(2617): sys.exec_prefix = /usr admin(2617): sys.path = /usr admin(2617): sys.platform = linux2 admin(2617): [----- Environment Variables -----] admin(2617): PATH_INFO: /rrzk-alle admin(2617): CONTENT_LENGTH: 71 admin(2617): SERVER_PORT: 443 admin(2617): HTTP_COOKIE: rrzk-alle+user+a0537--at--uni-koeln.de=2802000000693b2ecb4773280000006334633034373836316566 6166316665343032336164636566383561623361653764643930653462 admin(2617): SCRIPT_FILENAME: /usr/lib/mailman/cgi-bin/confirm admin(2617): PYTHONPATH: /usr/lib/mailman admin(2617): SERVER_SOFTWARE: Apache/2.0.46 (Red Hat) admin(2617): SERVER_ADMIN: postmaster at rrz.uni-koeln.de admin(2617): SCRIPT_NAME: /mailman/confirm admin(2617): SERVER_SIGNATURE:
Apache/2.0.46 (Red Hat) Server at lists.uni-koeln.de Port 443
admin(2617): admin(2617): REQUEST_METHOD: POST admin(2617): HTTP_HOST: lists.uni-koeln.de admin(2617): HTTP_KEEP_ALIVE: 300 admin(2617): HTTPS: on admin(2617): SERVER_PROTOCOL: HTTP/1.1 admin(2617): QUERY_STRING: admin(2617): PATH_TRANSLATED: /var/lib/mailman/httpd/docs/rrzk-alle admin(2617): HTTP_ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,* /*;q=0.5 admin(2617): HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 admin(2617): HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 admin(2617): HTTP_CONNECTION: keep-alive admin(2617): HTTP_REFERER: https://lists.uni-koeln.de/mailman/confirm/rrzk-alle/1ec33017837b4133f482c56c00c9034984e9a 9c7 admin(2617): SERVER_NAME: lists.uni-koeln.de admin(2617): REMOTE_ADDR: 80.135.230.145 admin(2617): REMOTE_PORT: 34201 admin(2617): HTTP_ACCEPT_LANGUAGE: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 admin(2617): UNIQUE_ID: Dh1Ol4ZfE0AAAC8-blMAAAAH admin(2617): CONTENT_TYPE: application/x-www-form-urlencoded admin(2617): GATEWAY_INTERFACE: CGI/1.1 admin(2617): HTTP_ACCEPT_ENCODING: gzip,deflate admin(2617): SERVER_ADDR: 134.95.19.37 admin(2617): DOCUMENT_ROOT: /var/lib/mailman/httpd/docs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906925&group_id=103 From noreply at sourceforge.net Tue Mar 4 18:16:04 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2008 09:16:04 -0800 Subject: [ mailman-Bugs-1906925 ] Return of bug #835036, Errors.MMAlreadyAMember Message-ID: Bugs item #1906925, was opened at 2008-03-04 03:33 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906925&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) >Assigned to: Mark Sapiro (msapiro) Summary: Return of bug #835036, Errors.MMAlreadyAMember Initial Comment: This seems to be the same or very similar to bug #835036, which was supposedly fixed in 2.1.4. We got the following running 2.1.9: Mar 02 23:47:25 2008 admin(2617): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(2617): [----- Mailman Version: 2.1.9 -----] admin(2617): [----- Traceback ------] admin(2617): Traceback (most recent call last): admin(2617): File "/usr/lib/mailman/scripts/driver", line 101, in run_main admin(2617): main() admin(2617): File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 138, in main admin(2617): addrchange_confirm(mlist, doc, cookie) admin(2617): File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 521, in addrchange_confirm admin(2617): op, oldaddr, newaddr = mlist.ProcessConfirmation(cookie) admin(2617): File "/usr/lib/mailman/Mailman/MailList.py", line 1217, in ProcessConfirmation admin(2617): self.ApprovedChangeMemberAddress(oldaddr, newaddr, globally) admin(2617): File "/usr/lib/mailman/Mailman/MailList.py", line 1127, in ApprovedChangeMemberAddress admin(2617): self.changeMemberAddress(oldaddr, newaddr) admin(2617): File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 251, in changeMemberAddress admin(2617): password=password, language=lang) admin(2617): File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 175, in addNewMember admin(2617): raise Errors.MMAlreadyAMember, member admin(2617): MMAlreadyAMember: cogel at uni-koeln.de admin(2617): [----- Python Information -----] admin(2617): sys.version = 2.2.3 (#1, Nov 20 2007, 10:35:51) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-58)] admin(2617): sys.executable = /usr/bin/python admin(2617): sys.prefix = /usr admin(2617): sys.exec_prefix = /usr admin(2617): sys.path = /usr admin(2617): sys.platform = linux2 admin(2617): [----- Environment Variables -----] admin(2617): PATH_INFO: /rrzk-alle admin(2617): CONTENT_LENGTH: 71 admin(2617): SERVER_PORT: 443 admin(2617): HTTP_COOKIE: rrzk-alle+user+a0537--at--uni-koeln.de=2802000000693b2ecb4773280000006334633034373836316566 6166316665343032336164636566383561623361653764643930653462 admin(2617): SCRIPT_FILENAME: /usr/lib/mailman/cgi-bin/confirm admin(2617): PYTHONPATH: /usr/lib/mailman admin(2617): SERVER_SOFTWARE: Apache/2.0.46 (Red Hat) admin(2617): SERVER_ADMIN: postmaster at rrz.uni-koeln.de admin(2617): SCRIPT_NAME: /mailman/confirm admin(2617): SERVER_SIGNATURE:
Apache/2.0.46 (Red Hat) Server at lists.uni-koeln.de Port 443
admin(2617): admin(2617): REQUEST_METHOD: POST admin(2617): HTTP_HOST: lists.uni-koeln.de admin(2617): HTTP_KEEP_ALIVE: 300 admin(2617): HTTPS: on admin(2617): SERVER_PROTOCOL: HTTP/1.1 admin(2617): QUERY_STRING: admin(2617): PATH_TRANSLATED: /var/lib/mailman/httpd/docs/rrzk-alle admin(2617): HTTP_ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,* /*;q=0.5 admin(2617): HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 admin(2617): HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 admin(2617): HTTP_CONNECTION: keep-alive admin(2617): HTTP_REFERER: https://lists.uni-koeln.de/mailman/confirm/rrzk-alle/1ec33017837b4133f482c56c00c9034984e9a 9c7 admin(2617): SERVER_NAME: lists.uni-koeln.de admin(2617): REMOTE_ADDR: 80.135.230.145 admin(2617): REMOTE_PORT: 34201 admin(2617): HTTP_ACCEPT_LANGUAGE: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 admin(2617): UNIQUE_ID: Dh1Ol4ZfE0AAAC8-blMAAAAH admin(2617): CONTENT_TYPE: application/x-www-form-urlencoded admin(2617): GATEWAY_INTERFACE: CGI/1.1 admin(2617): HTTP_ACCEPT_ENCODING: gzip,deflate admin(2617): SERVER_ADDR: 134.95.19.37 admin(2617): DOCUMENT_ROOT: /var/lib/mailman/httpd/docs ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-04 09:16 Message: Logged In: YES user_id=1123998 Originator: NO It is the same as 835036 which was never completely fixed. Coincidently, I just fixed this last week for 2.1.10. I have attached a patch for 2.1.9. File Added: MailList.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906925&group_id=103 From noreply at sourceforge.net Wed Mar 5 17:02:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 08:02:44 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 17:02 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=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Nobody/Anonymous (nobody) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Wed Mar 5 17:14:00 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 08:14:00 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 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=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) >Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Wed Mar 5 17:19:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 08:19:36 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 17:02 Message generated for change (Comment added) made by shagedorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Wed Mar 5 17:22:56 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 08:22:56 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 17:02 Message generated for change (Comment added) made by shagedorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Wed Mar 5 17:47:50 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 08:47:50 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 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=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:47 Message: Logged In: YES user_id=1123998 Originator: NO The queue entry you attached is not the one from the reported traceback and it seems to have a different problem. When I attempt to look at it with bin/dumpdb or bin/show_qfiles, I get UnicodeEncodeError: 'ascii' codec can't encode character u'\uc774' in position 0: ordinal not in range(128) in a different part of Generator.py. I see that you see the same. What is your Mailman version? Also, if I look at the contents of the queue entry, it appears to be a password reminder which is strange. I don't have time to look at this further right now, but if you can, can you find the 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck and attach that. Also, is the error in Mailman's error log for the 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck file the same UnicodeEncodeError that you get from show_qfiles and dumpdb, or is it the TypeError as in the original report? ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Wed Mar 5 17:58:08 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 08:58:08 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 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=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:58 Message: Logged In: YES user_id=1123998 Originator: NO The file you attached appears to be a password reminder with a lot of garbled unicode. Have you changed the characterset for the german language to utf-8? There is some issue with the templates/de/cronpass.txt template or a list specific version of it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:47 Message: Logged In: YES user_id=1123998 Originator: NO The queue entry you attached is not the one from the reported traceback and it seems to have a different problem. When I attempt to look at it with bin/dumpdb or bin/show_qfiles, I get UnicodeEncodeError: 'ascii' codec can't encode character u'\uc774' in position 0: ordinal not in range(128) in a different part of Generator.py. I see that you see the same. What is your Mailman version? Also, if I look at the contents of the queue entry, it appears to be a password reminder which is strange. I don't have time to look at this further right now, but if you can, can you find the 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck and attach that. Also, is the error in Mailman's error log for the 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck file the same UnicodeEncodeError that you get from show_qfiles and dumpdb, or is it the TypeError as in the original report? ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Thu Mar 6 06:55:16 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2008 21:55:16 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 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=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 21:55 Message: Logged In: YES user_id=1123998 Originator: NO I have looked further at the shunt queue entry 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck. Here's what I see. This message was a password reminder, originally generated by mailman on May 1, 2006. It was addressed to a user whose preferred language appears to be Korean as it is 'Content-Type: text/plain, charset="euc-kr"' with 'Subject: =?euc-kr?q?uni-koeln=2Ede_mailing_list_memberships_reminder?='. Apparently there was some error at that time which caused the message to be shunted. I am a bit confused about what happened next because the time stamp on the queue entry and the received_time in the message's metadata are 1167220351.925714 which is 11:52:31 Dec 27, 2006 +0000. However, the message metadata says the message was originally in the 'in' queue, so I think it must have been unshunted to the 'in' queue where it couldn't be properly processed, causing it to be shunted again in December, 2006. The question now is what is causing these messages to be reprocessed at this point, and why would a message that threw an exception in trying to flatten the message in SpamDetect be shunted with a 14+ month old time stamp? In any case, I think the current error with this particular message is due to it's being unshunted to the wrong queue. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:58 Message: Logged In: YES user_id=1123998 Originator: NO The file you attached appears to be a password reminder with a lot of garbled unicode. Have you changed the characterset for the german language to utf-8? There is some issue with the templates/de/cronpass.txt template or a list specific version of it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:47 Message: Logged In: YES user_id=1123998 Originator: NO The queue entry you attached is not the one from the reported traceback and it seems to have a different problem. When I attempt to look at it with bin/dumpdb or bin/show_qfiles, I get UnicodeEncodeError: 'ascii' codec can't encode character u'\uc774' in position 0: ordinal not in range(128) in a different part of Generator.py. I see that you see the same. What is your Mailman version? Also, if I look at the contents of the queue entry, it appears to be a password reminder which is strange. I don't have time to look at this further right now, but if you can, can you find the 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck and attach that. Also, is the error in Mailman's error log for the 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck file the same UnicodeEncodeError that you get from show_qfiles and dumpdb, or is it the TypeError as in the original report? ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Thu Mar 6 09:31:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2008 00:31:36 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 17:02 Message generated for change (Comment added) made by shagedorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-06 09:31 Message: Logged In: YES user_id=309132 Originator: YES Hi, thanks for looking into this. To address your questions: - we are running 2.1.9 - we have a cronjob in cron.daily that does an "unshunt" - the file I mentioned originally doesn't exist anymore (because it has been unshunted?) - the file I attached had this error message: Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Mar 05 07:56:19 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 05 07:56:19 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) ... So the error is different from what I see with show_qfiles. - We have not modified the charset of German to UTF-8 Now my question is whether the "unshunt" cron job is evil? I confess I never properly understood how it works. It seemed to get messages delivered that were shunted originally, so at some point I set up that cronjob ... I suppose I should just remove all files that are too old. But: how do I see the contents when show_qfiles does not work? Are there other tools? Thanks for all your help! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-06 06:55 Message: Logged In: YES user_id=1123998 Originator: NO I have looked further at the shunt queue entry 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck. Here's what I see. This message was a password reminder, originally generated by mailman on May 1, 2006. It was addressed to a user whose preferred language appears to be Korean as it is 'Content-Type: text/plain, charset="euc-kr"' with 'Subject: =?euc-kr?q?uni-koeln=2Ede_mailing_list_memberships_reminder?='. Apparently there was some error at that time which caused the message to be shunted. I am a bit confused about what happened next because the time stamp on the queue entry and the received_time in the message's metadata are 1167220351.925714 which is 11:52:31 Dec 27, 2006 +0000. However, the message metadata says the message was originally in the 'in' queue, so I think it must have been unshunted to the 'in' queue where it couldn't be properly processed, causing it to be shunted again in December, 2006. The question now is what is causing these messages to be reprocessed at this point, and why would a message that threw an exception in trying to flatten the message in SpamDetect be shunted with a 14+ month old time stamp? In any case, I think the current error with this particular message is due to it's being unshunted to the wrong queue. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:58 Message: Logged In: YES user_id=1123998 Originator: NO The file you attached appears to be a password reminder with a lot of garbled unicode. Have you changed the characterset for the german language to utf-8? There is some issue with the templates/de/cronpass.txt template or a list specific version of it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:47 Message: Logged In: YES user_id=1123998 Originator: NO The queue entry you attached is not the one from the reported traceback and it seems to have a different problem. When I attempt to look at it with bin/dumpdb or bin/show_qfiles, I get UnicodeEncodeError: 'ascii' codec can't encode character u'\uc774' in position 0: ordinal not in range(128) in a different part of Generator.py. I see that you see the same. What is your Mailman version? Also, if I look at the contents of the queue entry, it appears to be a password reminder which is strange. I don't have time to look at this further right now, but if you can, can you find the 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck and attach that. Also, is the error in Mailman's error log for the 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck file the same UnicodeEncodeError that you get from show_qfiles and dumpdb, or is it the TypeError as in the original report? ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Thu Mar 6 19:09:52 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2008 10:09:52 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 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=1908112&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 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-06 10:09 Message: Logged In: YES user_id=1123998 Originator: NO Thanks for the followup information. I have attached a small script which will work to obtain information from a shunted queue entry when bin/show_qfiles and bin/dumpdb throw exceptions. This script is not very robust and has only been tested on the single queue entry attached to this report, but it shold report at least some information from the queue entry. The script should be put in Mailman's bin directory and then run via bin/dump_qfile path/to/shunted/.....pck And yes, running unshunt in a daily cron is a very bad idea. At best, this will just fill up your error log with errors relating to the unshunting. I suggest that instead of doing this, you first remove from the shunt queue, any messages that can't be dumped by bin/show_qfiles or bin/dumpdb, as these can never be successfully unshunted anyway. Then you look at the rest of the messages and remove any that aren't current. Then if there are any left, you can try to unshunt those once, and if the unshunting fails (i.e. if they just get shunted again), proceed as if they are new as I describe below. What you should run as a daily cron, is a script to look at your logs and queues and mail you a report. An excellent script is at . If you don't want as much information as this produces, as a minimum you could just 'ls -l /path/to/qfiles/*'. This in itself will tell you if there are shunted messages and if any queues are backing up because their runner has died. Then if you find one or more shunted messages, you have to look at the error log and the message to figure out the problem. It could be something bad about the message itself, a Mailman bug, some list issue, some transient problem, or some system configuration issue. It is generally not helpful to try to unshunt the message without first addressing the cause. If you can't figure out the cause, you can post to mailman-users at python.org for help. File Added: dump_qfile ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-06 00:31 Message: Logged In: YES user_id=309132 Originator: YES Hi, thanks for looking into this. To address your questions: - we are running 2.1.9 - we have a cronjob in cron.daily that does an "unshunt" - the file I mentioned originally doesn't exist anymore (because it has been unshunted?) - the file I attached had this error message: Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Mar 05 07:56:19 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 05 07:56:19 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) ... So the error is different from what I see with show_qfiles. - We have not modified the charset of German to UTF-8 Now my question is whether the "unshunt" cron job is evil? I confess I never properly understood how it works. It seemed to get messages delivered that were shunted originally, so at some point I set up that cronjob ... I suppose I should just remove all files that are too old. But: how do I see the contents when show_qfiles does not work? Are there other tools? Thanks for all your help! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 21:55 Message: Logged In: YES user_id=1123998 Originator: NO I have looked further at the shunt queue entry 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck. Here's what I see. This message was a password reminder, originally generated by mailman on May 1, 2006. It was addressed to a user whose preferred language appears to be Korean as it is 'Content-Type: text/plain, charset="euc-kr"' with 'Subject: =?euc-kr?q?uni-koeln=2Ede_mailing_list_memberships_reminder?='. Apparently there was some error at that time which caused the message to be shunted. I am a bit confused about what happened next because the time stamp on the queue entry and the received_time in the message's metadata are 1167220351.925714 which is 11:52:31 Dec 27, 2006 +0000. However, the message metadata says the message was originally in the 'in' queue, so I think it must have been unshunted to the 'in' queue where it couldn't be properly processed, causing it to be shunted again in December, 2006. The question now is what is causing these messages to be reprocessed at this point, and why would a message that threw an exception in trying to flatten the message in SpamDetect be shunted with a 14+ month old time stamp? In any case, I think the current error with this particular message is due to it's being unshunted to the wrong queue. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:58 Message: Logged In: YES user_id=1123998 Originator: NO The file you attached appears to be a password reminder with a lot of garbled unicode. Have you changed the characterset for the german language to utf-8? There is some issue with the templates/de/cronpass.txt template or a list specific version of it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:47 Message: Logged In: YES user_id=1123998 Originator: NO The queue entry you attached is not the one from the reported traceback and it seems to have a different problem. When I attempt to look at it with bin/dumpdb or bin/show_qfiles, I get UnicodeEncodeError: 'ascii' codec can't encode character u'\uc774' in position 0: ordinal not in range(128) in a different part of Generator.py. I see that you see the same. What is your Mailman version? Also, if I look at the contents of the queue entry, it appears to be a password reminder which is strange. I don't have time to look at this further right now, but if you can, can you find the 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck and attach that. Also, is the error in Mailman's error log for the 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck file the same UnicodeEncodeError that you get from show_qfiles and dumpdb, or is it the TypeError as in the original report? ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 08:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 08:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Fri Mar 7 11:19:32 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2008 02:19:32 -0800 Subject: [ mailman-Bugs-1908112 ] Uncaught runner exception: iteration over non-sequence Message-ID: Bugs item #1908112, was opened at 2008-03-05 17:02 Message generated for change (Comment added) made by shagedorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&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: None Priority: 5 Private: No Submitted By: Sebastian Hagedorn (shagedorn) Assigned to: Mark Sapiro (msapiro) Summary: Uncaught runner exception: iteration over non-sequence Initial Comment: I don't normally check /var/log/mailman/error as long as everything seems to be working, but today I noticed loads of errors like this one: Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 04 07:50:44 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 04 07:50:44 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, 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/SpamDetect.py", line 111, in process g.flatten(p) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 293, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 226, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 273, in _handle_message_delivery_status g.flatten(part, unixfrom=False) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 270, in _handle_message_delivery_status for part in msg.get_payload(): TypeError: iteration over non-sequence I can provide more samples if necessary. I have searched the tracker for other reports like this, but haven't seen any ... ---------------------------------------------------------------------- >Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-07 11:19 Message: Logged In: YES user_id=309132 Originator: YES Thanks again for your help. It's appreciated. I have removed the cron job. Then I took care of the backlog of shunted messages. Initially there were 326 shunted messages. I wrote a script that deleted all that show_qfiles returned an error for. That brought it down to 243. I looked at all of those. All of them were from December 2006. I have no idea what was going on back then, but it doesn't really matter now. So now we're starting with a clean slate. As for mmdsr, we've been running that for a few weeks, but up to now there were just too many errors due to the backlog. I'm hoping that going forward we will take care of all errors as they happen. I will post follow-up questions to mailman-users ... ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-06 19:09 Message: Logged In: YES user_id=1123998 Originator: NO Thanks for the followup information. I have attached a small script which will work to obtain information from a shunted queue entry when bin/show_qfiles and bin/dumpdb throw exceptions. This script is not very robust and has only been tested on the single queue entry attached to this report, but it shold report at least some information from the queue entry. The script should be put in Mailman's bin directory and then run via bin/dump_qfile path/to/shunted/.....pck And yes, running unshunt in a daily cron is a very bad idea. At best, this will just fill up your error log with errors relating to the unshunting. I suggest that instead of doing this, you first remove from the shunt queue, any messages that can't be dumped by bin/show_qfiles or bin/dumpdb, as these can never be successfully unshunted anyway. Then you look at the rest of the messages and remove any that aren't current. Then if there are any left, you can try to unshunt those once, and if the unshunting fails (i.e. if they just get shunted again), proceed as if they are new as I describe below. What you should run as a daily cron, is a script to look at your logs and queues and mail you a report. An excellent script is at . If you don't want as much information as this produces, as a minimum you could just 'ls -l /path/to/qfiles/*'. This in itself will tell you if there are shunted messages and if any queues are backing up because their runner has died. Then if you find one or more shunted messages, you have to look at the error log and the message to figure out the problem. It could be something bad about the message itself, a Mailman bug, some list issue, some transient problem, or some system configuration issue. It is generally not helpful to try to unshunt the message without first addressing the cause. If you can't figure out the cause, you can post to mailman-users at python.org for help. File Added: dump_qfile ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-06 09:31 Message: Logged In: YES user_id=309132 Originator: YES Hi, thanks for looking into this. To address your questions: - we are running 2.1.9 - we have a cronjob in cron.daily that does an "unshunt" - the file I mentioned originally doesn't exist anymore (because it has been unshunted?) - the file I attached had this error message: Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Mar 05 07:56:19 2008 (4711) Uncaught runner exception: iteration over non-sequence Mar 05 07:56:19 2008 (4711) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) ... So the error is different from what I see with show_qfiles. - We have not modified the charset of German to UTF-8 Now my question is whether the "unshunt" cron job is evil? I confess I never properly understood how it works. It seemed to get messages delivered that were shunted originally, so at some point I set up that cronjob ... I suppose I should just remove all files that are too old. But: how do I see the contents when show_qfiles does not work? Are there other tools? Thanks for all your help! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-06 06:55 Message: Logged In: YES user_id=1123998 Originator: NO I have looked further at the shunt queue entry 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck. Here's what I see. This message was a password reminder, originally generated by mailman on May 1, 2006. It was addressed to a user whose preferred language appears to be Korean as it is 'Content-Type: text/plain, charset="euc-kr"' with 'Subject: =?euc-kr?q?uni-koeln=2Ede_mailing_list_memberships_reminder?='. Apparently there was some error at that time which caused the message to be shunted. I am a bit confused about what happened next because the time stamp on the queue entry and the received_time in the message's metadata are 1167220351.925714 which is 11:52:31 Dec 27, 2006 +0000. However, the message metadata says the message was originally in the 'in' queue, so I think it must have been unshunted to the 'in' queue where it couldn't be properly processed, causing it to be shunted again in December, 2006. The question now is what is causing these messages to be reprocessed at this point, and why would a message that threw an exception in trying to flatten the message in SpamDetect be shunted with a 14+ month old time stamp? In any case, I think the current error with this particular message is due to it's being unshunted to the wrong queue. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:58 Message: Logged In: YES user_id=1123998 Originator: NO The file you attached appears to be a password reminder with a lot of garbled unicode. Have you changed the characterset for the german language to utf-8? There is some issue with the templates/de/cronpass.txt template or a list specific version of it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:47 Message: Logged In: YES user_id=1123998 Originator: NO The queue entry you attached is not the one from the reported traceback and it seems to have a different problem. When I attempt to look at it with bin/dumpdb or bin/show_qfiles, I get UnicodeEncodeError: 'ascii' codec can't encode character u'\uc774' in position 0: ordinal not in range(128) in a different part of Generator.py. I see that you see the same. What is your Mailman version? Also, if I look at the contents of the queue entry, it appears to be a password reminder which is strange. I don't have time to look at this further right now, but if you can, can you find the 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck and attach that. Also, is the error in Mailman's error log for the 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck file the same UnicodeEncodeError that you get from show_qfiles and dumpdb, or is it the TypeError as in the original report? ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:22 Message: Logged In: YES user_id=309132 Originator: YES OK, I have attached the file. Its name is different, but I guess it's the same(?): # grep 1167220351.925714 /var/log/mailman/error Mar 02 07:37:24 2008 (4711) SHUNTING: 1167220351.925714+55bb5ab698f528a8061d4ef867a634abbed6769e Mar 03 07:36:03 2008 (4711) SHUNTING: 1167220351.925714+d29bf7b17b742fca8b0b71c09c1e52ebcf08620e Mar 04 07:50:44 2008 (4711) SHUNTING: 1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef Mar 05 07:56:19 2008 (4711) SHUNTING: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd Neither show_qfiles nor dbdump works: /usr/lib/mailman/bin/show_qfiles /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ====================> /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck Traceback (most recent call last): File "/usr/lib/mailman/bin/show_qfiles", line 95, in ? main() File "/usr/lib/mailman/bin/show_qfiles", line 88, in main sys.stdout.write(msg.as_string()) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) [root at lvr13 Mailman]# /usr/lib/mailman/bin/dumpdb /var/spool/mailman/shunt/1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck [----- start pickle file -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/lib/mailman/bin/dumpdb", line 159, in ? msg = main() File "/usr/lib/mailman/bin/dumpdb", line 149, in main pp.pprint(obj) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/usr/lib/mailman/Mailman/Message.py", line 51, in __repr__ return self.__str__() File "/usr/lib/mailman/pythonlib/email/Message.py", line 121, in __str__ return self.as_string(unixfrom=True) File "/usr/lib/mailman/pythonlib/email/Message.py", line 135, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 101, in flatten self._write(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 129, in _write self._dispatch(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 155, in _dispatch meth(msg) File "/usr/lib/mailman/pythonlib/email/Generator.py", line 198, in _handle_text self._fp.write(payload) UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Sebastian Hagedorn (shagedorn) Date: 2008-03-05 17:19 Message: Logged In: YES user_id=309132 Originator: YES File Added: 1167220351.925714+67431f92e260e4da420214c9a343ace677ca1acd.pck ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-05 17:14 Message: Logged In: YES user_id=1123998 Originator: NO There is a problem with the message. Try running bin/show_qfiles or if that doesn't work, bin/dumpdb on one or more of the shunted files (e.g. qfiles/shunt/1167220351.925714+8af35bc9b49ca21d542d7fac99bdb87a688619ef.pck). In any case, can you send me this file or attach it to this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1908112&group_id=103 From noreply at sourceforge.net Sun Mar 9 05:10:53 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Mar 2008 20:10:53 -0800 Subject: [ mailman-Bugs-1861600 ] whole HTML templates approach wrong Message-ID: Bugs item #1861600, was opened at 2008-01-01 13:01 Message generated for change (Comment added) made by jidanni You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1861600&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 beta Status: Open Resolution: None Priority: 5 Private: No Submitted By: jidanni (jidanni) Assigned to: Nobody/Anonymous (nobody) Summary: whole HTML templates approach wrong Initial Comment: Gentlemen, observe the deformed child among $ grep -ihc button mailman-2.1.10b1/templates/*/options.html|xargs 26 26 26 26 26 28 26 25 26 22 26 26 26 26 28 26 26 25 26 27 26 26 26 26 26 27 26 26 26 26 26 26 26 26 14 Yes at the very end, 14. Might as well just $ iconv -t gb2312 templates/zh_CN/options.html|iconv -f gb2312 -t big5| iconv -f big5 > templates/zh_TW/options.html It's better than a form without a submit button. Who knows how many other parts of mailman lack an eye here, a leg there... ---------------------------------------------------------------------- >Comment By: jidanni (jidanni) Date: 2008-03-09 12:10 Message: Logged In: YES user_id=1971011 Originator: YES See e.g., http://en.wikipedia.org/wiki/Tableless_web_design . ---------------------------------------------------------------------- Comment By: jidanni (jidanni) Date: 2008-01-17 11:13 Message: Logged In: YES user_id=1971011 Originator: YES I find putting & # 12345 ; style entities into the boxes on admin.cgi/.../general may be a workaround for getting past the charset stuff. Haven't tested ZH_tw blobs in EN email, or seen what will become of zh_TW archives when switching the _monolithic_ site language to EN. ---------------------------------------------------------------------- Comment By: jidanni (jidanni) Date: 2008-01-17 09:57 Message: Logged In: YES user_id=1971011 Originator: YES So I thought maybe for my zh_TW site, I shall change the site language to English, to avoid running all the 93 files with all kinds of missing code in them, here on Dreamhost's installation where even me, site administrator, has only the web interface. (I downloaded the source and am looking at it on my home machine, not Dreamhost's.) I thought just maybe I could at least put some Chinese in some of the four pages that we are allowed to edit via the web interface. But then I see the HTTP header already has the ascii character set defined, an as you know that overrides anything I can put in the body. Yes, I could have the zh_TW versions shown to users by default, and even edit them first to my hearts content, but that means I must change the site language to zh_TW, consigning myself to running the 93 defective parts. ---------------------------------------------------------------------- Comment By: jidanni (jidanni) Date: 2008-01-17 09:17 Message: Logged In: YES user_id=1971011 Originator: YES Gentlemen, I have figured out how to use the poorly documented transcheck command, and the winner is.... $ for i in $(cd messages;ls); do echo -n $i:\ ; bin/transcheck -q $i;done ar: 15 warnings in 2 files ca: 51 warnings in 4 files cs: 2 warnings in 1 files da: 17 warnings in 2 files de: 38 warnings in 10 files es: 40 warnings in 6 files ja: 0 warnings in 0 files ... sv: 50 warnings in 2 files tr: 21 warnings in 2 files uk: 17 warnings in 2 files vi: 9 warnings in 3 files zh_CN: 31 warnings in 4 files zh_TW: 93 warnings in 10 files That's right, zh_TW, another gold medal. Actually it appears your whole approach is wrong. With entire .html and .txt files to be translated, there will always be missing buttons, etc. If instead using just strings in .po files, if a message isn't translated, at least the English will be shown to the user. Anyway how terrible to have unlucky languages with missing buttons. Let's see how MediaWiki does this. There is just one template, and the stings are translated only. Doesn't that make more sense? You program's functionality shouldn't vary by language, but just the strings that describe the functionality. If one wants to customize, then one should customize the template, affecting all languages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1861600&group_id=103 From noreply at sourceforge.net Sun Mar 9 18:51:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2008 10:51:36 -0700 Subject: [ mailman-Patches-1910551 ] admindb: remove 'Reject' option Message-ID: Patches item #1910551, was opened at 2008-03-09 18:51 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=1910551&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.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Schuette (slyh) Assigned to: Nobody/Anonymous (nobody) Summary: admindb: remove 'Reject' option Initial Comment: I found that most users (=list moderators) do not know how e-mail rejects work and all too often 'reject' spam mails. In the best case this creates unnecessary bounces, usually it leads to more spam, and in the worst case it hits a spamtrap adress and gets the listserver blacklisted. Thus I think it is enough to have the 'Reject' option on the msgid page for single mails. It should not be offered on the hold queue page for all mails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1910551&group_id=103 From noreply at sourceforge.net Sun Mar 9 18:58:16 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2008 10:58:16 -0700 Subject: [ mailman-Patches-1910552 ] admindb: new label for 'preserve for admin' Message-ID: Patches item #1910552, was opened at 2008-03-09 18: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=1910552&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.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Schuette (slyh) Assigned to: Nobody/Anonymous (nobody) Summary: admindb: new label for 'preserve for admin' Initial Comment: In my experience nobody really knows what the 'Preserve messages for the site administrator' checkbox does and why it is there. -- But after I changed the text to 'train spamfilter' people really started using it and it became useful. Thus I suggest to find a new label for this checkbox and clearly indicate a spam-related action (so the user knows a marked mail will be used to train a spamfilter). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1910552&group_id=103 From noreply at sourceforge.net Mon Mar 10 19:52:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2008 11:52:44 -0700 Subject: [ mailman-Patches-1911318 ] Include message-id in bounce log Message-ID: Patches item #1911318, was opened at 2008-03-10 14:52 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=1911318&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.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Include message-id in bounce log Initial Comment: The attached patch improves the content of the bounce log, determining the message-id of the bounced message. This should make it possible for mmdsr or similar tools to determine what percentage of e-mails bounced. The patch also exercises the message-id code in test_bounces.py. Currently it fails because some of the messages in tests/bounces/ have mbox-style 'From ' lines, and this seems to make email.Message ignore the headers; this causes test_bounces.py to fail at the moment after the patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&group_id=103 From noreply at sourceforge.net Thu Mar 13 14:09:21 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2008 06:09:21 -0700 Subject: [ mailman-Patches-1911318 ] Include message-id in bounce log Message-ID: Patches item #1911318, was opened at 2008-03-10 14:52 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&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.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Include message-id in bounce log Initial Comment: The attached patch improves the content of the bounce log, determining the message-id of the bounced message. This should make it possible for mmdsr or similar tools to determine what percentage of e-mails bounced. The patch also exercises the message-id code in test_bounces.py. Currently it fails because some of the messages in tests/bounces/ have mbox-style 'From ' lines, and this seems to make email.Message ignore the headers; this causes test_bounces.py to fail at the moment after the patch is applied. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2008-03-13 09:09 Message: Logged In: YES user_id=11375 Originator: YES Here's an updated version of the patch that leaves the <> characters in message-ids, and updates the tests correspondingly. File Added: bounce-log-2.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&group_id=103 From noreply at sourceforge.net Thu Mar 13 15:05:08 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2008 07:05:08 -0700 Subject: [ mailman-Patches-1902402 ] Updated README Message-ID: Patches item #1902402, was opened at 2008-02-26 13:28 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1902402&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: documentation Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Updated README Initial Comment: The README hasn't been touched in a while; it encourages the user to download Python 2.3.3, points to a now-404 /mailman-21/ URL, and refers to the inactive mailman3-dev list and to public CVS. The attached patch modernizes the README. I think I have commit privs so I could commit it, but wanted to get the changes double-checked. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2008-03-13 10:05 Message: Logged In: YES user_id=11375 Originator: YES Change has been applied by merging the small-fixes branch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2008-02-26 13:50 Message: Logged In: YES user_id=12800 Originator: NO Andrew, how about creating a bzr branch with these changes and pushing them to Launchpad? :) I'd love to review a branch more than a patch! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-02-26 13:38 Message: Logged In: YES user_id=11375 Originator: YES Attaching another patch, for UPGRADING. File Added: UPGRADING.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1902402&group_id=103 From noreply at sourceforge.net Fri Mar 14 01:38:19 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2008 17:38:19 -0700 Subject: [ mailman-Bugs-1913963 ] Better error checking for MM list in accept_these_nonmembers Message-ID: Bugs item #1913963, was opened at 2008-03-13 17:38 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=1913963&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 beta Status: Open Resolution: None Priority: 5 Private: No Submitted By: James E. Blair (corvus_at_gnu) Assigned to: Nobody/Anonymous (nobody) Summary: Better error checking for MM list in accept_these_nonmembers Initial Comment: As of the 2.1.10 beta series, accept_these_nonmembers and other related fields accept the name of another mailing list in the form "@listname", or "@listname at hostname". Currently a user can specify a list's own name in its accept_these_nonmembers fields. This should not be allowed for two reasons: 1) It's confusing for users -- it would be better to simply use a list's own moderation feature rather than specifying that members of a list can post by listing the name of the list in a field where you specify non-members that can post. 2) It causes a new MailList object for a list to be created inside of a section of code that already has a locked MailList object for the same list. This is a source of potential lock problems that does not occur elsewhere in the Mailman source. I'm attaching a patch that handles this condition as well as improving the error reporting for the case where the user specifies a list that doesn't exist. Additionally, the patch adds protection in the GUI so that users are not permitted to enter either the name of the list they are editing, or a list that does not exist (the latter was already a suggestion in the comments). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&group_id=103 From noreply at sourceforge.net Fri Mar 14 03:01:54 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2008 19:01:54 -0700 Subject: [ mailman-Bugs-1913963 ] Better error checking for MM list in accept_these_nonmembers Message-ID: Bugs item #1913963, was opened at 2008-03-13 17:38 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&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 beta Status: Open Resolution: None Priority: 5 Private: No Submitted By: James E. Blair (corvus_at_gnu) >Assigned to: Mark Sapiro (msapiro) Summary: Better error checking for MM list in accept_these_nonmembers Initial Comment: As of the 2.1.10 beta series, accept_these_nonmembers and other related fields accept the name of another mailing list in the form "@listname", or "@listname at hostname". Currently a user can specify a list's own name in its accept_these_nonmembers fields. This should not be allowed for two reasons: 1) It's confusing for users -- it would be better to simply use a list's own moderation feature rather than specifying that members of a list can post by listing the name of the list in a field where you specify non-members that can post. 2) It causes a new MailList object for a list to be created inside of a section of code that already has a locked MailList object for the same list. This is a source of potential lock problems that does not occur elsewhere in the Mailman source. I'm attaching a patch that handles this condition as well as improving the error reporting for the case where the user specifies a list that doesn't exist. Additionally, the patch adds protection in the GUI so that users are not permitted to enter either the name of the list they are editing, or a list that does not exist (the latter was already a suggestion in the comments). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-13 19:01 Message: Logged In: YES user_id=1123998 Originator: NO You can take it to the bank. Make a release - get a new bug report. ;-) (2.1.10b4 was packaged and uploaded less than an hour befor this report) Thanks for the report. I will incorporate at least some of your patch before the next 2.1.10 release. A couple of notes. Regarding 1) - intentionally putting the name of 'this list' in *_these_nonmembers will never have an effect since a post from anyone who is a member will be handled based on that members moderate flag, and *_these_nonmembers will never be consulted. A further argument for preventing it from being done. Regarding not allowing a non-existent list name, I decided to allow it at the time to permit creating a 'list of nonmembers allowed to post', and adding that list to this list's accept_these_nonmembers to be done in either order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&group_id=103 From noreply at sourceforge.net Sun Mar 16 18:23:43 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Mar 2008 10:23:43 -0700 Subject: [ mailman-Bugs-1913963 ] Better error checking for MM list in accept_these_nonmembers Message-ID: Bugs item #1913963, was opened at 2008-03-13 17:38 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&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 beta >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: James E. Blair (corvus_at_gnu) Assigned to: Mark Sapiro (msapiro) Summary: Better error checking for MM list in accept_these_nonmembers Initial Comment: As of the 2.1.10 beta series, accept_these_nonmembers and other related fields accept the name of another mailing list in the form "@listname", or "@listname at hostname". Currently a user can specify a list's own name in its accept_these_nonmembers fields. This should not be allowed for two reasons: 1) It's confusing for users -- it would be better to simply use a list's own moderation feature rather than specifying that members of a list can post by listing the name of the list in a field where you specify non-members that can post. 2) It causes a new MailList object for a list to be created inside of a section of code that already has a locked MailList object for the same list. This is a source of potential lock problems that does not occur elsewhere in the Mailman source. I'm attaching a patch that handles this condition as well as improving the error reporting for the case where the user specifies a list that doesn't exist. Additionally, the patch adds protection in the GUI so that users are not permitted to enter either the name of the list they are editing, or a list that does not exist (the latter was already a suggestion in the comments). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-16 10:23 Message: Logged In: YES user_id=1123998 Originator: NO This has all been applied except for verifying in the GUI that the list exists. I don't think it's an error to reference a list in *_these_nonmembers with the intent of creating it later. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-13 19:01 Message: Logged In: YES user_id=1123998 Originator: NO You can take it to the bank. Make a release - get a new bug report. ;-) (2.1.10b4 was packaged and uploaded less than an hour befor this report) Thanks for the report. I will incorporate at least some of your patch before the next 2.1.10 release. A couple of notes. Regarding 1) - intentionally putting the name of 'this list' in *_these_nonmembers will never have an effect since a post from anyone who is a member will be handled based on that members moderate flag, and *_these_nonmembers will never be consulted. A further argument for preventing it from being done. Regarding not allowing a non-existent list name, I decided to allow it at the time to permit creating a 'list of nonmembers allowed to post', and adding that list to this list's accept_these_nonmembers to be done in either order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&group_id=103 From noreply at sourceforge.net Wed Mar 19 21:42:02 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Mar 2008 13:42:02 -0700 Subject: [ mailman-Bugs-1920151 ] CGI going bonkers Message-ID: Bugs item #1920151, was opened at 2008-03-19 15: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=1920151&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paddymcpaddy (paddymcpaddy) Assigned to: Nobody/Anonymous (nobody) Summary: CGI going bonkers Initial Comment: Hi all, I just started getting this message when attempting to modify my list on Bluehost. The interface is Fantastico Deluxe. I'm not a coder, so I have know idea what this is telling me. . .can you help?!? Thanks, D Mailman CGI error!!! The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog: Group mismatch error. Mailman expected the CGI wrapper script to be executed as group "nobody", but the system's web server executed the CGI script as group "daemon". Try tweaking the web server to run the script as group "nobody", or re-run configure, providing the command line option `--with-cgi-gid=daemon'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1920151&group_id=103 From noreply at sourceforge.net Thu Mar 20 03:58:47 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Mar 2008 19:58:47 -0700 Subject: [ mailman-Bugs-1920151 ] CGI going bonkers Message-ID: Bugs item #1920151, was opened at 2008-03-19 13:42 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1920151&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: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: paddymcpaddy (paddymcpaddy) Assigned to: Nobody/Anonymous (nobody) Summary: CGI going bonkers Initial Comment: Hi all, I just started getting this message when attempting to modify my list on Bluehost. The interface is Fantastico Deluxe. I'm not a coder, so I have know idea what this is telling me. . .can you help?!? Thanks, D Mailman CGI error!!! The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog: Group mismatch error. Mailman expected the CGI wrapper script to be executed as group "nobody", but the system's web server executed the CGI script as group "daemon". Try tweaking the web server to run the script as group "nobody", or re-run configure, providing the command line option `--with-cgi-gid=daemon'. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-19 19:58 Message: Logged In: YES user_id=1123998 Originator: NO Unless you control your own web server configuration, this is an issue for Bluehost. It is not a bug. It is a misconfiguration. See for some information on group mismatch errors, but as I said, this is a problem with the configuration of Mailman and/or the web server at Bluehost. There's probably nothing you can do about it other than reporting the issue to Bluehost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1920151&group_id=103 From noreply at sourceforge.net Sun Mar 30 14:01:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Mar 2008 05:01:40 -0700 Subject: [ mailman-Patches-1167696 ] add support for PGP and S/MIME encryption and signing Message-ID: Patches item #1167696, was opened at 2005-03-21 17:28 Message generated for change (Comment added) made by mnaumann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1167696&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: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joost van Baal (vanbaal) Assigned to: Nobody/Anonymous (nobody) Summary: add support for PGP and S/MIME encryption and signing Initial Comment: This patch is based upon a patch by Stefan Schlott ( http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.html ) It extends Mailman to: - A post will be distributed only if the PGP signature on the post is from one of the list members. - For sending encrypted email, a list member encrypts to the public key of the list. The post will be decrypted and re-encrypted to the public keys of all list members. (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to RFC 2440 (OpenPGP)). In order to achieve this, each list has a public and private key, as well as a key passphrase. Furthermore, new list settings are defined: gpg_postings_allowed: Is it allowed to send to this list postings which are encrypted with the GPG list key? gpg_msg_distribution: Are subscribers allowed (or even forced) to upload their GPG public key in order to receive all messages encrypted? gpg_post_sign: Should posts be GPG signed with an acknowledged subscriber key before being distributed? gpg_msg_sign: Should the server sign encrypted messages? Finally, each subscriber can upload her PGP public key using the webinterface. Latest version of the patch is available from http://www.non-gnu.uvt.nl/pub/mailman/ . ---------------------------------------------------------------------- Comment By: Moritz Naumann (mnaumann) Date: 2008-03-30 14:01 Message: Logged In: YES user_id=407680 Originator: NO This patch has since been updated for 2.1.9: http://ulm.ccc.de/pipermail/ssls-dev/2008-January/000003.html http://www.mail-archive.com/mailman-developers at python.org/msg10530.html ---------------------------------------------------------------------- Comment By: Joost van Baal (vanbaal) Date: 2006-10-13 07:40 Message: Logged In: YES user_id=28781 The patch fully supports S/MIME too. Between 2006-01 and 2006-10, no work has been done on this patch. It applies to Mailman 2.1.7 only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1167696&group_id=103