[nzach]

Some people really love putting dumb validation rules for emails in forms... You would be surprised to know how many system in the real world will just refuse anything that is not a letter or a number in your email.

And the 'fuck them, I won't do business with them' attitude doesn't really work if the system that wont accept your email is the local gas company.

And there is another problem, some systems will just remove any label without informing you. I've had this problem logging in some random websites. My account was created with [e-mail] but to log I had to use [e-mail].

[radlad]

Not surprised at all, I've been using the Internet and writing software for a couple decades now. Heck, I might've written one of the validators you're complaining about. But they are typically written to avoid +, for the exact reasons you described.

For those sites, you can add a dot in your username. Then you can ignore any emails sent to an address without the presence of a dot or a plus.

I'm sure there are sites that don't accept dots either, but I've never run into one. So you have to make an exception? Oh well.

I agree that it's easiest to do with [e-mail], like the grandparent suggested.

[centur]

IIRC dot is one of the characters that can't be discarded when checking local addr part (RFC 5322). So [e-mail] and [e-mail] are different addresses really. As far as I understand - it's a Gmail's team decision to configure local addr interpretation and allow `[e-mail]` and `[e-mail]` to be treated as the same address. I'd expect that dot trick rarely works anywhere outside of gmail world.

+ sign is part of the standard (`atext` token, RFC 5322), so sites, which disallow it in address are doing it wrong. The fact, that industry adopted a practice of using everything after + sign as a "tag" is not captured anywhere so this creates even more mess in already messy space (e.g MS followed GSuite in this too and added subaddressing - https://learn.microsoft.com/en-us/exchange/recipients-in-exc...)