Les adresses électroniques sont-elles sensibles à la casse?
J'ai lu que la première partie standard d'un e-mail est sensible à la casse. Cependant, j'ai essayé d'envoyer un e-mail à [email protected], [email protected] et [email protected] - il est arrivé chaque cas.
Comment les serveurs de messagerie gèrent-ils les noms d'utilisateurs? Est-il possible de rater un cas et ce message ne serait pas transmis? Est-il vraiment très important d’utiliser exactement la même boîte de lettres que celle utilisée lors de l’enregistrement lors de l’enregistrement de votre adresse électronique?
De RFC 5321, section-2.3.11:
La convention de dénomination de boîte aux lettres standard est définie comme "local-part @ domain"; L’utilisation contemporaine permet un ensemble d’applications bien plus large que les simples "noms d’utilisateur". En conséquence, et en raison d’un long passé 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 la sémantique attribuée uniquement par l’hôte spécifié dans la partie domaine de l’adresse.
Donc, oui, la partie précédant 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 différentes adresses en fonction de la casse.
La partie après le signe @ est cependant le domaine et selon RFC 1035, section 3.1,
"Les serveurs de noms et les résolveurs doivent comparer [domaines] sans tenir compte de la casse"
En bref, vous pouvez traiter en toute sécurité les adresses électroniques en respectant la casse.
Je sais que c’est une vieille question, mais j’aimerais juste faire un commentaire ici: dans la mesure où les adresses électroniques sont sensibles à la casse, la plupart des utilisateurs seraient "très imprudents" d’utiliser activement une adresse électronique nécessitant des majuscules. Ils cesseraient bientôt d'utiliser l'adresse parce qu'il leur manquerait beaucoup de courrier. (À moins qu'ils aient une raison particulière de rendre les choses difficiles, et qu'ils n'attendent du courrier que d'expéditeurs spécifiques qu'ils connaissent.)
C'est parce qu'il existe des humains imparfaits ainsi que des logiciels imparfaits (Surprise!) Qui supposent que tous les courriels sont en minuscule. Pour cette raison, ces humains et ces logiciels enverront des messages en utilisant une "version en minuscule" de l'adresse, quelle que soit la manière dont il a été fourni. pour eux. Si le destinataire est incapable de recevoir de tels messages, il ne faudra pas longtemps avant de s'apercevoir qu'il en manque beaucoup, de basculer vers une adresse e-mail en minuscules uniquement ou de configurer son serveur pour qu'il soit insensible à la casse.
Bien trop tard pour ce billet, mais j'ai quelque chose de légèrement différent à dire ...
>> "Are email addresses case sensitive?"
Eh bien, "Cela dépend ..." (TM)
Certaines organisations pensent en fait que c'est une bonne idée et leurs serveurs de messagerie imposent la sensibilité à la casse.
Donc, pour ces endroits fous, "Oui, les courriels sont sensibles à la casse."
Remarque: le fait qu'une spécification indique que vous pouvez faire quelque chose ne signifie pas que c'est une bonne idée de le faire.
Le principe de KISS suggère que nos systèmes utilisent des courriers électroniques insensibles à la casse.
Considérant que le principe de robustesse suggère que nous acceptons les courriels sensibles à la casse.
Solution:
- Stocker les emails avec sensibilité à la casse
- Envoyer des emails avec sensibilité à la casse
- Effectuer des recherches internes sans tenir compte de la casse
Cela voudrait dire que si cet email existe déjà: [email protected]
... et un autre utilisateur arrive et souhaite utiliser ce courrier électronique: [email protected]
... que notre logique de recherche sans distinction de casse renverrait un message d'erreur "Cet email 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 autorisant [email protected] dans votre système, même si l'[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 tout en permettant aux clients de payer pour cette assistance s'ils utilisent des systèmes de messagerie prenant en charge de telles absurdités.
p.s. ILIKE est un mot clé de PostgreSQL: http://www.postgresql.org/docs/9.2/static/functions-matching.html
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 la casse des parties locales de la 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.
Per @ l3x, ça dépend.
Il existe clairement deux types de situations générales dans lesquelles la réponse correcte peut être différente, ainsi qu'une troisième moins 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 êtes donc probablement en mesure d’ignorer la casse et de choisir le 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 préoccuper.
b) Vous développez un logiciel de messagerie :
Voir l'extrait de la RFC5321 2.4 en bas.
Lorsque vous développez un logiciel de messagerie, vous voulez être conforme à RFC. Vous pouvez rendre les adresses électroniques de vos propres utilisateurs insensibles à la casse si vous le souhaitez (et vous devriez probablement le faire). Mais pour être conforme à la RFC, vous DOIT traiter les adresses extérieures comme sensibles à la casse.
c) Gestion des listes d'adresses électroniques appartenant à l'entreprise en tant qu'employé :
Il est possible que le même destinataire de courrier électronique soit ajouté à une liste plusieurs fois, mais en utilisant des cas différents. Dans cette situation, bien que les adresses soient techniquement différentes, le destinataire pourrait recevoir des courriels en double. La façon dont vous traitez cette situation est similaire à la situation a) en ce sens que vous êtes probablement correct pour les traiter en double et pour supprimer une entrée en double. Il est toutefois préférable de traiter ces cas comme des cas particuliers, en envoyant un courrier de "rappel" aux deux adresses pour leur demander s’ils se dupliquent et, le cas échéant, quelle adresse électronique le destinataire préférerait utiliser.
D'un point de vue juridique, si vous supprimez un duplicata sans accusé de réception/autorisation des deux adresses, vous pouvez être tenu pour responsable pour avoir divulgué des informations privées/authentification à une adresse non autorisée simplement parce que deux destinataires réellement séparés ont le même adresse avec différents cas.
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 pièces locales de la 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 sensibilité à la casse des parties locales de la boîte aux lettres nuit à l'interopérabilité et est découragée.