My Email Setup

When you overcomplicate the f out of fEmail

This is a new series that I'm starting, tentatively called "Indecision". I have decision paralysis and I'm hoping to document my (overly long and winding) journey so that I or someone else may look back at it once they start having a mental meltdown about this exact topic because they can't decide what is the "optimal" solution/approach.

There's nothing inherently "wrong" with using @gmail.com, @yahoo.com, or @outlook.com. It's free, hassle-free, and there's really not much to think about other than to just use it as your email address.

But as you sign up for more and more services or expand what you use your email for, you may find that having one "account" for everything isn't so "scalable" anymore.

So maybe you create another Google account. Perhaps one for work, one for personal use.

But then managing multiple email accounts at the same time become complicated. Maybe you accidentally reply from the wrong account. Either way, it starts to get mixed up.

Furthermore, irrespective of you "growing out" of single-account solutions, you may find that you're getting emails from people you don't know about (most likely scammers), or that services are bombarding you with bullshit emails you don't want or need, and it's getting harder and harder to keep your inbox clean and to actually find the emails you DO care about. And once the unread number goes above a certain number - whether it be 100 or 1000 - you just... give up on bringing that number down to zero, and from that point on, you just give up on even the hope of emails being any useful.

It has mutated from being a simple tool into a monster of complexity, a black hole of information, something you dread to even look at every morning.

Clearly, I'm not the only one with this experience. Everyone has their own way of preventing this monster from growing out of control, but taming it is such a delicate balance that even a few days of missed "grooming" can feel like it's out of your control.

And while others have come up with very bespoke solutions (hey DHH), I'm going to talk about the way I put a leash on this beast once and for all, for my own requirements.

Requirements

