The period thing is a Gmail feature, not a standard. some.email@mydomain and someemail@mydomain most certainly do not deliver to the same mailbox.
For example, a malicious user can register
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
What is a problem, and what is non-standards-compliant, is GitHub incorrectly assuming that all mail providers will do this when many do not. It would be no different from assuming that "admin" and "postmaster" go the same mailbox because that's the way a lot of software is configured.
And the only way it can be automated is if the service doesn't protect itself against automated user sign-ups, which they will either start doing once someone really takes advantage of it, or will result in their domain being categorised as spam once they start sending lots of sign-up emails (either by the user or gmail in general).
That's why we keep your verified mailbox address for sending mail; but there's no good reason to consider them different for the purpose of identity.
Both of Microsoft's own identity services (AAD and Live ID, and by extension O365 and Outlook.com) recognize (and allow creation of) [email protected], [email protected], and [email protected] as distinct identities/email addresses.
What you're saying is that once the first of (microcolonel|micro.colonel|mic.rocolonel)@example.com registers at github, the other two will no longer be able to do so, but will instead receive a confusing 'you already have an account' error, (hopefully) without being able to receive password reset emails.
A false postive in these identity checks is likely to be less destructive than a false negative. But I still don't get the point of making up all sorts of rules not in the standard. I have seen both + as well as meaningful dots in e-mail adresses in the wild.
Google was the first installation I know of to silently swallow periods. Plus-addressing was well-known back in the day, but as far as I know GUI mailers more or less killed the practice by not offering support for it, and web sites written by people too smart to know how to validate email addresses ensured you can't even use them properly anymore.
Ref: http://www.faqs.org/rfcs/rfc822.html, pages 8/9.
I doubt we'll ever turn away a customer by preventing registration of a new account sharing the prefix to a plus sign in their email address with an existing customer.
RFC 822:
The local-part of an addr-spec in a mailbox specification (i.e., the host's name for the mailbox) is understood to be whatever the receiving mail protocol server allows.
I repeat, this has absolutely nothing to do with the mailbox address, where we send mail.
Are you suggesting I shouldn't be allowed an account with you if the person who beat me to my preferred email address also beat me to registering with you?
It's like deciding to not allow quoting and with this whitespace. Sure ":"@example.com is a legal mail address (surprised?) but nothing good will come from allowing it.
It might make them bad netizens and you may not like it. But the spec doesn't compel any behavior. It's just a way to communicate technical ideas and ideals.
You're under no obligation to accept names that are hard (as in painful) for you (except if you're the police, I suppose. Ironically)
You can't break user expectations and mental models by pointing to the spec as justification. The spec exists to serve users, not the other way around.
In the absence of being able to count on specs, I guess the user should expect a race?
Most of them can't specifically point to the problem, their impression is just that your services don't work properly. They're right.
Assuming they don't just fail to register and move on ...
So at best you can special case for those "major hosts" and not apply such treatment to any other domain.
The RFCs for email don't say "uhh dude whatever, just check what gmail does and maybe hotmail too lol". You are playing fast and loose with these things.
We accomplish this with a slightly more restrictive version of the standard ABNF provided in the RFC.
I guess I should probably document why we go to this trouble, in case somebody gets the brilliant idea to "simplify" it.