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.) _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
