Netz - Rettung - Recht

Bereits am 31.03.2009 hat der BGH eine bemerkenswerte Grundlagenentscheidung zur Frage der Beschlagnahme von E-Mails getroffen. Wie und unter welchen Voraussetzungen den Strafverfolgungsbehörden der Zugriff auf E-Mails möglich ist, ist nämlich eine bisher noch nicht höchstrichterlich entschiedene, umstrittene und durchaus praxisrelevante Frage, die aufgrund ihrer Komplexität nicht ganz einfach zu beantworten ist. 

Technische Grundlagen

Aus technischer Sicht werden E-Mails im Regelfall beim Absender auf einem unter seiner Kontrolle stehenden System verfaßt und dann über den Mailserver seines Providers (Smarthost) versandt. Dieser Mailserver nimmt die E-Mail entgegen, speichert sie zwischen, ermittelt den für die Empfängeradresse(n) zuständigen Mailserver und liefert die E-Mail nach dort aus. Sobald dies erfolgreich gelungen ist, löscht er die zwischengespeicherte Kopie. Der Mailserver des Empfängers, im Regelfall bei dessen Provider, speichert die eingegangene E-Mail in der Regel in der Mailbox des Empfängers; diese wurde früher zumeist (via POP3) komplett abgerufenen und die eingegangenen E-Mails auf dem Rechner des Empfängers gelesen und gespeichert, heute ist es hingegen oft üblich, die E-Mails in der Mailbox liegen zu lassen und dort auch dauerhaft zu speichern, d.h. nur zum Lesen und Sortieren (via IMAP) auf dieses Postfach zuzugreifen. Von diesem Regelfall gibt es natürlich mögliche Abweichungen und Varianten (Versand über eine Weboberfläche, E-Mail-Weiterleitungen, Speicherung einer Kopie im Postfach etc. pp.), aber mehr oder weniger lassen sich immer dieselben Stationen im Laufweg einer E-Mail unterscheiden.

Am Anfang liegt sie - wie er noch nicht versandte Brief - im Herrschaftsbereich des Absenders; dieser vertraut sie dann einem Telekommunikationsunternehmen an - wie den Brief mit Einwurf in den Briefkasten -, das sie weiterleitet; danach landet die E-Mail dann in einer Mailbox - vergleichbar einem konventionellen Postfach -, immer noch in der Obhut des Telekommunikationsunternehmens; und schließlich ruft der Empfänger sie ab und speichert sie wieder auf seinem eigenen Rechner - wie den aus dem Postfach entnommenen Brief, der zuhause abgelegt wird -. Diese Analogie wird erst dann schwierig, wenn die E-Mails nicht mehr alle abgerufen werden, sondern teilweise oder ganz auf dem Server des Providers verbleiben; dort liegt dann ggf. ein Mix von schon gelesenen (oder abgerufenen) und neu eingegangenen E-Mails vor.

Am Wochenende schrieb ich schon von einer Anfrage, die mich erreichte und die ich gerne und ausführlich beantwortete - allerdings erfolglos, denn die angegebene E-Mail-Adresse des Fragestellers existierte nicht.

Inzwischen hat sich die Sache geklärt. Ich war nämlich schon am Wochenende experimentierfreudig gewesen und hatte festgestellt, daß es die angegebene Mailadresse bei GMX zwar nicht gibt, aber dafür (mit demselben, ungewöhnlichen Localpart) bei web.de, und dort einmal eine entsprechende Anfrage hingesandt. Inzwischen ist die Antwort da, und sie lautet: Der Fragesteller hat bei seiner Anfrage im Absender schlicht die falsche Domain angegeben.

Was mich trotz allem etwas irritiert. Ich meine, GMX und web.de gehören seit Jahren beide zu United Internet, aber daß man nicht mehr weiß, wo man seine Mailadresse hat?

Da trudelte doch am gestrigen Freitag eine Anfrage über das Kontaktformular auf meiner Homepage mit der Bitte um Hilfe bei einer bestimmten Fragestellung (im Zusammenhang mit Newsgroups und einer schulischen Aufgabe) ein. Man weiß ja nie, wie sehr es dabei eilt, also nutze ich heute die anstehende Zugfahrt und stelle eine ausführliche Antwort - der Mailclient zählt rund 170 Zeilen, inkl. Quotes - mit Links zu weiterführenden Texten zusammen, die ich von unterwegs noch absende (immerhin habe ich jetzt ja eine funktionierende UMTS-Karte ).

Und was ist das Ergebnis? Die angegebene E-Mail-Adresse des Fragestellers (bei einem großen deutschen Freemailanbieter mit drei Großbuchstaben) ist nicht existent. Supersache.

(Vielleicht sollte ich nächstes Mal einfach gar nicht erst antworten. Spart Zeit, die ich eigentlich nicht habe …)

Die Titelzeile faßt es eigentlich schon zusammen: seit dem Upgrade meiner Mailman-Installation auf die aktuelle Version 2.1.12 mag das praktische Perlscript listadmin.pl, über das ich bereits berichtet hatte, seinen so hilfreichen Dienst nicht mehr versehen (auch nicht nach Update auf die aktuellste Version 2.40, die wohl aus dem Jahr 2007 datiert), offenbar deshalb, weil der Parser über geänderte Webseiten (geänderte Mailman-Templates) stolpert.

Solange keine administrativen Aufgaben zu erfüllen sind, läuft es problemlos durch (so soll es sein); wenn man es auf nicht mehr existente Listen losläßt, beschwert es sich und läßt die Liste aus (auch das ist vernünftig und akzeptabel):

ERROR: unexpected contents, please send /tmp/dump-0.144370685638027-list@domain.example.html to $address — skipping list

Wenn es aber etwas zu tun hätte, weil sich Anfragen in der Moderations-Queue befinden, dann bricht es leider einfach zusammen:

fetching data for list@domain.example … Died at ./listadmin.pl line 802.

Grund ist offensichtlich ein Stolpern des Parsers:

sub parse_subscription {
    my ($mmver, $config, $parse, $data) = @_;

    $parse->get_tag ("td") || die;
    my $address = $parse->get_trimmed_text ("/td") || die;
    my $tag = $parse->get_tag ("input") || die;
    my $id = $tag->[1]{"name"};
    $parse->get_tag ("/table") || die;
$parse->get_tag ("/tr") || die;
    $data->{$id} = { "subscription" => $address };
}

In der hervorgehobenen Zeile verlassen sie ihn. Offenbar sucht listadmin.pl erst nach zu genehmigenden oder abzulehnenden Beitrittsersuchen, bevor es die weiter unten auf der Seite folgenden zu moderierenden Beiträge abarbeitet, und erkennt letztere fehlerhaft als erstere, weshalb es die falsche Routine zum Parsen derselben aufruft, die dann aus dem Tritt gerät.

Allerdings ist mir der Parser auf Anhieb erstmal etwas zu hoch, daher meine Frage: Gibt es vielleicht schon eine aktuellere Version des Scripts? Oder hat sich schon jemand damit beschäftigt und einen Patch in der Hinterhand? Falls ja: Bitte melde Dich!

Das Landgericht Stuttgart - 16. Strafkammer - hat Berichten zufolge (bereits Mitte vergangenen Jahres) als obiter dictum entschieden, daß zumindest erhebliche Zweifel an der Wirksamkeit eines per E-Mail eingelegten Rechtsmittels - hier: eines Einspruchs gegen einen Strafbefehl - bestehen.

Das ist letztlich wenig überraschend, bedarf es doch auch anderswo - so z.B. im Zivilrecht bei prozeßbestimmenden Schriftsätzen - nicht nur der Schriftform, sondern auch der Unterschrift, um Zweifel darüber auszuschließen, ob der Schriftsatz nun als solcher gelten, das Rechtsmittel eingelegt sein soll oder nicht (und zu belegen, daß der Berechtigte, hier also der Angeklagte, gehandelt hat). Interessanter fände ich daher den Volltext der Entscheidung. Weiß jemand, ob und wo der veröffentlicht ist (außer in CR 2009)? juris hat lustigerweise die Entscheidung, aber nur ohne Text …

Spamfilter sind heute wichtig, will man nicht von der Flut unerwünschter E-Mails überrollt und erschlagen werden - und die entsprechenden Techniken sind durchaus weit entwickelt. Es gibt allerdings auch reihenweise eher ungeeignete Anti-Spam-Maßnahmen, die zunehmend den legitimen Mailverkehr behindern oder gar verhindern. Insbesondere als Unternehmer sollte man daher darauf achten, nicht etwa versehentlich Kundenanfragen auszufiltern und besonders vorsichtig an die Problematik heranzugehen.

Nicht so offenbar ein Unternehmen, das mir eigentlich zunächst ganz positiv auffiel ("Ich sende Ihnen das Angebot dann per E-Mail. Wie ist denn Ihre Mail-Adresse?"). Dort hat man nämlich offenbar entschieden, daß man ja weiß, von welchen Absendern erwünschte E-Mails kommen. Wenn man dann - wie ich - eine Vielzahl von E-Mail-Adressen für verschiedene Zwecke eingerichtet hat, um eingehende E-Mails zu strukturieren, aber normalerweise nur von einer Standardadresse aus antwortet, ist die Reaktion folgende:

To: Thomas Hochstein <****>
Subject: Return to Sender
From: administrator@****de
X-Mailer: ICS SMTP Component V2.32

Ihre Email wurde durch unseren SPAM-FILTER sofort gelöscht.

Um Ihre Email in unserer Positivliste einzutragen rufen Sie bitte
folgende Telefonnummer an:
[…]

Nun denn. Für einen privaten Nutzer halte ich das für unbrauchbar. Bei einer Firma fällt mir keine wirklich passende Bezeichnung dafür ein …

Willkommen im Internetzeitalter!

Post- und Fernmeldegeheimnis genießen besonderen verfassungsrechtlichen Schutz. Dies drückt sich nicht nur in strafprozessualen und präventiven Rechtsnormen aus, die den Schutz des Post- und Fernmeldegeheimnisses dem Staat gegenüber dienen, sondern gilt auch gegenüber Privaten. So stellt bspw. § 88 Abs. 3 S. 1 TKG klar, daß auch Fernmeldedienstleister nicht einfach Einblick in die Kommunikation ihrer Kunden nehmen dürfen, also bspw. deren E-Mail-Verkehr mitlesen.

Für den Bereich des Post- und des Telefoniewesens werden diese Verbote durch strafrechtliche Schutzvorschriften flankiert: §§ 202 Abs. 1, 206 Abs. 2 Nr. 1 StGB sanktionieren den Zugriff auf verschlossene Postsendungen durch Mitarbeiter des Postunternehmens (und Dritte), § 201 Abs. 2 Nr. 1 StGB stellt das Abhören von Telefongesprächen generell unter Strafe. Aber wie sieht es mit E-Mails und anderen elektronischen Kommunikationsformen aus? Bei näherer Betrachtung tun sich überraschende Strafbarkeitslücken auf.

§ 202 StGB, der das Briefgeheimnis schützt, betrifft nur verschlossene (!) Schriftstücke (!), also körperliche Gegenstände, und ist damit für den Schutz von E-Mails u.ä. nicht fruchtbar zu machen.

§ 202a StGB, der das Ausspähen von Daten durch Überwindung einer Sicherung gegen unbefugten Zugriff betrifft, dürfte nicht einschlägig sein, weil Systemadministratoren u.a. Mitarbeiter eines Mailproviders regelmäßig Zugang zu den entsprechenden Systemen und Daten haben, also keine besondere Sicherung überwinden.

