// Google Threatens To Kill Users


© by comedy.com

“We are f****** Google. If we tell you to buzz, you will buzz”. LOL

// Global DNS problems regarding the .de Top Level Domain [Update2]

Half of the Internet seems to be down today. Most sites I wanted to visit where not accessible because of a timeout.1)

First I thought the DNS server of my provider is down, this would not be the first time. But the problem still exists after switching to another, non-provider DNS server. Doing some research, it comes to light that there seems to be a serious problem regarding the whole .de-TLD caused by the DENIC root nameservers. Seriously – WTF?! 8-O 8-O

If this is true, it will be a really big problem. Should DENIC not fix it within the next hours, most .de based sites will not be reachable (at least if the provider DNS-caches are empty, common DNS A-RRs configurations got a TTL of 86400sec/1day).

Update: Yes, it is really a DENIC fail. So don't blame your provider and/or admin if your .de website is not reachable within the next hours.

Update2: DENIC released a public statement about the issue.

1)
e.g. ping andreas-haerter.de results in ping: “unknown host andreas-haerter.de”

// Heutzutage mahnt man sogar seine Händler ab... [Update]

Jedenfalls scheint ein bekannter Hersteller von Fahrradzubehör und -reifen so vorzugehen, eine solche Story geistert gerade durch das Web. Dabei geht es um den Sachverhalt, dass Händler (mit Produkten der Firma im Sortiment) originale Produktfotos des Herstellers für die eigenen Shops verwendet haben sollen, ohne eine Lizenz zu besitzen.

Wenn ich selber Fotos mache und ein direkter Konkurrent verwendet diese, um aus meiner Arbeit Kapital zu schlagen, könnte ich das gerade noch nachvollziehen.2) Aber seit wann mahnt man seine eigenen Händler ab? Juristisch ist das IMHO rechtens, aber moralisch fragwürdig.
Auch aus unternehmerischer Sicht ist das Vorgehen dämlich. Normalerweise ist jeder Hersteller darum bemüht, dass man nicht selbst Fotos macht, da diese meist unprofessionell sind. Bei Konsumgütern sind sogar Werbekostenzuschüsse üblich, damit in jedem Fall die hochqualitativen Produktfotos des Herstellers genutzt werden… Außerdem macht man Händlern so auch weniger Arbeit und senkt damit die Schwelle, Produkte in das Sortiment aufzunehmen. Was denkt man sich bloß in Reichshof?

Update: Es wird zurückgerudert...

2)
wobei es auch dann einfach mal ein Anruf/eine E-Mail anstatt immer gleich eine kostenpflichtige Abmahnung sein könnte – reden löst die meisten Probleme

// Adblock Plus-Filterregel für Fefes Blog

Damit auch dem technisch unversierten User geholfen ist: LOL

blog.fefe.de##DIV

Via Jürgen.

// HTTP digest authentication with PHP (safe mode enabled)

Doing HTTP digest authentication with PHP is an easy task. The manual entry is providing all needed information as long as you do not skip the last note on the page:

Note: If safe mode is enabled, the uid of the script is added to the realm part of the WWW-Authenticate header.

I just talked to one of my friends who did not notice the safe mode behavior, he had problems because HTTP digest authentication simply did not work on his server where safe mode is active. Unfortunately, the manual is not providing an example working with both active and inactive safe mode, therefore I am releasing one here. You may use the function directly… or better build a nice auth-class for doing the job. However, I think the example should help in both cases providing all needed information for creating your own HTTP digest authentication. Have fun. :-)

http-auth.php
<?php
/**
 * HTTP digest authentication
 *
 * @return true TRUE if everything worked/auth was successful.
 *         In case of errors and/or wrong credentials, the script will be killed
 *         (providing a message to the current client).
 * @author Andreas Haerter
 * @link http://en.wikipedia.org/wiki/Digest_access_authentication
 * @link http://de.wikipedia.org/wiki/HTTP-Authentifizierung
 * @link http://www.php.net/manual/features.http-auth.php
 * @link http://blog.andreas-haerter.com/2010/04/19/http-digest-authentication-with-php-safe-mode-enabled
 * @link http://www.php.net/manual/features.http-auth.php#93427
 */
function http_digest_authentication()
{
	//existing users/credentials
	$users = array("username1" => "password1",
	               "username2" => "password2");
 
	//message to show
	$realm = "Please enter your credentials";
 
	//send needed digest auth headers
	if (empty($_SERVER["PHP_AUTH_DIGEST"])) {
		header("HTTP/1.1 401 Unauthorized");
		header("WWW-Authenticate: Digest realm=\"".$realm."\",qop=\"auth\",nonce=\"".uniqid(mt_rand(), true)."\",opaque=\"".md5($realm."salt-for-opaque")."\"");
		die("unauthorized access");
	}
 
	//parse http digest (inspired through http://www.php.net/manual/features.http-auth.php#93427)
	$mandatory = array("nonce"    => true,
	                   "nc"       => true,
	                   "cnonce"   => true,
	                   "qop"      => true,
	                   "username" => true,
	                   "uri"      => true,
	                   "response" => true);
	$data = array();
	preg_match_all('@(\w+)=(?:(?:\'([^\']+)\'|"([^"]+)")|([^\s,]+))@', $_SERVER["PHP_AUTH_DIGEST"], $matches, PREG_SET_ORDER);
	foreach ($matches as $m) {
		$data[$m[1]] = $m[2] ? $m[2] : ($m[3] ? $m[3] : $m[4]);
		unset($mandatory[$m[1]]); //mandatory part was found, kick it out of the "to do" list (=$mandatory array)
	}
 
	//create valid digest to validate the credentials
	$digest = "";
	if (isset($users[$data["username"]])) {
		$realm_digest = $realm;
		//As mentioned at <http://www.php.net/manual/en/features.http-auth.php>:
		//If safe mode is enabled, the uid of the script is added to the realm part of
		//the WWW-Authenticate header (you cannot supress this!). Therefore we have to
		//do this here, too.
		if (6 > (int)PHP_VERSION //safe_mode will be removed in PHP 6.0
		    && (int)ini_get("safe_mode") !== 0) {
			$realm_digest .= "-".getmyuid();
		}
		$digest = md5(md5($data["username"].":".$realm_digest.":".$users[$data["username"]]) //A1
		              .":".$data["nonce"].":".$data["nc"].":".$data["cnonce"].":".$data["qop"].":"
		              .md5($_SERVER["REQUEST_METHOD"].":".$data["uri"]));                    //A2
	}
	if (empty($digest)
	    || $data["response"] !== $digest) {
		header("HTTP/1.1 401 Unauthorized");
		header("WWW-Authenticate: Digest realm=\"".$realm."\",qop=\"auth\",nonce=\"".uniqid(mt_rand(), true)."\",opaque=\"".md5($realm."salt-for-opaque")."\"");
		die("wrong credentials");
	}
	//if we are here, auth was successful
	return true;
}
?>

