OX 6 – Upgrade von OX 6.20.7 auf OX 6.22.1 unter OS 12.2

Habe mich seit längerem nicht mehr um Upgrades des bei mir unter Opensuse 12.2 laufenden OX 6 kümmern können. Mein letzter Schritt war im letzten Jahr ein Update auf die Version 6.20.7 gewesen. Seitdem hat sich doch einiges geändert und demnächst steht auch die OX 7 App Suite vor der Tür.

Mögliche Upgrade-Pfade

Laut den Infos auf den einschlägigen Open-Xchange Webseiten sind folgende Upgrade-Pfade vorgesehen:

  • v6.20.7 auf v6.22.0 (man beachte die 0 bei der 6.22-er version!)
  • v6.22.x auf OX App Suite 7

Siehe hierzu:
http://oxpedia.org/wiki/index.php?title=Update_to_6_22
http://oxpedia.org/wiki/index.php?title=AppSuite:Upgrade_from_6.22_for_SLES11

Alle Wege führen also zwingend über die Version 6.22.0 !

Version 6.22 klingt harmlos. Diese Applikation bringt allerdings gegenüber den Versionen 6.20.X wesentliche Neuerungen mit sich. Insbesondere die Aufsplittung der Repositories für Server-Komponenten und das Ajax-Frontend. Zudem werden die bisher 2 Dämonen zum Starten des OX6-Systems zu einem zusammengefasst. Es verschwinden auch etliche der vielen bisherigen Pakete. Offenbar werden hier Änderungen vorgenommen, die in eine noch stärkere Rollenaufteilung zwischen einem komponentenbasierten Backend und mehreren unterschiedlich ausgeprägten Frontends in der App Suite münden werden.

Das machte mir dann doch ein wenig Angst vor einem Update des OX6 unter Opensuse 12.2. Die zugehörigen Infos in den OX-Webseiten entsprechen mehr denen eines echten Upgrades als eines kleineren Updates. Aber die nachfolgende Abbildung beweist, dass alles am Schluss glatt lief. Gezeigt wird der Blick von Kontact/Korganizer auf Kalender-Einträge auf meinem OX6 v6.22.1.

ox622_cal_600

Dennoch gab es ein paar kleinere Hürden zu überwinden, auf die ich nachfolgend eingehe.

Fehlendes Opensuse 12.2 Repository für die als Zwischenschritt erforderliche OX-Version 6.22.0

Unter den Repositories für Opensuse 12.2 findet man zwar bereits ein Verzeichnis für die App Suite. Das enthält aber noch keine Dateien. Also wollte ich auf meinem Opensuse 12.2-System zunächst nur das sowieso erforderliche Upgrade auf die Version v6.22 vornehmen.

Nun drohte dieses Vorhaben daran zu scheitern, dass sich im Moment kein Opensuse 12.2 Repository mit RPMs zur OX Version 6.22.0 mehr finden lässt. Vorhanden ist nur ein Repository zur Version v6.22.1. Dorthin führt aber z.B. von OX 6 V6.20.7 kein direkter Weg !

Umweg über ein 6.22.0 Repository für den SLES 11

Ich habe dann notgedrungen das Experiment gewagt, ein Repository für den SLES 11 zu benutzen. Ein solches Vorgehen ist nicht risikofrei. Bevor andere das nachmachen, empfehle ich unbedingt ein Backup der OX6 Datenbank auf seinem MySQL-Server, ein Backup der OX6-Verzeichnisse auf dem Apache-Server und ein Backup der OX6-Dateien – bei mir unter “/opt/open-xchange”.

Das von mir genutzten SLES11-Repositories findet man unter:
OX 6.22.0 Backend: http://software.open-xchange.com/OX6/6.22/6.22.0/backend/SLES11/
OX 6.22.0 Frontend: http://software.open-xchange.com/OX6/6.22/6.22.0/
frontend/SLES11/

Diese Repositories bindet man in die Paket-Verwaltung unter YaST2 ein. Unter YaST2’s Software-Update-Modul wechselt man dann am besten in die Ansicht für die “Installationsquellen”. Dort prüfe man für das Repository zum OX6-Backend und im Repository zum Frontend, welche Pakete als update-fähig angezeigt werden und hake die Einträge entsprechend ab. (Weiter unten findet man 2 Listen zu den erforderlichen Paketen). Man wundere sich beim Auflösen der Paketabhängigkeiten durch YaST2 nicht, dass dann sehr viele alte Pakete für als zu löschen markiert werden. Das hat tatsächlich seine Richtigkeit!

Ändern des OX6-Daemon-Starts über den Run-Level-Editor

Nachdem der Update gelaufen ist, muss man den Start des OX6-Daemons ändern. Die ursprünglich 2 Dämonen für die OX6-Groupware und die OX6-Administration sind nun zu einem Dämon zusammengezogen worden. Man nimmt die Änderungen am schnellsten über den YaST2-Runlevel-Editor vor. Ja, das geht auch unter den neuen systemd-Verhältnissen. YaST2 übersetzt die alten sysvinit-Angaben für diese konventionellen LSB-Applikationen unter systemd schon passend:

update_ox622_daemon_600

Nach dem Update funktioniert der OX6-Login über die Web-Oberfläche erstmal nicht – 503-Fehler

Hat man den OX6-Groupware-Server dann erneut gestartet, darf man sich ein kleines Frustrationserlebnis abholen. Versucht man sich nach den bisherigen Operationen auf dem OX6-Server über die OX6-Weboberfläche einzuloggen, so geht das schief. Egal, welchen User man probiert, man erhält eine “503-Meldung”: “Service temporarily not available”.

Zusätzlich tauchen in den OX6-Logs Fehlermeldungen zu fehlenden Sprachfiles auf.

Bevor du nun das Fluchen anfängt:
Prüfe erstmal, ob die Anbindung der Kalender-Clients unter OX6 funktioniert! Von dort klappt nämlich die Anbindung zum backend anstandslos, wie ich überrascht feststellen musste. So schlimm konnte der Fehler also nicht sein. Einige Minuten später stellte sich nach einem Blick auf den Webserver folgendes heraus:

Der Fehlschlag mit der OX6-Web-GUI liegt daran, dass für das 6.22-Frontend neue Pakete installiert werden müssen! Sieht man sich unter den OX6-Verzeichnissen seines Apache-Servers mal die Datumsangaben der installierten OX6-Files an, so wird man feststellen, dass der bisherige, oben beschriebene Update-Prozess die HTML- und Javascript-Files der früheren 6.20-Installation nicht angetastet hat. Der alte Client passt aber schlicht nicht zum neuen Backend! Wir korrigieren dieses Problem gleich im Zuge eines Upgrades auf die Version 6.22.1!

Upgrade auf die Version OX 6.22.1

Wir deaktivieren unter YaST2’s Paketverwaltung nun die OX 6.22.0-Repositories. Zusätzlich binden wir die aktuellen OX6-Repositories für OS 12.2 ein:

http://download.opensuse.org/repositories/server:/OX:/ox6.22:/frontend/openSUSE_12.2/
http://download.opensuse.org/repositories/server:/OX:/ox6.22:/backend/openSUSE_12.2/

Und nun stellen wir folgende Listen an Paketen für den Upgrade zusammen:

OX6-Backend (V6.22.1)
update_ox622_backend_600

Hier kommt zu den bisherigen Paketen eines für
die “de_DE”-Sprachunterstützung des Backends hinzu: open-xchange-l10n-de-de.

OX6-Frontend (V6.22.1)
update_ox622_frontend_600

