Backscatter Mails mit Postfix ausfiltern

Backscatter ist eine besondere Form von Spam, die mit gängigen Spamfiltern und Server-Einstellungen kaum auszusortieren ist. Mit einer speziellen Blacklist ist es aber recht einfach möglich den größten Teil der Backscatter Mails (Und nur die Backscatter E-Mails!) abzuweisen, ehe sie überhaupt in das eigene Mailsystem hinein gelangen.

Die Vorgeschichte: Ein Kunde klagt sein Leid

Vor einiger Zeit erhielt ich den Anruf eines Kunden. Eine seiner eingerichteten E-Mail Adressen erhielt täglich mehrere hundert Status-Mails, á la „Delivery Failure Notice“ u.ä. Der Kunde hatte die entsprechenden Adressaten, von wo die Mail abgelehnt wurden, aber nie angeschrieben. Bei genauerem Hinsehen kamen die die meisten dieser Mails mit Mail-Adressen russischer Domains ( .ru ) und die ursprünglich an diese Adressen verschickte E-Mail war wohl wirklich Spam.

Keine Abwehr-Chance für den policyd-weight, SpamAssassin & Co.

Meine Mailserver arbeiten mit einem mehrstufigen System aus speziellen Einstellungen des Mail-Servers Postfix inkl. policyd-weight und dem Content-Filter SpamAssassin. Grob gesagt rund 90% der Mails werden vom System gar nicht erst angenommen (False Positives hatte ich schon lange keine mehr; ggf. gibt es für einzelne Mailserver von Dritten Ausnahmeregeln), der Rest wird durch SpamAssassin mit einem erweiterten und ständig aktualisierten Satz an Regeln geschleust. In den diversen Stufen kommen zudem auch Checks durch Razor, Pyzor und von DNSWL und SPF zum Einsatz.

Das alles konnte aber nicht helfen, weil die Backscatter Mails „korrekt“ waren. Ein Spamserver / diverse komprommitierte Systeme im Internet verschicken dabei Spam in alle Welt. Dabei benutzen sie real existierende E-Mail Adressen als gefälschte Absender. Nimmt das Zielsystem die Mail zunächst an, kann diese aber nicht zustellen, z.B. weil das Postfach nicht existiert, voll ist, oder dergleichen, wird eine „korrekte“ Mail zur Benachrichtigung des vermeintlichen Absenders an diesen verschickt. Dieser jedoch weiß von seinem zweifelhaften Glück bis dahin gar nichts.

So gesehen ist diese Statusmail technisch korrekt ausgestellt und enspricht keinem Schema, dem sonst übliche direkt zugestellte Spams entsprechen. Daher greifen die normalen Abwehrmechanismen hier nicht. Die Folge waren in diesem Fall bis zu 600 Fehlermails pro Tag und Adresse, die Spam gewissermaßen „über Bande“ zustellen!

So wird Abhilfe geschaffen

Nach einigem Suchen stolperte ich über eine spezielle DNSBL auf backscatterer.org, in der nur Server gelistet werden, die Backscatter Mails verschicken und zwar 4 Wochen lang ab dem Zeitpunkt, wo sie „erwischt“ werden, es sei denn die Betreiber können den Server vorher manuell aus der Liste austragen. Für den Postfix Mailserver geht man zur Nutzung folgendermaßen vor (getestet auf Debian Etch Systemen):

Wir prüfen erstmal, ob unsere Postfix Installation DBM Dateien verarbeiten kann:

[sourcecode language=“css“]

meinServer:~# postconf -m
btree
cidr
dbm
environ
hash
nis
proxy
regexp
sdbm
static
tcp
unix

[/sourcecode]

Dann legen wir eine neue Datei /etc/postfix/check_backscatterer mit folgendem Inhalt an:

[sourcecode language=“css“]

<> reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org

[/sourcecode]

