Importante procesador de pagos europeo no puede enviar correos a usuarios de Google Workspace

• La gran empresa europea de pagos Viva.com enviaba correos de verificación sin el encabezado Message-ID, por lo que los servidores de Google Workspace los rechazaban
• En la RFC 5322 (publicada en 2008), Message-ID está definido como un encabezado de nivel obligatorio, y Google aplica esta regla de forma estricta
• Los correos sí llegaban a direcciones personales de Gmail, lo que dejó en evidencia la diferencia de tratamiento entre Google Workspace y Gmail
• El soporte de Viva.com no reconoció el problema técnico y solo confirmó que el usuario había logrado rodearlo, mostrando una respuesta poco profesional
• Este caso, en el que ni siquiera se cumple con lo básico de la RFC, pone en evidencia problemas de calidad y pérdida de competitividad en la infraestructura fintech europea

---

El problema de que no llegaba el correo de verificación

• Durante el proceso de creación de una cuenta en Viva.com, el correo de verificación no llegaba en absoluto
  • Se estaba usando un correo con dominio personalizado basado en Google Workspace, y tampoco había nada en la carpeta de spam
• En Email Log Search de Google Workspace, el estado aparecía como “Bounced”
  • El motivo del rebote era: “Messages missing a valid Message-ID header are not accepted”
  • Google rechazó el correo por incumplir la especificación RFC 5322
• En los correos enviados por Viva.com faltaba el encabezado Message-ID, un elemento exigido como obligatorio desde 2008

Solución temporal

• Al cambiar a una dirección personal de @gmail.com, el correo de verificación se recibió con normalidad
  • Parece que la infraestructura de recepción de Gmail es más permisiva o lo procesa por otra ruta
• Sin embargo, se señala como un problema que para registrarse en una plataforma de pagos empresarial haya sido necesario usar un correo personal

Respuesta del soporte

• Se enviaron al soporte de Viva.com capturas de pantalla de los logs de Google Workspace junto con la explicación del problema
• El equipo respondió que “su cuenta ya tiene un correo verificado, por lo que no hay ningún problema”
  • No hubo reconocimiento del problema técnico ni escalamiento al equipo de ingeniería
  • Consideraron que no había problema solo porque el usuario logró esquivarlo por su cuenta

La esencia del problema

• Message-ID es un encabezado básico que todos los sistemas de correo generan por defecto
  • Para que falte, la canalización de correo tendría que estar gravemente mal configurada
• En la RFC 5322, Message-ID está definido como “SHOULD”, pero Google lo trata en la práctica como obligatorio (MUST)
• Como Viva.com no cumple con esto, los correos no llegan a los usuarios de Google Workspace
• Que una empresa que procesa pagos en toda Europa no cumpla con una especificación RFC básica plantea dudas sobre su confiabilidad técnica

Problema estructural de la infraestructura fintech europea

• En APIs y servicios empresariales de Europa se repiten problemas como documentación incompleta, manejo deficiente de errores y soporte poco profesional
• Se señala que esto no se debe a la capacidad de los ingenieros, sino a falta de competencia en el mercado y prioridades equivocadas
• Stripe elevó el estándar de experiencia para desarrolladores, pero no da soporte completo a redes de pago europeas (por ejemplo, IRIS), por lo que faltan alternativas reales
• Mientras no aparezca un competidor al nivel de Stripe, es probable que este tipo de problemas de calidad continúen

Propuesta de corrección técnica

• Viva.com debe añadir el encabezado Message-ID a los correos salientes
  • Ejemplo: Message-ID: <[e-mail]>
  • La mayoría de las librerías de correo lo generan automáticamente y puede resolverse con un cambio de una sola línea
• Hace falta una corrección inmediata para que los usuarios de Google Workspace puedan recibir normalmente los correos de verificación

Diferencia entre términos RFC y la política de Google

• Según la RFC 2119
  • MUST: requisito absoluto
  • SHOULD: solo puede omitirse si hay una razón especial
  • MAY: completamente opcional
• Message-ID es SHOULD porque algunos clientes delegan eso al servidor
• Google lo aplica como un requisito obligatorio para prevenir spam, actuando en la práctica como un estándar más estricto que la propia RFC
• Si Viva.com lo omitió intencionalmente, como mínimo debería mostrar una advertencia de “no compatible con Google Workspace”
  • Operarlo sin ninguna advertencia también contradice el espíritu de la regla SHOULD

[GN⁺]

Comentarios en Hacker News

• Se señaló como problema que los correos de verificación de Viva.com no tienen encabezado Message-ID
  Según la sección 3.6 del RFC 5322, dice que “every message SHOULD have a Message-ID field”, pero como SHOULD no es MUST, se cuestiona si realmente puede considerarse un “requisito”

  • Se explica que SHOULD es, en la práctica, un requisito obligatorio
    Debe cumplirse salvo que exista una razón especial, y simplemente “da flojera” no puede ser una excepción
    En el pasado se redactó como SHOULD porque, si un MUA enviaba correo sin Message-ID, el servidor lo agregaba automáticamente
    Esto está especificado en la sección 8.3 del RFC 6409
  • Según el RFC 2119, SHOULD significa que “puede ignorarse en circunstancias particulares, pero solo si se entienden bien las consecuencias y se evalúa cuidadosamente”
    Dice que no sabe cómo interpretó esto Google
  • Como postmaster de una empresa de hosting, enfatiza que en entornos reales Message-ID es indispensable
    Tal vez en correos de prueba no importe, pero si falta en correos de producción surgen problemas, por ejemplo con el filtrado de spam
    Añade que la ausencia de Message-ID suele ser señal de un sistema de envío personalizado y mal hecho
  • Message-ID no es obligatorio, pero también se quejan de servicios como Amazon SES que sobrescriben el Message-ID existente
  • Técnicamente podría no estar, pero para que se clasifique como correo normal en la práctica es casi indispensable
    Sobre todo, les parece absurdo que un servicio de pagos ni siquiera haya probado esto con un proveedor de correo importante como Google Workspace