// Spring

// Alles neu

I just redesigned my blog and came to the decision to write my coming postings in English.3) Reasons are various, mostly I want to improve my English skills. Additionally, my blog will get a strong focus on the internet and its technical background. I simply reach more persons with English because even most non-native speakers working as web developers should understand English good enough to get the information they might want. ;-)

In this spirit: Alles neu4)

3)
The exception proves the rule – some stuff may have a focus on Germany, and these posting will be written in German. Stuff close to my heart may be released in both languages.
4)
German for “everything new”

// GnuPG-Schlüsselhierarchie: passender Algorithmus für jede Aufgabe, Schlüsselaustausch ohne Verlust des Web of Trust

Vor ein paar Wochen habe ich mir einen neuen Key für GnuPG/PGP (im Folgenden einfach “GPG” genannt) zugelegt, weil mein bisheriger abgelaufen ist. Das habe ich zum Anlass genommen meine Vorgehensweise beim Erstellen eines GPG-Schlüssels zu überarbeiten. Die Erkenntnisse will ich hier festhalten, vielleicht bringt es ja jemandem etwas ;-). Ziel war:

  • Fein granulare Schlüsselhierarchie: Eine GPG-Aufgabe → Ein Schlüssel.
  • Die verschiedenen Schlüssel sollen den jeweils passendsten Algorithmus für die Aufgabe verwenden und bei Bedarf nach relativ kurzer Zeitspanne verfallen dürfen.
  • :!: Der Austausch eines Schlüssels soll NICHT zur Folge haben, dass das eigene Web-of-Trust verloren geht.

Dabei ist der letzte Punkt IMHO der Wichtigste. Er erspart einem, dass man wieder mühsam Signaturen für die neue Schlüssel einsammeln muss (den neuen Key vor Ablauf des alten Key mit selbigen zu signieren ist IMHO nur eine Notlösung, aber besser als nichts). Die Vorteile liegen auf der Hand:

  • Geeignetere Algorithmen und Schlüsselstärken für die jeweilige Aufgabe
    Beispiel: RSA erzeugt irrsinnig lange Signaturen, ist aber gut für Verschlüsselung geeignet. Wenn man dennoch zur Verschlüsselung auf RSA setzen will, kann man seinen Signierschlüssel über DSA realisieren. Zudem kann man die nötige Schlüssellänge (Bit) besser zwischen Aufgabe und Performance abwägen.
  • Mehr Sicherheit
    Selbst wenn mal ein Schlüssel mit brachialer Großrechnerpower über Jahre geknackt werden könnte, so hat der Angreifer bei regelmäßig wechselnden Schlüsseln dann immer nur einen Teil der Daten und muss für weiteren Zugang zu älteren/neueren Daten erneut genausoviel Aufwand in Kauf nehmen. Dies gilt natürlich auch, wenn ein Schlüssel anderweitig kompromittiert wird (was wahrscheinlicher ist als Brute-Force). Es ist ein deutlicher Unterschied, ob jemand ein einziges Jahr oder z.B. fünfzehn Jahre Kommunikation nachvollziehen kann ;-). Oder ob nur ein Webserver-Login ermöglicht wird oder gleich alle jemals verschickten Daten entschlüsselt werden können.

Grundlage

Damit man mit häufiger wechselnden Schlüsseln nicht andauernd sein Web-of-Trust ruiniert, fußt dass im Folgenden beschriebenen Szenario auf einem Hautpsignierschlüssel, welcher ausschließlich dazu verwendet wird, die eigenen und fremden Schlüssel zu zertifizieren (Certify), und nicht5) abläuft. D.h. dieser Schlüssel hat nur den Zweck, Dritten bei Verwendung der nach kürzerer Zeit6) wechselnden Unterschlüssel zu beweisen, dass der neue Schlüssel wirklich unter meiner Kontrolle steht und die damit verschlüsselten Inhalte auch nur mir zugänglich sein werden. Das muss man aber nicht extra “aufdröseln” oder “zusammenfrickeln”, da alle Identitäten immer am Hauptschlüssel hängen.

Die lange Laufzeit dieses Hautpsignierschlüssels ist dabei wenig sicherheitskritisch, da ein Angreifer damit “nur” die Identität fälschen könnte und so Kommunikationspartner ggf. weismachen, er sei ich. Er kommt aber nicht an bereits verschlüsselte Inhalte. Dies steht in keinem Verhältnis einen Großrechner Jahrzehnte zu beschäftigen, um den Hautpsignierschlüssel zu knacken. Man wird die Rechenzeit lieber in das “knacken” der Inhalte investieren als “lediglich” in das fälschen der Identität - es gibt zum Einen sicher billigere Wege, einem Dritten vorzugaukeln, man sei ich und zum Anderen könnte ich sofort einen neuen Key erstellen, nutzen und verbreiten (und damit all die Arbeit des Angreifers zu Nichte machen), sobald mir klar wird, dass jemand Drittes meine Identität zu fälschen versucht.

Nötiges GPG-Wissen

Dieser Text ist kein Anfänger-Tutorial, sondern ein Anwendungsbeispiel für fortgeschrittene GPG-Nutzer: Wer komplett neu ist, sollte sich zunächst 3-4 Tage Zeit nehmen und GPG kennen lernen7). Anschließend sollte die hier beschriebene Hierarchie aber gut umsetzbar sein, denn die Systematik dürfte auch für “neue” GPG-Nutzer Sinn ergeben.

Auch wenn man sich schon ein wenig mit GPG beschäftigt hat, ist es für den folgenden Text unabdingbar, zu 100% zu verstehen, was der Unterschied zwischen den verschiedenen Schlüsselfähigkeiten/Flags “Certify”, “Sign” und “Encrypt” ist. Außerdem sollte man wissen, dass verschiedene Algorithmen nicht mit jedem Flag kombiniert werden können. Daher will ich kurz darauf eingehen.

Die folgenden Flags können auf GPG-Schlüssel angewendet werden:

  • C: “Certify”
    Zertifizierung/Certification. Dient dazu Schlüssel (eigene/von Dritten) zu unterschreiben.
  • S: “Sign”
    Unterschreiben/Signing. Dient dazu Daten (eigene/von Dritten), z.B. eine Datei oder Text, zu unterschreiben.
  • E: “Encrypt”
    Verschlüsselung/Encryption. Dient dazu Daten (eigene/von Dritten), z.B. eine Datei oder Text, zu verschlüsseln.
  • A: “Authenticate”8)
    Authentifizieren. Dient dazu einen Aufrufe/challenge zu signieren. Kann z.B, genutzt werden, wenn der GPG-Schlüssel für einen (wie auch immer gearteten) Login genutzt werden soll, um der Kommunikationsgegenstelle beim challenge zu beweisen, dass man derjenige ist, für den man sich ausgiebt (also Identitätsnachweis), um so Zugriff auf einen Dienst zu erhalten. “Authenticate” ist also vergleichbar mit “Certify”/“Sign”, nur eben nicht für Schlüssel oder Daten, sondern für challenges. Kann je nach Software z.B. den Login via Passwort ersetzen oder ergänzen.

Die verschiedenen Algorithmen sind damit wie folgt kombinierbar:

  • RSA
    Alles. Ein RSA-Key kann mit Certify, Sign, Encrypt und Authenticate geflaggt werden.
  • DSA
    Ein nur zum signieren geeigneter Algorithmus, kann mit Certify, Sign und Authenticate geflaggt werden.
  • ElGamal
    Ein nur zum verschlüsseln geeigneter Algorithmus, kann nur mit Encrypt geflaggt werden.

Will man also verschlüsseln und signieren – was jeder GPG-Nutzer will ;-) – hat man daher die Wahl zwischen einem RSA-Hauptschlüssel mit RSA-Unterschlüssel(n) (⇒ RSA/RSA) oder einem DSA-Hauptschlüssel mit ElGamal-Unterschlüssel(n) (⇒ DSA/ElGamal bzw. DSA/ELG genannt). Auf die verschiedenen Algorithmen will ich hier nicht weiter eingehen, es sei nur gesagt, dass bisher geglaubt wurde (!=bewiesen), dass das dem DSA zu Grunde liegende mathematische Problem (Discrete logarithm problem :lang_en:) schwerer zu lösen sei, als das von RSA (Integer factorization problem), und daher ein RSA-Schlüssel mehr Bits aufweisen muss, um gleiche Sicherheit zu bieten. Allerdings kommen daran mehr und mehr Zweifel auf, und GPG wird u.a. daher in Zukunft auch den Default von DSA/ElGamal 1024/4096bit auf RSA 2048/2048bit ändern9). Es folgt dennoch eine kleine Entscheidungshilfe.

RSA:

  • Pro:
    • Sehr gut untersucht, weit verbreitet.
    • Offen entwickelt.
  • Contra:
    • Sehr lange Signaturen im vgl. mit DSA (fällt vor allem bei kurzen E-Mails ins Gewicht; selbst 4-5 Zeilen Text bringen immer 1-2 Zeilen à 80 Zeichen “Signaturlast” mit).
    • Weniger kompatibel zu sehr alten GPG-Versionen.

DSA:

  • Pro:
    • Kurze Signaturen
    • Hohe Kompatibilität zu sehr alten GPG-Versionen.
  • Contra:
    • Weniger untersucht als z.B. RSA
    • Kleine Keygröße macht DSA ggf. anfällig in Zukunft gebrochen zu werden. Der zu Grunde liegende Hash (SHA-1) ist zwar noch als vertrauenswürdig anzusehen, aber nicht mehr für neue kryptographische Anwendungen empfohlen.

Umsetzung

Genug Prosa, es wird konkreter. Ich will zeigen, wie man das Beschriebene umsetzen könnte. Ich erstelle daher beispielhaft eine Hierarchie, die 1:1 nachvollzogen werden kann (d.h. sie ist 100% praxistauglich):

  • Hautpsignierschlüssel (RSA-4096bit, Flag(s): Certify, Verfällt nie (=0))
    Nur zum zertifizieren eigener und fremder Schlüssel, also dem Aufbau/Erhalt eines Web-of-Trust. Alle Identitäten/User-IDs werden von GPG immer automatisch über den Hauptschlüssel integriert.
    • Unterschlüssel (DSA-1024bit, Flag(s); Sign, verfällt nach zwei Jahren (=2y))
      Dient nur dem Signieren von Daten (z.B. E-Mail). DSA statt RSA da sie Signaturen erheblich kürzer ausfallen.
    • Unterschlüssel (RSA-4096bit, Flag(s); Encrypt, verfällt nach zwei Jahren (=2y))
      Dient nur zum Verschlüsseln von Daten (z.B. E-Mail).
    • Unterschlüssel (RSA-4096bit, Flag(s); Authenticate, verfällt nach einem Jahr (=1y))
      Dient nur Authentifikationsprozessen (z.B. Login via SSH etc.).

Nun haben wir also für jede Aufgabe einen eigenen Schlüssel. Das Ganze funktioniert hervorragend, da GPG automatisch den passenden Schlüssel für die jeweilige Aufgabe auswählt. Das heißt, wenn eine Anwendung beispielsweise an GPG meldet “verschlüsseln eines Textes für den Empfänger john.doe@example.com” wird automatisch der passende Hauptschlüssel über die E-Mail-Identität john.doe@example.com sowie ein Unterschlüssel mit dem Flag Encrypt ausgewählt. Dabei stellt es überhaupt kein Problem dar, wenn der Unterschlüssel ein Verfallsdatum hat, der Hauptschlüssel jedoch nicht.

Dass der/die Unterschlüssel ein Verfallsdatum hat und der Hauptschlüssel nicht, ist im Grunde der Entscheidende Unterschied zu einem Default-Schlüsselpaar, das mit einem Verfallsdatum z.B. wie folgt aussähe:

  • Hautpsignierschlüssel (RSA oder DSA, Flag(s): Certify, Sign, Authenticate, verfällt in x Jahren)
    • Unterschlüssel (RSA oder ElGamal, Flags(s): Encrypt, verfällt in x Jahren)

Da der Hautpsignierschlüssel in der Default-Konfiguration ebenfalls abläuft, wenn man den zur Verschlüsselung genutzten Unterschlüssel aus Sicherheitsgründen ablaufen lässt, sind damit auch die ganzen Unterschriften/das Web of Trust im Eimer, da wie schon erwähnt alle Identitäten immer am Hautpsignierschlüssel hängen.

