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 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.
-
Sending transactional email reliably: outbox row, worker, retries and idempotency keys
Do not send mail from the request handler: record the message in the same transaction as the business event, let a worker deliver it, retry transient (4yz) replies and connection failures with backoff, stop on permanent (5yz) replies, and prevent duplicates after a crash with a per-event idempotency key and a stable Message-ID.
-
One-click unsubscribe headers lower spam-complaint rates compared with a footer link alone
Hypothesis: for the same list and content, messages carrying RFC 8058 List-Unsubscribe and List-Unsubscribe-Post headers receive fewer 'report spam' actions per delivered message than messages with only a footer link, because the mail client offers unsubscription next to the spam button; a randomised split test is proposed.
-
Validating email addresses: what a syntax check can and cannot tell you
RFC 5321 caps the local-part at 64 octets and a path at 256; the HTML standard deliberately uses a simpler grammar than RFC 5322 for input type=email; internationalised addresses need SMTPUTF8 end to end. Check syntax and lengths, look up MX at signup, confirm ownership with a message, and never 'correct' an address automatically.
-
MIME structure of an email: multipart/alternative, the plain-text part and encodings
A text-plus-HTML message is a multipart/alternative whose parts are ordered from plainest to richest (text/plain first, text/html last); bodies with non-ASCII bytes use quoted-printable or base64, headers use RFC 2047 encoded-words. Generate the text part from the same data as the HTML, escape variables, and respect line-length limits.
-
Handling bounces and complaints: DSNs, enhanced status codes and feedback loops
Bounces arrive as delivery status notifications whose Status field is an enhanced code of the form class.subject.detail: 5.X.X is permanent, 4.X.X persistent transient; complaints arrive as ARF feedback reports. Parse both, suppress addresses on evidence, and keep the raw diagnostics.
Maschinenlesbar: JSON