Thema: email
-
Nach wie vielen Soft Bounces, über welchen Zeitraum, sollte ein Versender eine Adresse nicht mehr anschreiben?
Offene Frage: Erweiterte Statuscodes trennen dauerhafte Fehlschläge (5.X.X) von anhaltend vorübergehenden (4.X.X), doch der Standard überlässt den vorübergehenden Fall der Richtlinie des Versenders; welche Schwellenwerte haben Versender verwendet, und was geschah mit Erholungsraten und Reputation?
-
List-Unsubscribe und One-Click-Unsubscribe-Header (RFC 2369 und RFC 8058)
RFC-2369-Header lassen Mail-Clients Listenaktionen anbieten; RFC-8058-One-Click ergänzt eine List-Unsubscribe-HTTPS-URI plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, verarbeitet über ein HTTPS-POST ohne Weiterleitung und ohne weitere Schritte, wobei beide Header von DKIM abgedeckt sind. Massenversender sind gemäss den Google-Richtlinien verpflichtet, dies zu unterstützen.
-
iCalendar-Einladungen: UID, SEQUENCE und korrekte Zeitzonen
Ein iCalendar-Ereignis wird über UID identifiziert und über SEQUENCE überarbeitet; seine Zeiten sind UTC, lokale Zeit mit einer TZID, die auf eine eingebettete VTIMEZONE verweist, oder frei schwebend. Zonengebundene lokale Zeit für wiederkehrende Termine verwenden, UTC für einmalige zeitzonenübergreifende Ereignisse, und Aktualisierungen sowie Absagen mit der iTIP-METHOD senden, die der empfangende Client erwartet.
-
E-Mail-Authentifizierung: SPF, DKIM und DMARC
SPF listet die Server, die für eine Domain senden dürfen, DKIM signiert Nachrichten mit einem Domain-Schlüssel, DMARC teilt Empfängern mit, was zu tun ist, wenn beides fehlschlägt, und wohin Berichte gesendet werden; alle drei sind DNS-TXT-Einträge, die bestehen bleiben müssen, wenn andere Einträge geändert werden.
-
E-Mail-Authentifizierung mit SPF, DKIM und DMARC
SPF (RFC 7208) benennt die Server, die für eine Domain senden dürfen, DKIM (RFC 6376) signiert Nachrichten mit einem im DNS veröffentlichten Schlüssel, und DMARC (RFC 7489) legt fest, was Empfänger bei Fehlschlag tun und wohin sie berichten. Alle drei sind DNS-TXT-Einträge, die jede DNS-Änderung überleben müssen.
-
Transaktionale E-Mails zuverlässig versenden: Outbox-Zeile, Worker, Retries und Idempotenzschlüssel
E-Mails nicht aus dem Request-Handler heraus senden: die Nachricht in derselben Transaktion wie das Geschäftsereignis erfassen, sie von einem Worker zustellen lassen, bei vorübergehenden (4yz) Antworten und Verbindungsfehlern mit Backoff erneut versuchen, bei dauerhaften (5yz) Antworten abbrechen, und Duplikate nach einem Absturz mit einem ereignisbezogenen Idempotenzschlüssel und einer stabilen Message-ID verhindern.
-
One-Click-Abmelde-Header senken die Spam-Beschwerderate gegenüber einem reinen Fusszeilen-Link
Hypothese: Bei gleicher Liste und gleichem Inhalt erhalten Nachrichten mit den RFC-8058-Headern List-Unsubscribe und List-Unsubscribe-Post pro zugestellter Nachricht weniger „Als Spam melden“-Aktionen als Nachrichten mit nur einem Fusszeilen-Link, weil der Mail-Client die Abmeldung neben der Spam-Schaltfläche anbietet; ein randomisierter Split-Test wird vorgeschlagen.
-
E-Mail-Adressen validieren: was eine Syntaxprüfung zeigen kann und was nicht
RFC 5321 begrenzt den Local-Part auf 64 Oktette und einen Pfad auf 256; der HTML-Standard verwendet für input type=email bewusst eine einfachere Grammatik als RFC 5322; internationalisierte Adressen benötigen SMTPUTF8 durchgängig. Syntax und Längen prüfen, bei der Registrierung den MX-Eintrag nachschlagen, den Besitz per Nachricht bestätigen und eine Adresse nie automatisch "korrigieren".
-
MIME-Struktur einer E-Mail: multipart/alternative, der Klartextteil und Kodierungen
Eine Nachricht mit Text- und HTML-Teil ist ein multipart/alternative, dessen Teile vom einfachsten zum reichhaltigsten geordnet sind (text/plain zuerst, text/html zuletzt); Bodys mit Nicht-ASCII-Bytes verwenden quoted-printable oder base64, Header verwenden RFC-2047-Encoded-Words. Den Textteil aus denselben Daten wie das HTML erzeugen, Variablen escapen und Zeilenlängengrenzen einhalten.
-
Umgang mit Bounces und Beschwerden: DSNs, erweiterte Statuscodes und Feedback-Loops
Bounces treffen als Delivery Status Notifications ein, deren Status-Feld ein erweiterter Code der Form class.subject.detail ist: 5.X.X ist permanent, 4.X.X ist anhaltend vorübergehend; Beschwerden treffen als ARF-Feedback-Reports ein. Beide auswerten, Adressen anhand von Belegen sperren und die Rohdiagnosen aufbewahren.
Maschinenlesbar: JSON