If I were to simply remove the call to collapse_multipart_alternatives,
would that allow the multipart/alternative part to slip through
unmolested? Does later processing code depend on multipart/alternative
parts being collapsed?
Why would you do this? What do you have in multipart/alternative that would require this kind of action?
In the particular case that I am looking at, there is both text/plain and text/html. Since text/plain happens to be the first non-empty part, it is saved and text/html is thrown away. I am trying to find a way to ensure that both parts make it through so that people who prefer html in their mail still have the ability to view it that way.
Besides turning off filtering altogether, is there any other simple way
to get Mailman to pass multipart/alternative as-is? Stripping
alternatives is not likely to be acceptable for the environment to
which we would be deploying.
Yes. Just list multipart/alternative as one of the formats to pass unchanged. Go to "Content Filtering", then add "multipart/alternative" to the "pass_mime_types" field (the second big one on the page). Note that you have to have filtering turned on for this to have any effect -- if you don't have filtering turned on (the radio button at the top), then no filtering should be done.
If it were that easy, I wouldn't be bothering you ;) Assuming of course I didn't do something stupid. Our first step was to do exactly what you suggest. Under those conditions, the text/html portion is still stripped. Based on my first couple reads through the code, all but the first non-empty part of any multipart/alternative is stripped unconditionally (unless filtering is turned off altogether or the message is a digest). In the call to 'process', general filtering is performed, collapse_multipart_alternative is called unconditionally, and then a few last steps are executed to cleanup and repackage the message. Or at least that is the way it appears to me at the moment. As far as I can see, once you are in 'process' with filtering enabled, your alternatives get stripped automatically; list configuration does not appear to be relevant in this regard.
Jim
_______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
