Résumé

  • Le RFC 9671 exige de comparer sémantiquement toutes les parties MIME qui contiennent des données de calendrier ; si elles divergent, processcalendar ne doit rien appliquer.
  • La valeur updated regroupe modification, annulation et suppression, tandis que :reason peut légitimement rester vide.
  • La preuve exploitable relie le message, les contrôles de confiance, la cible, les options Sieve et une relecture de l’événement réellement conservé.

Le corps lisible du message annonçait une réunion mardi à 10 heures. Une pièce text/calendar indiquait mardi à 11 heures. Une seconde représentation, jointe en fichier, gardait 10 heures mais remplaçait le lien de visioconférence. Chacune paraissait plausible. Ensemble, elles ne constituaient pas une invitation unique.

Dans ce cas, le meilleur résultat automatisé n’est ni l’insertion la plus vraisemblable ni la préférence pour un type MIME. Selon le RFC 9671, l’implémentation doit vérifier l’équivalence sémantique de toutes les parties calendaires. Si elles diffèrent, elle ne doit pas traiter le message. Si elles sont équivalentes, une seule représentation est appliquée.

Cette règle protège une frontière essentielle : la multiplicité de formats favorise l’interopérabilité, mais elle ne crée pas plusieurs vérités. Un système qui choisit silencieusement la version la plus facile à analyser transforme une ambiguïté d’entrée en décision durable dans l’agenda de l’utilisateur.

Le refus est parfois le résultat le plus sûr

processcalendar étend le langage Sieve afin d’ajouter, de mettre à jour, d’annuler ou de supprimer des objets calendaires transportés par courriel. Avant toute mutation, les données mal formées doivent être ignorées. Une contradiction sémantique entre plusieurs parties doit également arrêter l’action.

Il faut donc résister à un réflexe de supervision : assimiler no_action à une panne. Le résultat peut signifier qu’aucune donnée calendaire n’était présente, mais aussi qu’une option ou une règle de sécurité a empêché le traitement. Avec :updatesonly, par exemple, un nouvel UID ne doit pas être ajouté. L’absence de changement démontre alors que la limite a fonctionné.

La qualité opérationnelle ne se mesure pas au nombre d’actions exécutées. Elle se mesure à la proportion d’actions dont la prémisse, la cible et l’effet sont démontrables. Une automatisation qui sait refuser un objet ambigu protège mieux le calendrier qu’une automatisation qui « réussit » toujours.

L’adresse visée n’est pas l’identité de l’organisateur

Sans :allowpublic, le message doit être conforme à iTIP et l’une des adresses du destinataire doit correspondre à la cible définie par la méthode : ORGANIZER pour une réponse, ATTENDEE pour une demande, une annulation ou un ajout. Les adresses reconnues peuvent provenir du compte, du destinataire final de l’enveloppe ou du paramètre :addresses.

Ces éléments n’ont pas la même autorité. L’adresse visible dans le message peut différer de l’enveloppe. Un alias ajouté au script élargit la population admise. Une correspondance ATTENDEE prouve une cible syntaxique ; elle ne prouve pas que la personne souhaitait accepter la modification.

L’option :organizers renforce le contrôle en exigeant un message iTIP valide et une adresse ORGANIZER figurant dans une liste externe. Si l’option est absente, le RFC n’effectue aucune validation de cette propriété. Même lorsqu’elle est présente, la liste exprime une politique locale. Elle ne devient pas la preuve d’une intention humaine particulière.

Les signaux de confiance gardent leur objet propre

Le RFC interdit de traiter les données d’un message marqué comme indésirable ou malveillant. Il recommande de privilégier les expéditeurs connus et de ne pas agir pour un expéditeur potentiellement dangereux ou non fiable. Il cite S/MIME, SPF, DKIM et DMARC parmi les signaux possibles.

Ces mécanismes sont précieux précisément lorsqu’on ne leur demande pas davantage que ce qu’ils établissent. SPF traite l’autorisation d’un domaine pour le client SMTP observé. DKIM vérifie une signature liée à un domaine sur certaines parties du message. DMARC évalue l’alignement et une politique de réception. S/MIME fournit une signature de message sous une chaîne de certificats et des règles d’identité.

Aucun de ces faits n’affirme à lui seul : « l’organisateur humain a voulu déplacer cette réunion maintenant ». Un compte légitime peut être compromis ; un service autorisé peut reproduire une donnée ancienne ; une application interne peut générer une annulation erronée. La confiance technique est une entrée de décision, pas son substitut.

Un mot ne décrit pas trois mutations

Lorsque l’extension Variables est disponible, :outcome reçoit l’une de quatre valeurs : no_action, added, updated ou error. updated couvre explicitement un objet modifié, annulé ou retiré. Le champ :reason peut être vide si aucune raison n’est disponible.

La taxonomie est adaptée à un script qui doit choisir une branche suivante. Elle ne suffit pas à un audit, à une réconciliation ou à une enquête. Après updated, l’objet peut encore exister avec de nouvelles heures, exister avec le statut CANCELLED, ou ne plus exister. Avec :deletecancelled, la suppression est recommandée, mais le simple paramètre ne démontre pas qu’elle s’est produite.

Il faut donc conserver l’identifiant du message, le destinataire final, la génération du script, les décisions antispam et antimalware, toutes les parties calendaires et le résultat de leur comparaison. Il faut ajouter la méthode iTIP, l’UID, l’organisateur, l’ATTENDEE visé, la liste externe utilisée, les options et le calendrier résolu.

Puis vient la preuve d’exécution : relire l’UID, son calendrier, sa révision, son statut, ses participants et ses alarmes. Le RFC interdit à l’action de modifier le statut de participation du destinataire et recommande de retirer les alarmes avant application. Une relecture permet de distinguer une règle annoncée d’un état constaté.

Les pièces intégrées ajoutent une autre barrière. Elles devraient être décodées et analysées ; si l’une est malveillante, les données calendaires ne doivent pas être traitées. Il serait trompeur d’enregistrer updated avant d’avoir achevé le contrôle qui conditionne la mutation.

Enfin, processcalendar n’annule pas la conservation implicite du message Sieve. Le courriel et l’événement peuvent suivre des trajectoires différentes. La présence du mail ne prouve pas la présence de l’événement ; l’absence de l’événement ne prouve pas la suppression du mail.

Le guide de CalConnect sur les abus rappelle que les événements indésirables peuvent se placer loin dans le passé ou l’avenir, se répéter et déclencher des alertes sur plusieurs appareils. Le résultat humain dépasse donc l’instant de filtrage. Une action correcte doit pouvoir expliquer non seulement pourquoi elle a été admise, mais aussi ce qui subsiste après elle.

Le RFC 9671 n’échoue pas en refusant de tout dire dans updated. Il fixe un vocabulaire minimal commun. C’est à l’organisation de ne pas transformer ce minimum en réalité complète.

Sources