RootForum Community

Hallo,

nachdem ich gerade einen interessanten Artikel in der iX bezüglich der Spamflut, die neuerdings die E-Mail-Server erreicht gelesen habe, kam doch Interesse an einer kleinen Diskussion bei mir zu stande.

Um den Inhalt des Artikels kurz abzureißen:
Das gerne verwendete Verfahren des Greylisting gerät zunehmend in Probleme, da neuerdings Botnetze die E-Mail mit identischem Absender / Empfänger nach 10-20 Minuten erneut versenden. Dadurch kann Greylisting ausgetrickst werden und das Spamaufkommen erhöht sich massiv.

Die "großen" Anbieter blocken inzwischen E-Mails von dynamisch zugewiesenen IP-Adressen, jedoch noch lange nicht alle. Gerade kleine Anbieter oder Personen, die in kleinem Masse E-Mail-Server betreuen geraten dadurch ins Trudeln.

Abhilfe könnte das "Domainkeys Identified Mail"-Protokoll [1] schaffen.

---

Wie bewertet ihr die Lage oder welche Methoden würdet ihr einsetzen / setzt ihr ein?

Gruß
dtdesign

[1] RFC gegen Spam (heise online vom 27.05.2007)

Ich denke die größten Probleme werden in Zukunft die nicht mehr ganz kleinen bis mittelgroßen Anbieter bekommen.

Im kleinen kann man ja Filtern ohne (nennenswert) auf die dafür benötigten Ressourcen achten zu müssen, und bei sehr großen Installationen kann man gut eigene Techniken zur SPAM-Erkennung nutzen. (eigene Blacklists, Relaytests, Erkennung über Hashes wenn viele ähnliche E-Mails zeitnah ankommen usw.)

Hmm, ich bin kein Freund von Greylisting. Das Prinzip ist zwar schön, aber in der Praxis hat sich gezeigt, dass man sehr viel Zeit und Mühe in die manuelle Pflege von Whitelists stecken muss. Kunden haben einfach kein Verständnis dafür, wenn Mails von einem Geschäftspartner erst mit 4 Stunden Verzögerung zugestellt werden.

Ich setze heute auf eine Kombination aus RBLs und Konformitätsprüfungen (per policyd-weight) - das schafft mir schon mal einen großen Teil des Spams vom Hals (ca 60%). Die restlichen 40% erschlage ich mit Spamassassin/Pyzor/Razor und ClamAV, die ein gemeinsames Scoring für die Mail ermitteln. Hochprozentiges und virulentes wird discarded bzw. in Quarantäne gesteckt (gebounced wird nur während des Zustelldialogs, falls policyd Bedenken anmeldet), und der Rest wird zugestellt. Spamassassin wurde (und wird kontinuierlich) von mir entsprechend gut trainiert; außerdem hab ich noch manuelle White-/Blacklists. Das Quarantäne-Verzeichnis prüfe ich regelmäßig auf false positives, die dann nachtrainiert werden.

Unterm Strich bin ich damit nahe einer Spam-Zustellquote von Null - auch False Positives hab ich nur ganz selten (ca. 1 von 1 mio geprüfter Mails). Allerdings ist mir durchaus bewusst, dass dieses System Grenzen hat. Heute habe ich pro Mailbox ca. 50 - 150 Spam-Mails pro Tag und Mailbox, die von Policyd nicht abgewiesen werden und durch SA & Co. aussortiert werden müssen. Damit bewege ich mich im Bereich einiger Tausend Mails pro Tag, die durch meinen nachgelagerten Filter geprüft werden müssen.

Sollte sich diese Zahl drastisch erhöhen, bekomme ich bei den aufwändigen Prüfungen einen heftigen Engpass - einmal wurde mein MTA mit über 50.000 Spam-Mails innerhalb einer Stunde überflutet; da kommt eine Mail-Body-Prüfung wie SA einfach nicht mehr nach.

