Notre redirecteur se comporte, en réception, comme un sas entre des BAL publiques et des BAL privées. Si vous souhaitez rendre anonyme une ou plusieurs adresses courriel, faites en des BAL "cibles" et n'émettez jamais de courriels avec ces adresses.
Voici ci-après le synoptique fonctionnel de notre redirecteur :
| Bloc | Rôle |
|---|---|
| Lecteur |
Le rôle du lecteur est d'interroger à intervalle fixe les BAL source pour récupérer les courriels non encore traités. Le courriel est reçu sous la forme d'un flux EML (format brut conforme aux RFC). Le lecteur ne s'interresse pas au statut lu ou non lu des messages. Pour chaque message lu, il calcule son CRC et ne traite que les messages ayant un CRC inconnu. Pour cela, le système conserve les CRC de tous les messages lus sur une période de temps donné (l'année par défaut). Si la configuration le permet, chaque courriel lu (avec ou sans CRC redondant) est supprimé de la BAL source. L'intérêt de la suppression automatique est double :
La suppression automatique ne doit pas être utilisée sur une BAL source si cette BAL est à la fois redirigée et lue directement par un client de messagerie. Dans ce cas, l'utilisateur devra faire le nettoyage lui-même de cette BAL. C'est pour cela que la configuration permet une suppression automatique ou non pour chaque BAL source. Le flux EML et son CRC de chaque message lu sont envoyés vers l'analyseur et vers l'archiveur. Ce dernier ouvre une transaction pour stocker le flux EML mais ne la ferme pas. |
| Archiveur |
L'archiveur reçoit un flux EML accompagné de son CRC de deux origines différentes :
La réception d'un flux ouvre une transaction qui sera fermée sur une commande de validation (conservation du flux et de son CRC) ou d'invalidation (effacment du flux et de son CRC). Cette commande peut être émise par le système de filtrage, le re-directeur ou le composeur. A la commande est toujours associée une raison. Le système de filtrage ne peut qu'envoyer une commande de validation. Voir la spécification de ce bloc pour les raisons possibles. Le re-directeur ne peut qu'envoyer une commande de validation. Voir la spécification de ce bloc pour les raisons possibles. Le composeur ne peut qu'envoyer une commande de validation. Toutefois, avant d'envoyer cette commande, il adresse à l'archiveur le flux EML du message recomposé. Ce flux fait partiue intégrante de la transaction qu'il peut alors valider. Voir la spécification de ce bloc pour les raisons possibles. |
| Analyseur |
L'analyseur récupère le CRC et le message au format EML transmis par le lecteur. Il décompose le flux EML en un courriel structuré (cf. schéma ci-dessous). Il transmet le courriel structuré au 1er filtre du système de filtrage. Si l'analyseur échoue dans sa tentrative de décomposition, il demande à l'archiveur de stocker le message avec la mention "non analysé : échec de la décomposition, {cause de l'échec}". Le message n'est pas non plus transmis au système de filtrage. Le schéma "pratique" de la structure d'un courriel est illustré ci-dessous. Il s'agit d'une version simplifiée correspondante à la pratique actuelle. En effet, les spécifications d'un courriel (RFC) en font une structure arborescente lorsqu'il est composé de plusieurs parties (multipart) car chaque partie peut elle-même être constituée d'autres parties et ainsi de suite. Dans la pratique, les clients de messagerie ne présentent que le 1er niveau de cette arborescence ce qui correspond au schéma présenté. Dans les adresses, seule l'adresse from est obligatoire. Si le message vous est adressé en copie cachée, le courriel de la BAL source n'apparaît ni dans la liste des adresses To, ni dans celle des adresses Cc. Notez également que le contenu du message peut être vide (ni objet, ni corps, ni PJ). En pareil cas, l'analyseur demande à l'archiveur de stocker le message avec la mention "non analysé : pas de contenu" et le message n'est pas transmis au système de filtrage.
|
| Filtre i |
Le "filtre i" est le ième filtre du système de filtrage. Le système de filtrage est constitué d'une chaîne de filtres exécutés séquentiellement. Chaque filtre, à l'exception du filtre par défaut, est déclaré sous la forme d'une extension (plugin). Cela permet à une organisation d'ajouter ou d'insérer des filtres à la demande de manière à pouvoir personnaliser son système de filtrage. Comme évoqué précédemment, le système de filtrage comporte un filtre par défaut portant sur le CRC du flux EML ainsi que sur l'adresse courriel de l'expéditeur. Si le CRC existe déjà, le courriel est rejeté. Ce filtre dispose d'une liste d'expressions régulières définissant des adresses courriels en liste noire. Si l'émetteur du courriel entre en correspondance avec cette liste, le courriel est également rejeté. Ce filtre par défaut est toujours en première position de la chaîne séquentielle des filtres. |
| Re-directeur |
Le re-directeur est chargé d'identifier dans les adresses To les courriels source ayant une BAL cible. Cette identification permet de dresser une nouvelle liste des adresses To. Il fait de même pour les adresses Cc en éliminant celles déjà présentes dans la nouvelle liste To. Si les deux listes sont vides, le re-directeur envoi à l'archiveur une commande validation avec la raison "dispatcher : aucun destinataire". Il ne transmet pas non plus le courriel structuré au composeur. Si au moins une des listes est non vide, le re-directeur n'adresse aucune commande à l'archiveur et transmet le courriel structuré au composeur. |
| Composeur |
Le composeur est chargé de recomposer le message. Il ajoute un pied de page au corps du message (texte ou HTML) quitte à créer ce corps s'il n'y en a pas (corps HTML dans ce cas). Ce pied de page précise :
Après avoir composé le message, il en extrait le flux EML qu'il envoi à l'archiveur avec le CRC du message initial. Une fois que l'archiveur à reçu le flux, il envoi la commande de validation de la transaction à l'archiveur. Enfin, le composeur adresse le flux EML du message recomposé à l'émetteur. |
| Chiffreur |
Si l'utilisateur souhaite rendre son message opaque non seulement au transport mais aussi au sein du serveur contenant la BAL "cible", il a la possibilité de chiffrer son message. Cette fonction est optionnelle et dépend de la configuration. Le prototocole retenu est S/MIME car même s'il laisse les métadonnées en clair, contrairement à Open PGP, il masque la structure interne du message. La gestion des clefs et des certificats est ici réduite car elle s'applique aux BAL source et cible connues. Attention : les serveurs WebMail ne prennent pas forcément en charge S/MIME. Ils doivent être configurés pour cela et disposer des extensions ad'hoc. Côté navigateur, il y a aussi un travail de configuration à réaliser ne serait-ce que pour déclarer la clef privée du compte utilisateur (déchiffrement du contenu du message) et la clef publique de cette application de chiffrement (signature). C'est pouquoi le chiffrement s'applique, dans la configuration, à la BAL cible. Lorsque le chiffrement est appliqué, l'objet du message est remplacé par un, objet générique : **** Undefined subject ***. |
| Emetteur |
L'émetteur adresse au serveur SMTP décrit par la configuration le message reçu du composeur (chiffré ou non chiffré) ; Si l'organisation souhaite rendre anonyme les envois de message il est recommandé :
|