Comment 2 for bug 1517446

Revision history for this message
Mark Sapiro (msapiro) wrote :

The tarballs we distribute do not contain Mailman/Defaults.py. They and the lp:mailman/2.1 branch contain only Mailman/Defaults.py.in. Mailman/Defaults.py is generated by configure by applying various configure options and defaults to Mailman/Defaults.py.in.

Also, in Python,

DEFAULT_PASS_MIME_TYPES = ['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain', ]

and

DEFAULT_PASS_MIME_TYPES = ['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain' ]

(without the last comma) are equivalent.

Now, as far as the actual bug is concerned, I am unsure as to the best default for pass_mime_types. I agree that various multipart subtypes such as multipart/related and multipart/signed should be accepted so their text/plain sub-parts will be accepted. To this end, I think at a minimum we should have

DEFAULT_PASS_MIME_TYPES = ['multipart', 'text/plain']

to accept any text/plain subparts of any multipart type, but this brings up other questions. Namely, should we accept message/rfc822 parts to ultimately accept text/plain parts from attached (forwarded or ?) messages, and if we are accepting multipart/signed, should we also accept the actual signature.

For the former, I think the answer is yes. The latter is more complicated because application/pkcs7-signature parts are binary so in the spirit of only accepting text/plain, perhaps we should only accept application/pgp-signature signature parts. I'm tending towards

DEFAULT_PASS_MIME_TYPES = ['multipart', 'message/rfc822', 'text/plain', 'application/pgp-signature']

but I'm continuing to think about it.