Zusammenfassung

  • Die Fassung 03 des Mailmaint-Entwurfs vom 28. Oktober legt POSIX pax als Container fest. Ein logischer Export darf aus mehreren einzeln lesbaren Archiven bestehen; auch ein großer Ordner darf aufgeteilt werden.
  • Der Importeur muss Ordnerstücke anhand derselben UID und konsistenter Metadaten zusammenführen. Unsichere Pfade und besondere Archiveinträge sind zurückzuweisen. Dateibesitzer, Modusbits, erweiterte Attribute und ACLs aus dem Archiv dürfen nicht auf die Zieldateien übertragen werden.

Der Bruch geschieht nach dem Herunterladen

Eine große Mailbox wird auf zwei Pakete verteilt. Beide enthalten einen Ordner namens „Eingang“. Ein Empfänger, der nur die sichtbaren Namen verarbeitet, kann zwei Eingänge anlegen. Ein anderer übersieht das zweite Paket und meldet trotzdem einen abgeschlossenen Import. In beiden Fällen hat der Nutzer die Dateien in der Hand. Was fehlt, ist die einheitliche Mailbox, auf die Suchfunktion, Ordnerstruktur und spätere Synchronisation angewiesen sind.

Der Entwurf behandelt den gemeinsamen uid als Identitätsanker. Jedes Archiv muss unabhängig lesbar sein und eine eigene archive.json tragen; part zählt die Teile, final markiert den Abschluss. Taucht derselbe Ordner in mehreren Teilen auf, enthält jede folder.json nur die jeweiligen Elemente. Die übrigen Metadaten müssen übereinstimmen; die Liste entfernter Elemente wird in jeder Kopie wiederholt. Der Importeur muss die Teile zu einem Ordner verschmelzen. Wer den sichtbaren Namen für ausreichend hält, nimmt den eigentlichen Portabilitätstest nicht ab.

Neu ist auch die Wahl des Containers. POSIX pax erweitert tar um internationalisierte Pfadnamen und zusätzliche Größenangaben. Exportiert werden dürfen nur normale Dateien und Verzeichnisse, keine symbolischen oder harten Links und keine Gerätedateien. Pfade müssen relativ und gültiges UTF-8 sein, ohne .- oder ..-Segmente. Selbst dann können zwei im Archiv unterschiedliche Namen auf dem Zielrechner zusammenfallen, etwa wegen ignorierter Großschreibung oder Unicode-Normalisierung. Der Exporteur soll solche Kollisionen vermeiden; der Importeur soll Dubletten zurückweisen, statt eine Datei stillschweigend zu verlieren.

Diese Regeln klingen nach Archivtechnik, treffen aber die Verfügungsmacht über ein Konto. Der Absender organisiert das Paket. Der Empfänger entscheidet, ob die neue Umgebung die Identitäten unverfälscht wiederherstellt. Ohne diese Entscheidung ist der Export ein Haufen korrekter Bytes mit falscher sozialer Bedeutung.

Ein Kalendereintrag ist keine Zugangsberechtigung

Der Entwurf unterscheidet Daten über Rollen von gültigen Rechten. Ein Termin kann Teilnehmer nennen, ein Objekt ein shareWith-Feld enthalten. Die Zugriffskontrollen der Quelle reisen aber möglicherweise nicht zuverlässig mit. Hochgeladene Rollen können verändert worden sein. Der neue Dienst muss deshalb selbst prüfen, welchen Konten er welche Rechte gibt. Ein ausgelesener Teilnehmername ist kein Befehl, die importierte Kalenderdatei zu öffnen.

Auf Dateisystemebene ist die Anweisung zwingend. Vor dem Schreiben muss der Importeur absolute Pfade, Rücksprünge über .. und Eintragstypen außerhalb regulärer Dateien und Verzeichnisse ablehnen. Er darf Modusbits, Eigentümer, erweiterte Attribute und ACLs des Archivs nicht übernehmen. Die Dateien entstehen mit den Voreinstellungen des Zielsystems. Das verhindert, dass ein manipulierter Export Rechte auf einer fremden Maschine verteilt. Zugleich macht es klar, dass der Wechsel eines Dienstes keine automatische Übernahme seiner alten Berechtigungspolitik ist.

Bei Kontakten, Aufgaben und Kalenderobjekten verlangt der Entwurf uid und updated. Findet der Importeur eine bestehende UID mit hinreichend ähnlichem Inhalt, soll er nicht allein durch erneutes Einlesen den Zeitstempel ändern. Sonst erzeugt jede Migration künstliche Änderungen und womöglich doppelte Kontakte. Was „hinreichend ähnlich“ bedeutet, bleibt eine Entscheidung der jeweiligen Implementierung. Das Format ermöglicht eine Synchronisation in eine Richtung; es beseitigt nicht jeden Konflikt zweier lebender Konten.

Unkomprimierte Archive und gzip müssen angenommen werden, Zstandard sollte ebenfalls unterstützt werden. Ein kompaktes Downloadpaket kann beim Entpacken enorme Mengen an Dateien und Daten freisetzen. Der Entwurf nennt deshalb entpackte Gesamtgröße, Zahl der Einträge und Einzelgrößen als Grenzen, auf die Importeure achten sollen. Im Export liegen zudem Daten über Korrespondenzpartner und eingeladene Personen, die selbst keine Ausfuhr verlangt haben. Ein leicht tragbarer Datenbestand ist auch ein leicht gebündelter Privatbestand.

Die Vorversion 02 enthielt diese festgelegten pax- und Aufteilungsregeln noch nicht. Laut Datatracker ist Fassung 03 ein Internet-Draft der Arbeitsgruppe, kein veröffentlichter RFC und kein Nachweis einer funktionierenden Dienstmigration. Verfahren zum Anfordern und Übertragen des Archivs liegen außerhalb dieses Dokuments.

Quellen