Wichtiger europäischer Zahlungsabwickler kann Google-Workspace-Nutzern keine E-Mails senden

• Der große europäische Zahlungsdienstleister Viva.com verschickte Verifizierungs-E-Mails ohne Message-ID-Header, wodurch Google-Workspace-Server sie ablehnten
• In RFC 5322 (verabschiedet 2008) ist Message-ID als Header auf Pflichtniveau definiert, und Google setzt dies strikt durch
• An persönliche Gmail-Adressen wurden die E-Mails zugestellt, was den Unterschied in der Verarbeitung zwischen Google Workspace und Gmail zeigt
• Der Viva.com-Kundensupport erkannte das technische Problem nicht an und zeigte eine unprofessionelle Reaktion, indem nur das vom Nutzer erreichte Workaround-Ergebnis bestätigt wurde
• Als Fall, in dem nicht einmal grundlegende RFC-Konformität eingehalten wurde, zeigt dies Probleme bei Qualität und Wettbewerbsfähigkeit der europäischen Fintech-Infrastruktur auf

---

Problem nicht zugestellter Verifizierungs-E-Mails

• Während der Erstellung eines Viva.com-Kontos traf die Verifizierungs-E-Mail überhaupt nicht ein
  • Verwendet wurde eine E-Mail-Adresse mit eigener Domain auf Basis von Google Workspace, und auch im Spam-Ordner war keine Nachricht zu finden
• In der Email Log Search von Google Workspace wurde der Status als „Bounced“ angezeigt
  • Als Grund für die Rückweisung wurde „Messages missing a valid Message-ID header are not accepted“ angegeben
  • Google lehnte die E-Mail wegen eines Verstoßes gegen RFC 5322 ab
• In den von Viva.com versendeten E-Mails fehlte der Message-ID-Header, obwohl dieser seit 2008 verpflichtend gefordert wird

Vorläufige Lösung

• Nach dem Wechsel auf eine persönliche @gmail.com-Adresse wurde die Verifizierungs-E-Mail normal zugestellt
  • Offenbar ist die Gmail-Empfangsinfrastruktur toleranter oder verarbeitet die Zustellung auf einem anderen Weg
• Allerdings wurde kritisiert, dass für die Registrierung bei einer geschäftlich genutzten Zahlungsplattform eine private E-Mail-Adresse verwendet werden musste

Reaktion des Kundensupports

• Dem Viva.com-Kundensupport wurden ein Screenshot der Google-Workspace-Logs und eine Problembeschreibung übermittelt
• Das Support-Team antwortete: „Ihr Konto hat bereits eine verifizierte E-Mail-Adresse, daher gibt es kein Problem“
  • Es gab weder ein Verständnis für das technische Problem noch eine Weitergabe an das Engineering-Team
  • Die Reaktion behandelte das vom Nutzer selbst erreichte Umgehungsergebnis so, als gäbe es kein Problem

Kern des Problems

• Message-ID ist ein grundlegender Header, den praktisch jedes E-Mail-System standardmäßig erzeugt
  • Wenn er fehlt, ist die Mail-Pipeline in der Regel gravierend falsch konfiguriert
• RFC 5322 definiert Message-ID als „SHOULD“, Google behandelt ihn jedoch faktisch als Pflicht (MUST)
• Weil Viva.com dies nicht einhielt, erreichten die E-Mails Nutzer von Google Workspace nicht
• Dass ein Unternehmen, das europaweit Zahlungen abwickelt, grundlegende RFC-Standards nicht einhält, wirft Fragen zur technischen Zuverlässigkeit auf

Strukturelle Probleme der europäischen Fintech-Infrastruktur

• Bei europäischen Unternehmens-APIs und -Services treten wiederholt unvollständige Dokumentation, unzureichende Fehlerbehandlung und unprofessioneller Support auf
• Dies wird nicht als Problem der Fähigkeiten einzelner Engineers gesehen, sondern als Mangel an Marktwettbewerb und falsche Prioritätensetzung
• Stripe hat einen hohen Standard für die Developer Experience gesetzt, unterstützt jedoch europäische Zahlungsnetze (z. B. IRIS) nicht vollständig, wodurch es an Alternativen mangelt
• Solange kein Wettbewerber auf dem Niveau von Stripe auftaucht, dürften solche Qualitätsprobleme weiter bestehen

Vorschlag zur technischen Behebung

• Viva.com sollte in ausgehenden E-Mails den Message-ID-Header ergänzen
  • Beispiel: Message-ID: <[e-mail]>
  • Die meisten E-Mail-Bibliotheken erzeugen diesen automatisch, und das Problem lässt sich mit einer einzigen Zeile beheben
• Eine sofortige Korrektur ist nötig, damit Nutzer von Google Workspace Verifizierungs-E-Mails wieder regulär empfangen können

