235 lines
12 KiB
Markdown
235 lines
12 KiB
Markdown
---
|
|
title: Rediscovering Email
|
|
date: 2025-03-24
|
|
---
|
|
|
|
## Preamble
|
|
|
|
"Kids these days" don't really use email anymore. _It's me by the way, I'm
|
|
kids._ Sure, we email our professors, we email our resumes to potential
|
|
employers, we email when the business is a tad too official for text or
|
|
WhatsApp.
|
|
|
|
Email isn't just for communication. Think about it: when all you want to do is
|
|
talk to someone, are you sending them an email? When's the last time you emailed
|
|
a friend or loved one "What's up? How's it going?"
|
|
|
|
Email has been relegated, essentially, to administrative tasks. Emails are
|
|
something you _have_ to send. They carry an air of officiality. Definitely not
|
|
the way to contact your friends.
|
|
|
|
Why is that?
|
|
|
|
## Web Mail Sucks
|
|
|
|
I think our _experience_ of writing email takes a large chunk of the blame. To
|
|
be honest, it's pretty dreadful most of the time, thanks in no small part due to
|
|
the _God-awful_ interfaces through which we interact with emails.
|
|
|
|
Web mail interfaces _suck_. You log into Gmail just to see that every fifth
|
|
letter in your inbox is actually an ad. I'm not talking promotional mail, I'm
|
|
talking a literal ad, served to you by Google, masquerading as a real message.
|
|
|
|
And tell me why Outlook needs to make hundreds of JavaScript requests, and cache
|
|
a hundred megabytes of data just to show my inbox? If I'm using my laptop on the
|
|
school network, chances are, I'll be sitting there for at least ten seconds
|
|
before I can even see whether I've got any new messages.
|
|
|
|
Oh, and I don't know about you, but since I spent most of the day using my
|
|
computer, I like to do whatever I can to prolong my ability to, like, use my
|
|
eyes. A big part of that means using dark mode wherever possible, as God
|
|
intended. Which brings me to my next point: dark mode in most web mail clients
|
|
isn't great.
|
|
|
|
For instance, Proton Mail provides a lovely dark interface for your inbox, just
|
|
to burn your retinas off the moment you start composing a message or reading a
|
|
new email. This is one area I must be fair to Outlook, however, which provides
|
|
one of the nicest dark interfaces I've used.
|
|
|
|
|
|
|
|
For quite a few reasons, including those stated above, and of course wanting to
|
|
use my own text editor to write my letters, I finally decided it was time to
|
|
figure out a better way to interact with email. And as it turns out, there
|
|
really is one!
|
|
|
|
## Email In The Terminal?
|
|
|
|
If you know me at all, you know I'm a **fiend** for the terminal. If a given
|
|
task is even _possible_ to do in a command-line (or TUI) interface, then that's
|
|
the way I'll be doing it from now on until my hands my fall off my wrists. Call
|
|
it a neurodivergent stubbornness, but it's just the only way I really like to
|
|
interact with my computer.
|
|
|
|
It also happens that Helix, my text editor of choice, also runs in the terminal.
|
|
Anytime I'd have to draft an email longer than a few sentences, I'd start to
|
|
feel the withdrawal. Maybe Helix has really spoiled me, but the experience of
|
|
manipulating text in this beautiful program is too good to **not** incorporate
|
|
into every aspect of my life that involves writing. I'm already writing my
|
|
papers and slideshows in Helix (_more on that in a future post_), so why not
|
|
email?
|
|
|
|
First, I figured out using Thunderbird. Although it has many problems (like,
|
|
tell me how there _still_ isn't tray support for Linux?!) using Thunderbird was
|
|
otherwise a "solid" experience. Sure, Thunderbird is a GUI app, _but_ I wasted
|
|
no time in finding a pipeline for writing emails in my beloved Helix.
|
|
|
|
The extension "External Editor Revived" does exactly what it sounds like. Using
|
|
it, I was able to open up email files for editing in Helix, then pipe them back
|
|
to Thunderbird for review and sending. I was happy with this setup for a while
|
|
despite its problems.
|
|
|
|
But as it turns out, an even nerdier way was just around the corner...
|
|
|
|
## Enter Aerc
|
|
|
|
I forget where I first heard about `aerc`, but I'm really glad that I did! It's
|
|
a lovely little TUI email client maintained by the good people at Source Hut. It
|
|
features a vim-like ex-command setup and controls. The controls are also 100%
|
|
remappable, which makes my Colemak brain happy.
|
|
|
|
My favorite part, though, is the composing interface. It's really clever: the
|
|
top of the screen holds the standard headers you expect to see like From, To,
|
|
and the Subject, but the part where you write the body of your letter is
|
|
actually a tmux-style embedded terminal running your favorite `$EDITOR`!
|
|
|
|
|
|
|
|
Of course, there were quite a few hiccups in getting Helix to play along;
|
|
namely, spellchecking, Markdown syntax highlighting and automatic text-wrap was
|
|
a challenge. If you're interested in the details, I'll later be publishing a
|
|
tutorial outlining step-by-step how to replicate my Helix-mail setup.
|
|
|
|
### Authentication Problems
|
|
|
|
If you're going to use an email client, you need to authenticate with your email
|
|
provider. For Proton Mail, this was easy enough; the Bridge app interfaces with
|
|
your encrypted inbox, and exposes IMAP and SMTP services locally. Outlook, on
|
|
the other hand (especially a school/corporate policy) is a **hassle**.
|
|
|
|
Without getting too deep into it, it was more than one day of headache before I
|
|
managed to get it working. The solution involved finding (and modifying) a
|
|
Python script to authenticate and save my initial refresh token, as well as
|
|
manage requesting new access tokens when they expire. I also had to gaslight
|
|
Microsoft into thinking I was actually using Thunderbird (by pulling the
|
|
`client_id` straight from the Mozilla source code).
|
|
|
|
## Organizing Email
|
|
|
|
My inbox has _always_ been disorganized. Frankly, I don't know a single person
|
|
whose inbox isn't. And it's understandable! The tools at our disposal aren't
|
|
particularly helpful, and most importantly, **they're not standardized.** For
|
|
example, we could create various folders, moving the appropriate emails as we
|
|
read them. Some _(emph: some)_ providers let you automate this, but I've found
|
|
the filter rules to be a bit lacking. Organizing by folders also inherently
|
|
limits your ability to later filter and narrow down your searches.
|
|
|
|
Tags are clearly the best way, but again, the implementation depends
|
|
per-provider. Worst of all, as with most things these days, non-standard
|
|
implementations mean that as soon as you've put all your eggs in the basket,
|
|
you're essentially locked in; unless you want to go to the _colossal_ hassle of
|
|
re-organizing your inbox playing by _another_ provider's rules.
|
|
|
|
## Storing Email Locally
|
|
|
|
As it turns out, `aerc` (and other mail clients like it), besides the standard
|
|
ability to read mail from an IMAP server, has another trick up its sleeve. That
|
|
trick is reading mail from a _local database_. Now, this might not seem like a
|
|
big deal. Thunderbird does this too: when you access your inbox via IMAP,
|
|
Thunderbird downloads and caches all of your emails.
|
|
|
|
What I never knew, and it took messing around with `aerc` to learn about, is
|
|
that there exist multiple _standardized_ ways to store emails locally. What this
|
|
means is that as long as you synchronize your emails to this local store, you
|
|
can access them from **any** client!
|
|
|
|
I chose to go with a tool called `mbsync`, which stores mail in the standard
|
|
"maildir" format, and keeps it in sync with an IMAP server. The syncing only
|
|
happens when you trigger it manually -- although you can easily configure
|
|
another program to "listen" for new emails and sync automatically. I decided to
|
|
forego this, more on why later.
|
|
|
|
## Complex Tagging
|
|
|
|
The best part is that once you've got this email database, you can pick from a
|
|
host of tools and systems for indexing and organizing it. I went with a tool
|
|
called `notmuch`, a program that's very popular among programmers much older and
|
|
more bearded than I am. `notmuch` _indexes_ your maildir and basically acts as a
|
|
query engine. I found the experience of using it similar to, say, SQL. The basic
|
|
premise is that you write queries about your emails.
|
|
|
|
```sh
|
|
# Here's me searching for emails about GitHub authorization
|
|
notmuch search 'from:/@.*github.*/ subject:/auth\w*/'
|
|
```
|
|
|
|
You can also apply an arbitrary string to an email as a **tag**. Tags are more
|
|
powerful than **flags**, which are IMAP compliant, but limited to only a few
|
|
specific roles. `notmuch` allows you to create and use as many different tags as
|
|
you want!
|
|
|
|
```sh
|
|
# Here's me applying the "personal" tag to
|
|
notmuch tag +personal -- 'path:personal/**'
|
|
```
|
|
|
|
But the real juice is configuring rules that will automatically tag your new
|
|
emails. Then, not only can you filter/query your mail by tag, but when you open
|
|
your mailbox in `aerc`, you can configure queries as "folders" for easy,
|
|
repeated viewing. Nice!
|
|
|
|
## The Synchronization Problem
|
|
|
|
I spent a lot of time on tagging. Figuring out the rules and automatic filters,
|
|
fine-tuning my queries, etc. When I finally had it all figured out, I
|
|
encountered the next problem, which (I guess) I could've foreseen: **the
|
|
`notmuch` database is local**! And as it turns out, synchronizing its database
|
|
between devices (home PC and laptop in my case) is **not** a trivial task.
|
|
|
|
I first tried a tool called [muchsync](https://www.muchsync.org/). It's a clever
|
|
piece of software, with one big problem: it's designed around one database that
|
|
acts as a central server, which _other_ databases replicate. This turned out to
|
|
not be particularly reliable for my case, because thanks to the aforementioned
|
|
[authentication hacks](#authentication-problems), I can only **reliably**
|
|
synchronize my mail if I'm actually at the computer to re-authenticate when
|
|
necessary. Trying to wrangle the authentication and GPG-encrypted tokens via
|
|
`ssh` was starting to feel like more trouble than it was worth.
|
|
|
|
My next idea was to use SyncThing to just keep the entire local database
|
|
synchronized, peer-to-peer style. I figured that as long as I only ran `mbsync`
|
|
manually (for the external IMAP sync) and only accessed/edited my mail from one
|
|
device at a time, I wouldn't have any conflicts.
|
|
|
|
That was, apparently, an incorrect assumption. I was basically faced with a
|
|
conflict every single time I updated some tags or deleted a few emails. Because
|
|
of how `mbsync` is written, it was basically impossible to recover from these
|
|
broken database states. After multiple instances of needing to re-download my
|
|
entire inbox, I decided it was time to cut my losses, and `notmuch`
|
|
`pacman -Rns`'d out of my life almost as quickly as it `-Syu`'d into it.
|
|
|
|
## JMAP Is Amazing
|
|
|
|
For reasons I'll get into in another post, at this point, I was also completely
|
|
fed up with Proton Mail, and on the hunt for a new provider. I'd heard good
|
|
things about Fastmail, and after seeing that they implemented a new protocol
|
|
called JMAP, I decided to try it out.
|
|
|
|
> Note: I was actually so pleased with Fastmail that my free trial went paid
|
|
> subscriber in less than a day. Take that, Proton!
|
|
|
|
JMAP has **labels**, which are similar enough to `notmuch` tags. But because
|
|
they're supported by the protocol itself, they're hosted by the mail server
|
|
itself, meaning you can completely sidestep the synchronization hassle. Not only
|
|
that, but they're also a first-class citizen in Fastmail's web interface (which
|
|
is one of the best I've ever used).
|
|
|
|
A **label** is basically analogous to a folder. If an email has a certain label,
|
|
it's basically in that folder. If it has multiple, it's like multiple folders
|
|
symlink to the same message. What's cool about this system is that you can move
|
|
and "copy" your mail around without actually creating redundant copies of
|
|
emails.
|
|
|
|
With this approach, you don't even need to maintain an archive folder. Any mail
|
|
that doesn't have the Inbox label is considered archived. This means you can
|
|
archive messages while still retaining their other labels. Very useful for
|
|
things like digital receipts and automated messages from `noreply` addresses.
|