Spamabwehr: SPF und Greylisting

Vor ein paar Monaten hab ich testweise SPF und Greylisting auf meinem Mailserver aktiviert. Doch, was ist das?

Fangen wir mit dem einfacheren von beidem an:

Was ist Greylisting?

Beim Greylisting werden einkommende E-Mails erstmals mit einem temporären Fehler abgewiesen. Versucht es der absendende Mailserver nach ein paar Minuten nochmals, wird die E-Mail akzeptiert (ich hatte dafür als Wartefrist mindestens 10 Minuten eingestellt). Dann wird der Mailserver auf eine Art Whitelist gesetzt (bzw. seine IP-Range, je nach Einstellung), auf der er auch bleibt, so lange er nicht 14 Tage am Stück keine E-Mails an meinen Server gesendet hat.

Die „Erfindung“ des Greylistings basierte auf der Annahme, dass Spammer es nicht nochmals versuchen, die Mail zuzustellen. Früher war das wohl auch richtig, Heute ist der Anteil an erfolgreich abgewehrten Spamnachrichten aber doch eher klein geworden, weil die meisten Spammer „vollwertige“ Mailserver einsetzen, die es auch wieder versuchen..

Es wurden zwar ein paar Spams abgewehrt, im Gegenzug verzögert sich aber auch die E-Mail Zustellung, sofern der Absender in letzter Zeit keine Nachricht an mich gesendet hat. Es nervt einfach auf Dauer, wenn man sich irgendwo Forum anmeldet, die Bestätigungsmail 10 bis 15 Minuten brauch und man in seinen Logddateien sieht, dass sein Greylisting daran schuld ist. Das wiegt die „paar“ abgewehrten SPAM Nachrichten nicht auf. Zu allem Übel nutzen Spammer heutzutage auch gerne mal gehackte Mailaccounts. Da bringt Greylisting auch nichts.

 

Die zweite „Nettigkeit“ die ich getestet habe war SPF.

Was ist SPF?

Für SPF erstellt man unter seiner Domain einen weiteren DNS Eintrag vom Typ TXT und dem Inhalt, welche IP-Adressen für diese Domain E-Mails absenden dürfen.

Der Eintrag sieht für mich so aus:

v=spf1 ip4:83.169.40.215 -all

spf1 steht für die SPF Version 1, das im Moment gebräuchliche. Danach folgt die IPv4 Adresse von meinem Server, dass dieser E-Mails in meinem Namen (also für Absender innerhalb meine Domain) absenden darf und ein „-all“. Letzteres heißt, dass sonst absolut kein anderer Mailserver E-Mails für die Domain vthadden.de verschicken darf. Ein Empfangender Mailserver prüft nun beim Erhalt von E-Mails, ob für diese Domain ein SPF Eintrag besteht, wertet ihn aus und befolgt ihn hoffentlich.

Statt „-all“ gibt es noch „~all“ und „?all“. „-“ heißt Hardfail, E-Mails ablehnen; „~“ steht für Softfail, in dem Fall würde es bedeutet dass die E-Mail wahrscheinlich nicht richtig ist, was damit passiert ist mir aber egal; „?all“ steht für „mir egal, wer was verschickt“, also wie wenn kein Eintrag gesetzt wäre.

Wie ihr schon seht: der Empfangende Mailserver muss SPF unterstützen, auswerten und auch befolgen. Machen viele aber nicht.

Google setzt SPF z.B. ein, mit einem „?all“ am Ende, also setzen sie es praktisch doch nicht ein. Bei eingehenden E-Mails werten sie den Eintrag aus und ignorieren das Ergebnis. Eigentlich müssten sie E-Mails ablehnen, die als Absender meine Domain haben aber nicht von meinem Server kommen. Tun sie aber nicht, eben nochmals von anderen Servern aus getestet, die E-Mail wird zugestellt.

web.de hat keinen SPF Eintrag, 1und1 nutzt aktuell ~all.

