> Even now you run into the occasional validator that is convinced that the plus sign is not valid in email addresses.
These are intentional IMHO - force people to use their actual email address so a potential breach can't be tied back to the service. That's the only reason why someone would use a + in the first place.
Some validators are silly regular expressions that someone wrote in a minute without thinking about it ("Mastering Regular Expressions" has a regex associated with it for better matching an address; that regex is quite the sight to behold). And disallowing + is a crummy solution to whatever "force people to use their actual email address" means given that someone with full control of a domain can invent the alias whatevertheywant@example.org instead of using something with a + in it, or they can spin up an alternate address on some alternate provider, etc.
Other reasons folks use + in their email is to do mail routing (except where crappy web services disallow the + because they relied on a crappy regex) but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.
> but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.
Easy. Say I subscribe as "username+servicename@gmail.com" everywhere, when I get spam at that email address that service must have been either breached or sold off my data.
I built the authentication system on our website and as a regular user of Gmail + aliasing I was very surprised when my brother pointed out our website didn’t allow them.
Turns out the default for Microsoft’s ASP.NET Identity Framework is to disallow special characters, but simply setting a flag in its configuration rectified this.
These are intentional IMHO - force people to use their actual email address so a potential breach can't be tied back to the service. That's the only reason why someone would use a + in the first place.