On 9/8/25 13:20, Sam Darwin via Mailman-users wrote:
I don't understand what you envision such a rendering to do.
To achieve a level of rendering emails (and web) similar to gitlab or github. That includes bold, italics, code blocks, and possibly more. In both Hyperkitty and email clients.
If an incoming message contains HTML and it is not filtered or replaced by content filtering, it will be in the outgoing message and the message sent to HyperKitty. Thus, all you are asking here is that there be an option for HyperKitty to render the HTML (perhaps sanitized) inline as opposed to leaving it as an attachment. I understand that request.
Hyperkitty is one of the two main components. It's the web UI part. The other being the outgoing emails.
Actually Mailman core is the main component. Postorius and HyperKitty are really just examples of web based list management and archive rendering applications that communicate with Mailman core via it's REST API. Others have been developed, e.g. EMWD's Affinity and Empathy applications. This is really just and aside, but my point is that Postorius and HyperKitty are not integral parts of Mailman.
If you're suggesting a text/html part outside of a multipart/alternative part
I was probably imagining just "multipart/alternative", containing alternatives. Is the "outside" method also a possibility? I did not intend that.
I was asking if you envisioned that a text/html part outside of a multipart/alternative part would cause mailman to create a text/plain alternative and package it with the text/html part in a multipart/alternative part. But if that was not your intent, OK.
For example if in Yahoo mail one composes in "rich text" and drags and drops or copy/pastes or in some ways even types a link, the generated text/plain alternative doesn't contain the url in any form.
Our lists are set to "Convert html to plaintext". I just tested from Yahoo email, with rich text, and hyperlinks. Everything was fine. The problem didn't exhibit itself. I also "copied" a link from a website, and pasted it into the email, but it was ok. Perhaps other clients "aol.com, att.net, netscape.net, pacbell.net, prodigy.net, rocketmail.com, sbcglobal.net and ymail.com" have a problem? But today in mail.yahoo.com , no...
The issue is not in the plain text converted from the HTML by Mailman's Convert html to plaintext feature. The issue is in the text/plain alternative created by Yahoo when a message is composed as "rich text" and created by Yahoo as multipart/alternative. Were you looking at that text/plain alternative part from Yahoo., i.e. what you see in the outgoing mail if Collapse alternatives is Yes.
If most mail clients include Yahoo and Gmail send both HTML and plain-text versions in a multipart message, there would theoretically be two choices for mm3 with "Convert html to plaintext".
- Mail out the included plain-text copy from the multipart email. Or,
- Parse the HTML part of the message and "convert html to plaintext". which of those is occurring?
1 occurs if content filtering Collapse alternatives is Yes.
2 occurs if Convert html to plain text is yes, but the result depends on Collapse alternatives. If Collapse alternatives is Yes only the original text/plain alternative will be in the outgoing mail. If Collapse alternatives is No, both the original text/plain alternative and a second text/plain alternative consisting of the Mailman converted HTML will be in the outgoing messages multipart/alternative part, and most MUAs will render the converted html alternative.
To summarize again, the goal is to show in Hyperkitty and in email clients a format (based on HTML) that includes bold, italics, bullet items, and code blocks.
If you want email clients to display the HTML, either don't filter content or filter content and pass both multipart and text main types and set both Collapse alternatives and Convert html to plaintext to No.
This will accomplish what you want minus the possible sanitizing of the HTML for Mailman core and delivered messages. In HyperKitty, the HTML part(s) will still be rendered as attachments.
If we receive a merge request to implement inline rendering of HTML, it will be considered but no guarantees.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan