Peut-être pensez-vous à première vue “Quelle est donc cette question ? Ce qu’est un e‑mail est pourtant tout à fait clair !”. Ce qui, du point de vue typique d’un utilisateur, semble d’abord certainement simple, correct et compréhensible à répondre, peut toutefois, sous des aspects plutôt techniques (et aussi de conformité), devenir une question délicate. Surtout lorsqu’il s’agit de l’archivage des e‑mails et de la question de l’original d’un e‑mail. L’administration fiscale examine l’archivage des e‑mails du contribuable, entre autres, sur la base des critères de conformité de la GoBD, selon lesquels la restauration de l’original de chaque e‑mail archivé doit être possible.

Bien entendu, Benno MailArchiv dispose depuis le tout premier instant de la possibilité d'afficher chaque mail archivé dans son original. Ainsi, le courriel archivé au format natif RFC 822 est récupéré depuis l'archive, décompressé et présenté comme “code source”. Ce n’est ni quelque chose de spécial, ni une explication à notre question initiale. En fin de compte, ce qui est archivé, c’est ce qui provient du serveur de messagerie ou de la boîte aux lettres de l'utilisateur et qui doit être archivé.

Originaux et exemplaires de courrier

Que se passe‑t‑il s’il existe, au lieu d’un seul original pertinent d’un courriel, éventuellement deux, trois ou même davantage d’exemplaires ? Nous parlons toutefois expressément pas de simples duplicatas, par exemple des courriels récupérés plusieurs fois d’une boîte aux lettres ou similaire. Les duplicatas de courriels (ou doubles) à identifier constituent l’une des tâches fondamentales d’une solution d’archivage de courriels. Benno MailArchiv maîtrise cela aussi longtemps que l’affichage des courriels dans leur original.

“Plusieurs originaux pertinents d’un même e‑mail ? Impossible !” dites‑vous ? Pas dans des environnements complexes, comme ceux qui apparaissent parfois dans la pratique chez les grands hébergeurs et fournisseurs de services cloud (CSPs). Ici, les e‑mails arrivent, en partie à cause de circonstances liées à l’infrastructure, plusieurs fois dans le “entonnoir de traitement” de Benno MailArchiv.

Les faits décrits ci-dessous sont relativement simples à comprendre d'un point de vue technique. Mais l'archivage des courriels conforme à la législation est bien plus que la simple représentation ou mise en œuvre technique des exigences (GoBD et de conformité). C'est une solution informatique dans le champ des préoccupations des utilisateurs, des exigences légales ainsi que, le cas échéant, des exigences générales de conformité.

Nous vous invitons par la présente à discuter avec nous de ce qu’est un e‑mail (ou peut‑être pas). Il se peut que votre perception d’un si trivial “Ding” comme les e‑mails change après avoir lu cet article. Envoyez‑nous un e‑mail ou utilisez la fonction de commentaire à la fin de cet article pour nous faire part de votre avis.

Archiver les e-mails est, d'un point de vue technique, une tâche relativement simple en général. Il existe (en gros) des boîtes aux lettres utilisateur, des serveurs de messagerie et des voies de transport. L'ensemble est équipé d'interfaces correspondantes. Les conditions locales respectives offrent souvent plusieurs possibilités d'archiver les e-mails (de manière appropriée aux exigences pertinentes).

Archivage des e-mails sur site ou dans ses propres locaux

Une archive de messagerie configurée dans un fonctionnement sur site est souvent caractérisée par le fait que tous les courriels à archiver sont toujours et sans exception archivés de la même manière ou par le même mécanisme choisi. Bien que la livraison des courriels à l'archive puisse être individuelle en fonction du client et de son environnement informatique, on constate que le chemin de tous les courriels dans les installations sur site (une fois qu'il est défini et configuré) est de facto toujours le même. Une fois que la connexion à l'archive de messagerie est terminée, tout le reste se déroule quasiment automatiquement. Tous les courriels à archiver prennent toujours le même chemin. One size fits all.

L'avantage de cette situation est l'uniformité. L'acheminement des courriels vers les archives se fait selon un schéma bien défini. Il n'y a généralement pas d'exceptions à cela. Les courriels en double sont ainsi largement exclus. Le reste, c'est-à-dire le tri des doublons réels, est pris en charge par la détection des doublons de Benno MailArchiv au moment de l'archivage.

Archivage de messagerie dans le cloud

Un tout autre tableau se présente fréquemment dans les environnements vastes et complexes. Par exemple, en particulier dans les infrastructures des grands fournisseurs d'hébergement et de cloud. En raison d'une multitude de circonstances possibles (différents chemins de transport de courriels, différents serveurs de transport de courriels (MTA) et différentes stratégies d'acheminement vers les archives (actif par SMTP ou passif par IMAP ou POP3, etc.)), il arrive ici que le même courriel soit transporté plusieurs fois vers les archives par différents chemins et qu'il soit ainsi plusieurs fois en attente d'archivage.

En particulier, différents chemins de transport de courrier et MTAs ont pour effet que les courriels transportés sont dotés d'en-têtes de transport spécifiques au chemin parcouru. Lorsqu'un courriel concret parvient plusieurs fois aux archives via différents chemins et est doté à chaque fois d'en-têtes différents (ce qui est inévitable avec différents MTAs), il est considéré comme des courriels différents aux fins de la détection des doublons.

Examinons cela de plus près à l'aide d'un exemple :

Dans une infrastructure complexe, un e-mail concret «M» est transmis à Benno MailArchiv pour archivage via trois chemins différents. Lors du transport de chacun des trois exemplaires de cet e-mail (M1, M2, M3) via des chemins différents, des en-têtes différents sont saisis pour chaque exemplaire de l'e-mail. Les exemplaires de l'e-mail sont identiques sur le plan du contenu, c'est-à-dire du point de vue de l'utilisateur, qu'il s'agisse du message ou du texte. Néanmoins, ils diffèrent les uns des autres de manière formelle et technique en raison des différents en-têtes.

Les en-têtes font la différence

Du point de vue de la détection des doublons ou des duplicatas de Benno MailArchiv, il s'agit sans aucun doute de trois e-mails différents M1, M2 et M3. Lors de l'archivage, une somme de contrôle SHA256 est générée pour chaque e-mail livré. En raison des en-têtes différents (des exemplaires de mail par ailleurs identiques), il en résulte inévitablement trois sommes de contrôle différentes «C1», «C2» et «C3» pour les différents exemplaires. Ainsi, les trois exemplaires du même courrier électronique sont considérés comme des e-mails différents du point de vue de Benno MailArchiv. Ils seraient ainsi archivés individuellement comme tels. Cela aurait pour conséquence que, du point de vue de l'utilisateur (c'est-à-dire en se référant au contenu purement informatif de l'e-mail), il apparaîtrait que trois e-mails identiques sont contenus dans l'archive. Lors d'une recherche sur le contenu du message, les trois exemplaires de l'e-mail seraient en effet trouvés et affichés.

Dans un tel environnement, la détection de doublons classique n'est pas pertinente. Qui veut trouver plusieurs e-mails identiques (selon le contenu du message) lors d'une recherche ? Et comment faire en sorte qu'un seul des trois exemplaires de l'e-mail soit archivé ?

La complexité nécessite des solutions simples

On sait que la complexité est mieux compensée par une simplicité interne et des solutions simples que par des constructions de solutions complexes.

Si nous allons plus loin au fond des choses, nous constatons qu'un e-mail est déjà clairement identifiable par les en-têtes ci-dessous et en outre par son texte de message :

  • Envelope-From – X-REAL-MAILFROM
  • Envelope-To – X-REAL-RCPTTO
  • Return-Path
  • Objet
  • Message-Id
  • Date
  • De
  • À
  • Cc
  • Corps

Naturellement, en particulier lors du transport par SMTP, d'autres en-têtes spécifiques (soi-disant Received-Header) apparaissent dans l'e-mail. Le contenu de ces Received-Header dépend du chemin de transport réel de l'e-mail respective. Cela signifie que si deux e-mails M1 et M2 sont identiques en ce qui concerne les en-têtes susmentionnés (non spécifiques au transport), il s'agit définitivement du même e-mail — indépendamment des en-têtes conditionnels au transport qui sont encore contenus dans l'e-mail.

Conclusion : Le chemin de transport provoque éventuellement des en-têtes supplémentaires. De ce fait, un e-mail devient un e-mail avec plusieurs exemplaires non identiques. Les en-têtes conditionnels au transport ne sont pas pertinents pour la clarté de l'e-mail ou pour son contenu (leur présence documente uniquement le chemin de transport parcouru).

De plus, non seulement les en-têtes Received, mais également les signatures DKIM (et d'autres éléments) n'ont pas de rapport direct avec le contenu de l'e-mail. On peut attribuer ces en-têtes à l'enveloppe d'un e-mail.

Ainsi, la solution pour la situation avec plusieurs exemplaires de mail, qui sont techniquement différents mais identiques sur le plan du contenu, est évidente : alors que pour des raisons de conformité, la somme de contrôle sur l'e-mail entier est obligatoire, une seconde somme de contrôle, basée uniquement sur les parties de l'e-mail mentionnées ci-dessus, résout le dilemme de manière tout aussi simple et efficace.

Pratique versus critères formels et conformité

Certains thèmes peuvent être résolus de manière élégante par des moyens techniques. Cependant, certaines solutions pratiques échouent dans la vie quotidienne en raison de simples aspects formels. Il est donc approprié de regarder de plus près ici, car la conformité l'emporte malheureusement sur la praticabilité en matière d'archivage de messagerie :

La conservation des e‑mails conforme à la GoBD nécessite la possibilité de pouvoir restaurer chaque e‑mail dans son état original depuis l’archive. Chaque e‑mail doit donc incl. tous les en‑têtes, pièces jointes, etc., donc quasi dans le “texte source du message” affiché. De plus, chaque e‑mail doit être vérifiable quant à d’éventuelles manipulations. Concrètement, à l’aide de la somme de contrôle mentionnée ci‑dessus sur l’ensemble de l’e‑mail, on peut vérifier la cohérence ainsi que l’intégrité d’un e‑mail archivé ainsi que du contenu complet de l’archive.

Revenons à notre exemple : si plusieurs courriels M1, M2 et M3 identiques sur le plan textuel ou contenu (dans le sens mentionné ci-dessus d'exemplaires différents du même courriel) sont soumis à l'archivage, la question se pose de savoir comment procéder avec les exemplaires de courriels qui diffèrent par leurs en-têtes.

Une perspective sur les aspects juridiques de cette situation

Nous partons du principe que, d'un point de vue purement juridique, il n'y a aucune obligation d'archiver plusieurs variantes d'un courriel, en particulier si elles ne diffèrent que par les en-têtes de courriel qu'elles contiennent. Cependant, comme on ne peut exclure que différents milieux défendent des interprétations juridiques différentes, il est possible que notre hypothèse ne soit pas unanimement acceptée ou qu'elle soit même juridiquement incorrecte.

Pour exclure un dilemme (juridique) potentiel, il convient donc, d'un point de vue pragmatique, d'archiver tous les exemplaires du courriel concerné (dans notre exemple M1, M2, M3).

Si l'on considère la situation de manière purement formelle, il s'agit de plusieurs exemplaires de courrier électronique au sens de notre exemple en tant que différents courriels. Même si les différences entre eux sont de nature technique et que la valeur pratique des différences entre eux dans la vie quotidienne n'est pas ou guère présente, il s'agit formellement de différents courriels. Cela peut être immédiatement vérifié à l'aide des différentes sommes de contrôle.

Toute incertitude juridique peut être exclue simplement en archivant tous les exemplaires de courrier électronique. Même s'il était facile à réaliser techniquement en utilisant la méthode décrite ci-dessus avec deux sommes de contrôle différentes par courriel, par exemple, en n'archivant que le premier exemplaire d'une série d'exemplaires de courrier électronique

Pour parvenir à une solution juridiquement sûre pour l'exploitant, nous conseillons de discuter de ce fait avec un conseiller juridique de votre choix avant la mise en œuvre. Ce n'est qu'après avoir discuté et décidé de la forme concrète de la mise en œuvre de la détection des doublons que la mise en œuvre devrait être effectuée en conséquence.

En attendant, nous supposons que cela pourrait être juridiquement suffisant pourrait, appliquer la détection simplifiée des doublons ou des duplicatas, en n'archivant qu'un seul des multiples exemplaires d'e-mails arrivant. En raison des exigences du GoBD, l'élaboration d'une documentation de procédure est hors de tout doute et est obligatoire. Nous partons du principe que la déclaration ou la consignation du fait qu'un seul exemplaire d'e-mail soit archivé, dans la documentation de procédure, serait suffisante devrait, afin d'obtenir une archivage juridiquement sécurisée.

La décision über la méthode de détection des doublons appliquée et, par conséquent, la responsabilité contreüber l'administration fiscale incombe uniquement le propriétaire.

Qu'est-ce qu'un courriel ?

Un courriel est-il désormais chaque exemplaire, même si deux exemplaires ne diffèrent que par un seul en-tête de transport qui ne contribue pas à augmenter la valeur informative du message ? Un courriel doit-il donc être classé uniquement selon des critères formels ? Ou un courriel est-il un message entre deux ou plusieurs utilisateurs, dont la partie essentielle (et également pertinente pour l'archivage conforme aux GoBD) est le message lui-même ? Les en-têtes de courrier (qui restent généralement cachés pour l'utilisateur) sont-ils également pertinents pour les GoBD ou ne sont-ils pas si importants (même s'ils sont archivés en tant que partie du courrier original) ?

Ce qu'est exactement un e-mail reste probablement encore ouvert un certain temps dans ce sens.

Maintenant, vous avez la parole, cher lecteur ! Écrivez-nous un e-mail ou un commentaire sur votre compréhension de la nature et de l'étendue d'un e-mail.

Avis juridique / Clause de non-responsabilité / Avertissement

Cet article ne constitue pas une consultation juridique. Il sert uniquement à des fins d'information générale. Nous n'assumons aucune responsabilité quant à l'exactitude ou l'exhaustivité des informations. Toute responsabilité est exclue.