Von daher sehe ich das Medium E-Mail durchaus als kritisch, was die Zukunftsfähigkeit anbelangt. Zumal andere Techniken zur Spambekämpfung momentan entweder noch gar nicht verfügbar, nicht einsatzreif oder noch gar nicht standardisiert sind... und meiner Einschätzung nach werden auch noch einige Jahre vergehen, bis alternative Verfahren wie DKIM einsatzbereit sind (sprich: auch passende und ausreichend getestete und zuverlässige Software existiert). Ein anderes Problem ist die Verbreitung. Mit SPF etwa stünde ein durchaus wirksames Mittel gegen die Spammerei zur Verfügung. Die Verbreitung ist aber noch dermaßen gering, dass es sich kein Mailserver-Admin leisten kann, bei der Konfiguration von einer flächendeckenden Nutzung auszugehen - dann bleiben nämlich nicht nur Spam-Mails draußen...

DomainKeys schaut nach einer Lösung aus, die die Nachteile von SPF umgeht und nicht nur Mailserver-"Berechtigungen" checkt, sondern gleichzeitig auch noch den Absender-Mailserver verifiziert ...


Wenn es dafür einfach einzurichtende Tools gibt, und die großen Provider ihre Mails ebenfalls damit signieren (große Firmen wie Amazon, eBay, T-Online, ...), dann könnte das schon ne effektive Möglichkeit werden ...

Derzeit gibt es keinerlei vernünftige Möglichkeit, DKIM einzusetzen - die Verbreitung ist noch zu gering ...


Warten wir mal ab, was noch so alles auf uns zukommt ...

antondollmaier wrote:Wenn es dafür einfach einzurichtende Tools gibt, und die großen Provider ihre Mails ebenfalls damit signieren (große Firmen wie Amazon, eBay, T-Online, ...), dann könnte das schon ne effektive Möglichkeit werden ...

Derzeit gibt es keinerlei vernünftige Möglichkeit, DKIM einzusetzen - die Verbreitung ist noch zu gering ...

Natürlich ist es nicht immer einfach, sich auf einen neuen Standard zu einigen. Aber wo inzwischen mehr Spam als normale E-Mails versandt werden, müssen große Firmen erhebliche Ressourcen zur Mailfilterung bereitstellen. Die Implementierung neuer Standards kann eigentlich nicht so viel kosten, wie durch Wegfall der Sortierarbeit eingespart werden könnte (+Traffic).

antondollmaier wrote:DomainKeys schaut nach einer Lösung aus, die die Nachteile von SPF umgeht und nicht nur Mailserver-"Berechtigungen" checkt, sondern gleichzeitig auch noch den Absender-Mailserver verifiziert ...

SPF und DKIM setzen an zwei recht unterschiedlichen Punkten bzw. Zuständen während des SMTP-Dialogs an und haben beide ihre Berechtigung. Ich würde daher eher von einer "sinnvollen Ergänzung" als von einer "Alternative" sprechen.

DKIM bietet einen Schutz vor "menschenlesbaren" Adressfälschungen in RFC2822-From-Headern, kann also primär "Social Engineering" verhindern. SPF dagegen sorgt für korrekte (oder leere) Envelope-Froms und "schützt" somit vor falschadressierten Bounces aus ansonsten vernünftig konfigurierten Quellen und greift, anders als DKIM, bereits vor der Übertragung des eigentlichen Nachrichteninhalts. Anders als es verschiedentlich propagiert wird, lassen sich Delayed Bounces (Autoresponder zählen auch dazu) in der Praxis außer in "minimalistischen" Umgebungen lediglich auf ein Mindestmaß beschränken, aber kaum vollständig verhindern; genau das wäre bei flächendeckender Verbreitung von SPF aber auch kein echtes Problem mehr.

Sprich: DKIM eignet sich eher für die Bewertung von E-Mails nach erfolgter Annahme, SPF für direktes Abweisen während des SMTP-Dialogs.

Verhältnis im Durchschnitt ca. 10 (SPAM) auf eine reguläre Mail :-(

Hi,

wie wäre es denn nach über 25 Jahren mal das neue E-Mail Protokoll weiter zu entwickelten und einfach mal anzufangen es auch Flächendeckend einzuführen. :-k

charlie

XMPP existiert.

War dir eigentlich langweilig, dass du dich Foren-archäologisch betätigt hast? ;)