Which segues nicely into this section (not as nicely as Linus' transitions, but still).

One thing that I wanted from my email solution was the ability to use my own custom domain. After all, I bought the domain with my name on it, so might as well use it, not to mention using my own domain for email gives me lots of control that I’ll go over later.

Another "requirement" is privacy.

This... really shouldn't even be a requirement (it should be a prerequisite; something we take for granted). However, with the rise of surveillance state and the consumers' insatiable desire for humans (support agents) to save the users from themselves, it is no longer a given.

Sigh.

Well, it's at least simple to understand: I don't want anyone - human or neural networks - reading my goddamn emails. However, this is basically impossible nowadays without self-hosting it (I'm too old for this shit) or crippling the UX with "e2e" encryption (again, too old for workarounds).

With the "no one reads my email" effectively not being a choice anymore, what the requirement really means now, is to strike a reasonable balance between usability and keeping the number of entities who could read/is reading my emails to a minimum.

This is especially important for any humans that might be reading; while it's disgusting enough that algorithms comb through my email with their data-grubbing little hands, it's even worse with humans.

They have motives, so you must take note of what motives someone with access to your email might have, and what might be the worst they can do with the access they have, given their motive, and assess whether the risk is acceptable for your own use case (again, the perfect solution would be for no one to fucking read my emails in the first place).

After all, the FBI's motives are probably a lot different than those of a rogue employee who might be stalking someone (cough Google cough).

And, to tame the beast that email will eventually become if left alone, I'm going to need a couple of tools that I'll go over in the next section.

Finally, I need an email system that "just works", with features (at least, the ones I need) that are well integrated into the rest of "the stack" (OS, email clients, etc).

Email is, at this point, a core part of my digital life, and while I might be more tolerant of bad UX for shit I don't have to touch several times a day, "little annoyances" really add up with the number of times you interact with it, which is a lot.

Taming the Beast

Clearly, there are as many ways to deal with the sprawl of emails as there are ways to skin a cat.

Some people just power through the bullshit (all the power to you), while others come up with elegant solutions to make the experience of said "powering through the bullshit" more elegant, such as HEY (which I've alluded to earlier).

For example, HEY has tools to separate out who should be allowed to email you versus those who don't (the Imbox), a separate area for reading (the Feed), a ML-powered "box" to separate out the transactions, tools to help with composing, etc.

That's awesome, and if it works for you, that’s great. However, if you know me, you know I prefer building up my solutions with small, dedicated tools rather than trying to bend a wholesale solution to fit my use case.

So, what IS the secret to taming the beast?

It's routing.

When there's one person sending emails to one address (i.e. a 1:1 mapping), it's easy. When there's multiple people sending emails to one address (a N:1 mapping), it's more complicated. And when there's multiple people sending emails to multiple addresses (a N:M mapping), that's when shit blows up in complexity.

Have you seen this pattern before?

Yes, you have, and it's literally the exact same problem that message brokers deal with, and for which we already know the solution.

"Well then isn't the answer just rules to sort message into boxes?"

Yes, a large part of it is. Obviously it's not the entire solution, but the intuition for everything from HEY's organizational tools to even your grandmother's home-grown method of dealing with emails IS exactly this.

Okay, so what more is needed?

For one, a large part of why we need to read through emails to "sort" through them (rather than us knowing the context of the emails before we even glance at them, thus saving us time and cognitive load NOT opening up emails we don't care about at the moment) is simply that we do not have enough context.

So, not only do we need really detailed boxes, but we also need a way to make sure that only emails with that context gets to that specific "box" (what's the point in having a "transactions" box if others can just send non-transaction emails into that box?).

Side note: the "box" here doesn't literally have to be an inbox or a folder you set up; it just needs to be an easy-to-read, additional context with which you can construct rules and filter them.

For the former, while I'm sure you technically could set up very fine-tuned rules (with a sprinkle of Machine Learning, because it's $current_year and everything apparently needs to use ML), from my experience, it's just soooo much simpler and more reliable to just give out different email addresses for each "box".

Controlling which email addresses are used by whom can really tighten up the signal dilution, but it's naive to think that just because you meant for a particular email address to be used for, say, work context, only people within that context will email you through that address.

After all, your email address gets passed around, it gets leaked, and over time, your control over that email address dilutes considerably. In the best case scenario, you have a bunch of unrelated emails sitting in that box from people sharing that address. In the worst case scenario, you have spam and scam emails, cluttered all across all of your boxes.

And this dilution leads us straight back to square one - with no clear context to really separate these emails, we can't route them, and everything effectively ends up in one "box", even if you have multiple folders and addresses set up.

Hide My Email

And this is where the "hide my email" feature comes into play (it's called a lot of different things by different email providers, but the gist of it is that you construct a different email address for each use, on-the-fly).

And why would I want to hide my email address?

(a) It reduces blast radius for any email that "gets out". (b) And if it does get out, you can track down the source.

In other words, creating different email addresses for every use lets you Secure, Contain, and Protect the addresses people can use to reach you for each purpose, which lets us tighten up the aforementioned dilution of control, and hey, email routing is back on the menu!

This has further implications specifically for spam:

1. Because each address is unique to its use case, you can simply block incoming emails to that address should you start receiving unwanted emails.

2. Because you can track down each address to its "source", once you start getting unwanted email, you can figure out who's been selling your email addresses and stop doing business with them altogether...

3. or change the address at the source and "discard" the previous address to prevent any further unwanted contact from whoever else has been using that previous address. In effect, you basically don't have to worry about spam, even without the "spam filter" magic!

There are several ways to implement "Hide My Email":

  1. You can simply append a plus after your actual email address to quickly generate a unique email address on-the-fly (e.g. [email protected]). You've probably seen gmail doing this, but this is becoming more and more common across other email providers as well. However, this means more and more websites are catching up to this and either outright rejecting these addresses, or stripping the trailing bits to figure out your actual email (and lots of “big data” marketing software DO do this)!
  2. You can set up a wildcard alias for a domain (*@example.com), so that any email to that domain ([email protected]) gets routed to you. This is probably the easiest and safest way to go about implementing hide my email, but do know that someone can just... bypass any email you give them altogether by randomly trying [email protected] Of course, this doesn't happen often, but know that this can happen with a blacklist system (most often, they hit addresses that common email softwares expose, such as [email protected]).
  3. You can manually set up email aliases ([email protected]) with either your email service (should they provide it), or with your DNS. Obviously, this isn't a "scalable" solution and should only be considered when the "consumer" of that email address is a human being (so that you can craft nice, custom aliases that makes sense to them).
  4. And finally, there's the "randomized email" approach (e.g. [email protected]): it creates a random address that points to your email, and the critical part is that this can be done automatically (with Fastmail + 1Password integration, or with iCloud+)! This is a whitelist system, so people can't just randomly try [email protected] However, as the addresses are random, they are unreadable, and are really only suitable for when the "consumer" is a service.

While methods 1 and 2 are definitely easy to implement and use (not to mention that you're essentially free from vendor lock-in), they have inherent holes (especially so for method #1, where it's easy to figure out your real email by stripping out the + part, at which point it's game over) that compromise goal (a) for even having the "hide my email" feature in the first place.

And while method 2's "breach" case is less severe (you can just block whatever random [email protected] that people try to use to reach you), it still has some negative spam implications; not to mention, just because it doesn't happen "often" doesn't mean someone can’t just wrestle control over your email away from you!

Still, for most people, I would recommend going with method #2.

However, I ended up going with a combination of methods #3 and #4, mainly because the irrational part of my mind wanted to go with the "clean" solution. Technically, sure, it is the most bulletproof approach; however, it is ironic that I refused to compromise and take the "imperfect" one, because I sure as hell ended up compromising on other aspects anyway.

Now, there are two providers - that I know of - that provide method #4 and let you generate random addresses automatically wherever you have an email field: iCloud, with its "Hide My Email" feature, and Fastmail, with its "Masked Mail" feature. Both are functionally identical; however, as I have previously stated, I am trying to move away from Mr. Tim Apple's wild ride.

Thus, Fastmail was the last man standing; plus, I already was using 1Password as my daily driver, and not to mention, Fastmail already supported basically every one of my requirements - custom domain, no scanning of emails, reliable and proven operations over the course of 20 years - except one thing I will come back to in a bit.

With that selection in mind, the final setup ends up looking like this:

  • I have my "base" Fastmail email address setup, which constitutes the inbox in which everything else is built and routed to.
  • I have a custom domain connected to Fastmail, to which I set up a couple of manual aliases (such as [email protected]).
  • On those manual aliases, I set up rules to route them to their specific boxes (and in case of [email protected], I blocked emails to it altogether so I could finally be free of people trying to promote their shit through my public git email).
  • The nice thing about setting up aliases is that Fastmail automatically creates a matching “sending identity”, meaning, I can reply from those aliases!
  • While the manual aliases cover a limited use case - mainly for specific audiences (e.g. for a resume) and companies - 1Password’s Masked Mail integration covers the rest, creating random addresses whenever I sign up for something.
  • While email to these addresses all go into the inbox, I can block individual masked mail address!
  • And, oh yeah, you can reply from that randomized address as well.

All in all, this not only minimizes the chance of my email address being "leaked", but it also gives me tight control to bring down the ban hammer with a surgical precision.

I can protect my email addresses and my inbox from others and from sprawl this way.

Securing Your Emails

But once it arrives, who are you protecting it from, and what are you protecting?

(This is the section where I chew the fuck out of Fastmail, btw. Hint hint)

There are two types of email: transactional, and conversational.

You know what these transactional emails look like: bunch of notifications from random services, receipts, and perhaps most importantly, password resets (we'll get to this in a bit).

And as for conversational emails, well, they're emails where you are conversing with someone. By definition, there's at least one other party that's involved in the email thread, which means the copy of the thread is saved on the opposing party's email service/server, which means privacy is really not as much of a concern here.

Besides, I'm not really having "private" conversations on email (such a thing would be done through Signal), so I'm not too worried about Fastmail storing my emails in plaintext, where a Fastmail employee could read my boring ol' business-y email back-and-forth's.

Obviously, this is an oversimplification: even the "boring ol' business-y emails" can contain sensitive subjects (e.g. contracts that may move $$$$$$'s, or intimate details about your legal status).

And even if people don't read the few super-sensitive email, if someone gathers enough "data points" on you through your email, they could realistically forge your identity and act as you, at which point, it's game over.

But! This is where the whole "strike a reasonable balance" thing comes into play. Realistically, if people do end up with your emails, 1. it is likely going to be a small subset, and 2. it's going to be one of the feds, Fastmail employees or third-party processors reading your email. If it's the feds, them reading your email should be the last of your worries.

Of course, the 1st & 3rd-party employees are the ones to be worried about, but again, are the occasional few emails going to be enough for them to usurp you? Is them knowing that I got a job at $corp really going to change anything?

But for transactional emails? I really need to keep that shit away from prying eyes, and it all comes down to password resets.

What's the point of using 1Password with its bulletproof algorithms with e2e encryption and no shared keys, of me protecting my email and passwords properly by guarding it with 2FA and not using the same emails & passwords across websites using hard-to-crack passwords, if there's a big gaping hole on the back?

Once someone has access to your email, they can just take over any account using password resets and by simply clicking the link in the password reset email (and let's not even get started with 2FA - my banks, of all things, use SMS as the "2nd factor", which you can bypass easily with using SIM swap). It would mean automatic invalidation of every password and account I have had, ever.

And that truly would be a game over.

And Fastmail does not protect against this. In fact, they're well aware of it. It's for convenience, for sure, but consider the fact that Fastmail straight up didn't need to do anything to accommodate for Australia's insane anti-privacy law - because there was no privacy to begin with.

At that point, do whatever excuses that Fastmail come up with - "we have rigorous processes to ensure employees can only access your email when absolutely necessary" and "we make our subprocessors sign some legal shit", for instance - really mean much of anything? In the face of your emails just lying there in plain text, all of that really just amounts to "trust me bro".

We've seen how companies' "systems" have broken down to break that trust model, or worse, how companies abuse that trust against you, whether at the individual level or the organization level. "Just trust me bro" really shouldn't fly in this day and age.

And the problems don't just stop with Fastmail and its subprocessors having plain text access to your emails.

In fact, anyone motivated enough could simply bullshit their way through Fastmail's account recovery process, and accounts have been taken over this way.

There's no way to turn this "feature" off, especially the part where an employee needs to make the call whether to override your password/2FA: are we really trusting humans to make the call, to trust them to keep the keys to the kingdom safe, even after we've seen malicious actors use social engineering to play support agents like a goddamn fiddle time after time?

In Fastmail's view, this is because consumers have increasingly demanded that there be an "escape hatch" in the authentication process, and that this is for your own - the consumer's - good. And, they say, their account recovery process is "rigorous" and that only senior employees can override your account details during the recovery process.

"Just trust me bro."

In general, account recovery almost always is implemented in a way that basically "backdoors" any security you or the service has. It's a huge fucking security hole - I've seen entire accounts being taken over with just access to SMS, which, again, isn't that hard to do with SIM swaps!

This is how I paid the piper by going with the technically "clean" solution. Again, it's all about risk management, and maybe your answers differ from mine, but either way, I feel that I've made the wrong call to trade the "technical" for the "human".

But the arrow has already left the bow.

The Migration & Conclusion

There's really nothing like sunk cost fallacy to get you to commit to the "wrong" solution. And oh boy did I sure sink a lot of time and effort even thinking about this, let alone migrating to the new solution!

For now, I've imported all of my Gmail accounts into Fastmail, and have told Fastmail to continue polling for new emails from Gmail - that way, I can continue to use my email as-is for now.

And as for moving off of Gmail, I'm still undergoing the long and slow process of figuring out where my email is being used (which, of course, is not an easy thing to do with the "sprawl" that I brought up at the beginning of this article), and signing into those accounts and changing my email (and by the way, doing so made me realize just how fucking hostile many services are towards users managing their own accounts, but that's a story for another day).

So, at the end of the day, I have come to an imperfect conclusion, started using an imperfect solution, and started an imperfect process to move to said solution.

What did I learn from all of this?

  1. That you should think about how something is going to be used, even for something as simple as your email.
  2. Don't roll your own auth, don't roll your own auth, don't roll your own auth!
  3. And finally, that there is no staying secure & private in this day and age without building & hosting everything yourself.

But such is the price "we" pay for "convenience".

Subscribe to Jane's Dev Blog

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe