
Use plaintext email - ddevault
https://useplaintext.email/
======
jve
> Rich text features desirable for end users include things like inline
> images, bold or italicized text, and so on. However, the tradeoff isn't
> worth it. Images can simply be attached to your email, and you can employ
> things like _asterisks_ , /slashes/, _underscores_, or UPPERCASE for
> emphasis.

Well, why bother writing his own post in rich text then? He has headings,
bold, links, grey font at the bottom, image.

Don't get me wrong - for high security systems/environments, plaintext is way
to go. For everyday life use cases I prefer html. Although with Markdown
rendered text I would be pretty happy. And enough for author to cover his post
sans the green/red boxes and grey text.

~~~
DarkCrusader2
The page footer might interest you. It directly answers your question.

Quoting

    
    
      "But if plaintext is so good, why is this page written in HTML?" 
      This is a reference document, not an email, you twit.

~~~
wongarsu
But emails can be reference documents too! In fact I would argue most work
emails that are longer than a few lines are a reference document of some sort.

~~~
upofadown
Then you are better off using some format that can stand alone as a file such
as PDF. If it is a reference document that is intended to be edited on an
ongoing basis it is better to use something like a wiki. Having to root around
in your email to find a reference document is pretty inefficient and annoying.

~~~
lawn
We send syntax highlighted code all the time via email at my job. I hope
you're not suggesting we should use PDF instead?

And no, creating snippets on a wiki is also an extra unnecessary step. Email
is just easier and faster.

~~~
upofadown
Syntax highlighted code can hardly be considered a "reference document".

~~~
bgdnyxbjx
For the life of me I can’t remember the syntax for a particular thing I do in
the JavaScript console at work. Someone showed me the trick in an email about
seven years ago and about once a month I need to do this thing so I search my
inbox for the email so I can remember the syntax.

------
jraph
Some people sending plain text mails also wrap them manually.

If my window is small (maybe because I am using a small screen), the text is
painful to read. And a non manually wrapped plain text is not wrapped at all
in some cases.

By all means, send me plain text mails, it will be lighter for my self-hosted
inbox, but don't wrap them manually.

If you are going to _abuse_ /this/ kind of `formatting`, however, you are
making your mail harder to read for me. These are tags anyway, just not HTML
tags. I'd prefer you use the real formatting that is correctly handled in most
cases, but I will adapt.

> There are two main types of emails on the internet: plaintext and HTML. The
> former is strongly preferred

You will need to back this up because this is not what I observe.

My email client takes care of my privacy and my security, and you can use it
too if you are concerned, it's a cross platform maintained free software. It's
okay.

My problems with HTML emails is colors: if you want to use something like a
night mode, you will see emails with hard coded white background and black
texts, or worse, only black texts. You may be able to ignore colors but people
will assume you can see them. Maybe an extension like dark background on light
texts when using a browser for reading emails who do the trick, but I don't.

~~~
upofadown
>If my window is small (maybe because I am using a small screen), the text is
painful to read.

If your screen is so small that it can't display 80 characters across then
pretty much anything you look at it with is going to look odd. Any HTML
formatting such as tables will also be painful to read.

~~~
jraph
I like big characters. I can be far from my screen to read, use a low
brightness and never have tired eyes.

I just checked on my phone some random opened web page: with my settings
(which are far from the default - I raise the DPI setting and the font size so
I have small UI elements but big texts), it displays 45 characters per line on
portrait mode. Actually the font size is a bit too high, but I don't really
care as far as most web pages are readable. I'm fine with scrolling the
occasional big HTML table, and will change the settings if this becomes
annoying.

So, yes, sometimes, my screen displays less than 80 characters and is
perfectly usable. And this fact is not really of my correspondent's business,
whether they choose to manually wrap at 80 characters, 72 characters, 42
characters or some other arbitrary number of characters. Actually, nobody
knows that apart from people who read this comment. I display text as I see
fit (and this is totally an intended pun).

------
yyyk
Plaintext email is really troublesome if one wants to mail in an right-to-left
language. There's simply no compatible way to override the direction/embedding
without HTML * , so content is often scrambled.

Many mailers won't even align to right automatically if all input is in an
right-to-left language. In practice, HTML email is the only compatible way to
get a semi-decent experience for these languages.

* To answer the obvious: the unicode bidi override characters are not a solution. They are often stripped out, and editing zero-width characters is a very 'pleasant' experience.

~~~
gmueckl
Where are these characters stripped out? I can see that these create security
issues with urls that get rendered with changed field order to look benign.

