For nearly 25 years, I used a single email address (david@djstein.com) for all personal correspondence. Unfortunately, the volume of spam overwhelmed my ability to manage it. Instead, I’ve adopted a system of per-sender email accounts to provide more control and to win the war against spam.
Introduction
Way back in 1998, I purchased this domain and launched a small personal website, mainly as an identity placeholder and a public repository of small software projects. I started using david@djstein.com as my email address for personal correspondence. Over time, I used this address for a wide variety of reasons: as the account address for e-commerce accounts and newsletters, as the contact address for this website and projects, etc.
Problem
Over the years, the volume of spam that I received steadily grew. Much of it was “bacn” – spurious email from senders to whom I had voluntarily given my email address, but who then added me to an assortment of mailing lists, only some of which honored unsubscribe requests. Other spam was due to e-commerce sites sharing my email address – either voluntarily with ad partners, or involuntary through data breaches (including nearly 20 incidents reported by haveibeenpwned.com).
I tried a variety of techniques to reduce the rising tide of spam. david@djstein.com forwards to a Gmail account, and both the front-end host of djstein.com and Google apply spam filters to incoming mail. Also, I began developing and maintaining blocklists of every domain that has sent me spam – currently, approximately 700 domains are blocked. Finally, I added trusted senders to whitelist filters for routing to trusted folders.
Despite these measures, about 40-50 unwanted messages arrive in my Gmail inbox per week. All of these message arrive from new domains – domains that have never sent me spam before – and I have to add 30-40 new domains to my blocklists every week. Worse, the chain of filters results in frequent false positives, where wanted messages from trusted sources are either routed to a spam folder or silently dropped. The email path and filtering also delay mail delivery by 60+ seconds, which is frustrating for multifactor authentication.
The issues became so substantial that I began using my George Mason University (GMU) email account for important communications. But using multiple email accounts added new complications – e.g., the need to check and manage multiple inboxes, as well as multiple calendars and multiple contact lists. And when my GMU email account also began to exhibit issues with both spam and false positives, I decided that a better solution was needed.
Analysis
The typical way that we use one email address as a catch-all for many types of correspondence has several fundamental problems relating to spam – each of which resembles well-known security problems.
- Problem #1: Reuse. Using an email address with multiple senders has similar issues as using the same login credentials with multiple accounts: a breach or misuse by any one recipient jeopardizes its use by every other recipient. Let’s say you provide your email address to 100 websites, and one of them shares your address with spammers or leaks your address in a data breach. You no longer have control over who sends you email through that address; anyone can send mail to it. And if you want to change the address, you have to update your email address on 100 websites, which is very painful. Also, the risk of an email address being compromised increases in proportion to the number of recipients who know it.
- Problem #2: Default Allow. Most email providers will deliver all mail to your inbox that passes their spam filters. This policy no longer makes sense in an era when spammers use a variety of domains and can evade content-based spam detectors. In the context of network security, “default deny” is standard practice: every modern network device has a configurable firewall that only allows traffic of a selected profile. Similar logic should apply to email.
- Problem #3: Administrative Weight. Manually deleting spam is a chore. So is manually managing blocklists. So is manually dealing with false positives by rooting around through spam folders, updating blocklists or allowlists, and requesting resent messages to deal with delivery failures. At best, the administrative heaviness is inefficient; at worst, spam prevention fails when we fail to keep up with the manual administration.
Given these factors, I began considering the options for a new email account. Simply moving to a new email address would risk a recurrence of the same problems. I needed to develop new email practices that would reduce these issues.
I considered, and rejected, several options before settling on the solution:
- Option #1: Multiple email accounts. I could develop a “friends and family” email account, an “e-commerce” email account, a “mailing lists” email account, etc. The problem is that I don’t want multiple email accounts. I don’t want to check multiple inboxes, I don’t want to manage them separately, etc.
- Option #2: Sender-based filters. I could develop different email folders with rules to route email based on sender email addresses, and all other email could go into an “untrusted” folder. The problem is that people and companies sometimes change email addresses, and sometimes use multiple email addresses. Every time I received mail from a new address, I’d have to move the message and also update the filter to catch all future messages. Also, I still need to monitor the “untrusted” folder to receive mail from trusted senders using new addresses, so the “untrusted” folder has the default-permit problem.
- Option #3: Subject-line filters. I could ask trusted senders to include a certain token (e.g., a keyword) in the subject line of email to me. The problem is that this outsources my spam issue to senders who have to remember and honor my request. Also, most websites have no capability to add user-specific tokens.
- Option #4: Group-based email aliases. Gmail allows users to append an alias to the username part of an email address, like: david+friends@djstein.com or david+business@djstein.com. Gmail simply disregards the “+alias” part of the address before delivering it to you. Gmail rules can then filter mail to different folders based on aliases. The problem is outbound mail: Gmail allows you to specify one reply-to address for all outbound messages. It is not possible to send through an alias, and the alias is lost for all responses. Worse, when a sender sends a message to your alias (e.g., david+friends@djstein.com) and receives a response from a different address (e.g., david@djstein.com), the sender’s email client might not determine that the messages are related, or, worse, might block the response due to the mismatch.
Solution
Based on this analysis, I realized that the best solution involved the one field over which I had complete control: my email address. And that control can be maximized by using different email addresses not just for different contexts, but for different individual senders. That is – not just group-based aliases, but one address for every trusted sender. The solution is to find a way to associate multiple email addresses, for both sending and receiving, with a single email account, inbox, and filter rule set.
This solution has several advantages:
- Advantage #1: Adaptability. Every incoming trusted email occurs through an individual channel. If an email address is compromised, I can make changes to that address – e.g., adding sender-based or content-based filters, or completely blocking that address and switching to a different one – without affecting any other trusted senders.
- Advantage #2: Filtering. The individual channels are based solely on the email addresses that I specify, not the email addresses of the sender. Filters that route messages into folders can also be based on the email addresses that I specify. If a friend or website uses a different address to send messages, the rules will still apply because they are still using the email address that I specified. And I never have to update the inbound email rules if they change their email address.
- Advantage #3: Auditing. I can immediately tell when an email address is compromised, because I receive a message where the sender does not match the recipient. I can determine exactly what happened – because I gave that email address to only one recipient. It’s possible that the recipient doesn’t even know that they were compromised or leaked my address, and my notification to them might tip them off that their account has been compromised.
- Advantage #4: Generality. This solution relies entirely on the basic infrastructure and mechanics of email. I can use this solution with every single trusted sender – every individual, group, or website – without any special requirements or limitations.
After choosing this solution, I searched for a way to implement it that would not be subject to the limitations of group-based email aliases. Eventually, I discovered Fastmail, a private mail host with robust support for email aliases. I evaluated it through a trial period and determined that it met my needs, and admirably so.
Unlike Gmail, which simply disregards email aliases on incoming messages, Fastmail allows users to develop and maintain an entire list of aliases – up to 600 – and rules that are based on the aliases. Best of all, Fastmail features “sending identities” – i.e., you can send email through any alias that you define – and, by default, Fastmail responses use the same “sending identity” or alias as the previous incoming message. This feature is the silver bullet that I needed to implement my solution.
I spent a weekend migrating from Gmail to Fastmail. For online accounts, I went straight down the list in my password manager, logged into each one, and changed the email address in my profile. For family and friends, I just sent a text message or email with my new email address. The aliases are 100% individualized – every single account has its own alias.
So far, it’s been a dream come true. The Fastmail UI is a breeze: creating the aliases and filtering rules was effortless and rapidly became second-nature. Receiving and sending have worked perfectly, and are now more or less instantaneous. And I have received no spam over the course of a week – literally none.
The only complication is that I can’t use Outlook as my mail account on desktop, nor the native messaging app on my phone, because neither one supports sending identities. Instead, I send either through the Fastmail web interface or Fastmail client apps (which are available for Windows, macOS, iOS, etc.) The Fmail web interface and apps are well-designed and intuitive, so switching email clients has been zero-friction. I hope that email clients like Outlook add support for sending identities, but it seems unlikely without widespread awareness and acceptance.
Conclusion
After years of struggling with spam, I believe that I have permanently solved the problem.
Moreover, I believe that this type of solution is the future of email.
Spam is a growing problem in every communication modality – email, SMS, and of course phones. The public increasingly demands solutions in each modality, such as do-not-call lists, mobile device block lists and filters, and gatekeepers like RoboKiller. As the public generally embraces measures to combat spam across all modalities, I hope that more people will discover and adopt this type of solution. I hope that this post will aid people who are in search of solutions to the kinds of spam issues that I encountered.