> 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.
Yes. Or, the more the topic is discussed, I see there are two parts. Hyperkitty rendering is one of them. The other being to find a way to sanitize HTML of outgoing emails. > 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. I hadn't thought about that situation. Maybe it is relevant after all. And then, you said that you are not interested in doing that. It might need to be investigated along with these other features. Not sure. > 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. The list's settings are Collapse alternatives=Yes and Convert html to plaintext=YES. Standard "plain" URLs are ok, but I was just now able to replicate some sort of problem. Using the yahoo toolbar, a fully HTML hyperlink with an href and name failed to render in plain text. It resulted in just plain text without appearing as a "link". If that's happening even now, maybe it won't get worse in the future. only better. if switching to html. > and most MUAs will render the converted html alternative. interesting... The future plan would be to set all filtering to NO. All MIME parts delivered. But then, what if a plain-text version is missing somehow. > 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. Understood. Problems remain though: "minus sanitizing". Sanitizing should be added. "HTML part(s) will still be rendered as attachments." The bulk of this discussion is about avoiding Hyperkitty attachments, and instead showing html inline. > If we receive a merge request to implement inline rendering of HTML, it will > be considered but no guarantees. Exploring the issue. _______________________________________________ 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/KDMZGBKKPVAYL6A4S4KKMNZZIPZ6537O/ This message sent to arch...@mail-archive.com
