So if my email is HeLLo@example.com because I want to be cute people will have to try 6 times before they finally get the right email address? Imagine telling that to someone in person. This kind "weird" casing isn't that rare and doesn't require cute usernames: "DonaldDuck@example.com", "FreeBSD@example.com", "DrMcCoy@example.com", etc.
Languages that don't have case is not an issue; the situations where a lowercase <-> uppercase mapping is not simple are actually not that many. It's not trivial, but not all that complex either. The most annoying part is Turkish, Azeri, and Lithuanian where the rules differ a bit but the used language is often unknown. For the purpose of matching things ("is this email address known in our system?") it's actually not that hard, since you can just treat several characters as identical (displaying text correctly to users is harder, but that's not important here).
I see this attitude in various situations, often under "falsehoods programmers believe" articles, which goes something like "it's hard in a few rare cases, therefore we should not do it at all for the >99% cases where it's simple and unproblematic".
It is fine to have multiple email addresses connected to a single inbox. Email providers already do normalization like this that is not baked into the spec. Gmail for example treats johndoe@gmail.com and john.doe@gmail.com the same.
Well, maybe Google should check their own implementation, because interesting things happen when accounts for both version exist.
I have an account with the dot, that was made in age, when Gmail was invite-only. Few years ago, someone created an account without the dot. Yes, I'm receiving their mail, and have no way to contact them, because everything I send out comes back to me.
Not only do people do this, it's actually extremely common, ask anyone with commonname@gmail.com. Someone here said their original email address has become unusable because it gets thousands of messages a day that are intended for other people. "That guy" might actually be multiple people all making the same mistake with your email address.
My coworker told me there's a complete stranger who, every time she emails her son, accidentally sends the email to him first. This has been going on for years, she makes the same mistake every time, she doesn't learn her son's actual email address, and she doesn't learn to press "reply."
I'm 100% sure the "non-dot-version" doesn't exist as a separate account.
AOL used to allow users to email other users without using the @aol.com extension. Back in those days I (prior to any capacity to negotiate a sensible ISP, for the record) had an email that matched a common subject line that was inundated by people who typed their subject in the To line and then wrote an email.
And that’s why I regularly receive other people’s mail in my gmail inbox, and why i have stopped using gmail for anything important (it’s right to assume that gmail is also sending my emails to other people).
Google’s gmail people aren’t really as smart as they think they are.
That's something I don't understand. I've always given my email as john.doe@gmail.com, and I sometimes receive emails - addressed to Another John Doe - sent to johndoe@gmail.com.
That Another John Doe never, ever had access to johndoe@gmail.com, they just gave a wrong address. That's not gmail's fault.
That Another John Doe never, ever had access to johndoe@gmail.com, they just gave a wrong address. That's not gmail's fault.
This. My wife and I have two flavors of this.
Her address is firstmlast@gmail.com. There people frequently forget the m initial and somebody else owns firstlast@gmail.com She's since started using dots first.m.last to mitigate the error.
My address is firstlast@gmail, where first and last are not globally common, but are fairly common in Scotland. Once a year or so, I receive email for somebody else that shares my name. I don' know his real email, but I've been "invited" on his family vacations 3-4 times now. Infrequent enough that I just respond "thanks for the invite, but I think you'll be disappointed when I arrive and not the Alistair you were expecting."
Or someone assumed (or just tried) that other email address.
I signed up for my university's email forwarding for alumni early on and got my first name as my email. For quite a while, I would get emails, including fairly sensitive ones, sent to me by not yet very email savvy people just assuming you could send an email to someone's first name and it would get to them.
Nah, it happens with mangled names that no bot would ever try to stuff, too. E.g. I own derefr@gmail; but I sometimes receive email from people trying to reach a man named "Derek" — who almost certainly owns the address derek.fr@gmail, but probably typoed it once as dere.fr@, and now his browser autocompletes that into registration forms for him.
This doesn't really make any sense. It's not just gmail that does this, dots are almost always ignored before the @.
Nobody else can register an email that is the same as yours but without a dot. So the only way you receive someone else's email is if they give the wrong address.
> It's not just gmail that does this, dots are almost always ignored before the @.
That's not my experience. Which non-gmail email software ignores dots before the @?
Thinking about this, I guess the sending MTA doesn't care about dots; it goes RCPT TO: <address.with.dots@example.com>. The receiving MTA then has to validate that address; it does that using some account database that isn't typically part of the MTA - it could be a unix account (no dots!), a database table, or an LDAP user. Finally it passes the mail off to a delivery agent, which hopefully relies on the same account database.
So the elision of dots appears to be a feature of certain account databases. So which account databases elide dots?
MTAs can be configured to additional transforms before looking up the account. For example, postfix's virtual table [0] can be used for this and on my server it does elide dots in the local part (along with everything else).
> So if my email is HeLLo@example.com because I want to be cute people will have to try 6 times before they finally get the right email address? Imagine telling that to someone in person.
Yeah. That's fine.
If my email is LLLLLLLLLLLL@example.com because I want to be cute I have to tell people to type exactly the right number of L's. Do you think they should just be able to type a lot of L's and as long as it's somewhere near it counts as the same email address?
In a world where email addresses are always case sensitive, everyone will use lowercase (like they pretty much always already do anyway), and it'll be fine.
The only reason "LLL" and "lll" mean the same thing are because currently email addresses are (sometimes) case insensitive.
In a world where email addresses were "obviously" case sensitive, "LLL" mapping to "lll" would be just as crazy as "LLLLLLLLLL" mapping to "LLLLLLLLLLL".
They just seem similar, to humans. But they're different strings.
By maps to, they mean it counts as the same email address. 111@ and lll@ do not do that. The font has no impact on the email spec. However it can add extra confusion.
I doubt anyone is crazy enough to implement the email spec for comparing emails, to be fair. I would honestly be surprised if any publicly available mail agent or server supports that craziness.
Languages that don't have case is not an issue; the situations where a lowercase <-> uppercase mapping is not simple are actually not that many. It's not trivial, but not all that complex either. The most annoying part is Turkish, Azeri, and Lithuanian where the rules differ a bit but the used language is often unknown. For the purpose of matching things ("is this email address known in our system?") it's actually not that hard, since you can just treat several characters as identical (displaying text correctly to users is harder, but that's not important here).
I see this attitude in various situations, often under "falsehoods programmers believe" articles, which goes something like "it's hard in a few rare cases, therefore we should not do it at all for the >99% cases where it's simple and unproblematic".