Implizite Informationen

Der eine oder andere weiß, dass ich an meinem iMac noch eine zweite Tastatur angeschlossen habe. Diese ist vielleicht nicht so gut, um Passwörter einzugeben, hilft aber beim Lernen von Blindschreiben.

Bisher vertrugen sich beide Tastaturen gut. Seit zwei Tagen muckt Das Keyboard aber herum: Apfel-Q funktioniert nicht bei allen Anwendungen und auf einmal sind die Tasten "<" und "^" vertauscht. Ich könnte mich daran gewöhnen, aber nur um den Preis eines Broken Window. Also besser ändern. Dabei meinte ich, mit dem Umstieg von Windows auf OSX solche Flausen hinter mir gelassen zu haben.

Eigentlich sollte das Einstellen ganz einfach sein: Systemeinstellungen >> Tastatur >> Tastaturtyp ändern ... Eigentlich. Tatsächlich war vom Button zum Ändern des Tastaturtyps keine Spur. Ganz wie beim vormals großen Bruder aus Redmond.

Tief in den Eingeweiden von OSX findet sich dann doch noch ein Lösungsweg: als Administrator die Datei /Library/Preferences/com.apple.keyboardtype.plist löschen (Ängstliche benennen diese Datei nur um) und das System neu starten. Nach dem Reboot wird versucht, Das Keyboard mit Hilfe eines "Assistenten" zu identifizieren. Funktioniert. Der Button erscheint auch wieder in den Systemeinstellungen. So etwas kenne ich doch auch von diesem anderen Betriebssystem. Na ja, es funktioniert und mit Linux wird in einigen Jahren sowieso alles besser.

Es gibt vier Probleme, wenn man einen Mailserver selbst betreiben möchte:

• der Server sollte dauernd erreichbar sein, damit er Mails auch entgegen nehmen kann,
• der Server sollte abgesichert sein und offensichtliche Spam-Mail erst gar nicht annehmen,
• andere Mailserver sollten dem Server "vertrauen", damit sie dessen Mails entgegen nehmen,
• der Server sollte regelmäßig über ein Backup gesichert werden, damit (wichtige) Mails nicht verloren gehen.

Der letzte Punkt ist einfacher zu realisieren, denn dies sollte sowieso für jeden Computer gemacht werden. Wer seine Daten nicht sichert, darf sich hinterher nicht beschweren. Ich empfehle, die eigenen Daten ohne viel Schnickschnack zu sichern. Aber das ist eine andere Geschichte.

Die ersten drei Punkte sind dagegen viel schwerer zu realisieren. Einen Server dauerhaft im Netz zu betreiben, gut und permanent zu administrieren, Sicherheitspatches einzuspielen, sich über die neuesten Tricks der Spammer auf dem Laufenden zu halten und dafür zu sorgen, dass der eigene Server eben nicht auf eine Blacklist kommt, das ist eine Aufgabe für fähige Administratoren. Ganz zu schweigen, dass man sich tiefergehend mit MTAs, MDAs, MUAs und ggf. MRAs auseinander setzen muss. Tiefergehend. Für mein Wochenendprojekt ist das definitiv zu viel.

Viel einfacher ist der in einem c't-Artikel besprochene Weg: mein Mailhoster kümmert sich um die ersten drei Punkte. Das macht er nämlich richtig gut. Alles, was ich noch tun muss ist:

• einen Mailaccount beim Mailhoster einrichten,
• die Mails regelmäßig abholen und auf den eigenen Server schieben (dafür ist der MRA notwendig, bei mir ist es getmail),
• einen lokalen MDA betreiben (ist bei mir procmail),
• für den Zugriff meines Mailprogrammes einen IMAP einrichten (bei mir: dovecot),
• dafür sorgen, dass der MTA (bei mir postfix) die Mails nicht direkt versendet, sondern den MTA des Mailhosters als Relais verwendet.

Das alles klingt schwieriger als es ist. Außerdem hat ein Wochenende zwei Tage und zwei Nächte ;-). Im Ernst, je nach verwendetem Betriebssystem (Windows bitte eher nicht) und / oder Distribution und / oder Hersteller des Serverleins gibt es schöne Anleitungen im Netz. Einfach mit der Suchmaschine der Wahl danach googeln.

