99 lines
5.4 KiB
Markdown
99 lines
5.4 KiB
Markdown
+++
|
||
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.
|