Note: converting an HTML message to plain text should be done according to the specifications of DKIM/DMARC:
- either sign a message where you have attached BOTH the HTML version and the plain text-version (embedded as separate MIME entities); sign separately these two versions, so that the mailing list can choose to forward both or only one.
- or send only the HTML version, but use a correct filter that will strip all HTML tags (keeping only the plain-text elements) to compute the plain-text signature. However, if the mailing list accepts to transfer the HTML content (including tags), it has not been signed entirely and the mailing list server could then forward malicious HTML (e.g. scripts).
An advanced mailing list server can accept to transfer HTML messages provided they only use "safe HTML", excluding unsafe scripts (including in attached images which could have active scripted elements when rendered, or external unattached images like tracking pixels). This requires advanced parsers inside the mailing server to assert the security of embedded links and embedded or external images.
If the mailing list server has limited processing capabilities, the only thing it can do is to drop the HTML (and all attachments, including images in formats that can embed active links or scripts, like various multimedia formats including MPEG, OGG, SVG if it is rendered directly in the mail agent used by the recipient)
Some webmails provide a security that allows previewing HTML messages without rendering any active parts, such as external images frequently used as trackers, and embedded images or embeded multimedia files, that won't "autostart": these mail agents require a first click of activation of their content to "play" them on demand, so these attached images can still be used and rendered, but only in a static way without any script and without contacting any external server). But many webmail agents rendering HTML messages do not have this security.
So a mailing list server would need to first scan the attachments that use "safe standalone formats", like PNG, JPG, GIF, and standalone SVG with all scripts filtered out (attachments would have then their signature removed if a filter has been applied to them). Note that some PNG/JPG/GIF formats were not completely in valid formats, and this allowed to attack some of their renderers that did not validate these format before rendering them, this has been fixed for many renderers. But antimwalware tools know that these images in invalid formats are still seen in spammed messages to harvest the bugs of old unpatched renderers (notably in audio/video formatsn, which are very hard to validate without first "playing" them completely in a checked sandbox detecting validation errors before they become harmful: such sandbox is very costly to implement on a simple mail server, so the only thing that can be done is to restrict the set of "safe" formats allowed for attachments, which do not require a complex scanning: it is possible at low cost to accept unscripted SVG; all other formats will need to be separate attachments (that may be scanned separately with some external antimalware detection tool).
Alternatively, the mailing list server could also change the kind of attachment that it cannot fully validate itself: pinned file attachement instead of inline attachments (this changes only the MIME enveloppe, no need to change the contents of "pinned" attachments and no need to change the DKIM/DMARC signatures applied to the main content part or to the alternative plain-text content part), so that the only way for the recipient to see the attachment would be to save it locally as a file (which can be scanned locally by antimalware tools, before opening it to play it) and make embedded links to attachements inside the HTML inoperant (like broken links, going to a non-existant attachment MIME-id), without even needing to change anything the HTML part (except scripted HTML attributes like _onload_="..", or href="" whose URL is using an external scheme instead of the local link to an attachment MIME-id: those need to be filtered but this will invalidate the HTML signature)
