Migration

​

Les sources

​

Ce que l’import fait bien

• Les rôles de dossiers sont détectés depuis les noms. Un dossier source localisé sans métadonnée de rôle (« Brouillons », « Papierkorb », « Sent Items »…) fusionne dans le dossier système provisionné correspondant grâce à une table multilingue nom vers rôle, au lieu d’arriver comme dossier personnalisé en double à côté d’un dossier système vide. Cela vaut dans tous les modes, y compris les imports en mode JMAP.
• Les événements récurrents deviennent de vraies règles de récurrence. Les RRULE courantes des clients sont converties en RecurrenceRules JMAP typées par la même autorité de conversion que le serveur vivant. Un résidu inconvertible est conservé tel quel (et l’événement est marqué hasUnmodeledRecurrence en lecture) avec un avertissement bruyant : jamais de règle à moitié convertie, jamais de perte silencieuse. Un événement porte une seule règle : un VEVENT à deux lignes RRULE est refusé par le magasin et compté en erreur, plutôt que stocké avec sa seule première règle honorée.
• Un fichier d’agenda arrive à la bonne heure. Un DTSTART en UTC (la forme en Z) est stocké en heure locale dans Etc/UTC, un TZID dans sa zone IANA normalisée, une heure flottante ou une date inchangées, la règle de l’ingestion CalDAV ; il arrivait flottant, deux heures trop tôt à Zurich. DTEND devient la durée de l’événement, son propre TZID lu, une DATE sans fin dure un jour, et un DTEND invalide compte l’événement en erreur (durée et fin). Un fichier dont les lignes finissent en \r\r\n (un CRLF passé par un écrivain en mode texte sous Windows) ne laisse plus de retour chariot dans les titres et les UID. Google Takeout passe par la même conversion.
• Google Takeout écrit ce qu’il compte. Ses tâches vont dans la liste de tâches par défaut du compte par la même conversion et la même écriture que --from-ics (elles étaient comptées « ok » et jamais écrites ; une relance les importe), et ses événements sont rangés dans l’agenda par défaut du compte.
• Les identités d’annuaire sont frappées à neuf. Les comptes importés reçoivent des identifiants de principal nouveaux et distincts (le lien compte-principal est une colonne interne, pas une égalité d’identifiants), comme ce que fait le serveur pour les comptes créés nativement.
• Le certificat de la source est validé, et aucun réglage ne le désactive. Le client qui parle au serveur source transporte ses identifiants ; il désactivait la validation des certificats sans condition pendant qu’un réglage accept_invalid_certs posé à côté n’était lu par personne. La validation est désormais PKIX complète et le drapeau est retiré plutôt que câblé : la posture du projet est qu’une édition de production ne contient aucun contournement de certificat. La seule exception qui reste est la vérification d’après installation qui interroge la machine qu’on vient d’installer, dont le certificat est encore autosigné et où aucun secret ne circule ; ce qui compte n’est pas « client interne ou externe » mais « cette connexion transporte-t-elle un secret ».
• Une renumérotation côté source ne saute ni ne duplique. L’identité de reprise de chaque message inclut l’UIDVALIDITY que la source annonce ; une renumérotation force la ré-énumération, et la déduplication par contenu absorbe la re-présentation. Une source qui n’annonce pas de validité fait échouer l’import plutôt que de reprendre sur des clés ambiguës (RFC 3501 §6.3.1). Un UID recyclé pouvait faire sauter un message en silence, le pire des deux défauts.
• Tout atterrit par le chemin d’ingestion normal. Le courrier importé est analysé, indexé, enfilé et stocké exactement comme le courrier remis ; il n’existe pas de classe de stockage « importé » à part.

​

Idempotence et l’état d’avancement

​

Après l’import

oximail account dedupe-folders --all-accounts        # dossiers en double des imports anciens
oximail account dedupe-tasks   --all-accounts        # lignes de tâches en doublon exact des imports répétés
oximail check-dns --domain <domaine> --ip <ip>       # le DNS de courrier du domaine