• Alguien que trabajó en un ESP (Email Service Provider) comenta que la mayoría del software de servidores rechazaba correos sin Message-ID
  Dice que es difícil imaginar ignorar un rebote (bounce) proveniente de un destinatario grande como Google

  • En la práctica, dice, es más importante evitar problemas al usuario que aferrarse al estándar
    Aunque el sistema del otro lado sea poco razonable, es mejor adaptarse para evitar molestias a los usuarios
  • Para enviar correo a Google Workspace, Message-ID es en la práctica un MUST
    Si no quieren incluirlo, entonces deberían indicar explícitamente “no damos servicio a usuarios de Google Workspace”
  • Pero la mayoría de las empresas no se interesa por esos detalles técnicos, y su actitud es más bien “que funcione rápido y ya”
    Opina que tanto Viva como Google son demasiado grandes como para preocuparse por los problemas de una parte de sus clientes
  • También señala que, al estar centrada en empresas europeas, quizá la proporción de usuarios de Google Workspace no sea tan alta

• También hubo quejas sobre servicios que envían fatal la parte alternativa text/plain del correo
  A veces mandan una versión de texto sin enlaces o solo contenido inútil como “este es un correo en texto plano”

  • Dicen que lo más irritante es cuando la versión en texto plano solo muestra una “frase cute” en la notificación
    Incluso bromean con que los clientes de correo deberían resumir el HTML con IA
  • Un servicio llegó a incluir en text/plain la información de reserva de otro cliente (caso Avis)
  • Alguien comenta que ha visto implementaciones que generan text/plain volcando el HTML con el navegador Lynx, y se pregunta si eso realmente aporta valor
  • También dicen haber visto casos en los que meten directamente el código HTML o CSS dentro de text/plain

• También hubo comentarios burlándose de la incompetencia técnica de las instituciones financieras
  “Major European Payment Processor” fue descrito en realidad como “Major European Incompetence Center”

  • Otro usuario dice que suena exagerado, pero que de hecho ha visto niveles de seguridad terribles en instituciones financieras
    Por ejemplo, Harland Financial Systems usaba cifrado XOR de 2 bytes y enviaba la clave en texto plano al inicio de la conexión
  • Otro usuario menciona casos de corrupción en instituciones financieras de EE. UU. (aprobaciones erróneas, apertura no autorizada de cuentas, etc.) y pregunta si en Europa ocurre algo similar

• Un usuario que se cambió de Gmail a Fastmail dice que hasta cierto punto entiende el filtrado estricto de spam de Google
  En Fastmail le entra más spam y phishing

  • Otro usuario dice que Message-ID es en la práctica un estándar de la industria para correos automáticos, así que la medida de Google no le parece excesiva
    También comenta que a veces startups usan plantillas básicas tal cual y terminan siendo confundidas con phishing
  • Recomiendan que en Fastmail el filtro de spam mejora con el tiempo a medida que aprende
  • Un usuario veterano de Fastmail bromea con que a veces se cuela spam, pero que solo los correos de LinkedIn siempre logran pasar
  • Otro comenta que Fastmail a veces se pone lento para responder al spam, pero que en general está satisfecho

• También hubo quien opinó que, aunque según el RFC Viva.com está mal, Google también actúa de forma inapropiada al rechazar correos por algo marcado como SHOULD
  Aun así, dicen que si la probabilidad de spam es alta, debería enviarse a la carpeta de spam y no rechazarse

  • Señalan la realidad de que el equipo de soporte al cliente no transmite el problema al equipo técnico y solo repite respuestas de trámite
  • También se compartió una experiencia interna: desde la perspectiva del personal de soporte, reconocer el problema puede perjudicar su evaluación de desempeño, así que terminan evitando hacerlo
  • También aparece una opinión cínica: en la práctica los estándares de correo no funcionan perfectamente y todas las reglas son, en los hechos, de nivel “SHOULD”

• Se critica como lo más grave que Viva.com ni siquiera haya probado el problema de envío de correo con Google Workspace

  • En la práctica, bromean, lo están “probando en tiempo real” a través de los fallos de registro de usuarios
    Añaden que el cambio podría haber sido del lado de Google, pero que la falta de monitoreo es un problema aún mayor
  • También hubo una réplica: “no todas las empresas del mundo usan Google Workspace, ¿no?”

• También se preguntan cuánto tiempo tardó Viva.com en darse cuenta de este problema
  Dicen que con software de correo normal esto no habría pasado, y mencionan la posibilidad de una mala configuración
  SHOULD no es MAY, y si no se implementa hay que asumir las consecuencias
  Consideran incluso afortunado que Google haya indicado la causa en el mensaje de error

• Se explica que Message-ID era originalmente un campo obligatorio heredado de Usenet,
  y que sigue siendo necesario para el threading, las respuestas y el archivado del correo
  Dicen que la ausencia de Message-ID da la impresión de “no quiero respuestas ni dejar registro”, lo cual se ve sospechoso

• Sobre el comentario original que criticaba la calidad de las API de empresas europeas,
  responden que no es un problema regional sino un patrón común en startups e instituciones financieras de todo el mundo
  Las empresas grandes suelen tratar la API como un negocio secundario o la operan a la fuerza por motivos regulatorios
  En cambio, compañías como Stripe tienen APIs de alta calidad porque son parte vital de su negocio
  Añaden que las startups, por falta de recursos, a menudo no pueden priorizar una “API agradable de usar” por encima de una “API que simplemente funcione”