Un grand prestataire européen de traitement des paiements incapable d’envoyer des e-mails aux utilisateurs de Google Workspace

• Le grand prestataire européen de paiements Viva.com a envoyé des e-mails de vérification sans en-tête Message-ID, ce qui a conduit les serveurs Google Workspace à les rejeter
• Dans la RFC 5322 (adoptée en 2008), Message-ID est défini comme un en-tête de niveau obligatoire, et Google applique cette exigence strictement
• Les e-mails ont bien été reçus sur une adresse Gmail personnelle, révélant une différence de traitement entre Google Workspace et Gmail
• Le support client de Viva.com n’a pas reconnu le problème technique et a seulement constaté que l’utilisateur avait trouvé un contournement, montrant une réponse peu professionnelle
• Cet échec à respecter ne serait-ce que les exigences de base d’une RFC met en lumière des problèmes de qualité et de compétitivité dans l’infrastructure fintech européenne

---

Problème d’e-mail de vérification non reçu

• Lors de la création d’un compte Viva.com, l’e-mail de vérification n’est jamais arrivé
  • Une adresse e-mail de domaine personnalisé basée sur Google Workspace était utilisée, et rien n’apparaissait non plus dans le dossier spam
• Dans Email Log Search de Google Workspace, l’état apparaissait comme « Bounced »
  • La raison du rejet était : « Messages missing a valid Message-ID header are not accepted »
  • Google a refusé le message pour non-conformité à la RFC 5322
• L’e-mail envoyé par Viva.com ne contenait pas d’en-tête Message-ID, alors qu’il s’agit d’un champ requis depuis 2008

Solution temporaire

• En remplaçant l’adresse par une adresse personnelle @gmail.com, l’e-mail de vérification a été reçu normalement
  • Il semble que l’infrastructure de réception de Gmail soit plus permissive ou traite ces messages via un autre chemin
• Mais le fait d’avoir dû utiliser une adresse personnelle pour s’inscrire à une plateforme de paiement destinée aux entreprises est pointé comme un problème

Réponse du support client

• Une capture d’écran des logs Google Workspace et une description du problème ont été envoyées au support client de Viva.com
• L’équipe de support a répondu : « Votre compte dispose déjà d’une adresse e-mail vérifiée, il n’y a donc pas de problème »
  • Il n’y a eu ni reconnaissance du problème technique, ni transmission à l’équipe d’ingénierie
  • Le fait que l’utilisateur ait lui-même contourné le problème a été considéré comme une preuve qu’il n’y avait pas de dysfonctionnement

Le fond du problème

• Message-ID est un en-tête de base que tous les systèmes de messagerie génèrent normalement par défaut
  • Son absence implique en général une configuration gravement défaillante de la chaîne d’envoi des e-mails
• Dans la RFC 5322, Message-ID est indiqué comme SHOULD, mais Google le traite de facto comme obligatoire (MUST)
• Comme Viva.com ne respecte pas cette exigence, les e-mails n’atteignent pas les utilisateurs de Google Workspace
• Qu’une entreprise qui traite des paiements à l’échelle européenne ne respecte pas une RFC aussi fondamentale soulève des doutes sur sa fiabilité technique

Problème structurel de l’infrastructure fintech européenne

• Dans les API et services B2B européens, on observe de manière répétée une documentation incomplète, une mauvaise gestion des erreurs et un support peu professionnel
• Le problème est attribué non pas au niveau des ingénieurs, mais au manque de concurrence sur le marché et à des priorités mal définies
• Stripe a fixé un standard élevé en matière d’expérience développeur, mais ne prend pas complètement en charge les réseaux de paiement européens (par ex. IRIS), ce qui laisse peu d’alternatives
• Tant qu’aucun concurrent du niveau de Stripe n’émergera, ce type de problème de qualité risque de persister

Proposition de correction technique

• Viva.com doit ajouter un en-tête Message-ID aux e-mails envoyés
  • Exemple : Message-ID: <[e-mail]>
  • La plupart des bibliothèques e-mail le génèrent automatiquement, et une simple ligne de correction peut suffire
• Une correction immédiate est nécessaire pour que les utilisateurs de Google Workspace puissent recevoir normalement leurs e-mails de vérification

Distinction des termes RFC et politique de Google

• Selon la RFC 2119
  • MUST : exigence absolue
  • SHOULD : ne peut être omis qu’en présence d’une raison particulière
  • MAY : option totalement facultative
• Si Message-ID est en SHOULD, c’est parce que certains clients délèguent cette responsabilité au serveur
• Google l’applique comme une exigence contraignante pour lutter contre le spam, jouant ainsi en pratique le rôle d’un standard plus fort que la RFC elle-même
• Si Viva.com a omis ce champ intentionnellement, il devrait au minimum afficher un avertissement du type « incompatible avec Google Workspace »
  • Faire fonctionner le service sans aucune indication va aussi à l’encontre de l’esprit même du niveau SHOULD

[GN⁺]

Réactions sur Hacker News

• Le principal problème relevé est que l’e-mail de vérification de Viva.com ne contient pas d’en-tête Message-ID
  Selon la section 3.6 de la RFC 5322, « every message SHOULD have a Message-ID field », mais comme SHOULD n’est pas MUST, certains se demandent s’il est vraiment juste de parler d’« exigence »

  • Il est expliqué que SHOULD constitue en pratique une exigence quasi obligatoire
    Il faut s’y conformer sauf raison particulière, et simplement dire « c’était pénible » ne peut pas être une exception
    Historiquement, c’était formulé en SHOULD parce que les serveurs ajoutaient automatiquement un Message-ID quand un MUA envoyait un mail sans cet en-tête
    C’est explicitement indiqué dans la section 8.3 de la RFC 6409
  • D’après la RFC 2119, SHOULD signifie qu’on peut l’ignorer dans certaines circonstances, mais qu’il faut bien comprendre les conséquences et décider avec prudence
    L’interprétation qu’en a faite Google reste inconnue
  • Un postmaster d’hébergeur souligne que, dans un environnement de production réel, le Message-ID est indispensable
    Peut-être pas pour des mails de test, mais l’absence de cet en-tête dans des e-mails de service réel pose des problèmes, notamment avec le filtrage anti-spam
    Un Message-ID absent est généralement le signe d’un système d’envoi personnalisé bricolé
  • Le Message-ID n’est pas obligatoire, mais certains se plaignent aussi de services comme Amazon SES qui écrasent le Message-ID existant
  • Techniquement, on peut s’en passer, mais pour être considéré comme un e-mail légitime, il est de fait indispensable
    Il est particulièrement aberrant qu’un service de paiement n’ait même pas testé l’envoi vers un grand service mail comme Google Workspace

• Une personne ayant travaillé chez un ESP (Email Service Provider) dit que la plupart des logiciels serveur rejetaient les mails sans Message-ID
  Elle juge difficilement concevable d’ignorer les bounces provenant d’un grand destinataire comme Google

  • En pratique, éviter les problèmes utilisateurs est plus important que le respect strict du standard
    Même si le système en face est irrationnel, mieux vaut s’y adapter pour éviter des désagréments aux utilisateurs
  • Pour envoyer des mails à Google Workspace, le Message-ID est en pratique un MUST
    Si on refuse de l’ajouter, il faudrait alors préciser clairement : « service indisponible pour les utilisateurs Google Workspace »
  • Mais la plupart des entreprises ne s’intéressent pas à ce type de détail technique et adoptent surtout une logique de « il faut juste que ça fonctionne vite »
    Viva comme Google sont jugés trop gros pour se soucier des problèmes d’une petite partie de leurs clients
  • Quelqu’un note aussi qu’avec une clientèle surtout européenne, la part de Google Workspace n’est peut-être pas si élevée

• Des critiques visent aussi les services qui envoient des parties alternatives text/plain complètement bâclées
  Certains expédient une version texte sans les liens, ou limitée à un contenu inutile du genre « ceci est un e-mail en texte brut »

  • La version text/plain qui n’affiche qu’une « petite phrase mignonne » dans la notification est jugée particulièrement agaçante
    Quelqu’un plaisante en disant qu’il faudrait une fonction où le client mail utiliserait l’IA pour résumer le HTML
  • Un service a même envoyé en text/plain les informations de réservation d’un autre client (cas d’Avis)
  • Une personne dit avoir vu une implémentation qui générait le text/plain en faisant un dump du HTML via le navigateur Lynx, et se demande si cela a une réelle utilité
  • D’autres ont déjà vu du HTML ou du CSS copiés tels quels dans la partie text/plain

