Todd Zullinger wrote: > >However, I created a fresh list on my system to see whether this was a >list configuration issue or not and it's reproduceable using a default >list setup. I initially thought it must be some over-agressive >content filtering, but after having it work on a virgin list I don't >think that's the case. There may still be a way to configure the >content filtering to work around this, but I'm not familiar enough >with the various possibilities to know that.
It shouldn't be a content filtering issue. If a part is missing a Content-Type: header, the message methods get_content_type() and get_content_maintype() which are used by MimeDel.py (content filtering) return the default types which are text/plain and text except for subparts of multipart/digest when they are message/rfc822 and message. >> It seems that a good part of the problem in the above referenced >> archive is that the scrubbed attachment is not given a clickable >> link, and in fact the relative path given doesn't even work. I think >> at least part of this must be specific to this site - perhaps a >> (intentionally?) bad value for PUBLIC_ARCHIVE_URL in mm_cfg.py. > >I don't think it's related. My test list created a proper link to the >second message part, but it still scrubbed both mime parts. If I >added a content-disposition: inline header to the first part, then it >was similarly scrubbed and a link inserted. Without that header, the >part just disappeared completely. I can't duplicate this. I am trying a multipart/mixed message with two 'no content-type' parts and a third 'Content-Type: text/plain; charset="us-ascii"' part. The first two parts are (individually) either scrubbed and replaced with An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://example.com/pipermail/list1/attachments/... or left in the message body depending on whether or not they contain a Content-Disposition: inline header. >I can send you config_list output for the test list if you like, but >there weren't any changes made to the config so it should be nothing >but Mailman default. I don't know what OS the real gnupg-users list >runs on, but my test list was created on Fedora Core 6, using the >packaged mailman rpm there (version 2.1.9). I don't think there are >significant deviations from Mailman's source other than the FHS patch >that they apply. If you think it's relevant, I can install from >source and test as well. Can you just send me the original message that has parts lost? -- Mark Sapiro <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
