From noreply at sourceforge.net Sun Jan 19 14:46:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 17:49:48 2003 Subject: [Mailman-coders] [ mailman-Bugs-670535 ] qrunner stops for no apparent reason Message-ID: Bugs item #670535, was opened at 2003-01-18 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 8 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner stops for no apparent reason Initial Comment: About once every day or so, qrunner will stop for no apparent reason. The qrunner log file has the following ... Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner exiting. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner exiting. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner exiting. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner exiting. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner exiting. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner exiting. Jan 18 14:29:10 2003 (3444) NewsRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:12 2003 (3444) NewsRunner qrunner exiting. No other log has any indication of what might be happening. Is there a way to increase the logging somewhere so the cause can be identified? ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 17:46 Message: Logged In: YES user_id=12800 I'm not sure what kind of logging would help. Some process somewhere is SIGTERMing the mailmanctl controller process. There's no way to know where a signal is coming from, so I'm not sure what more you could do in mailmanctl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_id=103 From noreply at sourceforge.net Sun Jan 19 17:37:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 21:16:21 2003 Subject: [ mailman-Bugs-669081 ] Major attachment handling bug! Message-ID: Bugs item #669081, was opened at 2003-01-16 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 9 Submitted By: Daniel Buchmann (avalon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Major attachment handling bug! Initial Comment: Attachments are not handled correctly. Attached to this bug report is an example email in a mbox file. How to reproduce: 1. create a list called "clasohlson" 2. copy this mbox file to the archive mbox file 3. run bin/arch for the list 4. look at the resulting archive I will post a followup which will contain the resulting html file I got when doing this. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:37 Message: Logged In: YES user_id=12800 TK, I've looked at the patch, and I like parts of it but not other parts. For me, get_content_charset() always digs out the right character set without the need for that regexp. If it doesn't for you, then that's a bug in the email package, which we should report and fix. I've attached my tentative patch which seems to fix the clasohlson mbox when using Czech. I haven't yet tried attachment_error.mbox, and I haven't fixed the private archiver or the mimetypes lie, but will get to those next. ---------------------------------------------------------------------- Comment By: Jan Siml (janjules) Date: 2003-01-19 09:45 Message: Logged In: YES user_id=151422 After applying the patch it still doesn't work. I deleted the directory of the archive and rebuild the archive by using bin/arch. But even now, i got the same: no attachment, only ")Ãj×¢jxZž¢´§Öz|.× zÇ!ç]z»Cj×¢?©žŠÊ<óŸuAœ"±È^žš". Did i forget anything to do? ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-19 08:18 Message: Logged In: YES user_id=184577 Applied cleanly, and now there is only one problem left! :D I believe Mailman is supplying the wrong MIME type for the .doc file when the archive is private. Thus, the webbrowser just displays the raw file instead of launching an application that can handle it correctly. I changed the archive to public, and the file was displayed correctly. Thanks for your quick fix so far, this has really helped a lot! (The users of the particular list were depending heavily on the archive for the list, and considered the list completely unuseable without attachments available in the archive.) ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 19:57 Message: Logged In: YES user_id=67709 I have updated the patch. Please try. (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:54 Message: Logged In: YES user_id=184577 Sorry, forget my last comment, the attachment was just fine. My mistake. But attachment naming is still a problem. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:49 Message: Logged In: YES user_id=184577 Check also the attached "attachment_error.mbox". It contains a single message, with a MS Word document that becomes completely scrambled after going through pipermail... ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:18 Message: Logged In: YES user_id=184577 Applied without problems, but gave me the following error when running bin/arch (not on the mbox I submitted, though): Traceback (most recent call last): File "bin/arch", line 187, in ? main() File "bin/arch", line 175, in main archiver.processUnixMailbox(fp, start, end) File "/home/mailman/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox m = mbox.next() File "/usr/lib/python2.2/mailbox.py", line 33, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 79, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 99, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 145, in process cs = csre.search(part['content-type']) TypeError: expected string or buffer The offending message had no "Content-Type:" field in its header. (It was, of course, produced by a Microsoft product... ;) Some issues from my earlier subimtted example that still needs to be fixed: 1. The attachment file name still becomes ".dot", not ".doc" as it should have been. Also, the reported size is wrong (larger) than the actual file. 2. "The attachment was scrubbed" part in the archive web page is still sort of "attached" to the message itself, e.g. to the email signature of the user that posted the message. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 01:03 Message: Logged In: YES user_id=67709 Please try this patch. https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 11:29 Message: Logged In: YES user_id=184577 -changing priority and assignment- ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:31 Message: Logged In: YES user_id=184577 And here is the html file in english. Notice the difference. Lots of garbage (also called mojibake?) ;) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:28 Message: Logged In: YES user_id=184577 Here is the generated html page for the email, if list language is set to norwegian. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:26 Message: Logged In: YES user_id=184577 Sorry, my web browser hung after submitting the bug, and I had to go offfline in a hurry. Trying again.... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-16 10:07 Message: Logged In: YES user_id=12800 There was no attachment, are you sure you clicked the checkbox? :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 From noreply at sourceforge.net Sun Jan 19 17:41:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 21:16:21 2003 Subject: [ mailman-Bugs-669081 ] Major attachment handling bug! Message-ID: Bugs item #669081, was opened at 2003-01-16 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 9 Submitted By: Daniel Buchmann (avalon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Major attachment handling bug! Initial Comment: Attachments are not handled correctly. Attached to this bug report is an example email in a mbox file. How to reproduce: 1. create a list called "clasohlson" 2. copy this mbox file to the archive mbox file 3. run bin/arch for the list 4. look at the resulting archive I will post a followup which will contain the resulting html file I got when doing this. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:41 Message: Logged In: YES user_id=12800 Ok, attachment_error.mbox was shallow. I'll have a fix for that too. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:37 Message: Logged In: YES user_id=12800 TK, I've looked at the patch, and I like parts of it but not other parts. For me, get_content_charset() always digs out the right character set without the need for that regexp. If it doesn't for you, then that's a bug in the email package, which we should report and fix. I've attached my tentative patch which seems to fix the clasohlson mbox when using Czech. I haven't yet tried attachment_error.mbox, and I haven't fixed the private archiver or the mimetypes lie, but will get to those next. ---------------------------------------------------------------------- Comment By: Jan Siml (janjules) Date: 2003-01-19 09:45 Message: Logged In: YES user_id=151422 After applying the patch it still doesn't work. I deleted the directory of the archive and rebuild the archive by using bin/arch. But even now, i got the same: no attachment, only ")Ãj×¢jxZž¢´§Öz|.× zÇ!ç]z»Cj×¢?©žŠÊ<óŸuAœ"±È^žš". Did i forget anything to do? ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-19 08:18 Message: Logged In: YES user_id=184577 Applied cleanly, and now there is only one problem left! :D I believe Mailman is supplying the wrong MIME type for the .doc file when the archive is private. Thus, the webbrowser just displays the raw file instead of launching an application that can handle it correctly. I changed the archive to public, and the file was displayed correctly. Thanks for your quick fix so far, this has really helped a lot! (The users of the particular list were depending heavily on the archive for the list, and considered the list completely unuseable without attachments available in the archive.) ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 19:57 Message: Logged In: YES user_id=67709 I have updated the patch. Please try. (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:54 Message: Logged In: YES user_id=184577 Sorry, forget my last comment, the attachment was just fine. My mistake. But attachment naming is still a problem. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:49 Message: Logged In: YES user_id=184577 Check also the attached "attachment_error.mbox". It contains a single message, with a MS Word document that becomes completely scrambled after going through pipermail... ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:18 Message: Logged In: YES user_id=184577 Applied without problems, but gave me the following error when running bin/arch (not on the mbox I submitted, though): Traceback (most recent call last): File "bin/arch", line 187, in ? main() File "bin/arch", line 175, in main archiver.processUnixMailbox(fp, start, end) File "/home/mailman/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox m = mbox.next() File "/usr/lib/python2.2/mailbox.py", line 33, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 79, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 99, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 145, in process cs = csre.search(part['content-type']) TypeError: expected string or buffer The offending message had no "Content-Type:" field in its header. (It was, of course, produced by a Microsoft product... ;) Some issues from my earlier subimtted example that still needs to be fixed: 1. The attachment file name still becomes ".dot", not ".doc" as it should have been. Also, the reported size is wrong (larger) than the actual file. 2. "The attachment was scrubbed" part in the archive web page is still sort of "attached" to the message itself, e.g. to the email signature of the user that posted the message. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 01:03 Message: Logged In: YES user_id=67709 Please try this patch. https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 11:29 Message: Logged In: YES user_id=184577 -changing priority and assignment- ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:31 Message: Logged In: YES user_id=184577 And here is the html file in english. Notice the difference. Lots of garbage (also called mojibake?) ;) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:28 Message: Logged In: YES user_id=184577 Here is the generated html page for the email, if list language is set to norwegian. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:26 Message: Logged In: YES user_id=184577 Sorry, my web browser hung after submitting the bug, and I had to go offfline in a hurry. Trying again.... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-16 10:07 Message: Logged In: YES user_id=12800 There was no attachment, are you sure you clicked the checkbox? :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 From noreply at sourceforge.net Sun Jan 19 18:11:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 21:16:22 2003 Subject: [ mailman-Bugs-669081 ] Major attachment handling bug! Message-ID: Bugs item #669081, was opened at 2003-01-16 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 9 Submitted By: Daniel Buchmann (avalon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Major attachment handling bug! Initial Comment: Attachments are not handled correctly. Attached to this bug report is an example email in a mbox file. How to reproduce: 1. create a list called "clasohlson" 2. copy this mbox file to the archive mbox file 3. run bin/arch for the list 4. look at the resulting archive I will post a followup which will contain the resulting html file I got when doing this. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 21:11 Message: Logged In: YES user_id=12800 Ok, try the attached. I haven't checked the private cgi yet, but I'm sure that's an unrelated problem. This fixes all the other issues. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:41 Message: Logged In: YES user_id=12800 Ok, attachment_error.mbox was shallow. I'll have a fix for that too. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:37 Message: Logged In: YES user_id=12800 TK, I've looked at the patch, and I like parts of it but not other parts. For me, get_content_charset() always digs out the right character set without the need for that regexp. If it doesn't for you, then that's a bug in the email package, which we should report and fix. I've attached my tentative patch which seems to fix the clasohlson mbox when using Czech. I haven't yet tried attachment_error.mbox, and I haven't fixed the private archiver or the mimetypes lie, but will get to those next. ---------------------------------------------------------------------- Comment By: Jan Siml (janjules) Date: 2003-01-19 09:45 Message: Logged In: YES user_id=151422 After applying the patch it still doesn't work. I deleted the directory of the archive and rebuild the archive by using bin/arch. But even now, i got the same: no attachment, only ")Ãj×¢jxZž¢´§Öz|.× zÇ!ç]z»Cj×¢?©žŠÊ<óŸuAœ"±È^žš". Did i forget anything to do? ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-19 08:18 Message: Logged In: YES user_id=184577 Applied cleanly, and now there is only one problem left! :D I believe Mailman is supplying the wrong MIME type for the .doc file when the archive is private. Thus, the webbrowser just displays the raw file instead of launching an application that can handle it correctly. I changed the archive to public, and the file was displayed correctly. Thanks for your quick fix so far, this has really helped a lot! (The users of the particular list were depending heavily on the archive for the list, and considered the list completely unuseable without attachments available in the archive.) ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 19:57 Message: Logged In: YES user_id=67709 I have updated the patch. Please try. (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:54 Message: Logged In: YES user_id=184577 Sorry, forget my last comment, the attachment was just fine. My mistake. But attachment naming is still a problem. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:49 Message: Logged In: YES user_id=184577 Check also the attached "attachment_error.mbox". It contains a single message, with a MS Word document that becomes completely scrambled after going through pipermail... ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:18 Message: Logged In: YES user_id=184577 Applied without problems, but gave me the following error when running bin/arch (not on the mbox I submitted, though): Traceback (most recent call last): File "bin/arch", line 187, in ? main() File "bin/arch", line 175, in main archiver.processUnixMailbox(fp, start, end) File "/home/mailman/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox m = mbox.next() File "/usr/lib/python2.2/mailbox.py", line 33, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 79, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 99, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 145, in process cs = csre.search(part['content-type']) TypeError: expected string or buffer The offending message had no "Content-Type:" field in its header. (It was, of course, produced by a Microsoft product... ;) Some issues from my earlier subimtted example that still needs to be fixed: 1. The attachment file name still becomes ".dot", not ".doc" as it should have been. Also, the reported size is wrong (larger) than the actual file. 2. "The attachment was scrubbed" part in the archive web page is still sort of "attached" to the message itself, e.g. to the email signature of the user that posted the message. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 01:03 Message: Logged In: YES user_id=67709 Please try this patch. https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 11:29 Message: Logged In: YES user_id=184577 -changing priority and assignment- ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:31 Message: Logged In: YES user_id=184577 And here is the html file in english. Notice the difference. Lots of garbage (also called mojibake?) ;) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:28 Message: Logged In: YES user_id=184577 Here is the generated html page for the email, if list language is set to norwegian. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:26 Message: Logged In: YES user_id=184577 Sorry, my web browser hung after submitting the bug, and I had to go offfline in a hurry. Trying again.... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-16 10:07 Message: Logged In: YES user_id=12800 There was no attachment, are you sure you clicked the checkbox? :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 From noreply at sourceforge.net Sun Jan 19 18:18:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 21:16:22 2003 Subject: [ mailman-Patches-670167 ] fix i18n attachment description in archive Message-ID: Patches item #670167, was opened at 2003-01-18 00:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 Category: Pipermail Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix i18n attachment description in archive Initial Comment: Bug-ID 669081 (Major attachment handling bug!) is caused inaccurate handling of charset in Scrubber.py. This is caused by misuse of email functions (or by bug in email package). In Scrubber.py, attempt is made to get message charset by part.get_charset() but it returns only None, as far as I experimented. In this patch, message charset is extracted from regular expression pattern in content-type header. This also set the charset of internally crafted message part. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 21:18 Message: Logged In: YES user_id=12800 Accepted, with changes. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 19:52 Message: Logged In: YES user_id=67709 Update of patch. Please backout the first one if you have already applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 From noreply at sourceforge.net Sun Jan 19 18:35:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 21:32:07 2003 Subject: [ mailman-Bugs-669081 ] Major attachment handling bug! Message-ID: Bugs item #669081, was opened at 2003-01-16 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 Category: Pipermail Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Daniel Buchmann (avalon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Major attachment handling bug! Initial Comment: Attachments are not handled correctly. Attached to this bug report is an example email in a mbox file. How to reproduce: 1. create a list called "clasohlson" 2. copy this mbox file to the archive mbox file 3. run bin/arch for the list 4. look at the resulting archive I will post a followup which will contain the resulting html file I got when doing this. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 21:35 Message: Logged In: YES user_id=12800 I'm going to close this one as fixed. I'll have one or two minor refinements to check in momentarily. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 21:11 Message: Logged In: YES user_id=12800 Ok, try the attached. I haven't checked the private cgi yet, but I'm sure that's an unrelated problem. This fixes all the other issues. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:41 Message: Logged In: YES user_id=12800 Ok, attachment_error.mbox was shallow. I'll have a fix for that too. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 20:37 Message: Logged In: YES user_id=12800 TK, I've looked at the patch, and I like parts of it but not other parts. For me, get_content_charset() always digs out the right character set without the need for that regexp. If it doesn't for you, then that's a bug in the email package, which we should report and fix. I've attached my tentative patch which seems to fix the clasohlson mbox when using Czech. I haven't yet tried attachment_error.mbox, and I haven't fixed the private archiver or the mimetypes lie, but will get to those next. ---------------------------------------------------------------------- Comment By: Jan Siml (janjules) Date: 2003-01-19 09:45 Message: Logged In: YES user_id=151422 After applying the patch it still doesn't work. I deleted the directory of the archive and rebuild the archive by using bin/arch. But even now, i got the same: no attachment, only ")Ãj×¢jxZž¢´§Öz|.× zÇ!ç]z»Cj×¢?©žŠÊ<óŸuAœ"±È^žš". Did i forget anything to do? ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-19 08:18 Message: Logged In: YES user_id=184577 Applied cleanly, and now there is only one problem left! :D I believe Mailman is supplying the wrong MIME type for the .doc file when the archive is private. Thus, the webbrowser just displays the raw file instead of launching an application that can handle it correctly. I changed the archive to public, and the file was displayed correctly. Thanks for your quick fix so far, this has really helped a lot! (The users of the particular list were depending heavily on the archive for the list, and considered the list completely unuseable without attachments available in the archive.) ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 19:57 Message: Logged In: YES user_id=67709 I have updated the patch. Please try. (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:54 Message: Logged In: YES user_id=184577 Sorry, forget my last comment, the attachment was just fine. My mistake. But attachment naming is still a problem. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:49 Message: Logged In: YES user_id=184577 Check also the attached "attachment_error.mbox". It contains a single message, with a MS Word document that becomes completely scrambled after going through pipermail... ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-18 11:18 Message: Logged In: YES user_id=184577 Applied without problems, but gave me the following error when running bin/arch (not on the mbox I submitted, though): Traceback (most recent call last): File "bin/arch", line 187, in ? main() File "bin/arch", line 175, in main archiver.processUnixMailbox(fp, start, end) File "/home/mailman/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox m = mbox.next() File "/usr/lib/python2.2/mailbox.py", line 33, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 79, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 99, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 145, in process cs = csre.search(part['content-type']) TypeError: expected string or buffer The offending message had no "Content-Type:" field in its header. (It was, of course, produced by a Microsoft product... ;) Some issues from my earlier subimtted example that still needs to be fixed: 1. The attachment file name still becomes ".dot", not ".doc" as it should have been. Also, the reported size is wrong (larger) than the actual file. 2. "The attachment was scrubbed" part in the archive web page is still sort of "attached" to the message itself, e.g. to the email signature of the user that posted the message. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 01:03 Message: Logged In: YES user_id=67709 Please try this patch. https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 (Patch ID 670167) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 11:29 Message: Logged In: YES user_id=184577 -changing priority and assignment- ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:31 Message: Logged In: YES user_id=184577 And here is the html file in english. Notice the difference. Lots of garbage (also called mojibake?) ;) ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:28 Message: Logged In: YES user_id=184577 Here is the generated html page for the email, if list language is set to norwegian. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2003-01-16 10:26 Message: Logged In: YES user_id=184577 Sorry, my web browser hung after submitting the bug, and I had to go offfline in a hurry. Trying again.... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-16 10:07 Message: Logged In: YES user_id=12800 There was no attachment, are you sure you clicked the checkbox? :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=669081&group_id=103 From noreply at sourceforge.net Sun Jan 19 20:03:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 19 22:59:56 2003 Subject: [ mailman-Patches-670167 ] fix i18n attachment description in archive Message-ID: Patches item #670167, was opened at 2003-01-18 05:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix i18n attachment description in archive Initial Comment: Bug-ID 669081 (Major attachment handling bug!) is caused inaccurate handling of charset in Scrubber.py. This is caused by misuse of email functions (or by bug in email package). In Scrubber.py, attempt is made to get message charset by part.get_charset() but it returns only None, as far as I experimented. In this patch, message charset is extracted from regular expression pattern in content-type header. This also set the charset of internally crafted message part. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-20 04:03 Message: Logged In: YES user_id=67709 We, Japanese, need additional process of stringify and regenerate message instance.. Internal message is in 'euc-jp' but return value of get_content_charset() becomes 'iso-2022-jp' even though the get_payload() returns euc-jp text. The message and part body is converted to iso-2022-jp when it is output to SMTP (or whatever accepts in string format). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-20 02:18 Message: Logged In: YES user_id=12800 Accepted, with changes. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-19 00:52 Message: Logged In: YES user_id=67709 Update of patch. Please backout the first one if you have already applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 From noreply at sourceforge.net Sun Jan 19 21:13:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 00:10:07 2003 Subject: [ mailman-Patches-670167 ] fix i18n attachment description in archive Message-ID: Patches item #670167, was opened at 2003-01-18 00:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 Category: Pipermail Group: Mailman 2.1 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix i18n attachment description in archive Initial Comment: Bug-ID 669081 (Major attachment handling bug!) is caused inaccurate handling of charset in Scrubber.py. This is caused by misuse of email functions (or by bug in email package). In Scrubber.py, attempt is made to get message charset by part.get_charset() but it returns only None, as far as I experimented. In this patch, message charset is extracted from regular expression pattern in content-type header. This also set the charset of internally crafted message part. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-20 00:13 Message: Logged In: YES user_id=12800 Reopening so this issue doesn't get lost. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-19 23:03 Message: Logged In: YES user_id=67709 We, Japanese, need additional process of stringify and regenerate message instance.. Internal message is in 'euc-jp' but return value of get_content_charset() becomes 'iso-2022-jp' even though the get_payload() returns euc-jp text. The message and part body is converted to iso-2022-jp when it is output to SMTP (or whatever accepts in string format). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 21:18 Message: Logged In: YES user_id=12800 Accepted, with changes. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-18 19:52 Message: Logged In: YES user_id=67709 Update of patch. Please backout the first one if you have already applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=670167&group_id=103 From noreply at sourceforge.net Mon Jan 20 01:02:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 03:59:36 2003 Subject: [ mailman-Patches-671057 ] a shell script for lists backup Message-ID: Patches item #671057, was opened at 2003-01-20 10:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671057&group_id=103 Category: command line scripts Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Fil (filfil) Assigned to: Nobody/Anonymous (nobody) Summary: a shell script for lists backup Initial Comment: #################### mailman_save_lists.sh ##################### # v0.14 2003-01-14 11:30 # # this script saves a copy of mailman lists and config files # call this script regularly from the 'mailman' user # e.g. daily from crontab # 01 08 * * * /path/to/mailman_save_lists.sh # # we do save lists each time in compressed form: either they # are big and we can imagine they change each time, or they # are very small and we don't care # # comments to: # # please configure below: where lists are to be found, # and where states are to be saved (must be 'mailman'-writable) ######## mailman=/home/mailman lists=$mailman/lists/ state=/var/state/mailman/ ######## ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671057&group_id=103 From noreply at sourceforge.net Mon Jan 20 01:05:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 04:02:22 2003 Subject: [ mailman-Patches-671057 ] a shell script for lists backup Message-ID: Patches item #671057, was opened at 2003-01-20 10:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671057&group_id=103 Category: command line scripts Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Fil (filfil) Assigned to: Nobody/Anonymous (nobody) Summary: a shell script for lists backup Initial Comment: #################### mailman_save_lists.sh ##################### # v0.14 2003-01-14 11:30 # # this script saves a copy of mailman lists and config files # call this script regularly from the 'mailman' user # e.g. daily from crontab # 01 08 * * * /path/to/mailman_save_lists.sh # # we do save lists each time in compressed form: either they # are big and we can imagine they change each time, or they # are very small and we don't care # # comments to: # # please configure below: where lists are to be found, # and where states are to be saved (must be 'mailman'-writable) ######## mailman=/home/mailman lists=$mailman/lists/ state=/var/state/mailman/ ######## ---------------------------------------------------------------------- >Comment By: Fil (filfil) Date: 2003-01-20 10:05 Message: Logged In: YES user_id=243444 Can I attach a file? Second try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671057&group_id=103 From noreply at sourceforge.net Mon Jan 20 05:11:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 08:07:56 2003 Subject: [ mailman-Bugs-671147 ] ValueError on admin of upgraded list Message-ID: Bugs item #671147, was opened at 2003-01-20 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671147&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: seb bacon (sebbacon) Assigned to: Nobody/Anonymous (nobody) Summary: ValueError on admin of upgraded list Initial Comment: This is a dupe of bug 668664, but I'm darned if I can see how you can upload a file as a comment to an already existing bug. I looked at this bug for a friend and there appear to be a couple of obvious bugs that cause this ValueError to happen. I don't use mailman, so I didn't bother checking that this fix works, but hopefully it's helpful ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671147&group_id=103 From noreply at sourceforge.net Mon Jan 20 08:02:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 10:58:37 2003 Subject: [ mailman-Bugs-671225 ] (un)subscribe: insecure string pickly Message-ID: Bugs item #671225, was opened at 2003-01-20 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671225&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: (un)subscribe: insecure string pickly Initial Comment: After updating to the current CVS no (un-) subscribing via web is possible: When unsubscribing via link from monthly password reminder, Mailman detects a new Bug: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 87, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/options.py", line 149, in main mlist.ConfirmUnsubscription(user, userlang) File "/usr/lib/mailman/Mailman/MailList.py", line 1142, in ConfirmUnsubscription cookie = Pending.new(Pending.UNSUBSCRIPTION, addr) File "/usr/lib/mailman/Mailman/Pending.py", line 64, in new db = _load() File "/usr/lib/mailman/Mailman/Pending.py", line 121, in _load return cPickle.load(fp) ValueError: insecure string pickle ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671225&group_id=103 From noreply at sourceforge.net Mon Jan 20 08:03:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 11:00:22 2003 Subject: [ mailman-Bugs-671225 ] (un)subscribe: insecure string pickle Message-ID: Bugs item #671225, was opened at 2003-01-20 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671225&group_id=103 >Category: (un)subscribing >Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) >Summary: (un)subscribe: insecure string pickle Initial Comment: After updating to the current CVS no (un-) subscribing via web is possible: When unsubscribing via link from monthly password reminder, Mailman detects a new Bug: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 87, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/options.py", line 149, in main mlist.ConfirmUnsubscription(user, userlang) File "/usr/lib/mailman/Mailman/MailList.py", line 1142, in ConfirmUnsubscription cookie = Pending.new(Pending.UNSUBSCRIPTION, addr) File "/usr/lib/mailman/Mailman/Pending.py", line 64, in new db = _load() File "/usr/lib/mailman/Mailman/Pending.py", line 121, in _load return cPickle.load(fp) ValueError: insecure string pickle ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671225&group_id=103 From noreply at sourceforge.net Mon Jan 20 08:12:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 11:09:36 2003 Subject: [ mailman-Feature Requests-671231 ] deletion of lists Message-ID: Feature Requests item #671231, was opened at 2003-01-20 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=671231&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: deletion of lists Initial Comment: rmlist should move deleted lists with all data (config, archive) into a seperate folder. In case of a mistake (or a hack?) it should be possible to restore the list. Or: Mailman should mark this list for deletion with a timestamp and should ignore the existenz of the list completly. Another tool can delete those marked lists from time to time by a cron-job, if the deletion-timestamp is older then X days. Peer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=671231&group_id=103 From noreply at sourceforge.net Mon Jan 20 08:30:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 11:27:09 2003 Subject: [ mailman-Bugs-671239 ] no size shown by held messages Message-ID: Bugs item #671239, was opened at 2003-01-20 17:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671239&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 2 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: no size shown by held messages Initial Comment: When viewing details and body of a single held message mailman doesn`t list the size of the held message. -But mailman does that in the general overview of held messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671239&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:05:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:02:09 2003 Subject: [ mailman-Patches-671283 ] make mailmanctl script compatible with RedHat chkconfig Message-ID: Patches item #671283, was opened at 2003-01-20 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671283&group_id=103 Category: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: make mailmanctl script compatible with RedHat chkconfig Initial Comment: For the mailman services to run across boots it is necessary to start the mailman queue daemon as part of init via the rc.d scripts. The tool to manage the rc.d directories is called chkconfig. The RedHat version demands that the script contain chkconfig: line listing the run level and start/stop priorities, plus a description: entry. If these two headers are not present chkconfig will refuse to manange the script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671283&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:09:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:07:28 2003 Subject: [ mailman-Patches-671283 ] make mailmanctl script compatible with RedHat chkconfig Message-ID: Patches item #671283, was opened at 2003-01-20 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671283&group_id=103 Category: configure/install Group: Mailman 2.1 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: make mailmanctl script compatible with RedHat chkconfig Initial Comment: For the mailman services to run across boots it is necessary to start the mailman queue daemon as part of init via the rc.d scripts. The tool to manage the rc.d directories is called chkconfig. The RedHat version demands that the script contain chkconfig: line listing the run level and start/stop priorities, plus a description: entry. If these two headers are not present chkconfig will refuse to manange the script. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-20 13:09 Message: Logged In: YES user_id=12800 mailmanctl isn't the tool for this. Please see misc/mailman script, which already has the chkconfig lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671283&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:30:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:27:29 2003 Subject: [ mailman-Patches-671294 ] syntax error in tests/fblast.py Message-ID: Patches item #671294, was opened at 2003-01-20 13:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671294&group_id=103 Category: command line scripts Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: syntax error in tests/fblast.py Initial Comment: The tests/fblast.py script in version 2.1 had a syntax error due to a missing close paren. diff -r -u mailman-2.1.orig/tests/fblast.py mailman-2.1/tests/fblast.py --- mailman-2.1.orig/tests/fblast.py 2002-03-13 00:59:40.000000000 -0500 +++ mailman-2.1/tests/fblast.py 2003-01-14 16:46:57.000000000 -0500 @@ -54,7 +54,7 @@ """ % {'num' : i, 'FROMADDR': FROMADDR, 'LISTADDR': LISTADDR, - } + }) time.sleep(snooze) finally: conn.quit() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671294&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:34:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:31:32 2003 Subject: [ mailman-Patches-671297 ] set directory permissions, partition install steps Message-ID: Patches item #671297, was opened at 2003-01-20 13:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671297&group_id=103 Category: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: set directory permissions, partition install steps Initial Comment: This patch accomplishes two things: 1) A number of the directories created during make installed had failed to set their permissions correctly, this caused the script check_perms to report errors, this adds the setting of correct permissions to those directories. 2) Most packaging/install tools divide the installation task into 2 distinct phases File Marshaling: This is where the files of the package are built and installed into a temporary root. The the tool collects all the files under the temporary root and adds them to some type of archive file. During installation on the target machine these files are extracted from the archive and placed in matching positions in the target file system with matching ownership and permissions. Target Update: After the files are placed on the target it is often necessary to run commands on the target system to do such things as register the files, register services, etc. The "make install" in the shipped version of mailman did not separate out these two steps. In particular it attempted to compile the python files during the first phase of file marshaling. During this phase the python files are in a temporary root directory, not their final install position on the target. The paths.py file which is included by many of the python files has hard coded in it the the target installation directory (from the configure step). Thus when attempting to compile the files in the marshaling area the compilations would fail because it could not located patch information. Also the make install attempt to run the bin/update, but once again this has to be deferred to target update time, not package build time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671297&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:44:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:41:27 2003 Subject: [ mailman-Patches-671300 ] allow more than one user group to be specified Message-ID: Patches item #671300, was opened at 2003-01-20 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671300&group_id=103 Category: cross platform Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: allow more than one user group to be specified Initial Comment: Mailman security is in part enforced by requiring it execute SGID. When the mail process or the web server attempts to execute a mailman script a C program is invoked to verify the group permission. Mailman as it is shipped only allows one group to be specified at build time. For users who build and install on their own machine this is not a limitation. However, when making a binary package to be installed on an arbitrary machine it is hard to predict the correct group to use for that installation. Therefore this patch allows us to specify at build time a list of groups that will be iterated over, if the mailman process is executing as any of one of the group in the set of groups then the permission check passes. Since the groups we build with are limited to a small number of safe groups this does not lower the security much while at the same time provides a much more friendly way to package a binary installation that will run in a wider range of installations. It was necessary to add the macro MM_FIND_GROUP_LIST to the configure.in file replacing the original use of MM_FIND_GROUP_NAME, the former operates on a list of group names while the later on a single name. MM_FIND_GROUP_LIST includes a filter parameter that was added with the notion of supporting the with-permcheck option. If filter is true then only group names that exist on the build machine are permitted in the list, otherwise all names are permitted. However, note that whenever MM_FIND_GROUP_LIST is invoked it is currently hardcoded to disable filtering and is not tied to with-permcheck, this was done because of the observation that if one is passing a list of groups it is likely one is doing so to support installations that have a group not present on the build machine, but one might still want to take advantage of the other with-permcheck functionality. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=671300&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:52:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:48:58 2003 Subject: [ mailman-Bugs-671303 ] bin/arch --start and --end argument handling Message-ID: Bugs item #671303, was opened at 2003-01-20 13:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671303&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bryan Fullerton (fehwalker) Assigned to: Nobody/Anonymous (nobody) Summary: bin/arch --start and --end argument handling Initial Comment: bin/arch says (among other things): -s N --start=N Start indexing at article N, where article 0 is the first in the mbox. Defaults to 0. -e M --end=M End indexing at article M. This script is not very efficient with respect to memory management, and for large archives, it may not be possible to index the mbox entirely. For that reason, you can specify the start and end article numbers. However, using --end=[some #] or --start=[some #] results in these errors: % bin/arch --wipe --end=25000 test [...] option --end must not have an argument % bin/arch --wipe --start=25001 test [...] option --start must not have an argument Using --end [some #] or --start [some #] (ie with no =) works fine. So either the help output of bin/arch needs to be amended to remove the ='s, or the argument handling needs to be tweaked to understand ='s. I'm unsure which is preferable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671303&group_id=103 From noreply at sourceforge.net Mon Jan 20 10:53:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 20 13:50:04 2003 Subject: [ mailman-Bugs-671303 ] bin/arch --start and --end argument handling Message-ID: Bugs item #671303, was opened at 2003-01-20 13:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671303&group_id=103 >Category: Pipermail >Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Bryan Fullerton (fehwalker) Assigned to: Nobody/Anonymous (nobody) Summary: bin/arch --start and --end argument handling Initial Comment: bin/arch says (among other things): -s N --start=N Start indexing at article N, where article 0 is the first in the mbox. Defaults to 0. -e M --end=M End indexing at article M. This script is not very efficient with respect to memory management, and for large archives, it may not be possible to index the mbox entirely. For that reason, you can specify the start and end article numbers. However, using --end=[some #] or --start=[some #] results in these errors: % bin/arch --wipe --end=25000 test [...] option --end must not have an argument % bin/arch --wipe --start=25001 test [...] option --start must not have an argument Using --end [some #] or --start [some #] (ie with no =) works fine. So either the help output of bin/arch needs to be amended to remove the ='s, or the argument handling needs to be tweaked to understand ='s. I'm unsure which is preferable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671303&group_id=103 From noreply at sourceforge.net Mon Jan 20 23:00:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 21 01:56:58 2003 Subject: [ mailman-Patches-668819 ] improve plain-ness and i18n-ness of plain-text digest Message-ID: Patches item #668819, was opened at 2003-01-16 00:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=668819&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: improve plain-ness and i18n-ness of plain-text digest Initial Comment: When the mail charset and list charset are different like Japanese, plain text digests become mixture of these charsets and result in mojibake. This patch converts the message into list specific charset and deliver the digest with single charset. It also takes care of the message headers to retain in the digest according to the setting of mm_cfg.DEFAULT_PLAIN_DIGEST_KEEP_HEADERS. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-21 07:00 Message: Logged In: YES user_id=67709 Update of the patch: Use Scrubber.py to make plain text from multipart message. Problem: each attached file will be saved twice; when archiving and when digest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=668819&group_id=103 From noreply at sourceforge.net Mon Jan 20 23:32:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 21 02:28:37 2003 Subject: [ mailman-Bugs-621689 ] Subscribe requests dropped from admin db Message-ID: Bugs item #621689, was opened at 2002-10-10 20:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe requests dropped from admin db Initial Comment: Occasionally, subscribe requests (via the web page) to a list that requires moderator approval for subscriptions never make it to the admin db for that list. They are listed in the subscribe log file, but never show up on the admin db page. Log file entries look like this: Oct 10 18:43:43 2002 (31168) eventmasters: pending XXXXXX.swfla.rr.com But the admin db page for the list shows no outstanding issues. I have verified that there was an actual subscription request behind this log entry. ---------------------------------------------------------------------- >Comment By: Mark Dadgar (mdadgar) Date: 2003-01-20 23:32 Message: Logged In: YES user_id=598228 I suppose it's possible that those two patches are causing it, but it seems unlikely. What information can I provide that will help you track this down? It's kind of a bummer. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 21:06 Message: Logged In: YES user_id=12800 I definitely need more information. I've neve been able to reproduce the problem. Do you think it could be related to the unofficial patches you've applied? ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-12-05 23:29 Message: Logged In: YES user_id=598228 Ok, I verified that it's still a problem under 2.1b5 with the htdig and indexing patches. It's a real drag, too. :( Please let me know if you need more debug info. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-11-21 22:08 Message: Logged In: YES user_id=598228 Unfortunately, it's still occurring under 2.1b4. I'll check it under 2.1b5 as soon as the patches for htdig integration are released, as I need those to implement. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-22 07:11 Message: Logged In: YES user_id=12800 I'm going to defer this one until 2.1b4 goes out. I've fixed some related bugs in cvs, so hopefully this will be fixed in the new version. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-20 10:14 Message: Logged In: YES user_id=598228 Sorry - I'm running 2.1b3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-20 08:48 Message: Logged In: YES user_id=12800 What version of Mailman are you using. It's import to know the exact version, i.e. 2.1beta3, or if you're running from cvs. A lot of these problems have been fixed in cvs, which will soon be released as 2.1 beta 4. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-10 21:29 Message: Logged In: YES user_id=598228 I just verified, by cat'ing pending.pck, that the appropriate changes seem to be in there. But the web interface never picks them up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_id=103 From noreply at sourceforge.net Tue Jan 21 11:40:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 21 14:38:43 2003 Subject: [ mailman-Bugs-671984 ] move_list script - Syntax Errors Message-ID: Bugs item #671984, was opened at 2003-01-21 19:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671984&group_id=103 Category: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark (backquack) Assigned to: Nobody/Anonymous (nobody) Summary: move_list script - Syntax Errors Initial Comment: Initial execution of the move_list script resulted in serveral regarding korean encodings... Traceback (innermost last): File "./move_list", line 42, in ? import paths File "./paths.py", line 60, in ? import korean.aliases File "/home/mailman/pythonlib/korean/aliases.py", line 23, in ? import encodings.aliases After editing paths.py and commenting out korean.aliases and executing move_list -h I get the following..... ./move_list -h Traceback (innermost last): File "./move_list", line 44, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 686 text += Utils.maketext( ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=671984&group_id=103 From noreply at sourceforge.net Tue Jan 21 23:57:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 02:53:42 2003 Subject: [ mailman-Bugs-621689 ] Subscribe requests dropped from admin db Message-ID: Bugs item #621689, was opened at 2002-10-10 20:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe requests dropped from admin db Initial Comment: Occasionally, subscribe requests (via the web page) to a list that requires moderator approval for subscriptions never make it to the admin db for that list. They are listed in the subscribe log file, but never show up on the admin db page. Log file entries look like this: Oct 10 18:43:43 2002 (31168) eventmasters: pending XXXXXX.swfla.rr.com But the admin db page for the list shows no outstanding issues. I have verified that there was an actual subscription request behind this log entry. ---------------------------------------------------------------------- >Comment By: Mark Dadgar (mdadgar) Date: 2003-01-21 23:57 Message: Logged In: YES user_id=598228 I have a pending.pck file as well as a subscribe log that show subscription attempts that require approval for which I have not gotten admin requests, nor have they shown up in the web interface. I am loath to attach them here as they contain live email addresses. Shoot me an email at md@pdc-racing.net and I can get them to you. Then I'll kill this address. :) ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2003-01-20 23:32 Message: Logged In: YES user_id=598228 I suppose it's possible that those two patches are causing it, but it seems unlikely. What information can I provide that will help you track this down? It's kind of a bummer. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 21:06 Message: Logged In: YES user_id=12800 I definitely need more information. I've neve been able to reproduce the problem. Do you think it could be related to the unofficial patches you've applied? ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-12-05 23:29 Message: Logged In: YES user_id=598228 Ok, I verified that it's still a problem under 2.1b5 with the htdig and indexing patches. It's a real drag, too. :( Please let me know if you need more debug info. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-11-21 22:08 Message: Logged In: YES user_id=598228 Unfortunately, it's still occurring under 2.1b4. I'll check it under 2.1b5 as soon as the patches for htdig integration are released, as I need those to implement. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-22 07:11 Message: Logged In: YES user_id=12800 I'm going to defer this one until 2.1b4 goes out. I've fixed some related bugs in cvs, so hopefully this will be fixed in the new version. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-20 10:14 Message: Logged In: YES user_id=598228 Sorry - I'm running 2.1b3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-20 08:48 Message: Logged In: YES user_id=12800 What version of Mailman are you using. It's import to know the exact version, i.e. 2.1beta3, or if you're running from cvs. A lot of these problems have been fixed in cvs, which will soon be released as 2.1 beta 4. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-10 21:29 Message: Logged In: YES user_id=598228 I just verified, by cat'ing pending.pck, that the appropriate changes seem to be in there. But the web interface never picks them up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_id=103 From noreply at sourceforge.net Wed Jan 22 04:05:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 07:01:51 2003 Subject: [ mailman-Patches-672389 ] admindb.py and admin/user notice i18n subject Message-ID: Patches item #672389, was opened at 2003-01-22 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672389&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: admindb.py and admin/user notice i18n subject Initial Comment: When a message is hold for approval, notices are sent to the user and administrator. The administrator can later process the message with admindb cgi interface. When an i18n message was held, the subject is shown as mime encoded string and not easily readable. This patch decode the header and show the subject in the list preferred charset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672389&group_id=103 From noreply at sourceforge.net Wed Jan 22 04:07:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 07:03:40 2003 Subject: [ mailman-Patches-672389 ] admindb.py and admin/user notice i18n subject Message-ID: Patches item #672389, was opened at 2003-01-22 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672389&group_id=103 >Category: internationalization >Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: admindb.py and admin/user notice i18n subject Initial Comment: When a message is hold for approval, notices are sent to the user and administrator. The administrator can later process the message with admindb cgi interface. When an i18n message was held, the subject is shown as mime encoded string and not easily readable. This patch decode the header and show the subject in the list preferred charset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672389&group_id=103 From noreply at sourceforge.net Wed Jan 22 06:20:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 09:17:07 2003 Subject: [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 3 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2003-01-22 14:20 Message: Logged In: YES user_id=75166 htdig-2.1-0.3.patch corrects yet another bug in htdig.py. Hope that all of them! Stops use of obsolete config variable DEFAULT_HOST in several files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-15 20:18 Message: Logged In: YES user_id=75166 htdig-2.1-0.2.patch corrects a bug in htdig.py and deals with an adverse interaction between htdig.py and a bug in $prefix/scripts/driver (see #668685 for a patch to fix this). It also improves the content type and security handling by htdig.py for MM 2.1 version of patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-15 20:14 Message: Logged In: YES user_id=75166 Uploaded wrong file mailer-2.0.13-0.4.patch on last attempt. Should have been htdig-2.0.13-0.4.patch which improves the content type and security handling by htdig.py for MM 2.0.13 version of patch. Please ignore mailer-2.0.13-0.4.patch file ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-15 20:09 Message: Logged In: YES user_id=75166 mailer-2.0.13-0.4.patch improves the content type and security handling by htdig.py for MM 2.0.13 version of patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-02 16:07 Message: Logged In: YES user_id=75166 htdig-2.1-0.1.patch is a revised version of the patch that is compatible with MM 2.1 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-11 11:48 Message: Logged In: YES user_id=75166 htdig-2.1b6-0.1.patch is a revised version of the patch that is compatible with MM 2.1b6 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-04 10:53 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.3.patch corrects a minor typo in text appearing in the list TOC after the patch is applied. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-11-27 10:24 Message: Logged In: YES user_id=75166 htdig-2.1b5-0.1.patch is a revised version of the patch that is compatible with MM 2.1b5 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-10-30 11:43 Message: Logged In: YES user_id=75166 htdig-2.1b4-0.1.patch is a revised version of the patch that is compatible with MM 2.1b4 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-10-14 11:50 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.3.patch removes use of the file() function, used instead of the open() function, in three cron scripts added by the patch. Use of the file() function created an unnecessary dependency on Python 2.2 ---------------------------------------------------------------------- Comment By: Colin Mackinlay (cmackinlay) Date: 2002-10-12 16:51 Message: Logged In: YES user_id=624179 Got a workaround! The line referred to in the traceback: file(rundig_run_file, 'w').close() is used to create a 'rundig_last_run' file of lenght 0 bytes Creating this manually (or copying it) means the line isn't called and everything seems to work. Either file() is not a valid function call or my python is broken - I'm not literate enough in python to know the answer though! ---------------------------------------------------------------------- Comment By: Colin Mackinlay (cmackinlay) Date: 2002-10-06 14:18 Message: Logged In: YES user_id=624179 Just rebuilt MM as 2.1b3 with htdig. Upgraded lists which had htdig before work fine New lists give the obvious error: Unable to read word database file Did you run htmerge? Running the cronjob doesn't fix as it used to, message is: Output from command /usr/bin/python - S /usr/local/mailman/cron/nightly_htdig .. Traceback (most recent call last): File "/usr/local/mailman/cron/nightly_htdig", line 153, in ? main() File "/usr/local/mailman/cron/nightly_htdig", line 118, in main file(rundig_run_file, 'w').close() NameError: global name 'file' is not defined The archive/htdig folder only contains the xx.conf file, but no db.xx files If I copy in db.xx files from another list then the problem goes away (except I've now got an invalid set of references!) Is this my elementary error or is it more sinister?! ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-15 11:02 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.2.patch corrects a dumb syntax error in htdig- 2.1b3-0.1.patch which will typically show up as logged errors in the operation of the ArchRunner qrunner at line 721 of HyperArch.py ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-14 16:51 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.1.patch is a revised version of the patch that is compatible with MM 2.1b3 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 16:33 Message: Logged In: YES user_id=12800 I've sent Richard some comments off-line about this patch. Meta comments: the 2.0.x patches can't be officially supported, but I'm going to create an unofficial patches page off the wiki for where the 2.0 patches can be migrated. I think this patch set is too big for MM2.1, but if it's cleaned up as per my private message, let's re-evaluate it for MM2.2 (or 3.0). ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:11 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From noreply at sourceforge.net Wed Jan 22 11:26:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 14:23:06 2003 Subject: [ mailman-Bugs-672649 ] canonstr -> unicode usernames Message-ID: Bugs item #672649, was opened at 2003-01-22 19:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=672649&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: canonstr -> unicode usernames Initial Comment: Cgi.subscribe.process_form gets a unicode value for fullname, from Utils.canonstr() (return unicode(newstr, charset, 'replace') This came to my attention because it broke OwnerNotification when the email Message couldn't "flatten" itself with the unicode payload. Suspect that's only the beginning of the trouble that will be caused, so I'm hoping we really don't want unicode usernames values as a rule. I fixed it in subscribe.py with fullname = fullname.encode('iso8859-1'), but note that canonstr is used elsewhere like this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=672649&group_id=103 From noreply at sourceforge.net Wed Jan 22 12:51:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 15:47:30 2003 Subject: [ mailman-Patches-672714 ] cope with garbage Date Message-ID: Patches item #672714, was opened at 2003-01-22 20:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672714&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: cope with garbage Date Initial Comment: rfc822.parsedate(garbage) -> None This patch allows archive generation to survive a garbage Date value. It recognizes the None return and does what it would have done if Date had been missing. *** Mailman/Archiver/pipermail.py.dist Sat Dec 7 18:21:58 2002 --- Mailman/Archiver/pipermail.py Wed Jan 15 15:58:31 2003 *************** *** 223,228 **** --- 223,230 ---- if datestr is missing: return None date = parsedate_tz(datestr) + if date is None: + return None try: return time.mktime(date[:9]) except (ValueError, OverflowError): *** Mailman/Handlers/Scrubber.py.dist Fri Dec 20 11:55:43 2002 --- Mailman/Handlers/Scrubber.py Wed Jan 15 16:00:31 2003 *************** *** 73,78 **** --- 73,80 ---- def safe_strftime(fmt, floatsecs): + if floatsecs is None: + return None try: return time.strftime(fmt, floatsecs) except ValueError: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672714&group_id=103 From noreply at sourceforge.net Wed Jan 22 13:31:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 16:27:41 2003 Subject: [ mailman-Bugs-670535 ] qrunner stops for no apparent reason Message-ID: Bugs item #670535, was opened at 2003-01-18 21:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 8 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner stops for no apparent reason Initial Comment: About once every day or so, qrunner will stop for no apparent reason. The qrunner log file has the following ... Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner exiting. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner exiting. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner exiting. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner exiting. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner exiting. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner exiting. Jan 18 14:29:10 2003 (3444) NewsRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:12 2003 (3444) NewsRunner qrunner exiting. No other log has any indication of what might be happening. Is there a way to increase the logging somewhere so the cause can be identified? ---------------------------------------------------------------------- >Comment By: David Gibbs (midrangeman) Date: 2003-01-22 15:31 Message: Logged In: YES user_id=86339 After some further research, QRUNNER seems to stop after exactly 24 hours of operation. That is, 24 hours after qrunner starts, it ends as if someone killed it with SIGTERM. I know for a fact that nobody is actually doing this ... and no process on my system should be aware of the fact that qrunner is actually running. I will not discount the possiblity that this is an environmental factor, but it seems to me that a daemon process should not be affected by environmental factors. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 16:46 Message: Logged In: YES user_id=12800 I'm not sure what kind of logging would help. Some process somewhere is SIGTERMing the mailmanctl controller process. There's no way to know where a signal is coming from, so I'm not sure what more you could do in mailmanctl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_id=103 From noreply at sourceforge.net Wed Jan 22 16:38:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 22 19:35:03 2003 Subject: [ mailman-Patches-672389 ] admindb.py and admin/user notice i18n subject Message-ID: Patches item #672389, was opened at 2003-01-22 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672389&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: admindb.py and admin/user notice i18n subject Initial Comment: When a message is hold for approval, notices are sent to the user and administrator. The administrator can later process the message with admindb cgi interface. When an i18n message was held, the subject is shown as mime encoded string and not easily readable. This patch decode the header and show the subject in the list preferred charset. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-23 00:38 Message: Logged In: YES user_id=67709 I have to change cron/checkdbs also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=672389&group_id=103 From noreply at sourceforge.net Thu Jan 23 10:39:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 23 13:35:35 2003 Subject: [ mailman-Feature Requests-673265 ] Post confirmation + moderation Message-ID: Feature Requests item #673265, was opened at 2003-01-23 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_id=103 From noreply at sourceforge.net Thu Jan 23 11:45:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 23 14:41:19 2003 Subject: [ mailman-Patches-673294 ] Add message-id to more log messages Message-ID: Patches item #673294, was opened at 2003-01-23 14:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673294&group_id=103 Category: list administration Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add message-id to more log messages Initial Comment: Yesterday I spent some time looking into a user's complaint about not receiving a mems-talk message. Figuring this out required cross-referencing Exim's logs and the Mailman logs, made slightly more annoying because Mailman's post log doesn't mention message-ids. The attached patch includes the message-id in a few more log messages, and should reduce the need to go look at the MTA's logs to find when a message arrived. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673294&group_id=103 From noreply at sourceforge.net Thu Jan 23 11:48:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 23 14:44:14 2003 Subject: [ mailman-Patches-673294 ] Add message-id to more log messages Message-ID: Patches item #673294, was opened at 2003-01-23 14:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673294&group_id=103 Category: list administration Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add message-id to more log messages Initial Comment: Yesterday I spent some time looking into a user's complaint about not receiving a mems-talk message. Figuring this out required cross-referencing Exim's logs and the Mailman logs, made slightly more annoying because Mailman's post log doesn't mention message-ids. The attached patch includes the message-id in a few more log messages, and should reduce the need to go look at the MTA's logs to find when a message arrived. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-01-23 14:48 Message: Logged In: YES user_id=11375 #!@$ SourceForge file upload code... $%^$ ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673294&group_id=103 From noreply at sourceforge.net Thu Jan 23 11:55:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 23 14:51:58 2003 Subject: [ mailman-Patches-673305 ] List & member on bounce action notifications Message-ID: Patches item #673305, was opened at 2003-01-23 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673305&group_id=103 Category: bounce processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: List & member on bounce action notifications Initial Comment: I wanted to get a bit more information on the bounce action notification emails, so I could find them easier when a member wants to know why he was deactivated. The following patch adds the list name & member email address to the bounce action notification email subject. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673305&group_id=103 From noreply at sourceforge.net Thu Jan 23 16:13:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 23 19:09:26 2003 Subject: [ mailman-Patches-668819 ] improve plain-ness and i18n-ness of plain-text digest Message-ID: Patches item #668819, was opened at 2003-01-15 19:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=668819&group_id=103 Category: internationalization Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: improve plain-ness and i18n-ness of plain-text digest Initial Comment: When the mail charset and list charset are different like Japanese, plain text digests become mixture of these charsets and result in mojibake. This patch converts the message into list specific charset and deliver the digest with single charset. It also takes care of the message headers to retain in the digest according to the setting of mm_cfg.DEFAULT_PLAIN_DIGEST_KEEP_HEADERS. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-23 19:13 Message: Logged In: YES user_id=12800 I'm about to check in a bunch of changes related to this patch. Please double check me, as I've modified the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-21 02:00 Message: Logged In: YES user_id=67709 Update of the patch: Use Scrubber.py to make plain text from multipart message. Problem: each attached file will be saved twice; when archiving and when digest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=668819&group_id=103 From noreply at sourceforge.net Fri Jan 24 06:28:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 09:24:47 2003 Subject: [ mailman-Patches-673305 ] List & member on bounce action notifications Message-ID: Patches item #673305, was opened at 2003-01-23 14:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673305&group_id=103 Category: bounce processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: List & member on bounce action notifications Initial Comment: I wanted to get a bit more information on the bounce action notification emails, so I could find them easier when a member wants to know why he was deactivated. The following patch adds the list name & member email address to the bounce action notification email subject. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-24 09:28 Message: Logged In: YES user_id=12800 Why is this patch necessary when self.real_name and member are both in the body of the bounce message? Why put it both places? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673305&group_id=103 From noreply at sourceforge.net Fri Jan 24 06:33:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 09:29:57 2003 Subject: [ mailman-Patches-673305 ] List & member on bounce action notifications Message-ID: Patches item #673305, was opened at 2003-01-23 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673305&group_id=103 Category: bounce processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: List & member on bounce action notifications Initial Comment: I wanted to get a bit more information on the bounce action notification emails, so I could find them easier when a member wants to know why he was deactivated. The following patch adds the list name & member email address to the bounce action notification email subject. ---------------------------------------------------------------------- >Comment By: David Gibbs (midrangeman) Date: 2003-01-24 08:33 Message: Logged In: YES user_id=86339 Easier to find a specific bounce message if the list and member address are on the subject. You don't have to dig through ALL accumulated bounce messages to find one in particular. I keep bounce messages for a few months so that, if a subscriber bounces and wants to know why, I can tell them. Often it's a problem with their ISP or spam filters. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-24 08:28 Message: Logged In: YES user_id=12800 Why is this patch necessary when self.real_name and member are both in the body of the bounce message? Why put it both places? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=673305&group_id=103 From noreply at sourceforge.net Fri Jan 24 10:31:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 13:28:10 2003 Subject: [ mailman-Bugs-670535 ] qrunner stops for no apparent reason Message-ID: Bugs item #670535, was opened at 2003-01-18 21:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 8 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner stops for no apparent reason Initial Comment: About once every day or so, qrunner will stop for no apparent reason. The qrunner log file has the following ... Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner exiting. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner exiting. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner exiting. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner exiting. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner exiting. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner exiting. Jan 18 14:29:10 2003 (3444) NewsRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:12 2003 (3444) NewsRunner qrunner exiting. No other log has any indication of what might be happening. Is there a way to increase the logging somewhere so the cause can be identified? ---------------------------------------------------------------------- >Comment By: David Gibbs (midrangeman) Date: 2003-01-24 12:31 Message: Logged In: YES user_id=86339 I added some debug code to mailmanctl and found out that the sigalarm handler is firing just before the qrunners are terminating. ---------------------------------------------------------------------- Comment By: David Gibbs (midrangeman) Date: 2003-01-22 15:31 Message: Logged In: YES user_id=86339 After some further research, QRUNNER seems to stop after exactly 24 hours of operation. That is, 24 hours after qrunner starts, it ends as if someone killed it with SIGTERM. I know for a fact that nobody is actually doing this ... and no process on my system should be aware of the fact that qrunner is actually running. I will not discount the possiblity that this is an environmental factor, but it seems to me that a daemon process should not be affected by environmental factors. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 16:46 Message: Logged In: YES user_id=12800 I'm not sure what kind of logging would help. Some process somewhere is SIGTERMing the mailmanctl controller process. There's no way to know where a signal is coming from, so I'm not sure what more you could do in mailmanctl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_id=103 From noreply at sourceforge.net Fri Jan 24 11:20:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 14:16:46 2003 Subject: [ mailman-Bugs-621689 ] Subscribe requests dropped from admin db Message-ID: Bugs item #621689, was opened at 2002-10-10 23:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_id=103 Category: (un)subscribing Group: 2.1 (stable) >Status: Closed >Resolution: Later Priority: 7 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe requests dropped from admin db Initial Comment: Occasionally, subscribe requests (via the web page) to a list that requires moderator approval for subscriptions never make it to the admin db for that list. They are listed in the subscribe log file, but never show up on the admin db page. Log file entries look like this: Oct 10 18:43:43 2002 (31168) eventmasters: pending XXXXXX.swfla.rr.com But the admin db page for the list shows no outstanding issues. I have verified that there was an actual subscription request behind this log entry. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-24 14:20 Message: Logged In: YES user_id=12800 Mark, I've looked at the files you sent me, and I see nothing out of the ordinary. I'm going to have to close this one as unreproducible. It's *got* to be something about your system environment. Maybe there's some delay in getting these messages from Mailman to your mta. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2003-01-22 02:57 Message: Logged In: YES user_id=598228 I have a pending.pck file as well as a subscribe log that show subscription attempts that require approval for which I have not gotten admin requests, nor have they shown up in the web interface. I am loath to attach them here as they contain live email addresses. Shoot me an email at md@pdc-racing.net and I can get them to you. Then I'll kill this address. :) ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2003-01-21 02:32 Message: Logged In: YES user_id=598228 I suppose it's possible that those two patches are causing it, but it seems unlikely. What information can I provide that will help you track this down? It's kind of a bummer. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-24 00:06 Message: Logged In: YES user_id=12800 I definitely need more information. I've neve been able to reproduce the problem. Do you think it could be related to the unofficial patches you've applied? ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-12-06 02:29 Message: Logged In: YES user_id=598228 Ok, I verified that it's still a problem under 2.1b5 with the htdig and indexing patches. It's a real drag, too. :( Please let me know if you need more debug info. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-11-22 01:08 Message: Logged In: YES user_id=598228 Unfortunately, it's still occurring under 2.1b4. I'll check it under 2.1b5 as soon as the patches for htdig integration are released, as I need those to implement. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-22 10:11 Message: Logged In: YES user_id=12800 I'm going to defer this one until 2.1b4 goes out. I've fixed some related bugs in cvs, so hopefully this will be fixed in the new version. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-20 13:14 Message: Logged In: YES user_id=598228 Sorry - I'm running 2.1b3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-20 11:48 Message: Logged In: YES user_id=12800 What version of Mailman are you using. It's import to know the exact version, i.e. 2.1beta3, or if you're running from cvs. A lot of these problems have been fixed in cvs, which will soon be released as 2.1 beta 4. ---------------------------------------------------------------------- Comment By: Mark Dadgar (mdadgar) Date: 2002-10-11 00:29 Message: Logged In: YES user_id=598228 I just verified, by cat'ing pending.pck, that the appropriate changes seem to be in there. But the web interface never picks them up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=621689&group_id=103 From noreply at sourceforge.net Fri Jan 24 17:08:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 20:04:11 2003 Subject: [ mailman-Patches-674401 ] ToDigest.py i18n subject Message-ID: Patches item #674401, was opened at 2003-01-25 01:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest.py i18n subject Initial Comment: ToDigestl.py (v2.23) was considerably improved but there remain some oddities in digested message subject representation. Specificaly, MIME subject is not wrapped with the lheader() propperly. Please examine the files I am going to attach. 1. Test program to examine the behaviour of lheader() and improbed (but lengthy) header_in_a_line() which removes excessive CRLF and adjust folding white spaces. It simulates the subject-prefix which will be added in CookHeaders.py. 2. Result of test program. You will notice incompatiblity when the subject is once MIME encoded. 3. New patch which use header_in_a_line() and Utils.wrap() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 From noreply at sourceforge.net Fri Jan 24 17:16:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 20:12:14 2003 Subject: [ mailman-Patches-674401 ] ToDigest.py i18n subject Message-ID: Patches item #674401, was opened at 2003-01-25 01:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest.py i18n subject Initial Comment: ToDigestl.py (v2.23) was considerably improved but there remain some oddities in digested message subject representation. Specificaly, MIME subject is not wrapped with the lheader() propperly. Please examine the files I am going to attach. 1. Test program to examine the behaviour of lheader() and improbed (but lengthy) header_in_a_line() which removes excessive CRLF and adjust folding white spaces. It simulates the subject-prefix which will be added in CookHeaders.py. 2. Result of test program. You will notice incompatiblity when the subject is once MIME encoded. 3. New patch which use header_in_a_line() and Utils.wrap() ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-25 01:16 Message: Logged In: YES user_id=67709 Forget to note: This patch is revise of #668819 which was closed and differently applied in recent CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 From noreply at sourceforge.net Fri Jan 24 19:09:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 22:05:51 2003 Subject: [ mailman-Patches-674433 ] Add post_id information to messages Message-ID: Patches item #674433, was opened at 2003-01-24 22:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674433&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steve Huston (srhuston) Assigned to: Nobody/Anonymous (nobody) Summary: Add post_id information to messages Initial Comment: This patch will add the value of mlist.post_id to the mail during processing. It adds a X-Post-ID header, which can then be searched for and placed in the header/footer of the message (non-digest only). It will also grab this information to put it in the archives, so if you use a searchable archive you can search for a message by post_id. This part is a little 'iffy'. The patch assumes you have the ht://Dig patches installed, but should work fine without them; will likely complain about templates/en/article.html and templates/en/htdig-conf.txt There is also added the ability to inflate the post_id value from the "General" section in the GUI. It makes sure you keep the value as a float, as well as only lets you increase it. This is handy if you are importing messages from an old archive and need to start the post_id at a larger number so as not to interfere with old messages. Left to do as of this writing: i18n (somebody?), documentation in Gui/General.py explaining post_id better (and why you might want/need to mess with it), documentation in Gui/NonDigest.py or templates/en/headfoot.html explaining %(post_id)s variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674433&group_id=103 From noreply at sourceforge.net Fri Jan 24 19:12:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 24 22:07:48 2003 Subject: [ mailman-Patches-674433 ] Add post_id information to messages Message-ID: Patches item #674433, was opened at 2003-01-24 22:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674433&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None >Priority: 3 Submitted By: Steve Huston (srhuston) Assigned to: Nobody/Anonymous (nobody) Summary: Add post_id information to messages Initial Comment: This patch will add the value of mlist.post_id to the mail during processing. It adds a X-Post-ID header, which can then be searched for and placed in the header/footer of the message (non-digest only). It will also grab this information to put it in the archives, so if you use a searchable archive you can search for a message by post_id. This part is a little 'iffy'. The patch assumes you have the ht://Dig patches installed, but should work fine without them; will likely complain about templates/en/article.html and templates/en/htdig-conf.txt There is also added the ability to inflate the post_id value from the "General" section in the GUI. It makes sure you keep the value as a float, as well as only lets you increase it. This is handy if you are importing messages from an old archive and need to start the post_id at a larger number so as not to interfere with old messages. Left to do as of this writing: i18n (somebody?), documentation in Gui/General.py explaining post_id better (and why you might want/need to mess with it), documentation in Gui/NonDigest.py or templates/en/headfoot.html explaining %(post_id)s variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674433&group_id=103 From noreply at sourceforge.net Sat Jan 25 04:42:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 25 07:37:51 2003 Subject: [ mailman-Patches-674553 ] patch for options.py cross site scripting bug Message-ID: Patches item #674553, was opened at 2003-01-25 12:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for options.py cross site scripting bug Initial Comment: fix this issue Example: ----------------- This is a simple example for version 2.1: 1) With mailman options the email variable is vulnerable to cross-site scripting. You can recognise the vulnerabilities with this type of URL: https://www.yourserver.com:443/mailman/options/yourlist? language=en&email=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> and that prove that any (malicious) script code is possible on web interface part of Mailman. 2) The default error page mailman generates does not adequately filter its input making it susceptible to cross-site scripting. https://www.yourserver.com:443//mailman/options/yourlist? language=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 From noreply at sourceforge.net Sat Jan 25 07:24:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 25 10:20:49 2003 Subject: [ mailman-Patches-674553 ] patch for options.py cross site scripting bug Message-ID: Patches item #674553, was opened at 2003-01-25 07:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for options.py cross site scripting bug Initial Comment: fix this issue Example: ----------------- This is a simple example for version 2.1: 1) With mailman options the email variable is vulnerable to cross-site scripting. You can recognise the vulnerabilities with this type of URL: https://www.yourserver.com:443/mailman/options/yourlist? language=en&email=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> and that prove that any (malicious) script code is possible on web interface part of Mailman. 2) The default error page mailman generates does not adequately filter its input making it susceptible to cross-site scripting. https://www.yourserver.com:443//mailman/options/yourlist? language=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-25 10:24 Message: Logged In: YES user_id=12800 Please try this more comprehensive fix. If it looks good, I will issue a security patch later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 From noreply at sourceforge.net Sat Jan 25 07:27:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 25 10:23:11 2003 Subject: [ mailman-Patches-674553 ] patch for options.py cross site scripting bug Message-ID: Patches item #674553, was opened at 2003-01-25 07:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None >Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for options.py cross site scripting bug Initial Comment: fix this issue Example: ----------------- This is a simple example for version 2.1: 1) With mailman options the email variable is vulnerable to cross-site scripting. You can recognise the vulnerabilities with this type of URL: https://www.yourserver.com:443/mailman/options/yourlist? language=en&email=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> and that prove that any (malicious) script code is possible on web interface part of Mailman. 2) The default error page mailman generates does not adequately filter its input making it susceptible to cross-site scripting. https://www.yourserver.com:443//mailman/options/yourlist? language=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-25 10:24 Message: Logged In: YES user_id=12800 Please try this more comprehensive fix. If it looks good, I will issue a security patch later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 From noreply at sourceforge.net Sat Jan 25 20:17:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 25 23:12:55 2003 Subject: [ mailman-Patches-674553 ] patch for options.py cross site scripting bug Message-ID: Patches item #674553, was opened at 2003-01-25 12:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for options.py cross site scripting bug Initial Comment: fix this issue Example: ----------------- This is a simple example for version 2.1: 1) With mailman options the email variable is vulnerable to cross-site scripting. You can recognise the vulnerabilities with this type of URL: https://www.yourserver.com:443/mailman/options/yourlist? language=en&email=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> and that prove that any (malicious) script code is possible on web interface part of Mailman. 2) The default error page mailman generates does not adequately filter its input making it susceptible to cross-site scripting. https://www.yourserver.com:443//mailman/options/yourlist? language=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-26 04:17 Message: Logged In: YES user_id=67709 Please review my second patch. It use Utils.ValidateEmail() and return immediately if the input string is insecure. Also, websafe(user) again to secure the final output. Note that the Exapmle is circulated in bugtraq ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-25 15:24 Message: Logged In: YES user_id=12800 Please try this more comprehensive fix. If it looks good, I will issue a security patch later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 From noreply at sourceforge.net Sun Jan 26 13:33:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 26 16:29:34 2003 Subject: [ mailman-Patches-674553 ] patch for options.py cross site scripting bug Message-ID: Patches item #674553, was opened at 2003-01-25 07:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for options.py cross site scripting bug Initial Comment: fix this issue Example: ----------------- This is a simple example for version 2.1: 1) With mailman options the email variable is vulnerable to cross-site scripting. You can recognise the vulnerabilities with this type of URL: https://www.yourserver.com:443/mailman/options/yourlist? language=en&email=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> and that prove that any (malicious) script code is possible on web interface part of Mailman. 2) The default error page mailman generates does not adequately filter its input making it susceptible to cross-site scripting. https://www.yourserver.com:443//mailman/options/yourlist? language=<SCRIPT>alert('Can%20Cross%20Site%20Attack')</SCRIPT> ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-26 16:33 Message: Logged In: YES user_id=12800 Very good. Here's the patch I intend to commit and advertise as a fix for the cross-site scripting bug. This additionally fixes a crash when the language cgi variable is deliberately given a bogus value. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-25 23:17 Message: Logged In: YES user_id=67709 Please review my second patch. It use Utils.ValidateEmail() and return immediately if the input string is insecure. Also, websafe(user) again to secure the final output. Note that the Exapmle is circulated in bugtraq ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-25 10:24 Message: Logged In: YES user_id=12800 Please try this more comprehensive fix. If it looks good, I will issue a security patch later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674553&group_id=103 From noreply at sourceforge.net Mon Jan 27 23:18:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 28 02:14:12 2003 Subject: [ mailman-Patches-640518 ] SpamAssassin handler Message-ID: Patches item #640518, was opened at 2002-11-18 21:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=640518&group_id=103 Category: list administration Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: SpamAssassin handler Initial Comment: I've updated the existing SpamAssassin patch (534577) for Mailman 2.1. ---------------------------------------------------------------------- Comment By: Shamanic Acid (shamanicacid) Date: 2003-01-27 23:18 Message: Logged In: YES user_id=698712 I am a bit confused in which SpamAssassin.py file to use. There does not seem to be an embedded version number in the download links. The diff I see is as follows: $ diff SpamAssassin.1.py SpamAssassin.py 62,65d61 < # First, play footsie with _ so that the following are marked as translated, < # but aren't actually translated until we need the text later on. < def _(s): < return s 71,73d66 < reason = _('SpamAssassin identified this message as spam') < rejection = _('You message was identified as spam.') < 78,80d70 < reason = _('SpamAssassin identified this message as spam') < rejection = _('You message was identified as spam.') < Question # 1. Do I want to use the SpamAssassin.py file with the "footsie" code? Question # 2. Does the SpamAssassin.py code allow for exceptions when the e-mail is from the $list-owner ( bounces to moderator ) ? I ask because I ran into a problem with a mailer-loop occuring when SpamAssassin errantly tagged the $list-owner moderator bounces as spam. ( spamassasin marks pending e-mails from $list-owner with score 7.6 ) I have not read through all the code, I am curious if mlist.isMember(sender) includes the owner alias? Many Thanks in Advance ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2003-01-12 08:01 Message: Logged In: YES user_id=485579 I've updated the SpamAssassin handler to report a more detailed reason when a DiscardMessage and HoldMessage exception is raised. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2002-12-31 16:33 Message: Logged In: YES user_id=485579 The attached patch adds the SpamAssassin handler to Mailman's mail processing pipelines. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-27 08:13 Message: Logged In: YES user_id=12800 I'm only moving this to the MM2.2/3.0 group so I can concentrate on patches for 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=640518&group_id=103 From noreply at sourceforge.net Tue Jan 28 01:24:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 28 04:19:23 2003 Subject: [ mailman-Bugs-675979 ] Reply-To available, FollowUp-To missing Message-ID: Bugs item #675979, was opened at 2003-01-28 10:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=675979&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Kotes (count) Assigned to: Nobody/Anonymous (nobody) Summary: Reply-To available, FollowUp-To missing Initial Comment: Hi! instead of either 'Reply-To or no Reply-To mailman could/should offer an option to use FollowUp-To, too. http://cr.yp.to/proto/replyto.html This should help against lots of discussion like the one we had a few days ago about the 'reply-to-harmful' or 'reply-to-useful' points of view. Count ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=675979&group_id=103 From noreply at sourceforge.net Tue Jan 28 04:20:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 28 07:15:41 2003 Subject: [ mailman-Feature Requests-676051 ] smarter ./configure script Message-ID: Feature Requests item #676051, was opened at 2003-01-28 12:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=676051&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Szilard Vizi (szilardv) Assigned to: Nobody/Anonymous (nobody) Summary: smarter ./configure script Initial Comment: Mailman 2.1 supports different languages and maybe the ./configure script should check whether the language defined in the LC_LANG variable is among the supported languages. If so, "make install" notifies the user that the Mailman can be used in her/his language and can set up the DEAFULT_SERVER_LANGUAGE to this one with the approval of the user. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=676051&group_id=103 From noreply at sourceforge.net Wed Jan 29 09:55:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 29 12:50:43 2003 Subject: [ mailman-Feature Requests-676923 ] mail command: reject Message-ID: Feature Requests item #676923, was opened at 2003-01-29 18:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=676923&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: mail command: reject Initial Comment: A feature request one of my listowners sent me: I'd like to have a 'reject' command (with possibility to add the reasons for the reject) in addition to the 'approve' and 'discard' commands when administrating mailman by mail. Additionally, the moderation request shouldn't be a MIME composition of three mails to make it easier to reply to the requests. At the moment I don't know a mail client where I can just h it the reply button and then the required 'confirm ' line is in the subject. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=676923&group_id=103 From noreply at sourceforge.net Wed Jan 29 10:06:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 29 13:01:43 2003 Subject: [ mailman-Bugs-660675 ] special characters in realnames Message-ID: Bugs item #660675, was opened at 2003-01-01 15:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=660675&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None >Priority: 9 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: special characters in realnames Initial Comment: Mailman crashs when realnames of members include special language-specifc characters like german "Umlaute" (äöüß). Traceback (most recent call last): File "/usr/lib/mailman/bin/list_members", line 232, in ? main() File "/usr/lib/mailman/bin/list_members", line 207, in main s = formataddr((name, addr)).encode(enc, 'replace') UnicodeError: ASCII decoding error: ordinal not in range(128) It isn`t possible to get a list of all members of this list with list_members or a who command. Mailman has to be able to handle other signs then A-Z and 0-9 in realnames and mailaddresses. Peer ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2003-01-29 19:06 Message: Logged In: YES user_id=581680 Hi Barry! This problem is really old now, I wrote it to you many weeks ago. It`s a *hugh* daily problem on our server and I really have to solve this problem and can`t wait any more! It is a middle-big problem that "who" and "list_members" doesn`t work, because the listowners aren't able to extract their own listmembers into a file or a seperate list. I have over 75.000 users in our mailinglists and there is no chance to have a working membership-management without the possibility to extract the membership-lists to work with! And it is a *hugh* problem, that the daily heldmessages-reminders to the admins don`t work! The daily cronjob to send out those reminders dies every day with this ASCII decoding error. And IT IS a problem, when no held-messages-reminders are available for a lot of weeks now! and heldmessage-management isn`t working correctly! We have to handle about 2000 - 4000 held messages in out lists! Please: Could you solve this problem in the really near future and give them a higher precedence? You know, I`ll help you and I`ll send you all the files you`ll possible need to debug an dtrace this error! ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2003-01-16 16:54 Message: Logged In: YES user_id=581680 Using the actual CVS-checkout I still have problems with that. Because of that a lot of list`s doesn`t work properly and mails are shunted. Is it pssoible to clear that problem with a fast fix? Peer ---------------------------------------------------------------------- Comment By: Jorge Becerra (jlbpcuba) Date: 2003-01-07 23:03 Message: Logged In: YES user_id=680844 I think that the bug is on python itself, because is suppossed that encode(enc, 'replace') show no errors at all according to http://www.reportlab.com/i18n/python_unicode_tutorial.html But is the middle i remove from the code and works ok. .encode(enc, 'replace') ---------------------------------------------------------------------- Comment By: Jorge Becerra (jlbpcuba) Date: 2003-01-07 23:03 Message: Logged In: YES user_id=680844 I think that the bug is on python itself, because is suppossed that encode(enc, 'replace') show no errors at all according to http://www.reportlab.com/i18n/python_unicode_tutorial.html But is the middle i remove from the code that and works ok. .encode(enc, 'replace') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=660675&group_id=103 From noreply at sourceforge.net Thu Jan 30 11:14:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 30 14:09:10 2003 Subject: [ mailman-Bugs-677668 ] Subscription confirmation fails Message-ID: Bugs item #677668, was opened at 2003-01-30 20:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=677668&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription confirmation fails Initial Comment: If the list language is english, but a subscribing user chooses a different language (e.g. norwegian), the following error occurs when confirming the subscription: admin(5296): Traceback (most recent call last): admin(5296): File "/home/mailman/scripts/driver", line 87, in run_main admin(5296): main() admin(5296): File "/home/mailman/Mailman/Cgi/confirm.py", line 110, in main admin(5296): subscription_confirm(mlist, doc, cookie, cgidata) admin(5296): File "/home/mailman/Mailman/Cgi/confirm.py", line 331, in subscription_confirm admin(5296): op, addr, pw, digest, lang = mlist.ProcessConfirmation( admin(5296): File "/home/mailman/Mailman/MailList.py", line 1071, in ProcessConfirmation admin(5296): self.ApprovedAddMember(userdesc) admin(5296): File "/home/mailman/Mailman/MailList.py", line 900, in ApprovedAddMember admin(5296): msg = Message.OwnerNotification(self, subject, text) admin(5296): File "/home/mailman/Mailman/Message.py", line 257, in __init__ admin(5296): UserNotification.__init__(self, recips, sender, subject, text, lang) admin(5296): File "/home/mailman/Mailman/Message.py", line 203, in __init__ admin(5296): self['Subject'] = Header(subject, charset, header_name='Subject') admin(5296): File "/home/mailman/pythonlib/email/Header.py", line 164, in __init__ admin(5296): self.append(s, charset) admin(5296): File "/home/mailman/pythonlib/email/Header.py", line 230, in append admin(5296): ustr = unicode(s, incodec) admin(5296): UnicodeError: ASCII decoding error: ordinal not in range(128) The user then recieves the welcome-to-this-mailing-list email, but is not subscribed to the list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=677668&group_id=103 From noreply at sourceforge.net Thu Jan 30 19:41:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 30 22:37:16 2003 Subject: [ mailman-Patches-677940 ] English Only mailman Message-ID: Patches item #677940, was opened at 2003-01-30 22:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=677940&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Davis (big-dog) Assigned to: Nobody/Anonymous (nobody) Summary: English Only mailman Initial Comment: Strips out all languages except english. # cd mailman-2.1/messages # rm -fr big5 cs de es et fi fr hu it ja ko lt nl no pt_BR ru sv # cd ../templates # rm -fr big5 cs de es et fi fr hu it ja ko lt nl no pt_BR ru sv gb # cd ../misc # rm -fr JapaneseCodecs-1.4.9.tar.gz KoreanCodecs-2.0.5.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=677940&group_id=103 From noreply at sourceforge.net Thu Jan 30 19:43:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 30 22:39:00 2003 Subject: [ mailman-Patches-677940 ] English Only mailman Message-ID: Patches item #677940, was opened at 2003-01-30 22:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=677940&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Davis (big-dog) Assigned to: Nobody/Anonymous (nobody) Summary: English Only mailman Initial Comment: Strips out all languages except english. # cd mailman-2.1/messages # rm -fr big5 cs de es et fi fr hu it ja ko lt nl no pt_BR ru sv # cd ../templates # rm -fr big5 cs de es et fi fr hu it ja ko lt nl no pt_BR ru sv gb # cd ../misc # rm -fr JapaneseCodecs-1.4.9.tar.gz KoreanCodecs-2.0.5.tar.gz ---------------------------------------------------------------------- >Comment By: Matthew Davis (big-dog) Date: 2003-01-30 22:43 Message: Logged In: YES user_id=34240 Trying to attach file again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=677940&group_id=103 From noreply at sourceforge.net Thu Jan 30 21:17:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 31 00:12:56 2003 Subject: [ mailman-Patches-674401 ] ToDigest.py i18n subject Message-ID: Patches item #674401, was opened at 2003-01-24 20:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest.py i18n subject Initial Comment: ToDigestl.py (v2.23) was considerably improved but there remain some oddities in digested message subject representation. Specificaly, MIME subject is not wrapped with the lheader() propperly. Please examine the files I am going to attach. 1. Test program to examine the behaviour of lheader() and improbed (but lengthy) header_in_a_line() which removes excessive CRLF and adjust folding white spaces. It simulates the subject-prefix which will be added in CookHeaders.py. 2. Result of test program. You will notice incompatiblity when the subject is once MIME encoded. 3. New patch which use header_in_a_line() and Utils.wrap() ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 00:17 Message: Logged In: YES user_id=12800 Tell me what you think of the hial() function in the attached file. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-24 20:16 Message: Logged In: YES user_id=67709 Forget to note: This patch is revise of #668819 which was closed and differently applied in recent CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 From noreply at sourceforge.net Thu Jan 30 21:55:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 31 00:50:39 2003 Subject: [ mailman-Patches-674401 ] ToDigest.py i18n subject Message-ID: Patches item #674401, was opened at 2003-01-25 01:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest.py i18n subject Initial Comment: ToDigestl.py (v2.23) was considerably improved but there remain some oddities in digested message subject representation. Specificaly, MIME subject is not wrapped with the lheader() propperly. Please examine the files I am going to attach. 1. Test program to examine the behaviour of lheader() and improbed (but lengthy) header_in_a_line() which removes excessive CRLF and adjust folding white spaces. It simulates the subject-prefix which will be added in CookHeaders.py. 2. Result of test program. You will notice incompatiblity when the subject is once MIME encoded. 3. New patch which use header_in_a_line() and Utils.wrap() ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-31 05:55 Message: Logged In: YES user_id=67709 Looks like good for english text (may be for western) but folding white space should be treated as null string ('') in iso-2022-jp encoded japanese (and other RFC 2047 encoded MIME subject, I believe). u' '.join() must be u''.join() in these languages. You must alway check if the part of the header is mime encoded or not when joining. :-( ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 05:17 Message: Logged In: YES user_id=12800 Tell me what you think of the hial() function in the attached file. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-25 01:16 Message: Logged In: YES user_id=67709 Forget to note: This patch is revise of #668819 which was closed and differently applied in recent CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 From noreply at sourceforge.net Thu Jan 30 22:47:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 31 01:42:44 2003 Subject: [ mailman-Bugs-664466 ] 2.0 cookies break 2.1 web auth Message-ID: Bugs item #664466, was opened at 2003-01-08 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=664466&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Bryan Fullerton (fehwalker) Assigned to: Nobody/Anonymous (nobody) Summary: 2.0 cookies break 2.1 web auth Initial Comment: (as discussed on mailman-users) If there are *any* mm2.0 cookies in the URI-space mm2.1 looks in, the following code will always raise a Cookie.CookieException and return 0. # Treat the cookie data as simple strings, and do application level # decoding as necessary. By using SimpleCookie, we prevent any kind # of security breach due to untrusted cookie data being unpickled # (which is quite unsafe). try: c = Cookie.SimpleCookie(cookiedata) except Cookie.CookieError: return 0 If python's Cookie code (or at least SimpleCookie) doesn't like cookies with :'s in them that'd explain it. This is rather a problem for anyone thinking they could run both mm2.0 and mm2.1 mapped into the same URI-space. Simply put, you can't (without re-auth'ing with every action in 2.1 lists), unless the mm2.1 code is rewritten to handle that exception better. Or unless you nuke all your cookies after every use of a 2.0 list (not just logout - in my testing that doesn't actually remove the cookie, just the cookie's contents). The good news is that this should be no problem once everything is moved to 2.1. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 01:47 Message: Logged In: YES user_id=12800 The following patch should fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=664466&group_id=103 From noreply at sourceforge.net Thu Jan 30 23:01:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 31 01:56:32 2003 Subject: [ mailman-Patches-674401 ] ToDigest.py i18n subject Message-ID: Patches item #674401, was opened at 2003-01-25 01:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: ToDigest.py i18n subject Initial Comment: ToDigestl.py (v2.23) was considerably improved but there remain some oddities in digested message subject representation. Specificaly, MIME subject is not wrapped with the lheader() propperly. Please examine the files I am going to attach. 1. Test program to examine the behaviour of lheader() and improbed (but lengthy) header_in_a_line() which removes excessive CRLF and adjust folding white spaces. It simulates the subject-prefix which will be added in CookHeaders.py. 2. Result of test program. You will notice incompatiblity when the subject is once MIME encoded. 3. New patch which use header_in_a_line() and Utils.wrap() ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-31 07:01 Message: Logged In: YES user_id=67709 OK, Barry. I will compromise. Use u''.join() not u' '.join(). This eliminate extra space added when joining. Remember that all-ASCII header will get double space after the prefix for English text while the spaces after the prefix is removed for Japanese text. I think __unicode__() joining in the email package should take care the difference in RFC2822/2047 headers. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-31 05:55 Message: Logged In: YES user_id=67709 Looks like good for english text (may be for western) but folding white space should be treated as null string ('') in iso-2022-jp encoded japanese (and other RFC 2047 encoded MIME subject, I believe). u' '.join() must be u''.join() in these languages. You must alway check if the part of the header is mime encoded or not when joining. :-( ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 05:17 Message: Logged In: YES user_id=12800 Tell me what you think of the hial() function in the attached file. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-01-25 01:16 Message: Logged In: YES user_id=67709 Forget to note: This patch is revise of #668819 which was closed and differently applied in recent CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674401&group_id=103 From noreply at sourceforge.net Fri Jan 31 14:01:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 31 17:02:57 2003 Subject: [ mailman-Feature Requests-678423 ] Make simple bounce & simple warning regex's configurable Message-ID: Feature Requests item #678423, was opened at 2003-01-31 16:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=678423&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: Make simple bounce & simple warning regex's configurable Initial Comment: Due to the large number of MTA's in the world, it would probably be good to make the regular expression sets that SimpleBounce & SimpleWarning use externally definable in mm_cfg.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=678423&group_id=103