gmx.de hat einen SPF Eintrag, sogar mit -all, sie nutzen SPF also in diesem Sinne schonmal. Eingehende E-Mails von meinem DSL Anschluss werden schonmal direkt abgewiesen (bzw die Verbindung sofort getrennt), eine E-Mail von einem anderen Server aus wird aber angenommen und im SPAM Ordner abgelegt. Das wäre bei einem Softfail („~all“) akzeptabel, entspricht aber nicht dem bei einem Hardfail definierten verhalten, so ganz scheinen sie sich nicht zu trauen.

Selbst aol.com, die in Sachen Spambekämpfung einen eigenartigen Ruf haben hat ein „?all“ im DNS Eintrag. Von breiter Akzeptanz kann man wohl nicht sprechen. Paypal.com hat ein „~all“ eingetragen.

Manche Domains haben zwar ein -all eingetragen, aber deutlich mehr Hosts (IP-Adressen) erlaubt als meine Software auswerten konnte, wodurch die E-Mail auch abgewiesen wurde, twitter.com fällt z.b. hierunter, ob das Problem nur bei dem von mir benutzten ‚tumgreyspf‘ auftritt oder auch bei anderen Programmen weiß ich nicht.

Wo ist jetzt der Knackpunkt bei SPF?? Bei E-Mail Weiterleitungen. Theoretisch könnte/sollte man dafür den Absender umschreiben (indem man z.b. einen Envelope-From benutzt)

Ich habe z.b. noch eine E-Mail Adresse bei GMX, welche ich mir auf meinen Server weiterleiten lasse. GMX ändert aber den Absender nicht einwandfrei, wodurch z.b. eine weitergeleitete E-Mail von PayPal (ihr erinnert euch „-all“) abgewiesen wurde, weil GMX nicht authorisiert ist E-Mails für PayPal abzusenden.

Afterbuy versendet seine E-Mails z.b. im Namen und mit dem Absender des Shops, der afterbuy nutzt. Hat dieser eine GMX Adresse wird diese E-Mail mit hoher Wahrscheinlichkeit auch abgewiesen, jenachdem wie das „~all“ interpretiert wird.

Dies sind jetzt nur 2 Beispiele die ich auf Anhieb (also ohne große Suche) in meinen Logdateien gefunden habe. Weitere würde ich sicher finden.

Eine weitere mögliche Fehlerquelle sind natürlich noch falsche DNS einträgt, die man z.B. nach einem Serverumzug nicht korrigiert oder ergänzt.

Also gilt für SPF (in meinem Falle) das Gleiche wie für Greylisting: Ja, es kann Spam abwehren, im Gegenzug kann es aber auch erwünschte E-Mails blockieren. Die paar False-positives (fälschlicherweise abgewiesene Mails) die ich hatte, waren aber trotzdem ärgerlich, sie kamen zwar durch falsche Konfiguration anderer Mailserver zustande, treffen mich aber trotzdem.

Fazit:

Greylisting hat früher viel gebracht, heute überwiegen aber die Nachteile. SPF ist im Ansatz zwar „schön“, weil man damit einschränken kann, wer in wessen Namen E-Mails veschicken darf, in der Praxis ist es aber entweder schlecht implementiert oder garnicht eingerichtet. Auch hier überwiegen im Moment die Nachteile.

Ich für meinen Teil bleibe weiterhin aus der Kombination von ix-DNS Blacklist und Spamassassin, den ich aus meinem Spamordner regelmäßig anlerne. Diese beiden „Hürden“ leisten bei mir seit langer Zeit eine gute Arbeit, verbessern kann man da wohl nicht mehr sehr viel ohne mehr False-positives zu bekommen (diese bewegen sich im Moment irgendwo im Promille Bereich).

SMTP Ports 25 und 587

Wenn man jemandem nach dem SMTP Port fragt ist die Antwort meistens „25/tcp“. Manchmal hört man noch „465/tcp“ für SMTPS. Der Port darf dafür aber eigentlich nicht mehr verwendet werden (seit 1998), stattdessen soll STARTTLS über den normalen SMTP Port verwendet werden.

Seit einigen Jahren wird bei manchen ISPs, wenn man eine Einwahlverbindung (wie z.B. DSL) nutzt, der Port 25 für Verbindungen gesperrt, bekannt hierfür ist unter Anderem die Telekom. Diese Anbieter sperren bei Verdacht auf den Spamversand den Port 25 für ausgehende Verbindungen einzelner DSL Anschlüsse. Wie dies überprüft wird weiß ich nicht.

Als neuer Port für entsprechende Client zu Server Verbindungen wurde der Port 587/tcp definiert. Der Dienst hierzu heißt „Submission“ und sieht laut RFC 2476 die Authentifizierung der User vor. Dies heißt, dass jegliche Server zu Server Verbindungen weiterhin über Port 25 erfolgen, die Clients sich aber auf Port 587 verbinden müssen/sollen.

Wie hier berichtet will Südkorea nun für „Endkunden“ den Port 25 sperren. Sie Planen ähnliche Sperren wie bei der Telekom, die Server zu Server Kommunikation soll weiterhin über Port 25 laufen. Die Sperre soll den Versand von Spamnachrichten erschweren. Hier für muss man sich überlegen wie der E-Mail Versand normalerweise abläuft.

Der Enduser der eine E-Mail versenden will sendet diese z.b. mittels Thunderbird. Thunderbird verbindet sich auf den Mailserver des Anbieters von dem man eine E-Mail Adresse hat (bei mir ist es mein eigener Server), authentifiziert sich mit Usernamen und Passwort und reicht die E-Mail Weiter. Der Mailanbieter ist in dem Fall der Smart Host bzw. das Relay welches die Nachrichten weiterleitet.. Er nimmt die E-Mail an, schaut an wen sie zugestellt werden soll und verbindet sich mit dem Mailserver des Zielanbieters (z.b. gmx, gmail und co). Dieser Server nimmt die E-Mail nun ohne Authentifizierung an, da er für die Zieldomain zuständig ist und stellt die E-Mail nun lokal zu.

Das Grundprinzip ist also: Für Nachrichten die an andere Mailserver weitergeleitet werden sollen sollte man sich authentifizieren. Ist der Mailserver aber für die Zieldomain zuständig ist keine Authentifizierung notwendig und die E-Mail wird direkt angenommen. Meistens werden noch weitere Dinge, wie IP-Adresse und Domain des Absenders überprüft (ob der DNS richtig eingetragen ist) bzw. auch die IP-Adresse mit einer Blacklist abgeglichen.

Welche Wege gibt es nun Spamnachrichten zu versenden:

– Normale, virenverseuchte, PCs die direkt Verbindungen mit des Zielservern herstellen und die Spamnachrichtenversenden

– gehackte/verseuchte Server bzw. fehlerhaft konfigurierte Server, die Nachrichten direkt zustellen

– gehackte Useraccounts bei Mailhostern

Das Sperren von Port 25 greifen effektiv nur bei der ersten Gruppe. User die Einwahlverbindungen benutzen können bei entsprechenden Sperren E-Mails nicht direkt zustellen sondern dafür einen Smart Host verwenden, z.B. den ihres Mailanbieters. Der normale Internetuser macht dies auch so, er würde bestenfalls wahrscheinlich nichts von den Sperren mitbekommen, sofern er seinen E-Mail Client richtig konfiguriert hat und den Port 587 zur SMTP Kommunikation einsetzt. Bietet der Mailanbieter den Versand über den Port 587 nicht an, bleibt nur noch der (veraltete) Port 465 für SSL, welcher meistens auch unterstützt wird. Der Virus auf dem Rechner versucht dagegen die Zielsysteme zum Zustellen der Spamnachrichten direkt zu erreichen und wird durch die Sperre davon abgehalten. Die Kommunikation über Port 587 sollte nicht möglich sein, da auf dem Port grundsätzlich eine Authentifizierung vorgesehen ist. Hier setzen allerdings auch schon DNS Blacklisten an, die häufig entsprechende IP-Adressbereiche die zur dynamischen Vergabe vorgesehen sind bzw. Spamnachrichten versenden listen, wodurch Mailserver unautorisierte E-Mails von entsprechenden IP-Adressen nicht annehmen sollten.

Die zweite Gruppe kann man damit nicht blockieren. Hier hilft nur der Ansatz der DNS Blacklisten, der auch schon bei Gruppe 1 hilft. Falsch konfigurierte Server nehmen von unautorisierten Usern nicht nur E-Mails zur lokalen Zustellung an sondern leiten diese auch ohne Authentifizierung an andere Mailanbieter weiter.

