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".
1. Mail out the included plain-text copy from the multipart email. Or,
2. 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 <m...@msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
_______________________________________________
Mailman-users mailing list -- mailman-users@mailman3.org
To unsubscribe send an email to mailman-users-le...@mailman3.org
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/KKKU3UKW6F5MC75PK43TBFKLHJODYG4J/
This message sent to arch...@mail-archive.com
