[Mailman-Developers] MM3: Content filter rules
barry at list.org
Mon Mar 2 21:45:19 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Mar 2, 2009, at 2:15 PM, Mark Sapiro wrote:
> My typical list is set up as follows to allow plain text only. List
> mail is not signed so I don't have that issue.
> filter_content -> Yes
> filter_mime_types -> empty
> filter_filename_extensions -> default, but irrelevant
> pass_filename_extensions -> empty
> collapse_alternatives -> Yes
> convert_html_to_plaintext -> Yes
> filter_action -> Reject
It's interesting how simple it is for you to explain what you want,
but how complicated it is for you to make Mailman do it!
> I have one list which is used to discuss the planning for an annual
> event (century bicycle ride) which we run as a fund raiser. Since it
> is not possible to get all the people involved to understand that
> there are alternatives to attaching spread sheets and word processing
> documents, this list is set up as above except that pass_mime_types is
> set to
> This generally works except for one user's misconfigured Microsoft
> Outlook/Exchange that attaches a PDF as application/octet-stream.
> There's no good way around that (other than fixing the source). We
> could accept all MIME types and filter only on file name extension,
> but that would accept anything without a name or with a name without
> an extension.
Touching on the plugin idea, let's say you had a generic whitelist
filter. It would seem that some level of user configurability should
be exposed in order to allow you to configure this.
> In fact, given the nature of this list and its membership, I could
> probably accept everything and just collapse alternatives and convert
> HTML to plain text and it would be OK.
> BTW, as an aside regarding collapse_alternatives, I have seen on a
> non-Mailman list, non-compliant posts from a Lotus notes user that
> have the text/html alternative preceding the text/plain alternative in
> a multipart/alternative part. I don't know what you do about that...
I'm not sure either, except perhaps it shouldn't be called
'collapse_alternatives' but instead something like
> As far as ideas for improvement go, I don't know if anyone actually
> uses filter_mime_types. It seems best to "whitelist" what you want
> rather than trying to "blacklist" what you don't want. I think we
> could probably do without filter_mime_types.
And probably the same with extension types? I think I agree with you!
> The other confusing point for some users is they have to allow various
> multipart/* types in order to allow the sub-parts they want. Possibly
> we could do something where you just specify the elemental content
> types you want to allow, and we examine all multipart parts implicitly
> and accept those elemental sub-parts that are allowed.
This is a good idea too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
-----END PGP SIGNATURE-----
More information about the Mailman-Developers