Bei mir war die Sache mit dem MRA (getmail) etwas einfacher, da ich getmail schon für den Backup meines Kontos bei Google Mail verwendet habe. Das dort beschriebene entsprechend anpassen.

Das Einrichten von MDA (procmail) und IMAP (dovecot) war recht einfach, viel zu schrauben ist dort nicht. Trickreicher war höchstens, den MTA (postfix) zu überreden, die Mails nicht selbst auszuliefern, sondern den Mailhoster als Relais zu verwenden. (Nebenbei: bei meinen persönlichen Tests kamen alle Mails auch ohne Relaisfunktion an, bis auf die an meine Arbeit. Your mileage may vary.)

Den Aufruf von getmail steuere ich übrigens per cron. Zu meiner eigenen Entschleunigung fragt getmail nicht alle paar Minuten meinen Mailhoster auf neue Mails ab, sondern viel seltener. Aktuell experimentiere ich mit Zeitabständen von 2-3 Stunden. Sprich, ich kann soviel meinen lokalen IMAP-Server neue Mails prüfen lassen, die kommen eh erst alle 2-3 Stunden an. Wenn ich mich an die Zeitabstände gewöhnt habe (ja, dass muss ich), dann werde ich die Zeitabstände wochentags noch weiter verzögern: nur noch um 13 Uhr und um 17 Uhr. Wenn ich einmal eine Mail schneller benötige (z.B. zur Registrierung), kann ich den Abruf manuell starten oder den Webmail-Client meines Mailhosters nutzen.

Mit diesem Aufbau kann ich meine Mails im lokalen Netz sehr komfortabel abrufen. Für den mobilen Zugang muss ich meinen Router an zwei kleinen Stellen öffnen (IMAPS und SMTPS), mein Serverlein über einen DDNS-Dienst einen DNS-Namen geben (habe ich aus anderen Gründen sowieso) und einige Zertifikate für SSL erzeugen (habe ich auch schon).

Fertig.

Jetzt kann ich meine Mails auch mobil abrufen. Bisher nutzte ich auf meinem Händie zwei Mailprogramme: eines für die Arbeit und für Google Mail das von Google. Nun brauche ich nur noch eines. Sehr bequem.

Mein Konto bei Google Mail hat eine Weiterleitung auf meinen Mailhoster, seit Jahren nutze ich den Weiterleitungsdienst der ACM. Diesem muss ich meine neue Mailadresse mitteilen. So kommen alle Mails weiter an. Wer so etwas nicht hat, sollte nun allen die neue Mailadresse mitteilen.

Der Backup funktioniert?

Jetzt ist das erste Wochenende auch schon herum. Wer den Tatort verpasst hat, kann sich bei Twitter für das montägliche Teeküchengespräch beim Kaffeekochen noch schnell präparieren.

Beim nächsten Mal geht es um einen Ersatz für Google Reader.

Update 20.02.2012: die Gewöhnung an die Zeitabstände ging schneller als gedacht. Ab nun also nur noch wirklich um 13 Uhr und um 17 Uhr.

Als ich im letzten Blogeintrag darüber schrieb, wie man ein Backup für Google Mail anlegen kann, blieb bei mir tief im Inneren das Gefühl: da stimmt etwas nicht.

Google Mail ist ein sehr bequemer Dienst. Die Web-Oberfläche ist zwar nur einigermaßen komfortabel, aber ich habe mich mit einer Reihe von Labels und Filter dort gut eingerichtet. Spam ist kein großes Problem, dem Filter sei Dank. Für den mobilen Zugriff gibt es eine halbwegs vernünftige App. Zur Not ginge auch die Mobilansicht. Also was solls?

Ja, damals wollte ich weg von Google und habe es nicht geschafft. Den Anfang sollte Google Reader machen, aber nach einiger Zeit bin ich dann doch wieder zurück gekommen. Zu fehlerbehaftet war die Software (damals: Gregarius). Das lag sicher auch daran, dass ich nur über einen, hmm, eingeschränkten Webspace verfügte. Vom mobilen Zugang möchte ich gar nicht sprechen.

Heute ist vieles anders. Über meinen Hoster kann ich mich selbst nach knapp einem Jahr nun gar nicht beschweren. So gut wie alles ist dort möglich. Aber viel wichtiger: seit über 2 Jahren schnurrt ein kleines, linux-basiertes Serverlein unter meinem Schreibtisch. Dort hoste ich Daten, die besser auf meinen Systemen bleiben sollen (Klausuren, ...). Denn für jeden Rechner gilt: you must trust the admin. Nicht, dass ich Uberspace nicht über den Weg traue. Aber selbst unter Freunden gibt es Dinge, von denen der andere nichts wissen muss. Seit einem halben Jahr traue ich mich mein Serverlein nicht nur intern zu betreiben.

Irgendwann im letzten Jahr fing ich an, über meine eigenen Daten wieder nachzudenken. Mail, RSS-Feeds, Kalender, Kontaktdaten liegen teilweise in der Cloud. (BTW, immer wenn ich "Cloud" höre, fehlt mir das Objekt des Satzes). So 100%ig bin ich auch mit den ganzen sozialen Netzen nicht zufrieden. Weil es Twacbak gibt, nutze ich Twitter. Geplusst wird kaum und wenn, dann nur an bestimmte Kreise. Und Facebook? Da ist wohl wenig zu sagen. Wer sich dort austoben will, soll es tun. Oder ist noch nicht 18.

Den letzten Anschub gaben ein c't-Artikel und der Blogpost Why do self-respecting hackers use Gmail & Co?. Natürlich hätte ich einfach nur meine Mail bei Uberspace hosten lassen können. Aber zum einen lerne ich gerne dazu. In diesem Fall, wie man einen Mailserver aufsetzt und betreibt. Und zum anderen möchte ich meine Daten bei mir haben. Auf nicht von mir kontrollierten Systemen können gerne ggf. Kopien liegen. Aber meine Mail soll aufs Serverlein.

Womit ich die Titelzeile auflösen kann: Yoyod bedeutet "You Own Your Own Data". Das ist mein Motto für dieses Jahr. Ich weiß, damit bin ich spät dran. Aber besser als nie.

Nach dem Abschied von Google Mail steht der von Google Reader an. Passt sowieso zur Änderung der "Datenschutzerklärung" bei Google.

Als Ende Februar 2011 bei ca. 150.000 Nutzern von Google Mail die dort gespeicherten E-Mails gelöscht wurden, dachte ich erst einmal "Puh, zum Glück bin ich nicht betroffen". Aber will ich das weiter hoffen? In den ersten Tagen danach war das Web voll von klugen Ratschlägen, wie man ein Backup anlegen kann. Alle diese Methoden haben einen Nachteil: sie sind für Mausschubser graphische Oberflächen optimiert und müssen manuell gestartet werden.

Nichts für mich. Ich brauche einen Mechanismus, der im Hintergrund alles für mich automatisch erledigt. Idealerweise sogar auf meinem kleinen Serverlein. So werden E-Mails auch gesichert, wenn mein Hauptrechner ausgeschaltet ist.

Es gibt einige Anleitungen, wie man mittels Fetchmail an die E-Mails bei Google herankommt. Auf Grund einiger Inkompabilitäten funktioniert das Ganze wohl auch, aber das Problem ist ein anderes: was mache ich mit den frisch gelesenen E-Mails? Fetchmail ist darauf hin optimiert, die E-Mails an einen lokalen Mail-Server weiter zu leiten. Den wollte ich nicht auch noch aufsetzen.

Gestolpert bin ich dann über einen etwas älteren Blogeintrag How to back up your Gmail on Linux in four easy steps. Die dort angesprochene Software getmail realisiert genau das, was ich brauche: die frisch gelesenen E-Mails werden als normale Textdatei(en) gespeichert und können zur Not von üblichen Mail-Programmen eingelesen werden.

