1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
---
# vim: tw=80
title: Please use text/plain for email
layout: post
tags: [mail]
---
A lot of people have come to hate email, and not without good reason. I don't
hate using email, and I attribute this to better email habits. Unfortunately,
most email clients these days lead users into bad habits that probably
contribute to the sad state of email in 2016. The biggest problem with email is
the widespread use of HTML email.
Compare email to snail mail. You probably throw out most of the mail you get -
it's all junk, ads. Think about the difference between snail mail you read and
snail mail you throw out. Chances are, the mail you throw out is flashy flyers
and spam that's carefully laid out by a designer and full of eye candy (kind of
like many HTML emails). However, if you receive a letter from a friend it's
probably going to be a lot less flashy - just text on a page. Reading letters
like this is pleasant and welcome. Emails should be more like this.
I consider this the basic argument for plaintext emails - they make email
better. There are more specific problems with HTML emails that I can give,
though (not to mention the fact that I read emails [on
this](https://drewdevault.com/2016/03/22/Integrating-a-VT220-into-my-life.html)
now).
## What's wrong with HTML email
**Tracking images** are images that are included in HTML emails with <img
/> tags. These images have URLs with unique IDs in them that hit remote
servers and let them know that you opened the email, along with various details
about your mail client and such. This is a form of tracking, which many people
go to great lengths to prevent with tools like
[uBlock](https://github.com/gorhill/uBlock). Most email clients recognize this,
and actually *block* images from being shown without explicit user consent. If
your images aren't even being shown, then why include them? Tracking users is
evil.
Many **vulnerabilities** in mail clients also stem from rendering HTML email.
Luckily, no mail clients have JavaScript enabled on their HTML email renderers.
However, security issues related to HTML emails are still found quite often in
mail clients. I don't want to view this crap (and I don't).
HTML email also makes **phishing** much easier. I've often received HTML emails
with links that hide their true intent by using a different href than their text
would suggest (and almost always with a tracking code added, ugh). They are also
**incompatible** with many email-based workflows, such as inline quoting,
mailing list participation, and sending & working with source code patches.
## Good habits for plaintext emails
Some nice things are possible when you choose to use plaintext emails. Remember
before when I was comparing emails to snail mail letters? Well, let's continue
those comparisons. Popular email clients of 2016 have thoroughly bastardized
email, but here's what it once was and perhaps what it could be today.
The common mail client today uses the abhorrent "[top
posting](https://en.wikipedia.org/wiki/Posting_style#Top-posting)" format, where
the entire previous message is dumped underneath your reply. As the usual quote
goes:
>A: Because it messes up the order in which people normally read text.
>
>Q: Why is top-posting such a bad thing?
>
>A: Top-posting.
>
>Q: What is the most annoying thing in e-mail?
A better way to write emails is the same way you write a letter to send via
snail mail. Would you photocopy the entire history of your correspondence and
staple it to your response? After a while you would start paying more for the
weight! Though bandwidth seems cheap now, the habit is still silly. Instead of
copying the entire conversation into your email, quote only the relevant parts
and respond to them inline. For example, let's say I receive this email:
Hi Drew!
Could you take a look at the server this afternoon? I think it's having some
issues with nginx.
I also took care of the upgrades you asked for last night. Sorry it took so
long!
--
John Doe
The best way to respond to this would be:
Hi John!
>Could you take a look at the server this afternoon? I think it's having some
>issues with nginx.
No problem. I just had a quick look now and nginx was busted. Should be
working now.
>I also took care of the upgrades you asked for last night. Sorry it took so
>long!
Thanks!
--
Drew DeVault
John might follow up with this:
>Should be working now.
Yep, seems to be up. Thanks!
--
John Doe
Much better if you ask me. This works particularly well on mailing lists for
open source projects, where you send a patch and reviewers will respond by
quoting specific parts of your patch and leaving feedback. Just treat emails
like letters!
## Multipart emails
I think there are nothing but negatives to HTML email. I use
[mutt](http://www.mutt.org/) to read email, which doesn't even render HTML
emails and allows me to compose emails with Vim. But if you absolutely insist on
using HTML emails, please use [multipart
emails](https://en.wikipedia.org/wiki/MIME#Multipart_messages). If you're
sending automated emails, your programming language likely contains a mechanism
to facilitate this. The idea is that you send an alternative text/plain body for
your email. Be sure that this body contains all of the information of the HTML
version. If you do this, I will at least be willing to read your emails.
## How do I use plaintext emails?
Your mail client should have an option for composing emails with plaintext. Look
through your settings for it and it'll change the default. Then you're free!
Tell your friends to do the same, and your email life will be happier.
|