Der Text ist zwar auf *ix zugeschnitten, die Informationen sollten aber auch Nutzern anderer Betriebssysteme dienlich sein. Die Kommandozeilenausgaben können – je nach verwendeter GPG-Version – leicht variieren.

Per Default legt GPG Signierschlüssel mit den Flags Sign, Certify und Authenticate10) an. Um einen in unserem Aufbau benötigten Certify-only Schlüssel zu erhalten, wird die --expert-Option verwendet. Falls man einen DSA-Schlüssel mit mehr als 1024bit anlegen will, muss --enable-dsa2 verwendet werden (darauf verzichte ich in meinen Beispiel, das hauptsächlich auf RSA fußt und DSA aus Kompatibilitätsgründen “nur” mit 1024bit nutzt).

Erstellen des Hautpsignierschlüssels

Nochmal die Eckdaten: RSA-4096bit, Flag(s): C, Verfällt nie (=0).

Man rufe den passenden GPG-Schlüsseldialog auf:

gpg --gen-key --expert

Man wählt dort (7) RSA (eigene Fähigkeit setzen). GnuPG konfrontiert einen dann mit folgender Ausgabe:

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Zertif. Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Zertif. Verschlüsseln
[...]

Wie man sieht sind per Default für RSA die Flags Sign Certify Encrypt gesetzt. Wir wollen einen Certify-only 4096bit-Schlüssel, daher schalte ich die entsprechenden Fähigkeiten im Dialog um (→ S, E), so dass man folgende Ausgabe sehen sollte:

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Zertif. Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Zertif. 
[...]

Jetz passen die Flags. Weiter geht's:

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 0
Schlüssel verfällt nie

Es folgen die persönlichen Angaben der Hauptidentität, d.h. man sollten den Namen und ggf. die “Haupt”-E-Mail-Adresse angeben.11) Alle Identitätsangaben können nachträglich editiert werden, weitere E-Mail-Adressen/Identitäten kann man ebenfalls später hinzufügen. Wenn man also in zwei Jahren die Firma und damit auch die berufliche E-Mail-Adresse wechselt ist das kein Problem.

Die Schlüsselgenerierung kann wirklich sehr lange dauern, u. U. sollte man schon mal 5-10 Minuten mitbringen.12)

Nach der Generierung sollte eine ähnlich lautende Meldung ausgegeben werden:

gpg: Schlüssel <KEYID> ist als uneingeschränkt vertrauenswürdig gekennzeichnet
Öffentlichen und geheimen Schlüssel erzeugt und signiert.

Diese <KEYID> sollte man sich für die folgenden Schritte notieren. Falls man es verpasst hat oder ein paar Tage später etwas ändern will, schlägt man sie einfach kurz via gpg --list-keys nach.13)

Erstellen der Unterschlüssel

Erzeugen der Unterschlüssel, wie direkt unter “Umsetzung” beschrieben.

Sign-only DSA-Unterschlüssel

Erstellen des Sign-only DSA-Unterschlüssels (DSA-1024bit, Flag(s); Sign, verfällt nach zwei Jahren (=2y)).

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's:

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 3

Mögliche Aktionen für einen DSA Schlüssel: Unterschreiben Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Sign-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben sieht, nichts mehr ändern. Es kann also direkt weitergehen:

Ihre Auswahl? Q
Das DSA-Schlüsselpaar wird 1024 Bit haben.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.

Nun heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save

Encrypt-only RSA-Unterschlüssel

Erstellen des Encrypt-only RSA-Unterschlüssels (RSA-4096bit, Flag(s); Encrypt, verfällt nach zwei Jahren (=2y)).

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's:

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 7

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Encrypt-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln sieht, noch den “Unterschreiben”/Sign-Flag entfernen und dazu wie folgt vorgehen:

Ihre Auswahl? S

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun passt es. Weiter geht's:

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
[...]

Nun heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save

Authenticate-only RSA-Unterschlüssel

Erstellen des Authenticate-only RSA-Unterschlüssels (RSA-4096bit, Flag(s); Authenticate, verfällt nach einem Jahr (=1y)).

gpg --edit-key --expert Key-ID-des-Hauptschlüssels
Befehl> addkey

Nun muss man seinen Passphrase eingeben, um den Private-Key zu entsperren und den Unterschlüssel hinzufügen zu können.

Los geht's:

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (2) DSA (nur unterschreiben/beglaubigen)
   (3) DSA (eigene Fähigkeit setzen)
   (4) Elgamal (nur verschlüsseln)
   (5) RSA (nur signieren/beglaubigen)
   (6) RSA (nur verschlüsseln)
   (7) RSA (eigene Fähigkeit setzen)
Ihre Auswahl? 7

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun setzt/entfernt man also die Flags, die man nicht haben will. Für einen Authenticate-only-Schlüssel muss man, wie man an der Zeile Derzeitige erlaubte Aktionen: Unterschreiben Verschlüsseln sieht, noch den “Unterschreiben”/Sign-sowie den “Verschlüsseln”/Encrypt-Flag entfernen und den “Authentifizierung”/Authenticate-Flag hinzufügen. Dazu geht man wie folgt vor:

Ihre Auswahl? S

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Verschlüsseln 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Ihre Auswahl? E

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Ihre Auswahl? A

Mögliche Aktionen für einen RSA Schlüssel: Unterschreiben Verschlüsseln Authentifizieren 
Derzeitige erlaubte Aktionen: Authentifizieren 

   (S) Umschalten der Fähigkeit zum Unterzeichnen
   (E) Umschalten der Verschlüsselungsfähigkeit
   (A) die Fähigkeit zur Authentifizierung umschalten
   (Q) Beendet

Nun passt es. Weiter geht's:

Ihre Auswahl? Q
RSA Schlüssel können zwischen 1024 und 4096 Bits lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 4096
Die verlangte Schlüssellänge beträgt 4096 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am <DATUM> <UHRZEIT>
Ist dies richtig? (j/N) j
Wirklich erzeugen? (y/N) y
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
[...]

Jetzt heißt es warten.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save

Weitere Identitäten hinzufügen

gpg --edit-key Key-ID-des-Hauptschlüssels
Befehl> adduid

Der folgende Dialog sollte selbsterklärend sein. Falls einem die Identitätsverwaltung via Konsole zu frickelick ist, dem kann ich Seahorse als grafische Oberfläche empfehlen.

Falls man sich mal vertippt hat: Editieren ist nicht möglich. Stattdessen muss man die fehlerhafte Identität löschen und anschließend neu anlegen.

Die Hauptidentität kann mittels

gpg --list-key Key-ID-des-Hauptschlüssels
Befehl> primary
Bitte genau eine User-ID auswählen.

Befehl> <NUMMER>

ausgewählt werden.

<NUMMER> entnimmt man der direkt darüber angezeigten Auflistung. Beispiel

[uneingeschränkt] (1).  John Doe (privat) <foobar@example.com>
[uneingeschränkt] (2)   John Doe (business) <business@example.com>

(1). ist die derzeitige Hauptidentität. Um (2) zur Hauptidentität zu machen, müsste man also

gpg --edit-key Key-ID-des-Hauptschlüssels
Befehl> primary
Bitte genau eine User-ID auswählen.

Befehl> 2

verwenden. Im der folgenden Auflistung ist die neue Hauptidentität mit einem Sternchen gekennzeichnet. Die Nummerierung ändert sich erst nach dem Speichern.

Ist alles erledigt, jetzt muss man die Änderungen speichern und kann anschließend wieder zur Konsole wechseln:

Befehl> save
Befehl> quit

Überprüfen

Alles was man gerade erstellt hat, kann man sich einfach auflisten lassen:

gpg --list-key Key-ID-des-Hauptschlüssels

Es sollte eine Ausgabe, erscheinen, die so ähnlich aussieht wie die Folgende:

pub   4096R/B55A743F <DATUM>
uid                  John Doe (privat) <foobar@example.com>
uid                  John Doe (business) <business@example.com>
sub   1024D/56F9EF32 <DATUM> [verfällt: <DATUM>]
sub   1024R/A99B3881 <DATUM> [verfällt: <DATUM>]
sub   2048R/6D0696AE <DATUM> [verfällt: <DATUM>]

Hinweise zum Verständnis:

  • Hinter pub findet sich der Hauptschlüssel.
  • Hinter sub findet sich jeweils ein Unterschlüssel
  • Hinter uid finden sich and den Hauptschlüssel angehängte Identitäten (User-IDs).
  • Die Bitstärke, Algorhithmus, Key-ID und Erstellungsdatum verstecken sich in hinter <BITS><ALGORHITMUS>/<KEYID> <DATUM>. R steht dabei für RSA, D für DSA und g für ElGamal.14)

Fertig. Die neue Schlüsselhierarchie ist einsatzbereit. Jetzt einfach den Publickey exportieren und wie gewohnt nutzen, unterschreiben lassen etc..

5)
oder erst nach vielen Jahren
6)
z.B. jährlich
7)
am besten die Einstiegs-Weblinks am Ende dieses Textes durcharbeiten und alles einmal ausprobieren
8)
seit GPG 1.4 verfügbar
10)
seit GPG 1.4
11)
es geht aber auch gänzlich ohne
12)
also nicht an der Meldung “Es sind nicht genügend Zufallswerte vorhanden. Bitte führen Sie andere Arbeiten durch, damit das Betriebssystem weitere Entropie sammeln kann!” verzweifeln, sondern einfach dem Rat folgen und ein wenig surfen, bis sich wieder etwas tut.
13)
Aufbau: pub <BITS><ALGORHITMUS>/<KEYID> <YYYY-MM-DD>. Die gesucht ID steht also hinter dem Schrägstrich.
14)
in der hier vorhanden Konfiguration nicht genutzt

// Der moderne Satzbau

[Subjekt] - [Prädikat] - [Beleidigung], Alter!

LOL

// Internationale, mehrsprachige Websites: Content Negotiation to the rescue?

Eigentlich sollte es heute kein Problem mehr sein: internationalisierte Websites in verschiedenen Sprachen. Oder – falls keine vollständige Internationalisierung15) nötig ist – zumindest die Anzeige des gleichen Inhalts in den jeweiligen nativen Sprachen. Doch die Aufgabe ist komplizierter als man denkt und in großen Teilen des Webs nur mangelhaft gelöst.

Ein Weg aus der Misere kann Content Negotiation darstellen, dieser Text setzt sich damit auseinander.

Warum überhaupt Internationalisierung (i18n) und Lokalisierung (l10n)?

Ich arbeite in der Webbrache. Werden Umsätze online generiert ist je nach Projektausrichtung jeder Nutzer wichtig. Trotz offensichtlicher Dominanz der englischen Sprache wäre es daher ein grober Fehler Lokalisierungen links liegen zu lassen. Das Internet ist mittlerweile bei der breiten Masse angekommen, 2009 wurden mehr als 50% der Google Suchanfragen in anderen Sprachen als Englisch gestellt, 33% davon in einer europäischen Sprache,16) Tendenz steigend. Der e-Commerce-Markt Europa ist riesig und sofern eine Website in der nativen Sprache vorliegt, kaufen Benutzer vier mal häufiger online ein und verbringen mehr als doppelt so viel Zeit auf ihr.17)
Außerdem hat man im Web vornehmlich mit in den USA ansässigen Unternehmen zu konkurrieren, welche Lokalisierungen oft gänzlich oder sehr lange vernachlässigen – so kann man sich mit lokalisierten Projekten einen Vorteil auf nicht-US-Märkten verschaffen. Manchmal funktioniert dies sogar, wenn man ansonsten viel schlechter ist – ein StudiVZ wäre meiner Meinung nach niemals möglich gewesen, wenn Facebook sich von Beginn an mehr um übersetzte Versionen der eigenen Seite inkl. Marketing gekümmert hätte.18)

Das Thema ist also wichtig und ein paar Gedanken wert.

Das Problem: Internationalisierung (i18n) und Lokalisierung (l10n) ist aufwendig

Die meiste gängige Web-Software ist mit der Verwaltung eines Dokuments in mehreren Versionen ziemlich überfordert oder entsprechende Features für nicht-Techniker kaum zu bedienen. Oft existiert lediglich kein Problembewusstsein, da einfach in der jeweiligen Muttersprache veröffentlicht wird oder gar das ganze Projekt für jede Sprache auf einer spezifischen Länderdomain parallel gepflegt wird. Letzteres sorgt aber mit Garantie für höheren Wartungsaufwand (→ parallele Infrastrukturen), mehr Kosten (→ Domains, Infrastruktur) und manchmal sogar redundanten Code (denn nicht immer arbeitet man mit Systemen, der Architektur man komplett selbst beeinflussen kann). Zudem bergen parallele Strukturen die ständige Gefahr, dass veraltete Inhalte entstehen oder nicht alle Inhalte auf allen Plattformen verfügbar sind, was wiederum aufwendige Synchronisation bedingt. Diese Probleme können die eigentliche Übersetzung von Inhalten bezüglich Aufwand als auch Kosten leicht um ein Vielfaches übersteigen.

