Netz - Rettung - Recht

Nach einem guten Jahr habe ich mal wieder Zeit zu einer kleinen Änderung in checkmail gefunden, die ich dann sogleich als Version 0.5 released habe.

checkmail überprüft die ihm übergebenen E-Mail-Adressen nun zunächst auf syntaktische Richtigkeit (wobei allerdings auf der Domain-Seite keine in eckigen Klammern stehenden IP-Adressen akzeptiert werden), bevor er weitere Tests damit durchführt.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

RBLs (Realtime Blackhole Lists) sind mittlerweile über ein Jahrzehnt alt und eine weitverbreitete Methode der Filterung unerwünschter E-Mails. In diese Listen, die über das DNS propagiert werden, trägt der jeweilige Betreiber nach seinen Kriterien die IP-Adressen von Hosts ein, die gefiltert werden sollen. Manche dieser Listen sind sinnvoll, andere sind es nicht; manche zählen Spam-Quellen auf, offene Proxies und Relays, von Malware befallene Systeme, andere jedes System, dessen Betreibers Nase dem RBl-Provider nicht passt. Wer RBLs einsetzt, muß sich also informieren, welche Policy eine RBL verfolgt, und wie zuverlässig sie das tut.

Neben den RBLs gibt es auch Anbieter, die prüfen, ob bestimmte Systeme auf diesen RBLs landen; das sollte jeder Admin größerer Mailsysteme eigentlich selbst tun, um ggf. (das für die Listung ursächliche Problem zu beheben und dann) die Löschung von der jeweiligen RBL zu veranlassen, aber für diejenigen, die das nicht tun können oder möchten, sind solche Angebote sicher interessant. Nur sollten diese Anbieter von RBL-Checks auch wissen, was sie da eigentlich tun, was wohl nicht immer sichergestellt ist …

Ich bekam jedenfalls dieser Tage (mal wieder) einen Hinweis, eines meiner Systeme sei in der RBL hostkarma.junkemailfilter.com gelandet; wie der Name andeutet, versucht deren Betreiber Mailserver in gute, schlechte oder neutrale einzuteilen. Wie zuvor habe ich daraufhin mein System auf den Webseiten des RBL-Betreibers geprüft und bekam - wie immer - als Antwort, das System sei nicht gelistet. Diesmal bin ich der Sache nachgegangen und habe festgestellt, daß der RBL-Check-Anbieter grundsätzlich Recht hat: meine Maschine war tatsächlich in der RBL eingetragen! Aber warum bestreitet das der RBL-Provider dann? Nun, meinem System war dort der Wert "127.0.0.1" zugewiesen. Und der RBL-Provider meint zu diesem Wert folgendes:

127.0.0.1 - whitelist - trusted nonspam

Danke, keine weiteren Fragen mehr.

Aufgrund einer bei mir eingegangenen Anfrage habe ich mich heute mal mit dem korrekten Format eines Date:-Headers in einer E-Mail befasst.

Ein Leser meiner Homepage schilderte mir das Problem, das automatisch generierte E-Mails aus seiner Webanwendung bei ihm im Posteingang von GMX (Webinterface) immer mit dem Datum "01.01.1970" angezeigt würden, in seinem Mailclient (Outlook) aber korrekt. Das Datum (die "Epoche") roch natürlich nach fehlendem oder nicht standardkonformen Date:-Header … Nach Überlassung eines Beispiels konnte ich sehen, daß die Anwendung den Header nach dem Muster Wed, 29 Sep 10 22:45:24 generiert. Meine erste Vermutung, daß das Jahr vierstellig angegeben werden müsse, erwies sich als falsch … aber die zweite, nämlich daßdie Angabe der Zeitzone fehlt, als goldrichtig.

Der letzte STD 10, RFC 822, sieht die Angabe einer Zeitzone nämlich ebenso wie seine Nachfolger, RFC 2822 und der momentan auf dem Standard Track befindliche RFC 5322 (der künftige Standard) als zwingend vor; eine Datumsangabe ohne diese ist somit nicht nur uneindeutig, sondern auch syntaktisch fehlerhaft. Test-E-Mails an GMX bestätigten dann auch, daß im Posteingang der Weboberfläche (nur) die Mails mit fehlender Zeitzone fälschlisch auf den 1.1.1970 datiert wurden. Interessanterweise wurde das Datum aber in der Einzelansicht der E-Mails - genau wie auch in meinem Mailclient - korrekt (in der - hier ja auch zutreffenden - lokalen Zeitzone) angezeigt.

Die Anwendung sollte dementsprechend nachgebessert werden, um undefinierte Ergebnisse zu vermeiden.

Nach dem gestrigen Release der praktisch komplett neu geschriebenen Version 0.3 von checkmail kann ich heute die Version 0.4 von checkmail ankündigen, die die eigentlich geplanten Änderungen enthält.

checkmail erkennt temporäre Fehler - bspw. auch beim Greylisting - jetzt als solche, statt diese E-Mail-Adressen als nicht zustellbar zu definieren; außerdem werden in jedem Fall die Antworten des Mailservers standardmäßig ausgegeben.

Überdies kann checkmail jetzt selbst eine tatsächlich zufällige - und damit mit hoher Sicherheit nicht zustellbare - E-Mail-Adresse erzeugen, wenn geprüft werden soll, ob der betreffende Mailserver überhaupt schon im SMTP-Dialog die Zustellbarkeit überprüft (ansonsten sind positive Antworten keine Garantie für die Existenz der geprüften Adresse). Die übrigen Konfigurationsangaben (der zu verwendende Absender und die Angaben für HELO/EHLO) können nun nicht nur im Script definiert, sondern auch auf der Kommandozeile übergeben werden.

Die Dokumentation wurde entsprechend aktualisiert.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Nach rund 5 Jahren Pause habe ich nunmehr eine neue Version 0.3 von checkmail released, einem Kommandozeilen-Tool zur Überprüfung der Zustellbarkeit von E-Mail-Adressen.

Im Prinzip wurde das Script komplett neu geschrieben, modularisiert, neu strukturiert und in den Kommentaren vereinheitlicht. Außerdem habe ich die Ausgaben neu gefaßt und ausführlicher gemacht; MXe werden jetzt zuverlässig in der nach dem DNS vorgegebenen Reihenfolge ausprobiert, Multi-Line-Antworten ordnungsgemäß protokolliert und der Exit-Status bei der Batch-Verarbeitung von Adressen sinnvoll gesetzt (womit zugleich eine Veränderung der Bedeutung des Exit-Status verbunden war).

Außerdem wurde die Dokumentation im POD-Format in das Script integriert und ins Englische übersetzt und ein Changelog hinzugefügt.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Meine Mailserver erwarten, daß derjenige, der eine E-Mail einliefern möchte, sich ordnungsgemäß "vorstellt" (also ein einigermaßen korrektes HELO bzw. EHLO überträgt, namentlich nicht den - respektive einen der - Namen meiner eigenen Maschinen und auch keine bloße IP-Adresse). Normalerweise fängt dieser vergleichsweise "weiche" Filter nicht viel Spam weg (und "härter" filtern, bspw. überprüfen, ob die Vorwärts-Rückwarts-Auflösung stimmt o.ä., möchte ich darauf nicht).

In den letzten Tagen hat sich allerdings namentlich eine Maschine aus Venezuela geradezu rührend bemüht, trotzdem E-Mail loszuwerden:

root@host:~# zgrep -c wonderl.com /var/log/exim/mainlog.*
/var/log/exim/mainlog.01:32569
/var/log/exim/mainlog.02.gz:133069
/var/log/exim/mainlog.03.gz:164318
/var/log/exim/mainlog.04.gz:161655
/var/log/exim/mainlog.05.gz:142325

Das sind gestern rund 32.500 Versuche, und die vier Tage zuvor, mithin über Ostern, jeweils deutlich über 100.000. Ich würde ja gerne wissen, ob das immer dieselbe E-Mail sein sollte (nachdem die Versuche in der Regel maximal im Sekundenabstand liegen, liegt das allerdings eher fern), oder ob mir da massiv Spam erspart geblieben ist … Jedenfalls eine durchaus bemerkenswerte Penetranz, die dort an den Tag gelegt wurde.

… andere sind es weniger.

Ich hatte bereits im vergangenen Jahr berichtet, wie wenig zuverlässig E-Mail als Medium mittlerweile oft ist, dann aber positiv überrascht zur Kenntnis nehmen dürfen, wie vergleichsweise schnell auch ein großer Anbieter wie Ebay auf entsprechende Hinweise reagiert und die (gar nicht im Ernst erwarteten) notwendigen Änderungen an seinen Mailsystemen vornimmt. Nunmehr kann ich berichten, daß andere Anbieter zwar dasselbe Problem haben, aber die Reaktion leider nicht immer gleich kompetent ist. Vodafone versendet E-Mails nämlich gleichfalls mit nicht existenten Absendern; mein entsprechender Hinweis wurde schnell, aber leider nur so beantwortet:

