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.