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.