website/content/posts/blocking-invalid-rcpt-postfix.md

+++ date = '2025-08-01T10:03:15+02:00' draft = false title = 'Backscatter ade: Ungültige Empfänger vor dem Exchange abfangen'

[cover] image = "/imgs/email-route.jpg" alt = "E-Mail App Icon auf blauem Hintergrund" caption = "" +++

Neulich hatte ich ein richtig fieses Problem: Backscatter. Einer unserer Mail-Gateways landete auf der backscatter.org-Blacklist, weil wir Bounce-Nachrichten an gefälschte Absender geschickt haben. Ja, genau so läuft das: man will ja eigentlich nur Mails zustellen und plötzlich ist man selber der Spammer.

Nach einem Blick in die Logs war mir klar: Unser System war gegen Backscatter-Attacken so gut geschützt wie ein Fahrradschloss aus Pappe. Also musste was passieren.

Was zur Hölle ist Backscatter?

Backscatter ist Müll, den dein Mail-Server verschickt, nachdem er eine Nachricht angenommen hat – meistens in Form eines Non-Delivery Reports (NDR) oder Bounces an eine gefälschte Absenderadresse.

Passiert so:

• Ein Spammer schickt 'ne Mail mit ner fake "Von"-Adresse (oft von nem armen Unschuldigen).
• Dein Server nimmt die Mail an, stellt aber später fest: "Hoppla, den Empfänger gibt's gar nicht."
• Dein Server schickt nen Bounce an die gefälschte Absenderadresse – und trifft damit den Falschen.

Und Zack, dein Server versendet Spam, ohne es zu wollen. Willkommen im Club.

Das Problem bei uns

Unser Mail-Gateway leitet hauptsächlich Mails an mehrere interne Exchange-Cluster weiter. Klar, wir haben eine Liste mit gültigen Domains – Postfix nimmt nur Mail für diese Domains an.

Das Problem? Postfix wusste nicht, welche einzelnen Empfänger auf den Exchange-Servern gültig sind. Also hat es fröhlich Mails für nicht existierende Benutzer angenommen, um sie dann später zu bouncen. Klassischer Backscatter.

Das Ziel

Wir wollten Mails während der SMTP-Session ablehnen – idealerweise direkt nach dem RCPT TO-Befehl, wenn der Empfänger auf dem Exchange nicht existiert.

Dann kriegt der Sender sofort einen Korb und wir müssen erst gar keinen Bounce generieren. Win-Win.

Mögliche Lösungen (und warum ich sie verworfen hab)

1. relay_recipient_maps

Dafür hätte ich ne komplette Liste aller gültigen Empfänger in Postfix pflegen müssen. Klar, geht. Aber dann müsste ich ein Skript schreiben, das die Liste regelmäßig aus Active Directory synchronisiert.

Für uns war das zu viel Gefrickel, zu fehleranfällig und zu nervig zu warten.

2. virtual_mailbox_maps mit LDAP

LDAP-Lookups direkt gegen Active Directory, um Empfänger in Echtzeit zu prüfen. Klingt erstmal gut, aber:

• Mehr Komplexität und Abhängigkeiten.
• Potenzielle Sicherheitsrisiken.
• Hat nicht so richtig in unsere Umgebung gepasst.

Also auch gestrichen.

Die Lösung: reject_unverified_recipient

Beim Durchlesen der Postfix Address Verification Howto bin ich über reject_unverified_recipient gestolpert – und dachte sofort: "Digga, genau das brauch ich!"

Wie es funktioniert

Wenn ne eingehende SMTP-Session die RCPT TO-Phase erreicht:

1. Postfix checkt, ob reject_unverified_recipient für die Empfängerdomäne aktiv ist.
2. Wenn ja, wird kurz beim downstream Mail-System angefragt, ob die Adresse existiert.
3. Antwort vom downstream System:
   • User existiert → Postfix macht weiter.
   • User existiert nicht → Postfix lehnt sofort ab mit:

     550 5.1.1 <user@example.de>: Recipient address rejected: User unknown
     

Weil die Ablehnung während des SMTP-Dialogs passiert, wird gar kein Bounce generiert. Backscatter ade!

Umsetzung in ISPConfig

Bei uns laufen die Mail-Gateways mit Postfix und ISPConfig als Verwaltungsoberfläche. Also hab ich ne neue Konfigurationsoption in ISPConfig eingebaut, mit der man `reject_unverified_recipient** pro Domain steuern kann – plus einen Validation Server für den downstream-Server.

Validation Server für die Empfängerprüfung

Wichtiges Detail: Exchange-Server können standardmäßig keine Empfänger über SMTP-Port 25 validieren. Man muss die Funktion erst auf dem Exchange aktivieren und den Hub Transport Service nutzen – der läuft standardmäßig auf Port 2525.

Unbedingt den Zugriff auf diesen Port einschränken! Der erlaubt nämlich anonyme Logins für die Empfängervalidierung – das will man nicht in der freien Wildbahn haben.

Achtung: Das ändert nichts an deinem normalen Mail-Flow. Nur die SMTP-Probes für die Empfängerprüfung gehen an diesen Validation Server. Postfix macht das mit der address_verify_transport_maps-Option.

Für die Performance hab ich noch nen lokalen Cache auf dem Gateway eingerichtet (address_verify_map), damit nicht ständig dieselben Empfänger neu geprüft werden. Spart Nerven und Resourcen.

Jetzt können wir für alle Domains, die eine Empfängerprüfung brauchen, das Ding im Panel anschalten und Postfix ans richtige Validation Transport schicken.

Das Ergebnis

Seit reject_unverified_recipient aktiv ist und auf die Exchange-Cluster zeigt, ist der Backscatter komplett weg. Wir nehmen keine Mails mehr für ungültige Empfänger an. Feierabend.

Fazit

Wenn dein Postfix als Relay für Exchange (oder ein anderes downstream-Mail-System) läuft und du Backscatter-Spam loswerden willst: reject_unverified_recipient ist der Weg. Sauber, dynamisch, keine großen statischen Listen – und vor allem: die Drecksmail kommt erst gar nicht rein.