Das Problem mit dem Blogeintrag: er nutzt ein Übertragungsprotokoll, dass einige Beschränkungen aufweist: POP3. Zum einen beschränkt Google die Menge an übertragenen E-Mails, nach ca. 320 E-Mails ist Schluss. Zum anderen werden damit nur die empfangenen E-Mails abgeholt, nicht die E-Mails, die ich selbst geschrieben und gesendet habe.

Google Mail erlaubt zum Glück den Zugriff via IMAP. Wie auch POP3 muss IMAP innerhalb von Google Mail aktiviert werden. Bei den Einstellungen innerhalb von Google Mail auf den Punkt "Weiterleitung und POP/IMAP" klicken und dort "IMAP aktivieren". Alles andere in der Standardeinstellung belassen.

Der geneigte Nutzer von Google Mail weiß, dass unter dem Label "Alle Nachrichten" wirklich alle E-Mails zugreifbar sind, bis auf die im Spam-Ordner. Aber wer will die schon sichern? Bei einem Zugriff via IMAP werden die Label von Google Mail zu sogenannten Ordnern. Der Posteingang heißt unter IMAP "INBOX". Den IMAP-Namen für "Alle Nachrichten" konnte ich mittels Thunderbird als "[Gmail]/Alle Nachrichten" ermitteln. Bei einer anderen als der deutschen Spracheinstellung muss der Name entsprechend angepasst werden. Erinnert mich an das frühe VBA, als selbst die Befehle eingedeutscht waren. Schrecklich. Aber nicht zu ändern.

Mit diesen Daten ist alles zum Konfigurieren von getmail beisammen. Wie Sie getmail installieren müssen, werde ich nicht erklären. Das ist zu systemspezifisch. Auf meinem Serverlein reichte ein einfacher Aufruf des Paketmanagers.

Legen Sie als erstes in Ihrem Benutzerverzeichnis "~" das Verzeichnis .getmail so an, dass nur Sie darauf zugreifen können:

mkdir -m 0700 ~/.getmail

Dann legen Sie die Konfigurationdatei an. USER ist Ihr Benutzername bei Google Mail, PASSWORD Ihr Kennwort.

