Les adresses e-mail sont-elles sensibles à la casse?

J'ai lu que la première partie standard de l'e-mail est sensible à la casse, mais j'ai essayé d'envoyer un e-mail à [email protected], [email protected]et [email protected]- il est arrivé dans chaque cas.

Comment les serveurs de messagerie gèrent-ils les noms d'utilisateur? Est-il possible de rater l'affaire et ce message ne serait pas transmis? Est-il vraiment très important d'utiliser exactement la même casse, comme cela a été écrit lors de l'inscription en donnant votre adresse e-mail?

De RFC 5321, section 2.3.11 :

La convention de dénomination standard de la boîte aux lettres est définie comme "local-part @ domain"; l'utilisation contemporaine permet un ensemble d'applications beaucoup plus large que les simples "noms d'utilisateur". Par conséquent, et en raison d'une longue histoire de problèmes lorsque des hôtes intermédiaires ont tenté d'optimiser le transport en les modifiant, la partie locale DOIT être interprétée et affectée à la sémantique uniquement par l'hôte spécifié dans la partie domaine de l'adresse.

Alors oui, la partie avant le "@" pourrait être sensible à la casse, car elle est entièrement sous le contrôle du système hôte. En pratique cependant, aucun système de messagerie largement utilisé ne distingue les différentes adresses en fonction de la casse.

La partie après le signe @ est cependant le domaine et selon la RFC 1035 , section 3.1,

"Les serveurs de noms et les résolveurs doivent comparer les [domaines] de manière non sensible à la casse"

En bref, vous êtes sûr de traiter les adresses e-mail comme insensibles à la casse.

Je sais que c'est une vieille question, mais je veux juste commenter ici: dans la mesure où les adresses e-mail sont sensibles à la casse, la plupart des utilisateurs seraient "très imprudents" pour utiliser activement une adresse e-mail nécessitant des majuscules. Ils cesseraient bientôt d'utiliser l'adresse car il leur manquerait beaucoup de courrier. (À moins qu'ils n'aient une raison précise de compliquer les choses et qu'ils n'attendent du courrier que de la part d'expéditeurs spécifiques qu'ils connaissent.)

C'est parce qu'il existe des humains imparfaits ainsi que des logiciels imparfaits, (Surprise!) Qui supposera que tous les e-mails sont en minuscules, et pour cette raison, ces humains et ces logiciels enverront des messages en utilisant une "version inférieure" de l'adresse, quelle que soit la façon dont ils ont été fournis. pour eux. Si le destinataire n'est pas en mesure de recevoir de tels messages, il ne tardera pas à remarquer qu'il manque beaucoup et à passer à une adresse e-mail en minuscules uniquement, ou à configurer son serveur pour qu'il ne respecte pas la casse.

Bien en retard à ce poste, mais j'ai quelque chose de légèrement différent à dire ...

>> "Are email addresses case sensitive?"

Eh bien, "ça dépend ..." (TM)

Certaines organisations pensent en fait que c'est une bonne idée et leurs serveurs de messagerie imposent une sensibilité à la casse.

Donc, pour ces endroits fous, "Oui, les e-mails sont sensibles à la casse."

Remarque: ce n'est pas parce qu'une spécification dit que vous pouvez faire quelque chose que c'est une bonne idée de le faire.

Le principe de KISS suggère que nos systèmes utilisent des e-mails insensibles à la casse.

Alors que le principe de robustesse suggère que nous acceptons les e-mails sensibles à la casse.

Solution:

• Stockez vos e-mails en respectant la casse
• Envoyer des e-mails en respectant la casse
• Effectuer des recherches internes avec insensibilité à la casse

Cela signifierait que si cet e-mail existe déjà: [email protected]

... et un autre utilisateur arrive et souhaite utiliser cet e-mail: [email protected]

... que notre logique de recherche insensible à la casse renvoie un message d'erreur "Cet e-mail existe déjà".

