Skip to main content
Au-delà du courrier, OxiMail sert les agendas, les contacts, les tâches, les fichiers et le chat en JMAP, avec des passerelles CalDAV/CardDAV pour les clients classiques (protocoles historiques). Cette page couvre les comportements qu’un exploitant doit comprendre, et les réglages et outils de réparation qui vont avec.

​
Planification de réunions (iTIP)

Quand des utilisateurs s’invitent, le serveur échange les messages de planification (REQUEST / REPLY / CANCEL) par courrier, selon la RFC 5546. Deux règles empêchent les ratés :
  • Côté organisateur seulement. OxiMail n’envoie de courrier de planification que pour les événements dont l’ORGANIZER se résout vers un compte local (RFC 5546 §3.2 : seul le serveur de l’organisateur envoie les invitations). Un événement arrivé comme invitation entrante ne réémet jamais de REQUEST quand le client du participant le réécrit, et supprimer une copie reçue ne diffuse jamais de CANCEL non autorisé : sur les chemins JMAP et CalDAV, en mode fermé.
  • Émis après le commit. Les messages iTIP ne partent qu’une fois la transaction qui a modifié l’événement réellement validée. Un conflit d’édition concurrente (stateMismatch) ou tout échec de validation n’émet rien : une invitation ne peut plus s’échapper pour un changement annulé, et un REQUEST de mise à jour porte toujours le contenu postérieur au changement, avec la SEQUENCE incrémentée.
Les invitations entrantes (parties text/calendar) sont traitées à l’ingestion, y compris le style de propriétés paramétrées d’Outlook, et mettent à jour l’agenda du destinataire.

​
Libre/occupé et disponibilité

Trois surfaces de lecture répondent à « quand cette personne est-elle libre », toutes à travers une seule autorité d’énumération des occurrences (un événement récurrent se développe partout à l’identique, changement d’heure compris) :
  • Principal/getAvailability (JMAP) compose la disponibilité depuis les agendas auxquels le sujet est abonné et dont includeInAvailability vaut all ou attending ; un événement privacy: "secret" cache entièrement son temps occupé ; les détails d’un événement ne sont fournis qu’aux appelants qui détiennent un vrai droit de lecture : l’accès au libre/occupé n’implique jamais l’accès aux détails. Un appelant sans droit de libre/occupé sur aucun agenda du sujet reçoit un forbidden explicite, pas une disponibilité vide et trompeuse.
  • La free-busy-query CalDAV renvoie un VFREEBUSY de périodes occupées fusionnées (le provisoire compte comme occupé ; les événements libres/transparents, à la corbeille ou annulés sont exclus).
  • L’interface de planification d’un client s’appuie sur les mêmes données.

​
Fuseaux horaires

Les événements flottants (sans fuseau explicite) se résolvent par une chaîne de repli : fuseau de l’événement → fuseau de l’utilisateur → défaut de l’organisation → UTC. L’assistant capture le défaut de l’organisation à l’installation (premier démarrage) ; modifiez-le ensuite avec :
Les noms de fuseaux du registre Windows (venant d’Outlook, Exchange, eM Client) sont normalisés vers IANA sur chaque chemin d’ingestion, et les VEVENT exportés embarquent le VTIMEZONE correspondant pour que les clients stricts calculent des heures locales correctes.

​
Notifications

Les changements d’agenda produisent des objets CalendarEventNotification pour les personnes concernées : l’écriture d’un bénéficiaire sur un agenda partagé notifie le propriétaire, et un message de planification entrant notifie l’utilisateur concerné (REQUEST/CANCEL vers le destinataire, REPLY vers l’organisateur ; les changements de son propre fait sont tus). Les notifications sont inscrites au journal de changements et poussées : les clients les voient sans interroger. Les alertes (rappels) acceptent des déclencheurs relatifs et absolus, et sonnent une fois par occurrence grâce à une table de déduplication.

​
Tâches

Les listes de tâches suivent le modèle des agendas : méthodes JMAP, passerelle CalDAV VTODO, listes partagées. Chaque compte a exactement une liste de tâches par défaut, garantie par un invariant en base : un Task/set create sans taskListIds y atterrit. Les alertes de tâches acceptent un déclencheur absolu sans exiger d’échéance.

​
Contacts

Les contacts sont des ContactCards JMAP (RFC 9610) avec une passerelle CardDAV. Le serveur possède l’uid (un uid fourni par le client à la création est rejeté), et un PUT CardDAV qui créerait un doublon inter-sources d’un UID existant est refusé plutôt que dupliqué en silence. Les composantes de nom et d’adresse font l’aller-retour complet entre vCard et la forme JMAP.

​
Partage

Agendas, listes de tâches, carnets d’adresses et dossiers du drive partagent un seul modèle de droits (cartes shareWith indexées par principal, formes RFC 9670). Deux garanties utiles à l’exploitant :
  • L’état par lecteur reste par lecteur. Un bénéficiaire qui masque un agenda partagé (isVisible) ou met en favori un fichier partagé n’affecte que sa propre vue, jamais l’objet du propriétaire.
  • Les bénéficiaires doivent être adossés à un humain. Un droit accordé à une identité technique non connectable est rejeté à l’écriture sur tous les domaines : un droit qui ne pourrait jamais s’exercer est un mensonge dans l’ACL. La garde du drive des comptes partagés a sa propre surface : oximail account custodian (voir multi-tenant).

​
Réparations en un coup

Les artefacts d’époque migration ont des commandes de réparation dédiées, en simulation par défaut : Les deux enregistrent des changements JMAP pour que les clients se resynchronisent proprement. Voir la référence CLI.