Zunächst würde dovecot ein selbstsigniertes Zertifikat benutzen. Zwar könnte man jetzt stattdessen ein eigenes Zertifikat mit openssl erstellen, doch hätte man dadurch kaum etwas gewonnen. Dennoch sei an dieser stelle erwäht, dass

Common Name (eg, YOUR name) []:

nicht etwa nach einem Personennamen fragt, sondern nach dem Domainnamen des Mailservers. In meinem Fall also mail.jdsrv.de.

Hat man sich stattdessen entschlossen, ein Zertifikat von cacert.org zu beantragen, so speichert man den Privaten Schlüssel sowie das Zertifikat dort, wo dovecot es erwarten würde (z.B. /etc/ssl/cert/dovecot.pem bzw. /etc/ssl/private/dovecot.pem) und startet dovecot neu. Wie man so ein Zertifikat beantragt und den privaten Schlüssel generiert, entnimmt man am besten einer Anleitung.

Hat man das alles geschafft, so muss man Windows nur noch davon überzeugen, dass cacert.org vertrauenswürdig ist, denn sonst:

Also importiert man die Root-Zertifikate (Class 1 und Class 3) von cacert.org mit dem Internet Explorer.

Link (PEM Format) anklicken, Datei öffnen, “Zertifikat installieren…”, “Weiter >”, “Alle Zertifikate in folgendem Speicher speichern”, “Durchsuchen…”, “Vertrauenswürdige Stammzertifizierungsstellen”, “OK”, “Weiter >”, “Fertig stellen”, Fingerabdruck mit dem auf der Webseite vergleichen, bei Übereinstimmung “Ja”, “OK”.

Danach sollte auch Outlook keine Warnung mehr anzeigen.

Wenigstens bleibt so etwas aber nicht ohne Lerneffekt:

• Deaktiviere keine Dienste von Windows, ohne genau zu wissen, wofür sie zuständig sind und welche Dienste von Ihnen abhängig sind, wofür diese wiederum zuständig sind, welche Dienste von diesen wiederum abhängen…
  Denn: Es kann passieren, dass die Performance des Rechners sich durch diese Maßnahme verbessert und dass die Soundausgabe nebenbei nicht mehr funktioniert. Der Windows-Audio-Dienst hängt nämlich von der Windows-Audio-Endpunkterstellung ab und diese hängt wiederum von einem anderen Dienst ab, der aber nicht näher benannt wird. Schlecht ist jedenfalls, wenn der RPC-Server nicht gestartet werden kann. Einen Dienst, der so heißt, gibt es selbstverständlich nicht, doch mehr erfährt man aus der Fehlermeldung auch nicht.
• Wenn man doch Dienste von Windows deaktiviert, ohne genau zu wissen, wofür sie zuständig sind [... wir hatten das schon], dann sollte man vorher die Liste der Dienste exportieren. Zumindest Windows 7 bietet eine entsprechende Funktion an. So kann man später im Zweifel alle Dienste, die vorher aktiviert waren, wieder aktivieren.
• Wenn man nicht vorher die Liste der Dienste exportiert hat, war das ein Fehler. Aber wozu hat man Mitbewohner mit dem gleichen Betriebssystem auf ihrem Rechner.

• Eine .exe-Datei, die gar nicht allzu kompliziert ist, die ohne Installation auskommt und eigentlich nur eine Netzwerkverbindung aufbaut, kann auf einem Rechner mit Windows XP SP 3 funktionieren, auf einem anderen nicht. Natürlich erscheint auch hier die passende Fehlermeldung:

Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren.

• Noch einmal: Das Programm kommt ohne Installation aus, es besteht nicht einmal die Möglichkeit einer Installation. Die Konfiguration wird nach dem Programmstart zum ersten Mal vorgenommen.

• Wenn Mailinglisten über Mailman E-Mails mit dem Absender bla@sub.einedomain.tld verschicken, so sollte bla auch einen A-Record im Zonefile des zuständigen DNS-Servers besitzen. Sonst könnten verschiedene Mailserver auf böse Ideen kommen.

Mailman vs. Mailserver

Gegeben:
eine Domain www.einedomain.tld, eine Subdomain sub.einedomain.tld, eine Mailingliste liste@sub.einedomain.tld, konfiguriert mit Mailman, sowie eine Weiterleitung liste@einedomain.tld -> liste@sub.einedomain.tld.

Gewünschtes Verhalten:
Benutzer x mit E-Mail-Adresse x@eineanderedomain.tld schickt eine E-Mail an liste@einedomain.tld oder liste@sub.einedomain.tld. In beiden Fällen soll diese E-Mail an alle Abonnenten der Liste ausgeliefert werden. Als Absender (also im FROM-Header) soll x@eineanderedomain.tld erscheinen, die Antwortadresse (REPLY-TO-Header) soll die Adresse der Liste, also liste@sub.einedomain.tld sein.

Tatsächliches Verhalten:
Benutzer x, der eine Kopie seiner Nachrichten wünscht, empfängt die E-Mail und als Antwortadresse ist liste@sub.einedomain.tld eingetragen. So weit, so gut.
Benutzer y, ein anderer Abonnent der Liste, empfängt die E-Mail, die an seine Adresse y@einedrittedomain.tld geschickt wurde und sieht als Antwortadresse liste@www.einedomain.tld.

Was hat Benutzer y falsch gemacht? Nichts.

Was hat Benutzer x falsch gemacht? Auch nichts.

Was hat wurde bei der Einrichtung von Mailman falsch gemacht? Wieder nichts.

Wer ist dann Schuld?

Zum einen ist der DNS-Server, der für die Domain einedomain.tld (und alle ihre Subdomains) zuständig ist, so konfiguriert, dass für die Subdomain sub lediglich ein CNAME-Eintrag vorhanden war, der auf www gezeigt hat. Ein Fehler, denn:

Canonicalization: RFC-821 Section 3.1

The domain names that a Sender-SMTP sends in MAIL and RCPT commands MUST have been “canonicalized,” i.e., they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations. A canonicalized name either identifies a host directly or is an MX name; it cannot be a CNAME.

Zum anderen ist der Mailserver, der für einedrittedomain.tld zuständig ist, so konfiguriert, dass die Domains ankommender E-Mails nachgeschlagen werden und durch die Domain ersetzt werden, auf die sie verweisen (wenn sie nur einen CNAME-Eintrag haben). Der Mailserver verändert also den FROM-Header und den REPLY-TO-Header. Ob das sein muss, ist fraglich, da zumindest Mailserver existieren, die das nicht tun und diese nicht unbedingt als unbedeutend einzustufen sind (z.B. der Mailserver von Google).

Dieses Horror-Szenario stellte uns gestern die Tagesschau in Aussicht. Die ICANN wolle ihre Root-Server abschalten, um vom IPv4-Protokoll auf das modernere IPv6-Protokoll umzuschalten. Der Grund: IPv4-Adressen neigen sich dem Ende zu, IPv6-Adressen gäbe es mehr als genug. Der “langsame Wechsel” habe nicht funktioniert, also müsse man zu dieser radikalen Lösung greifen.

Das Ergebnis: weltweites Chaos. Welche Bank arbeitet mit Systemen, die IPv6 komplett unterstützen? Welcher Flughafen wäre auf diese Veränderung eingestellt? Das sind nur zwei Beispiele – von vielen.

Zur Beruhigung: Gestern war der 1. April. Der Artikel war ein – wenn auch gut erarbeiteter – Scherz. Dazu kam es natürlich zu einigen Kommentaren der Leser, wovon die Tagesschau wenige exemplarisch zitiert. Einer davon soll auch hier zitiert werden:

S.M. aus Jena schrieb uns: “Geiles Ding, hab´s echt geglaubt und das, obwohl ich im Nebenfach Informatik studiere. Hab mich zwar gewundert, weil das Internet doch eigentlich dezentral angelegt ist, aber der Artikel war fast schon zu gut recherchiert für einen Aprilscherz.”

Gut, Informatik im Nebenfach ist löblich. Das bedeutet allerdings im Zweifel nur, dass die ersten beiden Vorlesungen des Informatikstudiums belegt werden müssen. Da wird das Internet nicht allzu umfangreich behandelt. Sonst wüsste man wohl, dass dieses zwar dezentral angelegt ist, insbesondere die DNS-Rootserver, um deren Abschaltung es im Artikel ging, dass diese Root-Server zwar von verschiedenen Institutionen betrieben, jedoch von der ICANN koordiniert werden. Wenn die ICANN jetzt also die Möglichkeit (und den Willen) hätte, die 13 Root-Server abzuschalten, die es gibt, so hätten wir ein Problem. Oder?

Welcher Idiot hat sich das denn einfallen lassen? Es müssen lediglich 13 Rechner ausgeschaltet werden, damit das Internet nicht mehr funktioniert?

Nicht ganz. Zunächst handelt es sich zwar um 13 Server, diese bestehen aber insgesamt aus 123 Rechnern, die zu logischen Servern zusammengeschlossen sind. Diese 123 Rechner sind weltweit verteilt und vermutlich nicht jedem Touristen frei zugänglich.

Fällt einer dieser Rechner aus, ist das Internet noch lange nicht lahm gelegt. Natürlich gab es auch schon Angriffe auf dieses System. Der erfolgreichste verhinderte zu 9 der 13 Server einen Verbindungsaufbau – zumindest einen Verbindungsaufbau in normaler Geschwindigkeit. Trotzdem funktionierte das Internet weiter, doch warum?

Zum einen wird bei Root-Servern mit Redundanz gearbeitet. Jeder der 13 Server hält alle Informationen bereit, die auf den übrigen 12 Servern verfügbar sind. Doch einer alleine käme mit der Menge der Anfragen nicht zurecht. Allerdings ist das System so aufgebaut, dass zwei Drittel der Server ausfallen könnten und die übrigen vier bis fünf Server alle Anfragen beantworten könnten.

Zum anderen wird eine DNS-Anfrage nicht direkt vom Benutzer an einen Root-Server geschickt. Vielmehr schickt ein Benutzer die Anfrage an den DNS-Server seines Providers. Dieser erkundigt sich dann, welcher DNS-Server z.B. für die Top-Level-Domain .de zuständig ist. Diese Information gibt es beim Root-Server. Nur ändert sich die Information nicht im Minutentakt. Also speichert der DNS-Server des Providers das Ergebnis dieser Anfrage in seinem Cache. Bei der nächsten Anfrage des Benutzers wird der Root-Server schon nicht mehr gefragt. So wäre selbst ein Tag ohne Root-Server noch kein völliger Untergang des Internts.

Kurze Antwort: gar nicht.

Seit ein paar Monaten bin ich stolzer Besitzer eines Servers. Auf diesem laufen verschiedene Dienste, unter anderem ein WWW, E-Mail und FTP. Eingerichtet wird alles über die Kommandozeile, eine graphische Oberfläche existiert nicht.

Wie alles begann

In den ersten Tagen stand ich einem System gegenüber, mit dem ich auf diesem Weg noch nicht gearbeitet hatte. Ein entfernter Rechner, auf dem zunächst nur eine minmale Version von Debian installiert war. Mit verschiedenen Hilfsmitteln gelang es einfach, eine Version des Betriebssystems zu installieren, die schon alles beinhaltete. Der Nachteil: Ich hatte keine Ahnung, was da alles installiert war, wie man es richtig einrichten konnte und ob ich es überhaupt brauchte.

Der Nächste Schritt war also die Neuinstallation des Systems, diesmal wieder mit einer Minimalversion von Debian. Nach und nach installierte ich die benötigten Anwendungen, bis nach einigen Tagen mein Server in der Lage war, E-Mails zu empfangen, Internetseiten darzustellen und Dateien per ftp zu übertragen. Das alles ließ sich über eine einfache Web-Oberfläche bedienen. Doch dann kam Quassel.

Sind Sie sicher, dass Sie Ihr System zerstören möchten?

Da ich an verschiedenne Orten von verschiedenen Geräten aus im Internet surfe und auch über ICQ chatte, kam ich bisher nie in den Genuss einer vollständigen Historie. Einzelne Gesprächsfetzen waren auf verschiedenen Geräten verteilt. Meldet man sich auf einem Gerät an, wird man auf dem anderen automatisch abgemeldet. Meldet man sich wieder ab, so ist man offline. Offline funktioniert der Erhalt von Nachrichten allerdings nur unzuverlässig. Also suchte ich nach einer Alternative.

Quassel ist ein IRC-Client, bestehend aus einem Server und einem Client. Der Server baut die Verbindung zum IRC-Netz auf und beliebig viele Clients können sich am Server anmelden und diese Verbindung nutzen. Mit Bitlbee wird eien Verbindung zwischen Quassel und ICQ möglich, so dass dort dasselbe Prinzip angewendet werden kann.

Es war also naheliegend, den Quassel-Server und Bitlbee auf meinem Server zu installieren. Das Problem: In den den vordefinierten Paketquellen war Quassel nicht enthalten. So suchte ich nach einer anderen Quelle, fand sie, ergänzte die Paketquellen und installierte Quassel.

Während der Installation musste ich – wie das bei Linux üblich ist – bestätigen, dass einige weitere Pakete installiert oder aktualisiert werden. “Mach du mal, du wirst schon wissen, was du tust.”

Was für mich nicht ganz klar war: Die Frage nach der Aktualisierung eines Pakets war gleichzusetzen mit der Frage “Möchten Sie dieses Paket, welches bei Ihnen schon auf dem neuesten sicheren Stand ist, durch eine Version ersetzen, die sich zurzeit in der Entwicklung befindet, wodurch Probleme auftreten könnten, zukünftige Updates immer auf dieser unsicheren Version basieren und auch andere Pakete betroffen werden können?” oder eben “Sind Sie sicher, dass Sie Ihr System zerstören möchten?”.

Wenn man keine Ahnung hat…

Jetzt weiß ich nicht, ob mir die Gelben Seiten geholfen hätten, was allerdigns geholfen hat, war jemand, der sich mit Debian auskennt.  Nach ein paar Stunden Arbeit war der Server neu aufgesetzt. Diesmal mit einem 64-Bit-System (ein weiterer Anfängerfehler…), einer vernünftigen Konfiguration – und Quassel.

Es gibt also noch viel zu lernen. Diese Erfahrung hat jedenfalls bewirkt, dass ich immer dann, wenn ich nicht weiß, was ich da eigentlich bestätigen soll, zuerst in Erfahrung bringe, welche Folgen es hat.