Das Symptom
Das neue Handy ist eingerichtet, die Mails laufen seit einer Stunde einwandfrei ein.
Nur der Kalender ist leer. Das Adressbuch enthält vier Einträge, die aus der
SIM-Karte stammen, und sonst nichts. Termine, die man am Rechner anlegt, erscheinen
nirgendwo sonst; Termine, die man unterwegs einträgt, sind nach dem nächsten
Gerätewechsel verschwunden.
Besonders verwirrend: Beim Einrichten wurde eine E-Mail-Adresse und ein Passwort
abgefragt, und beides hat funktioniert — die Mail beweist es ja. Trotzdem behauptet
das Gerät hartnäckig, es gebe keine Termine.
Die „Layer 8“-Wahrheit
Der Irrtum steckt schon im Wort Konto. Was man einrichtet, fühlt sich an wie ein
Zugang zu allem, was zu dieser Adresse gehört. Tatsächlich ist es ein Zugang zu
genau einem Dienst, und dieser Dienst kann ausschließlich Nachrichten. IMAP
transportiert Mail. Kein Termin, kein Kontakt, keine Aufgabe. Im gesamten Standard
kommen diese Wörter nicht vor, und zwar aus dem einfachen Grund, dass sie dort nicht
hingehören.
Für Kalender und Adressbücher gibt es zwei eigene Protokolle, und beide stammen aus
einer ganz anderen Ecke des Netzes: Sie sind Erweiterungen von WebDAV und damit von
HTTP. CalDAV, standardisiert 2007, überträgt Termine im iCalendar-Format. CardDAV,
standardisiert 2011, überträgt Visitenkarten im vCard-Format. Beide sprechen also
über denselben Kanal wie eine Webseite, nur mit zusätzlichen Methoden wie PROPFIND
und REPORT. Mit dem Mailserver haben sie technisch nichts gemein, auch wenn beim
selben Anbieter dieselben Zugangsdaten gelten.
Daraus folgt die unbequeme Konsequenz, an der die meisten scheitern: Man richtet
nicht ein Konto ein, sondern drei. Auf Apple-Geräten stehen die entsprechenden
Punkte hinter dem unscheinbaren Menüpunkt „Andere“, und wer dort nicht hinsieht,
findet sie nie. Android bringt von Haus aus gar keine Unterstützung dafür mit —
was regelmäßig für einen Defekt gehalten wird und keiner ist, sondern eine
Produktentscheidung.
Immerhin muss man die Serveradressen selten selbst wissen. Der Standard sieht eine
Selbstfindung vor: SRV-Einträge im DNS nennen Rechnername und Port, und unterhalb
von /.well-known/ liegt eine Adresse, die ausdrücklich nur ein Platzhalter ist und
auf den echten Pfad weiterleitet. Ein Gerät, das diese Suche beherrscht, braucht die
Domain und sonst nichts. Ein Anbieter, der beides nicht eingerichtet hat, zwingt
seine Kundschaft dagegen dazu, Pfade aus einer Hilfeseite abzutippen — was der
Standard seit 2013 ausdrücklich vermeiden wollte.
Und wenn alles verbunden ist, wartet noch die letzte Falle: der Standardkalender.
Neue Termine wandern ohne Rückfrage dorthin, und wenn das ein rein lokaler Kalender
auf dem Gerät ist, werden sie nie abgeglichen. Sie sind dann nicht verloren, sondern
Gäste in einem Ordner, den nie jemand sichert — bis zum Gerätewechsel, an dem sie
mit dem Gerät verschwinden. Ein einziger Testtermin nach dem Einrichten hätte das
verraten.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Den Dienst im DNS suchen, bevor man rät
Der Standardweg zur Serveradresse führt über SRV-Einträge. Die Befehle fragen für eine Domain nach dem verschlüsselten Kalender- und Adressbuchdienst. Die Antwort besteht aus vier Werten: Priorität, Gewicht, Portnummer und Rechnername. Als Gegenprobe, dass die Befehle stimmen, liefert das Beispiel mit icloud.com eine echte Antwort — dort steht für den Kalender 0 0 443 caldav.icloud.com. und für die Kontakte 0 0 443 contacts.icloud.com. Kommt für die eigene Domain nichts zurück, ist das kein Fehler des Befehls, sondern eine Auskunft: Der Anbieter hat die Selbstfindung nicht eingerichtet.
dig +short SRV _caldavs._tcp.icloud.com
dig +short SRV _carddavs._tcp.icloud.com
dig +short SRV _caldavs._tcp.example.com
2.Den Server fragen, ob er Kalender überhaupt spricht
Das ist die wichtigste Prüfung der ganzen Seite, und sie dauert eine Sekunde. Der Befehl schickt eine OPTIONS-Anfrage und zeigt nur die Antwortkopfzeilen. Gesucht ist die Zeile, die mit DAV: beginnt. Enthält sie calendar-access, unterstützt der Server CalDAV; enthält sie addressbook, unterstützt er CardDAV. Beim Beispiel iCloud steht dort tatsächlich DAV: 1, access-control, calendar-access und danach noch ein Dutzend weiterer Erweiterungen. Fehlt die Kopfzeile ganz, ist die Adresse falsch oder der Dienst nicht vorhanden.
curl -sS -X OPTIONS -o /dev/null -D - https://caldav.icloud.com/
curl -sS -X OPTIONS -o /dev/null -D - https://example.com/
3.Den tatsächlichen Einstiegspunkt über die bekannte Adresse ermitteln
Nach RFC 6764 ist die Adresse unter /.well-known/ nur ein Platzhalter, der auf den echten Pfad weiterleitet. Der Befehl folgt dieser Weiterleitung und gibt am Ende die Adresse aus, bei der man herauskommt — genau die gehört ins Gerät, wenn die automatische Suche versagt. Der Server darf laut RFC für diese Anfrage eine Anmeldung verlangen und zunächst mit dem Status 401 antworten; deshalb sind die Zugangsdaten mitzugeben. Wer sein Passwort nicht in der Befehlszeile stehen haben will, lässt den Doppelpunkt samt Passwort weg — curl fragt dann nach.
curl -sS -L -u benutzer@example.com -o /dev/null -w '%{url_effective}\n' https://example.com/.well-known/caldav
curl -sS -L -u benutzer@example.com -o /dev/null -w '%{url_effective}\n' https://example.com/.well-known/carddav
4.Das eigene Benutzerverzeichnis auf dem Server abfragen
Der nächste Schritt der im Standard beschriebenen Selbstfindung ist eine PROPFIND-Anfrage auf die Eigenschaft DAV:current-user-principal. Sie beantwortet die Frage, welchem Konto der Server die Anmeldung zuordnet — und liefert den Pfad, unter dem die Kalender dieses Kontos hängen. Der Befehl schickt genau diese Anfrage. In der Antwort steht ein href-Element mit dem Pfad; stimmt der nicht mit dem erwarteten Benutzernamen überein, meldet man sich gerade als jemand anderes an. Als Zieladresse den Pfad einsetzen, den der vorige Schritt ausgegeben hat.
curl -sS -u benutzer@example.com -X PROPFIND -H 'Depth: 0' -H 'Content-Type: application/xml; charset=utf-8' --data-binary '<D:propfind xmlns:D="DAV:"><D:prop><D:current-user-principal/></D:prop></D:propfind>' https://example.com/caldav/
5.Die Kalenderliste des Kontos abrufen
RFC 4791 definiert in Abschnitt 6.2.1 die Eigenschaft CALDAV:calendar-home-set. Sie benennt laut Standard die Adresse aller WebDAV-Sammlungen, die Kalendersammlungen der zugehörigen Benutzerkennung enthalten. Der Befehl fragt sie ab; als Zieladresse dient der Pfad aus dem vorigen Schritt. Für Adressbücher heißt die entsprechende Eigenschaft CARDDAV:addressbook-home-set und liegt im Namensraum urn:ietf:params:xml:ns:carddav. Kommt hier eine Liste zurück, ist der Server sauber erreichbar, und jeder weitere Fehler liegt in den Geräteeinstellungen.
curl -sS -u benutzer@example.com -X PROPFIND -H 'Depth: 0' -H 'Content-Type: application/xml; charset=utf-8' --data-binary '<D:propfind xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><C:calendar-home-set/></D:prop></D:propfind>' https://example.com/principals/benutzer/
6.Im Gerät die richtige Kontoart anlegen — nicht die naheliegende
Hier scheitern die meisten. Auf dem iPhone und dem Mac steht die Auswahl unter Accounts hinter dem Punkt Andere: dort gibt es getrennte Einträge für einen CalDAV-Account und einen CardDAV-Account, und beide muss man einzeln anlegen. Unter Android bringt das System selbst weder CalDAV noch CardDAV mit; dort braucht es eine App, die den Abgleich übernimmt und die Konten in der Kontenverwaltung anmeldet. Unter Thunderbird führt der Weg über Neuer Kalender, dann Im Netzwerk, dann CalDAV — und für Kontakte über ein CardDAV-Adressbuch. In allen Fällen gilt: Das bestehende Mailkonto zu bearbeiten hilft nicht, weil dort kein Feld für diese Protokolle existiert.
7.Nach dem Einrichten kontrollieren, in welchen Kalender geschrieben wird
Sind mehrere Kalender eingerichtet, hat jedes Gerät einen Standardkalender, in den neue Termine ohne Rückfrage wandern. Die klassische Falle: Der Termin landet im lokalen Kalender des Geräts statt im Kalender auf dem Server, wird also nie abgeglichen und ist beim Gerätewechsel weg. Nach der Einrichtung einmal einen Testtermin anlegen, dreißig Sekunden warten und auf dem zweiten Gerät nachsehen. Erscheint er nicht, im ersten Gerät den Standardkalender umstellen — und den lokalen Kalender, falls er nicht gebraucht wird, ganz abschalten. Dasselbe gilt für Kontakte und den Standardspeicherort neuer Einträge.