Zugschlusbeobachtungen

Ursprünglich hat man in der Unix-Welt seine Mail direkt per SMTP auf dem Rechner empfangen, auf dem man die Mail später auch gelesen hat - nicht selten auf dem eigenen Arbeitsplatzrechner. Schließlich war im Internet ja jeder Rechner weltweit erreichbar, und wenn der eigene rechner auf den Namen quark lautete, war die mailadresse halt meine-userid@quark.example.com. Hat man einen neuen Rechner bekommen, änderte sich die Mailadresse.

Relativ schnell kamen dann "sprechende" Mailadressen vor oder nach dem @ hinzu. Über den im DNS eingetragenen MX-Record (MX = Mail-Exchange) konnten die Betreiber größerer Installationen für den Mailverkehr reservierte Systeme bekanntgeben, die Mail für einen bestimmten Domainnamen empfangen haben, ohne selbst so zu heißen. Diese Systeme haben dann die eingehende Mail entweder lokal zugestellt und für die Benutzer bereitgehalten, oder - wie früher - an den Arbeitsplatzrechner des Benutzers weitergeleitet.

Ausgehende Mail wurde weiterhin direkt von den Rechnern aus verschickt, auf denen der Benutzer auf "Senden" gedrückt hat und von diesen direkt beim MX der Zieldomain oder beim gleichnamigen Rechner eingeliefert.

Zusätzlich gab es noch "Mailrelays". Diese Systeme haben einfach jede eingehende Mail an den eigentlichen Empfänger weitergeleitet.

Dann kamen die Spammer, die diese offene Architektur zum Einliefern weitreichender Werbemail verwendet haben. Früher als Zeichen guter Nachbarschaft offen gehaltene Relays wurden von den Spammern ebenso fleißig missbraucht wie gutgläubig programmierte Webanwendungen.

Relays wurden geschlossen, Firewalls sprossen an allen Ecken aus dem Boden, die Benutzung von MX-Hosts wurde mangels direkter Erreichbarkeit der Arbeitsplatzrechner notwendiges muß. Gleichzeitig wuchsen die Ansprüche der Anwender im gleichen Maße wie ihr Wissen sank. So wurde es notwendig, die Mailsysteme zentral zu administrieren, weil der einzelne Benutzer gar nicht mehr in der Lage war, das Mailsystem seines Arbeitsplatzrechners eigenständig zu konfigurieren.

Und das sich immer weiter als Arbeitsplatzbetriebssystem durchsetzende Windows hatte gar kein eigenes, lokal laufendes Mailsystem mehr. Windows-Anwender waren somit zum Zugriff auf ein zentrales Mailsystem, bestehend aus Posteingangs- und Postausgangsserver gezwungen. Damit ein Anwender seine Mail von unterschiedlichen Arbeitsplatzrechnern lesen konnte, wurden hierfür neue Protokolle, das Post Office Protocol (POP3) und das Internet Message Access Protocol (IMAP) erfunden.

Für den Postausgang wurde damals wie heute sowohl für die Übertragung von Mails von Server zu Server im Internet wie auch für die Übertragung vom Arbeitsplatz des Benutzers zum Server (Client to Server) SMTP verwendet.

Doch nun genug der langatmigen Vorrede, denn um SMTP "Client to Server" soll es heute in diesem Artikel gehen.

Als es noch unüblich war, sich mit seinem Arbeitsplatzrechner frei durch die Welt zu bewegen, war der Betrieb eines Postausgangsservers einfach. Man hat einfach einen SMTP-Server installiert und sichergestellt, dass er nur Mails annimmt, die entweder

• an eine Adresse in einer der eigenen Domains adressiert ist und somit eingehende Mail ist oder
• von einer IP-Adresse des eigenen lokalen Netzes eingeliefert wurde und somit legitim ausgehende Mail ist.

Letztere Regel ist die wichtige, wenn man nicht zum Spamrelay werden möchte: Leitet man einfach alles weiter, haben die Spammer das offene Relay innerhalb von Nullkommanichts gefunden und prompt steht man - zu Recht - in den Blacklisten, aus denen man leicht wieder herauskommt und leider auch in denen, aus denen man nicht wieder so leicht oder gar schnell herauskommt.

Beschränkt man die Einlieferung auf eigene IP-Adressen, sitzt der Spammer immerhin im eigenen Netzwerk und man hat eine gewisse Möglichkeit, ihn mit dem LART zu bearbeiten, damit er seine Untaten abbricht und nicht wiederholt.

