Sam Darwin via Mailman-users writes:
Right, that is already the case. However equally important is formatting via the sanitizer, not just removing malicious HTML.
Not clear what "sanitization" you want to suggest here. Authors want HTML so they can have more control over the presentation than offered by Markdown (which most agents don't implement anyway). Sanitizing HTML likely breaks the intended presentation. Fundamental features of HTML such as links and automatic display of multimedia objects are obvious vulnerabilities, but disabling those will not make your HTML-loving users happy!
You are saying "All sorts of malicious malware can be attached to email in other than HTML parts." What is the solution to this currently?
Discard them or save them as attachments, usually as .bin with a non-specific MIME type such as application/octet-stream. Also, these are image/* and application/* parts, and malware filters run by the MTA know quite well what to do with them. The problem with HTML is that it's more amenable to social engineering than most such formats (PDF is an obvious exception).
We have "Collapse alternatives" and "Convert html to plaintext" enabled. If one of those is relevant
Relevant to possibly malicious email? As far as the documentation goes, maybe it should be changed to mention that.
But the default for "Collapse alternatives" is True. In the past most HTML mail was bundled with a plain text alternative, so that would take care of possibly malicious HTML parts. OTOH, assuming that HTML- only mail was deliberately configured that way by the sender, we did set the default for "Convert HTML to plaintext" to False to respect that intent, as it's likely that there is legitimate content that can't be represented as plaintext or attractively presented as a separate MIME part. I think that logic is still probably valid. And as Mark said, the likelihood that malicious mail will be sent via a mailing list is relatively low as long as it's set to members-only posting. So the current default settings seem like a good compromise, and it's not obvious to me that it's worth discouraging changing those settings if they're in demand from the subscribers and the list owner is OK with that.
For Mailman the real problem is that doing more than we currently do, and doing it well, would require construction of the DOM and a pretty capable CSS implementation, with features driven by what the full range of user agents implement. It's a lot of work, and it's not obvious what the benefit to most Mailman users would be, over and above offering "collapse = False; convert = False" as an option and defaulting to "collapse = True".
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan