Spécifications techniques du lecteur

Rôle

Le rôle du lecteur est d'interroger les dossiers "source" décrits dans la base de données afin d'en charger les courriels encore inconnus.

Cinématique des appels.

Le schéma qui suit expose la cinématique des appels, dépôt de fichiers et signaux :

Le lecteur commence par demander à l'archiveur les paramètres des dossiers source à lire. Pour cela, il invoque la fonction sourceFolders() de l'archiveur dans son constructeur. Cet appel est fait avant le changement du thread d'affinité afin que l'échange se fasse sur le thread principal qui a aussi créé l'archiveur.

Ensuite, il lit en une même session l'ensemble des en-têtes des courriels et calcul pour chacun d'eux son code SHA256. Une fois le code SHA256 calculé, le lecteur demande à l'archiveur s'il le connait. Pour cela, il émet le signal requestFortHeadersHashCodeStatus(const QString& hashCode). L'archiveur répond à ce signal par le signal headersHashCodeStatus(const QString& hashCode, bool status).

Si l'archiveur ne connait pas le code de hachage, le lecteur :

• lit le courriel depuis le dossier source ;
• dépose le contenu dans un fichier sur le répertoire de la file d'attente disque des courriels lus. Le fichier est nommé {id}-{code de hachage des en-têtes}.eml avec {id} égal à la clef primaire de la table t_folder.

Si le code de hachage des en-têtes est connu de l'archiveur, le lecteur passe au test du courriel suivant.

Le code de hachage des en-têtes joue le rôle d'identifiant unique du flux EML.

Notez que la file d'attente n'échange aucun signal avec le lecteur. Une fois le fichier EML déposé, la communication de la file d'attente se fait avec l'analyseur et l'archiveur. Le premier est sollicité pour amorcer le traitement de redirection tandis que le second est sollicité pour achivage systématique des flux EML reçus. Seules les amorces de communication entre la file d'attente et l'analyseur ou l'archiveur sont représnetées ici.

Parmi les en-têtes, 4 sont particulièrement importantes : Date, From, Message-ID et Subject. Notez que les RFC précisent que les en-têtes Date et From sont obligatoires. Si une de ces en-têtes est absente, le message est ignoré (trace dans le journal).

Le lecteur se comporte comme un "producteur" tandis que l'analyseur et l'archiveur se comportent comme des consommateurs. L'annexe D détaille un peu plus ce mécanisme.

Configuration.

La configuration spécifique du lecteur consiste à fournir à l'application les paramètres de connexion aux dossiers source. Initialement prévue pour être intégrée au fichier de configuration, les dossiers source sont désormais décrits en base de données via les tables t_mailbox et t_folder. La table t_mailbox décrit les paramètres de connexion à la BAL tandis que t_folder précise le dossier à lire.

La seule donnée nécessaire au lecteur et provenant du fichier de configuration est le nom du répertoire de dépôt des fichiers EML géré par la file d'attente.

Comme la base de données est censée être protégée via-à-vis des accès réseau, les mots de passe peuvent y être stockés en clair. Dans ce cas, ils sont préfixés de la lettre C. Cela ne les protège pas d'une indiscrétion ayant son origine au sein de l'équipe d'exploitation technique. Pour éviter ce type d'indélicatesse, il est possible de les protéger en les préfixant avec la lettre E. Le chiffrement est réalisé par le biais de la clef AES interne à la librairie cipher. (En développement le programme non livré buildkey -b64e permet ce type de chiffrement). Pour améliorer la sécurité, l'archiveur transmet les mots de passe tels qu'ils sont lus en base de données. C'est au lecteur d'effectuer le déchiffrement éventuel.