Résumé

  • Une seule liste développée peut produire plusieurs historiques différents. Le relais retire les destinataires bcc, remplace les entrées anonymisées par un URI factice accompagné d’un compte et applique bcc lorsqu’aucun copyControl n’est présent.
  • Un URI répété ne doit normalement recevoir qu’une requête ; la classe retenue suit l’ordre to, cc, bcc, tandis que bcc l’emporte sur anonymize. La normalisation décide donc aussi de ce qui sera révélé.
  • L’historique est transporté comme partie facultative et ne prouve ni existence, ni joignabilité, ni acceptation, ni participation, ni facturation. TLS ou S/MIME protège sa garde, pas sa véracité.

Une projection, pas une photocopie

Le document de départ décrit des ressources. Après développement, le service connaît les URI auxquels il pourrait adresser une requête. Mais cette connaissance interne n’autorise pas une publication identique auprès de tous.

Pour chaque sortie, le relais fabrique un historique recipient-list-history. La personne visible comme destinataire principal peut voir les autres entrées visibles. Une copie cachée doit être absente de sa vue. Le destinataire caché peut recevoir sa propre adresse dans une copie distincte afin de comprendre que répondre à tous révélerait sa présence.

Deux corps différents peuvent donc provenir du même document et de la même exécution. Pour les contrôler, il faut conserver la liste source, le résultat du développement et le corps exact remis à chaque URI. Un tableau final commun à toutes les sorties détruit précisément la preuve recherchée.

La question d’audit n’est pas seulement « combien de requêtes ont été envoyées ? ». Elle est « quelle vue chaque observateur a-t-il reçue, selon quelle règle et à partir de quelle version de la liste ? ».

L’absence de champ vaut bcc

Lorsqu’une entrée ne porte pas copyControl, la RFC 5364 lui attribue bcc. Ce choix contient le risque d’une ancienne liste, d’un producteur incomplet ou d’une migration ayant perdu un attribut. Le silence du document ne devient pas une autorisation d’exposer l’adresse.

Il faut néanmoins distinguer un bcc explicite d’un bcc obtenu par défaut. Leur projection peut être identique, mais leur diagnostic ne l’est pas. Le premier exprime une décision de l’auteur ; le second montre que le relais a appliqué une règle de sûreté à une entrée incomplète.

Le journal doit conserver les octets XML, la présence ou l’absence de l’attribut, la version du schéma, le parseur, la valeur par défaut et la classe finale. Réécrire ensuite la ligne comme si bcc avait toujours été explicite ferait disparaître l’état réel de l’entrée.

Cette règle est aussi un test de régression utile. Une bibliothèque qui change son traitement des attributs absents peut transformer silencieusement une liste privée en carnet visible.

Bcc et anonymisation ne cachent pas la même chose

Une copie cachée disparaît des historiques destinés aux autres. L’anonymisation conserve au contraire le marqueur SIP anonyme défini par la norme. L’attribut de compte peut indiquer combien d’entrées cette trace représente.

Le premier mécanisme masque l’identité et, dans la vue concernée, l’existence. Le second masque l’identité mais révèle l’existence et parfois la taille du groupe caché. Dans une négociation sensible, annoncer « cinq participants anonymes » n’est pas neutre.

Si une entrée combine bcc et anonymize, bcc l’emporte. Produire malgré tout un espace réservé anonyme divulgue une information que la copie cachée devait retirer.

Les contrôles de confidentialité doivent donc mesurer deux fuites séparées : les URI et la cardinalité. Une interface qui rassemble tous ces états sous l’étiquette « privé » ne permet pas d’établir ce qui a réellement été communiqué.

Pour chaque projection, noter les attributs sources, la règle de précédence, l’ensemble omis, l’ensemble anonymisé, le compte affiché et le hash du corps rendu.

Le doublon transporte parfois deux intentions

Un même URI peut apparaître plusieurs fois, notamment après le développement de listes imbriquées. La comparaison doit suivre les règles du schéma d’URI, pas seulement l’égalité des chaînes.

La RFC indique qu’envoyer plusieurs requêtes au même URI n’a pas d’usage raisonnable. Le service devrait n’en produire qu’une et choisir la classe la plus prioritaire : to, puis cc, puis bcc.

Cette résolution a un effet de divulgation. Garder arbitrairement la première ligne pourrait rendre aveugle un destinataire également déclaré visible ; envoyer deux fois pourrait remettre des historiques incompatibles au même terminal. Fusionner trop largement peut supprimer une destination distincte.

Il faut donc journaliser les formes originales, la méthode de comparaison, le groupe de collision, tous les attributs concurrents, la classe gagnante et l’identifiant de l’unique requête. La déduplication ne doit jamais ressembler à un simple nettoyage sans portée.

L’article consacré à la RFC 5363 traite déjà le développement et les effets multiples d’une liste. Ici, la question plus étroite est celle de la visibilité qui survit à la collision.

Répondre à tous peut dévoiler la copie cachée

La confidentialité ne s’arrête pas au relais. Un terminal qui reçoit une requête comme copie cachée peut révéler sa propre adresse en utilisant une fonction « répondre à tous ».

La RFC 5364 prévoit ce danger. Si le propre URI du destinataire est absent de l’historique ou indiqué comme aveugle, le client devrait empêcher ou limiter cette action. La vue devient alors une entrée de politique locale.

Reconnaître son propre URI n’est pas trivial : alias, renvois et identités multiples peuvent tromper le client. Un historique falsifié peut également modifier le comportement de l’interface. La présence du bouton, son état et la liste réellement produite doivent être testés ensemble.

Conserver le corps reçu, le résultat du parseur, l’identité locale retenue, la correspondance trouvée, l’état de l’action et les destinataires de la réponse. Le fait que le serveur ait correctement supprimé un bcc ne prouve pas que le terminal a préservé le secret.

Facultatif ne veut pas dire traité

Le corps d’historique devrait porter la disposition recipient-list-history avec handling=optional. Un ancien terminal peut ainsi accepter la requête SIP principale sans comprendre la partie multipart.

Il existe dès lors deux succès distincts : la requête a été acceptée, et l’historique a été consommé. Le premier n’implique pas le second. Une statistique « livré avec historique » ne prouve même pas que l’interface a affiché une seule adresse.

Le reçu complet inclut la construction MIME, la disposition, le paramètre de traitement, les capacités du terminal, le résultat du décodage et la présentation. Un abandon silencieux de la partie facultative doit être observable.

Cette compatibilité a un prix. Elle maintient le service de base, mais retire éventuellement le contexte nécessaire à la prévention de « répondre à tous ». Les usages sensibles doivent décider explicitement s’ils acceptent ce mode dégradé.

L’historique ne dit pas qui était présent

Le texte normatif refuse plusieurs inférences séduisantes. Un URI affiché ne prouve pas que l’adresse existe, qu’elle est joignable, que la requête est arrivée, qu’elle a été acceptée ou qu’une personne a participé.

Il ne constitue pas davantage une base de facturation. Une invitation ne mesure ni durée, ni capacité utilisée, ni partie responsable du paiement. Un automate peut répondre ; un humain peut rejoindre sous une autre identité ; une entrée peut rester sans réponse.

L’historique peut en outre être falsifié. La validité XML atteste une forme, pas une vérité sociale. Même signé et chiffré, un énoncé trompeur reste trompeur.

Les preuves ultérieures doivent vivre ailleurs : requête sortante, réponse du terminal, authentification d’une jonction, média observé, durée et événement comptable. Elles peuvent être corrélées au même identifiant, jamais remplacées par le contenu de la liste.

La protection du transport garde les octets

Une liste de destinataires peut révéler des relations. L’authentification, l’autorisation, TLS et S/MIME sont donc pertinents. Ils permettent de protéger un trajet ou un contenu selon leurs modèles respectifs.

Ils ne décident pourtant pas si le relais a lu la bonne liste, appliqué le bon comparateur, respecté les précédences ou produit la bonne vue. Ils ne certifient ni l’exhaustivité du document d’origine ni l’issue de la session.

Le contrôle doit séparer la garde et la sémantique. Enregistrer pair TLS, certificat ou clé, résultat de vérification et portée du chiffrement ; puis enregistrer indépendamment la transformation, le hash de projection et l’identité de son destinataire.

Présenter « TLS réussi » comme la preuve d’un historique exact prête à la couche de transport une autorité qu’elle ne possède pas.

Construire le registre de projection

Le premier reçu contient le principal qui soumet, sa politique d’autorisation et les octets immuables de la liste. Le deuxième contient le graphe de développement. Le troisième fixe la comparaison des URI et les groupes de doublons.

Le quatrième enregistre les valeurs explicites, les valeurs bcc par défaut, l’anonymisation et les précédences. Le cinquième décrit, pour chaque destinataire, les entrées visibles, omises et remplacées, puis lie le hash du corps à la requête sortante.

Les reçus suivants appartiennent au terminal et au monde réel : partie MIME reconnue, affichage, blocage de « répondre à tous », réponse SIP, participation et facturation éventuelle.

Cette chaîne permet de comprendre une différence sans la qualifier trop tôt d’incident. Elle permet aussi de prouver une fuite : si une adresse aveugle figure dans une vue qui ne lui était pas destinée, l’entrée, la règle et la sortie restent comparables.

Tester chaque observateur

Les fixtures doivent couvrir champ absent, to, cc, bcc, anonymisation simple et groupée, combinaison bcc/anonymize, doublons équivalents aux attributs contradictoires, copie propre du destinataire aveugle et ancien terminal qui ignore la partie facultative.

Pour chaque cas, vérifier le nombre de requêtes et les octets exacts de chaque historique. Tester ensuite la reconnaissance du propre URI et le comportement de réponse. Enfin, vérifier qu’aucune règle métier ne transforme l’appartenance à l’historique en présence ou en charge.

Les tests adverses doivent modifier une liste après autorisation, réordonner les doublons, retirer un attribut, falsifier un compte, rejouer une ancienne projection et supprimer la partie optionnelle.

La publication de la RFC comme Proposed Standard en octobre 2008 et l’absence de résultat affiché sur la page d’errata capturée décrivent le dossier documentaire. Elles ne démontrent aucune adoption actuelle ; toute affirmation de produit exigerait des preuves versionnées supplémentaires.