cat <<EOF > ~/.getmail/getmailrc
[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = USER@gmail.com
password = PASSWORD
mailboxes = ("[Gmail]/Alle Nachrichten", )

[destination]
type = Maildir
path = ~/.getmail/gmail-backup/

[options]
verbose = 0
delivered_to = false
received = false
read_all = false
message_log = ~/.getmail/gmail.log
EOF

Jetzt müssen Sie nur noch das Verzeichnis gmail-backup anlegen. Dies erledigt getmail leider nicht automatisch.

mkdir -m 0700 -p ~/.getmail/gmail-backup/{cur,new,tmp}

Jetzt kommt der große Moment:

getmail -g ~/.getmail -v -v -v

Mit diesem Aufruf starten Sie getmail (der konkrete Befehl kann, je nach Installation, ein wenig variieren). Die drei Optionen -v bewirken, dass Sie die Zugriffe auf Google Mail gut nachvollziehen können. Die ganz Harten unter uns können auch --trace verwenden. Nun wird der gesamte Inhalt Ihres Google Mail Kontos heruntergeladen und im Verzeichnis ~/.getmail/gmail-backup/new in einer Datei pro E-Mail gespeichert. Das kann dauern.

Inzwischen erkläre ich den Inhalt von getmailrc. Der Abschnitt [retriever] dürfte soweit klar sein. Hier geben Sie alle Informationen, um auf Ihr Google Mail Konto zugreifen zu können. Unter mailboxes geben Sie eine Liste der zu sichernden Labels an. Im Abschnitt [destination] wird definiert, wo und in welchen Format die E-Mails abgelegt werden. Ich habe mich für das Maildir-Format entschieden, da es gegenüber dem konkurrierenden mbox-Format wesentlich robuster ist. Und darauf kommt es mir bei einem Backup an. Wer möchte, kann die E-Mails in beiden Formaten speichern. getmail kennt dazu das Konzept MultiDestination.

Einige Einträge im Abschnitt [options] sind wichtig. read_all muss auf den Wert false gesetzt werden. Sonst liest getmail bei einem zweiten Aufruf alle E-Mails erneut ein und speichert diese mehrfach. delivered_to und received besitzen ebenfalls den Wert false, damit getmail die sog. Headerinformationen nicht ergänzt / ändert. Alle Vorgänge können in der unter message_log benannten Datei nachvollzogen werden.

Sind alle E-Mails inzwischen heruntergeladen worden? Nein? Dann ist ja noch etwas Zeit einen cron-Job einzurichten. Wieder ist dies von der jeweiligen Installation abhängig. Wichtig ist aber, beim Aufruf von getmail die Option -q anzugeben. Dann teilt getmail nur im Fehlerfalle etwas mit. Ich habe mir eine Datei angelegt, die ich dann im cron-Job verwende:

cat <<EOF > ~/bin/backup-gmail.sh
#!/bin/sh
/usr/bin/getmail -q -g /home/dkr/.getmail
EOF
chmod 700 ~/bin/backup-gmail.sh

Die Datei backup-gmail.sh lasse ich periodisch einmal am Tag aufrufen:

crontab -u dkr -l
50  23  *   *   *   /home/dkr/bin/backup-gmail.sh

Pünktlich um 23:50 Uhr läuft dann auf meinem Server die (inkrementelle) Datensicherung an. Bis jetzt ohne Probleme. Wer möchte, kann die nun lokal vorhandenen E-Mails auch noch woanders hin sichern. Sicher ist sicher.

Das Backup muss nicht per cron gestartet werden. Wenn Sie kein Serverlein besitzen, kann backup-gmail.sh auch ganz normal beim Anmelden gestartet werden. Nach dem ersten Backup, der naturgemäß länger dauert, braucht getmail auf meinem System ca. 3 Minuten für das Sichern der neu hinzugekommenen E-Mails. Davon wird die meiste Zeit mit dem Erkennen der neuen E-Mails verbracht. Bei mir sind es aktuell ca. 10.000 E-Mails, deren Header-Informationen gelesen werden müssen. Verschmerzbar.

Auf einen Nachteil möchte ich hinweisen: ungelesene E-Mails werden nach einem Backup als gelesen markiert. Dies ist vom Autor von getmail so gewollt, aber auch nicht wirklich schlimm. Der Backup kann nach dem Lesen der E-Mails gestartet werden. Oder ich schaue mir die E-Mails in der Reihenfolge ihres Eingangs unter "Alle Nachrichten" an. Fertig.

Wieder einmal regen sich einige Leute auf. Dropbox soll die Benutzer "belogen" haben, was die Sicherheit ihrer Daten betrifft.

Unabhängig von möglichen Versprechungen auf der Website von Dropbox, wundert mich, dass jemand mit etwas technischem Verstand diese wirklich ernst genommen hat. Wenn Klartextdaten von einer Website herunter geladen werden können, dann muss der Betreiber auf diese Daten im Klartext Zugriff haben. Es sei denn, der Benutzer hat auf seinem Rechner zum Download eine spezielle Software installiert (direkt oder durch den Beteiber). Das ist aber bei Dropbox nicht der Fall.

Der Konkurrent Wuala verschlüsselt tatsächlich nur beim Benutzer, ein Webzugriff erfolgt über ein Java-Applet. Ist das sicherer? Vielleicht. Denn ich muss Wuala vertrauen, dass sie in den Verschlüsselungmethoden keine Hintertür eingebaut haben.

Bei allen Diensten, die ich nutze gilt: ich muss dem Administrator / Diensterbringer vertrauen. Alles andere funktioniert nicht. Oder ich betreibe alle Dienste selbst. Wenn ich meine Daten "sicher" haben möchte, dann packe ich einen TrueCrypt-Container in meine Dropbox. Oder in meinen Wuala-Space.

Mich wundert, weshalb Wired und Netzpolitik jetzt diese Kuh durch das digitale Dorf treiben. Haben wir schon das Sommerloch? Oder fehlt beiden das grobe technische Verständnis? Ich weiß nicht, was mich mehr beunruhigen sollte. Die "Lüge" von Dropbox oder der technische Mangel von technologie-orientierten Webseiten.