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

Mark Sapiro msapiro at value.net
Sat Jul 2 02:04:02 CEST 2005


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



More information about the Mailman-Developers mailing list