[Mailman-Developers] content filtering bug (text/html andtext/plain in multipart emails)

[Michael Dunlap]

Thanks - commenting out those lines did the trick and will make my clients 
happy.

Developers- what was the reason for this behavior?  I don't believe this 
was an arbitrary decision, so what unwanted events is it designed to 
prevent?

Michael

Michael Dunlap                   Systems Programmer / Administrator
michael.dunlap at yale.edu          Workstation Support, ITS
(203) 432-1256                   Yale University

On Fri, 1 Jul 2005, Mark Sapiro wrote:

> Michael Dunlap wrote:
>>
>> I've been reading the archives and it looks as if the problem of having
>> content filtering on and passing multi-part emails (plain and html)
>> isn't really solvable.  One email to the users list summarizes the
>> problem this way:
>>
>>
>>> There is a basic design decision in content filtering that makes this
>>> difficult. Namely, after filtering, only the first remaining sub-part
>>> from a multipart/alternative part is retained.
>>>
>>> What this means in practice is if you want to allow both text/plain
>>> parts and text/html parts, the only way to get html to the list is to
>>> insure that the MUA (e-mail client) that creates the post creates an
>>> html only message, not a multipart/alternative message with both
>>> text/plain and text/html sub-parts.
>>>
>>> If you want Mailman content filtering to pass the html part from a
>>> multipart/alternative post, the only way to do this is to disallow
>>> text/plain and require everyone to post html, or to turn off content
>>> filtering and allow everything.
>>
>> My question is two parts.  One, is there a work-around available, and
>> two is this a "feature" which the developers intend to fix?
>
> 1) It depends what you mean by a work-around. If you are willing to
> hack code, look at Mailman/Handlers/MimeDel.py. There you'll find the
> following:
>
>    # Now replace all multipart/alternatives with just the first
> non-empty
>    # alternative.  BAW: We have to special case when the outer part is
> a
>    # multipart/alternative because we need to retain most of the outer
> part's
>    # headers.  For now we'll move the subpart's payload into the outer
> part,
>    # and then copy over its Content-Type: and
> Content-Transfer-Encoding:
>    # headers (any others?).
>    collapse_multipart_alternatives(msg)
>    if ctype == 'multipart/alternative':
>        firstalt = msg.get_payload(0)
>        reset_payload(msg, firstalt)
>
> You could just delete this.
>
> 2). I'm not a Mailman developer, and I can't speak for anyone's intent,
> but a patch which makes the above conditional on a new list attribute,
> updates Mailman/Gui/ContentFilter.py to maintain and document the new
> attribute and updates Mailman/MailList.py to set the default value
> (current behavior) for new and migrated lists, might be accepted.
>
> --
> Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>