Unterscheidung der RFC-Begriffe und Googles Richtlinie

• Laut RFC 2119 gilt
  • MUST: absolute Anforderung
  • SHOULD: darf nur aus besonderen Gründen weggelassen werden
  • MAY: vollständig optional
• Dass Message-ID als SHOULD klassifiziert ist, liegt daran, dass manche Clients dies an den Server delegieren
• Google setzt dies zur Spam-Abwehr als verbindliche Anforderung durch und fungiert damit praktisch als realer Standard über den RFC hinaus
• Falls Viva.com dies absichtlich weggelassen hat, sollte zumindest ein Hinweis wie „nicht mit Google Workspace kompatibel“ angezeigt werden
  • Der Betrieb ohne jegliche Information widerspricht auch dem Sinn der SHOULD-Vorgabe

[GN⁺]

Hacker-News-Kommentare

• Es wurde kritisiert, dass die Bestätigungs-E-Mails von Viva.com keinen Message-ID-Header enthalten.
  Laut Abschnitt 3.6 von RFC 5322 heißt es zwar „every message SHOULD have a Message-ID field“, doch da SHOULD nicht MUST ist, wurde infrage gestellt, ob man das wirklich als „Anforderung“ sehen könne.

  • Es wird erklärt, dass SHOULD praktisch eine verbindliche Anforderung ist.
    Man sollte sich daran halten, sofern es keinen besonderen Grund dagegen gibt; bloß „weil es lästig ist“ gilt nicht als Ausnahme.
    Früher wurde es als SHOULD formuliert, weil Server automatisch eine Message-ID ergänzten, wenn eine MUA E-Mails ohne Message-ID verschickte.
    Das ist auch in RFC 6409 Abschnitt 8.3 festgehalten.
  • Laut RFC2119 bedeutet SHOULD, dass man es „in bestimmten Situationen ignorieren kann, die Folgen aber vollständig verstehen und sorgfältig abwägen muss“.
    Wie Google das interpretiert hat, sei unklar.
  • Ein Kommentator betont aus Sicht eines Postmasters bei einem Hosting-Unternehmen, dass eine Message-ID im realen Betrieb zwingend nötig sei.
    Bei Testmails vielleicht nicht, aber bei produktiven E-Mails führe ihr Fehlen etwa bei Spam-Filtern zu Problemen.
    Keine Message-ID sei meist ein Zeichen für ein schlampiges Custom-Versandsystem.
  • Eine Message-ID sei zwar nicht verpflichtend, aber es gebe auch Dienste wie Amazon SES, die bestehende Message-IDs überschreiben, was ebenfalls kritisiert wird.
  • Technisch könne man zwar ohne auskommen, aber um als normale E-Mail behandelt zu werden, ist sie faktisch unverzichtbar.
    Dass ein Zahlungsdienst das nicht einmal mit einem großen Maildienst wie Google Workspace getestet habe, sei besonders absurd.

• Ein ehemaliger Mitarbeiter eines ESP (Email Service Provider) sagt, dass die meiste Server-Software E-Mails ohne Message-ID zurückgewiesen habe.
  Sich Bounces von großen Empfängern wie Google einfach zu ignorieren, sei kaum vorstellbar.

  • In der Praxis sei es wichtiger, Nutzerprobleme zu verhindern, als Standards dogmatisch auszulegen.
    Selbst wenn das Gegenüber irrational handle, sei es besser, sich anzupassen, um Frust bei Nutzern zu vermeiden.
  • Wer an Google Workspace zustellen wolle, müsse eine Message-ID praktisch als MUST behandeln.
    Wenn man das nicht tun wolle, müsse man explizit angeben: „Kein Service für Google-Workspace-Nutzer“.
  • Die meisten Unternehmen interessierten sich aber nicht für solche technischen Details und hätten die Haltung: „Hauptsache, es läuft schnell irgendwie.“
    Sowohl Viva als auch Google seien so groß, dass sie sich um die Probleme einzelner Kunden nicht weiter kümmerten.
  • Es wird auch angemerkt, dass Google Workspace bei überwiegend europäischen Firmen womöglich keinen so großen Anteil habe.

• Es gab auch Beschwerden über Dienste, die den text/plain-Alternativteil von E-Mails völlig vermurksen.
  Manchmal fehle im Textteil der Link, oder es stehe nur nutzloser Inhalt wie „Dies ist eine Plain-Text-E-Mail“ darin.

  • Am nervigsten seien Plain-Text-Versionen, in denen in Benachrichtigungen nur ein „niedlicher Spruch“ auftauche.
    Jemand scherzt, E-Mail-Clients bräuchten eine KI-Funktion, die HTML zusammenfasst.
  • Ein Dienst habe im Plain-Text-Teil sogar Buchungsdaten anderer Kunden mitgeschickt (Fall Avis).
  • Jemand habe eine Implementierung gesehen, die HTML per Lynx-Browser in text/plain dumpt, und frage sich, ob das tatsächlich sinnvoll sei.
  • Es gebe auch Fälle, in denen HTML-Quelltext oder CSS einfach unverändert in text/plain landet.

