That wouldn’t work for such cases. If someone legitimately had MRAY@ and wants to sign up, they simply couldn’t get an account at all even if mray@ never signed up. All attempts to register MRAY@ would get sent to mray@
- store case as entered for ident
- use case-insensitive uniqueness test (do not allow mray@ and MRAY@ to both register accounts)
- send all emails using the ident case
- allow log-ins and resets to be case-insensitive
Thus, if mray@ exists and MRAY@ tries to log in, they’d still need the pass. But if MRAY@ tries to reset the pass, the email will go to mray@. Same in reverse. If MRAY@ registers, then mray@ will not be allowed to sign-up — but if mray@ tries a pass reset, the reset email will go to MRAY@ still as that is the ident originally registered.
I propose this as the solution. From everything I can think, this addresses any security and UX problems. The issue of not allowing two users with case-only-difference emails is unlikely to ever be a real issue.
I don’t have data from the sysadmin side really, but I searched around online and found that near-universal dominant approach is that emails are case-insensitive, and then the odd comment here and there of someone saying there really are two John Smiths at a business who have two emails that are different only in case. So, it seems that’s real and fits the spec, but almost all orgs ignore it.
I did also find it common (certainly not universal though) for the ID part of logins to be case-insensitive even when the ID is not an email address. (Obviously passphrases stay case-sensitive in all cases)