Dies sind etliche Pakete mehr als beim Upgrade zu v6.22.0 ! Am wichtigsten ist das Paket “open-xchange-gui” ! Hinzu kommen Pakete zur deutschen Sprachunterstützung sowie zu Hilfe-Funktionen. Benötigt werden außerdem separate Pakete für die E-Mail-Account-Verwaltung und Plugin-Wizards:

open-xchange-gui-help-plugin, open-xchange-gui-help-plugin-gui, open-xchange-gui-l10n, open-xchange-gui-l10n-de-de, open-xchange-online-help-de-de, open-xchange-gui-themes-default, open-xchange-gui-loading-theme-default, open-xchange-gui-login-theme-default, open-xchange-gui-mail-accounts-plugin, open-xchange-gui-wizard-plugin, open-xchange-gui-wizard-plugin-gui

Man führe dann per YaST2 den Update zu diesen Paketen durch. Ein kurzer Blick auf den Webserver zeigt danach, dass dort jetzt aktuelle OX6-Web-GUI-Files mit einem neueren Datum vorliegen. Ferner ist jetzt auch das Verzeichnis “/opt/open-xchange/i18n” gefüllt.

Und jetzt klappt endlich auch der Web-Login für den OX6!

ox622_mail_600

Das Bild zeigt den Zugriff auf einen (separaten) IMAP-Server über den OX6! Der WE-GUI-Zugriff auf die im OX6 selbst verwalteten Kalender-Einträge, Aufgaben, den Infostrore, etc. funktionierten bei mir ebenso völlig anstandslos wie der Rest der upgedateten Web-GUI!

Ich musste nur bei einem einzigen User in die Datenbank eingreifen und dort den Email-Account für die Unified Mail (“unifiedinbox”) löschen. Bevor ich das tat, verweigerte OX6.22 für diesen speziellen Account jegliche Mail-Anzeige und deaktivierte das Mail-Modul. Die Ursache blieb unklar; aber das war mir auch egal, da dieser lokale Account sowieso nicht benutzt wurde. Bei keinem anderen User trat ein solches Problem auf!

Erfolgreicher Check des OX6-Zugriffs mit Kontact-Komponenten von KDE 4.10

Bleibt abschließend nur, den Zugriff von Kontakt/Organizer und vom Kontact/Addressbook (eiens aktuellen KDE 4.10) auf den OX6.22 zu prüfen. Der Zugriff läuft über Akonadi und da ist man bekanntlich nie vor Überraschungen gefeit.
Aber: Alles funktionierte auf Anhieb und ohne jede Änderungen oder Eingriffe. Der OX6-Konnektor von Akonadi funktioniert also auch mit OX 6.22.1 ! Interessant, dass auch die “Address Auto Completion” von Kmail 4.10 beim Zugriff auf das OX6-Adressbuch keine größeren Zicken machte. Soweit ich sehen kann, werden die vorhandenen Adressen genauso gut (oder schlecht) wie zuvor angezeigt. Sehr gut funktionierte CUH der Web-Dav-Zugriff auf die Verzeichnisse des InfoStore über Dolphin!

Geht doch !

Der Linux-Blog läuft endlich nicht mehr als 1&1 Applikation

Jahrelang habe ich meinen Linux-Blog als 1&1-Applikation genutzt. Das war am Anfang bequem, entpuppte sich aber mehr und mehr als Dummheit. Für den wachsenden Unmut waren folgende Gründe ausschlaggebend:

  • Man war bei 1&1 auf vorgefertigte und z.T. nicht fehlerfreien 1&1 Layouts begrenzt.
  • Das Verzeichnis mit den WordPress-Programm-Dateien war nicht zugänglich. Damit hatte man auch keinen Zugriff auf die Konfigurationsdatei.
  • Man kam nicht an die in irgendwelchen 1&1-Datenbanken hinterlegten Daten heran.
  • Es gab keine Export-Funktion in der von 1&1 beschnittenen Blog-Verwaltung.
  • Man konnte die Subdomaine/Domaine, unter der der 1&1-Blog eingerichtet war, nicht ohne ein gleichzeitiges Löschen aller Blog-Inhalte auf ein anderes Server-Verzeichnis legen.

Das alles waren Einschränkungen, mit denen 1&1 eine Kundenbindung erzwang. Ein einfacher Wechsel des Providers oder auch nur eine Übernahme des Blogs in selbst verwaltete Datenbanken und Webserver-Verzeichnisse war praktisch ausgeschlossen, weil das immer mit einer Aufgabe des Blogs und einem Verlust der Daten verbunden gewesen wäre. Nun konnte ich aber die von 1&1 zur Zeit systematisch vorgenommene Umstellung auf eine neuere WordPress-Version nutzen, um mich endlich ein wenig unabhängiger zu machen.

Das war auch bitter und dringlichst notwendig. Denn die heute von 1&1 vorgenommene sogenannte “Umstellung” erwies sich als nicht gelungen; 1&1 hat bei der Migration des Blogs offenbar wenig Wert auf ein sauberes Vorgehen gelegt:

  • Kein adäquates Layout mehr nach der “Umstellung”:
    Ich hätte erwartet, dass das von 1&1 früher angebotene und von mir vor Jahren gewählte Layout vorab überarbeitet und an die aktuelle WordPress-Version angepasst worden wäre. Man möchte seinen Blog nach einer Migration natürlich wieder mit dem Aussehen vorfinden, zu dem 1&1 einen früher verführt hatte. Weit gefehlt: Nach der Migration fand ich meinen Blog statt in dem früher von mir gewählten Layout im öden blauen WP-Basis-Layout vor. Und keines der früheren 1&1-Layouts war im Theme-Angebot zu finden.
  • Englisch als Standardsprache:
    Das zweite Übel bestand darin, dass die Sprache auf Englisch umgestellt worden war und dass die Datenbank nun unter UTF8 läuft. Leider war dies in den migrierten Datenbankdaten nicht nicht überall berücksichtigt worden. Das verhunzte u.a. alle Kategorie-Namen, die Umlaute enthalten hatten. Die Kategorie-Bezeichnungen wurden ab dem ersten Umlaut schlicht abgeschnitten.
  • Alle Posts waren nach der Migration für eine Kommentierung freigegeben:
    Noch viel schlimmer bewerte ich die Tatsache, dass das Spamaufkommen zu meinem Blog etwa 1 Stunde nach der Umstellung von 161 abrupt zunahm. Ursache hierfür war, dass das früher eingestellte Verbot einer Kommentierung von Artikeln nach der 1&1-Migration aufgehoben war.

Diese Art der Umstellung erfolgte wie gesagt heute und hatte mir erstmal einen kleinen Schock versetzt. Mein IMAP-Server füllte seinen Spam-Ordner und der Blog sah schlicht furchtbar aus. Das mochte ich meinen Lesern nicht zumuten.

Nachdem ich einen ersten Wutanfall überwunden hatte, habe ich dann den heutigen Nachmittag genutzt, um den Blog unter meine eigenen Fittiche zu bekommen. Vielleicht haben einige meiner Leser ja auch den Wunsch, sich im Zuge der “1&1-Migration” ihres Blogs sich diesbezüglich von 1&1 abzunabeln. Glaubt mir: So günstig erhaltet ihr vermutlich nie wieder die Chance, eure Daten auf einfache Weise und völlig ohne jedes Hacking in den Griff zu bekommen.

Also – nachfolgend findet ihr einen kleinen Handzettel zur

“Migration eures Blogs weg von der 1&1-Wordpress-Applikation in eine selbst kontrollierte Web-Präsenz”.

Diese selbst kontrollierte Web-Präsenz kann durchaus wieder bei 1&1 liegen – wichtig ist nur die eigene Kontrolle über die WordPress-Dateien und die WordPress-Daten (u.a. die der wertvollen Posts) in einer selbst verwalteten Datenbank.

