There are two main types of emails on the internet: plaintext and HTML. Many people, particularly in technical communities, strongly prefer or even require the use of plain text email from participants. However, your mail client may not have it set up by default. We'll help you get it configured, and introduce you to the norms and conventions of plain text email.
The following email clients are known to handle plaintext especially well:
These clients all compose plaintext emails by default, with correct quoting and text wrapping settings, requiring no additional configuration to use correctly. Want to add your own mail client to this list?
If your email provider's webmail doesn't have good plain text support,
please consider writing to
with a complaint, and using one of the recommended clients over IMAP & SMTP
After configuring your client, be sure to review our etiquette recommendations.
Afterlogic does not support plain text email. Please ask them for it and use a different mail client.
alot uses plain text email by default.
Plaintext is the default. To enable bottom-posting:
You can also prefer to show the plain text email by default when viewing multipart messages:
When replying, use "Reply to all" instead of "Reply to list".
To wrap text, press Ctrl+M in the composition view.
Geary will remember your preference next time.
To bottom-post, you have to highlight the portion of message that you want to quote.
Gmail will remember your preference next time.
Gmail wraps plain text messages at 78 characters.
Gyazmail has the correct settings by default.
It is also recommended that you select "Manage identities", and for each identity, untick "Use Signature". This will remove "Sent from K-9" from your emails.
You can request better plaintext support via their user forum.
Mailspring supports basic plaintext composing. You can also create a single plain-text email by holding Alt or Option while clicking "Compose" or "Reply". Request more features by asking them for it.
Notice: Use of IMAP and SMTP with Protonmail requires the use of a bridge. A third-party, MIT-licensed bridge is available. Proton technologies also makes the source code to their official bridge available under the GNU-GPL-3.0-or-later.
It's also recommended that you visit Settings → Account → Identity and remove the default email signature.
Also consider setting "Automatically add signature" to "never".
Runbox 7 uses plain text email by default.
Smail uses plain text email by default.
Notice: Use of IMAP and SMTP, open standards for email clients, is not possible with Tutanota. This is not acceptable behavior for an email provider and use of Tutanota is strongly recommended against for this reason. Tutanota's stated reasons for not supporting these protocols are lies and you would be well served by closing your account there.
Windows Mail does not support plain text email. Please issue a feature request through the Feedback Hub app, and use a different mail client.
A few notes on the subject of plain text email ettiquite:
When you reply to an email, many email clients will include a quoted version of the entire message that you are responding to beneath your reply. This leads to long email threads which contain the entire history of the discussion in an increasingly long trailer on every email. This is called "top posting", and it's strongly frowned upon by many users of plain text email.
Plain text email makes it easier to incorporate the original text into your reply much more meaningfully. Consider these two examples:
Yes, that sounds good. Jim said on 2019-03-23 at 11:02 PM: > Are you okay with maroon? > > Tim said on 2019-03-23 at 10:43 PM: >> Do we know what color we should use for the background? >> >>> Jim said on 2019-03-23 at 10:30 PM: >>> Is there anything left to do on the site?
This email uses top-posting, and this approach is discouraged. A better approach might look more like this:
Jim said on 2019-03-23 at 11:02 PM: > Are you okay with maroon? Yes, that sounds good.
You can also edit the original email more, quoting it several times to make it clear what points you are responding to, like so:
Hey Drew, Can you look into the bug which is causing 2.34 clients to disconnect immediately? I think this is related to the timeouts change last week. Also, your fix to the queueing bug is confirmed for the next release, thanks!
Hey Sarah, I can look into that for sure. > I think this is related to the timeouts change last week. I'm not so sure. I think reducing the timeouts would *improve* this issue, if anything. I'll look into it. > Also, your fix to the queueing bug is confirmed for the next release, > thanks! Sweet! Happy to help.
As the old joke goes...
Plain text emails are generally encouraged to be wrapped at 72 columns, by inserting a newline and resuming the content on the next line. This is encouraged to make email more comfortable to read and quote in many of the contexts where technical users may encounter it, such as terminal emulators. Of course, it's far too annoying to do this manually as you write — the recommended clients will do this for you, as well as any client shown above with "Wraps text or uses format=flowed".
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.
HTML emails allow you to make links which hide the URL behind some user-friendly text. However, this is an extremely common vector for phishing attacks, where a malicious sender makes a misleading link which takes you to a different website than you expect. Often these websites are modeled after the login page of a service you use, and will trick you into entering your account password. In plaintext emails, the URL is always visible, and you can more easily make an informed choice to click it.
Many phishing emails have also taken the step of carefully replicating the visual style of an email you might trust, such as the appearance of a PayPal email. With plain text, it's much more difficult to trick you like this.
Virtually all HTML emails sent by marketers include identifiers in links and inline images which are designed to extract information about you and send it back to the sender. Examine the URLs closely - the strange numbers and letters are unique to you and used to identify you. This information is used to hack your brain, attempting to find advertisements which are more likely to influence your buying habits. HTML emails are good for marketers and bad for you.
HTML emails open up a lot of possibilities which are exploited by spammers to circumvent spam filters, such as making large amounts of text invisible, using hidden elements, and so on. Many people discard HTML emails (particularly mailing lists) on the simple basis that it dramatically reduces the amount of spam emails they receive.
HTML is an extremely large and complicated set of specifications designed without emails in mind. It's designed for browsing the world wide web, on which a huge variety of documents, applications, and more are available. Implementing even a reasonable subset of these standards represents hundreds of thousands of hours of work, or even millions. A large subset (perhaps the majority) of these features are not desirable for emails, and if included can be leveraged to leak information about you, your contacts, your calendar, other emails in your inbox, and so on. However, because of the herculean effort necessary to implement an HTML renderer, no one has built one specialized for emails which is guaranteed to be safe. Instead, general purpose web browsers, with many of their features disabled, are employed in most email clients. This is the number one source of vulnerabilities in email clients which result in information disclosure and even the execution of arbitrary malicious code.
This is a list of 421 remote code execution vulnerabilities in Thunderbird. If you're bored, try finding one that doesn't exploit web tech.
Browsing the web is a big challenge for users who require a screenreader or other assistive tools to use their computer. The same problems apply to email, only more so - making an accessible HTML email is even more difficult than making an accessible website due to the limitations imposed on HTML emails by most mail clients (which they have no choice but to impose - for the security reasons stated above). Plain text emails are a breeze in comparison for screenreaders to recite, especially for users with specialized email clients designed for this purpose. How do you speak bold text aloud? How about your inline image?
Some email clients don't support HTML emails at all. Many email clients are designed to run in text-only environments, like a terminal emulator, where they're useful to people who spend a lot of time working in these environments. In a text-only interface it's not possible to render an HTML email, and instead the reader will just see a mess of raw HTML text. A lot of people simply send HTML emails directly to spam for this reason.
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. You can still communicate your point effectively without bringing along all of the bad things HTML emails come with.
Thanks for your interest in making plaintext emails more accessible to your users!
Email clients which meet all of these criteria and prefer plaintext by default are entitled to a spot on our recommended clients list.
Do you want to add instructions for a new email client? Have suggestions or questions? Please send a plain text email to ~firstname.lastname@example.org. You can also email a patch to this address. The code may be found on git.sr.ht.
"But if plaintext is so good, why is this page written in HTML?"
This is a reference document, not an email!
This site is distributed with the MIT license. "Plaintext Certified" graphic by Jens, CC-BY-SA.