Reflexiones en voz alta sobre el email de segunda generación

Nota: Este texto solo pone en orden mis ideas. No es algo que haya pensado a fondo, y no hace falta asumir que sea una buena idea. Conviene leerlo con las expectativas lo más bajas posible.

Problemas del email

• Muchas tecnologías antiguas siguen en uso, pero el email me irrita cada vez que lo uso.
• Desde la perspectiva del usuario, el email funciona bastante bien. A veces llega demasiada basura por spam, pero el email es antiguo, confiable, fácil de entender y relativamente fácil de buscar.
• Sin embargo, el backend del email es un desastre.

Problemas del backend del email

• Muchas funciones del email no tienen una especificación clara. Por ejemplo, al responder, no está claro si la respuesta debe ir arriba del mensaje o al final.
• No está claro qué tipo de HTML se puede incluir en un email. A veces Microsoft Outlook abusa del renderizador HTML de Microsoft Word.
• Tampoco está claro cómo cifrar el email. Se inventó algo llamado OpenPGP, pero casi no se usó y tiene fallas importantes.
• Nunca se pudo verificar siempre la autenticidad del email. Por eso se inventó SPF, pero SPF tampoco resolvió todos los problemas. Entonces se inventó DKIM, pero DKIM tampoco los resolvió todos. Después se inventó DMARC, pero como DKIM tiene fallas graves, DMARC también puede eludirse.
• Se agregó otra capa llamada BIMI, que también depende de DMARC, y DMARC depende de DKIM, y DKIM tiene fallas.
• Incluso cuando existe DMARC, el 68.2% de los registros están configurados con p=none. Eso significa que, en la práctica, DMARC no hace nada por defecto.
• Todo lo anterior, sumado a políticas agresivas contra el spam, hace que el email autoalojado sea muy difícil.
• Por último, está la gestión de reputación de IP. Algunas direcciones IP son más "limpias" que otras, sobre todo en sistemas compartidos como SendGrid o AWS SES. Eso complica registrar cuentas de correo masivo y muchas veces hace que emails legítimos terminen marcados como spam.

Hipótesis sobre el email de segunda generación

• Crear un nuevo registro DNS MX2. La mayoría de los servicios de email tendrían registros MX2 y MX. Los servicios antiguos solo tendrían MX.
• Si un cliente de email viejo de hace 20 años intenta enviar un mensaje, buscará el registro MX y enviará el mensaje. Los clientes modernos verán MX2 y enviarán el mensaje allí.
• Los servicios de email que implementen MX2 publicarán una fecha pública, y después de esa fecha clasificarán automáticamente como spam todos los mensajes enviados al registro MX.

Prioridades del email de segunda generación

1. Proveer una especificación HTML estandarizada para email y una suite de pruebas de conformidad.
2. Proveer encabezados para preferencias de hilos de email u otras preferencias relacionadas con el email.
3. Proveer una copia de solo texto sin HTML junto con la vista HTML.
4. Todos los registros MX2 deben incluir una clave pública.
5. Generar un hash para verificar la autenticidad e integridad del email, cifrarlo y agregarlo al encabezado.
6. Eliminar SPF, DKIM y DMARC, y estandarizar todo en un solo registro MX2 para simplificar el stack de email autoalojado.
7. Autenticar el email por dominio y no por dirección IP.
8. Los clientes que implementen MX2 podrían elegir un nuevo esquema de cifrado que reemplace a OpenPGP.

Pensamientos adicionales

• Hace falta una forma de compartir archivos grandes.
• Si Google y Microsoft no participan, MX2 nunca se hará realidad.
• También podría considerarse reemplazar SMTP por HTTP con una API REST estandarizada y cuerpos JSON.
• El simple hecho de usar HTML puede ser polémico. El email no fue diseñado originalmente para HTML.
• Existe una oportunidad para hacer cumplir estrictamente el nuevo estándar.

Opinión de GN⁺

• El intento de resolver la complejidad y los problemas de seguridad del sistema de email es muy interesante. En particular, proponer un nuevo método para garantizar la autenticidad e integridad del email podría ser útil.
• Sin embargo, introducir un nuevo estándar es extremadamente difícil. En especial, la participación de actores principales como Google y Microsoft es indispensable.
• La controversia sobre el uso de HTML sigue existiendo. Puede ser necesario considerar otro lenguaje de marcado para resolver los problemas de seguridad.
• Hacer cumplir estrictamente un nuevo estándar sería ideal, pero en la práctica puede ser difícil. Harían falta mecanismos adicionales para evitar la deriva del estándar y los errores de implementación.
• La centralización del sistema de email podría ayudar a introducir un nuevo estándar, pero al mismo tiempo podría aumentar la dependencia de ciertas empresas.