Zur Vorbereitung der Migration habe ich mir zunächst genauer angesehen, ob ich die Daten meines Blogs nicht mit den Standardfunktionen der neuen WordPress-Version exportieren könnte. Ja das ging; das war von 1&1 diesmal nicht abgestellt. Also hatte ich nun schon mal eine XML-Datei meiner Daten als letzten Notanker. Leider musste ich dann feststellen, dass ein Import in einen kurzfristig installierten eigenen WordPress-Blog nicht funktionieren wollte. Vielleicht weil das Import-Plugin nicht mit der aktuellen WordPress-Version zusammenspielt (s. hierzu auch: http://blog.trisepo.com/archives/61/ ) oder weil der Import in meinem Fall alle gesetzten PHP- und MySQL-Zeitlimits auf den 1&1-Servern überstieg. Letzteres war und ist in meinem Fall mehr als wahrscheinlich.

Dann habe ich mir angesehen, auf welches Verzeichnis die Subdomaine meines 1&1-Blogs nach der Migration umgelenkt wurde. Und oh Wunder: Dieses Verzeichnis war zumindest für eine Weile in den Serververzeichnissen meines Hosting-Paketes bei 1&1 zugänglich! Damit hat man dann schon fast gewonnen:

Schritt 0: Man führe als allererstes eine Sicherung des gesamten neuen WordPress-Verzeichnisses durch. Danach studiere man die WordPress-Konfigurationsdatei “wp-config.php” des Hauptverzeichnisses. Die dort angegebenen Daten sind in zweierlei Hinsicht bedeutsam:

Erstens werden die Verbindungsdaten zur Datenbank angegeben, auf die 1&1 den Blog nun migriert hatte. Diese Datenbank ist ja nicht unter den normalen Banken zu finden, die dem eigenen 1&1-Paket zugeordnet sind. Damit sind sie auch nicht über die 1&1-MySQL-Verwaltung zugänglich. Zweitens enthält die Datei wichtige Angaben zu den Verschlüsselungsverfahren, die 1&1 zum Hashen der Passwörter verwendet. Diese Daten sind sehr wichtig, wenn man bei der Abnabelung Probleme mit den Passwörtern vermeiden will.

Die nächsten Schritte zur Abkopplung von der 1&1-Wordpress-Applikation sind dann folgende:

Schritt 1: PhpMyadmin in der eigenen Webpräsenz bei 1&1 installieren. Dort in der PhpMyAdmin-Konfiguration die Zugriffsdaten für die 1&1-Datenbank des migrierten 1&1-Wordpress-Blog eintragen. In diese 1&1-Datenbank kann man sich dann mit PhpMyAdmin einloggen. Jetzt erstmal die gesamte Bank per PhpMyAdmin-Export in eine Datei sichern und diese herunterladen. Dann erneut auf die Bank zugreifen und die Tabellen mit den angehäuften WordPress-Daten der letzten Jahre einzeln (!) exportieren.

Man tut einfach gut daran, Tabelle für Tabelle in separaten Dateien zu sichern und herunterzuladen – nicht alle Tabellen in einem einzigen Export-File. Gründe: Der spätere Import in eine selbstverwaltete Datenbank würde bei einer einzigen, großen Datei ggf. zu lang dauern und die Limit des Providers sprengen. Ferner muss man später in der Sicherungsdatei für die Tabelle der Posts per Editor die Link-Adressen aller Artikel ändern (s.u.). (Das Arbeiten an der Datei ist aus meiner Sicht jedenfalls das schnellste und einfachste Verfahren.)

Schritt 3: Download einer aktuellen (deutschen) WordPress-Version (Version 3.5.1) aus dem Web. Danach Upload der zugehörigen Verzeichnisse und Dateien in ein neues Blog-Verzeichnis auf dem gewünschten eigenen Web-Server. Aber danach bitte keine WordPress Installation vornehmen! Wir migrieren in den nachfolgenden Schritten vielmehr alle Tabellen und Daten aus der bisherigen 1&1-Blog-Installation und nutzen deren Konfigurationsdatei nach der
Durchführung erforderlicher Änderungen.

Schritt 4: Mit PhpMyAdmin eine eigene Datenbank auf einem eigenen DB-Server einrichten. Dann die vorher heruntergeladenen Sicherungsdateien der WordPress-Tabellen in die eigene Datenbank importieren. Ausnahme: Die Sicherungsdatei für die Tabelle, die die “Posts” enthält. Die erkennt man in der Regel am Namen (“…_wp_posts”). Die Namen aller anderen, durch die PhpMyAdmin-Importe erzeugten Tabelllen in der eigenen Datenbank nun durch eigene Namen ersetzen: Dies dient nur dazu, das 1&1-Tabellenprefix mit einem eigenen zu ersetzen (z.B.: myblog_wp_…. ). Die hinteren Namensanteile der Tabellen lassen wir dagegen unverändert.

Schritt 5: In den Tabellen “myblog_wp_usermeta”, “myblog_wp_options” alle erforderlichen Anpassungen vornehmen. (“myblog_wp_” ist natürlich durch den gewählten eigenen Prefix zu ersezen!) Die erforderlichen Änderungen betreffen u.a. die Rechtevorgaben an den Tabellen – man erkennt die alten Tabellen-Prefixes leicht in den entsprechenden Tabellenspalten. Diese Tabellenverweise muss man nun an die neuen Tabellen-Namen mit dem eigenen Prefix anpassen. Änderungen sind aber auch für die Domain-Angabe zum neuen, selbst verwalteten Blog erforderlich. Die bisherige Domain-Bezeichnung muss durch die Bezeichnung der künftigen (Sub-) Domaine für den neuen Blog ersetzt werden.

Wichtiger Hinweis: Man sollte dem neu eingerichteten Blog in jedem Fall so lange eine andere Domaine als die des bisherigen 1&1-Blog zuordnen, bis der neue Blog richtig läuft. Erst danach kann man den alten (Sub-) Domainnamen von 1&1 umlenken. Beachte: Eine Domain-Umlenkung und Akopplung von der 1&1-Blog-Applikation ist mit einer endgültigen Zerstörung aller Blogdaten bei 1&1 verbunden – das genau war ja deren Folterinstrument zur Kundenankettung. Und dieses Risiko nehmen wir erst nach einer erfolgreichen Blog-Migration auf uns.

Schritt 6: Editieren einer Kopie der per PhpMyAdmin erzeugten Sicherungsdatei für die Tabelle zu den Posts. Z.B. mit einem flexiblen Editor wie Kate. Kate muss dabei auf sehr (!) lange Zeilenlängen (ggf. 100000 Zeichen) eingestellt werden. Dann im File den alten Domainnamen durch den gewünschten neuen an allen vorkommenden Stellen ersetzen. Damit wird die URL der Artikel geändert. In den Statements der Datei für die Tabellengenerierung ist zudem der bisherige 1&1-Tabellennamen durch den gewünschten neuen mit dem eigenen Prefix zu ersetzen.

Schritt 7: Importieren des geänderten Files für die “Posts”-Tabelle per PhpMyAdmin in den eigenen Datenbankserver. Die erzeugte Tabelle sollte dann gleich die richtige Bezeichnung haben.

Schritt 8: In der Dateisicherung der 1&1-Wordpress-Dateien die Konfigurationsdatei “wp-config.php” ausfindig machen. Eine Kopie für Änderungen und den späteren Upload auf den eigenen Server erstellen. Diese Kopie muss nun editiert werden. U.a. muss die dortige Konfigurationsvorgabe für die Sprach-Einstellung explizit auf “de_DE” umgestellt werden. Ferner sind die neuen, eigenen Datenbankzugangsdaten einzugeben. (Gemeint ist hier natürlich die eigene Bank, auf der man den neuen Blog zum Laufen bringen will – also die Bank auf die man die Tabellen hochgeladen hat). Auch das Prefix für die Datenbank-Tabellen ist in den config-Einstellungen anzupassen. An den Verschlüsselungseinstellungen (Key- und Salt-Angaben) aber bitte nichts ändern! Das würde nämlich alle alten Passwörter unbrauchbar machen! Dann die veränderte Konfigurationsdatei unter dem Namen “wp-config.php” in das WordPress-Hauptverzeichnis der eigenen Installation hochladen.

Schritt 9: In der Datei-Sicherung des bisherigen 1&1-Blogs das Verzeichnis “wp-content/uploads” ausfindig machen. Dann ganzen Inhalt diese Verzeichnisses in das entsprechende Verzeichnis der neuen Blog-Installation hochladen. (Damit füllen wir die Mediathek des neuen
Blogs in konsistenter Weise zu den migrierten Datenbankdaten).

Schritt 10: In seiner Web-Präsenz eine (Sub-)Domaine für den neuen, eigenen Blog anlegen oder anlegen lassen. Dann diese (Sub-) Domaine auf das Verzeichnis der WordPress-Installation in der eigenen Webpräsenz lenken.

Schritt 11: Durchatmen, kurz Mut fassen und sich mit den alten Administrator-Zugangsdaten im neuen Blog unter dem (neuen) Domainnamen einloggen.

Schritt 12: Für alle alten Posts ggf. als erstes wieder die Kommentierungssperre setzen, die 1&1 während deren Umstellung aufgehoben hatte.

Schritt 13: Überprüfung und Setzen aller weiteren Einstellungen des Blogs. Wichtig ist auch hier die temporäre Umstellung der URL des Blogs unter “Einstellungen   >   Allgemein” auf die neue (Sub-) Domaine.

Schritt 14: Ändern des Layouts durch die Auswahl eines Themes, Nutzen der WordPresss Tools und durch Manipulation der CSS-Dateien des geladenen Themes. Da dieser Schritt einige Zeit in Anspruch nehmen kann, kann man ihn auch auf später verschieben.

Schritt 15: Überarbeiten der Kategoriebezeichnungen mit Umlauten, die ggf. von 1&1 während deren Blog-Umstellung zerstört worden waren.

Schritt 16: Alles sichern (Datenbanken und Dateien).

Schritt 17: Wenn der neue, selbstverwaltete Blog sauber läuft und alle Artikel inkl. Bilder und Anhängen anzeigt werden: Den alten Domainnamen bei 1&1 von der 1&1-WordPressP-Applikation lösen – dies bedeutet dann allerdings die unwiederbringliche Löschung aller alten Blog-Daten bei 1&1. Aber die hatten wir ja in den ersten Schritten bereits gesichert. Danach Zuweisung der (Sub-)Domaine zum neuen Blog-Verzeichnis, falls dieses in einer eigenen Web-Präsenz bei 1&1 liegt. Falls nicht, eine Domain-Umlenkung auf die neue Domaine vornehmen.

Schritt 18:Läuft dann auch unter dem alten Domainnamen alles wie gehabt, kann man zumindest im Fall einer Webpräsenz bei 1&1 alle Einstellungen zur Domain-URL des Blogs wieder auf die alten Einstellungen zurücksetzen. Dies geschieht teilweise durch Benutzung der Verwaltungsoberfläche “Einstellungen   >   Allgemein”, teilweise durch direkten Eintrag in die bereits genannten Datenbank-Tabellen, bzgl. der Posts aber durch Export der Tabelle in eine Datei, Überarbeiten der dortigen Adressangaben per Editor und Reimport der Tabelle.

Schritt 19: Einstellen des PING-Mechanismus unter “Einstellungen   >   Schreiben” zur Benachrichtigung von anderen Blog- und Crawler-Engines. Unter
http://www.instant-info-online.com/wordpress-compressed-all-inclusive-ping-list.html
wird zur Vermeidung von Mehrfachpings folgende komprimierte Liste empfohlen:

http://rpc.pingomatic.com
http://blogsearch.google.com/ping/RPC2
http://ping.myblog.jp

Dies liste funktioniert nach meiner Erfahrung sehr gut.

Schritt 20: Ggf. Installation eines Ping-Optimizer-Plugins zur Begrenzung des selbst verursachten Ping-Aufkommens, um beim eifrigen Bloggen nicht zum Ping-Spammer zu werden.

Und das wars dann schon. Viel Spass mit dem Bloggen unter eigener Kontrolle der erzeugten Daten.

Spam-Schutz von E-Mail-Adressen im Web-Impressum ?

Gestern erhielten wir eine Kundenanfrage: Was man denn tun könne, um eine in der Kunden-Webseite enthaltene E-Mail-Adresse vor Spam-Mißbrauch zu schützen?

Das ist eine Frage, die sich keineswegs so eindeutig und einfach beantworten ließe, wie man zunächst meinen könnte. Gräbt man sich erst einmal in die Thematik ein, umso schwieriger stellt sie sich dar. Man gelangt zudem schnell in rechtliche Grauzonen – besonders in Hinblick auf die genaue Form der Angabe der E-Mail-Adresse auf der Impressum-Seite einer Website.

Ich nehme es vorweg:

Ich beleuchte in diesem Artikel zwar die Thematik des Spam-Schutzes von E-Mail-Adressen in Websites unter verschiedenen Blickwinkeln – aber eine explizite Vorgehensempfehlung für Impressum-Webseiten spreche ich nicht aus. Ich rate diesbzgl. vielmehr zu rechtlicher Beratung.
Mein letztliches Fazit wird sein: Investiert lieber in gute Spamfilter !

Wem das als Ergebnis zu wenig ist, erspare sich einfach die weitere Lektüre. Andere Leser werden aber hoffentlich den einen oder anderen erwägenswerten Gedanken finden. Zumindest habe ich versucht, die Grenzen bestimmter Maßnahmen aufzuzeigen und plausibel zu machen.

Rechtliche Aspekte im Zusammenhang mit der E-Mail-Adresse auf der Impressum-Seite einer Web-Präsenz

Meine erste reflexartige Frage an den erwähnten Kunden war, ob er denn die E-Mail-Adresse auf der Impressum-Seite meinen würde und ob er sich über die rechtlichen Vorgaben in Deutschland im Klaren sei. Soweit man sich denn als juristischer Laie darüber überhaupt klar werden kann.

Die gesetzliche Vorgabe und den formalen Maßstab für die erforderliche E-Mail-Angabe auf der Impressumseite einer Website liefert das Telemediengesetz (“TMG”; http://www.gesetze-im-internet.de/bundesrecht/tmg/gesamt.pdf). Wie viele andere Gesetze ist auch dieses interpretationsfähig. Am Ende des Artikels habe ich deshalb Links zu Webseiten zusammengestellt, in denen sich Andere – z.T. Juristen – mit dem Thema auseinandergesetzt haben.

Dem aufmerksamen Leser wird bei der Lektüre solcher und anderer Beiträge zur Rechtssituation kaum entgehen, dass z.B. der Einsatz von elektronischen Grafiken anstelle einer E-Mail-Adresse im Klartext auf der Impressumseite durchaus umstritten ist. Sehen Sie hierzu u.a.: http://www.datenschutzbeauftragter-info.de/impressum-spam-schutz-grafik-e-mail/
Bzgl. der Zulässigkeit von Verfremdungen der E-Mail-Adresse als Anti-Spam-Maßnahme wird die rechtlich verlässliche Information für Impressum-Seiten schnell noch weniger als dünn.

Meine laienhafte Interpretation und Zusammenfassung der im Web zusammengestellten Kommentare oder Empfehlungen ist folgende:

Die Angabe der E-Mail-Adresse ist bis auf wenige Ausnahmen, die auf unsere Kunden i.d.R. nicht zutreffen, grundsätzlich Pflicht. Eine einfache elektronische Kontaktaufnahme soll möglich sein. Auch ein kurzfristiges Beantworten von Fragen muss ermöglicht werden. Ein Kontaktformular allein reicht dazu nicht aus. Nicht nur im Impressum kommerziellen Sites müssen Telefonnummer und/oder Faxnummer daher zusätzlich zur E-Mail-Adresse angegeben werden.
 
Mit großer Wahrscheinlich gilt ferner, dass ein Besucher der Website die E-Mail-Adresse auch bei Benutzung nichtgrafischer Browser oder von Screen-Readern herausfinden können muss. Hier zieht aus meiner Sicht ein Verbot der Benachteiligung von Mitbürgern mit einer Sehbehinderung.

Sollte diese Interpretation stimmen, dann ergibt sich fast zwangsläufig:

  • Elektronische Bilder statt (ggf. leicht verfremdeter)
    Klartext-Adressen auf der Impressum-Seite sind zu vermeiden.
  • Bestimmten Verfremdungen der E-Mail-Adresse durch CSS-Verfahren oder durch den Einsatz javascript-basierter Mechanismen sind auf der Impressumseite mit hoher Wahrscheinlichkeit Grenzen gesetzt.

Dazu unten mehr.

Schutz vor was?

Eine weitere Fragen an den Kunden ist:
Welche Aktion eines Spammers zur Erlangung einer E-Mail-Adresse genau willst du denn abwehren? Das Erfassen durch Hinschauen? Oder das Erfassen durch maschinelle Analyse des HTML-Codes und/oder von Javascript-Programmen? Und zu welchem Preis willst du das verhindern?

Wenn man die E-Mail-Adresse auf der Impressum-Seite mal außer Acht lässt, könnte man ja auf den Gedanken kommen, auf bestimmten Seiten der Web-Präsenz Web-Formulare zur Kontaktaufnahme einzusetzen, um so die Angabe einer E-Mail-Adresse ganz zu vermeiden. Ist das wirklich so einfach, wie es sich anhört? Sind Web-Formulare problemfrei?

Als Maßnahme gegen automatisierte Auswertung des HTML-Codes werden im Web auch auch mehr oder weniger aufwändige Methoden zur Verfremdung von E-Mail-Adressen diskutiert. Dabei hegt man die Hoffnung, das eine solche Hürde wenigstens einen Teil der Spammer abhält. Wie berechtigt ist diese Hoffnung eigentlich ?

Schutz gegen Hinschauen?

Oftmals will man seine E-Mail-Adresse auf einer Webseite gar nicht visuell verbergen. Denn eine Kontaktmöglichkeit für ernsthafte Besucher der Webseite oder gar Kunden soll ja ermöglicht werden! Und auf der Impressum-Seite ist die Angabe der E-Mail-Adresse in Deutschland ja in der überwiegenden Anzahl der Fälle sowieso ein Muss (s.o.).

Die oft beschworene Methode, zum Schutz vor Spam ein elektronisches Bild statt Klartext auf der Webseite einzusetzen, entspricht genau dieser Motivation. Geschützt wird die E-Mail-Adresse dabei bewusst nur gegen maschinelle Programme wie Spam-Bots/Crawler und eben nicht gegen den Blick eines neugierigen Betrachters.

Dies bedeutet umgekehrt, dass natürlich auch ein Spammer die E-Mail-Adresse auf der Webseite durch schlichtes Hinschauen erfassen kann. Vor dem “Hingucken” und “Verstehen” eines Angreifers schützen tatsächlich die allerwenigsten adressbezogenen Anti-Spam-Verfahren. Im “Hingucken” des Spammers finden auch alle Verfahren zur Verfremdung der E-Mail-Adresse ihre Grenze. Hierbei meine ich nicht mal allein das Hinschauen mit den Augen – mafiös organisierte Spammer werden auch den Aufwand mit Bild- und OCR-ähnlichen Auswertemethoden nicht unbedingt scheuen.

Nun könne man meinen, OCR-Verfahren und Hingucken seien ineffektiv. Aber es gilt:

Ist eine E-Mail-Adresse erst einmal bekannt, kann sie direkt als Teil einer wachsenden Adressliste in den einschlägigen Spammer-Kreisen vermarktet werden.

Damit dreht sich die Diskussion im Kern eigentlich um die Frage nach dem Verhältnis von Nutzen zu Aufwand auf der Seite des Spammers. Lohnt es sich für Spammer im Einzelfall, physisch “hinzuschauen” statt die Ergebnisse von Bot- und Crawler-Programmen heranzuziehen? Ich persönlich glaube leider, dass diese Frage zunehmend mit ja zu beantworten ist.

Diese Einschätzung nährt sich aus der Analyse der Spam-Angriffe auf eine von uns betreute Website, auf der Captcha-Verfahren zum Einsatz kommen. Hier zeigt sich, dass immer wieder Aktionen vorkommen, bei denen der begründete Verdacht naheliegt, dass der Spammer (oder ein von ihm abhängiger Billiglohn-Arbeiter?) eine manuelle Eingabe des Captcha-Codes durchgeführt hat und nicht ein Programm. Nun könnte man weiter vermuten, dass solche manuellen Schritte primär dem Austesten des Captcha-Verfahrens dienten. Aber das ist ja genau der Punkt:

Wenn sich im Einzelfall ein solcher manueller Test lohnt, dann
lohnt sich das Hinschauen auf E-Mail-Adressen ggf. auch. Man darf dabei nicht vergessen, dass es weltweit traurigerweise sehr viele sehr billige Arbeitskräfte gibt, die “professionelle” Spammer-Organisationen einsetzen können. Geht man von einer bis zwei manuell erfassbaren Adressen pro Minute aus, so kann bereits eine einzelne Person viele hundert Adressen pro Tag in guter Qualität “ernten”.

Stimmt diese Mutmaßung, so relativiert das den Sinn aufwändiger Anti-Spam-Maßnahmen doch sehr. Geld und größere Anstrengungen sollten dann eher in die Auswahl und Implementierung guter Spam-Filter für die E-Mail-Systeme fließen – nicht nur beim Endverbraucher sondern in der gesamten E-Mail-Transfer-Kette, auf die man einen Einfluss hat.

Einsatz elektronischer Bilder statt einer E-Mail-Adressangabe im Klartext?

Bilder sind im Zusammenhang mit Webseiten vor allem eines: sie sind nicht barrierefrei !

Dies benachteiligt Menschen mit Sehbehinderung bei der Kontaktaufnahme eindeutig. Auf der Impressumseite einer Web-Präsenz ist der Einsatz eines Bildes für die Angabe der E-Mail-Adresse deshalb wohl als sehr kritisch einzustufen. Siehe hierzu u.a. folgenden interessanten Artikel:
http://www.shopbetreiber-blog.de/2011/02/24/abmahnung-impressum-grafik/.
Ich finde die dortigen Argumente nachvollziehbar und denke wie der Verfasser, dass man eine Bild-“Lösung” aus rechtlichen Gründen in Deutschland eher vermeiden sollte.

Ferner gibt es auch kosmetische Nachteile von Bildern: Man bekommt die Schrift im Bild trotz des Leistungsvermögens von Bildbearbeitungsprogrammen manchmal nicht genau so hin, dass sie aussieht wie die vom Browser generierte Schrift. (Etliche Nutzer erlauben eine Darstellung im Browser sowieso nur mit vorgegebenen Fonts anstelle derjenigen, die der Webseiten-Code vorsieht.) Linienartige Inhalte bestimmter elektronischer Bildformate werden beim Skalieren der Web-Seite durch den Anwender ggf. verzerrt – hier sind gerade ältere Browser anfällig. Die krakeligen Schriften sehen dann halt nicht schön aus.

Einsatz von Kontaktformularen ?

Will man seine E-Mail-Adresse auf bestimmten Web-Seiten visuell absolut nicht preisgeben und trotzdem eine elektronische Kontaktaufnahme jenseits von Telefon und Fax ermöglichen, so kann man alternativ serverbasierte Kontakt- und Anfrage-Formulare auf der Webseite anbieten. Dabei betone ich nochmals folgende Einschränkung:

Auf einer Impressum-Seite ist gem. TMG ein Kontaktformular allein nicht hinreichend ! Selbst als Ersatz für eine Telefonummer muss die interne Handhabung des Kontaktformulars offenbar bestimmten Anforderungen genügen. U.a. soll eine maximalen Weiterleitungs- und Reaktionszeit von 60 Minuten gewährleistet sein. Sehen Sie hierzu bitte die Links am Ende des Artikels.

Ferner muss man sich die Frage stellen: Welche Schwierigkeiten bringt denn der Einsatz elektronischer Kontaktformulare auf Webseiten ggf. mit sich? Sind diese denn gegen Spam gefeit?

Nein, das sind sie natürlich nicht! Kontakt-Formulare, die ohne E-Mail-Adressangabe im HTML- oder einem Javascript-Code auskommen, beruhen meist auf einer Server-Skript-Sprache wie PHP. Ein Skript wertet die per POST- oder GET-Verfahren übergebenen Daten aus. Daten lassen sich aber mit Schad- und Spamcode befrachten. Auch Web-Formulare müssen deshalb natürlich gegen die Übergabe von Spam und gegen andere elektronische Angriffe geschützt werden! Formulare sind ohne Zusatzmaßnahmen geradezu ideale und prädestinierte Ziele für maschinelle, elektronische Angriffe! Davon können gerade Administratoren von Blogs und Foren ein Lied singen!

Erforderlich ist zum einen eine rigorose Prüfung der übergebenen Daten, um XSS-Angriffe und andere Angriffsvektoren, die auf die
Datenhaltung am Server zielen, zu vermeiden. Diese Thematik ist nicht gänzlich trivial. Entsprechende Maßnahmen schließen aber übergebene Spaminhalte noch nicht aus. Als Anti-Spam-Schutzmaßnahme werden in Web-Formularen deshalb zusätzlich sog. Captcha-Verfahren eingesetzt. Captcha-Programme stellen dem Besucher einer Website Aufgaben oder erfordern eine Analyse visueller Bilder mit verzerrten alphanumerischen Zeichensequenzen. Die Hoffnung dabei ist die, dass diese Aufgaben nur von Menschen und nicht von einer Maschine oder einem Programm gelöst werden können. Das mag im Einzelfall ja so sein. Es hat sich in unserer Praxis aber auch gezeigt, dass bei unzureichend programmmierten Captcha-Verfahren die statistische Verteilung der generierten Zeichen oder Aufgabenbestandteile keineswegs so zufällig ist, wie vom Laien oder Gelegenheitsprogrammierer oft angenommen. Es gibt durchaus Beispiele, in denen die von Pseudo-Zufallszahlengeneratoren (PRNG) erzeugten Catcha-Sequenzen vorhersagbar sind. Hierzu mehr in einem anderen, separaten Artikel. Beim Einsatz von Web-Formularen muss man also sehr auf die Qualität der verwendeten Captcha-Verfahren achten.

Ein grundsätzlicher Nachteil rein visueller Captcha-Verfahren ist in jedem Falle die nicht gegebene Barrierefreiheit! Das schließt deren Einsatz auf Impressum-Seiten aus meiner Sicht aus.

Zudem kann man darüber streiten, ob das Lösen einer Captcha-Aufgabe der Anforderung einer leichten Kontaktaufnahme nicht im Wege steht. Die angeführten Punkte gelten übrigens gleichermaßen für den Einsatz von Verfahren, bei denen der visuelle Zugang zu einer E-Mail-Adresse erst nach der Lösung einer Captcha-Aufgabe freigegeben wird.

Fazit zum Einsatz von Web-Formularen:
Der Einsatz von elektronischen Kontaktformularen verschiebt das Problem von Spamangriffen und anderen ggf. noch gefährlicheren elektronischen Angriffsverfahren nur auf andere elektronische “Schlachtfelder”. Auf Impressum-Seiten kann ein Formular die Angabe der E-Mail-Adresse sowieso nicht ersetzen.

Schutzmaßnahmen gegen eine automatisierte Auswertung des HTML-Codes ?

Das, was auf einer Webseite sichtbar ist, ist in der Regel auch im HTML-Code oder im Javascript-Code, der an den Browser übermittelt wurde, in lesbarer Form hinterlegt. Solche Inhalte können dann durch Bot- und Crawler-Programme automatisiert erfasst werden. Das gilt i.d.R. auch für Mail-Adressen.

Im Laufe der Zeit wurden verschiedene Ansätze ausprobiert, die auf einer Webseite bzw. im Impressum angegebene E-Mail-Adresse entweder schon im Klartext oder zumindest im HTML-Code zu “verfremden” und dadurch schützen. Eine gute Übersicht zu den eingesetzten Methoden liefert folgende Web-Seite unter “drweb.de”:
http://www.drweb.de/magazin/wirklich-wirksamer-schutz-fr-e-mail-adressen/

Unter den dort diskutierten Varianten spricht der sehr geringe Realisierungsaufwand, der zudem keine Spezialkenntnisse voraussetzt, für CSS-basierte Verfremdungsansätze in Kombination mit folgenden zusätzlichen Verfahren:

  • Klartext-Verfremdung nach dem Muster “renate (dot) musterfrau [at] gmx (dot) de” (oder Teilen dieses Musters)
  • HTML-Code-Verfremdung mit Hilfe des Ersatzes von Klartext durch UTF8-Zeichencode-Nummern.

Zur Umsetzung des letzten Ansatzes helfen im Netz zugängliche UTF8-Übersetzer; siehe etwa:
http://www.internetende.com/mailadresse.htm”>http://www.internetende.com/mailadresse.htm

Zwei gängige CSS-basierte Verfahren – nämlich die “Umkehrung der Zeichenreihenfolge” und die “Integration von im Browser nicht dargestellten Tags” –
sind im oben zitierten Dr.Web-Artikel explizit ausgeführt. Ich erspare mir deshalb eine explizite Beschreibung des Codings an dieser Stelle.

All diese Ansätze sind jedoch kritisch zu würdigen – sowohl unter dem Gesichtspunkt der technischen Umgehung als auch in Bezug auf ihren Einsatz auf Impressum-Seiten:

Kritikpunkt 1 – Leichte Umgehbarkeit durch Spam-Bots
Ich arbeite auch als Entwickler. Meiner begründeten Meinung nach gilt grundsätzlich, dass alle (!) genannten Ansätze programmtechnisch mit relativ geringem Aufwand ausgehebelt werden können. Das ist sogar so einfach, dass ein Spam-Bot-Programmierer, der diese Möglichkeit nicht nutzt, eher als faul zu bezeichnen wäre. CSS-basierte Schutzmaßnahmen können durch ein Minimum an Tag- und CSS-Analyse und Aufhebung der CSS-Anweisungen unwirksam gemacht werden. Noch einfacher geht es durch Auswerten eines bereinigten Zeichenstroms, der von einem hinreichenden HTML/CSS-Interpreter ausgespuckt wird. Noch simpler ist es, UTF8-Zeichencodes zu erkennen und zu übersetzen. Gleiches gilt für den Einsatz von verfremdenden Blanks, Klammern und verschiedenen Formen eines ausgeschriebenen “at”, “Ät” etc.. Wir sind hier wieder mal bei der Frage gelandet: Welcher Aufwand lohnt sich für die Spam-Mafia?

Dennoch: Da der Aufwand zur Implementierung dieser Hürden auch auf unserer Seite klein ist, sehe ich keinen prinzipiellen Grund, diese minimalen Barrieren gegen Spammer nicht zu nutzen. Aber man muss sich über Folgendes im Klaren sein:

Verfremdungen durch eingesetzte Blanks, Klammern und Ausschreiben von “@” als “at” bieten gegen hinreichend programmierte Spam-Bots keinerlei wirksamen Schutz ! Das Gleiche gilt für den Einsatz von ISO- oder UTF8-Zeichensatz-Nummern. Weiterführende CSS- und javascript-basierte Verfahren können mit mehr oder weniger geringem Aufwand unwirksam gemacht werden.

Mit dieser Meinung stehe ich keinesfalls alleine da. Siehe etwa den folgenden Link:
http://www.cedis.fu-berlin.de/cms/doc/faq/allgemein/email-adressen.html.
Doch es gibt noch mehr Gegenargumente.

Kritikpunkt 2 – Eventuelle Verletzung der Barrierefreiheit
Bzgl. des Einsatzes auf Impressum-Seiten vermute ich, dass der Verfremdung dort Grenzen gesetzt, wo sie sich ggf. negativ auf die Barrierefreiheit für Sehbehinderte auswirkt. Intuitiv würde ich zwar annehmen, dass moderne Screen-Reader UTF8-Zeichen-Nummern korrekt umsetzen, aber wer weiß …..

Ein Fragezeichen ist auch bei der Interpretation einer umgedrehten Zeichenreihenfolge zu setzen. Ich muss zu meiner Schande gestehen, dass ich schlicht nicht weiß, wie Screenreader für Blinde sich hier verhalten. Für Hinweise bin ich dankbar. Ein getesteter Befund macht mich aber schon mal sehr misstrauisch:

In einem rein textbasierten Browser wie Lynx wirkt die CSS-Anweisung zur Umkehrung der Textreihenfolge nicht:
<span style=”unicode-bidi:bidi-override; direction: rtl;”>CBA</span>
wird in Lynx nicht als “ABC” sondern als “CBA” dargestellt.

Das macht diese Methode meiner Meinung nach für den Einsatz auf Impressum-Seiten ungeeignet.

Ähnliches gilt für das Hinzufügen von angeblich “nicht sichtbaren Tags” auf der Basis der CSS-Anweisung “display:none;”. Der Inhalt dieser Tags taucht nämlich in rein textbasierten Browsern wie Lynx dennoch auf ! Damit verbietet sich bei Anwendung dieser Methode ein anderer Text innerhalb des Tags als ein schlichtes “Blank” (&nbsp;). Ein Blinder hätte ansonsten erhebliche Mühe, sich die E-Mail-Adresse zusammen zu reimen. Ein “Spamschutz” der Art “renate (dot) mustermann   [at] gmx (dot) de” ist dann aber kaum mehr wert als die Variante ganz ohne das “unsichtbare Tag”.

Grundsätzlich würde ich mal sagen:

Alles was in Lynx so dargestellt werden würde, dass es beim Leser zu Verwirrung führen könnte, ist beim Einsatz von Screenreadern für Sehbehinderte sicher als noch problematischer einzustufen. Unter diesem Gesichtspunkt sollten deshalb alle Verfremdungsmaßnahmen grundsätzlich mit einem textbasierten Browsern ausgetestet werden. Das dies natürlich vor allem für die Impressum-Seite gelten muss, versteht sich nach der bisherigen Lektüre von selbst.

Demnach fällt die Umkehrung der Schreibrichtung für Impressum-Seiten aus. Und die Methode mit der Ergänzung unsichtbarer Tags reduziert sich letztlich auf das Einfügen von “Blanks” auf eine komplexe Weise.

Kritikpunkt 3 – Umgehung CSS-basierter Maßnahmen durch Auswertung eines Textstroms aus einem HTML-Interpreter
Da wir gerade schon Lynx ansprachen: Spammer, die einen geringen Aufwand nicht scheuen, werden den HTML-Code evtl. gar nicht direkt auswerten, sondern zuvor durch einen HTML-Interpreter wie den Kern von Lynx schicken. Der interpretiert dann HTML, CSS, ggf. auch Javascript und setzt das Ergebnis schließlich in einen bereinigten ASCII/ANSI-Textstrom um, der wieder voll lesbar und maschinell auswertbar ist. Bei einer solchen Vorgehensweise, die auf bereits interpretiertem HTML-Code aufsetzt, versagen die diskutierten CSS-basierten Verfremdungen natürlich völlig. (Übrigens auch ein Teil an Javascript-Verfremdungen).

Kritikpunkt 4 – Die große Ungewißheit: Sind Verfremdungen der E-Mail-Adresse auf Impressum-Seiten überhaupt zulässig ?
Ich bin wirklich kein Jurist. Es erscheint mir aber plausibel, dass eine Verfremdung zumindest auf verständliche, nachvollziehbare und leicht korrigierbare Effekte begrenzt bleiben muss. Wenn ich die juristischen Texte zum Impressum richtig einschätze, so ist es wohl zumutbar, dass jemand die E-Mail-Adresse zur Kontaktaufnahme abtippt. Als Unbedarfter stellt man sich dann die Frage: Vielleicht ist es dann ja auch zumutbar, dass der Besucher der Impressumseite im Zuge des Abtippens kleine verständliche Korrekturen vornimmt, wie etwa das Entfernen von “Blanks” (“Leerzeichen”) und den Ersatz eines “at” durch ein “@”?

Allerdings sollte man dies dem User dann auf der Webseite wohl auch explizit mitteilen. Genau so verfahren heute viele Webseiten – als Beispiel sei etwa die Webseite eines Services der Sparkassen genannt:
http://www.siz-service.de/index.php?id=44 (Stand: 04.03.2013)

Man beachte im genannten Beispiel aber auch die Feinheiten: Der Verfremdungseffekt ist wirklich minimal ! Hier werden ausschließlich Blanks zur Abgrenzung des “@” benutzt. Der Benutzer wird zudem explizit auf die Verfremdung aufmerksam gemacht und es wird gesagt, was er tun muss, um eine funktionierende E-Mail-Adresse zu erhalten. Hier spürt man regelrecht das Unbehagen der Seitenersteller !

Der Leser sei deshalb gewarnt:

Ich habe zum diskutierten Thema viel gegoogelt. Man findet meiner Ansicht nach im Moment keine vertrauenswürdige Seite mit juristischer Kompetenz im Hintergrund, die explizit feststellen würde, dass eine Verfremdung nach dem oben angegebenen Muster auf einer Impressum-Seite zulässig sei ! Das halte ich für wirklich bemerkenswert !

Sieht man sich dann mal bei den Webseiten großer deutscher Unternehmen und/oder öffentlichen Verwaltungen um, so wird man feststellen, dass praktisch alle dieser Organisationen Verfremdungen auf der Impressum-Seite vermeiden! Dort findet man überall direkt kopierfähige E-Mail-Adressen in schönster Klartextform – ganz ohne zwischengeschobene Blanks und ohne ausgeschriebenes “at”. Anders ist dies dagegen bei mittelständischen Firmen, besonders bei den kleinen.

Nun kann der Leser spekulieren: Ist die Ursache die, dass große Unternehmen bessere Rechtsberater haben und sich nicht trauen, Verfremdungen der E-Mail-Adresse vorzunehmen? Oder gab schlicht das Vertrauen in die
sicher üppigen Anti-Spam-Maßnahmen dieser Groß-Unternehmen den Ausschlag, auf Verfremdungen zu verzichten?

Ich traue mich nicht, das zu beurteilen. Und so spreche ich deshalb explizit keine Empfehlung aus und rate jedem, sich rechtlich in puncto Verfremdung der E-Mail-Adresse auf der Impressum-Seite beraten zu lassen!

Verfremdungs- und Schutzmaßnahmen auf Basis von Javascript

Es gibt im Web eine ganze Reihe von Seiten, die Schutzmaßnahmen für E-Mail-Adressen auf der Basis von Javascript anbieten. Ich stehe dem skeptisch gegenüber. Ausschlaggebend sind 3 Punkte:

  • Javascriptcode kann am Browser eingesehen und verstanden werden. Dann brechen die Schutzmaßnahmen zusammen.
  • Javascript setzt im Browser einen aktivierten Javascript-Interpreter voraus. Das ist in manchen textbasierten Browsern von Haus aus nicht gegeben. Aber auch in vielen Firmen ist Javascript aus Sicherheitsgründen abgeschaltet.
  • Javascript ist auf älteren Mobil-Geräten nicht voll umfänglich verfügbar oder fehlerhaft implementiert.
  • Javascript ist nicht behindertenfreundlich und steht einer Barrierefreiheit in der Regel im Weg.

Aus diesen Gründen scheiden für mich auch Javascript-basierte Maßnahmen für Impressum-Seiten aus. Hier erscheint mir die Möglichkeit, mit dem TMG in Konflikt zu geraten,doch relativ groß zu sein.

Fazit: Was bleibt von den beschrieben Maßnahmen eigentlich übrig?

Aufwandsorientierung
Nach den von mir dargestellten Argumenten ist die Luft für sinnvolle, sicher zulässige und zugleich wirksame Schutzmaßnahmen ziemlich dünn. Grundsätzlich bin ich aber der Meinung, dass man auch kleine Hürden nicht verschmähen soll. Und da orientiere ich mich dann schlicht am zu betreibenden Aufwand. Für gewöhnliche Webseiten einer Web-Präsenz kann man vor allem an einfache Verfremdungsmaßnahmen denken. UTF8-Einsatz schadet nicht, der Einsatz von unsichtbaren Zusatztags mit ” ” als Inhalt wohl auch nicht. Das Einfügen von Blanks und Klammern finde ich auch für Laien erkenn- und nachvollziehbar.

Auf einer Impressumseite ist die rechtliche Lage dabei für mich nicht wirklich abschätzbar. Ob man hier geringfügige Verfremdungen, die auch Sehbehinderte auf ihren Geräten erkennen und auflösen können, vornehmen will, muss jeder also selber entscheiden. Wenn man es denn tatsächlich tun will, sind explizite Hinweise an die Besucher der Seite sicher angebracht und hilfreich.

Einsatz spezifischer und leicht austauschbarer Mailadressen
Unabhängig von Schutzmaßnahmen: Ich denke, bei Webseiten ist der Einsatz spezifischer und vor allem leicht ersetzbarer Email-Adressen und zugehöriger Mailboxen sinnvoll. Die Vorteile sind:

  • Man erkennt sehr einfach, dass der Kontakt über die Webseiten-Info hergestellt wurde.
  • Man kann die Mails leicht in bestimmte Bearbeitungs-, Filter- und Empfangskanäle oder Mailboxen lenken.
  • Man kann die Adresse schnell austauschen, wenn die Spamflut trotz aller Filter überhand nimmt.

Kontaktformulare auf Nicht-Impressumseiten nur dann, wenn andere Gründe als die Spamabwehr dafür sprechen
Auf Nicht-Impressumseiten sind Kontakt-Formulare eventuell eine sinnvolle Lösung. Aber ich sehe hier viel eher fachliche Gründe als den Grund der Spamabwehr. Die Daten der Kunden kann man in eine Datenbank überführen, man kann sie in Form von Mails aufbereiten und viele andere schöne Dinge machen. Wie oben bereits festgestellt: Die Spam- und XSS-Abwehr bei Web-Formularen ist dagegen kompliziert und technisch anspruchsvoll. Das fängt bei ganz trivialen Fragen an: Soll man
z.B. Quittungsmails an den Nutzer des Formulars verschicken? Und wenn ja mit welcher eigenen Adresse? Ggf. schickt man dadurch ja einem Spammer eine schöne Antwort und bestätigt, dass er durchgekommen ist. Und die zu berücksichtigenden Themen hören bei der Auswahl guter PRNG-Verfahren als Grundlage der Captcha-Generierung keineswegs auf.

Spam-Filter als primäre Maßnahme
Bzgl. noch komplexerer Abwehr-Maßnahmen finde ich, dass man sich den Aufwand einfach sparen und lieber in eine gute Spamlösung investieren sollte. Wegen der Vorgaben des Gesetzgebers für die Impressum-Seiten wird man ein gewisses Spam-Aufkommen wohl nie los werden. Also muss man filtern. Bei uns hat sich eine Kombination aus Spamfiltern

  • beim Internet- oder Web-Provider,
  • auf unserem eigenen Mail-Server (spamassassin),
  • auf einigen Mail-Clients

bewährt. Einzige Nachteile: Spamassassin muss immer mal wieder ein Ham/Spam-Training durchlaufen. Und man muss regelmäßig einen Blick auch in die Spam-Verzeichnisse für den Fall werfen, dass doch mal eine Mail falsch einsortiert wurde.

Also: Es bleibt nur, viel Spaß beim Filtern der Spams zu wünschen, die wegen der verpflichtenden E-Mail-Adress-Angabe auf der Impressum-Seite sicherlich früher oder später eintrudeln werden.

Links

http://www.online-werberecht.de/impressumspflicht.html
http://www.linksandlaw.info/Impressumspflicht-45-kontaktformular.html
http://linksandlaw.info/Impressumspflicht-Notwendige-Angaben.html
http://www.impressum-recht.de/abmahnung-bei-verstoss-gegen-impressum-pflicht.html
http://irights.info/schutz-der-eigenen-webseite-vor-abmahnungen/7047
http://www.jurawelt.com/aufsaetze/8588

http://www.datenschutzbeauftragter-info.de/impressum-spam-schutz-grafik-e-mail/
http://www.shopbetreiber-blog.de/2011/02/24/abmahnung-impressum-grafik/
http://rechtsanwalt-schwenke.de/abmahnung-wegen-impressums-als-bilddatei/
http://www.shopbetreiber-blog.de/2008/05/15/lg-essen-kontaktformular-statt-e-mail-adresse-im-impressum-unzureichend/
http://www.ferner-alsdorf.de/2010/09/olg-naumburg-email-adresse-muss-leserlich-in-das-impressum/

http://www.impressum-generator.de/tag/internetportal/
http://www.leipzig.ihk.de/inhalt/geschaeftsfeld/Recht-Fair-Play/Wettbewerbsrecht/Angabe-der-E-Mail-Adresse-im-Impressum-ist-ausreichend.aspx/
http://www.it-recht-kanzlei.de/5/Viertes_Thema_Rechtsprechungsuebersicht_2008-2010/impressum.html