• Certains commentaires se moquent de l’incompétence technique des institutions financières
  « Major European Payment Processor » y est reformulé en « Major European Incompetence Center »

  • Un autre utilisateur dit que la formule paraît exagérée, mais que dans la réalité, le niveau de sécurité de certaines institutions financières était effectivement catastrophique
    Il cite par exemple Harland Financial Systems, qui utilisait un chiffrement XOR sur 2 octets et envoyait la clé en clair au début de la connexion
  • Un autre évoque des cas de corruption dans la finance américaine, comme des validations erronées ou l’ouverture non autorisée de comptes, et demande si l’Europe connaît des dérives comparables

• Un utilisateur passé de Gmail à Fastmail dit comprendre en partie la rigueur du filtrage anti-spam de Google
  Selon lui, Fastmail laisse passer davantage de spam et de phishing

  • Une autre personne affirme que le Message-ID est de fait un standard de l’industrie pour les e-mails automatiques, et que la décision de Google n’est donc pas excessive
    Elle mentionne aussi des startups qui utilisent les modèles par défaut et finissent prises pour du phishing
  • Il est conseillé de laisser le temps au filtre anti-spam de Fastmail d’apprendre et de s’améliorer
  • Un utilisateur Fastmail de longue date plaisante en disant que du spam passe parfois, mais que seuls les e-mails de LinkedIn franchissent systématiquement le filtre
  • Fastmail est parfois jugé lent à réagir à certaines vagues de spam, mais le bilan global reste positif

• D’autres estiment que, même si Viva.com a tort au regard de la RFC, Google ne devrait pas rejeter un e-mail au motif d’un SHOULD
  Si le message semble suspect, il vaudrait mieux l’envoyer en spam plutôt que le refuser

  • Certains dénoncent le fait que le support client ne fasse pas remonter le problème à l’équipe technique et se contente de réponses de façade
  • Une personne ayant une expérience interne explique aussi que, côté support, reconnaître le problème peut nuire aux évaluations de performance, ce qui pousse à éviter de le faire
  • D’autres expriment un point de vue cynique selon lequel les standards e-mail ne fonctionnent jamais parfaitement en pratique, et que toutes les règles finissent par ressembler à des SHOULD

• Plusieurs soulignent que le plus grave est que Viva.com n’a même pas testé son envoi d’e-mails avec Google Workspace

  • Quelqu’un ironise en disant qu’en réalité ils font leurs « tests en temps réel » via les échecs d’inscription des utilisateurs
    Le problème pourrait venir d’un changement côté Google, mais l’absence de monitoring est jugée encore plus grave
  • D’autres rétorquent qu’après tout, tout le monde n’utilise pas Google Workspace

• Certains se demandent depuis combien de temps Viva.com n’a pas remarqué le problème
  Avec un logiciel de messagerie classique, cela ne serait probablement pas arrivé, ce qui fait penser à une mauvaise configuration
  SHOULD n’est pas MAY : si on choisit de ne pas l’implémenter, il faut en assumer les conséquences
  Le fait que Google ait indiqué la cause dans le message d’erreur est même vu comme un point positif

• Il est rappelé que le Message-ID est à l’origine un champ obligatoire hérité d’Usenet
  Il est nécessaire pour le threading, les réponses et l’archivage des e-mails
  L’absence de Message-ID donne l’impression que l’expéditeur ne veut « ni réponse ni trace », ce qui paraît suspect

• En réponse au reproche sur la mauvaise qualité des API d’entreprises européennes, certains disent que ce n’est pas un problème régional mais un schéma commun aux startups et institutions financières du monde entier
  Les grandes entreprises traitent souvent l’API comme une activité annexe, ou la maintiennent à contrecœur uniquement pour des raisons de conformité réglementaire
  À l’inverse, une société comme Stripe fournit une API de meilleure qualité parce que c’est au cœur de son activité
  Les startups, faute de ressources, n’ont souvent d’autre choix que de privilégier une API “qui marche” plutôt qu’une API “agréable à utiliser”