Maintenant, vous avez une décision à prendre: cette solution est-elle adéquate dans votre cas?

Sinon, vous pouvez facturer des frais de commodité aux clients qui demandent une assistance pour leurs e-mails sensibles à la casse et implémenter une logique personnalisée qui autorise [email protected] dans votre système, même si [email protected] existe déjà.

Dans ce cas, votre logique de recherche / validation de courrier électronique pourrait ressembler à quelque chose de ce pseudocode:

if (user.paidEmailFee) {
   // case sensitive email
   query = "select * from users where email LIKE ' + user.email + '"
} else {
   // case insensitive email
   query = "select * from users where email ILIKE ' + user.email + '"
}

De cette façon, vous appliquez principalement l'insensibilité à la casse, mais vous permettez aux clients de payer pour cette assistance s'ils utilisent des systèmes de messagerie qui prennent en charge de telles absurdités.

ps ILIKE est un mot clé PostgreSQL: http://www.postgresql.org/docs/9.2/static/functions-matching.html

Normes ouvertes IETF RFC 5321 2.4. Principes de syntaxe générale et modèle de transaction

Les implémentations SMTP DOIVENT prendre soin de préserver le cas des parties locales de boîte aux lettres. En particulier, pour certains hôtes, l'utilisateur "smith" est différent de l'utilisateur "Smith".

Les domaines de boîtes aux lettres suivent les règles DNS normales et ne sont donc pas sensibles à la casse

Par @ l3x, cela dépend.

Il existe clairement deux ensembles de situations générales où la bonne réponse peut être différente, ainsi qu'une troisième qui n'est pas aussi générale:

a) Vous êtes un utilisateur qui envoie des mails privés :

Très peu de systèmes de messagerie modernes implémentent la sensibilité à la casse, vous pouvez donc probablement ignorer la casse et choisir la casse que vous souhaitez utiliser. Il n'y a aucune garantie que tous vos courriers seront livrés - mais si peu de courriers seraient affectés négativement que vous ne devriez pas vous en soucier.

b) Vous développez un logiciel de messagerie :

Voir l'extrait RFC5321 2.4 en bas.

Lorsque vous développez un logiciel de messagerie, vous souhaitez être compatible RFC. Vous pouvez rendre les adresses e-mail de vos propres utilisateurs insensibles à la casse si vous le souhaitez (et vous devriez probablement). Mais pour être conforme à la RFC, vous DEVEZ traiter les adresses externes comme sensibles à la casse .

c) Gestion des listes d'adresses e-mail appartenant à l'entreprise en tant qu'employé :

Il est possible que le même destinataire de l'e-mail soit ajouté à une liste plus d'une fois - mais en utilisant une casse différente. Dans cette situation, bien que les adresses soient techniquement différentes, un destinataire peut recevoir des e-mails en double. La façon dont vous traitez cette situation est similaire à la situation a) dans la mesure où vous pouvez probablement les traiter comme des doublons et supprimer une entrée en double. Il est toutefois préférable de les traiter comme des cas particuliers en envoyant un courrier de "rappel" aux deux adresses pour leur demander s’il s’agit de doublons et, dans l’affirmative, quelle adresse e-mail le destinataire préférerait utiliser.

D'un point de vue juridique, si vous supprimez un doublon sans accusé de réception / autorisation des deux adresses, vous pouvez être tenu responsable de la fuite d'informations privées / authentification vers une adresse non autorisée simplement parce que deux destinataires réellement distincts ont la même adresse avec des cas différents .

Extrait de RFC5321 2.4:

La partie locale d'une boîte aux lettres DOIT ÊTRE traitée comme sensible à la casse. Par conséquent, les implémentations SMTP DOIVENT prendre soin de préserver la casse des parties locales de boîte aux lettres. En particulier, pour certains hôtes, l'utilisateur "smith" est différent de l'utilisateur "Smith". Cependant, l'exploitation de la casse des parties locales de boîte aux lettres empêche l'interopérabilité et est déconseillée.