Re: Posting netiquette: HTML, attachments etc.

On Sun, 26 Jun 2022 20:59:04 +0200, Baptiste Daroussin wrote:
> On Sun, Jun 26, 2022 at 12:32:41PM -0600, Warner Losh wrote:
> > On Sun, Jun 26, 2022, 12:20 PM Walter Parker <walterp@gmail.com> wrote:
> > 
> > > So, utf-8 is good, posting to multiple lists is bad (but ok when you do
> > > it), what about the original post? He was asking about HTML. UTF-8 != HTML.
> > > UTF is a character encoding format. It is supported by most email clients
> > > and does not require HTML for support.
> > >
> > 
> > Html is fine as well. Most modern mail platforms generate it for you,
> > whether you want them too or not. Most of the advice in appendix c is dated
> > and doesn't really match what people do on the lists. Phones and web based
> > Gmail are to large a presence to ignore or have policies against. I stopped
> > listening to complaints about how Gmail or my phone formatted posts 5 years
> > ago... and I'm definitely an old school straggler...
> > 
> > Warner
> > 
> 
> Note that the mailing list engine will reject html only email, html is fine as
> long at it is created with text/plain alternative.

At least, that's what the established standards and RFCs say.
However, "smart" and "modern" MUAs often fail to so so, and
even _if_ there is a plaintext counterpart...

On Mon, 27 Jun 2022 03:54:38 +0200, Ralf Mardorf wrote:
> [...] These days almost all
> multipart/alternative messages contain unreadable formatted plain text,
> let alone that I several times received multipart/alternative messages
> with a text/plain saying "yes" and a text/html saying "no". IOW
> text/plain and text/html of a multipart/alternative message could be
> two completely different texts.

Yes, that is sadly the truth.

Furthermore, some MUAs completely mess up the linebreaks and
quoting indentation in the plaintext part, so it is no longer
usable for a conversation. :-/

Another valid point against HTML: As it has been mentioned
as follows:

On Sun, 26 Jun 2022 12:02:51 -0700, Walter Parker wrote:
> Breaking DKIM so
> that you can make emails 7 bit ASCII clean is a bad idea in the modern era
> (where security is a now actually a thing).

Security is a thing that can easily be fought by using HTML,
for example in the <a href="evil.example.com/pwn.html">handbook</a>
you can see how easy that is. Combine this with "UTF-5 lookalikes"
for certain letters and you're ready to go. And then there is
all the stuff like "hidden requests" (the "1x1.gif trick"),
external resources ("But I want this font!") as well as content
control handed over to a 3rd party ("Look at the screenshot!"
where example.com/screenshot.png is now showing NSFW content).
Now combine this with the inability of certain message processors
to even handle HTML correctly and greater than semicolon and
emdash a-circle one-fourth and amp semicolon.

Imagine all this also going invisibly to the mailing archives.

The next big thing could be allowing HTML with inline JS in the
mailing list messages which will be expected to be processed by
the user's MUA... and the archives... ;-)

"But that is needed for proper display! I want animation!"

My very stupid opinion is that things should be easy. Plain text
is easy. It is the default, as per the standard. A MUA not being
able to support the lowest common standard is not a program that
one should be using. Either switch to something else or demand a
program chance by the author. If you're already in a walled garden,
then it's not your choice anyway. Funny to see that even decades
old programs can do this fine, deal with HTML and plain text, and
both display and create messages in the correct character set
without problems, using the default settings.

Yes, I'm a very old person failing to understand "shmart". :-)



PS.

The only thing I _personally_ would like to have the mailing list
accepting is image support for JPG or PNG for the purpose of
showing screenshots in situations where you cannot get the text
into the message body (typing a few lines is okay, but imagine
it's about a kernel stack trace that doesn't end up in a kernel
core file, for some strange reason). Such images could probably
be subject to moderation. And of course they should only be used
as needed.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...