Netz - Rettung - Recht

Meine Homepage hat noch ein Kontaktformular. Selbstverständlich findet sich auf derselben Seite auch meine Mailadresse (samt GPG-Key), und man sollte annehmen, dass das der übliche Weg zur Kontaktaufnahme wäre, aber überraschend viele Nachrichten erreichen mich dann doch noch über das Kontaktformular. Dafür mag es verschiedene Gründe geben: der Mailclient auf dem Arbeitsrechner (oder dem Smartphone) hat vielleicht kein Profil mit der gewünschten Absenderadresse - oder für den Absender ist “E-Mail” gleichbedeutend mit “GMail” oder einem anderen webbasierten Dienst, d.h. es wird gar kein Mailprogramm mehr verwendet. Sei dem, wie dem sei - das Kontaktformular wird (trotz Recaptcha) durchaus genutzt, und ab und an verschluckte es sich an unerwarteten Eingaben. Gerne genommen war beispielsweise ein Komma im Eingabefeld für den Namen (“Müller, Egon”). Da das Formular die Eingabe einfach 1:1 in das From:-Feld übernommen hat, fand sich da dann etwas wie

Müller, Egon <absender@domain.example>

Das aber gefällt der Technik nicht, denn ein , trennt im From: oder To: mehrere Absender/Adressaten voneinander. Soll im Namen ein Komma vorkommen, muss der gesamte Name in " gesetzt werden.

Heute möchte ich mal über ein - primär technisches - Thema schreiben, dass ich schon seit drei Jahren hier im Blog (immer zum Jahreswechsel) anspreche, aber noch nie umfassend ausformuliert habe: mein Mailsetup, bzw. über das historisch gewachsene Chaos in diesem Bereich, das ich gerne auflösen würde. Am Rande geht es auch ein bisschen um Usenet-News, aber das ist nicht das Thema, das mich primär umtreibt, und kann getrennt betrachtet werden.

Ich möchte das (umfangreiche und in Einzelaspekten vielfach miteinander verknüpfte) Thema gerne - wie schon im Titel angekündigt - in drei Schritten angehen: Wie hat sich mein Umfang mit News und Mail über die letzten zweieinhalb Jahrzehnte entwickelt? Wie sieht mein Setup heute aus? Und wo möchte ich hin, was sind meine Vorstellungen für die Zukunft? (Das ist dann der Teil, wo ich konzeptionellen Rat und konkrete Software-Empfehlungen suche und dankbar für Berichte über eigene Lösungen bin, in der Hoffnung, dass der Knoten bei mir irgendwann einmal platzt.)

Ursprünglich wollte ich zwei verschiedene Beiträge verfassen: einmal den historischen Rückblick, und dann getrennt davon die konkreten Vorstellungen und Fragen für die Zukunft, um gezieltes Feedback und Tipps zu ermöglichen. Nun ist es doch ein einziger, langer Beitrag geworden. Wer Zeit und Lust hat, Reminiszenzen aus den letzten mehr als 20 Jahre zu lesen, der fängt vorne an; wer keine Zeit oder Lust hat, der kann (tl; dr) direkt zu meinen konkreten Vorstellungen und Fragen springen.

So lange ich ein Smartphone nutze, so lange verwende ich auch die App mit dem seltsamen Namen K-9 als Mailclient. Das Programm ist stabil und bietet mir alles, was ich brauche: ich kann theoretisch mehrere Accounts konfigurieren, ich kann entscheiden, welche Verzeichnisse angezeigt und synchronisiert werden sollen und ich kann mir verschiedene Profile anlegen. IMAP-Push funktioniert (mehr oder weniger), und TLS ist natürlich auch kein Problem.

Mir war gar nicht aufgefallen, dass es rund um K-9 einigermaßen still geworden war - erst Ende Juli wurde ich darauf aufmerksam, dass mit der Version 5.800 das erste Update seit etlichen Jahren ansteht, das zugleich eine Änderung der Oberfläche mitbringt und auf aktuellen Android-Versionen problemloser läuft, insbesondere im Hinblick IMAP-Push (das seit Android 6 (!) wohl Probleme machte).

Wie bereits berichtet verliere ich meine bisherige “Haupt-E-Mailadresse” und muss daher bei einer Vielzahl von Accounts die dort hinterlegte Adresse ändern. Diese Aufgabe bin ich lieber direkt und noch vorletzte Woche während meines Urlaubs angegangen. Wie erwartet verlief das meistens reibungslos, aber beileibe nicht immer; es gab eine ganze Reihe … eher skurrile Erfahrungen.