Daher wird oft komplett auf Übersetzungen verzichtet oder vieles ausschließlich in Englisch veröffentlicht, um mit einer Inhaltsversion möglichst viele Menschen zu erreichen (So handhabe ich das auch hier mit diesem Blog). Englisch hat eben nicht nur den Vorteil, dass mit den USA, Australien, Großbritannien etc. schon eine ganze Menge Menschen beisammen sind (das wäre mit z.B. Spanisch ebenso der Fall), sondern dass eben sehr viele Menschen Englisch als Zweitsprache gut genug verstehen, um an die präsentierten Informationen in hinreichender Qualität zu gelangen. Nichts desto weniger vergrault man Leser, Nutzer und Kunden, welche ggf. mit dem Projekt ansonsten glücklich wären.
Für kleinere Websites und private Projekte wie dieses Blog mag das kein Problem sein (vorallem wenn keine kommerziellen Interessen verfolgt werden). Doch auch Konzerne mit viel Geld haben ähnliche Probleme (und die grottigen Internationalisierungen und Websites die außer toller Grafiken und Marketing-Sprech nichts bieten, sind der Beweis dafür). Sie können sich das oft nur leisten, weil das eigentliche Geschäft Offline stattfindet.19)

Für Web-Unternehmen ist das freilich kein Trost. Doch vielen kann mittels Content Negotiation geholfen werden, solange man die Fallstricke kennt.20)

Content Negotiation - Funktionsweise

Technisch sind mehrere Übersetzungen in den Griff zu bekommen, Content Negotiation heißt das entsprechende Stichwort. Es beschreibt das Vorgehen, dass die Website http://example.com/foobar je nach Spracheinstellung des Besuchers (→Accept-Language-Header) den Inhalt in der jeweils passenden Sprache anzeigt. Falls keine passende Übersetzung vorhanden ist wird auf einen Fallback zurückgegriffen, meist Englisch.

Die Vorteile liegen auf der Hand: Man hat eine Infrastruktur ggf. sogar unter lediglich einer Domain zu pflegen. Auch hinsichtlich der Aktualität und Flexibilität wäre man im Grunde aus dem Schneider, da bei fehlenden Übersetzungen ohne Aufwand zumindest aktueller “Fallback”-Inhalt in Englisch angezeigt werden kann. Im schlechtesten Fall steht man also immerhin genauso gut da wie ein Konkurrent, der ausschließlich englischsprachige Inhalte anbietet – so kann schnell reagiert und nach und nach ergänzt werden.

Mittels Content Negotiation kann man also dafür sorgen, dass der Besucher immer die vermeintlich geeignetste Übersetzung erhält. Damit das alles klappt und auch Proxies etc. nicht verwirrt werden teilt man über den Vary-Header mit, dass der Inhalt Aufgrund bestimmter vom Client gesendete Daten verändert wurde (z.B. mit dem Wert Negotiate,Accept-Language).

Zusammen mit einer manuellen Sprachauswahl auf der Website selbst (welche die Präferenz z.B. via Cookie speichert) wäre die Lösung IMHO fast perfekt, sofern man davon absieht, dass die URLs selbst natürlich nicht lokalisiert sind (→ http://example.com/free vs. http://example.com/kostenlos). Damit die URLs vorhersehbarer sind, könnte man noch diverse Alias-Seiten anlegen und mittels 301 Moved Permanently-Weiterleitungen und/oder Tags wie <link rel="canonical" href="http://example.com/page.html"/>21) dafür Sorgen, dass Suchmaschinen nur die gewünschte URL in den Index aufnehmen.

Kurzusammenfassung:

  • Der Accept-Language-Header des aufrufenden Clients wird analysiert.
  • Die enthaltenen, gewichteten IETF-Language-Tags werden ausgewertet und basierend darauf die passende Übersetzung/Lokalisierung ausgeliefert.
  • Damit der Client wahrnimmt was passiert und Proxies weniger Probleme bereiten, sollte serverseitig der Vary-Header verwendet werden.
  • Die “Duplicate Content”-Problematik bekommt man ohne Probleme mittels 301-Redirects und <link rel="canonical"> in den Griff.
  • Beispiel: http://example.com/content.html wird aufgerufen mit einem Browser, welcher Accept-Language mit dem Wert de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 sendet. Deswegen wird die Seite in Deutsch ausgeliefert und über Vary mit dem Wert Negotiate,Accept-Language mitgeteilt, das das Ergebnis mit einem anderem Accept-Language-Wert anders aussehen könnte.

Problem: "Vary"-Header vs. Crawler

Ich denke mittels “reinem” Content Negotiation kommen viele Lösungen aus (für reine Intranet-Software würde ich sofort darauf zurückgreifen). Man sollte vor einem Internet-Einsatz allerdings die Nachteile kennen, und sich in der technischen Realisierung auf einen gewissen Mehraufwand einstellen, um einen Workaround zu realisieren (womit Content Negotiation nicht mehr ganz so elegant ist :-():

  • Google ignoriert den ''Vary''-Header, Yahoo! ebenso.
    Indiziert wird daher lediglich die Sprachversion, die der jeweilige Crawler/Bot angefordert hat. Die Bots von Google und Yahoo! geben sich selbst als englischsprachig aus und “sehen” daher nur die englische Version der bereitgestellten Inhalte. Man kann das Problem damit beschreiben, dass Suchmaschinen “eine URL, eine Version des Dokuments” fordern.22)
  • Die Folge sind weniger Besucher durch nicht-englischsprachige Suchanfragen
    Z.B. solche, die sich in den jeweiligen Sprachen stark unterscheiden. Internationale Produktnamen sind weniger das Problem aber “Fahrrad” und “Bicycle” wäre eines. Bei der Google-Suche kommt sogar noch hinzu, das viele Nutzer mit der Spracheinstellung “Seiten auf X” suchen, was die indizierten Inhalte u.U. komplett ausschließt. Sucht jemand über das deutschsprachige Google.de mit der Einstellung “Seiten auf Deutsch” wird er unsere nur auf englisch indizierten Inhalte nicht finden, obwohl eine deutsche Übersetzung verfügbar ist.

Die IMHO praxistauglichste Lösung dieser Problematik ist, Content Negotiation einzusetzen aber dennoch auf jeder Seite permanente URLs zu einer erzwungenen Sprache anzubieten (entweder über Unterverzeichnisse oder Subdomains). Selbige werden dann zusätzlich indiziert und decken Suchanfragen in den jeweiligen Landessprachen zuverlässig ab. Beispiel mittels Unterverzeichnissen:

  • http://example.com/free – Content Negotiation-Version mit Englisch als Fallback, jeweils mit Links auf:
    • http://example.com/de/free – Deutsche Version
    • http://example.com/fr/free – Französische Version
    • […]
    • http://example.com/en/free – Englische Version (der Konsistenz wegen).
      Diese Version ist hinsichtlich der Suchmaschinen allerdings redundant und sollte ggf. auf http://example.com/free weiterleiten oder via <link rel="canonical"> auf diese Version verweisen. Man könnte auch mittels “noindex” ausschließen.

“Real-World”-Beispiel, direkt zum selbst ausprobieren – Die Apache-Webserver-Dokumentation:

Diesem Workaround kann man bei Bedarf sogar noch einen Vorteil abringen, indem die sprachspezifischen Links lokalisiert und so seine Schlüsselworte besser positionieren kann:

  • http://example.com/free/
  • http://example.com/en/free/
  • http://example.com/de/kostenlos/

Die Lösung “Content Negotation + einzigartige URLs zu den Übersetzungen” ist in meinen Augen ein guter Kompromiss. Der Benutzer bekommt beim normalen Surfen immer möglichst kurze, universelle URLs präsentiert, die bei Weitergabe den jeweiligen Nutzer wiederum in der geeignetsten Sprache präsentiert werden. Bei Bedarf kann dennoch auf explizit eine Sprachversion verlinkt werden, Sprachspezifische Google-Suchen führen nicht ins Leere und man erhält bessere Page-Ranks, da ggf. doch mehr Nutzer auf ein und die selbe, universelle URL verweisen. :-)

15)
Wem der feine aber wichtigen Unterschied zwischen Internationalisierung (i18n) und Lokalisierung (l10n) nicht klar ist lege ich die Lektüre von Internationale und mehrsprachige Webseiten ans Herz
18)
Das wird die VZ-Netzwerke freilich nicht mehr retten, da die eigene Position leichtsinnig verspielt wird und der Abwärtstrend IMHO kaum aufzuhalten ist.
19)
Welchen Endverbrauchen interessiert es denn wirklich, ob die Website von Siemens, Bosch oder General Electric “suboptimal” realisiert ist, solange man über Google noch Handbücher und Datenblätter findet…
20)
wenngleich es sich dennoch nicht für jeden eigenen mag – aber bekanntlich führen viele Wege nach Rom
22)
ich rede hier nicht von der “Duplicate Content”-Problematic die man über 301-Redirects, <link rel="canonical"> und “noindex”-Regeln leicht in den Griff bekommt
23)
eine deutsche Übersetzung ist derzeit leider nicht verfügbar, ein deutschsprachiges Browser-Setting eignet sich daher hier für Demo-Zwecke weniger

// New GnuPG public key

I will write a posting about this key during the next weeks or so (Update: There it is). It comes with a nice hierarchy, making subkey changes possible without loosing the WebOfTrust plus usage of the best fitting algorithm for the different tasks.

24)
This URL always points to the latest key I am using – If I have to replace my current key for whatever reason, you'll get the new one here.

// Vermeintlich sinnloser Wortlisten-SPAM und dessen Hintergrund

Gerade schlug hier eine Mail auf, die nur mit ca. 150 sinnlos wirkenden Worten angefüllt war. Ohne erkennbaren Inhalt, sowas kommt von Zeit zu Zeit vor.

Wer sich schon immer gefragt hat, warum Spammer solche “bescheuerten” Mails rausschicken (schließlich bekommt man damit ja nix verkauft), dem sei gesagt: das sind keine ungewollten Fehler, das sind auch keine Erreichbarkeitstests. Mit solchen Mails soll das Durchkommen künftiger SPAM-Wellen bzw. der dazu benötigten Schlüsselwörter begünstigt werden. Mit den Wortlisten werden statistische Filter mit Fehlinformationen gefüttert. Im Speziellen geht es da meist um das Vergiften von Bayesschen Filtern, denn die gängigen Implementierungen sind “lernend” hinsichtlich der Worthäufigkeiten in bereits durchgekommenen E-Mails. Das ist der profane Hintergrund dieser rätselhaften Mails.

// Thunderbird v2 in Verbindung mit IMAP: Migrations-Tipps und -Stolpersteine

Bisher habe ich meinen E-Mail-Verkehr komplett über den Laptop abgehandelt. Den konnte ich problemlos zu verschiedenen Arbeitsplätzen mitnehmen. Gemacht habe ich das, um nicht irgendwelche Thunderbird-Profile wg. POP3 frickelig synchronisieren zu müssen um immer alle Daten parat zu haben. IMAP habe ich bisher, trotz der vielen Vorteile (inkl. der Lösung des Synchronisationsproblems), gemieden. Mir behagte nicht, dass mein Mail-Archiv unverschlüsselt auf einem Internet-Server existiert.