So hat es jahrelang prima funktioniert, bis die Internet-Hosting-Provider auf die Idee kamen, ihren Kunden auch Maildienste anzubieten und die Betreiber von Firmennetzen immer mehr vor die Aufgabe gestellt wurden, ihren Benutzern auch dann das Versenden von Mail zu erlauben, wenn sie mit dem Notebook unterwegs sind oder aus dem - mit dynamischer, sich ständig ändernder IP-Adresse angebundenen - Home-Office arbeiten.

Parallel dazu trat die erste Malware auf, deren Zweck war, befallene Arbeitsplatzrechner zum massenweisen Versand von Spam zu missbrauchen. Da es Spamfiltern natürlich schwer fällt, zwischen direkt von einem Arbeitsplatzrechner aus beim MX des Empfängers eingelieferter legitimer Mail und von einem Spam-Zombie versendeten Werbemail zu unterscheiden, begannen Mailempfänger, Mail mit Absender aus einem der bekannten IP-Adressbereichen, die von den großen ISPs an ihre Privatkunden vergeben wurden, nicht mehr zu akzeptieren. Parallel dazu stieg - insbesondere am angloamerikanischen Raum - der Druck auf die Accessprovider, Verbindungen aus ihren Endkundennetzen zu Port 25 von Servern in der Welt technisch zu unterbingen.

Einige Zeit lang hat man versucht, die Leute dazu anzuhalten, einfach den zu ihrem aktuellen Internetzugang gehörenden Postausgangsserver zu verwenden, denn diesen darf man ja benutzen, wenn man aus einem der "eigenen" Adressräume kommt. Das erzeugt aber Arbeit beim Anwender, der sich nach jeder Bewegung des Rechners einen neuen Postausgangsserver eintragen muss, und wurde außerdem durch die Habgier der Provider durchkreuzt, die auf die Verwendung ihrer eigenen Mailadressen bestanden, um die Mailadressen als Instrument zur Kundenbindung einsetzen zu können.

Schlaumeier kamen dann auf die Idee, "halboffene" Mailrelais anzubieten, die Mail "von überall" weiterzuleiten, wenn sie eine "passende" Absenderadresse haben. Wenn der Provider dann groß genug ist, reicht es einfach, so lange Absenderdomains durchzuprobieren, bis man eine Adresse gefunden hat, die dem Server genehm ist. Dieses Flickwerkverfahren hat sich bis weit in dieses Jahrtausend gehalten.

Während sich die Anwender zum Abholen von Mail schon seit Jahren mit Usernamen und Passwort am Server authentifizieren, liefen alle bisher genannten Wege zum Versand von Mail unauthentifiziert. Natürlich hat man sich dann Gedanken gemacht, wie man auch das Abliefern von Mail sowohl

• unabhängig vom Aufenthaltsort des Anwenders als auch
• nur schwer zum Spamversand zu missbrauchen

gestalten kann. In Ermangelung eines verbreiteten Standards kamen die Großprovider zu einer Krücke namens "SMTP-after-POP", bei der man seine Mail für eine bestimmte Zeit von der aktuell benutzten IP-Adresse einliefern darf, sobald man vorher einmal erfolgreich seine Mail authentifiziert per POP abgeholt hat. Das hat leidlich gut funktioniert; Problem war hier lediglich zum Beispiel das NAT von Studentenwohnheimen, deren IP-Adressen nahezu dauerhaft bei den Großprovidern freigeschaltet waren und somit den Spamzombies des Zimmernachbarn frei Bahn schaffte.

Die technisch korrekte Lösung heißt SMTP AUTH, bei der in jeder SMTP-Session erneut ein Username und ein Passwort übermittelt wird. Ca 100 % der heute gebräuchlichen für private Enduser geeigneten Mailclients nutzt SMTP AUTH. Diese SMTP-Erweiterung muss serverseitig konfiguriert werden und kann sogar im Mischbetrieb mit der Server-zu-Server-Kommunikation betrieben werden.

Bei den beiden gängigsten Verfahren, sich mit SMTP AUTH zu authentifizieren (LOGIN und PLAIN), wird das Passwort unverschlüsselt übertragen. Beim weniger weit verbreiteten Verfahren CRAM-MD5 ist das Passwort auf der Leitung gehashed, muss dafür aber sowohl auf der Client- als auch auf der Serverseite unverschlüsselt zur Verfügung stehen. In allen Fällen werden die eigentlichen Daten unverschlüsselt übertragen und stehen einem gezielten Angriff jederzeit offen, und zwar auf der vorhersagbaren Strecke zwischen dem Client und dem Postausgangsserver. Das macht das gezielte Mitlesen besonders einfach.

Daher ist empfehlenswert, wenigstens die Kommunikationsstrecke zwischen Server und Client zu verschlüsseln, wenn man schon keine Ende-zu-Ende-Verschlüsselung des Mailinhalts wie GnuPG oder SMIME einsetzen möchte. Auf diese Weise sind nicht nur die Zugangsdaten auch bei den "einfacheren" Authentifikationsverfahren wie PLAIN oder LOGIN, sondern auch die Inhalte der übertragenen Mails geschützt.

Dass die Mail dann trotzdem ohne Ende-zu-Ende-Verschlüsselung unverschlüsselt auf der Platte des Servers landet und sehr wahrscheinlich auch unverschlüsselt weiter übertragen wird, darf hier nicht unerwähnt bleiben.

Gängig für die Aktivierung der Verschlüsselung ist inzwischen, nachdem auch Microsoft den Weg der Tugend eingeschlagen hat, die SMTP-Erweiterung STARTTLS. Hierbei wird nach einer normal aufgebauten Klartext-SMTP-Verbindung durch das Kommando STARTTLS in den verschlüsselten Modus umgeschaltet, das Serverzertifikat übertragen und die Verbindung dann - diesmal verschlüsselt - neu begonnen.

Microsoft hat jahrelang einen nicht standardisierten Alleingang auf dem nicht an Microsoft vergebenen TCP-Port 465 durchgezogen. Dafür mögen diejenigen, die dies zu verantworten haben, bitte in interessanten Zeiten leben.

Die meisten Clients lassen sich konfigurieren, dass sie auf einer verschlüsselten Verbindung bestehen, bevor sie die Zugangdaten übermitteln; der Default ist oftmals, nach dem Fehlschlagen der verschlüsselten Verbindung wie bei der Server-zu-Server-Kommunikation auf die unverschlüsselte Kommunikation zurückzufallen. Das will man nicht, bitte abschalten.

Manche Server erzwingen ihrerseits - eigentlich standardwidrig - die verschlüsselte Kommunikation für authentifizierte Verbindung, indem sie vor dem Umschalten auf verschlüsselte Kommunikation ihre Fähigkeit zur Authentifikation nicht anbieten. Glücklicherweise gibt es kaum einen Mailclient, der in diesem Fall die Verbindung abbricht. Ordentliche Mailclients geben in ihrer Verbindung trotzdem das Kommando STARTTLS; der Server gibt dann zu, dass er SMTP AUTH beherrscht und alles ist fein.

Bleibt noch das Problem der oben erwähnten Provider, die den Port 25 aus ihren Enduser-Netzen sperren. Dafür hat sich SMTP submission etabliert. Dabei lauscht ein Mailserver zusätzlich zum Port 25 auch auf Port 587. Standardkonforme Mailserver sprechen auf Port 587 genau dasselbe SMTP wie auf Port 25, mit dem Unterschied dass auf Port 587 Mail überhaupt nur nach erfolgreicher Authentifikation angenommen wird.

Port 587 wäre eine gute Lösung für alles, wenn nicht mein Lieblings-ISP mit Spezialeigenschaft "den Supportaufwand für andere maximieren, hauptsache der eigene ist niedrig", die Deutsche Telekom, sich nicht eine besondere Perversion hätte einfallen lassen. Mindestens eine Baureihe der Speedports (das ist südpolinesisch für 'Drecksteil, niemals freiwillig nehmen, auch nicht geschenkt') hat eine Liste mit "Sicheren E-Mail-Servern", auf denen die großen Anbieter stehen, aber der eigene kleine Server natürlich nicht. Und wer nicht auf dieser Liste steht, wird noch im Router gedroppt. Ja, auch Port 587. Und dreimal dürft ihr raten, wen dann die Anwender anbrüllen, weil Mail nicht geht. Der Routerlieferant ist es jedenfalls nicht.

Zusammengefasst ist der Stand der Technik für die Client-zu-Server-Kommunikation für den Postausgang:

• SMTP AUTH
• STARTTLS sowohl client- als auch serverseitig erzwungen
• auf Port 587

Hier noch ein Beispiel für das erfolgreiche Abliefern einer Mail per SMTP AUTH über STARTTLS:

[1/5120]mh@swivel:~ $ swaks --tls --server torres.zugschlus.de --auth --to mh+blogdemo20170314@zugschlus.de --port 587
Username: mh+blogtest20170314
Password: <redacted>
=== Trying torres.zugschlus.de:587...
=== Connected to torres.zugschlus.de.
<-  220 torres.zugschlus.de ESMTP Exim 4.84_2 Tue, 14 Mar 2017 20:24:57 +0100
 -> EHLO swivel.zugschlus.de
<-  250-torres.zugschlus.de Hello swivel.zugschlus.de [2a01:238:4071:3202::1f]
<-  250-SIZE 104857600
<-  250-8BITMIME
<-  250-PIPELINING
<-  250-STARTTLS
<-  250 HELP
 -> STARTTLS
<-  220 TLS go ahead
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/CN=torres.zugschlus.de"
 ~> EHLO swivel.zugschlus.de
<~  250-torres.zugschlus.de Hello swivel.zugschlus.de [2a01:238:4071:3202::1f]
<~  250-SIZE 104857600
<~  250-8BITMIME
<~  250-PIPELINING
<~  250-AUTH PLAIN LOGIN
<~  250 HELP
 ~> AUTH LOGIN
<~  334 <redacted>
 ~> <redacted>
<~  334 <redacted>
 ~> <redacted>
<~  235 Authentication succeeded
 ~> MAIL FROM:<mh+blogtest20170314@zugschlus.de>
<~  250 OK
 ~> RCPT TO:<mh+blogdemo20170314@zugschlus.de>
<~  250 Accepted
 ~> DATA
<~  354 Enter message, ending with "." on a line by itself
 ~> Date: Tue, 14 Mar 2017 20:24:30 +0100
 ~> To: mh+blogdemo20170314@zugschlus.de
 ~> From: mh+blogdemo20170314@zugschlus.de
 ~> Subject: test Tue, 14 Mar 2017 20:24:30 +0100
 ~> Message-Id: <20170314202430.027756@swivel.zugschlus.de>
 ~> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
 ~>
 ~> This is a test mailing
 ~>
 ~> .
<~  250 OK id=1cns41-0007EM-TY
 ~> QUIT
<~  221 torres.zugschlus.de closing connection
=== Connection closed with remote host.
[2/5121]mh@swivel:~ $
</pre>


Wir beachten hier insbesondere beim Verbindungsaufbau, dass der Server am Kommando EHLO des Clients im Gegensatz zum klassischen HELO ankündigt, was er alles kann, und dass in der ersten Liste vor Beginn der Verschlüsselung die Zeile "250-AUTH PLAIN LOGIN" fehlt. Damit möchte der Server verhindern, dass ein unsicher konfigurierter Client ihm die sensiblen Zugangsdaten vor dem Umschalten auf die verschlüsselte Kommunikation unverschlüsselt um die Ohren bläst. Tut der Client dies, ohne dass der Server angesagt hat, dass er AUTH beherrscht, ist dem Client nicht mehr zu helfen.

Hinte der Zeile "TLS go ahead" führen die Systeme erstmal den üblichen TLS-Handshake aus, bevor dann die hier im Klartext gezeigte Kommunikation über den nun verschlüsselten Kanal stattfindet.

Der Client sagt ein zweites Mal EHLO und bekommt diesmal eine andere Liste an Capabilities vorgesetzt: STARTTLS ist nicht mehr dabei, da die Verbindung schon verschlüsselt ist, dafür verrät der Server diesmal, dass er AUTH unterstützt. Der Client macht dann auch SMTP AUTH und kann nach der erfolgreichen Authentifikation die Mail übermitteln, wie es auch ein Server täte.

P.S.: Ich bin mir bewusst, dass die korrekten Begriffe für das, was ich hier als Spam (klein geschrieben, SPAM ist eine Handelsmarke von Hormel Industries für Frühstücksfleisch) bezeichne, eigentlich Unsolicited Commercial/Bulk E-Mail (UCE/UBE) lauten. Die Begriffe werden inzwischen anders verwenden, und ich möchte den Leser dieses doch sehr technischen Artikels nicht verwirren.