Wenn unser Postfix DBM Dateien unterstützt, die Ausgabe von „postconf -m“ also eine Zeile „dbm“ enthält, fügen wir nun folgende Zeile als letzte Option in die smtpd_recipient_restrictions in die /etc/postfix/main.cf ein (als vorletzte Zeile, falls wir als letzte das optionale und im Grunde überflüssige „permit“ benutzen):

[sourcecode language=“css“]

smtpd_recipient_restrictions =

check_sender_access dbm:/etc/postfix/check_backscatterer,
permit

[/sourcecode]

Wenn unser Postfix keine DBM Dateien unterstützt, die Ausgabe von „postconf -m“ also die Zeile „dbm“ nicht enthält,  fügen wir stattdessen folgende Zeile ein …

[sourcecode language=“css“]

smtpd_recipient_restrictions =

check_sender_access hash:/etc/postfix/check_backscatterer,
permit

[/sourcecode]

… und müssen dann noch die  /etc/postfix/check_backscatterer in das Hash-Format umwandeln mit:

[sourcecode language=“css“]

meinServer:~# postmap hash:/etc/postfix/check_backscatterer

[/sourcecode]

Nun können wir Postfix anweisen seine Konfiguration neu einzulesen und alles ist scharfgeschaltet:

[sourcecode language=“css“]

meinServer:~# /etc/init.d/postfix reload
Reloading Postfix configuration…done.
[/sourcecode]

Wer wissen möchte wieviele solche Mails abgewiesen wurden, kann dies z.B. hiermit herausfinden:

[sourcecode language=“css“]

meinServer:~# cat /var/log/mail.log | grep backscatterer | wc -l
27
[/sourcecode]

Ende gut, alles gut

Der Schutz ist nur so gut wie die benutzte Blacklist. Im Fall meines Kunden reduzierten sich die durchkommenden Mails auf eine kleine handvoll pro Tag – um Längen besser als die mehreren hundert, die sonst Tag für Tag in seinem Postfach aufschlugen. Der Kunde ist glücklich und ich habe etwas dazu gelernt.

