> The first is reflected in the users FAQ 3.10 "How to enforce a
> text-plain policy". The answer being "with difficulty" because this
> option probably (as I read it) ensures that any message with
> non-plain-text content is completely, utterly, and totally, rejected,
> even if plain-text is present,
That's true for Mailman 2.0, which I hope nobody who doesn't have a
very good idea of what they're doing is using anymore.
For Mailman 2.1, almost all of the time the presence of a text/plain
part means the message will get through in tolerable shape given the
recommended settings. And assuming you have one of the non-GUI web
browsers (usually lynx) available to generate text/plain from
text/html, most of the time you should get something usable from
text/html, but that is only as good as the conversion tool is.
> The second is Content Filtering. I understand that this is to remove
> objectionable content types, and steamroller the rest into conformity as
> plain-text. It appears not to be 'on' by default.
AFAIK it actually only knows how to "steamroller" text/html, although
a modest amount of programming (== "Somebody on this list can post a
patch with a few minutes thought") should allow pretty much any text/*
type to be converted. Other non-objectable content types will be
passed through unmolested, on the assumption that the list admin
believe the MUAs in use can handle them.