Insgesamt weist mein Passwortmanager mehr als 300 Accounts auf, und bei der weit überwiegenden Mehrzahl stand die verwendete Mailadresse zur Änderung an. Ohne Passwortmanager wäre die Aufgabe vermutlich unlösbar gewesen … So konnte ich mit den wichtigsten Accounts (Google, Microsoft, Dropbox, Github …) anfangen und mich dann systematisch durch die Vielzahl wichtiger oder weniger wichtiger Accounts bei einer Unzahl von Diensten, Webshops, Publikationen u.a. kämpfen.

That which we call a rose by any other name would smell as sweet.

Nachdem ich zukünftig auf meine altgewohnte, liebgewonnene Mailadresse thh@inter.net verzichten werden muss, habe ich wenigstens eine gleichermaßen kurze und gut zu merkende neue Adresse gefunden: thh@thh.name wird es zukünftig sein.

[Nachträglich veröffentlicht im Mai 2021.]

Vor recht genau 18 Jahren, im August 2002, stieß ich auf ein interessantes Angebot des Berliner Providers snafu, dessen Name mir aus dem Usenet-Umfeld grundsätzlich bekannt war. Seit Juli 2000 war das unter diesem Namen auftretende Privatkundengeschäft der Interactive Networx GmbH & Co KG auf die Inter.net Germany GmbH übergegangen; das entsprach dem Vorgehen der Muttergesellschaft PSINet Inc., die auch in anderen Ländern ihr Privatkundengeschäft auf die Inter.net Ltd. übertragen hatte. Und es gab für schmales Geld die Möglichkeit, dort eine providerunabhängige E-Mail-Adresse unterhalb der Domain inter.net zu erhalten. Das war mir sehr recht: eine interessante Domain, mein Kürzel thh war noch verfügbar, und ich musste mir weder um Spamfilterung noch um die Verfügbarkeit der Mailadresse Sorgen machen. Zwar hatte ich mir im Juni 2002 meinen ersten “Rootserver” geleistet, aber das war mir für meine hauptsächliche Erreichbarkeit noch zu unsicher.

Seitdem habe ich thh@inter.net zunächst primär im Usenet - und als Kontaktadresse auf Webseiten - genutzt, zunehmend aber als meine Haupt-E-Mailadresse: leicht zu merken, schnell zu tippen, leicht zu diktieren - viel angenehmer, als für jeden neuen Account in irgendeinem Onlineshop eine spezifische Adresse neu anzulegen. Und so trat ich öffentlich mit der Zeit nur noch unter dieser Adresse auf: Usenet, Webseiten, Accounts in sozialen Netzwerken, aber auch bei Google oder Github, ja sogar auf Visitenkarten. Vor ein paar Monaten dachte ich einmal darüber nach, das zu ändern; eine Mailadresse unterhalb einer eigenen Domain hat (wie bei Webseiten) den großen Vorteil, dass man sie jederzeit mitnehmen kann (und mittlerweile bieten auch die meisten Anbieter von E-Mail-Diensten die Möglichkeit an, eine eigene Domain zu nutzen). Nach einer Abwägung des Gewinns gegen den damit verbundenen Aufwand entschloss ich mich aber dagegen.

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.

Die bereits bestehende, umfangreiche Liste von Newsservern auf meiner Homepage habe ich jetzt um eine Liste von Windows-Mailservern ergänzt, die sicherlich noch nicht umfassend ist, aber einen ersten Überblick ermöglichen sollte.

Ergänzungen und Korrekturen - und ggf. auch Empfehlungen - können gerne in den Kommentaren erfolgen; ich nehme sie freilich auch per E-Mail gerne entgegen.

Wer - privat oder beruflich - Outlook nutzt, weiß wahrscheinlich, dass die dort gespeicherten Inhalte - E-Mails, aber auch Kontakte, der Kalender, Aufgaben u.a. - in einer .pst-Datei abgelegt werden, wobei diese Abkürzung für Personal Storage Table steht. Wird Outlook an einem Exchange-Server betrieben, wird man in der Regel auf seinem lokalen Rechner eine .ost-Datei finden, eine Off-line Storage Table, die die auf dem Server gespeicherten Inhalte offline bereitstellt, falls zum Server keine Verbindung besteht.

