Why ‘john.doe+shopping’ Shouldn’t Break Your App (But Does)

A rant about internet standards, e-mail, plus-aliases, and why reading the RFCs matters.

The Internet is a mess

E-Mail is a mess. It has been around since the 80s and has been implemented hundreds, if not thousands, of times by different people, in different ways, with different levels of compatibility.

But: everything in the internet that has to be interoperable and that is older than 1 year is a mess. As humans, we never get a design right on the first try. People want new features. Security issues are found. So a new scheme is designed. But because not everyone will upgrade to the new scheme (because of cost, unawareness, loss of skilled staff, or just not caring), the updated scheme has to be backwards compatible with the old scheme. And what is worse, many did not even implement the old scheme correctly.

Thus over time, as new requirements come in, the whole thing inevitably evolves into a huge pile of patches.

E-Mail is not alone here, you can find this pattern in most, if not all, (internet) protocols. Just look at the Internet Protocol (IP) and NAT: even 25+ years later, many big organisations are still not migrating to IPv6 – not successfully, or not at all. (I have studied and worked at such organisations. In 2025, there are still IPv4-only mobile carriers in Switzerland.) So instead of IPv6, we got NAT. And because of NAT, we got STUN, TURN, and ICE. (To learn more about NAT, I highly recommend Eric Rescorla’s four-part series.)

In fact, we are moving towards a new narrow waist of the OSI model.

NAT is an example where it was made to work: WebRTC works, your Jitsi/Zoom/Teams/Signal/WhatsApp calls work. Even though under the hood, there is a pile of protocol patches trying to find a way through your home network’s NAT sitting behind a CGNAT, because your ISP could not be bothered.

It is easy to say “let’s abandon e-mail and build something better and more modern”. If your new thing is centralised: great, that will work for you. But if your goal is to build something that is interoperable (“federated”) across different entities, then your system will, over time, evolve into a similar mess as all the other protocols before.

Plus-aliases

Back to e-mail: one of my pet peeves is the so-called “plus-alias”.

If my main email address is “john.doe@example.com”, then “john.doe+shopping@example.com” and “john.doe+banking@example.com” are two plus-aliases. You can suffix your username (the local-part) with “+” and some label. These new emails will be delivered to your normal inbox.

This is NOT supported by all email providers. GMail and Proton Mail support this, but your university or work email might not.

This is where internet standards¹ come in:

1. The “+” character is allowed in the local-part. In fact, like it or not, all of these characters are allowed in the local-part:

! # $ % & ' * + - / = ? ^ _ ` { | } ~

So as far as the IETF standards are concerned, john!#$doe%&'=?{shopping+bank}@example.com is a valid e-mail address.

2. The local-part is locally interpreted. “[…] it is simply interpreted on the particular host as a name of a particular mailbox” (RFC 5322). So if GMail decides to interpret the “+” as an alias, and another mailserver interprets it as separate mailboxes, this is completely up to them. It is NOT up to the sender to make any decision about this.

All of this is defined in RFC 5322, which defines the format of Internet Messages. It superceded RFC 2822, which in turn superceded the original RFC 822, written for the ARPANET in 1982.

People ignore standards

Unfortunately – and this part is my pet peeve – there is a lot of software that thinks that “+” is not a valid character in the local-part.

I have seen this fail in so many wonderful ways:

• In the best case, the input form (wrongly) claims “this is not a valid e-mail”.
• Some sites will let me register an account with a plus-alias e-mail, but then won’t let me log in with it.
• Some sites silently strip the “+” (“john.doeshopping@example.com”). This is obviously a different address, so the mailhost will interpret it differently. I had to register a new e-mail account once in order to regain access to my domain registrar after their internal migration stripped my “+”.
• Putting the email address in an URL, but not URL-encoding the address, (+ would need to be encoded as %2B). This often happens in links such as “click here to confirm your e-mail address for this account”. And it breaks those links.

Companies have lost business over not supporting plus-aliases. I have turned to alternatives or have lost interest completely when a site didn’t let me register with a plus-alias.

Why bother?

The easy way would be to just stop using plus-aliasses. However, while it is annoying to recover from these bugs, I find it a very useful first indicator of how well (or badly) written the software is.

When they implemented e-mail handling, the people writing those softwares:

• Either never read the standards about e-mail. After all, “+” has been an allowed character ever since e-mail was designed in 1982.
• Are not e-mail power users, otherwise they would have been aware that GMail supports plus-aliases since at least 2008, i.e., 17 years ago.
• Or they knew, but had some technical reason or constraint to deny “+” anyway.

While I see some reason to ignore some characters (like / ` { | }), plus is not one of them. Plus-aliases are widely used:

• By “power users” – GMail has supported them for 17 years.
• By mailing list software. Look for headers like List-Unsubscribe: <mailto:listname+unsubscribe@example.org>
• By ticketing software. Look for headers like Reply-To: Acme Corp <support+id123456@acmecorp.zendesk.com>

So your software, too, ought to allow “+” in e-mail addresses. If only for compatibility with, you know, GMail.

Conclusion

Interoperable things, like e-mail, will grow to a bunch of patches over time. You can contribute to ameliorate the situation by reading the existing standards and actually implementing them. If you do that, you will make your customers happier. If everyone did that, it would make the work of the people who have to put patches on top of the existing pile a tiny bit easier. Thank you!