Guten Tag Herr Hochstein,

Ihr Hinweis hilft uns, Fehler zu erkennen und uns zu verbessern. Vielen Dank dafür. Leider können wir in diesem Fall keinen weiteren Support leisten. Eine Änderung des Absenders bei automatischen Bestätigungen ist nicht angedacht.

Sicherlich werden Ihre User keine Problemne haben, wenn sie Ihnen Mails über ihr Vodafone-MobileMail Postfach versenden.

Den ersten Absatz verstehe ich, auch wenn er mir inhaltlich nicht gefällt, aber, ganz ehrlich: was der zweite Absatz mir sagen will, ist mir schleierhaft. *kopfkratz* Am Problem der mit ungültigem Absender versandten automatisierten Bestätigungen geht diese Antwort doch völlig vorbei.

Es geschehen noch Zeichen und Wunder! Auf meine Anfang November an den Support gestellte Frage bzw. den Hinweis auf Probleme beim Mailversand durch Ebay bzw. der Zustellung solcher E-Mails kam - nach einem Zwischenbescheid - nunmehr eine Antwort in der Sache:

Sehr geehrter Herr Hochstein,

Sie hatten sich an eBay gewandt, da Ihre Nutzer nicht alle E-Mail von uns erhalten haben.

Durch Sie und andere E-Mail-Provider sind wir auf eine Änderung in der Kopfzeile unserer Benachrichtigungen hingewiesen worden. Dies könnte der Auslöser für das geschilderte Problem gewesen sein. Um diese  Fehlerquelle auszuschliessen, haben diese Änderung jetzt korrigiert.

Herr Hochstein, bitte informieren Sie uns, ob Ihre Nutzer ab dem 16.12.2009 noch Benachrichtigungen vermissen.

Ich danke Ihnen für Ihre Mühe und wünsche Ihnen eine angenehme Woche.

Und die Überprüfung hat tatsächlich eine Behebung des Problems ergeben: die im Envelope-From bzw. Return-Path (dem "technischen" Absender der E-Mail) verwendeten Adressen existieren jetzt wieder bzw. nehmen E-Mail entgegen.

Erfreulich, daß man sich bei Ebay solcher Probleme tatsächlich annimmt und sie behebt. Das motiviert dazu, auch in anderen Fällen entsprechend tätig zu werden.

Nachdem ich im letzten Monat meine Verwaltung personalisierter E-Mail-Adressen auf eine bequeme Weboberfläche umgestellt hatte, habe ich dieses Konzept nun auch auf meine abonnierten Mailinglisten erweitert.

Bislang habe ich alle Mailinglisten mit derselben E-Mail-Adresse abonniert, die ich dann per UUCP abgerufen habe. Das hatte den protokollbedingten Vorteil, daß die E-Mails komprimiert wurden, aber den Nachteil, daß ich keine Kontrolle über die Konfiguration des MX hatte, also auch keine Spamfilterung implementieren konnte, und daß bei einem Wechsel des Providers auch diese E-Mail-Adresse verlorengeht, dann also plötzlich alle bezogenen Mailinglisten unter anderer Adresse neu abonniert werden müssen. Und schließlich kamen über diese Adresse geradezu ungeheure Mengen an Spam an, geschuldet den Webarchiven der meisten Mailinglisten. Also habe ich mich nun entschieden, auch für den Bezug von Mailinglisten jeweils individualisierte Mailadressen unter einer (anderen) Subdomain einzusetzen; das erleichtert es überdies, bei Problemen mit der Abbestellung einer Liste einfach die entsprechende Bezugsadresse stillzulegen.

Das Hauptproblem bei einer solchen Umstellung ist es, die bisherige Bezugsadresse aus jeder einzelnen Liste aus- und die neue Bezugsadresse dann wiederum in jede Liste neu einzutragen (von der Reihenfolge her natürlich andersherum, damit keine Mailverluste auftreten). Und man glaubt gar nicht, wie schnell man dabei Low-Traffic-Listen (Ankündigungen o.ä.) vergißt …

