> The fact that email addressed to some of them may end up in the same box is neither here nor there.

It's not an issue if they're the same, the issue is if they're different. E.g. if I'm storing bitcoin on an exchange (I know) behind the [email protected], then I don't want someone else to be able to register [email protected] and then start looking for bugs in the service or start trying to socially engineer customer support. (The local part of the email address is case sensitive as per the spec.)

You hit the nail on the head.

People can hem and haw about the specs, but at the end of the day Gmail trained most of the world to believe email addresses are case-insensitive, dots don't matter, etc., and now we have to live with the consequences. If that means somebody can't sign up for twelve accounts using case and dot variations of their Gmail, well, so be it. And if that means they come to HN to rant about how that awful site didn't follow the RFCs, then they come to HN to rant about that, but their account will be safer in spite of it.

Maybe. But, if I was legitimately [email protected] and you refused to allow me to register an account just because somebody else had a similar email, I'd be pretty annoyed. There's a good chance I'd take my business elsewhere.

I've only once had my email address rejected by a website (for ending with an underscore), but I never bothered setting up another email just for them.

And if the call-center person decided that '[email protected]' should be able to reset the password for '[email protected]' because they read a lifehack article about how dots in email addresses don't matter, you'd take your business elsewhere.

No matter what, there are reasonable hypotheticals where you get angry and take your business elsewhere. The difference is my approach has you leave because you're angry at the signup page, and your approach has you leave because someone stole your stuff. I'll take my approach any day of the week.

Given that we're developers and we make the tools that the help desk people use, why would we make a help-desk password reset that can send to a different address than the one registered with the account? Couldn't there be other social engineering tricks people could pull on your help desk employees that you haven't yet imagined? Maybe they also think it's ok to drop the underscore from my email address, despite that not being a part of the gmail scheme.

What about the "I've lost that email account, can I switch it to another to recover my account?" case. Or the "I'm the legal guardian of this person and need the account control switched to my personal email", or in the business world "this employee doesn't work here anymore and as administrator I would like the account transferred to me" cases. Locking customer support systems down tightly has it's own pros/cons.

I suppose I was more specific than I really should have been. More broadly, I'm trying to say that you have control over the tools and processes followed by your customer service. They can be used to combat social engineering.

For something as important as the credentials for a bitcoin exchange account, as Alex gave as his example, there should be policies specifying the reasons why account credentials can be changed and what evidence must be presented to do so. Front-line customer service reps shouldn't be flying by the seat of their pants when making difficult decisions with potentially hundreds of thousands of dollars on the line.

What happens when someone calls the CS person and tells them to type in their email address instead of copy pasting it or whatever. If there are any bugs at all in the CS software then it won’t be hard for the CS person to believe there is a bug they need to work around similar to the other bugs that are already in their dashboard.

The point of social engineering attacks is that they’re innocuous requests that don’t raise suspicion, and are hard to train people against.

OK. You go get every single company, site and service on earth to deploy a 100% perfect credential-recovery system and only have it used by 100% perfect people who never ever make a mistake. And when you've finished, let me know and I'll rethink my approach to email.

You don't need to make a system that's perfect. You just need to make a system in which checks are required to make _any_ change the credentials on an account. Once those checks are complete, it makes no difference if the change is from [email protected] to [email protected] or to [email protected].

It’s not just password resets that are the issue. It’s also things like:

- Functions to get the account based on the email address

- Internal tools

- Stored procedures and other SQL stuff that happens outside the main code base

- Third-part integrations (Mailgun, Sailthru, ZenDesk, SalesForce, etc.)

That’s a huge attack surface where if there is even a minor mistake by a junior dev that no one noticed then everyone is going to lose their assets under protection.

> Gmail trained most of the world

At least here in the UK, gmail has high reach among techies but is very much a minority provider for normal people. Looking through the 3000ish registered accounts on the local community website I run, Hotmail, Yahoo, and particularly ISPs (btinternet.com, plus.net, sky.com) are all more common than gmail.