Mailman 3 March 2006 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net Aug. 19, 2022

Aug. 19, 2022

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

2 1

[ mailman-Bugs-1462479 ] mailman 2.1.7 not on ftp.gnu.org
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1462479, was opened at 2006-03-31 23:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: karl berry (kberry) Assigned to: Nobody/Anonymous (nobody) Summary: mailman 2.1.7 not on ftp.gnu.org Initial Comment: the web page on list.org says that the current version of mailman is downloadable from GNU, but ftp.gnu.org doesn't actually have 2.1.7 (or 2.1.6). >From the lack of .sig files in ftp.gnu.org/gnu/mailman, I surmise your gpg keys may never have gotten registered by sysadmin to enable ftp uploads. here's the bit from maintain.texi about that procedure in case it helps: http://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html Best, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_…

1 0

[ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1461279, was opened at 2006-03-30 02:41 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Closed Resolution: Invalid Priority: 2 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 11:46 Message: Logged In: YES user_id=1123998 "Seems Konqueror messed up the line breaks in my last reply." Actually, it's usually the tracker itself that messes up line breaks. :-( "Could it be that that something in the 2.1.5 to 2.1.7 upgrade didn't go right" When you upgraded from 2.1.5 to 2.1.7 the collapse_alternatives list settings would have been initialized from the DEFAULT_COLLAPSE_ALTERNATIVES in mm_cfg.py/Defaults.py which would have been "Yes" to match pre 2.1.7 behavior unless you had already set it to No in mm_cfg.py, but any subsequent display/change on the admin content filtering page would have shown/set the actual value at that point. ---------------------------------------------------------------------- Comment By: - (psy-q) Date: 2006-03-30 23:22 Message: Logged In: YES user_id=244049 Seems Konqueror messed up the line breaks in my last reply. These last two days are full of cursed software :) I tried a vanilla installation of Mailman 2.1.7, configured the list as described here and everything worked exactly as expected (and advertised). I can't explain where yesterday's behavior came from, and I'm sorry if I caused any confusion. I can only guess: Could it be that that something in the 2.1.5 to 2.1.7 upgrade didn't go right, or that I did something wrong, and somehow 2.1.5's hardcoded collapse_alternatives had taken effect even though 2.1.7's settings said not to collapse? I did restart the qrunner with mailmanctl after the upgrade, but on the other hand, I did install 2.1.7 into the same location where 2.1.5 previously was. Something there might have been the source of the error. ---------------------------------------------------------------------- Comment By: - (psy-q) Date: 2006-03-30 23:04 Message: Logged In: YES user_id=244049 Thanks for clearing that up, you've confirmed most of what I've only had vague suspicions about :) I found out about 2.1.5's hardcoded collapse_alternatives behavior about half an hour after posting my bug, but thanks for confirming it. I feel like a fool at the moment. I just retried this so I could give you example messages, and the behavior has stopped. I reproduced the unwanted filtering for over an hour yesterday, I have no idea why it's working correctly now. Yesterday, I tried about a dozen combinations of filter strings and settings, none of which produced the desired result. In the end, I returned to the configuration that I posted here and performed a final test to verify that the behavior is indeed confusing. Today, I switched my test MTA back on, switched Mailman back on and tried the very same test message as yesterday. Amazingly, it went through exactly as expected. Then I removed text/html from pass_mime_types, and again it behaved exactly as advertised: It let the multipart/alternative message through, kept the text/plain part intact but removed the text/html. This is completely different behavior than I saw yesterday. So now I'm even more confused than before -- In theory, this means that an upgrade to 2.1.7 using this list configuration would make everything work as it should at my site, and it would mean that there is no bug. I will test a bit more thoroughly, I'll remove Mailman and do a vanilla install of 2.1.7 to see if I can get the behavior to show again. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-30 17:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_…

1 0

[ mailman-Bugs-1462091 ] admin links force me to insecure mode with password
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1462091, was opened at 2006-03-31 05:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) >Status: Pending >Resolution: Invalid Priority: 5 Submitted By: Trent Larson (trentlarson) Assigned to: Nobody/Anonymous (nobody) Summary: admin links force me to insecure mode with password Initial Comment: I start out in secure mode when I administer my list, but many operations have hard-coded links to HTTP, and then it loses my session information and requires me to login again from that insecure page. In other words, there are many screens that I cannot use without logging in insecurely. Using v 2.1.6. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 08:56 Message: Logged In: YES user_id=1123998 This is not a bug. It is a misconfiguration. What you want to do is put DEFAULT_URL_PATTERN = 'https://%s/mailman/' in mm_cfg.py and then run bin/fix_url.py to update your existing lists, e.g. bin/withlist -l -a -r fix_url -- [fix_url options] but first run bin/fix_url.py stand alone for help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_…