Schon seit langer Zeit (tatsächlich wiederum Jahren) habe ich daher Scripts laufen, die versuchen, aus den über die Zustellung an meine Mailnglistenadresse geschriebenen Logs möglichst alle betroffenen Mailinglisten zu isolieren. Und ausgerüstet mit diesen Listen, einer Liste der Mailinglisten, an deren Bezug ich mich bewußt erinnere und einer Liste meiner Mail2News-Gateways habe ich nunmehr die Herkules-Aufgabe begonnen, alle Mailinglisten umzustellen (und manche dabei direkt abzubestellen). Ich bin gespannt, welche Listen ich vergessen werde …

Dazu waren ergänzende Umstellungen "drumherum" erforderlich: bspw. bei der lokalen Auslieferung der Mailinglistenmails, die Filter und Mail2News-Gateways berücksichtigen muß, oder auch bei der Konfiguration der richtigen Absenderadresse für jede Mailingliste in Mailclient oder Newsreader, damit eventuelle Antworten auf die Listen dann auch auf diesen landen und nicht abgewiesen werden, weil sie von einer Adresse kommen, die dem Mailinglistensystem unbekannt ist. Und das Logging wollte angepaßt werden, und … und … und …

Ich bin gespannt, wie sich diese Umstellung bewähren wird.

Angeregt durch den ohnehin erforderlichen Umzug des Mailinglistenservers Mailman auf eine neue Maschine habe ich jetzt endlich auch die - historisch gewachsene - Konfiguration der meisten Mailinglisten geändert und bei der Gelegenheit auch eine Vielzahl bereits seit Jahren "toter" Mailinglisten - ggf. nach Rücksprache mit dem jeweiligen Betreiber - entsorgt. Die Konfigurationsänderung besteht in erster Linie in einer Änderung des per Default genutzten Hostnamens bzw. der Domain von "list.th-h.de" (Singular, da es anfangs eine Parallelinstallation "lists.th-h.de" gab …) zu "lists.szaf.org", weil es schließlich weniger um ein nur von mir genutztes Angebot geht als vielmehr um einen Dienst, der auch anderen zur Verfügung stehen soll. Selbstverständlich bleiben die bisher genutzten Namen für die bestehenden Listen verfüg- und nutzbar.

Praktisch finde ich, daß sich Mailman so konfigurieren läßt, daß - je nach dem Hostname, unter dem das Webinterface aufgerufen wird - jeweils nur die Mailinglisten angezeigt werden, die unter der entsprechenden Domain angelegt sind. Ein Aufruf von list.th-h.de bringt also ein anderes Ergebnis als ein Aufruf von lists.szaf.org (natürlich nur soweit die Mailinglisten überhaupt öffentlich angezeigt werden).

Man sagt, E-Mail sei in früheren Zeiten technisch bedingt ein eher unzuverlässiges Medium gewesen: schmale Anbindungen, schwachbrüstige oder unter Leistungsgesichtspunkten knapp kalkulierte Server, Auslieferung über viele verschiedene Zwischenstationen (Hops), teilweise über Systeme, die nicht permanent ans Internet angebunden sind (store-and-forward), teilweise auch unzuverlässige Software, zumindest bei einem hinreichend breit gefaßten Begriff von E-Mail auch viele verschiedene, zueinander inkompatible Formate (Internet-E-Mail, X.400, Mail über UUCP, private Nachrichten in Mailboxnetzen, …), die untereinander umgesetzt werden mußten, teilweise über Netzgrenzen hinweg.

Das ist heute Vergangenheit. E-Mail wird in der Regel nur noch als "Internet-E-Mail" ausgetauscht, die betreffenden Server sind per ausreichend dimensionierter Standleitung ans Netz angebunden und entsprechend leistungsmäßig - wenn sich natürlich auch jede Infrastruktur durch genügend E-Mails, meistens im Rahmen der Versendung von Spam oder Malware, in die Knie zwingen läßt -, die Protokolle sind verfeinert und erweitert und man muß nicht mehr damit rechnen, daß irgendwelche Konvertierungen zu Informationsverlusten führen oder sich zwingend auf den ASCII-Zeichensatzvorrat (ohne Umlaute o.ä. oder gar "Anhänge") beschränken.

