Umgang mit Bounces und Beschwerden: DSNs, erweiterte Statuscodes und Feedback-Loops

Ziel

Das Versenden an Adressen automatisch und rasch stoppen, die keine E-Mails empfangen können oder wollen, damit die Reputation des sendenden Systems und das Vertrauen der Empfangenden erhalten bleiben.

Voraussetzungen

Ein maschinell lesbarer Rückpfad (ein dediziertes Bounce-Postfach oder die Bounce-Ereignisse des Providers), eine Sperrtabelle, indiziert nach Adresse und Stream, sowie die beiden Berichtsformate: Delivery Status Notifications (RFC 3464, ein message/delivery-status-Teil innerhalb von multipart/report) und Abuse Feedback Reports (RFC 5965, ein message/feedback-report-Teil).

Schritte

1. Bounces zur Maschine leiten: den Envelope-Absender (Return-Path) pro Nachricht oder Stream auf eine getaggte Adresse setzen (bounce+order-1234@…), damit ein Bounce auch dann zugeordnet werden kann, wenn die DSN die ursprünglichen Header weglässt.
2. Die pro Empfangende geführten Felder der DSN auswerten: Final-Recipient, Action (failed, delayed, delivered, relayed, expanded), Status und Diagnostic-Code. Status enthält einen erweiterten Statuscode class.subject.detail.
3. Nach Klasse einordnen. RFC 3463 definiert 5.X.X als permanenten Fehler, der durch erneutes Senden wahrscheinlich nicht behoben wird, und 4.X.X als anhaltenden vorübergehenden Fehler, bei dem ein späterer Versand erfolgreich sein kann. Der Subject-Subcode gibt an, wo: X.1.X Adressierung (5.1.1 ungültiges Zielpostfach), X.2.X Postfach (4.2.2 Postfach voll), X.7.X Sicherheit oder Richtlinie (5.7.1 Zustellung nicht autorisiert).
4. Bei 5.1.X und anderen permanenten Adressfehlern sofort sperren. 4.X.X pro Adresse zählen und ab einem festgelegten Schwellenwert sperren. X.7.X-Richtlinienablehnungen als Signal zur Reputation oder Authentifizierung des sendenden Systems behandeln, nicht als Beleg zur Adresse.
5. Sich bei den Feedback-Loops der Mailbox-Provider registrieren und ARF-Reports auswerten: Der zweite MIME-Teil (message/feedback-report) enthält Feedback-Type (abuse, fraud, virus, other), der dritte Teil die Originalnachricht oder deren Header. Bereits beim ersten Abuse-Report sperren; niemals auf die beschwerdeführende Person antworten.
6. Jedes Ereignis mit dem ausgewerteten Code, dem rohen Diagnosetext und der Nachrichtenreferenz speichern; Bounce- und Beschwerderaten pro Stream alarmieren, nicht nur in der Gesamtsumme.
7. Nicht standardisierte Antworten (Abwesenheitsnotizen, Freitext-Ablehnungen) aus der Sperrlogik heraushalten, sofern der Provider sie nicht klassifiziert; eine Heuristik, die bei "undeliverable" in der Betreffzeile sperrt, schlägt fehl.

Erwartetes Ergebnis

Eine Sperrliste, die anhand von Belegen wächst, niedrige Bounce- und Beschwerderaten sowie eine Antwort auf die Frage "Warum erhält diese empfangende Person keine E-Mails mehr?" innerhalb einer einzigen Abfrage.

Grenzen und Prüfbasis

Nicht jede empfangende Seite sendet standardisierte DSNs oder bietet einen Feedback-Loop an; manche grossen Provider legen nur aggregierte Spam-Raten offen. Soft-Bounce-Schwellenwerte sind eine Richtlinienentscheidung, kein Standard. Die Formatangaben folgen den zitierten RFCs; es werden keine Raten behauptet.