On 9/8/25 07:22, Sam Darwin via Mailman-users wrote:
How about a feature to include "HTML" in the current Hyperkitty choices of (Text or Markdown) rendering?
I don't understand what you envision such a rendering to do. First of all, this setting only affects rendering in HyperKitty thread and message views of archived messages. It has nothing at all to do with messages delivered to list members.
Archived messages which contain text/html parts currently render those parts as attachments that can be downloaded. Are you suggesting that "HTML" rendering would render those inline or something else?
A sanitizer must be used to prevent malicious attacks. https://github.com/messense/nh3 . lxml is another package that processes html.
A sanitizer would be helpful for more aspects. Permit a limited set of markdown so that messages still appear professional. Gitlab/Github don't allow arbitrary fonts or font sizes, right? Mostly remove these tags.
A way that code blocks could be presented: determine an established list of known codeblock styles. Configure the sanitizer to permit this range of fonts or styling elements. By allowing them through the filter, a code styling is rendered. (It is permitted/allowed to be rendered.) Even better, when the sanitizer recognizes the fonts, it replaces them with an "official" set of codeblock fonts.
Otherwise, if other font tags are entirely removed, if they are missing, the email client or web ui will decide the font selection, and it will appear "standard".
Your reference to email client suggests you are thinking in terms of messages delivered to list members. HyperKitty's rendering mode has nothing to do with that.
In order for both email clients and Hyperkitty to view the same result, the sanitizer should ideally be applied to outgoing emails as well as rendering in the UI. That means this feature would affect more than just Hyperkitty. (i.e. mailman-core). Although, that could be implemented as a separate step, until which time emails would get a full range of HTML, without sanitizing.
As far as Mailman core is concerned, Things like this are handled in content filtering. In particular the settings Collapse alternatives and Convert html to plaintext.
In this scheme, ensure outgoing emails are multi-part MIME with plain text and html versions.
If the incoming message is multipart/alternative with text/plain and text/html alternatives and content filtering accepts all those MIME types and does not Collapse alternatives, the outgoing message will be the same.
If you're suggesting a text/html part outside of a multipart/alternative part should cause Mailman to create a text/plain alternative and convert the text/html part into a multipart/alternative part containing the text/plain and text/html alternatives, that could be done, but I'm not interested in doing it. We already have a mechanism for converting HTML to plain text, but current code replaces the HTML.
As far as converting plain text to HTML, the straight forward way to to that is just to wrap it in <pre>..</pre> tags, but there seems to be nothing gained by that. As far as converting urls and email addresses into clickable links, many MUAs already do that.
Some of our users are really in favor of more formatting.
Others prefer plain text.
Those who prefer plain text have various arguments that HTML messages will be rendered badly, and won't be legible.
All of the settings mentioned are per list, not user option/
Questions:
- Would "multi-part MIME with plain text and html versions both" solve the problem for users who prefer plain text?
If they set their MUA to render the text/plain alternative.
- What percentage of email clients that support HTML formatting when sending will also include a plain text rendering of the same content in the outgoing message?
Many if not all mainstream ones do or at least have settings to control it, but some do a horrible job. 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 - see <https://www.grizz.org/wiki/PostingURLsToLists>
- Is it usually the responsibility of a receiving mail client to be able to convert HTML to plain text if the user requests it?
If a message part is multipart/alternative and the user wants plain text, I think most MUAs will just display the text/plain alternative. If the message is HTML only, I suppose the MUA will convert it somehow.
- When mailman-core receives and then sends out a message, can it receive HTML, generate a plain-text version, and then send both?
Not currently. It can convert the HTML to plain text using a configured process such as lynx or elinks, but then only the plain text is sent, not both.
On the other hand, if the incoming message is multipart/alternative and content filtering is off or appropriately set, the outgoing message will be multipart/alternative.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan