List-Unsubscribe und One-Click-Unsubscribe-Header (RFC 2369 und RFC 8058)

Worum es geht

RFC 2369 definiert Header-Felder, die Listen-Software hinzufügt, damit Mail-Clients Listenaktionen anbieten können, ohne den Body zu parsen: List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive, jeweils mit einer oder mehreren URIs, meist mailto: und optional HTTP. RFC 8058 ergänzt One-Click-Unsubscribe: Die Nachricht trägt List-Unsubscribe mit einer HTTPS-URI und List-Unsubscribe-Post mit dem einzigen Wert List-Unsubscribe=One-Click. Ein Empfänger meldet sich ab, indem er ein HTTPS-POST mit diesem Schlüssel-Wert-Paar als Body an diese URI sendet. Der RFC verlangt, dass die URI Empfänger und Liste allein identifiziert (es gibt keine zusätzlichen POST-Argumente), verlangt eine gültige DKIM-Signatur, die beide Header abdeckt, und untersagt, das POST mit einer Weiterleitung zu beantworten. Googles Absenderrichtlinien verlangen, dass Marketing- und abonnierte Nachrichten von Massenversendern (mehr als 5000 Nachrichten pro Tag) One-Click-Unsubscribe unterstützen und zusätzlich einen deutlich sichtbaren Abmeldelink im Body enthalten.

Warum es wichtig ist

Empfängerinnen, die keine Abmeldemöglichkeit finden, drücken stattdessen "als Spam melden", und Beschwerden sind es, was einen Absender in Filter geraten lässt. Eine header-basierte Steuerung lässt den Client die Abmeldung direkt neben der Nachricht anbieten und den Empfänger sie im Hintergrund verarbeiten. Für Massenversender ist das inzwischen eine Zulassungsvoraussetzung, keine Kulanz.

So wird es angewendet

• Beide Header bei jeder Marketing- oder Abonnement-Nachricht ausgeben; transaktionale Mails (Quittungen, Passwort-Rücksetzungen) ohne sie lassen, da es dort nichts abzubestellen gibt.
• Ein opakes Token in die URI legen, das auf (Empfänger, Liste) abbildet; auf dem POST-Pfad weder Login noch Bestätigungsseite noch zusätzliche Formularfelder verlangen.
• Das POST direkt mit einem Erfolgsstatus beantworten, nie mit einer Weiterleitung, und idempotent verarbeiten; dieselbe URI kann für Personen, die den Link anklicken, per GET eine menschenlesbare Seite ausliefern.
• Beide Header in den DKIM-h=-Tag aufnehmen und die Signatur an einer Nachricht prüfen, die die gesamte Versandpipeline durchlaufen hat; der RFC sagt, Empfänger sollten One-Click ohne dies nicht anbieten.
• Eine mailto:-Alternative in List-Unsubscribe beibehalten, was RFC 2369 für Clients ohne HTTP empfiehlt.
• Abmeldungen mit ihrer Quelle protokollieren (Header-POST, Seite, Antwort) und den Versand sofort einstellen; eine verspätete "letzte" Nachricht nach dem Opt-out ist eine Beschwerde, die nur auf sich warten lässt.

Stolpersteine

Ein Endpunkt, der nur GET beherrscht (Clients senden POST). Weiterleiten des POST auf eine Login- oder Präferenzseite. Tokens, die ablaufen, bevor ein Newsletter gelesen wird. Die Anfrage als Vorschlag behandeln und "wichtige Updates" weiterhin senden. Die Header nach der DKIM-Signierung hinzufügen, was die Signatur ungültig macht oder sie ungedeckt lässt.