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