[Last updated: 26 January 2024]

Email isn’t going anywhere. No matter how many alternative protocols and chat clients we create. This is not without its reason. It integrates with automation and bots, is an exportable archive of conversations, and makes it easy to include new people in the conversation. Except there is the issue of the all-too-real 200+ a day inbox.

A while back, while playing with a Postfix mail server (as you do), I came across an interesting thing called sub-addressing that can help with automatically organizing emails. It is a simple no-fuzz-way to create on-the-fly email separation capabilities that are especially useful for registering online accounts. Here are some use case examples to better illustrate.

Alice has an email address (alice@example.com) and she receives a steady torrent of email. If she could filter out the newsletters, bulletins and marketing materials to one folder it would be easier to follow conversations she is having. Re-registering for the newsletters she uses + to create a sub-address of alice+newsletters@example.com. The newsletters are still delivered to her regular email, but now with the sub address added in the To: field.

Whipping up an email filter she has all emails to this address automatically sorted into the Newsletters sub folder in the inbox. Even if some of the newsletters switch from Mailchimp to SubStack (other providers available) resulting in a new From: address, the emails still get sorted.

One day she is at a conference and needs to connect her laptop to the hotel WiFi, which requires registration. Alice sub-addresses her email to alice+hotel-name-wifi@example.com and registers. She sets up a quick email rule that checks any email coming to alice+hotel-name-wifi@example.com has to come from an @hotel-name.com address or be automatically put in the spam folder.

A few years later the company supplying the WiFi portal service to the hotel is broken into by cyber criminals. Over two hundred thousand email addresses are stolen and sold far and wide to every spammer and scammer under the sun. Alice’s inbox starts receiving strange spam, marked with the hotel WiFi sub-address, but thanks to the filter and sub-address she never sees the emails.

After some time however she notices the rapid increase of spam messages in her spam folder. She reaches out to Bob in IT, whom was with her at the conference, informing him that he may be targeted of spear phishing as a result of the breach.

Bob sees an opportunity and uses the alice+hotel-name-wifi@example.com address as a spam honey pot, automatically rejecting any address that has sent spam to the address. Hopefully helping to safe guard any other employees that have stayed at the hotel over the years.

Granted, this is a hypothetical, so how about a use case from my past. Had I known of sub addressing back then things would have been much easier.

In this case there is a shared inbox - support@example.com - as is common in some support team structures. Each team member has used the settings in their email client for the support account (one line in account settings) to change their “from” email address to support+name@example.com when replying to any emails in the support inbox.

Carlos sends an email to support@example.com and Denice picks up the case. As she has configured her email as support+denice@example.com any replies from the client will use this extended email address. A quick email filter, this time implemented on the mail-server itself rather than email clients of the users, auto sorts all responses from the client to the Denice sub-folder of the shared inbox. This frees up the shared inbox, and makes it easier for the other team members to see new cases as they come in.

The case progresses and after a week they are nearing a resolution. Except there is now a ticking clock. If the issue is not resolved within the next five hours, Carlos is liable to be saddled with fines in the millions due to incorrect paperwork supplied to the tax authorities. Denice is ready to send the corrected papers but is missing the tax filing number of the original filing.

Sending an urgent email to the client she edits the From: field as a one-time action in her email client and adds +URGENT. Adding a filter to her email client he sets an alert to play when an email is received from the client responding to the new sub-address. With an hour to spare, the klaxon sound alerts Denice to the reply. She sends the papers and Carlos avoids being fined into oblivion.

One thing to keep in mind is that the extended address scheme (RFC5233) is an optional standard so not all email providers support it, but both Gmail and Outlook do. and most default Postfix installations seem to along with most providers using Sieve email filtering. If you don’t know if your email service supports it, try sending an email to yourself with a +test added and see if it arrives with the sub-address intact.

As you can see, extended email addresses have many uses. The only limitation is your imagination and email filters.

Addendum 1

[04.05.2023] As pointed out by Jomo, the imagined first use case of Alice and Bob makes the assumption that spammers are unaware of sub-addressing. Which they are not. It appears to be fairly common practice for spammers to sift for and remove the sub part of email addresses. The secondary use case of Carlos and Denice is still entirely plausible, so the following ideas for potential work arounds will focus on the anti-spam use case.

As this is not the best covered area of spam protection (or the algorithms are simply not giving me what I want) these ideas are purely theoretical - while working as a technician and system administrator there was little focus on email infrastructure as we relied on a paid email provider for most of our needs.

For self-hosted infrastructure

For those in organizations running their own email infrastructure (eg. using Postfix and Dovecot) it is possible to use a different separator character sequence than ‘+’. If the naming scheme for company emails is .@example.com then the separator could be set to ‘-’ (or vice versa) which is a common character found in email addresses.

Alternatively a custom Sieve filter could be deployed looking for other non-standard naming schemes to achieve the same function as sub-addressing. Though this could easily become unmanageable and a bottle neck for smooth speedy email operations.

Granted, without seeing examples of common regex/filtering techniques used by spammers I do not know if this is an efficient obfuscation.

For paid email provider users

For those organizations relying on a paid email provider I can imagine two possible solutions:

  1. Use email aliases setup ahead of time (ex. alice-registrations@example.com). The onus then being on the user to filter any mail delivered via the alias to their spam folder and having to manually sift and mark registration emails that are not spam.

  2. An internal mailbot with a dedicated inbox. Users still use sub-addressing but instead use something like +1234-hotel-name-wfi with the part before the first hyphen being the denominator as to whom it is to be delivered (each user having to note down their “spam” number). Any email sent to the inbox with a valid spam number is forwarded to the relevant user, any without a sub-address is discarded.

The first solution is cumbersome and requires some setup, defeating the “on the fly” nature of sub-addressing, while the second solution relies on a form of [security through obscurity](https://en.wikipedia.org/wiki/ Security_through_obscurity) which is frowned upon (with good reason).

However, if your threat model is “spammers avoiding manually checking mailing lists by using automated tools to strip sub-addresses” then this could work.

A big thank you to Jomo for pointing out the false assumption. As the old cryptography axiom goes (paraphrasing) anyone can design a system they themselves cannot break - but will break on first contact with the outside world.

Happy emailing, and don’t forget to backup your email filters.