WebMail 
Support 
Backscatter-Schutz: So verbessern wir die Zustellbarkeit Ihrer E-Mails
Wir haben auf unserer gesamten Mail-Infrastruktur einen zusätzlichen Backscatter-Schutz aktiviert, der einen bislang wenig beachteten Angriffsweg schließt. Dabei bringen Fremde einen Mailserver dazu, unfreiwillig Nachrichten an unbeteiligte Dritte zu versenden. Die Folge sind Einträge auf Reputationslisten und damit Zustellprobleme für alle Kunden, die über den betroffenen Server versenden.
Wir haben einen solchen Fall vollständig analysiert, die Ursache belegt und eine dauerhafte Lösung eingerichtet. Diese wird seitdem täglich automatisch überprüft.
Für Sie ändert sich nichts. Der Schutz greift ausschließlich beim Empfang von fremden Servern. Ihr eigener Versand bleibt unverändert.
Was Backscatter ist
Als Backscatter bezeichnet man automatisch erzeugte Unzustellbarkeitsmeldungen, die an einen gefälschten Absender gehen.
Spam wird praktisch immer mit einer erfundenen Absenderadresse verschickt. Nimmt ein Mailserver eine solche Nachricht an und stellt erst danach fest, dass er sie nicht zustellen kann, erzeugt er eine Rückmeldung. Diese geht an die Adresse im Absenderfeld, und die gehört jemandem, der mit dem Vorgang nichts zu tun hat.
Aus Sicht dieses Empfängers kommt unerwünschte Post von unserem Server. Genau so bewerten es auch die großen Reputationsdienste. Sammeln sich solche Meldungen, landet die IP-Adresse auf einer Blockliste. Ab diesem Moment werden auch alle legitimen Nachrichten abgelehnt: Rechnungen, Bestellbestätigungen, Terminabsprachen.
Wie der Angriff funktioniert
Der klassische Auslöser für Backscatter ist die Annahme von Nachrichten an nicht existierende Empfänger. Dagegen schützt eine korrekt konfigurierte Empfängerprüfung, die auf unseren Servern seit jeher aktiv ist.
Der Fall, den wir untersucht haben, war raffinierter. Der Angreifer richtete seine Nachrichten an existierende Adressen und fügte dabei selbst eine Kopfzeile ein, die normalerweise nur der empfangende Server schreibt:
Delivered-To: E-Mail anzeigen
Diese Kopfzeile ist in RFC 9228 beschrieben und dient eigentlich der Nachverfolgung von Weiterleitungen.
Mailserver prüfen beim Zustellen, ob die Empfängeradresse bereits in einer solchen Zeile steht. Ist das der Fall, gehen sie von einer Weiterleitungsschleife aus und brechen ab:
status=bounced (mail forwarding loop for E-Mail anzeigen)
Diese Prüfung ist sinnvoll. Im Normalbetrieb verhindert sie, dass Nachrichten endlos zwischen zwei Systemen kreisen. Wird die Kopfzeile jedoch von außen untergeschoben, greift sie ins Leere. Eine Schleife existiert nicht, der Server erzeugt aber trotzdem eine Rückmeldung, und die geht an den gefälschten Absender.
Der Angreifer benötigt weder Zugangsdaten noch eine Sicherheitslücke. Er nutzt eine Schutzfunktion gegen den Server, der sie einsetzt. Entsprechend unauffällig sind die Symptome: kein kompromittiertes Postfach, kein Massenversand, keine verdächtigen Anmeldungen.
So funktioniert unser Backscatter-Schutz
Naheliegend wäre gewesen, die betreffende Kopfzeile serverweit zu entfernen. Das hätte das Problem beseitigt, gleichzeitig aber den echten Schleifenschutz für alle Zustellwege ausgehebelt, auch für interne Weiterleitungen und den Versand unserer Kunden.
Wir haben deshalb einen gezielteren Weg gewählt. Ausschließlich der öffentliche Eingang auf Port 25, über den fremde Server einliefern, verwendet eine eigene Verarbeitungsinstanz. Nur dort wird eine mitgelieferte Delivered-To-Zeile umbenannt und damit unschädlich gemacht.
Alle anderen Wege bleiben unverändert:
| Zustellweg | Verarbeitung | Schleifenschutz |
|---|---|---|
| Port 25, fremde Server | gesonderte Instanz | Angriff wirkungslos |
| Port 587, Ihr Versand | unverändert | vollständig aktiv |
| Port 465, Ihr Versand | unverändert | vollständig aktiv |
| interne Weiterleitungen | unverändert | vollständig aktiv |
Die Zeile wird umbenannt statt gelöscht. So bleibt nachvollziehbar, dass jemand eine Kopfzeile untergeschoben hat, und bei einer späteren Fehlersuche verschwindet nichts spurlos.
Der Backscatter-Schutz im Test
Wir wollten sicher sein, dass der Schutz auch wirklich greift. Dafür haben wir denselben Angriff zweimal eingeliefert, einmal mit deaktiviertem und einmal mit aktiviertem Schutz:
| Zustand | Ergebnis | Rückmeldung an Dritte |
|---|---|---|
| ohne Schutz | Zustellung abgebrochen, Schleife vermutet | ja |
| mit Schutz | Nachricht zugestellt | keine |
In der zugestellten Nachricht standen anschließend beide Kopfzeilen übereinander: die untergeschobene unter neuem Namen, darunter die echte des Zustellsystems. Der Angriff läuft damit ins Leere.
Dauerhaft abgesichert
Serververwaltungen wie Plesk schreiben ihre Konfiguration bei Reparaturläufen und größeren Updates neu. Eine von Hand vorgenommene Anpassung überlebt das nicht zwangsläufig, und ihr Verschwinden fällt im Alltag niemandem auf.
Wir haben die Konfiguration deshalb in unsere täglich laufende Wartungsroutine aufgenommen. Ein Prüfmodul stellt den Sollzustand wieder her, falls er abweicht, protokolliert jede Änderung und setzt bei einem Fehler automatisch auf den vorherigen Stand zurück. Weicht nichts ab, bleibt es still.
Was das für Sie bedeutet
- Stabile Zustellbarkeit. Ihre Nachrichten erreichen die Empfänger, ohne durch Reputationsprobleme ausgebremst zu werden, an denen Sie keinen Anteil haben.
- Keine Einschränkungen im Versand. Ihr eigener Versand über Port 587 und 465 ist von der Änderung nicht betroffen. Übermittlungs- und Lesebestätigungen funktionieren unverändert.
- Kein Handlungsbedarf auf Ihrer Seite. Die Umstellung erfolgte im laufenden Betrieb, ohne Unterbrechung und ohne Konfigurationsänderung in Ihren Postfächern oder Programmen.
- Laufende Kontrolle. Die Absicherung wird täglich automatisch geprüft und bei Bedarf wiederhergestellt.
Häufige Fragen
Nein. Die Umstellung erfolgte serverseitig und ohne Unterbrechung. In Ihren Postfächern, Mailprogrammen oder Shopsystemen ist keine Änderung nötig.
Nein. Lesebestätigungen werden vom Mailprogramm des Empfängers ausgewertet und bleiben unverändert. Übermittlungsbestätigungen auf Protokollebene sind ebenfalls weiterhin verfügbar.
Ein Blick in die Warteschlange genügt. Nachrichten ohne Absenderangabe sind Rückmeldungen des Systems. Gehen diese an Domains, mit denen keine Geschäftsbeziehung besteht, erzeugt der Server Backscatter.
Auf unserer Infrastruktur liefern über Port 25 ausschließlich fremde Server ein. Auf den Versandwegen 587 und 465 sowie bei internen Weiterleitungen erfüllt sie ihren eigentlichen Zweck und bleibt deshalb erhalten.
Fazit
Backscatter ist kein Einbruch, sondern die Zweckentfremdung einer Schutzfunktion. Genau das macht ihn schwer erkennbar, denn es fehlen alle üblichen Anzeichen eines Angriffs. Sichtbar wird das Problem erst, wenn die Zustellbarkeit bereits leidet.
Wir sehen es als Teil unserer Aufgabe, solche Fälle nicht nur zu beheben, sondern bis zur Ursache zu durchdringen und die Lösung dauerhaft abzusichern. Ihr E-Mail-Verkehr profitiert davon unmittelbar.
Haben Sie Fragen zur Zustellbarkeit Ihrer Nachrichten? Rufen Sie uns an unter +49 511-999 791 70.
