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

[Les Niles]

On Sun, 3 Jul 2005 17:48:37 -0400 (EDT) Michael Dunlap <michael.dunlap at yale.edu> wrote:
>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?

The development of the content-filtering module was triggered by
the release of AOL 6.0, whose MUA would not allow users to turn off
HTML formatting.  The HTML content was pretty annoying on mailing
lists that were plain-text by convention so I wrote MimeDel to
reduce everything to plain text -- that meant removing various
attachments and replacing multipart/alternative sections with just
their text/plain versions.  IOW, the undesirable behavior was
pretty much the original functional spec for the content filter.

Barry made MimeDel a lot more nicely configurable, robust, and RFC-
compliant when he incorporated it into the mailman distribution,
but the basic strategy for dealing with multipart/alternative
remains.  It shouldn't be difficult to provide for either keeping
all alternative sections with certain types, or to provide an
ordered list of types from which to pick the one alternative that
will be kept.  At the expense of a few more knobs, of course.

  -les

>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.
>>>> ...