[Mailman-Developers] MM3: Content filter rules

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> pass_mime_types
>  multipart
>  message/rfc822
>  text/plain
>  text/html
> 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
>
> multipart
> message/rfc822
> text/plain
> text/html
> application/pdf
> application/vnd.oasis.opendocument.spreadsheet
> application/vnd.ms-excel
> application/vnd.oasis.opendocument.text
> application/vnd.openxmlformats- 
> officedocument.wordprocessingml.document
> application/msword
>
> 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  
'select_text_plain_alternative'.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmsRV8ACgkQ2YZpQepbvXEi9gCfaHM0wf5dkmi1LQWzTo8RYnj8
eZ4An1nkLrJJdzxY+ZaYarHLI1fJKudu
=kDC3
-----END PGP SIGNATURE-----