E-Mail, die ankommt
Eine Willkommensnachricht, einmal beim ersten Gebrauch eines Kontos, und ein Hinweis an jemanden, mit dem ein Dokument geteilt wurde. Beides brauchte drei Anläufe: Der Hinweis hing an einem Endpunkt, den die Anwendung nie aufruft, ging danach erst nach der Antwort hinaus, sodass die Anfrage die Funktion nie verließ, und scheiterte schließlich an einem Schlüssel, der in den ersten Builds tatsächlich fehlte. Für die Zustellbarkeit fehlte DMARC, nicht SPF und DKIM.
Post von einem Produkt ist meistens etwas, dem man misstrauen sollte — also sei gesagt, wie wenig davon es hier gibt. Zwei Nachrichten: ein Willkommen, wenn ein Konto zum ersten Mal wirklich benutzt wird, und ein Hinweis an jemanden, mit dem ein Konto ein Dokument geteilt hat. Keine Zusammenfassungen, keine Produktneuigkeiten, keine Liste, von der Sie sich abmelden müssten.
Warum sie nicht ankamen
Drei Fehler, einer nach dem anderen. Der Hinweis hing zuerst an einem Endpunkt, den die Anwendung nie aufruft. Dann wurde er abgeschickt, nachdem die Antwort schon hinaus war — das Naheliegende, wenn man es schreibt, und in einer serverlosen Funktion das Falsche: Die Plattform darf die Instanz in dem Moment einfrieren, in dem die Antwort geht, und eine Anfrage, die noch nicht draußen war, geht nie mehr hinaus. Auf einer laufenden Bereitstellung wurden drei Adressen hinzugefügt, und der Mail-Dienst hat gar nichts protokolliert: kein Fehlschlag, eine Abwesenheit.
Ein Versand gehört deshalb jetzt zu der Anfrage, die ihn ausgelöst hat, und wird abgewartet — mit vier Sekunden Zeitgrenze, damit ein Dienst mit einer schlechten Minute aus dem Teilen kein langsames Teilen macht. Der dritte Fehler war nüchterner als die beiden anderen: Der Schlüssel fehlte in den ersten Builds wirklich.
Warum sie im Spam landeten
SPF und DKIM waren von Anfang an eingerichtet und nie das Problem. Was fehlte, war DMARC — der DNS-Eintrag, der sagt, was ein Empfänger mit Post tun soll, die an den beiden anderen scheitert. Eine junge Domain, die ohne ihn automatische Post verschickt, wird streng behandelt. Das ist DNS und nicht Code, was erklärt, warum es dauerte.
Was der Code tun kann, ist, es nicht schlimmer zu machen: beide MIME-Teile statt nur Text, denn eine reine Textnachricht von einer Domain ohne Versandgeschichte ist genau das, was ein Filter am wenigsten mag. Eine Betreffzeile, die mit dem Namen des Dokuments beginnt statt mit einer nackten Adresse neben einem Dateinamen in Anführungszeichen — ein Paar, dessen Form Filter kennen. Und ein Reply-To auf die Person, die geteilt hat, denn eine Nachricht, die man nicht beantworten kann, liest sich wie Maschinerie.
Was diese Nachrichten nicht sind
Keine Bilder und kein Zählpixel; der HTML-Teil sind dieselben Worte wie der Textteil, gesetzt vom Konverter des Produkts selbst. Der Name eines Dokuments steht in einer Code-Spanne, damit eine Datei namens [Confirm your account](https://elsewhere.example) als Text ankommt und nicht als klickbarer Link in einer Nachricht, die unsere Signatur trägt. Eine Bereitstellung ohne Schlüssel verschickt nichts und sagt nichts, und ein Teilen, das geklappt hat, wird nie als gescheitert gemeldet, weil die Post es nicht tat. Alles davon ist englisch: Es geht an eine Adresse, über die wir sonst nichts wissen.
Weiter: ein Dokument als Link teilen und ob ein Online-Konverter sicher ist.