Und in der eigentlichen Spezialvorschrift zum Post- und Fernmeldegeheimnis, nämlich § 206 StGB, ist zum einen schon generell sehr umstritten, ob "Sendungen" im Sinne von Abs. 2 der Vorschrift nur körperliche Gegenstände sein können, was die herrschende Meinung in der Literatur annimmt, das OLG Karlsruhe jedoch in einem (der in der Regel nur im Promillebereich erfolgreichen) Klageerzwingungsverfahren für die Variante des Unterdrückens von Sendungen (§ 206 Abs. 1 Nr. 2 StGB) bestreitet (Beschluß vom 10.01.2005, 1 Ws 152/04). Für unsere Fragestellung kommt es darauf jedoch gar nicht an, weil die Tatbestandsvariante des § 206 Abs. 2 Nr. 1 StGB ausdrücklich "eine Sendung, die einem solchen Unternehmen zur Übermittlung anvertraut und verschlossen ist", verlangt; das kann - unstreitig - nur körperliche Gegenstände betreffen. Auch hier ist also der unbefugte Zugriff auf E-Mails u.ä. durch Mitarbeiter des Anbieters nicht strafbewehrt.

Im TKG finden sich gleichfalls keine auf § 88 Abs. 2 TKG bezogenen Strafnormen.

Womit ich die Frage dann mal an die Leserschaft weitergeben möchte - übersehe ich eine Strafnorm, oder ist der unbefugte Zugriff auf textuelle elektronische Kommunikation schlicht strafrechtlich bisher nicht sanktioniert?

Die Bundesnetzagentur bietet auf ihren Webseiten des Abonnements eines Newsletters an - und da es da ja um etliche interessante Thematiken geht, dachte ich mir am Wochenende, ich könnte ihn ja einfach einmal abonnieren.

Bei dem Gedanken blieb es aber bisher, denn das Ausfüllen des bereitgestellten Webformulars führte nur zur Fehlermeldung eines LISTSERV-Servers an mich per E-Mail, ich dürfe diese Liste nicht abonnieren. Soso. Bei Fragen solle ich mich an die Listowner-Adresse (…-request) wenden. Gesagt - getan, und dabei stellte ich dann heraus, daß es nicht bei der Nichtfunktion und der eher kryptischen, zudem englischsprachigen Fehlermeldung bleibt, sondern eine Mail an die Betreiberadresse zu allem Überfluß noch durch ein Challenge-Response-System freigeschaltet werden muß. Das habe ich zwar getan, allerdings noch keine Antwort erhalten (trotz eines CC: an die Pressestelle - die einzige Mailadresse, die auf den Webseiten zu finden war und einigermaßen passend erschien), und ich fürchte fast, das wird auf absehbare Zeit so bleiben.

Diese Vorgehensweise dürfte jedenfalls garantieren, daß ein Newsletterabonnement zumindest einigermaßen fachkundigen und zugleich frustrationstoleranten Interessenten vorbehalten bleibt …

Wer Mailman-Mailinglisten betreibt, wird das Problem kennen: es sammelt sich mit der Zeit - jedenfalls bei offen auf den Webseiten angekündigten oder sonstwie verlinkten Listen - eine ganze Menge Spam an, der zwar in der Regel hängenbleibt, wenn man nur E-Mails von Listenteilnehmern automatisch auf die Liste durchreicht, der dann aber moderiert werden will. Der Aufwand ist dank eines bequemen Webinterfaces nicht so groß - tägliche Hinweismail überfliegen, einloggen, einen Haken bei "discard all", absenden, fertig -, aber wenn man das jeden Tag für ein halbes Dutzend Listen machen muß, ist das trotzdem ziemlich nervig, und man wünscht sich eine einfachere Lösung.