~~~
yyyk
I meant stripped from the mail body - though I suspect these programs would
also strip them out of the other fields (I haven't checked that). In general,
working with zero-width characters is a bad idea from both security and
usability POV and is not a practical solution.

The result is that the only reasonable and compatible way to mix LTR (left-to-
right, like English) and RTL (right-to-left, as with ME languages) is with
HTML email. Note that in most cases rendering is an LTR context, so even
sending RTL on its own will fare poorly.

------
tqwhite
What a load of bollocks. The arguments against come down to, 'you are an idiot
who can't figure out phishing links' and, well, that's it. Something about
marketing emails. Stupid. Luddite. I'm surprised they don't insist you use a
monospace type face in your email reader to give it that late eighties feel.

I have always used HTML email, even when it was new and poorly supported. I
want people who read my email to see a nice appearance. I like bold face and
sometimes images.

"Strongly preferred". An appeal to the Authority Fallacy is an indication of a
weak argument. Or, no argument at all.

~~~
owenmarshall
I think this opinion is strongly worded and might get some heat, but I think
you touch on something important.

Plaintext email often serves as an in group shibboleth to distinguish “us”
from “the other lusers”. Does it have merit beyond that, or do these articles
just reinforce that?

~~~
mbreese
I think the main issue at play here is quoting. In particular, how bad rich
text/html mail programs are at dealing with inline quoting. In my opinion,
that’s the main “feature” of email communication that has been lost over the
years. On the top replies make it difficult to follow a nested thread of
emails.

If html email clients handled this better, I don’t think there would be as
much of a problem. I think you’re right though that plain text acts as a bit
of a shibboleth to differentiate “advanced” users vs luddites. But the main
thing that I’ve heard people complain about with respect to html email is the
loss of inline quoting.

Plaintext has its issues too— in particular long line soft wrapping. Which
some would argue would be better supported if html email hadn’t become so
popular.

~~~
tln
I absolutely agree -- the aspect of email I miss from the good ol' days was
well-trimmed replies and doing so inline. Threaded inboxes and smart trimming
helps, but not completely.

However I think that HTML clients handle this well enough but the etiquette
has been completely lost.

    
    
        Because it messes up the order in which people normally read text.
        > Why is top-posting such a bad thing?
        >> Top-posting.
        >>> What is the most annoying thing in e-mail?

------
owenmarshall
I’d love someone to convince me I’m wrong - but I think we’ve lost this fight.

Years of use of plaintext hostile clients by people who read our emails means
bottom posting or inline replies are seen as extremely strange, and impossible
when you have one of those “seven email deep” threads forwarded to you. (I
know, I know, “snip it down”, but sometimes I just don’t have those minutes in
my day ;))

Wrapping as well has given me trouble - I'm not sure what I settled on but I
went through a period of having some users see my emails come across poorly
formatted. And to that note, IIRC Outlook doesn’t do a passable job with
plaintext mail, instead shoving monotype text in an ugly system font. The last
time I checked I don’t think it converted > into quoting and just vomited them
up.

I don’t know what the solution is beyond reluctantly accepting that we have to
both consume AND produce HTML email now, and make tools that do it gracefully.

~~~
superkuh
There's no losing as long as you're being the change you want to see. I will
always send plaintext emails and I have the technical skill to dig into the
raw email and decode the encoded HTML data manually or rip out the relevant
authorization URL/strings.

~~~
owenmarshall
You’ve just made the problem an externality. While you have the skill and
desire to do that - and to be clear, as a mu user I do the same dance when I
need - inbound messages are rarely the problem for me.

What is a problem is outbound messages. When I try to do (what I think is) the
right thing and trim the message and reply inline or bottom post, confusion
abounds. I’ve had messages missed because the recipients told me they thought
I accidentally sent an empty reply and didn’t scroll past the “on July 24th,
superkuh wrote:”

Whose fault is that? Is it the 20 people on the distribution list who learned
email protocol from years of Outlook and not “the right places?” I don’t feel
comfortable pushing that blame onto them.

~~~
jefftk
_> I’ve had messages missed because the recipients told me they thought I
accidentally sent an empty reply and didn’t scroll past the "on July 24th,
superkuh wrote:"_

A common way to handle this when writing to people who aren't likely to expect
an inline response is to put "Responses inline below:" at the very beginning,
and then respond inline as usual.

------
ubermonkey
My god, this is never going to die, is it?

I mean, I get it. There are some things about plaintext that are nice, or that
really appeal to the kind of people who read HN. I used to have arguments
about this, too -- but it was 20 years ago. Today, the ship has fucking
SAILED.

And you know what? It's GREAT. I send formatted email constantly -- and
they're better for it. Being able to embed screenshots is awesome. Being able
to use color, or bold, or italics, makes a difference in communication.

It's done. I'm not going back to plaintext, and I can't imagine most people
will, either. There's no good reason to (in particular, the downfalls of HTML
the author lists are all either easily solved or are issues orthogonal to the
format of the email.)

~~~
u801e
> Being able to embed screenshots is awesome. Being able to use color, or
> bold, or italics, makes a difference in communication.

Yet, you cannot do any of that on HN (other than a limited case like _italic_
). But, we can communicate just fine without those features.