1 0

[ mailman-Bugs-1462091 ] admin links force me to insecure mode with password
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1462091, was opened at 2006-03-31 06:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Trent Larson (trentlarson) Assigned to: Nobody/Anonymous (nobody) Summary: admin links force me to insecure mode with password Initial Comment: I start out in secure mode when I administer my list, but many operations have hard-coded links to HTTP, and then it loses my session information and requires me to login again from that insecure page. In other words, there are many screens that I cannot use without logging in insecurely. Using v 2.1.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_…

1 0

[ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1461279, was opened at 2006-03-30 12:41 Message generated for change (Comment added) made by psy-q You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 2 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: - (psy-q) Date: 2006-03-31 09:22 Message: Logged In: YES user_id=244049 Seems Konqueror messed up the line breaks in my last reply. These last two days are full of cursed software :) I tried a vanilla installation of Mailman 2.1.7, configured the list as described here and everything worked exactly as expected (and advertised). I can't explain where yesterday's behavior came from, and I'm sorry if I caused any confusion. I can only guess: Could it be that that something in the 2.1.5 to 2.1.7 upgrade didn't go right, or that I did something wrong, and somehow 2.1.5's hardcoded collapse_alternatives had taken effect even though 2.1.7's settings said not to collapse? I did restart the qrunner with mailmanctl after the upgrade, but on the other hand, I did install 2.1.7 into the same location where 2.1.5 previously was. Something there might have been the source of the error. ---------------------------------------------------------------------- Comment By: - (psy-q) Date: 2006-03-31 09:04 Message: Logged In: YES user_id=244049 Thanks for clearing that up, you've confirmed most of what I've only had vague suspicions about :) I found out about 2.1.5's hardcoded collapse_alternatives behavior about half an hour after posting my bug, but thanks for confirming it. I feel like a fool at the moment. I just retried this so I could give you example messages, and the behavior has stopped. I reproduced the unwanted filtering for over an hour yesterday, I have no idea why it's working correctly now. Yesterday, I tried about a dozen combinations of filter strings and settings, none of which produced the desired result. In the end, I returned to the configuration that I posted here and performed a final test to verify that the behavior is indeed confusing. Today, I switched my test MTA back on, switched Mailman back on and tried the very same test message as yesterday. Amazingly, it went through exactly as expected. Then I removed text/html from pass_mime_types, and again it behaved exactly as advertised: It let the multipart/alternative message through, kept the text/plain part intact but removed the text/html. This is completely different behavior than I saw yesterday. So now I'm even more confused than before -- In theory, this means that an upgrade to 2.1.7 using this list configuration would make everything work as it should at my site, and it would mean that there is no bug. I will test a bit more thoroughly, I'll remove Mailman and do a vanilla install of 2.1.7 to see if I can get the behavior to show again. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 03:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_…

1 0

[ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1461279, was opened at 2006-03-30 12:41 Message generated for change (Comment added) made by psy-q You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Open Resolution: None >Priority: 2 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: - (psy-q) Date: 2006-03-31 09:04 Message: Logged In: YES user_id=244049 Thanks for clearing that up, you've confirmed most of what I've only had vague suspicions about :) I found out about 2.1.5's hardcoded collapse_alternatives behavior about half an hour after posting my bug, but thanks for confirming it. I feel like a fool at the moment. I just retried this so I could give you example messages, and the behavior has stopped. I reproduced the unwanted filtering for over an hour yesterday, I have no idea why it's working correctly now. Yesterday, I tried about a dozen combinations of filter strings and settings, none of which produced the desired result. In the end, I returned to the configuration that I posted here and performed a final test to verify that the behavior is indeed confusing. Today, I switched my test MTA back on, switched Mailman back on and tried the very same test message as yesterday. Amazingly, it went through exactly as expected. Then I removed text/html from pass_mime_types, and again it behaved exactly as advertised: It let the multipart/alternative message through, kept the text/plain part intact but removed the text/html. This is completely different behavior than I saw yesterday. So now I'm even more confused than before -- In theory, this means that an upgrade to 2.1.7 using this list configuration would make everything work as it should at my site, and it would mean that there is no bug. I will test a bit more thoroughly, I'll remove Mailman and do a vanilla install of 2.1.7 to see if I can get the behavior to show again. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-31 03:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_…

1 0

[ mailman-Bugs-1461279 ] Filtering content while allowing HTML messages impossible
by SourceForge.net March 31, 2006

March 31, 2006

Bugs item #1461279, was opened at 2006-03-30 02:41 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: - (psy-q) Assigned to: Nobody/Anonymous (nobody) Summary: Filtering content while allowing HTML messages impossible Initial Comment: I hope this is a genuine bug. I'll use 2.1.7 in these examples, though I verified this behavior in 2.1.5 also. I have a mailing list configured as such: filter_content = 1 filter_mime_types = '' pass_mime_types = """multipart/mixed multipart/alternative text/plain text/html""" collapse_alternatives = 0 convert_html_to_plaintext = 0 filter_action = 2 And yet all HTML messages are automatically stripped of HTML, have their attachments removed and are immediately posted to the list. The originals are sent as multipart/alternative with two attachments, one the text/plain rendition of the message and one the text/html original. It seems to be okay, user agents can render this message as intended. All that remains when delivered by Mailman is the text/plain bit, though. Shouldn't this list configuration let HTML mails through? I can't see a reason why Mailman should remove the HTML silently with these settings. If filter_content is turned off, sending HTML messages works. (I know it's not polite to send HTML messages through mailing lists, but some of my users insist.) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-03-30 17:00 Message: Logged In: YES user_id=1123998 You can't really compare 2.1.5 and 2.1.7 in this respect since 2.1.5 doesn't have the collapse_alternatives setting and always operates as if collapse_alternatives is true (non-zero). I.e., 2.1.5 will always replace a multipart/alternative part with just the first alternative. Also, your "immediately posted" remark makes me think that you think filter_action applies whenever content is filtered in any way. This is not true. filter_action only applies when the message is empty after filtering. You also say "yet all HTML messages are automatically stripped of HTML, have their attachments removed and ...". I think you may or may not have a misconception here. With the pass_mime_types settings you have given, no attachments of any type other than text/plain or text/html should be left in the message. The types multipart/alternative and multipart/mixed only allow such messages/parts to be further processed looking for allowable types. I.e, with these settings a message or part of type multipart/related will be filtered completely (nothing left) regardless of what it contains, because multipart/related is not accepted. On the other hand, a message or part of type multipart/mixed will have it's sub-parts examined for allowable types because multipart/mixed is allowed. So the only issue is why are text/html parts being removed in 2.1.7 from multipart/mixed and/or multipart/alternative parts. This may or may not be a bug. Please attach full copies of a message both before and after filtering including all headers to this report, so we can see if there is a bug or what the problem might be. Note that your description of the multipart/alternative messages and results is the only way Mailman 2.1.5 works so there is no bug there. In 2.1.7 with collapse_alternatives = 0 and text/html in pass_mime_types, the html should remain in the outgoing message, so there is clearly a problem here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461279&group_…

1 0