Mit listadmin hat man sie gefunden. listadmin ist ein Perlscript, das die betreffenden Listen und einige Vorgaben aus einer Konfigurationsdatei ausliest, für jede Liste das Webinterface aufruft und dann für jede zu moderierende Mail Absender, Betreff und Moderationsgrund angibt und auf eine Eingabe wartet. Man kann sich dann Teile oder die ganze Mail ansehen und sie entsprechend freigeben, bouncen oder verwerfen; darüber hinaus können auch automatisch Spam-Score-Header ausgewertet werden.

Das macht den Ablauf einfach: alle Listen in die Konfiguration stecken, einmal täglich das Script aufrufen, Default-Action auf "discard" setzen, und für jede Mail einmal <Enter> drücken, und dann noch einmal für jede Liste mit <Enter> die Übernahme der Änderungen bestätigen. Fertig. Kein Aufwand. Toll. Und das beste: listadmin nutzt das Webinterface, d.h. muß nicht auf dem Mailinglistenhost laufen, sondern kann auf einer beliebigen Maschine installiert werden.

(Man sollte allerdings eher nicht das Debian-Package aus stable benutzen, weil das nur Mailman 2.0 unterstützt, und diese Version dürfte in freier Wildbahn eher selten sein. Nachdem der Tarball aber nur aus Manpage und Script besteht, ist es nicht sehr aufwendig, das an der Paketverwaltung vorbei zu installieren.)

Das Landgericht Köln hatte sich vor 14 Tagen mit der im Usenet regelmäßig auftauchenden - und ebenso regelmäßig dann zuvörderst von Ralph Babel mit Verweis auf die Leserbrief-Entscheidung des BGH vom 25.05.1954 (BHGZ 13, 334) beantworteten - Frage nach der Zulässigkeit der Veröffentlichung fremder E-Mails zu beschäftigen und hat in einer wenig überraschenden und nur aufgrund der m. E. bestenfalls verwirrenden Berichterstattung u.a. bei Heise teilweise kontrovers diskutierten Entscheidung (28 O 178/06 vom 06.09.2006), deren Inhalt bei der Kanzlei Dr. Bahr abrufbar ist, die Unzulässigkeit der Veröffentlichung im konkreten Fall bestätigt.

Dem Fall lag zugrunde die Veröffentlichung zweier vertraulicher E-Mails, die - offenbar - ein Aufsichtsratsmitglied einer Aktiengesellschaft in deren Angelegnheiten versandte, auf einer Webseite, die sich - mutmaßlich kritisch - mit dieser Aktiengesellschaft beschäftigte. Wie die E-Mails nach dort gelangten, ist unklar, mutmaßlich wurden sie jedoch von einem Rechner entwendet.

Der Absender der E-Mails verlangte unter Berufung auf sein allgemeines Persönlichkeitsrecht, die E-Mails nicht mehr öffentlich zugänglich zu machen, Schadensersatz zu leisten und zur Bestimmung des Schadensersatzanspruches der Höhe nach Auskunft über die Abrufzahlen der entsprechenden Seite zu erteilen. Der beklagte Veröffentlicher hielt dagegen, die E-Mails seien mit dem Absenden aus der Privatsphäre und dem persönlichen Geheimbereich des Absenders in den allgemeinen Bereich gelangt, so dass eine gravierende Verletzung des allgemeinen Persönlichkeitsrechts nicht vorliege; darüber hinaus diene die Veröffentlichung dem legitimen Informations- und Schutzinteresse der von dem Handeln der AG und des Klägers betroffenen Nutzer der Webseite.

Spam ist ein seit gut 10 Jahren bekanntes Übel, und Spam, der durch Spamfilter rutscht, leider auch nicht so selten, daß er einen Blogeintrag wert wäre. Spam, in dem Spam-Bekämpfung beworben wird, ist allerdings hinreichend selten, dafür aber umso dreister - und wenn die beworbene "Lösung" so (vermutlich unfreiwillig) humoristisch angehaucht ist wie in diesem Fall, dann sollte man diese Verbindung aus Unverschämtheit und unfreiwilliger Komik auch entsprechend würdigen.