Das Exportieren der eigenen Daten ist daher auch vergleichsweise leicht: sie lassen sich aus Outlook heraus in eine .pst-Datei exportieren und aus einer solchen auch wieder importieren. Was aber, wenn man eine .pst-Datei ohne Outlook lesen möchte? Oder wenn der Export scheitert, weil - bspw. am Arbeitsplatz - der Zugriff auf .pst-Dateien gesperrt worden ist?

In beiden Fällen helfen Tools. Konvertierungsprogramme von .ost nach .pst finden sich bei Google. Und - bspw. - der PST Viewer von PST Walker Software kann sowohl .pst- als auch .ost-Dateien anzeigen. Weitere Tools können in das und aus dem proprietären .msg-Format konvertieren oder auch E-Mails u.a. als .eml-Dateien speichern.

“Information overload” ist im Netz kein ganz neues Thema. Dazu gehört auch die Vielzahl von Newslettern und Mailinglisten, die regelmäßig die Inbox verstopft und selten bis nie gelesen wird. Wie schnell ist ein interessant klingender Newsletter abonniert, oder vielleicht ist das Abonnement auch mit der Anmeldung bei einem Dienst verknüpft, und man will dann erst einmal auf dem Laufenden bleiben - abmelden kann man sich ja immer noch. Und will man wirklich das Risiko eingehen, ein interessantes Angebot zu verpassen?

Bereits vor rund zwei Jahren, im Januar 2013, hatte ich mir aber einmal ein Herz gefasst und rund drei Dutzend (!) Newsletter abbestellt. Keinen habe ich seitdem wirklich vermisst, aber natürlich sind etliche geblieben und mittlerweile weitere dazugekommen.

Nun habe ich bereits viele Monate lang beobachtet, dass ich alle (!) eingehenden Newsletter nur noch automatisch oder manuell in den entsprechenden Ordner verschiebe und sie weder zeitnah noch überhaupt je lesen. Insofern erscheint mir der richtige Zeitpunkt gekommen, einmal das letzte Quartal in diesem Ordner durchzugehen und konsequent jeden Newsletter abzubestellen, bei dem ich mir nicht sicher bin, ob ich ihn im kommenden Vierteljahr lesen werde - dann was bringt es, interessante Informationen und Sonderangebote zu erhalten, wenn man ohnehin die ganze Masse nicht liest? Diesmal waren es knapp vier Dutzend (!) Newsletter, die ich ab sofort nicht mehr beziehen werde. Vielleicht erlaubt mir das dann ja, den verbleibenden Rest ab und zu auch einmal wirklich anzuschauen.

(Als nächstes steht dann ein kritischer Blick auf die abonnierten Mailinglisten an, denn auch dort gibt es mehrere, die ich seit Jahren (!) nur noch regelmäßig auf gelesen setze. Wobei in diesem Fall ja wenigstens noch das Argument greift, dass ein lokales Archiv von Supportmailinglisten u.ä. es erlaubt, im Falle eines auftretenden Problems schnell einen Überblick zu gewinnen, was dazu bereits von anderen geschrieben wurde, ein Mehrwert, den Newsletter nicht zu haben pflegen.)

Blogsysteme müssen regelmäßig E-Mails generieren, sei es an den Blogbetreiber, sei es an Kommentatoren: Informationen über neue Kommentare oder Beiträge, mögliche Updates usw. usf. Das erfordert natürlich das Vorhandensein einer (gültigen) E-Mail-Adresse, die als Absender solcher Mails eingesetzt werden kann.

Serendipity macht es sich einfach und überlässt dem Nutzer die Wahl: die “E-Mail-Adresse des Blogs”, blogMail, ist entsprechend in der Konfiguration zu setzen. Das erlaubt dem Nutzer die freie Wahl, erfordert aber umgekehrt natürlich, dass der Nutzer sich darüber Gedanken macht - andererseits: wie soll das anders gehen?

Die Antwort darauf liefert der Konkurrent WordPress, und sie überzeugt mich nicht: auch WordPress verlangt zwar die Angabe einer E-Mail-Adresse “zu administrativen Zwecke”, setzt standardmäßig als Absender aber die Adresse wordpress@example.com, wobei statt example.com die Domain des Blogs steht. Großartig, wenn eine solche Absenderadresse dann nicht existiert. Außerdem setzt WordPress offensichtlich standardmäßig keinen Envelope-Sender, so dass in der Regel der Benutzer, unter dem der Webserver-Prozess läuft, als solcher eingesetzt wird. Auch an diesen “Absender” in der Form www-data@yourhost.example.com kann man allerdings regelmäßig keine Mail schicken …

