Netz - Rettung - Recht

Vor einem Jahr hatte ich darüber berichtet, dass sich viele Probleme bei der Mailauslieferung an Google schlicht durch den Verzicht auf IPv6 für den Mailversand beheben lassen, und dafür auch eine Lösung vorgestellt. Diesen Weg würde ich aber nicht mehr empfehlen.

Die Verwendung eines eigenen Routers wird in vielen Fällen ein gangbarer Weg sein; er ist aber unnötig komplex und kann Schwierigkeiten aufwerfen, wenn es weitere Router für Spezialfälle gibt - denn dann wird ggf. nur der andere Router durchlaufen (oder der Router für “Mailauslieferung an Google über IPv4”, aber nicht der Router für den anderen Spezialfall).

Man munkelt, dass insbesondere Google eingehende E-Mails unterschiedlich streng filtert, je nachdem, ob sie per IPv6 oder per IPv4 eingeliefert werden.

Google selbst deutet das in seinen Bulk Senders Guidelines durch den Abschnitt Additional guidelines for IPv6 an, und ich hatte verschiedentlich den Eindruck, dass E-Mail, die ich an Adressaten bei Google (GMail, Hosting, …) versende, dort jedenfalls nicht in der Inbox landet. Für Mails an GoogleGroups - die u.a. Mailinglisten mit einem Webinterface und Webarchiv darstellen - kann ich das sogar positiv belegen: versende ich E-Mails über IPv6 nach dort, werden sie zwar lt. Logfile angenommen, dann aber offensichtlich ausgefiltert. Jedenfalls erscheinen sie nie in der GoogleGroup, auch nach mehreren Versuchen und mehreren Tagen nicht. Versende ich dieselbe Mail aber über IPv4, trifft sie binnen Sekunden ein.

Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …

Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option "use_shell", die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a user’s filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

Schon seit vielen Jahren verwende ich eine Subdomain zur Vergabe von personalisierten E-Mail-Adressen, die ich dann für Zwecke verwenden kann, bei denen ich meine normale E-Mail-Adresse nicht preisgeben möchte, bspw. das Abonnieren von Newslettern, an deren Seriösität ich Zweifel habe, für Webshops etc. pp. Das hat den Vorteil, daß sich über diese personalisierten E-Mail-Adressen nachvollziehen läßt, aus welcher Quelle bspw. Spammer ihre Adressen bezogen haben, und, viel wichtiger, daß sich diese Adressen rückstandslos entsorgen lassen, wenn sie missbraucht werden. Insgesamt eine gute Idee; die Frage ist immer nur, wie man sich diese Adressen erzeugt.

Meine erste Lösung war ein Catch-All, was aber den Zweck der Übung letztlich konterkarierte, weil man auf diese Weise eine unbegrenzte Anzahl valider E-Mail-Adressen erzeugt und Spam potentiell potenziert. Zwar kann man bestimmte Adressen selektiv deaktivieren, bspw. über eine Aliases-Datei, in der sie explizit geerdet werden und ein Catch-All als Fallback für nicht explizit definierte Adressen verwendet wird, aber Spammer permutieren Adressen gerne; wenn man abashop@domain.example deaktiviert, bekommt man stattdessen vielleicht Mail an abasho@domain.example und an abash@domain.example und an … So hat sich das nicht bewährt.

Also habe ich die Adressen stattdessen in einer Aliases-Datei explizit definiert (und für eine Übergangszeit doch einen Catch-All als Fallback verwendet, für den Fall, daß ich eine bereits verwendete Adresse vergessen hatte …). Das tat etliche Jahre seinen Zweck, hatte aber den Nachteil, daß ich mich für Änderungen immer erst auf dem entsprechenden Host einloggen und die Datei ändern mußte. Unbequem und, wenn man gerade unterwegs ist und nur Webzugriff hat, erst gar nicht möglich. Also habe ich reichlich oft doch meine Hauptadresse für diverse Anmeldungen verwendet; diesen Nachteil gab es bei der Verwendung des Catch-All nicht.

Die Lösung wäre - so war mir ebenfalls seit langer Zeit klar - die Verwendung eines bequemen, nach Möglichkeit webbasierten Interfaces zur Anlage neuer solcher Adressen, damit der innere Schweinehund nicht mehr dazwischenkommen kann. Und diese Lösung habe ich jetzt endlich umgesetzt. Zumindest provisorisch, aber das wird vermutlich wieder so ein langlebiges Provisorium werden …