Category: programación

Para acceder a muchos sitios web (Facebook, Amazon, …) utilizamos como nombre de usuario nuestra dirección de correo electrónico. Para el desarrollador web es una forma sencilla de obtener una dirección de correo electrónico, que puede ser utilizada para varias acciones útiles dentro de la web: validar la inscripción en el sitio web, obtener o recuperar la contraseña de acceso, enviar notificaciones,… En otros sitios utilizan un nombre de usuario (Slashdot, Barrapunto, …), decisión que me gusta menos, ya que necesitas pedir más datos al usuario para realizar su registro, con los posibles abandonos en el registro que esto puede acarrear. Incluso bastantes sitios (Menéame, Stack Overflow,…) permiten registrarse y autenficarse con el usuario de Facebook, de Twitter o de Google+, con lo que el tiempo de registro es mucho menor y, por lo tanto, el porcentaje de abandono también es menor. Es un punto clave en el comercio electrónico, ya que muchas tiendas permiten añadir productos al “carrito de compra virtual” sin estar registrados y se solicita el registro al finalizar la compra, momento en el que se produce la mayor parte de los abandonos, perdiendo la venta.

Volvamos al registro que utiliza la dirección de correo electrónico como nombre de usuario. Algo tan sencillo para el usuario final como introducir su dirección de correo electrónico al registrarse o al acceder a la aplicación web plantea varias cuestiones al desarrollador de la aplicación web. Entre ellas está la que trataré de analizar en esta entrada, algo que puede parecer tan trivial y sencillo como qué hacer ante dos direcciones idénticas pero una escrita con minúsculas y otra con mayúsculas, como por ejemplo pepe@example.com y PePe@example.com

Lo primero que se nos puede pasar por la cabeza es convertir todo a minúsculas, de tal forma que tanto la inserción en la base de datos como las comprobaciones al tratar de encontrar usuarios ya existentes en el proceso de registro o al tratar de acceder al sistema el en proceso de autentificación utilicen siempre comprobaciones en minúsculas. Este planteamiento puede ser correcto, o no. Voy a plantear su análisis desde tres puntos de vista: el técnico, el del usuario final y el “estándar de facto” o lo que están haciendo las grandes compañías.

Técnico

Para analizar cómo debe afrontar un desarrollador este problema hay que ver cómo se define una dirección de correo electrónico. Esta está formada de la siguiente forma

user@example.com

La parte local de la dirección de correo electrónico (“user” en el ejemplo) solo puede utilizar  los caracteres ASCII indicados en la sección 3.2.3 del RFC 5322 (Internet Message Format), entre los que se encuentran las letras minúsculas y mayúsculas del alfabeto inglés. Aquí ya se hace una primera distinción de mayúsculas y minúsculas. En la sección 2.4 del RFC 2821 (Simple Mail Transfer Protocol) se aclara totalmente:

The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user “smith” is different from the user “Smith”. However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

Lo que viene a decir aquí es que los servidores de correo deben de ser sensible a mayúsculas, pero se recomienda mantener una política interna en la organización que evite estos problemas de colisión.

Además indica que la parte de dominio (lo que va despues de la @, en el ejemplo sería example.com) no es sensible a mayúsculas, tal y como se puede comprobar a lo largo del RFC 1035 (Domain names – Implementation and specification), leyendo los párrafos donde aparacen las palabras “case-insensitive” y como se aclara en el RFC 4343 (Domain Name System (DNS) Case Insensitivity Clarification).

Aclarándonos, lo que va antes de la @ es sensible a mayúsculas (aunque no se recomienda su uso para evitar problemas de interoperatibilidad) y lo que va después no es sensible a mayúsculas.

Aquí llega el primer problema, que es el de las colisiones si normalizo todas las direcciones de correo electrónico a minúsculas antes de insertarlas en la base de datos o antes de hacer las comparaciones (usuario existente en el proceso de registro, proceso de autentificación,…).

Un ejemplo claro es qué pasa si un usuario PePe@example.com se registra en mi sistema web y el servidor de correo electrónico de “example.com” tiene otro usuario cuya dirección de correo electrónico es pepe@example.com. Si este servidor de correo es sensible a mayúsculas la confirmación de la inscripción en el sitio web o la recuperación de la contraseña tendría que ser enviada al usuario PePe@example.com, pero llegaría a otro buzón de entrada, al del usuario pepe@example.com, con el consiguiente problema de seguridad que acarrea. Este tipo de problemas se pueden atacar de varias formas en el sistema web, como podría ser guardar el nombre de usuario en el formato original (PePe@example.com) y hacer que las comprobaciones no sean sensibles a mayúsculas. Pero nos encontraríamos con otro problema, ya que aunque el sistema podría registrar a los dos usuarios (PePe@example.com y pepe@example.com), ¿qué hago en el proceso de autentificación o de recuperación de la contraseña? ¿A quién le envío el token de recuperación de la contraseña?

