Should I treat emails as case sensitive or insensitive?

Asked

Viewed 905 times

9

It is common to have a register, mainly of login requesting an e-mail address. According to the RFC governing e-mails and domains the first is case sensitive, while the second is insensitive, which in this case makes it much easier.

The problem is that the user is not required to know the RFC and respect this as much as when registering his email as when using the address for something in the system (login for example), and then you know, if you follow the RFC will give error to the user that he is using wrong email when for him is not wrong, the characters are, for him, visually the same.

The simple solution is to send RFC to #$@%&*! and consider what emails are case insensitive. Not without a problem, although rare, it may be that there are two different emails with the same text when we don’t look at their box.

So which of the two should be used? Has a specification or recommendation that can be considered universal?

Choosing to Treat How RFC Tells You What to Do When the User Puts The Email Wrong? Remembering that the wrong can be what he registered (maybe both are wrong).

Choosing to treat without box sensitivity, what to do when you have two ambiguous emails when this happens?

I remember that presenting registered emails in your system to disambiguate can be a breach of privacy or even security.

Requiring a lot at the time of registration can scare away a user who is entering your system.

I have some ideals to do, but a creative solution would be even more useful, even if it takes a little more work but have a fallback not to create too much problem.

The question is about the ambiguity of email addresses.

  • In all the systems I’ve worked on, I’ve always converted email addresses to lower case. I believe that the providers should do the same, since I do not remember seeing in capital letters...

2 answers

1

Specification or recommendation considered universal is the RFC (as well pointed out). The remainder and any other approach goes to the taste of the customer.

If you send an email to Apple servers (my case) or create an Apple ID, it doesn’t matter if you’re on uppercase or lowercase. They are treated as a single address. I can log into any of their services with uppercase or not. The same goes for Gmail/Google (the example in the attached image shows this).

Faced with this, if I were in your skin with this problem, my approach would be:

  1. Test the major email providers (Gmail, Apple, Hotmail, UOL) and understand how they behave with this issue. If it doesn’t matter to them the "box", I normalized everything in lowercase.
  2. Small providers or "strange" addresses, would leave as the user typed but would make a fallback for authentication.

I can’t see a "silver bullet" in the question, but the probability of there being two similar email addresses whose only difference is the box of a character is very remote and I don’t feel it’s worth much to think about.

Greetings

Exemplo de "diferentes" endereços

-1

There are providers today who accept high-volume emails and are case sensitive.

In these providers, if you change Uppercase to Lowercase or vice versa, it will not accept your login, after all it is case sensitive.

In the projects I have worked on, I have chosen to be case sensitive, after all it is the same that it will use on your provider to log in, and when I trigger any email communication to this user even for account confirmation, i had assurance that the email will arrive if it is correctly typed.

There are several applications where the rule can change... For communications where the user just typed his email to receive promotions and the like, and the same is not a concrete customer, just a possibility and there is no way to be sure that the same typed correct your email address, it may be feasible not to use case sensitive.

Another point is, if your application digests customer information, and it is highly accessed by mobile devices, possibly the keyboard already starts the first letter capitalized, which may cause divergence from the actual email, in this case may be more effective and may bring greater communication reach predicting that all will be lowercase. OR even apply a rule to receive and provide for this data.

Anyway, I know I didn’t respond in a concrete way and only hypotheses to this problem.

The conclusion is that the choice between how this information is digested depends on where it is being applied, and what it can be used for later.

  • 3

    Hey, there, Breno. It’s good you participate and contribute, but the way your post looks more like a personal report (which does not work very well in our model, would work better in forums) than a technical response. Remember that at any time you can [Edit] and improve the post (perhaps tracing pros and cons of possible solutions). A read on [Tour] and [Help], and other posts with punctuated responses can help you get familiar with the website template.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.