I suppose it's really a difference of a read once message versus having a
discussion. In a read once message, you can format it like you describe.
That's how most blogs and web pages work. But if you want to have a
discussion, then plain text with very limited markup works best since it
minimizes the required vertical scrolling and it allows you to see the overall
discussion since you can view more messages in the given screen space.

~~~
neuronic
Communicating just fine is not the same as communicating at optimum.

In the analog world, you _could_ just hand over a white, plaintext birthday
card. Or you could give one with a motive, color, some doodles and maybe a
memorable photograph attached.

Which one is more memorable?

"It's used by marketing." is not an arguments against it. We have
sophisticated spam filters. Update your rules then.

~~~
zepolen
Go and visit a forum where embedded images are allowed and tell me that there
is any sort of "optimum" discussion over there.

In the end what happens is people use text overlays in the IMAGES in order to
reply to each other.

Since you edited your response to mention the birthday card:

Yea - on the one hand you can leave a boring "Happy Birthday" message with
lots of glitter to make it memorable.

Or you can make the _message_ memorable.

~~~
SifJar
An internet forum (presumably we're referring to a public forum here) is a
very different communication medium than email (especially when used in a
professional context)

~~~
u801e
> An internet forum (presumably we're referring to a public forum here) is a
> very different communication medium than email

Not really. Take a look at any email discussion like the Linux kernel mailing
list or the git mailing list. Same thing with newsgroups (usenet).

~~~
arbitrage
> Same thing with newsgroups (usenet).

good lord, how old are you?

~~~
darkpuma
I was participating in rec.games.roguelike.development until 2011 or so. Some
of those communities lasted a lot longer than most would expect.

------
zaarn
>HTML as a vector for phishing

I would disagree, You can make Text-only links look fairly harmless too. The
issue is more often that people do not look at all, even in text-mail, what
the link points to, not that they can't see it (plus you can hover and the
browser still shows the URL once you open it)

>Privacy invasion and tracking

Only if you use an ancient and outdated client that doesn't block external
resources by default or proxies them over another server.

>Mail client vulnerabilities

Only an issue if the client rolls their own HTML renderer. Outlook uses the IE
Trident Engine, Thunderbird uses Firefox' engine, Gmail transforms using the
Chromium engine internally. That means the email client is usually as secure
as the respective browser, unless you use a mail client that rolls their own
engine.

>HTML emails are less accessible

Possibly, depends on the sender. You can make them more accessible than Text
though because you can prevent the screenreader from trying to read out the
link or irrelevant information.

>Some clients can't display HTML emails at all

Most mail clients will usually bundle a text-version of the mail, some MTAs
also do this on their own. Doesn't really matter in practise since 99.99% of
people use a mail client that can display HTML.

It feels a bit like complaining that people on the highway drive so fast that
you can't properly merge into the rightmost lane with your oldtimer car.

>Rich text isn't that great, anyway

And tbh, this last one basically seals it; this is a website made to rant from
the personal perspective of someone who blocks mails containing any HTML from
their services and has quite the history of throwing people using their lib
under the bus over personal preferences.

I don't see how any of this is relevant when even the site itself admits that
using a multipart mail with both text and HTML is sufficient, why should I
even begin to send plaintext instead of doing that?

Unless your mailclient is garbage, it handles multipart and will understand
the mail.

~~~
u801e
> You can make Text-only links look fairly harmless too.

Could you give an example? As far as I know, you cannot do something like
making a link look like it belongs to a completely different domain.

~~~
zaarn
Examples from what I've seen:

    
    
        https://account:paypal.com.login@verified-account.com/phish
    

This, to the untrained eye, might at first glance look like a paypal.com link.
In fact, it belongs to verified-account.com and it abuses the capability of
URLs to contain a username and password to make it look legit.

~~~
zepolen
Don't even need that account: at start, this works in chrome:

[https://www.paypal.com@google.com](https://www.paypal.com@google.com)

~~~
b3n
In Firefox it tells me:

    
    
        You are about to log in to the site “google.com” with the username “www%2Epaypal%2Ecom”, but the website does not require authentication. This may be an attempt to trick you.
        
        Is “google.com” the site you want to visit?

~~~
jefftk
From the error message it sounds like if this was an attacker controlled site
configured to require authentication it wouldn't trigger? If so it's not that
useful a defense since whether to require auth is entirely under the
attacker's control.

------
masukomi
I just want to put it out there, that regardless of if this is a "fight worth
fighting" or not. Email was a nightmare for me. I could not keep up. Coworkers
would catch themselves and laugh when they asked if I'd gotten an email.

Switching to neomutt has changed everything for me. I now mmaintain Inbox
Zero.

I write in markdown. I convert it into a multipart email with HTML in one
keystroke for everyone else.

Other benefits:

I don't know this for a fact, but i suspect that HTML email has got to _suck_
for visually impaired people using screen readers.

plaintext email means no tracking by marketers, or facebook, or anyone else.

plaintext emails are also _way_ shorter. There is so much less crap to
mentally deal with when all the marketing BS has been stripped away.

plaintext emails give you a glimpse into just how much you're tracked too.
Nevermind the privacy aspects of seeing the real url, you see that the "real"
url is multiple lines long because of all the tracking they've embedded in it.
It makes you think twice before clicking it.

~~~
tomjen3
What is it about neomutt that allows you to be that efficient with your
emails?

~~~
benoliver999
For me it's not mutt so much as being able to write and edit in vim. I can
reply in-line, quickly chop out chunks of text etc etc.

I'm not one to shout at people for not using plain text etc but I personally
quite like it.

------
beefhash
For the convenience of anyone that may consider licensing and language it's
written in a relevant part of their choice of software, here's the list of
recommended e-mail clients in the submission with licensing and programming
language info:

\- aerc: MIT, Go

\- alpine: Apache 2.0 (parts 4-clause BSD), C

\- claws mail: GPLv3, C

\- Gnus: LGPLv2+, elisp

\- KMail: GPLv2 (parts GFDLv1.2, parts LGPLv2.1), C++

\- mutt: GPLv2, C

\- SquirrelMail: GPLv2, PHP

Side note:

> (context: ProtonMail) It's also recommended that you visit Settings →
> Account → Identity and remove the default email signature.

It bears noting that free accounts on ProtonMail cannot remove the ProtonMail
advertisement in the signature, cf. [1].

[1]
[https://www.reddit.com/r/ProtonMail/comments/5ageqz/question...](https://www.reddit.com/r/ProtonMail/comments/5ageqz/question_about_protonmail_signature/)

~~~
stevekemp
My own client:

lumail, c++, gpl

[https://github.com/lumail/lumail](https://github.com/lumail/lumail)

~~~
Boulth
It would be great if you inserted a screenshot of your client in action in the
README.md. In my experience screenshots have excellent information density
when it comes to evaluating software :)

~~~
stevekemp
The website has this page of simple screenshots:

[https://lumail.org/screenshots/](https://lumail.org/screenshots/)

------
eythian
This ship has long ago sailed. People are using email less and less these days
as it is, anyway. I get personal emails less than once a week now.

You'd be better off pushing people to using email for communication in place
of walled-garden IM or social platform du jour (which I also think will be a
losing battle in general, but perhaps more worthwhile), in which case being
able to make your email look nicer might even be a draw.

------
joegreen
I would like to read more details about "The former is strongly preferred".
Why is plain text preferred and by whom?

~~~
aloisdg
Keep reading the article:

HTML emails are mainly used for marketing - that is, emails you probably don't
want to see in the first place. The few advantages they offer for end-users,
such as links, inline images, and bold or italic text, aren't worth the trade-
off.

and more at [https://useplaintext.email/#why-
plaintext](https://useplaintext.email/#why-plaintext)

~~~
atombender
Is this true? All the people I interact with professionally are sending HTML
email, probably because they all use Gmail.

~~~
Sir_Cmpwn
Sure, but are they sending it for a concious choice to prefer HTML, or because
it's Gmail's default?

~~~
zaarn
Does it matter? The default is HTML, the majority of mail is HTML (or atleast
multipart). So why does it matter if GMail defaults to what the majority is
doing? Everyone (99.9999% of people) can receive and send HTML, so just do
that, it's the informal standard for mail now.

~~~
Sir_Cmpwn
I think it does matter. For my rationale consult TLA.

~~~
zaarn
It's great that you think that it matters but I don't think that what you
think that it matters matters in practise, really, the world is HTML email
now.

------
hesk
I greatly prefer top posting because it emphasizes what I'm looking for in a
email reply which is new information. Moreover, modern email clients
automatically hide the quoted text so only the reply, with the new
information, is visible but context is available if necessary.

For example:

\---

Let's meet at 8 pm.

(Show more from person A).

\---

Typically, the context will be clear from reading the reply and the sender. If
not, I can establish context by clicking on the link:

\---

Let's meet at 8 pm.

> Agreed, when should we meet?

>> I think we should meet face-to-face to discuss this.

>>> This is a super-important discussion.

>>>> I propose to implement HTML mails.

>>>>> Plaintext mails suck. I missed important information because the mail
used asterisks instead of bold text.

\---

With top posting, I can stop reading the previous mails as soon as I
understand what's going on. Consider the opposite with bottom posting: Here I
would have to read the entire context from the beginning or am at the mercy of
how other people edited the context.

EDIT: Put --- on individual lines. Fixed asterisks formatting.

~~~
frenchyatwork
That's only relevant because you're including your whole thread (or part of
it, if there's forks) in your email. As far as I know, there's no real reason
for people to do this anymore. Email clients should be able to handle email
threads themselves, and then the recipient can decide how they want to sort
it.

If you're only replying to things that are specifically relevant to the
section (what quoting was traditionally used for), then bottom-posting doesn't
make sense.

------
Hitton
The part about ProtonMail and Tutanota seems pretty biased. I would like to
hear how the author suggests that they should implement IMAP and SMTP without
compromising the encryption.

It sounds like the author prefers dubious advantages to real improved
security.

That's quite ridiculous considering that according to him HTML emails are:

>"... a security nightmare, are mostly used for advertising to you and
tracking you, are less accessible for many users, and don't offer anything
especially great for it."

~~~
bjpbakker
> the author prefers dubious advantages to real improved security

Encrypting the data transfer doesn’t improve any of the HTML email security
issues. So I fail to see how that would be “real improved security”.

But I do share the authors sentiment on the failure to not using open
standards of both Protonmail and Tutanota. So maybe I’m biased.

~~~
knd775
The data in a protonmail account is encrypted with your own key. How is
protonmail supposed to encrypt an email if they receive it unencrypted over
SMTP?

~~~
bjpbakker
There are various ways. One would be to use standard imap and decrypt the
message on the client. Their bridge sort of does that but with proprietary
protocol.

Either way, that has absolutely nothing to do with the security issues of html
email. Eg phishing and tracking still works when you decrypt the message and
open it.

------
wongarsu
The page is about setting up email clients to send plain text emails, but most
of the reasons given why plaintext is preferable are about receiving email.
The remaining reasons are either "rich text isn't that great" or are trivially
solved by the client (extracting plain text from a rich text email isn't hard
on non-marketing emails).

------
bitwize
"How about you get a mail client from this century?"

\--Actual response I got when I complained to an IT admin at a former company
that Exchange had started eating all plaintext versions of emails

------
upofadown
>Mail client vulnerabilities

Yeah, this is the part that is eventually going to bite us ... hard. It is
just straight up insane to allow random entities access to the vast attack
surface of a web browser. Unfortunately no one seems to even care about
present day ongoing attacks. We will have to wait until someone comes up with
a worm that takes down email and possibly the whole net.

~~~
jorangreef
MIME is hard enough:

[https://snyk.io/blog/how-to-crash-an-email-server-with-a-
sin...](https://snyk.io/blog/how-to-crash-an-email-server-with-a-single-
email/)

------
camillomiller
The attitude of high-skilled tech people to think that their stripped down,
interface-less, and brutalist version of something has to be simply better
than anything else needs its own German term, something like Schadenfreude or
Treppenwitz. I'm sure some of the German readers here can work out something.

~~~
t0astbread
Isn't that just elitism/gatekeeping?

Other than that "Hackerwahn" ("hacker mania") sounds like a nice term for this
as mostly low-level hackers seem to show this kind of behavior. (Note: This is
not meant as an insult or a generalization.)

------
tjoff
Not having inline images is an issue though. It helps immensely with
readability and usability. Especially with people that aren't as computer-
savvy.

Partly because many email-clients will list attachments below the mail
content. And since it is standard practice to include the previous mail when
responding you have to scroll a kilometer to get to the bottom with the
attached images.

That is just unusable. Yes, it is an issue with bad clients and not plaintext.
But nonetheless it is a big issue.

~~~
kungtotte
Maybe you should read the entire page? It specifically warns against top
posting and quoting the entire email you're replying to.

So if people followed this advice you wouldn't have to scroll a kilometer for
attachments (unless someone actually wrote an email that long).

~~~
tjoff
I don't know if I've ever seen bottom-posting in my life. They have particular
weak arguments against that as well. It is very useful when forwarding a
message or including someone else as cc.

~~~
scbrg
It is very useful for you, the sender. It is a nightmare for the receiver.
Whenever I receive one of those forwarded top posted thirty mail long horrors
I just ignore everything and hope I can guess context from whatever you wrote
in the last email. The alternative is to spend an hour deciphering the blob of
goo that is actual mail messages mixed with signatures, attachments, all being
meaningless replies to questions I haven't yet read - because top posting.

Sending me such a thing is equivalent to telling me _" Fuck you, your time is
worth nothing to me."_

~~~
Dayshine
>The alternative is to spend an hour deciphering the blob of goo that is
actual mail messages mixed with signatures, attachments

You mention attachments, which implies you've been included in all the
previous emails. In which case, your email client should be splitting them
(often referred to as "conversation" view).

Otherwise, how does it make any difference if the infinite nesting is at the
top or the bottom? Or by "top posting" do you just mean replies without
trimming?

~~~
scbrg
I would say that top posting _does_ mean replies without trimming. In theory,
they're not the same, of course. In practice, I've seen top posting _with_
trimming a total of... well, zero times.

And in either case, reading something from top to bottom is certainly easier
than to read something in the order of: Last 3% of the message, followed by
the bits that are 93-97% into the message, followed by the bits that are at
86-93% of the message, followed by the bits... every email is like watching
Memento. With each scene in whatever typeface _that_ particular person's email
client thought was a good idea to enforce upon me. And sometimes purple.

------
pcunite
Is it not _ironic_ that the very website promoting the benefits of plain text,
uses a textual medium consisting of bold, underlined, colorized, and other
font effects? Something that can only be achieved via HTML enhanced emails!

~~~
ignaloidas
I think footer text might interest you:

> "But if plaintext is so good, why is this page written in HTML?" >This is a
> reference document, not an email, you twit.

------
alphagrep12345
If you block remote image loading (to thwart trackers) and be careful about
phishing links, I don't see a need for plain text-only email.

~~~
u801e
Most people aren't going to change the default configuration of their email
client or use caution when dealing with phishing emails.

But if the email is plain text, then that's not an issue.

------
moonrider
I think this is unfortunately mostly preaching to the choir. The "industry" is
moving in the opposite direction - the page should have a section on "AMP for
email".

------
unixsheikh
I hate HTML email with a passion.

In more that 20 years I cannot remember when I last saw a well marked up HTML
email that wasn't miss aligned due to missing closing tags or some other
stupid mistake. They are always filled with utter useless and distracting crap
and for some reason people tend to think that that is better than simply
focusing on the flipping point of the message.

And no, I don't want people to embed screenshots in the message body, I much
prefer attachments.

Claws-mail has a beautiful setting called: "Render HTML messages as text", and
if that doesn't work because the HTML message is too messed up -> Delete to
trash!

Edit: People can't figure out how to make relative well formed HTML for the
browser, yet someone thought it was a good idea to introduce the mess to
email. Go figure!

------
tyingq
The issue here is that most people looking for plain text email want to
_receive_ plain text email.

These instructions really only help you to send plain text email. It's unclear
if the receivers care either way.

I am sympathetic to the issues around HTML email but it's a hard ship to turn.

------
rhabarba
I consider support for HTML e-mails which is enabled by default a major bug in
a mail client.

------
ThinkBeat
He forgot about the even worse AMP emails that come out now.

------
atombender
The problems with HTML email originate in the days when clients like Outlook
would produce horrendous, non-responsive HTML that were basically entire
embedded web pages; the idea that the sender should be able to dictate the
font of an email is a bit ridiculous, not to mention the layout, and the
result was often broken depending on the email client.

Emails _aren 't_ web pages, but they do benefit from formatting (bold,
italics, links, paragraphs), all of which lead to better emails overall. After
all, everyone has their plaintext style (asterisks for emphasis, or maybe
underscores, etc.) and HTML formalizes those conventions in a way that has
been standard for decades and even centuries if you consider typesetting in
general.

I like the idea of HTML email better than I like the implementation. I'd love
to see a minimal HTML subset that only included formatting (including
paragraphs, indentation and blockquoting), images and links. No tables, no box
model, fonts or styling. We can keep full HTML for fancy marketing emails, but
letter-form email should be simple and impossible to abuse.

These days, of course, most email is HTML simply because that's the default
for almost all email apps (Gmail, Outlook, Spark, Polymail, etc.). It's not
true that only marketing emails use HTML, as the author claims.

~~~
virtualritz
"After all, everyone has their plaintext style"

This is counter to my own experience. I am using (plain text) email since 27
years. Including inline quoting and avoiding top posting at all costs.

People used _bold_ (not sure how to render a '*' in HN) /italic/ and
_underscore_ consistently on lists, newsgroups and -- rarely, as seldomly
needed -- in private correspondence.

I learned how to do this by example. Everyone being very disciplined about
this in the 90's still.

This started deteriorating rapidly in the wake of eternal September [1] and
Outlook becoming the standard client in the corporate world, using HTML as
default. Personally I blame Outlook for HTML email hell foremost.

It is very simple to display plain text email, omitting aforementioned
formatters and applying them. The same goes for displaying in a proportional
font (detecting intended indentations from the original and replicating them
with tabs, on the fly).

Using such formatters is just another (and not even alien) form of inline
markup. Actually the very one that inspired markdown, ReST, etc.

The only reason people use HTML email is that it's the default. Not that it's
better in any way.

The average user simply doesn't know any better.

[1]
[https://en.wikipedia.org/wiki/Eternal_September](https://en.wikipedia.org/wiki/Eternal_September)

~~~
jodrellblank
" _The only reason people use HTML email is that it 's the default. Not that
it's better in any way._"

There are people in this page of comments right here, explaining their use of
HTML, their reasoning for using it, and how it's better in many ways.

------
davidcollantes
I was always a strong advocate for plain text emails. Because for many years
my mail client was Mutt, I saw everything plain text. Now that clients are
graphical, it bothers me to know others might be reading my plain text emails
with a "Times New Roman" font, and not a monospaced (as god intended it to
be).

So, to avoid that, I use HTML on my emails. Yes, it makes them a bit bigger.
Yes, they go against my very belief. Yet, they look like I want them to be
seeing.

~~~
ignaloidas
Have you thought that others may not want to see your emails as you intended?

~~~
davidcollantes
End recipients can always overwrite, no?

~~~
ignaloidas
overwriting HTML styles is harder than setting how to format plaintext. HTML
styling has order of magnitude more customization options than plaintext,
which has three that I can think of: font, font size, tab width. Almost all
clients have customization for plaintext, I haven't seen one that can override
HTML customizations.

------
NoGravitas
I'd like to see formatting for email that doesn't have the security and
privacy vulnerabilities and complexity of HTML email. Markdown would be fine.
Inline images can refer only to attachments in the same message, not to
arbitrary URLs. Maybe some restrictions on links to reduce their effectiveness
in phishing emails. It would be fine. It would be everything you actually
need.

~~~
dragonwriter
> I'd like to see formatting for email that doesn't have the security and
> privacy vulnerabilities and complexity of HTML email. Markdown would be fine

Markdown supports arbitrary HTML, and so has exactly the privacy and security
implications of HTML (though there extensions available which limit this, and
are standard in some markdown processors and expected by default in some
markdown variants.)

~~~
NoGravitas
Okay, to be pedantic, I mean a subset of Markdown that doesn't allow arbitrary
HTML, and may have additional restrictions of the types I mentioned.

------
arbuge
One interesting anecdote about plain text not being the default in most
popular email clients come from my own PublicEmails.com email-to-blog-post
project. People would experiment with it and the allowed list of HTML tags for
formatting
([https://publicemails.com/blog/display/772/37f6f81d9a](https://publicemails.com/blog/display/772/37f6f81d9a))
but would get confused when the tags would render verbatim instead of being
processed correctly. They didn't realize they were in HTML mode by default in
most email clients like Gmail, and that they would have to manually switch
back to plain text if they wanted to use HTML tags.

I ended up adding a question to the FAQ to address this issue specifically,
though people still get confused from time to time. There is a touch of irony
about it - to get HTML tags to work, you have to be in plain text, not HTML
mode. Once you're in HTML mode all that's needed for formatting is the
client's own formatting controls.

------
yoz-y
Who does this page cater to though? The recommended tools are programs that
are packaged for Linux or need compiling[1]. If they want to convince anybody
who already does not prefer plaintext then they should be targeting the
Windows and macOS crowd.

[1]: Later some tools such as thunderbird or configuration for Apple Mail and
Gmail are mentioned. They should be top and center.

------
superbatfish
Un-un-popular opinion: Top-posting is fine. Interleaved posting is great, too.
Bottom posting is idiotic.

------
mgulick
I'm surprised by the recommendation to use format=flowed. I set up thunderbird
a while back to use the recommendations from the LKML:
[https://www.kernel.org/doc/html/latest/process/email-
clients...](https://www.kernel.org/doc/html/latest/process/email-
clients.html#email-clients). Doesn't format=flowed mangle patches?

I've also disabled wrapping (as recommended in that document), however I'm not
a big fan of it. I do think that plain text wrapped at 72 or 80 characters
looks much nicer. I wish thunderbird allowed me to select portions of the text
to wrap, or to disable wrapping for selected portions (e.g. a code snippet).
Is this handled better in other email clients?

~~~
ignaloidas
Now that page recommends using git send-email, on which the author also made a
tutorial: [https://git-send-email.io](https://git-send-email.io)

~~~
Sir_Cmpwn
Thanks for the link - this is indeed my stance, I don't think people should be
pasting patches into their daily MUA.

~~~
Boulth
That should be highlighted more. Not using git sendmail is the problem, not
format=flowed.

------
omaranto
It seems to me this webpage uses "bottom-posting" to include both what
Wikipedia [1] calls bottom-posting and what it calls interleaved posting or
inline replying. For example, in the section called "Top posting", the webpage
advises you to "Write anything you have to say underneath the quote it
pertains to.", which is interleaved posting (unless you only quote one thing).

Is this abuse of language common? Am I actually on the side of bottom-posters
because they really mean "write anything you have to say underneath the quote
it pertains to" rather than "reply to everything at the bottom"?

[1]
[https://en.wikipedia.org/wiki/Posting_style](https://en.wikipedia.org/wiki/Posting_style)

------
Crinus
> SquirrelMail

I _really_ _REALLY_ wish they'd make a new release (there is work on still
going on but the latest release is from 2013). SquirrelMail is my favorite
webmail since it was first available on a shared host i used early 2000s or
so. So simple and lightweight. But the lack of releases apparently made Debian
to remove it, then followed by several other hosts. I could set up a VPS to
have it myself but i do not really want to bother with mail administration (if
anything, not wanting to bother with mail was one of the main reasons i
switched to shared hosting - which initially had SquirrelMail, to my delight,
but sadly got rid of it some months later).

------
tzs
Plaintext email was doomed from the moment it got named "email" rather than
"etelegram". Regular mail can include graphics, different fonts, color, bold,
etc., so it is natural to expect email to handle that too.

Early email systems could not, but because they ran on systems that could only
display simple text, the natural assumption is that they were plain because of
technological limitations.

Once GUI systems became the norm, removing that limitation, it was inevitable
that email would follow.

This is not to say that HTML email is good. It was inevitable that email would
support rich text, inline attachments, and stuff like that that, but HTML did
not have to be the way that was done.

------
jancsika
> Top posting

> When you reply to an email, many email clients will _infer and_ include a
> quoted version of the message you're replying to above the text of your
> reply, _or else prompt if the context is ambiguous_. _This is normal-- it
> happens in clients that conform to RFC -1 which use data gleaned from your
> input to prevent_ long email threads containing the entire history of the
> discussion in an increasingly long and nested footer on every email. _This
> is called "top post prevention" and is required _ in all conforming clients.
> Please email your admin if your client doesn't conform to this
> specification.

------
esnowrackley
There are just different use cases for plaintext and HTML email. I can't
implement plaintext only email in some environments because it just won't work
with who I'm communicating with.

------
jimnotgym
> Notice: Use of IMAP and SMTP with Protonmail requires the use of a special
> third-party bridge. Protonmail is not recommended for this reason.

I am a bit tired of this campaign against Protonmail by Sir_Cmpwn. Yeah you
can't use SMTP directly. But if he was being objective would gmail not get a
disclaimer "Google read your emails to work out what to sell you, and pass
this on to government surveillance too"...Outlook is not recommended
because... insert whichever gripe about protocols is on your mind.

------
c-smile
Why just only such black and white dilemma?

It could be a different format altogether - something third as the golden
mean.

Alternatives: Markdown (we need specification for that) or HTML v2.0 or
something else.

Requirements to such format:

\- it shall provide only one way of text -> rendering and rendering -> text so
WYSIWYG can be implemented in non-controversial manner.

If HTML then HTML v. 2.0 as the last version that supported WYSIWYG editing
(as it has no CSS). CSS is allowed to be applied by email agent application
(user's theming) but not from the body of the message.

~~~
marcthe12
Agree. Hyperlinks and the subset used by term emulators today. For example
bold and tables can be rendered on even terminal emulators today. Another
issue is probably captioning.

------
parliament32
I use Claws Mail with the "Fancy HTML Viewer" plugin -- by default emails get
rendered in plaintext but I can hit a few buttons to see the HTML version if I
really need to (only happens occasionally). I only compose messages in
plaintext, as do most of my coworkers, and it works great. The only thing
that's still a problem is top posting... as much as I hate it, I'm not going
to be That Guy and reply to a 8-email-deep 6-participant chain at the bottom.

------
ksahin
> HTML emails are mainly used for marketing - that is, emails you probably
> don't want to see in the first place

Wait what?

Maybe you're subscribed to the wrong newsletter, but in my case, I'm
subscribed to products / brand I like, I'm aware that I will receive
advertisement / product updates and I'm fine with it !

------
dancek
The list of recommended mail clients had nothing for mobile. Is it because
good ones don't exist?

I'm a happy GMail (android+webmail) user because the usability is good enough
and I don't need to install and configure stuff.

If I wanted to send plaintext email from my Android phone, is there a
reasonably easy and usable way to do it?

------
mlang23
This belongs in my ~/.signature

------
pard68
The claims against Protonmail and Tutanota (possibly others, but the are the
two I saw) are from a place of ignorance. Both are the way the re because they
are decrypted clientside.

IMAP/SMTP needs a bridge or is inaccessible because of the needed decryption
step.

------
gdfasfklshg4
Does anyone else hate when someone assumes their screenwidth and hard wraps at
72 characters?

~~~
yakubin
For me it's not about the screen width. It's simply unergonomic to read wide
lines of text. Ever wondered why book pages are vertically-oriented? I don't
want my eyes to run a marathon from left to right with each line of text.

------
vbezhenar
Thanks, I apparently found out that Claws Mail had Windows version. Default
Windows E-mail client does not support text mode at all and I prefer text
mode, so I'll try it.

------
thedz
It's ironic to me that useplaintext.email uses formatting and design to
communicate intention that would be impossible in a plaintext email

------
cedex12
This whole discussion is making me hesitate to actually switch from plain text
to html emails… unforeseen consequences!

------
Tomte
Why is this a Show HN? It's just a web page, isn't it?

~~~
beefhash
Probably because Sir_Cmpwn just made it. Considering his other e-mail-related
website[1], I'd say that's why.

[1] [https://git-send-email.io/](https://git-send-email.io/)

~~~
Tomte
That's not what Show HN is for. I don't submit my articles that way.

It's for things (apps etc.) you can try out. Not for essays.

~~~
Sir_Cmpwn
You can apply the information on this page to configuring your mail client
(and should!). It's also intended to serve as a one stop resource for
cataloguing plaintext support in most, if not all, mail clients, in the
future.

~~~
Tomte
Still no Show HN. You've been here long enough to know that.

~~~
Sir_Cmpwn
Clearly I disagree. Feel free to ask the mods to clarify and update the title
accordingly.

