Please add multipart/signed to DEFAULT_PASS_MIME_TYPES
Hi,
By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file with this configuration:
DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain']
So, when someone enables filtering on a mailing list by mime-type, the default is to filter all emails not matching any of those 3 mime-types.
Therefore, this is unfortunately filtering multipart/signed emails.
multipart/signed is defined on RFC 4880 and 3156 and is the recommended way of signing mails with GPG: See http://wiki.gnupg.org/SignatureHandling As an example, this email is multipart/signed.
This default causes trouble to people that signs their mails with GPG. I already had problems due to this default on the Alioth Debian mailing lists and on the WebKit mailing lists.
Please, change this default by adding multipart/signed to the list of types allowed.
Thanks.
On 11/16/15 6:14 PM, Carlos Alberto Lopez Perez wrote:
Hi,
By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file with this configuration:
DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain'] ... Please, change this default by adding multipart/signed to the list of types allowed.
There are other issues, but if you file a bug, I will change it to ['multipart', 'text/plain', 'application/pgp-signature'] or ???.
There are other signature types that are 'binary' rather than plain ascii text, and I'm reluctant to include those. On my own site, I include 'message/rfc822' as well and could consider that.
File the bug at <https://bugs.launchpad.net/mailman/+filebug> for MM 2.1 and <https://gitlab.com/mailman/mailman> for MM 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 17/11/15 07:29, Mark Sapiro wrote:
On 11/16/15 6:14 PM, Carlos Alberto Lopez Perez wrote:
Hi,
By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file with this configuration:
DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain'] ... Please, change this default by adding multipart/signed to the list of types allowed.
There are other issues, but if you file a bug, I will change it to ['multipart', 'text/plain', 'application/pgp-signature'] or ???.
I was thinking in changing it to :
['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain']
Instead, you suggest to just add [ 'multipart' ] to the list. I have 2 questions:
- Will 'multipart' match all the 3 previous multipart/variations?
- Is there any multipart/variation that we shouldn't allow by default?
If the answer is yes to the first question and no/notsure the second one, then I think is a good idea to just add 'multipart'
Not sure regarding 'application/pgp-signature'. I guess we can include it also.
There are other signature types that are 'binary' rather than plain ascii text, and I'm reluctant to include those. On my own site, I include 'message/rfc822' as well and could consider that.
Sounds like a good idea, probably is also worth including message/rfc822 in the default list of accepted mime types.
File the bug at <https://bugs.launchpad.net/mailman/+filebug> for MM 2.1
Filed: https://bugs.launchpad.net/mailman/+bug/1517446
and <https://gitlab.com/mailman/mailman> for MM 3.
I wasn't able to find a Defaults.py on the Mailman3 tarballs. Neither an alternative config file with this default.
Where are the defaults of Mailman 3 specified? Has the default for DEFAULT_PASS_MIME_TYPES changed?
Regards
On Nov 18, 2015, at 01:35 PM, Carlos Alberto Lopez Perez wrote:
I wasn't able to find a Defaults.py on the Mailman3 tarballs. Neither an alternative config file with this default.
Where are the defaults of Mailman 3 specified?
System-wide defaults in MM3 are specified in ini-style .cfg files, but that's somewhat irrelevant to this case.
Has the default for DEFAULT_PASS_MIME_TYPES changed?
Actually, there aren't any default pass or filter types on the mailing list objects currently, although if a list is migrated from MM2, the filters are ported over.
When a mailing list is created, a 'style' is applied. An implementation strategy would be to add the pass and filter types to a style. Probably BasicOperation class in src/mailman/styles/base.py. Or refactor the filter/pass stuff into a separate style class which can be composed in the LegacyDefaultStyle class. Extra points for adding the defaults to the schema.cfg file.
If you want to submit a bug against MM3, please have it say something like "add MIME pass and filter types to the default list styles".
Cheers, -Barry
On 11/18/15 4:35 AM, Carlos Alberto Lopez Perez wrote:
I was thinking in changing it to :
['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain']
Instead, you suggest to just add [ 'multipart' ] to the list. I have 2 questions:
- Will 'multipart' match all the 3 previous multipart/variations?
'multipart' will match any MIME multipart/anything content type, including those 3 and multipart/related, multipart/report, etc. See <http://www.iana.org/assignments/media-types/media-types.xhtml#multipart> for the registered sub-types, but some MUAs may create even others.
- Is there any multipart/variation that we shouldn't allow by default?
Multipart parts are those which contain other parts as sub-parts. Since ultimately, the elemental (non-multipart) parts that are contained in the multipart part must be explicitly allowed, passing any multipart part should be safe.
I.e., considering your issue, you want to accept text/plain parts but they are contained in a multipart/signed part which is not accepted, so those parts are removed.
It doesn't matter what multipart types you accept. If the only elemental parts you accept are text/plain, the only elemental parts that will remain after filtering is text/plain parts.
If the answer is yes to the first question and no/notsure the second one, then I think is a good idea to just add 'multipart'
Not sure regarding 'application/pgp-signature'. I guess we can include it also.
This depends on your objective in accepting multipart/signed. If you only care about accepting the text and don't mind if the signature is stripped, you don't need to accept signature parts, but if you want to actually deliver a signed or partially signed message to the list, you need to accept the signature parts as well. These include in decreasing order of frequency observed, application/pgp-signature, application/pkcs7-signature and application/x-pkcs7-signature.
Noted. Thanks.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Carlos Alberto Lopez Perez writes:
Instead, you suggest to just add [ 'multipart' ] to the list. I have 2 questions:
- Will 'multipart' match all the 3 previous multipart/variations?
Yes.
- Is there any multipart/variation that we shouldn't allow by default?
The only other multipart I can think of offhand is multipart/related. Let's see what Google turns up: multipart/form-data (probably shouldn't be allowed, but very unlikely to show up except perhaps in an attack), multiport/report (used for email reports such as delivery status notifications, but it's basically multipart/mixed -- not a problem that I can see, but perhaps should trigger administrivia filters), and multipart/encrypted. There is also at least one that is mostly useful in HTTP (multipart/byteranges).
Sounds like a good idea, probably is also worth including message/rfc822 in the default list of accepted mime types.
That's a definite "maybe". There are known to be MUAs that can't handle embedded messages. (That's why we can't recommend "Wrap Message" as the standard workaround for DMARC.)
participants (4)
-
Barry Warsaw -
Carlos Alberto Lopez Perez -
Mark Sapiro -
Stephen J. Turnbull