Programación en torno a mayúsculas y minúsculas de direcciones de correo electrónico

Al igual que muchos sitios web, utilizamos direcciones de correo electrónico como identificadores de usuario para los inicios de sesión.

RFC 5321 [ # 2.3.11 ] establece que las partes locales de las direcciones de correo electrónico:

DEBE ser interpretada y asignada semántica solo por el host especificado en la parte del dominio de la dirección

Esto significa que las aplicaciones que procesan direcciones de correo electrónico no pueden adivinar, por ejemplo, la forma en que GMail ignorará los puntos al determinar los nombres de usuario . También significa que las aplicaciones deben tratar las partes locales de la dirección de correo electrónico como mayúsculas y minúsculas, ya que así es como se especifica la parte local .

Sin embargo, los usuarios son estúpidos y, en un caso reciente, un usuario que se había registrado con una dirección de correo electrónico en mayúscula (y que había recibido e hizo clic con éxito en el correo electrónico de verificación) descubrió que no podían iniciar sesión porque ahora estaban usando el formato en minúscula de su correo electrónico habla a.

Nunca me he encontrado con un servidor de correo electrónico que aplicara mayúsculas y minúsculas en sus bandejas de entrada. No dudo que algunos existan en algún lugar, pero estoy cuestionando si no hay un beneficio mayor al eliminar la distinción entre mayúsculas y minúsculas para nuestros nombres de usuario de correo electrónico que si hay problemas para mantenerlo.

No iría tan lejos como para emular el procesamiento de puntos de GMail, o cualquier tipo de direccionamiento positivo , porque esos no parecen ser tan ubicuos o tan asumidos automáticamente como mayúsculas y minúsculas. Sin embargo, soy consciente de que no es un escenario en blanco y negro, así que me interesa si alguien sabe cuán extendidas son las direcciones de correo electrónico sensibles a mayúsculas y minúsculas.

http://tools.ietf.org/html/rfc5321#page-42 (énfasis agregado):

Si bien la definición anterior para Parte local es relativamente permisiva, para una interoperabilidad máxima, un host que espera recibir correo DEBE evitar definir buzones donde la parte Local requiere (o usa) el formulario de Cadena entre comillas o donde la parte Local es el caso -sensible.

El rfc desalienta la distinción entre mayúsculas y minúsculas. Además, personalmente nunca he visto un host con partes locales sensibles a mayúsculas y minúsculas.

Las direcciones de correo electrónico que no distinguen entre mayúsculas y minúsculas son un estándar de facto.

Por lo tanto, creo que tiene razón al decir que hay un mayor beneficio al eliminar la distinción entre mayúsculas y minúsculas para sus nombres de usuario de correo electrónico que los problemas para mantenerlo.

Párrafo 2.4. Principios generales de sintaxis y modelo de transacción de los estados RFC 5321 (énfasis mío):

Por lo tanto, las implementaciones de SMTP DEBEN tener cuidado de preservar el caso de las partes locales del buzón. En particular, para algunos hosts, el usuario "smith" es diferente del usuario "Smith". Sin embargo, explotar la sensibilidad a mayúsculas y minúsculas de las partes locales del buzón impide la interoperabilidad y se desaconseja. Los dominios de buzones siguen las reglas DNS normales y, por lo tanto, no distinguen entre mayúsculas y minúsculas.

AFAIK todos los servidores de correo populares evitan los correos electrónicos sensibles a mayúsculas y minúsculas, y usted también debería hacerlo. No he usado un servicio que suponía mayúsculas y minúsculas para los correos electrónicos, y odio que me sorprendan.

Lo que debe hacer es usar la dirección de correo electrónico que se proporciona para enviar correos electrónicos y transformarla en algo menos propenso a errores cuando se usa como identificador de cuenta o al menos usarla como reserva cuando no encuentra una coincidencia exacta.

Esto sería un análogo muy aproximado de lo que hace el algoritmo Soundex para palabras o nombres en inglés al eliminar las cosas que crean ambigüedades. Por ejemplo, puede convertir la dirección completa en minúsculas y eliminar subdirecciones y símbolos no alfanuméricos de la parte local (por ejemplo, Lance.Boyle+sometag@Example.comse despojaría a lanceboyle@example.com). Aplicar la misma transformación a cualquier dirección utilizada durante el inicio de sesión le daría una coincidencia para más variantes, y el usuario no es más sabio porque cualquier otro uso de la dirección sería la versión proporcionada.

Desde un punto de vista técnico, esto hace que sus inicios de sesión sean marginalmente más fáciles de aplicar fuerza bruta. Si eso es una preocupación, siempre puede solicitar una coincidencia exacta para los inicios de sesión y proporcionar una opción de "Olvidé mi nombre de usuario o contraseña" que es tolerante al buscar la cuenta, ya que cualquier correo electrónico que envíe será a la dirección "correcta".

Si una dirección como la anterior se completa a través del registro y la verificación, no creo que sea irrazonable rechazar a otros que se transforman de la misma manera que los duplicados. Me postulo que cualquier sitio que asigna direcciones locales como Lance.Boyle, LanceBoyle, lance.boyley lanceboyley trata como diferentes podrían ser el origen de otros tipos de problemas.