• Manche Kommentare spotten über die technische Inkompetenz von Finanzinstituten.
  „Major European Payment Processor“ sei praktisch gleichbedeutend mit „Major European Incompetence Center“.

  • Ein anderer Nutzer meint, das klinge zwar überzogen, aber das Sicherheitsniveau bei Finanzinstituten sei tatsächlich oft erschreckend.
    So habe Harland Financial Systems etwa eine 2-Byte-XOR-Verschlüsselung verwendet und den Schlüssel zu Beginn der Verbindung im Klartext geschickt.
  • Ein weiterer Nutzer verweist auf Korruptionsfälle bei US-Finanzinstituten, etwa falsche Genehmigungen oder unbefugt eröffnete Konten, und fragt, ob es in Europa ähnlich sei.

• Ein Nutzer, der von Gmail zu Fastmail gewechselt ist, zeigt ein gewisses Verständnis für Googles strenge Spam-Filterung.
  Bei Fastmail bekomme er mehr Spam und Phishing.

  • Ein anderer meint, Message-ID sei bei automatisierten E-Mails de facto Branchenstandard, daher sei Googles Vorgehen nicht überzogen.
    Gerade Startups würden oft Standardvorlagen unverändert verwenden und dadurch wie Phishing wirken.
  • Es wird geraten, dass Fastmails Spam-Filter mit der Zeit lernt und besser wird.
  • Ein langjähriger Fastmail-Nutzer witzelt, dass gelegentlich Spam durchkomme, aber ausgerechnet LinkedIn-Mails als einzige immer durchrutschen.
  • Fastmail habe zwar phasenweise langsamere Reaktionen auf Spam-Wellen, insgesamt sei man aber zufrieden.

• Manche meinen: Laut RFC liegt Viva.com zwar falsch, aber auch Google verhalte sich unangemessen, wenn es E-Mails wegen eines SHOULD-Punkts ablehnt.
  Wenn Spam vermutet werde, sollte die Mail eher im Spam-Ordner landen statt komplett abgewiesen zu werden.

  • Es wird kritisiert, dass der Kundensupport das Problem nicht an die Technik weitergebe, sondern nur formelhafte Antworten wiederhole.
  • Aus interner Erfahrung berichtet jemand, Support-Mitarbeiter hätten oft Angst, ein Problem einzugestehen, weil das negative Folgen für ihre Leistungsbewertung haben könne.
  • Ein zynischer Kommentar meint, E-Mail-Standards funktionierten in der Praxis ohnehin nie perfekt und alle Regeln seien letztlich nur SHOULD.

• Besonders schwerwiegend sei, dass Viva.com das Problem beim Versand an Google Workspace offenbar gar nicht getestet habe.

  • Tatsächlich teste man nun quasi in Echtzeit über fehlgeschlagene Nutzeranmeldungen, heißt es sarkastisch.
    Vielleicht liege die Ursache auch an einer Änderung bei Google, aber das größere Problem sei das fehlende Monitoring.
  • Dagegen wird eingewandt, dass eben nicht jedes Unternehmen auf der Welt Google Workspace benutze.

• Es wird gefragt, wie lange Viva.com dieses Problem schon nicht bemerkt hat.
  Mit normaler Mail-Software wäre so etwas wohl kaum passiert; als mögliche Ursache wird eine Fehlkonfiguration genannt.
  SHOULD sei eben nicht MAY, und wer es nicht umsetze, müsse mit Problemen rechnen.
  Dass Google in der Fehlermeldung überhaupt die Ursache genannt habe, wird eher positiv bewertet.

• Message-ID stamme ursprünglich als Pflichtfeld aus Usenet
  und werde für Threading, Antworten und Archivierung von E-Mails benötigt.
  Fehle sie, wirke das wie ein Signal: „Ich will weder Antworten noch eine Aufzeichnung“, also verdächtiges Verhalten.

• Auf die Kritik an der Qualität europäischer Unternehmens-APIs im Ausgangspost heißt es,
  das sei kein regionales Problem, sondern ein weltweites Muster bei Startups und Finanzinstituten.
  Große Unternehmen betrachteten APIs oft als Nebengeschäft oder betrieben sie nur widerwillig, um regulatorische Vorgaben zu erfüllen.
  Firmen wie Stripe hätten dagegen hochwertige APIs, weil diese ihre Lebensader seien.
  Startups müssten wegen knapper Ressourcen oft eher eine „funktionierende API“ statt einer „gut benutzbaren API“ priorisieren.