Das angepriesene Werk will dem durchschnittlichen Nutzer in drei Schritten nahebringen, wie er Spam vermeiden kann, ja wie Spam geradezu ausgerottet wird, wenn nur jeder diese Schritte befolgt. Kurz gefaßt umfaßt dabei Schritt 1 die Auswahl einer passenden E-Mail-Adresse. In der aus einschlägigen Teleshoppingsendungen und (Tv-)Ratgebern bekannten Sprache erfahren wir auf 53 Seiten, was Spam ist, und daß wir eine E-Mail-Adresse auswählen sollen, die möglichst schwer zu erraten ist; am besten sollen wir dazu mit Papier und Stift in Ruhe unserer Kreativität freien Lauf lassen. Zwar ist richtig, daß damit das Erraten der Mailadresse erschwert oder unmöglich gemacht wird, aber so richtig zielführend mag die Übung dann nicht erscheinen. Garniert wird das (für Fortgeschrittene und Firmen) dann noch mit dem tollen Tip, leicht erratbare Adressen (info@, support@, …) abzuschalten und dort nur einen Autoresponder mit Verweis auf ein Webformular einzurichten (also collateral spam zu produzieren). Daß auch über ein Webformular gespamt werden könnte, scheint dem Autor noch nicht begegnet zu sein (oder es geht über den Horizont des 175-Seiten-Buches hinaus, daß sich gezielt auf E-Mail-Spam beschränken will).

Ich habe recht viele (Mail-)Accounts. Zu viele, eigentlich. Daher rufe ich nur die wichtigeren stündlich ab, und den Rest - das, was da und dort dabei ist oder früher mal intensiver genutzt wurde, bei Arcor, T-Online, GMX, web.de, Google, CVMX und wo auch immer - nur einmal pro Tag. Der entsprechende Cronjob meckerte seit Wochen, daß das Paßwort für den Googlemail-Account nicht passe, bzw. keines gespeichert sei (was daran liegt, daß ich mit den Servernamen experimentiert habe, und der Servername, unter dem das Paßwort in der .fetchmailrc liegt, nicht der Servername ist, mit dem fetchmail durch den Cronjob aufgerufen wird), was mir aber recht egal war, weil ich von dort eh nicht wirklich Mail erwarte.

Schade nur, daß fetchmail bei diesem Fehler dann abbricht. Was ich immerhin heute schon - zufällig - bemerkt habe. Das erklärt jetzt übrigens auch, warum ich im Zusammenhang mit dem GNUU-Ausfall keine Mailbenachrichtigungen bekommen habe … Nun, nachdem 200 Mails von diesem Account, 570 von jenem, 60 dort, 12 hier usw. eingesammelt waren, ist alles wieder gut.

Witzigerweise waren auch tatsächlich eine Handvoll "echte" und private Mails darunter. Aber keine älter als 8. Januar.

(Warum passiert mir sowas eigentlich dauernd? Und immer mit Mail? *grübel*)

Ich hätte doch sofort nach den schlechten Erfahrungen nach meinen eigenen Kontaktformularen schauen sollen. Dann wäre mir eine Peinlichkeit - und dem Netz eine weitere Belastung - erspart geblieben:

Ihre Kundennummer: *******
Ihre Vertragsnummer: *******

Guten Tag Herr Hochstein,

Sie verwenden auf Ihrer Präsenz das Skript
  /kunden/homepages/***/***/***/juh-nw/kontakt.php4

mit dem User
  p*******

welches gestern und heute für den Versand von Spammails massiv missbraucht
wurde. Da hierdurch ein erhebliches Mailaufkommen entstanden ist, sehen wir
uns gezwungen, das Skript unverzüglich zu sperren, um einen weiteren Miss-
brauch zu verhindern.
Einen entsprechenden Hinweistext README_SPAM.TXT haben wir Ihnen parallel
hierzu in das Skriptverzeichnis gelegt.

