 |
| netcup präsentiert RPaaS :: Kurz notiert: Lockfile für Arme |
|
|
||||||||||
|
||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Was würdest du antworten, wenn dich jemand fragt, ob dein Mailserver (Postfix) im Normalzustand Backscatter ermöglicht?
Bisher wäre meine Antwort, ohne lange nachzudenken, sofort gewesen: "Natürlich nicht! Das ist ein absolutes No-Go." Mittlerweile sehe ich das etwas anders und würde wohl eher so antworten: "Das ist kompliziert, es kommt drauf an..." 
Vorwort: Delivery Status Notifications (DSN) Die Sache ist eigentlich relativ einfach: Eine Mail sollte bereits während des SMTP-Dialogs abgewiesen werden. Normalerweise erreicht man das mit diversen Checks während der SMTP-Transaktion, häufig unterstützt durch diverse Milter für Viren-/Spamfilter. Sobald die Mail durch den Server angenommen wurde und in der eigenen Queue landet, würde jede danach folgende Abweisung zum Versand einer Delivery Status Notification sorgen. Das grundlegende Problem daran ist, dass der vermeintliche Absender der Mail und somit Empfänger einer DSN beliebig gefälscht werden kann. Das ist eine weit verbreitete Masche der Spamversender. Es gilt somit, dass der Versand einer DSN an externe Adressen immer vermieden wird. Sobald eine Mail in die eigenen Queue aufgenommen wurde, darf sie nicht mehr abgewiesen werden! (Von temporären Systemfehlern o.ä. einmal abgesehen.) Davon unterscheiden sollte man explizite DSN-Requests des Versenders. Diese haben ihre Daseinsberechtigung allerdings meistens nur für (authentifizierte) Benutzer des eigenen Mailservers. Das Missbrauchspotential durch Außenstehende ist andernfalls zu groß. Wie man angeforderte DSN komplett deaktiviert oder einschränkt, erklärt die Postfix Dokumentation. Darum geht es in diesem Blogbeitrag nicht. Delivered-To Header als Loop Detection Häufig genutzte Transports bzw. Befehle bei Postfix sind z.B. local, virtual und pipe. Und überall gibt es eine Erkennung für Endlosschleifen. Realisiert wird das meistens über den Delivered-To Header, in den die Adresse des Zielpostfachs eingetragen wird. Nachfolgend einige Auszüge aus der Dokumentation...
Postfix weist eine Mail ab, wenn ein passender Delivered-To Header mit der gleichen Postfachadresse bereits vorhanden ist. Das ist prinzipiell keine schlechte Idee! Aber was passiert, wenn ein Spammer genau diesen Header von selbst bereits setzt? Einsturz des Kartenhauses... Eine Mail mit vorhandenem Delivered-To Header und passendem Inhalt löst bei einer Standardkonfiguration nun das aus, was die Dokumentation beschreibt:
Das ist unschön. Extrem unschön! Ein Außenstehender kann Bounce-Nachrichten an beliebige Empfänger auslösen, allgemein als Backscatter bekannt. Er muss dafür nur die genaue Adresse eines E-Mail Postfachs kennen, Aliasadressen reichen dafür nicht! Wirklich schlimm wird es aber erst dadurch, dass sich viele Postfix-Admins nicht bewusst sind, welche gefährliche Funktion im System schlummert. Ich gehörte bis vor wenigen Tagen ebenfalls zu dieser Gruppe. In zahlreichen Anleitungen wird dieses Verhalten sogar noch explizit aktiviert, siehe z.B. der LDA-Beitrag im Dovecot Wiki. Die Lösung? Es gibt mehrere... Es gibt mehrere Möglichkeiten, um dieses Verhalten abzuschwächen oder ganz zu deaktivieren. Eines haben alle mir bekannten Lösungen leider gemeinsam: Entweder man deaktiviert damit die Bounce-Versendung ganz bzw. teilweise oder die Loop-Detection wird ausgehebelt. Die Alternative, zur Quelle für Backscatter zu werden, gefällt mir persönlich allerdings noch weniger!
Alternativ gibt es einige Methoden, die unabhängig vom verwendeten Transport/Befehl arbeiten und den Delivered-To Header unverändert einfügen. Einige davon, wenn nicht sogar alle, sind aus rechtlicher und technischer Sicht allerdings bedenklich.
Letzteres lässt sich mit header_checks und einer PCRE-Tabelle realisieren. Unter Debian muss dafür das Paket postfix-pcre installiert sein. Die Überprüfung kann durch eigene Cleanup-Services sogar je Port anders geregelt werden. Das würde allerdings den Rahmen dieses Blogbeitrags deutlich sprengen. Code:
Als Inhalt der soeben eingetragenen Datei könnte so etwas dienen: Code:
Dadurch wird automatisch ein "X-" vorangestellt. Die Aktion wird übrigens detailliert ins Protokoll von Postfix (z.B. Syslog) geschrieben. Persönliches Fazit Mailserver sind und bleiben ein fragiles sowie kompliziertes Thema. Backscatter lässt sich nie zu 100% vermeiden.
Beim letzten Punkt beziehe ich mich auf das Hopcount-Limit, das standardmäßig bei 50 liegt. Dabei werden die enthaltenen Received Header (inkl. der neu eingefügten Received Zeile) gezählt und mit einem Limit verglichen. Sollte es durch eine Fehlkonfiguration von Weiterleitungen zu einer Endlosschleife zwischen mehreren Servern kommen, schlägt normalerweise immer noch diese allerletzte Sicherheitsfunktion an. Das Gute daran: Dabei kommt es zu keinem Bounce! Wenn das Hoplimit erreicht wurde, wird die Nachricht noch während des SMTP-Dialogs abgewiesen:
Seltsamerweise findet man diese Meldung nicht im Protokoll des Mailservers, der die Ablehnung erzeugt. Aber das ist eine andere Geschichte. Weiterführende Links Es gibt zu diesem Thema einige ältere Beiträge im Internet...
Feedback bitte in den Kommentaren (nur für registrierte User), im Forum oder per E-Mail abgeben. |
||||||||||
|
||||||||||
|
|||
| Autor | Nachricht | ||
|---|---|---|---|
| Für diesen Beitrag können zur Zeit keine neuen Kommentare verfasst werden. Kontaktiere den Autor des Beitrages, falls du Fragen dazu hast. |
|||
|
||||
  |
|
|||