Dieser Zugewinn an technischer Sicherheit wird m.E. aber leider oft durch administrative Maßnahmen mehr als aufgewogen: technisch mag es zwar trivial sein, E-Mail auszuliefern, aber administrativ führen Abwehrmaßnahmen gegen tatsächliche oder vermeintliche Bedrohungen (Blacklists, Filterung jenseits technisch zwingender Notwendigkeit, Greylisting, Sender-Verification-Callouts, SPF und Co., BATV, DKIM und Co., Spam-, Viren- und andere Contentfilter etc. pp.) und nicht selten auch bloße Inkompetenz derjenigen, die "mal eben" einen Mailserver aufsetzen, dazu, daß die Mailzustellung faktisch langsamer und schwieriger wird und teilweise für den Absender noch nicht einmal erkenbbar wird, daß seine E-Mail den Adressaten nicht erreicht hat). Das gilt insbesondere, wenn verschiedene Filtertechniken oder Konfigurationen auf Absender- und Empfängerseite miteinander interagieren, was zu unerwarteten Folgen führen kann.

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

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

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

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

Ich hatte bereits am 20.05.2009 über die bemerkenswerte Entscheidung des BGH zur Beschlagnahme von E-Mails beim Provider ("in der Mailbox") berichtet, nach der die Vorschriften über die Postbeschlagnahme einschlägig sind, nicht etwa § 100a StPO, mit der Folge, daß weder eine Katalogtat noch ein gesteigerter Tatverdacht ("bestimmte Tatsachen") noch eine ultima-ratio-Situation vorliegen müssen. Ich hatte dabei auch bereits (vielleicht etwas süffisant) angemerkt, daß das BVerfG schon seit Ende 2006 anläßlich einer Verfassungsbeschwerde über dieser Frage brütet.

Nunmehr hat man dort zu Ende gebrütet und im Ergebnis die Ansicht des BGH bestätigt bzw. ist noch über diese Ansicht hinausgegangen. Mit Beschluß vom 16.06.2009 - 2 BvR 902/06 - hat das BVerfG festgehalten, daß die Beschlagnahme von E-Mails, die beim Provider gelagert sind, zwar in das Grundrecht aus Art. 10 GG eingreift, die allgemeinen Beschlagnahmevorschriften aber (bei besonderer Beachtung des Verhältnismäßigkeitsgrundsatzes) zur Rechtfertigung des Eingriffs genügen, und die Verfassungsbeschwerde zurückgewiesen.

Am Wochenende habe ich mich - endlich - mal wieder meiner Ablage gewidmet und Kontoauszüge, Rechnungen, Bestellungen, Gehaltsabrechungen, Steuerbescheide und was einem sonst noch so die sommerlichen Temperaturen verderben kann sortiert und abgelegt. Dabei stellte ich fest, daß mir für diverse Accounts bei 1&1 die Rechnungen aus dem Juni fehlten: Mai war da, Juli auch, Juni fehlt. Nachdem die Rechnungen per E-Mail versandt wurden, habe ich natürlich als erstes einmal nachgesehen, ob ich wohl vergessen hatte, sie auszudrucken; aber nein, es liegen auch keine E-Mails vor.

Eine genauere Untersuchung ergab dann, daß die Rechnungs-E-Mails nicht angenommen wurden, weil die entsprechenden E-Mails eine nicht-existente Absenderadresse aufwiesen:

2009-06-05 16:39:55 H=mbulk.1and1.com [212.227.126.221] F=<bill-iid-***-200906051626-***@bounce.kundenserver.de> rejected RCPT <thh@***.de>: Sender verify failed

Sehr nervig. Hilft also nur, den entsprechenden Mailserver (hier wohl mbulk.1and1.com) zu whitelisten. *brummel*

Nein, es soll heute nicht um Fahrtrichtungsanzeiger, vulgo Blinker, gehen, sondern um einen großen deutschen Freemailanbieter, der sog. "Fun-Domains" anbietet, d.h. die Registrierung von E-Mail-Adressen nicht nur unter der Hauptadresse des Dienstes ("example@freemailer.example"), sondern auch unter weiteren Domains anbietet ("example@cooler-hase.example").

Dieser Anbieter hat offenbar derzeit Probleme mit der Synchronisation der Benutzerdaten zwischen seinen Mailservern, was mir deshalb auffiel, weil eine E-Mail an eine bestimmte Adresse nicht zustellbar war, bei einer Überprüfung der Adresse diese aber gültig erschien. Nachdem dennoch eine weitere Mail als unzustellbar zurückging, habe ich das Phänomen gestern dann etwas systematischer - unter Zuhilfenahme eines entsprechenden Scripts - untersucht, mit überraschendem Ergebnis.