[ mailman-Feature Requests-1460796 ] Add option to remove Sender header
by SourceForge.net March 30, 2006

March 30, 2006

Feature Requests item #1460796, was opened at 2006-03-29 12:04 Message generated for change (Comment added) made by xpl0re You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Myke Olson (xpl0re) Assigned to: Nobody/Anonymous (nobody) Summary: Add option to remove Sender header Initial Comment: When sending messages through mailman with Postfix, it adds a new header called "Sender" in addition to the Errors-To and Return-Path headers. Outlook (probably mistakenly) sees the Sender header and treats it like gold. All messages show up in the user's mailbox as from list-bounces on behalf of therealperson. What's worse is that the rules/filters will only work on the list-bounces part and not therealperson. If we could selectively turn off the addition of the Sender header (and be able to keep the other two), then we should still be able to use bounces but have Outlook be able to filter messages. ---------------------------------------------------------------------- >Comment By: Myke Olson (xpl0re) Date: 2006-03-30 10:48 Message: Logged In: YES user_id=689092 Thanks for that posting. The hack to comment that line out definetly fixes the "problem". While I definetly agree that putting in fixes to correct behavior in MS products sucks, in this case, it would be great to just have it as an option so we don't have to have the hacked code. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2006-03-30 09:57 Message: Logged In: YES user_id=75166 RFC2822 (Para 3.6.2. - Originator fields) would suggest that simply not using the Sender: header when Mailman is the agent responsible for the actual transmission of the message is a breach of the RFC. The problem with the behaviour of Outlook is discussed in the Mailman FAQ here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.003.htp A suggested code change which cosmetically improves the Outlook presentation by changing the Sender: header value from the listname- bounces alias to the listname alias is described there. Paranthetically: The Error-to: header is deprecated and only inserted for backward compatibilty with old/broken MTAs. The Return-path is not a header that travels with the message and is known as a trace field. It is mandatory and normally inserted at the start of the message, as a header, by the final SMTP delivery MTA and is the value of the SMTP envelope sender. As an aside, Outlook 2003 appears to allow filtering on the contents of From: header wihtout any problems (as opposed to the From field displayed on the GUI) and this does not involve the contents of the Sender: header. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_…

1 0

[ mailman-Feature Requests-1460796 ] Add option to remove Sender header
by SourceForge.net March 30, 2006

March 30, 2006

Feature Requests item #1460796, was opened at 2006-03-29 17:04 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Myke Olson (xpl0re) Assigned to: Nobody/Anonymous (nobody) Summary: Add option to remove Sender header Initial Comment: When sending messages through mailman with Postfix, it adds a new header called "Sender" in addition to the Errors-To and Return-Path headers. Outlook (probably mistakenly) sees the Sender header and treats it like gold. All messages show up in the user's mailbox as from list-bounces on behalf of therealperson. What's worse is that the rules/filters will only work on the list-bounces part and not therealperson. If we could selectively turn off the addition of the Sender header (and be able to keep the other two), then we should still be able to use bounces but have Outlook be able to filter messages. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2006-03-30 14:57 Message: Logged In: YES user_id=75166 RFC2822 (Para 3.6.2. - Originator fields) would suggest that simply not using the Sender: header when Mailman is the agent responsible for the actual transmission of the message is a breach of the RFC. The problem with the behaviour of Outlook is discussed in the Mailman FAQ here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.003.htp A suggested code change which cosmetically improves the Outlook presentation by changing the Sender: header value from the listname- bounces alias to the listname alias is described there. Paranthetically: The Error-to: header is deprecated and only inserted for backward compatibilty with old/broken MTAs. The Return-path is not a header that travels with the message and is known as a trace field. It is mandatory and normally inserted at the start of the message, as a header, by the final SMTP delivery MTA and is the value of the SMTP envelope sender. As an aside, Outlook 2003 appears to allow filtering on the contents of From: header wihtout any problems (as opposed to the From field displayed on the GUI) and this does not involve the contents of the Sender: header. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1460796&group_…

1 0