Abgesehen davon, dass daraus Probleme mit der Auslieferung der E-Mails entstehen können (Stichworte “Verifikation von Absenderadressen” und “Spamfilter”), ist das auch einfach technisch unschön. Wie also lässt sich das abstellen?

1. Der Mailserver muss dem PHP-Prozess zunächst einmal erlauben, einen Envelope-From (bspw. via sendmail -f blog@example.com) zu setzen.
   Wenn man - wie ich - Exim einsetzt, muss der entsprechende Benutzer, unter dem der Webserver läuft, zu trusted_users hinzugefügt werden. Man kann sich dabei stundenlanges Debugging sparen, wenn man rechtzeitig daran denkt, dass man via mod_suphp (oder auf ähnliche Art und Weise) PHP-Scripts nicht unter der User-ID des Webservers, sondern unter derjenigen des Benutzers laufen lässt. Dieser Benutzer - und nicht www-data o.ä. - muss dann auch in trusted_users.

2. Danach muss man WordPress davon überzeugen, den passenden From:-Header zu setzen.
   Das geht über manuelle Änderungen von Konfigurationsdateien oder - einfacher und m.E. auch besser - durch Installation eines passenden Plugins, von denen es eine ganze Reihe gibt. Ich nutze dazu WP JV Custom Email Settings, das mir leichtgewichtig genug erscheint. Stattdessen kann man natürlich auch WP Simple Mail Sender, Personal Email oder etwas ähnliches verwenden, im Extremfall etwas wie WP Mail Options, das den Zugriff auf alle Einstellungen von PHPMailer, dem verwendeten PHP-Modul, eröffnet und insbesondere auch Test-E-Mails generieren kann, was zum Testen ganz praktisch sein mag.

3. Schließlich muss man in WordPress auch den Envelope-Sender korrekt setzen.
   Das kann, soweit ich sehe, nur das Plugin Set email sender.

Danach funktioniert dann auch in WordPress alles so, wie man sich das eigentlich von Anfang an gedacht hätte.

Ich weiß, dass man sich keine Illusionen über die Zuverlässigkeit auch - gering - bezahlter Dienste machen soll, und ich weiß auch, dass Service oft ein Zuschussgeschäft ist. Ich bin auch nie davon ausgegangen, dass man bei bekannten Anbietern kostenloser E-Mail-Adressen einen verlässlichen Dienst erwarten kann; auch dann nicht, wenn man dort einen bezahlten Account hat, denn das ist ja im Zweifel dieselbe Technik mit denselbem Personal.

Dennoch hat es mich etwas überrascht, welche Schwierigkeiten ein Anbieter - übrigens ein solcher, der keine kostenlosen Accounts anbietet, sondern schon ein paar Euro pro Monat für ein E-Mail-Postfach verlangt - bei der Beseitigung einer Störung hat. Aufgefallen ist diese Stärung, die sich darin äußerte, dass ein Versuch des Mailabrufs über IMAP/POP3 wie über Webmail in Timeouts lief, mir am 21. Juni; gut, das war ein Wochenende. Da tat sich offenbar auch nicht viel mehr, als dass eine Mitteilung auf der Webseite geschaltet wurde. Danach hat man sich dann um die Fehlerbehebung bemüht; viel getan hat sich aber nicht. Ab und an konnte man mal einige E-Mails erhalten, aber ein richtiger Abruf war nicht möglich. Bis Donnerstag (immerhin der 6. Tag der Störung!); da hat man dann damit begonnen, die Mailboxen umzukopieren. Nachdem ich meinem Client (am Samstag …) beigebracht hatte, dass sich die UIDVALIDITY geändert hatte, funktionierte der Abruf dann immerhin. Tröpfelnd. Pro E-Mail vergingen mehrere Sekunden. Das dauerte. Und dauerte. Und dauerte auch weiter. Auch heute, am Sonntag, dem 29.06.2014 (9. Tag der Störung) war man immer noch an der Arbeit und mit dem Umkopieren von Daten beschäftigt.

Zwar läuft es bei mir, aber ich bin gespannt, wann man die endgültige Störungsbehebung vermelden kann.

Und ich bin nicht beeindruckt.

Nachtrag vom 05.07.2015: Auch am 02.07.2014 - so der letzte Stand - war man weiter mit dem Umkopieren verbleibender Mailboxen beschäftigt …

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.