[Mailman-Developers] MM3: Content filter rules

[Bob Puff@NLE]

Mark Sapiro wrote:
> Barry Warsaw wrote:
>   
>> So I'd like to solicit your input on how you use the feature, and if  
>> you have any ideas for an approach that would be easier to understand,  
>> more useful, or both.
>>     
>
>
> 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
>
>
> 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.
>
> 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...
>
> 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.
>
> 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.
>
>   
If there was a way to have the filters also work based on file 
extensions, that would be a definite plus.  Granted, mime types are 
usually right, but as you pointed out, not always.  Same thing goes for 
file extensions.  Its a messy world!

Bob