Otro ejemplo problemático sería ¿qué hacer si tengo un sistema sensible a mayúsculas, el usuario se registra con la dirección PePe@example.com (por equivocación), recibe el correo electrónico de confirmación de la inscripción en la dirección pepe@example.com (sistema de correo no sensible a mayúsculas, que hay unos cuantos, como mostraré posteriormente) y al tratar de acceder posteriormente con el usuario pepe@example.com se le indica que el usuario no existe, ni es posible que recupere su contraseña.

Los casos problemáticos son unos cuantos si nos paramos a analizarlos, con la reducción de usabilidad del sistema, y, consecuentemente, con la frustración por parte del usuario en el uso de la aplicación web, que puede llevar a su abandono.

Usuario

Vistos algunos de los problemas que pueden plantearse cuando tratamos de ceñirnos a los RFC, ahora enfoco el problema desde el punto de vista del usuario final, del que va a registrarse y a utilizar nuestro sistema web. Deberíamos buscar un sistema usable, que no le haga pensar este tipo de cuestiones al usuario ni en el registro, ni en la autentificación ni en el proceso de recuperación de la contraseña. Que le pida una dirección de correo electrónico, una contraseña (por duplicado o no), que le pida (o no) confirmación del registro y…. listo.

Analizado el problema desde este punto de vista, tendríamos que tratar como el mismo usuario y la misma dirección de correo electrónico a PePe@example.com, a pepe@example.com, a PEPE@EXAMPLE.COM y a PEPE@example.com. Lo más cómodo para el desarrollador será realizar una conversión a minúsculas en la dirección de correo electrónico antes de utilizarla para cualquier tipo de procesado o almacenamiento.

El único problema es que si el servidor de correo electrónico de la organización “example.com” es sensible a mayúsculas y en mi sistema trata de registrarse PePe@example.com, el correo de confirmación nunca le llegará a él, sino a la cuenta pepe@example.com, en el caso de que exista.

Los “big players”

En estos momentos los tres principales proveedores de cuentas de correo gratuitas (Gmail, Yahoo y Hotmail), y quizás las más utilizadas por los usuarios en su ámbito personal no son sensibles a mayúsculas. No busqué ningún documento para comprobarlo. Simplemente envié un correo electrónico a mis direcciones en los tres servicios, pero cambiando el nombre de usuario, que en todos los casos está en minúsculas, por otro en el que intercalaba una letra mayúscula y una minúscula. Los correos llegaron de forma casi instantánea.

Conclusiones

Lo primero sería plantearse si es lo correcto utilizar una dirección de correo electrónico como usuario en el portal. Los portales web que utilizan un nombre de usuario único pueden mantener la dirección de correo electrónico original, sensible a mayúsculas, en su base de datos, de tal forma que se utiliza el usuario para el proceso de autentificación y el correo electrónico para la confirmación de la inscripción y para la recuperación de la contraseña. Ya serán los servidores de correo electrónico los que se encarguen de gestionar la problemática con cómo esté escrita la dirección de correo electrónico que el usuario utilizó al registrarse. Los principales portales (Facebook, Twitter,…) no están utilizando este formato ni es la tendencia actual.

Descartado este sistema, si queremos ser estrictos y cumplir a rajatabla los estándares de Internet, sin lugar a dudas hay que desarrollar un sistema sensible a mayúsculas.

Pero viendo cómo operan los grandes proveedores de correo electrónico, analizando qué es lo más usable y adecuado para el usuario final (que será el que dictamine el éxito o fracaso del sistema web) y viendo que ni en el RFC 2821 (el de SMTP) lo recomiendan (exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.) , si yo tuviera que desarrollar un sistema en el que el nombre de usuario fuera una dirección de correo electrónico, no lo haría sensible a mayúsculas. Trabajaría en todos los casos con un sistema en minúsculas, sabiendo de antemano que ni estaría cumpliendo los estándares RFC (pero sí los “de facto”) y que un mínimo número de usuarios puede que tengan problemas en el registro en mi sistema web.