[cometkim]

Al menos en lo relacionado con mejorar el renderizado, Google y Microsoft ya han invertido... después de todo, ambos participaron y dieron soporte al proyecto AMP Email.

[coremaker]

Crear estándares de datos como JSON está bien,
pero como también habría que discutir en conjunto la especificación de renderizado, no parece algo sencillo.

¿No será que la razón por la que se eligió HTML
fue también para aprovecharse de la especificación de renderizado de HTML+CSS?

[ldmsys]

Como ya mencionaron arriba el caso extremo de Shop Mail, personalmente soy bastante escéptico con clasificar abiertamente como deprecated un protocolo que ya funciona bien y hacer compatible solo un estándar de protocolo nuevo cualquiera que no sea compatible.

[unsure4000]

4. Todos los registros MX2 deben incluir una clave pública.
   Esto me parece un poco extraño, porque da la impresión de que los proveedores de servicio usarían como clave pública no la que envió el usuario, sino una que ellos mismos generaron...

[iolothebard]

Así que hicimos un correo insertado… (¿eh? No, no era eso…)

[xguru]

El sistema de correo electrónico es cómodo y está bien, pero realmente da la impresión de que se necesitan mejoras graduales en el protocolo.
Seguir usándolo de esta manera dentro de varias décadas es un poco...

[GN⁺]

Comentarios de Hacker News

Resumen de comentarios de Hacker News

• La complejidad e interoperabilidad del sistema de correo electrónico

  • Con base en la experiencia operando servicios de correo en internet, el sistema de email es complejo, pero está adoptado de forma universal y tiene una gran interoperabilidad.
  • Introducir un sistema nuevo implica la dificultad de competir contra la enorme inversión en I+D del sistema existente.
  • Si se quiere proponer un nuevo sistema de email, conviene hacerlo en espacios como la IETF o M3AAWG.

• La ambigüedad y los problemas del email

  • Los encabezados del email pueden generar confusión cuando tienen valores duplicados o contradictorios.
  • Existen diversos problemas, como cuando se incluyen valores de 8 bits en encabezados que deberían usar solo ASCII.
  • La forma de manejar los hilos de correo tampoco está estandarizada, y eso también causa problemas.

• El problema de la centralización del email

  • La centralización del email no es deseable. Las empresas tienen muchas probabilidades de actuar en función de lo que les conviene a ellas, no de lo que es mejor para la humanidad.
  • Alojar tu propio correo no es difícil, y también es fácil hospedarlo mediante un proveedor confiable.

• Los problemas del email en HTML

  • El correo en HTML puede provocar problemas como phishing y fraudes.
  • Si se rediseñara el email, hay quienes opinan que sería mejor excluir HTML y usar un formato como Markdown.

• La necesidad de mantener la asincronía del email

  • El email debe seguir siendo asíncrono, porque es la última línea de defensa técnica para evitar trabajar 24 horas al día.
  • Esa es una de las razones por las que la gente no adopta sistemas supuestamente mejores.

• La dificultad de operar servidores de email

  • Operar un servidor de correo se está volviendo cada vez más difícil, porque hay que cumplir con los requisitos de los grandes proveedores.
  • Los servidores pequeños están siendo desplazados por los grandes proveedores o por los spammers.

• La definición de email legítimo

  • La definición de email legítimo es subjetiva. El spam está arruinando internet, y hace falta alguna forma de imponer un costo para frenarlo.

• La necesidad de mejorar el sistema de email

  • Aunque se rediseñara el sistema de correo, lo deseable sería mejorarlo manteniendo el sistema actual.
  • Hace falta adoptar sistemas modernos de cifrado y mecanismos de autenticación del remitente.

• Checklist de ideas anti-spam

  • Se necesitan algunos ajustes de implementación para prevenir el spam.
  • Los reenviadores de correo y los servidores SMTP deberían reenviar lo antes posible, y el filtrado anti-spam debería rechazarse a nivel SMTP.

Checklist de por qué tu idea anti-spam no va a funcionar