In meiner beliebten Serie über idiotische Sperrlisten, dieses Mal eine ganz grossartig bescheuerte Idee von SpamCop.net. Bei denen wird jetzt ein Server eingetragen, wenn dieser Mails auf nachgelagerte Systeme routet und dann Fehlermeldungen wieder rausroutet. Kurz unser Firmenszenario: unsere Kunden werden über unseren zentralen Mailserver versorgt, haben aber in der Regel eigene Mailsysteme (Exchange oder Linux-Systeme). Aus diesem Grund müssen wir für einige der Kunden Mails anehmen, egal welchen Localpart die haben - wir haben keine Kontrolle darüber, wer alles im Exchange konfiguriert ist. Desweiteren sind diese Systeme dynamisch angebunden, weshalb auch eine Life-Prüfung nicht in Frage kommt. Natürlich generieren die Mailsysteme Bounces für diese falschen Adressen - und natürlich entstehen dadurch auch Bounces auf Virenmist und Spam. Unsere Kunden haben aber ein berechtigtes Interesse an diesen Bounces, da nur so deren Partner über Tippfehler in Adressen erfahren.
Spamcop hingegen ist jetzt der Meinung, man solle die Bounces nicht weiterleiten, man müsse unbedingt ganz vorne auf SMTP-Ebene prüfen. Oder man müsse Bounces über eine eigene IP routen, die dann von Spamcop gesperrt wird, was ja kein Problem wäre (hä? damit kommen aber die legitimen Bounces nicht beim Empfänger an, wenn der hinter jemandem sitzt, der diese unfähig administrierte Liste benutzt).
Fachlich bedeutet das, das Spamcop sich anmaßt die Entscheidung zu treffen, das ein Mailserver keine Bounces rausleiten darf, wenn er eine Mail akzeptiert hat. Bounces dürfen nach Spamcop-Meinung nur auf SMTP-Ebene als Abweisung passieren, die klassichen Bounce-Mails sind nach deren Ansicht ein Grund, jemanden in eine Sperrliste einzutragen. Sie gehen sogar so weit, das jegliche Form von Autorespondern verboten ist und zu einem Eintrag in deren Sperrliste führt.
Einer Sperrliste, wohlgemerkt, deren angebliches Ziel es ist, das Spam abgewiesen wird. Was hiermit eindeutig mal wieder widerlegt ist - SpamCop hat genauso eine eigene Agenda, wie jeder andere Betreiber von Sperrlisten, und wie üblich (siehe SORBS mit den Eintragungen als gehackter Server, wenn z.B. FTP auf einem ungewöhnlichen Port läuft) glänzt es durch Inkompetenz.
Übrigens haben wir Sender-Verify auf unseren Mailservern aktiviert, weshalb nur Mails durchgehen, deren technischer Absender vom eigenen MX als gültig avisiert werden. Von daher bouncen wir nur auf Adressen, die zumindestens von deren eigenem MX auch als gültig angesehen werden. Es sind keine "misdirected bounces" auf ungültige Adressen, es sei denn, der MX dieser Adressen lügt (dann ist das aber sein eigenes Problem).
Mailbetreiber, die solche Sperrlisten zur Abweisung von Mailserver-Connects verwenden, handeln unverantwortlich. Einer davon sitzt bei Microsoft ...
-thh Sept. 23, 2006, 10:18 a.m.
Unverantwortlich handelt m.E. eher der, der gültige Adressen mit collateral spam bedenkt. "Late bounces" sind für Betroffene von Spamruns mit gefälschten Absendern (gibt es noch andere?) sogar deutlich problematischer als Spam, zum einen wegen der eingehenden Massen an Bounces, zum anderen, weil sie schlechter filterbar sind.
Der richtige Ansatz ist also nicht, sich über Spamcop zu beschweren, sondern an der Verbesserung der eigenen Infrastruktur zu arbeiten. Daß man für einige Kunden Mail für alle Adressen annehmen muß, ist ja nicht gottgegeben, sondern Konfigurationsfrage, genau wie es nicht gottgegeben war, daß ein Mailserver beliebig relayed. Letzteres hat man schon abgestellt (oder steht auf einer Blacklist), ersteres wird man abstellen müssen; denn die Idee seitens von Spammern, ihren Dreck "umgekehrt" zu adressieren - d.h. ungültige Adresse als Empfänger, Zieladresse als Absender -, so daß der Bounce dann erst zur Auslieferung führt, ist nicht direkt neu. Zumindest dürfte es zu fordern sein, daß man bestmöglich überprüft, ob die E-Mail denn tatsächlich vom angeblichen Absender kam; dazu genügt es natürlich nicht, zu prüfen, ob es den überhaupt gibt, sondern zumindest eingeführte Systeme der Absenderverifikation wie SPF sollten ausgewertet werden.
hugo Sept. 24, 2006, 12:27 p.m.
SpamCop trägt Server ein, die a) nicht spammen und b) RFC-konform sind. Das ist technisch schlicht falsch. Alles andere hat damit erstmal nichts zu tun - spf macht das nicht besser (blockieren von bouncenden Servern ist immer noch falsch). Spam wird immer verteilt werden (stopfe ein Loch heute, finde ein neues morgen), ein Alleingang in Cowboy-Mentalität der RFCs verletzt oder nach eigenem Gusto uminterpretiert ist immer noch falsch. Und ja, ich werde auch weiterhin über Idioten schimpfen, die selbstherrlich ihre eigene Agenda umsetzen wollen und dabei anderen Arbeit machen.
SPF hat bisher keine brauchbare Verbreitung, ob du es einsetzt oder nicht ändert nichts an der Tatsache, das SpamCop Systeme einträgt, die irgendeine Form von Autoresponse generieren - selbst wenn dieser RFC-konform gekennzeichnet ist (mit dem leeren Envelope Absender).
Bounces sind trivial erkennbar und genauso filterbar wie jede andere Mailform. Also auch kein Argument dafür, das es korrekt wäre, diese Systeme in Sperrlisten einzutragen.
Ja, der richtige Ansatz wäre eine weite Verbreitung einer funktionierenden Absender-Verifizierung. Gibt es aber noch nicht. Und daher ist es technisch Blödsinn, mit einem Alleingang Serverbetreibern Ärger zu machen.
Und was das "Abstellen" angeht: es ist nunmal Fakt, das Systeme nicht immer in einer Online-Kette verbunden sind. Jeder Admin, bei dem noch UUCP-Ketten im Einsatz sind, kennt das. Und es gibt haufenweise andere Situationen, in denen ähnliche Probleme existieren. Genau für diesen Zweck sind Bounce-Mails nunmal da. Per RFC definiert.
Wer keine Bounces haben will, kann jederzeit am eigenen Mailserver auf den leeren Envelope-Absender prüfen und alles damit wegwerfen. Und nie wieder erkennen, wenn ein Problem vorliegt. Das ist dann eine lokale Entscheidung. Dumme Mailserver-Admins die SpamCop als harte Sperrliste eintragen hingegen machen das zu einer wesentlich globaleren Entscheidung. Und ja, das ist etwas das mir stinkt.
Wäre SPF ein RFC im Standard-Track, und würden nur Systeme in der Liste landen, die an gefälschte Adressen automatische Responses schicken zu einem Eintrag führen, wäre das zumindestens technisch fundierter. Trotzdem noch problematisch, da nur ein verschwindend geringer Teil von Domains SPF-Einträge hat.
Ja, indirekter Bounce-Spam nervt. Dumme Admins, die einem das Leben schwer machen mit einer technisch inkompetenten Entscheidung nerven allerdings weitaus mehr.
Es gibt übrigens gute Gründe, warum nahezu alle Sperrlistenbetreiber empfehlen die Liste nicht zum harten Sperren einzusetzen, sondern nur im Rahmen eines Scoring ... (selbst SpamCop macht das so)
Andreas Oct. 14, 2006, 3:31 p.m.
All "TELECOM ITALIA" smtp addresses blocked by SpamCop.
This makes a lot of problems sending emails to SpamCop's users.