Kommentare (18)

  1. Greylisting tut’s auch. Simpel, ressourcensparend und effektiv. Meine Kunden berichten von max. 2-3 durchkommenden Spam-Mails im Monat. Und der Mailserver idelt dahin … :)

  2. Diverse Untersuchungen in der Praxis zeigen, dass Spam-Wellen auch gezielt in typischerweise eingestellten Zeiträumen vom Greylisting kommen, um dieses zu umgehen. Ich habe u.a. ein paar sehr mailintensive Kunden mit mehreren Dutzend Arbeitsplätzen in mehreren Standorten weltweit udn entsprechender Kundschaft auf dem ganzen Globus. Ich möchte mir gar nicht ausmalen was geschieht, wenn die mal ne Stunde auf eine Mail warten müssen. ;-)
    Newsletter etc. sollen in dem Zusammenhang auch problematisch sein.

    Grundsätzlich kann man wohl sagen, dass es ein Sammelsurum an Möglichkeiten gibt und es letzten Endes die Kombination macht. Was durchkommenden Spam ankommt kann ich mich nicht beschweren, ich kenne ja meine Postfächer und Serverstatistiken. Dafür, dass ich mein System nicht nochmal selbst mit Spam und Ham trainiere (ich habe da keinen Nerv zu, die Kunden haben auch weder Nerv noch Kenne) ist die Quote schon sehr sehr gut – deutlich besser und vor allem transparenter als manches System durchaus guter Hoster von diversen anderen Kunden.

    Es gibt in der Tat ein paar raffetückische Systeme, wo man beispielsweise als Sender erstmal mit dem Mailsystem nach einer Rückmail über ein Webinterface kommunizieren muss, um sich händisch auch als Mensch erkennen zu geben und sich somit in eine interne Whitelist des Systems eintragen zu lassen. Zumindest damals als ich mal nachforschte, gab es sowas aber nur als rein kommerzielle Lösung, bzw. per MX-Eintrag als Service.

  3. Ich habe das nun einmal getestet und nach ersten Tests gleich wieder deaktiviert, weil gar keine E-Mail mehr durchkam, denn offenbar werden nicht nur Unzustellbarkeitsnachrichten mit dieser Technik geblockt, sondern der gesamte eingehende Mailverkehr der auf backscatterer.org gelisteten Domains. Und Positives hatte ich gestern Abend bei Mailservern von GMX, Domainfactory, Silverserver (Österreich) – diese habe ich halt getestet.

    Bei meinem Test eben wird eine IP einmal für „mindesten 1 Monat gesperrt“ angezeigt, 10 min später ist dieselbe IP clean.

    Das ist mir zu unsicher – da wird Mailing ja zum Glücksspiel.

    Hast Du denn solche Erfahrungen nicht??

  4. Nein, hier funktioniert bislang alles völlig problemlos und bei den Mailvolumina meiner Kundschaft hätte ich sonst wohl schon Beschwerden bekommen.

    Die UCEPROTECT Listen sind ja durchaus recht umstritten, aber mit dieser Konfig werden ja lediglich Mails über die Liste geprüft, deren Sender <> oder postmaster sind.

    Bist du denn Nach Anleitung vorgegangen? Habe ich was vergessen? Originalanleitung ist hier zu finden: http://www.backscatterer.org/?target=usage

  5. Moin Manfred!

    Wo ich dich gerade hier habe: Ich hatte die letzten Tage so zwei Server an die ich keine Mails schicken konnte. In beiden Fällen waren sie als Backscatterer gelistet und wurden abgelehnt, als sie Sender Verification mit meinem Mailserver betreiben wollten.

    Führt SV zum Listing?

  6. Habe mir den entsprechenden Beitrag http://www.backscatterer.org/?target=sendercallouts nochmal gegeben und bin damit soweit völlig d’accord. Quitnessenz ist, dass ich der Meinung bin alles richtig zu machen. Daraus ergibt sich aber die beiderseitige Notwendigkeit Mail-Server sowohl in die DNSWL (dnswl.org) einzutragen als auch vorne in den Header-Checks gegen die DNSWL zu checken – und zwar „hart“ (keine weiteren Header Checks bei Positiven).

    Zum „Glück“ handhabe ich das schon lange so. Die Bösen sind also diejenigen, die noch VRFY machen, nicht hart auf DNSWL checken und in der ips.backscatterer.org stehen. Die muss man sich dann wohl erziehen… ;)

  7. Die Liste von backscatterer.org ist ein Witz! Wird eine IP positiv gelistet weil sie RFC konform auf eine unzustellbare Mail dem vermeintlichen Absender antwortet wird diese IP für 4 Wochen (!) gelistet. Ein Delisting (bei allen seriösen Listanbietern kostenfrei möglich) kostet rund 50 Euro Gebühr. Ich kann daher nur dazu raten dieser – meiner Meinung nach – Abzocke ein Ende zu bereiten und diese Liste auf gar keinen Fall zu verwenden.

  8. Ich kann mir kaum vorstellen, dass man dort für „eine“ Mail gelistet wird. Nach meinen bisherigen Erfahrungen sind die geblockten IPs entweder irgendwelche Russenserver, oder aber Server die Sender Callouts machen. Ggf. sollte man als Admin aber ein Auge darauf haben, ob irgendein Postfach seit Wochen voll ist, weil der Inhaber es aufgegeben hat sich durch den Spam zu wühlen (womöglich weil er selbst den Filter deaktiviert hat oder so „schlau“ war nen Catchall einzurichten)..

    Sollen sich die Admins in die DNSWL eintragen und diese nutzen, schon haben wir alle weniger Probleme.

    Frage des Tages:
    Bekommen eigentlich auch Spam-Bot Betreiber Spam, oder sind diese „immun“?

  9. Ich kann HosterME nur zustimmen. Eine vollkommen RFC konforme Mail (NDR) von meinen Exchangeserver ist der Auslöser für die Sperrung eines Mailservers!
    Jeder sollte sich überlegen diesen Dienst zu nutzen.
    Das Angebot für 50€ den Server zu entfernen sagt mehr als 1000 Worte!

    Meiner Meinung nach Abzocke !!!

  10. @AL Ja, Sender Callouts führen zu einem Listing

    @Jürgen Herrmann
    Wenn Sie die erste Spammwelle mit Ihrer Domain als Absender trifft und die Callouts der Server draußen auf Ihren Exchange einschlagen werden Sie anders darüber denken.

    Ich möchte wetten, der NDR ging an einen gefakten Absender mit einem Dialupbot als „Einliefendes System“….

  11. Total doofe Sache backscatterer.org zu nutzen.

    Meine Server waren auch schon einige Male auf deren Liste.
    Na und? Kein Mensch hat sich darüber beschwert.

    Und Sender Callouts mach mein MTA per default-Konfiguration und das ist auch gut so. Die meisten Spam-Mails werden durch das ‚Sender Callout‘ verhindert.

    Jaja, ich warte auf die Spamwellen, welche durch einen gefakten Absender meine Server platt machen.

    Nur zu :-)

  12. Hallo,

    also backscatterer sollte niemand abfragen, am besten komplett
    useprotect vergessen. Das sind nur Geldschneider.

  13. Für so einen sinnfreien Kommentar einen 1 Jahr alten Eintrag zu kommentieren. Hut ab.

  14. Da setze ich noch einen rauf, weitere 6 Monate danach. :-) Backscatterer.org sind nun mal Abzocker. Ich betreibe 3 Webserver. Gerade der Server der am wenigsten Domains und Emailtraffic hat, steht ständig da auf der Liste. Ist er mal wieder gelöscht, dauert es keine Woche, dann ist er dort wieder gelistet. Ich kenne alle Kunden die den Server nutzen persönlich. Ich weiß nicht, wer von denen dafür sorgen sollte, dass ein Mailserver auf diese blöde Liste kommt. Geld für die Austragung zu verlangen und dann noch in dieser Höhe ist einfach vermessen. Ich freue mich auch über jeden, der so einem Anbieter den Rücken kehrt.

  15. Den Mail-Server, den ich damals pimpte, gibt es seit ein paar Monaten nicht mehr. Seine Nachfolger hatten das Problem zum Glück nie, weswegen ich die Liste in den Setups meiner aktuellen MXer auch nicht mehr einsetze. Ich hoffe, dass mir dies auch in Zukunft erspart bleibt.

  16. @Martin:
    Es spielt für Backscatter keine Rolle welche Kunden auf dem Server liegen. Backscatter sind Mails wie Status Delivery Notices, Abwesenheitsnotizen und dergleichen, die der Server selbständig verschickt und die nicht durch einen User über SMTP zur Auslieferung übergeben werden.

    Ein nur leicht suboptimal konfiguriertes System verschickt schnell mal solche Mails. Das ist auch nicht grundsätzlich problematisch, nichtmal im Sinne der etwas seltsamen Betreiber von backscatterer.org. Stattdessen gilt es sich dort mal die Texte unter „Bounces“, „Autoresponders“ und „Sender Callouts“ durchzulesen und die Konfiguration der eigenen Mailserver entsprechend gegenzuprüfen und ggf. anzupassen.

    Da ich das hier bei einem Kollegen gerade mitbekomme nochmal ganz klar, weil es gerne überlesen und darum falsch gemacht wird: Die RBL ips.backscatterer.org ist keine DNSBL, gegen die generell Mail gecheckt werden sollte! Setzt man diese Liste ein, sollten nur Mails von den Absendern <> und postmaster gegen sie geprüft werden. Das bezeichnen die Betreiber als SAFE MODE.

    Wer diese RBL anders einsetzt wird früher oder später auf jeden Fall auch vermehrt False Positives haben, also Mails die zu Unrecht geblockt werden.

  17. Pingback: Backscatter – Man wird alt wie ‘ne Kuh | campino2k

Kommentare sind geschlossen.