Die dritte Gruppe der Absender kann man als Zielsystem der Spamnachricht bisher nicht effektiv blocken. Für alle Beteiligten ist die Nachricht nicht ohne weiteres von einer legitimen Nachricht zu unterscheiden. Hier ist man auf die Kooperation der Mailanbieter angewiesen, bei denen der gehackte Account registriert ist.

Die RFC für Port 587/tcp sieht ausdrücklich vor, dass auf diesem Port nur von autorisierten Benutzern Nachrichten angenommen werden sollen, eine Server zu Server Kommunikation soll hierüber nicht erfolgen. Ein richtig konfigurierter Mailserver sollte sich hieran auch halten, fehlerhaft konfigurierte Server sind aber immer noch ein Problem. Die Chance, dass ein Admin den Port 587 genauso falsch (also komplett ohne Authentifizierung) konfiguriert wie schon den Port 25 ist durchaus gegeben. Hier helfen also wieder „nur“ Blacklists.

Eine Sperre des Ports 25 für Client zu Server Verbindungen ist nicht selten, von daher auch nicht weiter tragisch. Server zu Server Verbindungen darüber auch zu sperren würde allerdings keinen Sinn machen. Einerseits weil man damit gegen die RFC verstößt, andererseits weil Spammer nicht so unflexibel sind wie manch einer vermutet und rasch auf andere Ports ausweichen würden. Die Server zu Server Verbindung auch mit Passwörtern abzusichern ist nicht machbar. Weitere Sicherungsmaßnahmen zum Authentifizieren des Absenders werden zwar teilweise eingesetzt, meistens funktionieren sie aber nicht richtig oder sind nur halbherzig implementiert wodurch sie größtenteils nutzlos sind. (Oh, ich dachte den Beitrag dazu hätte ich schon veröffentlicht.)

Es bleibt abzuwarten, wie groß der Effekt der Portsperren beim Spamaufkommen sein wird. Ich selbst erwarte mir hiervon keinen merklichen Unterschied. Die meisten der ankommenden Spamnachrichten werden bei mir durch die NiX Spam DNSBL (Infos hierzu). Die wenigen Nachrichten, die es zum Spamassassin schaffen, kommen meistens von gehackten Useraccounts, hier werden die Sperren keinen Unterschied machen.

Nachtrag: Wenn man keine DNSBL verwendet kommt natürlich mehr Spam durch. Es gehen also schon noch einige direkt über Einwahlanschlüsse raus, so gesehen würde durch eine Sperre von Port 25 das Problem schon etwas abgeschwächt werden. Der Großteil der Nachrichten kommt aber eher von falsch konfigurierten Servern und von gehackten Useraccounts.

Captcha

Lange Zeit hatte ich keinerlei Sicherheitsmaßnahmen beim Kommentieren aktiviert. Man musste lediglich Name und E-Mail Adresse hinterlassen.

Jeder der selbst bloggt wird wissen: SPAM ist auch bei Kommentaren sehr beliebt. Es bringt den Spammern zwar nicht viel (sofern die Suchmaschine das Attribut rel=“nofollow“ auswertet) aber sie tun es trotzdem. Heute kam im Schnitt alle 2 Minuten ein neuer SPAM-Kommentar dazu, zwischenzeitlich hatte ich deswegen bei Artikeln die älter als 14 Tage sind die Kommentarfunktion deaktiviert.

Da aber doch mehr Besucher über Google auf alte Beiträge kommen, als ich dachte, ist das wahrscheinlich keine so gute Idee; vielleicht will von denen ja jemand etwas hinterlassen.

Von daher habe ich nun ein kleines Captcha aktiviert, ob es auf Dauer nützlich ist wird sich zeigen. Wichtig war mir, dass es kein externes Captcha ist, welches Daten von einem anderen Server laden muss. Wenn es sich aber als nutzlos herausstellt wird es wohl oder übel ein externes werden müssen (während ich diesen Beitrag schreibe, kam jedenfalls kein neuer SPAM-Kommentar rein, toi toi toi 🙂 )