Heutiger Fall, dass Mails unserer Kunden bei Reddox Mail-Gateways abgewiesen werden mit:

dsn=5.0.0, status=bounced (host ….] said: 550 Recipient not accepted. (BATV: no tag) (in reply to RCPT TO command))

Was ist passiert?

Der ursprüngliche Absender nutzt mit seinem Reddox-Spam-Gateway, BATV zur Bounceabwehr. Hier erhält jede ausgehende Mail folgenden Header:

Return-Path: <prvs=1901156906=absender@senderdomain.de>

Die Zahl ist ein individueller Code. Erhält das Reddox-Mailgateway eine Bounce-Mail eines fremden Servers, wird bei BATV erwartet, dass jede Mail an eine mit prvs=…. und Code hinterlegte Adresse zurück geschickt wird.

Trägt eine Mail keinen Code, geht Reddox/BATV davon aus, dass diese Mail nicht ursprünglich von diesem System verschickt wurde.

Dies hat jedoch zwei Desigsn-Schwächen:

Fordert der Absender beim Versand eine Lesebestätigung an vom Empfänger, ergänzt dieser dazu den Mailheader um:

Disposition-Notification-To: Ursprünglicher Absender <absender@senderdomain.de>

Jetzt sieht man hier schon das Problem. Bei Bounces muss der Absender immer <> – also leer sein um ein Ping-Pong von Bounces zu vermeiden. Der Empfänger der die Lesebestätigung beantwortet, schickt also folgende Nachricht los:

from=<>

to=

absender@senderdomain.de

Jetzt prüft der Empfänger ob die Mail einen prvs Code enthält, findet ihn nicht und lehnt die Mail ab.

Aus meiner Sicht gibt es bessere Methoden zur Bounce-Abwehr. Speziell weil in o.g. Fall, der Sender seine eigene angeforderte Lesebestätigung, durch den Design-Fehler von BATV, selbst ablehnt, wenn er eintrifft.

Categories: Blog