Bei Skripten, welche für den Spamversand missbraucht werden, handelt es
sich meist um sogenannte Formmail Skripte, welche Daten, die über eine
Webseite eingegeben werden, an bestimmte E-Mail-Adressen versendet.
Durch Lücken im Code dieser Skripte ist es oft möglich, diese E-Mails auch
an weitere Adressen als nur die beabsichtigten Empfänger zu verschicken.

Einige sichere Formen dieser Skripte finden Sie zum Beispiel unter:

  http://nms-cgi.sourceforge.net/scripts.shtml

Sollte es sich um ein Skript handeln, welches aus einem größeren Frame-
work wie z.B. CMS oder Forum stammt, sollten Sie sich an den Hersteller
wenden, um eine neue sichere Version zu erhalten. 

Bei Fragen helfen wir Ihnen gerne weiter. Ihre persönliche Rufnummer 
finden Sie in Ihrem 1&1 Control-Center unter Hilfe & Kontakt > Support.

Mit freundlichen Grüßen
1&1 Internet AG

Und das muß ausgerechnet mir passieren … Aber die alten Präsenzen dort hatte ich tatsächlich vergessen. Nun ja, jetzt sollte auch da alles wieder gut sein. Hoffe ich.

Der Morgen beginnt auch heute mit Rasieren, Zähneputzen und der Sichtung der Postmaster-Mailbox. Leider ist letztere ziemlich voll. Mit Bounces. Bounces von Spam an AOL-Adressen über meinen Server. *seufz*

Kurze Recherche ergibt als Verursacher einen "Kunden", bzw. dessen Kontaktformular, das die übergebenen Parameter nicht hinreichend prüft und so vermittels Übergabe eines Absenders, der einen oder mehrere Zeilenumbrüche enthält und unbearbeitet in den Mailheader eingefügt wird, die Übergabe weiterer Zieladressen außer der des hartkodierten eigentlichen Empfängers ermöglicht - die c’t berichtete vor Monaten. Nun gut, also das Script stilllegen, Verursacher anschreiben, Mailserver anhalten und die letzten hundert Spams aus der Queue werfen, und alles wird gut. War ja gottseidank nur AOL, da will ja niemand Mail einliefern. Hoffentlich langt das nicht für eine RBL-Nominierung, das wäre ärgerlich.

Und ich sollte mir fürs Wochenende notieren, auf jeden Fall auch nochmal alle meine eigenen Formulare auf den diversen von mir betriebenen Wbepräsenzen zu prüfen, ob überall entsprechende Überprüfungen eingefügt sind.

Eigentlich hätte ich mich schon lange wundern müssen, warum in meinen gegateten Mailinglisten überhaupt keine Mail mehr aufschlägt. Oder warum ich keine Benachrichtigungen über Systemjobs mehr bekomme, und auch keine Berichte mehr über Followups auf meine Postings. Nicht mehr jedenfalls, nachdem ich das Onlineupdate seine Arbeit tun ließ.

Heute, als ich gerade einmal früh ins Bett gehen wollte, fiel mir das allerdings auf, und ich wunderte mich - wunderte mich genug, um mal in die Mailqueue zu schauen. Ein mailq und viele hundert Zeilen Output später beginnt dann leichtes Wundern, da es sich da ganz eindeutig um die Ausgabe eines Postfix handelt - das auf der Maschine, dem heimischen Server, aber gar nicht in Betrieb ist. Stattdessen werkelt da ein selbstkompilierter Exim, das Postfix ist stillgelegt und nur deshalb nicht entfernt, weil der tatsächlich in Betrieb befindliche MTA nicht in der rpm-Datenbank steht und deshalb mit Postfix der scheinbar einzige MTA entfernt würde, was aus Dependency-Sicht suboptimal ist. *hüstel*