It was thus said that the Great Jim once stated:
> 08.06.2019, 10:25, "Lorenzo Donati" <lorenzodonatibz@tiscali.it>:
> > Moreover, it is very bad netiquette
>
> another point would be abstaining from posting html formated
> messages.
I'm subscribed to a mailing list devoted to classic computers [1], and
*they* gave up on trying to enforce non-HTML emails (and top posting, and
... ). Sadly, it's a lost cause.
And for my case, you're wrong, the mails were sent from some machine running some Linux or BSD system (anything that Google wanted for its Gmail service). And they're definitely NOT old computers, but very modern ones, highly optimized for efficiency and security.
I've abandonned since long any use of local mail clients (because they were very unpractical and storage was at much more risk. Security was not even better locally than what Google can do itself on its servers, and with much better handling and detection of spams. You may argue that privacy is an issue, but privacy is definitely not one for public mailing lists like this one.
So yes this is a lost cause (otherwise Gmail would have enforced it since long, but it NEVER made that even the default). So any claim of "netiquette" about this placement is simply fake, it may have been proposed by a few but never accepted and supported by a large majority. The same is true about HTML posting (that still works much better than plain-text only messages) and must ALWAYS used with the dual encoding (HTML original + altered plain-text only for those that use very antique softwares that can't even parse a safe basic HTML syntax that shows at last the content but can still disable any form of active scripting, including links to external images not part of the mail as an attachment, or tracking pixels).
In fact emails should use HTML-only by default now. Plain-text-only is outdated and not reliable (it breaks legitimate contents to give non-sense), and the current HTML+plain-text format shouls now no longer be necessary (if you use Lynx, Lynx can still perfectly parse HTML and render its text; otherwise if your agent can only process plain-text, it is definitely antique, and most probably dangerous for you to use, or at least very unreliable, given the many inconsistencies left in the old RFCs supporting it but that were never solved correctly... before the arrival of MIME and the shared development with HTTP that allowed full interoperability and HTML then made the default (and now efficient, consistant and secure since the huge HTML5 efforts) !)