Mittlerweile tingle ich aber regelmäßig zwischen mehreren Arbeitsplätzen an denen feste Desktops stehen… und den Laptop nur wg. Mail mitzuschleppen nervt. Zudem schlägt hier praktisch sämtliche archivierungswürdige Korrespondenz GnuPG verschlüsselt auf (das war n' Stück Erziehungsarbeit ;-) ). Also war es Zeit umzustellen und meinen Thunderbird etwas zu auf die Sprünge zu helfen.

Wer Ähnliches vor hat, findet die folgenden Infos ggf. interessant. Ich gehe aber nicht darauf ein, was IMAP leistet, warum man es haben will und wie man feststellt, ob der eigene Mail-Server IMAP unterstützt. Wikipedia und Google sind da ziemlich ergiebig.

IMAP-Konto und die alten Mails auf den Server bekommen

Konto einrichten – es ist sehr viel einfacher als man vielleicht denkt. Zum einen muss man an seinem Postfach auf dem Mailserver normalerweise nichts ändern. Man fragt es nur nicht über POP3 sondern IMAP ab. Damit Thunderbird das macht, legen wir ein neues IMAP-Konto an. Das macht auch das “Umziehen” der bisher schon gespeicherten Mails leichter. Einfach via “Extras\Konten…”, Button “Konto hinzufügen…” links unten den entsprechenden Assistenten starten: E-Mail-Konto auswählen, Namen und E-Mail-Adresse eingeben und im dritten Dialog dann schließlich “IMAP” statt dem voreingestellten “POP” auswählen. Der Rest erklärt sich von selbst. Anschließend sollte man nicht vergessen, unter “Server-Einstellungen”→“Verschlüsselte Verbindung verwenden: TLS” auszuwählen (sofern dein Server dies unterstützt. Im Zweifelsfall auf “TLS, wenn verfügbar” stellen). Falls es bei Massenhostern zu nervigen “Domain passt nicht zum Zertifikat”-Meldungen kommt (die natürlich berechtigt sind, aber besser ein Domain-Mismatch als unverschlüsselt) hilft das Add-On Remeber Dismatched Domains weiter. Ab Thunderbird v3 wird man das wohl nicht mehr brauchen, da man da wohl – wie beim Firefox3 auch – dauerhafte Ausnahmen speichern kann.

Mails umziehen – Hat man das neue Konto angelegt läuft es ziemlich einfach weiter: Man kann nämlich per Drag&Drop oder “Rechtsklicke\Verschieben” die Mails der alten, lokalen Ordner in das neue Konto verschieben und dadurch auch auf den Server hochladen. Man kann prinzipiell sogar ganze Ordner kopieren (verschieben geht per Drag&Drop geht bei Ordnern nicht), das würde ich aber nicht empfehlen. Zum Einen buggt Thunderbird rum, wenn nicht mindestens eine E-Mail in jedem (Unter)Ordner liegt, zum Anderen werden die Mails dann eben nur kopiert und man muss den Überblick behalten. Mangels gescheiter Status-Anzeige ist dies schwer, so weiß man dann nicht wirklich ob alles gut geklappt hat und muss manuell abgleichen. Ich würde empfehlen die eigene Ordnerstruktur geschwind im IMAP-Konto neu anzulegen, und dann den Inhalt der lokalen Ordner mittels Bearbeiten\Auswählen…\Alles bzw. Ctrl+A Ordner für Ordner zu verschieben. Da sieht man ganz genau wie die einzelnen Mails auf den Server landen und anschließend alle Mails aus dem lokalen Ordner verschwunden sind. Wenn alle Mails verschoben sind, kann und sollte man das alte POP-Konto unter “Extras\Konten…” löschen um nicht wieder alle gerade mühsam verschobenen Mails wieder abzurufen und damit vom Server zu kratzen ;-).

Feintuning (u.a. schnelle Anzeige großer Mails ohne Offline-Sync)

Man wird es schnell merken: bei allen Vorteilen, wenn die E-Mails auf dem Server liegen, nervt es, dass es sehr lange braucht eine E-Mail mit großem Dateianhang anzuzeigen da Thunderbird erst die gesamte Mail herunterlädt bevor der Text angezeigt wird. Und das hat nicht wirklich einen Vorteil, klickt man nämlich auf “Speichern unter…” wird der Anhang wieder heruntergeladen (also nichts mit Caching). “Beheben” kann man das Verhalten ganz einfach, wenn man unter “Ansicht\Anhänge” eingebunden anzeigen den Haken entfernt. Dann lädt Thunderbird den Anhang erst herunter, wenn man ihn öffnet oder speichern will, folglich bekommt man den Text der Mails sehr viel schneller zu Gesicht. Den einzigen Nachteil den man durch deaktivieren der Funktion hat: wenn wirklich nur Bilder angehängt sind werden selbige eben, wie die Funktion auch sagt, nicht direkt unter dem Text angezeigt. Das kann ich aber verschmerzen, weitaus weniger schlimm als oft ne halbe Minute auf meinen Text zu warten.

Was ggf. auch nervt ist, dass man kein längeres Abfrage-Intervall mehr hat und die Mails direkt reintriggern. An sich natürlich ein großer Vorteil, aber bei angeschalter Benachrichtigung über neue Mails (unter “Extras\Einstellungen…”, Reiter “Allgemein” ganz unten) bekommt man zu verkehrsstarken Zeiten nämlich ständig ein Pop-Up (statt z.B. nur alle zehn Minuten beim einmaligen Abfragen des Servers, dass man X neue Mails hat). Aber es gibt eine extrem schöne Abhilfe: Die allgemeine Benachrichtigung abschalten und das Add-On Mailbox Alert nutzen. Da kann man das ganze Ordner-Weise steuern und wird nicht von Traffic-starken Mailinglisten oder Ähnlichem belästigt. Nach der Installation einfach auf die relevanten Order rechtsklicken und im Kontextmenü “Mailbox Alert” anklicken. Der folgende Dialog sollte weitestgehend selbsterklärend sein. Auf der Mailbox-Alert-Website findet man auch, wie man den Absender, Subject etc. in die Benachrichtigung bekommt (einfach die dort gelisteten Platzhalter verwenden, ich habe mich für %sendername (%countall neu) und %subject entschieden.

Fehlerbehebung in Verbindung mit GnuPG und Enigmail ("IMAP-Nachricht ist zu groß zum entschlüsseln")

Nach einer Weile fiel mir auf, dass ich manchmal Probleme beim Öffnen verschlüsselter Mails mit Anhang habe. Statt mit dem Inhalt wurde ich nach Eingabe des Passphrase mit der Fehlermeldung “IMAP-Nachricht ist zu groß zum entschlüsseln” konfrontiert. Kurzes googlen brachte die nötigen Informationen. Hängt wohl mit dem deaktivierten Ansicht\Anhänge eingebunden anzeigen zusammen, welches mit den Enigmail-Defaults kollidiert. Einfach unter “OpenPGP\Einstellungen…” den Reiter “Erweitert” auswählen und die unterste Option “Anhänge nur herunterladen, wenn diese geöffnet werden sollen (nur bei IMAP)” deaktivieren. Dann klappt wieder alles. Allerdings verträgt sich diese Einstellung nur bedingt mit PGP/MIME, da dies ja eben genau verhindern soll, dass ein Client/Dritter sehen kann, wo welche Anhänge existieren. Wenn man also viele PGP/MIME-Nachrichten bekommt muss man ggf. doch mit ein wenig längerer Ladezeit leben.

I'm no native speaker (English)
Please let me know if you find any errors (I want to improve my English skills). Thank you!
QR Code: URL of current page
QR Code: URL of current page start (generated for current page)