Architecture

		1. Principes généraux
		2. Traitement des données
		3. Accès aux données
		4. Choix d'architecture
		5. Collecte des données sur le serveur de Messagerie
		6. Mise en quarantaine des messages

 

1. Principes généraux

Back to Top

MailFlow Analyzer est une solution applicative qui analyse les flux de messagerie au sein d'une architecture IBM Domino. Elle nécessite l'installation sur les serveurs de messagerie (passerelles, serveur relais, serveur hébergeant des bases mail, serveurs applicatifs envoyant des mails...) d'un premier composant (Mail Flow Lib) qui va collecter les informations relatives aux messages entrant et sortant du serveur (nom de l'expéditeur, noms des destinataires, objet du message, taille...). Ces données sont consolidées dans un fichier et envoyées de façon régulière vers une Mail In Database (Mail In DB) afin d'y être centralisées. Les informations de l'ensemble des messages transitant par les serveurs de l'infrastructure Domino se retrouvent donc, sous forme de fichiers, dans une unique Mail In Database. Aucune donnée n'est conservée sur les serveurs de messagerie.

Le module de traitement des données s'installe sur un serveur Domino dédié (ou un serveur Domino applicatif). Ce serveur héberge le moteur de l'application (Mail Flow Engine) dont l'objectif est d'aller récupérer dans la Mail In Database (Mail In DB) les données relatives aux messages, de les traiter (calcul des statistiques) et de stocker les résultats sous forme d'une arborescence de fichiers sur le disque du serveur (Mail Data). Le moteur de l'application 'consomme' les informations 'produites' par les composants déployés sur les serveurs de messagerie de l'entreprise. La Mail In Database ne contient à l'instant T que les fichiers reçus des serveurs et non encore traités par le moteur. Sa taille reste donc assez faible.

Afin de présenter les informations statistiques résultant du traitement des données, l'application Mail Flow Analyzer (Mail Flow Engine) publie ces informations sous forme de documents Notes, dans plusieurs bases Notes (Mail Flow Databases). Ces bases peuvent être accédées vie un client IBM Notes ou un navigateur Web.

En plus de l'analyse du trafic des messages passant par les serveurs Domino, Mail Flow Analyzer dispose d'un module de contrôle du routage des messages via les Règles de Messagerie () activées sur les serveurs où le collecteur de données est installé. Ces règles ont la capacité de bloquer les messages indésirables en les expédiant vers une base de quarantaine (Quarantine DB). Le moteur de traitement analyse régulièrement le contenu de la base de quarantaine et notifie les expéditeurs des message à propos du blocage de leurs messages. Le blocage peut être temporaire (le mail est ainsi libéré au bout de quelques heures) ou définitif. Il sera alors purgé de la base de quarantaine au bout de quelques jours.

Le schéma suivant permet de visualiser les différents éléments entrant en jeu lors du fonctionnement de la solution MailFlow Analyzer :

Suivi des messages

Comme un message est susceptible de traverser plusieurs serveurs IBM Domino entre le moment où il est expédié et le moment où il est délivré (en interne ou vers Internet), il est important de le suivre tout au long de son acheminement. Dès qu'un nouveau message entre dans le maillage formé par les serveurs Domino où est installé Mail Flow Analyzer, celui-ci est identifié et on lui associe une clé unique (ajout d'un champ $MailInfoID au message). Cette clé unique permettra de détecter les passages du message sur les différents serveurs sous contrôle de l'application, et ainsi de pouvoir établir le chemin de routage suivi par ce message ainsi que les temps de transferts entre les différentes branches du maillage. Si Mail Flow Analyzer est installé sur le serveur de messagerie offrant les services de passerelle avec le monde Internet, toute sortie du message vers Internet sera enregistrée. Cela permettra de fournir, si la demande en est faite, la confirmation que le message a bien été délivré vers Internet et à quelle heure.

Comme il est important de détecter au plus tôt tout nouveau message, il est essentiel de bien cibler les serveurs sur lesquels le module de collecte des données des messages doit être installé. Il s'agit en priorité des serveurs de Mail hébergeant des boites aux lettres, des serveurs passerelles (vers Internet ou d'autres domaines Notes) mais également les serveurs dont les bases applicatives sont susceptibles d'envoyer des messages.

En étant positionné directement sur le serveur envoyant le message, Mail Flow Analyzer est capable d'identifier le processus à l'origine de l'envoi de message. Ainsi, sur un serveur de Mail, le programme sait différencier un message envoyé par un utilisateur via son client Notes d'un message envoyé par un agent programmé (Forward) d'une des boites aux lettres. Cette finesse dans l'analyse des flux de messagerie autorise la création de statistiques impossibles à obtenir par les moyens classiques (analyse des Log Notes).

 

2. Traitement des données

Back to Top

Le serveur Domino dédié à l'application Mail Flow Analyzer héberge le moteur de traitement des données (calcul des statistiques) et les données des messages une fois celles-ci traitées (conservation pour recherche ultérieure). Elle est donc utilisée à la fois pour son potentiel de traitement CPU et pour ses capacités de stockage disque. Le terme de 'serveur dédié' prend tout son sens pour des grandes entreprises, où les flux de messagerie sont tels que le volume des données à traiter et à stocker vont accaparer toutes les ressources de la machine. Pour les petites et moyennes entreprises, le moteur de traitement des statistiques et les fichiers de données peut être placé sur un des serveurs Domino ou, à la rigueur, sur une machine disposant d'un client Notes. Cette dernière solution peut être retenue par exemple lors du test de l'application en vue de son évaluation mais elle n'est pas vraiment pérenne à long terme.

Le schéma suivant présente les différentes étapes du traitement des données sur la machine dédiée :

Le moteur de l'application (MailFlow.exe) commence par extraire de la Mail In Database (Mail In DB) les fichiers contenant les données collectées dans les messages (Mail Data). Ils sont amenés sur la machine hébergeant l'application et supprimés de la Mail In Database. Ainsi, celle ci est pratiquement vide la plupart du temps.

Les données de chaque message sont traitées afin d'en extraire les informations nécessaires aux statistiques serveurs et utilisateurs. Elles sont ensuite stockées dans des fichiers textes afin de pouvoir servir plus tard, en cas d'interrogation sur le routage d'un message ou d'export vers des fichiers XML. Comme un message a pu traverser plusieurs serveurs de messagerie, le moteur de l'application reçoit dans les données qu'il a à traiter autant de traces du passage d'un message sur un serveur que de serveurs traversés (heure de passage du message sur le serveur et nom du serveur traversé). Il faut donc regrouper l'ensemble les données associées à un même message (utilisation de la clé unique $MailInfoID) pour pouvoir établir des statistiques fiables. Le fichier Mail Data File stocké sur la machine correspond donc à une agrégation des différentes données d'un même message. Pour des raisons d'efficacité, on place les données de 1000 messages dans un fichier Mail Data File. De plus, ce ficher est zippé pour économiser de la place disque.

Les données concernant les statistiques calculées pour les serveurs et les utilisateurs sont stockées dans des fichiers séparés (Statistics Data). Sous cette forme, il s'agit encore de données brutes. Le rendu de ces données sous formes statistiques classiques (%, évolution, tableaux, graphiques, etc), dans des documents Notes, se fait selon une fréquence définie lors du paramétrage de l'application. Ces données, au format Notes, sont accessibles, dans leur intégralité, dans des bases Notes du serveur hébergeant l'application. Il est possible de publier une partie de ces statistiques dans une base accessibles aux utilisateurs (Mail Flow Stat). Par exemple, pour les statistiques utilisateurs, il est possible de ne souhaiter voir figurer que le Top 100 des utilisateurs les plus consommateur de la messagerie, et pas nécessairement toutes les fiches utilisateurs. Il est également possible de sélectionner une partie des statistiques qui seront publiées parmi toutes celles qui sont conservées au niveau du serveur produisant les statistiques. Par exemple, on peut souhaiter ne pas publier vers l'extérieur certaines informations personnelles liées aux utilisateurs comme le nom des domaines Internet vers lesquels ils expédient du courrier.

Le moteur de création des statistiques crée toutes les statistiques possibles et le filtrage, dans le choix de ce qui est montré à travers la base Mail Flow Stat, se fait au moment de la publication des données dans la base.

L'application s'installe sur une machine Windows, disposant d'un serveur Domino (fortement conseillé) ou d'un simple client Notes (évaluation du produit, faible volumétrie,...). En cas d'installation sur une machine ne disposant que d'un client Notes, il conviendra de disposer d'un ID Notes autorisé à accéder aux documents de la Mail In Database et ayant les droits de suppression sur ces documents. Les différents composants de l'application Mail Flow Analyzer qui sont installés sur la machine dédiée sont les suivants :

• Dans le répertoire programme Domino du serveur :

  • Un exécutable MailFlow.exe qui est le moteur de l'application. Il peut se comporter comme une tâche Domino s'il est installé sur un serveur ou comme un simple exécutable Windows s'il est installé sur un client Notes. Ce programme scanne en permanence la Mail In Database, extrait les fichiers de données, traite les informations pour créer les statistiques relatives à l'infrastructure, aux serveurs, aux flux entre serveurs, aux populations, aux flux entre populations, aux utilisateurs et aux groupes d'utilisateurs. Ces statistiques sont conservées sous forme de fichiers compressés (fichiers Infra, Population, Server, Cross Server et User), sur le disque de la machine. Une fois les statistiques calculées, les données des messages sont stockées sur le disque de la machine (fichiers Mail Data File). A intervalles réguliers, les statistiques sont mises en forme et placées dans des documents Notes (documents Infra, Population, Cross Population, Server, Cross Server et User), dans des bases Notes de Mail Flow Analyzer du serveur Domino.
    
    
  • De manière optionnelle, un exécutable SynchroNSF.exe qui pourra être utilisé pour affiner la publication des statistiques ou pour fédérer plusieurs annuaires et bases de données Notes utilisés lors de la génération des statistiques des groupes d'utilisateurs.
    
    

• Dans le répertoire Data du serveur IBM Domino :

  • Une base Notes MailFlow.nsf qui permet de paramétrer l'application, de suivre l'état de l'exécution de l'application, et de lancer des requêtes vers celle-ci (reconstruction des statistiques des serveurs, redémarrage, arrêt, recherche, export des données). Cette base contient l'ensemble des composants de l'application (exécutable, bases Notes, documentation). Elle est également utilisée pour son déploiement. Il s'agit de la base principale de l'application.
    
    
  • Une base Notes MailFlowServer.nsf qui contient tous les documents Notes présentant les statistiques infrastructure, population, entre les populations, serveurs et les statistiques de flux entre serveurs (documents Infra, Population, Cross Population, Server et Cross Server).
    
    
  • Une base Notes MailFlowUser.nsf qui contient tous les documents Notes présentant les statistiques utilisateurs et groupes d'utilisateurs (documents User).
    
    
  • Une base Notes MailFlowLog.nsf qui recueille les informations de fonctionnement de l'application (événements divers et erreurs).
    
    
  • Une base Notes MailFlowSearch.nsf qui offre une interface de recherche multi-critères pour la localisation des messages ayant transités dans l'infrastructure.
    
    
  • Une base Notes MailFlowReport.nsf qui offre un module de génération planifiée de rapports sous forme de fichiers Word ou Excel.
    
    
  • Une base Notes MailFlowStat.nsf (Mail Flow Stat) qui contient une sélection de documents User, Infrastructure, Population, Cross Population, Server et Cross Server provenant des bases MailFlowUser.nsf et MailFlowServer.nsf. Cette base est accessible via un client IBM Notes ou un browser Web. C'est la base de publication des informations de statistiques. La création et la mise à jour des documents dans cette base peuvent être réalisées via le moteur de l'application MailFlow.exe (natif) ou par SynchroNSF.exe (pour une gestion plus fine).
    
    
  • Une base Notes MailFlowDashboard.nsf accessible via un navigateur Web fournissant des tableaux de bord synthétiques sur l'infrastructure de messagerie.
    
    
  • Une base Notes MailFlowCollect.nsf qui est la réplique de la base installée sur les serveurs de messagerie. Cette base contient les Règles de Messagerie qui interviennent dans le blocage des messages ainsi que le paramétrage pour la collecte des données sur chaque serveur Domino.
    
    
  • Une base Notes MailFlowQuarantine.nsf qui est installée sur un des serveurs de l'entreprise (pas forcément sur le moteur de traitement) et qui reçoit tous les messages bloqués par les Règles de Messagerie.
    
    

• Sur le disque dur du serveur de traitement, on trouve l'arborescence des fichiers contenant les données :

  • Un répertoire IDIndex qui héberge les fichiers IDFiles conservant les clés uniques de l'ensemble des messages ($MailInfoID) traités.
    
    
  • Un répertoire MailData qui héberge les fichiers Mail Data File contenant les données récupérées dans les messages. Dans un fichier Mail Data File, on conserve les données issues de 1000 messages.
    
    
  • Un répertoire InfraData qui héberge les fichiers Infrastructure contenant les statistiques pour l'infrastructure globale et les sous-infrastructures définies dans le document de Setup de l'application (1 fichier par Infrastructure, voir plus en cas de périodes glissantes).
    
    
  • Un répertoire PopulationData qui héberge les fichiers Population contenant les statistiques pour les populations et les cross-populations définies dans le document de Setup de l'application (1 fichier par population, voir plus en cas de périodes glissantes).
    
    
  • Un répertoire UserData qui héberge les fichiers User contenant les statistiques pour chacun des utilisateurs ou groupes d'utilisateurs (1 fichier par utilisateur ou groupe d'utilisateur).
    
    
  • Un répertoire ServerData qui héberge les fichiers Server contenant les statistiques pour chacun des serveurs IBM Domino de l'entreprise (1 fichier par serveur, voir plus en cas de périodes glissantes).
    
    
  • - Un répertoire CrossServerData qui héberge les fichiers CrossServer contenant les statistiques des flux entre serveurs (1 fichier pour les données concernant le flux d'un serveur A vers un serveur B, voir plus en cas de périodes glissantes).
    
    

Le schéma suivant présente l'installation des fichiers Mail Flow Analyzer sur le serveur Domino traitant les données :

La volumétrie des données hébergées dans les bases Notes (documents Infrastructure, Population, Cross Population, Server, Cross Server et User) va rapidement se stabiliser car le nombre de documents reste globalement fixe. Les statistiques présentées dans ces documents vont toujours occuper la même taille. Ceci est également vrai pour les fichiers contenant l'ensemble des statistiques (fichiers Infra, Population, Server, Cross Server et User). Ceux-ci vont légèrement augmenter au cours du temps mais la compression systématique de leur contenu permet de limiter leur expansion.

Pour les éléments offrant des statistiques sur des périodes glissantes (par année, par mois, par semaine, par jour) comme pour les Infrastructure, Population, Cross Population, Server et les Cross Server, l'application conserve autant de fichiers Infrastructure, Population, Cross Population, Server et Cross Server que de périodes traitées. Pour un serveur, on peut donc avoir dans le répertoire Server Data jusqu'à 29 fichiers :

ALL		Le fichier des statistiques globales cumulées (sans limite de temps).
YEAR		Les 5 fichiers correspondants aux 5 dernières années (glissantes).
MONTH		Les 12 fichiers correspondants aux 12 derniers mois (glissants).
WEEK		Les 4 fichiers correspondants aux 4 dernières semaines (glissantes).
DAY		Les 7 fichiers correspondants aux 7 derniers jours (glissants).

Afin de ne pas surcharger les répertoires avec trop de fichiers, une sous arborescence a été prévue sous les répertoires ID Index, Mail Data, CrossServer Data et User Data. Pour les deux premiers, il s'agit également d'offrir un découpage par mois afin de faciliter la sauvegarde des données ou leur purge.

Le seul container de données dont la taille augmente sans cesse est le répertoire Mail Data qui contient les fichiers Mail Data File hébergeant les données récupérées dans les messages transitant dans l'infrastructure. La taille des données du répertoire Mail Data sera donc proportionnelle au nombre de messages circulant et à la période de rétention choisie. La seule façon de borner la taille occupée par les données des messages est de limiter la durée de conservation des données. Afin de calculer la place nécessaire au stockage de ces informations, voici des éléments d'appréciation issus de données de production :

- 1 fichier Mail Data File contient les informations de 1000 messages
- Les informations d'un message occupent en moyenne 1 Ko
- Le fait de compresser systématiquement le fichier Mail Data File permet
  de réduire sa taille à 170 Ko (au lieu de 1000 Ko).

Le tableau suivant présente les projections d'occupation d'espace disque du répertoire Mail Data sur plusieurs années, en fonction du nombre de messages journaliers :Les volumes précédents ont été calculés dans les cas les plus défavorables, c'est à dire en extrayant des messages toutes les informations disponibles (objet, nom des pièces attachés, liste des destinataires...) et en considérant que le nombre de messages par jour était constant 365 j / 365. Dans la réalité, le nombre de messages est plus faible le week-end et les jours fériés.

 

3. Accès aux données

Back to Top

Les statistiques sont calculées en temps réel par l'application, au fur et à mesure que les données des messages arrivent sur la machine hébergeant le moteur de l'application. Afin d'en assurer un traitement correct, la durée de conservation minimale obligatoire de ces données sous forme de fichiers Mail Data File est d'environ 2 jours. Ce délai est rendu nécessaire par le fait qu'un message peut mettre plusieurs heures entre le moment où il est émis et le moment où il est délivré. Comme, de plus, il est susceptible de traverser des fuseaux horaires différents ou un changement de journée, il peut arriver le lendemain de son expédition, même si son délai d'acheminement n'était que de quelques minutes. Après ce délai de rétention de 2 jours, il serait possible de supprimer tous les fichiers du répertoire Mail Data sans que cela ne porte à conséquence sur la qualité des statistiques produites. Cela interdirait évidemment toute recherche d'informations sur les messages datant de plus de 2 jours.

Le choix de conserver les données au delà du délai nécessaire à la construction des statistiques permet d'exploiter les informations provenant des messages pour y effectuer des recherches ou l'interrogation de ces données pour retrouver, par exemple, le cheminement d'un message dans l'infrastructure afin de s'assurer de son bon acheminement (Mail Tracking). La cellule Help Desk de l'entreprise sait ainsi répondre immédiatement à une personne demandant si son message a bien été envoyé vers Internet. En recherchant dans ses données au moyen de l'interface offerte dans la base MailFlow Search, MailFlow Analyzer affichera la liste des message envoyés par cette personne dans le créneau horaire spécifié, et pour chacun d'entre eux, indiquera les serveurs par lesquels le message est passé (avec des informations d'horodatage). Afin de préserver la confidentialité de certains échanges, il est possible de ne pas prendre en compte les messages expédiés ou distribués à certaines personnes de l'entreprise (Direction, Ressources humaines..).

La conservation de toutes ces données autorise également leur traitement rétroactif, en vue de sortir des statistiques non prises en compte le jour de leur stockage, notamment au moyen de l'interface d'extraction des données au format XML.

 

4. Choix d'architecture

Back to Top

Collecte des données

Le fait de placer un composant sur les serveurs de messagerie que l'on souhaite analyser garantie la qualité de l'information récupérée. En étant physiquement présent sur le serveur, on capte à la source l'ensemble des informations nécessaires à l'établissement de statistiques détaillées. Les autres méthodes disponibles pour capter les informations sur les flux de messagerie telles que l'analyse des fichiers de log (Log.nsf) ne permettent pas d'obtenir un niveau de détail suffisant (types des fichiers attachés, proportion de messages chiffrés, signés, etc) pour la construction de statistiques fiables ou ne fournissent pas assez d'élément pour y autoriser des recherches basées sur des critères avancés (nom des pièces attachées, objet du message, etc).

L'autre avantage d'être présent sur les serveurs de messagerie et de capter les données en temps réel permet de ne pas avoir à activer un niveau de Log important sur les serveurs. L'augmentation du niveau des Logs est généralement demandée par les outils se basant sur le contenu des documents de Log pour établir leurs statistiques. Cela pénalise fortement le serveur à la fois en terme de performance mais également en volume de données stockées. L'installation du composant Mail Flow Analyzer sur les serveurs ne demande aucune modification de leur configuration. Le module de récupération des informations est transparent pour le serveur, il ne surcharge pas son CPU, ni son espace disque.

Stockage des données

Le fait de conserver les données des messages en dehors de l'infrastructure Domino, sous une arborescence de fichiers, est dicté à la fois par des contraintes volumétriques, de sécurité et d'exploitation. Comme dans les grandes entreprises, le nombre de messages transitant quotidiennement au travers de l'infrastructure Domino peut largement dépasser 100 000 Messages / Jour, il est n'est pas envisageable de vouloir stocker une telle volumétrie dans une ou même plusieurs bases Notes. Surtout dans le cas où, comme pour Mail Flow Analyzer, on souhaiterait pouvoir conserver un historique couvrant plusieurs années de messages. D'un point de vue sécurité / confidentialité des informations recueillies dans les messages, il est plus facile d'assurer la sécurisation d'un serveur dédié plutôt que d'un ensemble de machines. La remarque est valable également pour l'archivage et la sauvegarde de ces données (Mail Flow Analyzer conserve les informations sur les messages en organisant ses fichiers par année / mois / jour).

Les processus natifs Domino (Mail Tracking) qui essayent de conserver une trace des messages qui ont transité sur les serveurs de messagerie aux cours des X derniers jours ne sont pas capables de supporter des volumétries de 100 000 messages jours sans que cela ne provoque régulièrement la corruption des bases hébergeant les données (MTStore.nsf) et la perte des données de la période correspondante. La recherche de messages sur une longue période (plusieurs mois), en se basant sur un ensemble de critères (nom de l'expéditeur, des destinataires, de l'objet du message, le nom des pièces attachées, etc), est donc impossible avec une architecture de type Mail Tracking. Par contre, cela est possible pour Mail Flow Analyzer qui a su conserver et organiser toutes les données dans un format compatible avec les contraintes de volume.

Le recours à une solution propriétaire pour le stockage des données des messages (arborescence de fichiers zippés) en lieu et place d'une solution plus conventionnelle comme un système de gestion de base de données (SQL Server, DB2, Oracle...) est guidé par des contraintes techniques et financières. La volumétrie nécessaire au stockage des données de tous les messages dans une base de donnée relationnelle aurait été très supérieure à celle mise en place dans notre architecture, où nous zippons systématiquement toutes les informations. L'économie dans les coûts se fait ressentir à la fois au niveau du gain en nombre de disques dur nécessaires pour le stockage mais également au niveau du prix de la licence de la base de donnée. De plus, là où une base de données se doit de garantir un temps d'accès identique à l'ensemble de ses enregistrements, la nature même des informations que nous stockons nous permet d'établir une hiérarchie : les données des messages récents doivent être immédiatement disponibles car elles sont utilisées pour la création des statistiques, alors que les données des messages des jours précédents ne seront accédées qu'en cas de recherche ou d'export de données. La gestion des buffers (cache mémoire) peut donc être optimisée pour favoriser les données récentes, ce qui limite la consommation mémoire de la machine.

La granularisation du stockage des données dans un ensemble de fichiers, qui sont organisés selon la date du jour, facilite les opérations de sauvegarde car les fichiers contenant les données des messages datant de quelques jours ne sont plus jamais modifiés. Le volume des données à sauvegarder à chaque session correspond donc simplement aux nouvelles données. Cette organisation présente également un avantage certain pour les opérations de purge, car celle-ci peut se faire directement au niveau des fichiers de l'arborescence, en éliminant les fichiers en se basant sur leurs noms (qui contiennent la date correspondante aux informations stockées).

Traitement des données

Le volume de données à traiter et le nombre de statistiques à calculer pour chacun des messages est tel qu'il vaut mieux déporter sur un serveur Domino dédié le traitement de ces informations. La charge CPU de cette machine peut rester élevée au cours de la journée sans que cela ne perturbe l'infrastructure de messagerie. L'augmentation continuelle des volumes de messagerie nous conforte dans l'idée qu'il vaut mieux ne rien installer sur les serveurs de messagerie qui soit de nature à les surcharger comme le ferait un antivirus dont le moteur d'analyse du contenu des fichiers attachés aux messages tourne sur le serveur de messagerie. C'est donc en limitant les traitements effectués sur les serveurs de messagerie, que l'on limite du même coup les risques d'instabilité.

Publication des statistiques

Le volume des informations publiées concernant les flux de messagerie pour les serveurs et les utilisateurs est compatible avec la capacité de stockage d'une base Notes (MailFlow Stat), puisqu'il s'agit de consolider les données dans des documents Notes dont le nombre total est indépendant du nombre de messages circulant sur l'infrastructure. Pour une période donnée (1 jour, 1 semaine, 1 mois ou 1 année), la base va héberger :

• Un document Notes décrivant l'Infrastructure globale.
• Un document Notes par Population demandée dans le document de Setup.
• Un document Notes pour les Cross Population (flux entre les Populations souhaitées).
• Un document Notes pour les statistiques de chacun des Serveurs de l'entreprise,
• Deux documents Notes Cross Server pour les statistiques de flux entre un couple de serveurs A et B (un document pour le flux A --> B et un document pour le flux B-->A).
• Si on veut publier les statistiques utilisateurs, un document Notes par utilisateur, par Mail-In database ou par groupe d'utilisateurs (regroupement possible par OU, par serveur de Mail, par certificat, par organisation, etc).

Cette base Notes ne contient que les données que l'on souhaite voir publier, à la fois en terme de type (infrastructure, population, flux entre populations, serveurs, flux entre serveurs, utilisateurs, groupes d'utilisateurs) et de contenu (nature des statistiques exposées). Il s'agit d'un sous-ensemble des statistiques complètes disponibles au niveau du serveur hébergeant l'application Mail Flow Analyzer et les données des messages. Ces informations étant stockées dans un format ouvert (des documents Notes dans une base Notes), il est tout à fait envisageable qu'un processus tiers puissent venir y puiser des informations.

L'ouverture au monde extérieur des données extraites des messages, sous forme d'une interface de recherche et d'un module d'export en XML, autorise un accès interactif aux données (recherche basée sur des critères de sélection multiples) et leur exploitation en dehors du cadre de l'application (export vers une base de données, transfert dans un moteur de gestion graphique comme Crystal Report ou Excel). Même si les données des messages sont stockées dans un format propriétaire (fichiers textes) au niveau de la machine dédié à l'application, elles restent disponibles dans des formats ouverts.

Exploitation au quotidien

Cette architecture distribuée permet d'assurer une grande flexibilité dans la mise en place et l'exploitation de la solution. Il n'est pas nécessaire de placer le composant collectant les informations sur tous les serveurs de l'entreprise pour commencer à obtenir des statistiques. Si le composant n'est installé que sur un seul serveur, les statistiques concerneront ce serveur ainsi que les utilisateurs qui ont leurs boites aux lettres sur ce serveur. Si le composant est installé sur au moins 2 serveurs, l'outil sera capable, en plus, de fournir les informations sur les flux de messagerie entre ces 2 serveurs. Plus on augmente le nombre de points collectant des données, plus les statistiques fournies sont précises.

Comme la collecte des données est indépendante de leur traitement (les 2 se font normalement sur des machines différentes), il est possible de mettre les collecteurs en place avant de démarrer le module d'analyse des données. Les informations récupérées dans les messages sont envoyées dans la Mail In Database et y restent tant que le module d'analyse ne les y récupère pas. Cette zone de stockage intermédiaire qu'est la Mail In Database autorise l'arrêt du processus de traitement des données et de la machine l'hébergeant pour des raisons liées à l'exploitation (sauvegarde quotidienne, reboot de la machine, mise à jour des logiciels, etc) sans que cela ne perturbe le fonctionnement global de la solution. Dès que le module de traitement des données redémarrera, il traitera tous les fichiers Mail Data se trouvant dans la Mail In Database.

La mise à jour de l'application Mail Flow Analyzer vers une version supérieure est facilitée par son hébergement à un endroit unique, en dehors des serveurs de production. Le choix du système d'exploitation Windows permet de lui associer, sur la même machine, tous les moteurs de création de fichiers du marché (Word, Excel, PDF, Crystal Report...).

 

5. Collecte des données sur le serveur de Messagerie

Back to Top

Sur l'ensemble des serveurs qui hébergent des boites aux lettres ou par lesquels transite du courrier, il convient d'installer le composant qui collecte des informations sur les messages qui passent. Sur tous les serveurs Domino recevant ou envoyant du courrier, les messages sont copiés dans la base Mail.box du serveur avant que la tâche Router ne les transfère soit vers un autre serveur Notes, soit les délivre dans les boites aux lettres locales des destinataires. C'est précisément au moment de la création du message dans la base Mail.box que le composant est en mesure de collecter les données du message. Ce composant est constitué par :

• Une DLL (Mail Flow Lib) qui s'accroche au coeur de Domino et qui va pouvoir accéder, en mémoire, au contenu des messages créés dans la base Mail.box, et ceci avant même que le Router ne les traite. Le code de la DLL va récupérer dans le message, les informations utiles à création des statistiques (nom de l'expéditeur, liste des destinataires, type de message, taille du message, liste des fichiers attachés, objet du message, etc) et les conserve en mémoire. Dès que son buffer mémoire est plein, il transfère les données des messages dans un fichier sur le disque du serveur (fichier Mail Data). Lorsque le fichier a atteint une certaine taille, le code présent dans la DLL le clôture (ajout d'une ligne spécifique à la fin) et transfère les données suivantes dans un nouveau fichier.
  
  En plus de la capture des données des messages traversant le serveur, la DLL peut également analyser le contenu des messages et modifier à la volée le nom de l'expéditeur, les noms des destinatires ou même bloquer le message en l'envoyant vers une Mail-in database de quarantaine. La modification du routage des messages est contrôlé par des documents Règles de Messagerie (Mail Rules) présents dans la base MailFlowCollect.
  
  Pour que cette DLL s'attache au coeur du serveur Domino, il convient de la déclarer dans le fichier Notes.ini du serveur. Le terme DLL indique ici une Librairie partagée (Dynamic Link Library). En fonction des différents OS sur lesquels le serveur Domino existe, ce fichier peut recevoir des dénominations différentes (DLL sous Windows, Librairie sous Unix...).
  
  
• Une tâche serveur (Mail Flow Task) dont la seule fonction est d'envoyer vers la Mail In Database centrale (Mail In DB) les fichiers de données créés par la DLL (Mail Data). La tâche ne transfert que les fichiers qui sont dans un état terminé.
  
  
• Une base Notes (Mail Flow Collect) qui contient les informations de paramétrage nécessaires au fonctionnement de la Librairie et de la Tâche. On trouve également dans cette base les documents Règles de Messagerie (Mail Rules) utilisées pour modifier le routage des messages en les expédiant vers une base de quarantaine. Cette base est répliquée sur tous les serveurs hébergeant le collecteur de données. Cela permet un contrôle centralisé du paramétrage du module.

Le schéma suivant présente une installation du module de récupération des données sur un serveur de messagerie :

 

La base Mail Flow Collect est un composant neutre du dispositif. Elle se contente de fournir les paramètres à la DLL et à la Tâche comme par exemple les documents Règles de Messagerie (Mail Rules) utilisés pour la modification du routage des messages, l'emplacement sur le disque où créer les fichiers Mail Data ou encore la liste des données que l'on souhaite extraire des messages. Il est en effet possible de restreindre la nature des informations que l'on collecte (ne pas récupérer l'objet du message, se contenter de la liste des extensions des fichiers rattachés et non pas de leurs noms, etc).

La DLL et la Tâche de Mail Flow Analyzer utilisées sur les serveurs de messagerie sont dépendantes du système d'exploitation du serveur. Il convient donc de sélectionner le bon composant lors de l'installation (.dll et .exe sous Windows, .so sous Unix...).

Transfert des données collectées vers la Mail In Database

La DLL est le composant principal du dispositif car c'est elle qui à accès au message en mémoire et qui extrait les informations. C'est également elle qui crée les fichiers de données Mail Data. Elle joue le rôle de 'producteur' de données, et la Tâche joue le rôle de 'consommateur' de ces données. Une fois les fichiers Mail Data envoyés vers la Mail In Database (Mail In DB), ils sont supprimés du disque du serveur. Si la tâche doit être arrêtée quelques minutes, cela n'empêche pas le système de récupération des données de fonctionner. Les fichiers Mail Data continuent d'être créés sur le disque du serveur. Ils seront tous expédiés au démarrage de la Tâche Mail Flow. En fonctionnement normal, les fichiers ne restent que quelques minutes sur le serveur avant d'être transférés vers la Mail In Database.

Comme la DLL bufferise les données (afin de limiter les écritures sur disque), et que la tâche n'envoi le fichier que quand celui-ci atteint une certaine taille (ou qu'un certain délai s'est écoulé), il faut compter à peu près 20 minutes (cette durée est paramétrable) entre le moment où le mail passe sur un serveur et le traitement de cette information par le moteur de l'application MailFlow Analyzer sur sa machine dédiée. Les données sont donc traitées au fur et à mesure de leur arrivée sur la machine hébergeant l'application, mais avec un décalage d'environ 20 minutes. Ce délai est rendu nécessaire pour ne pas perturber le serveur de messagerie. En effet, il n'est pas question d'écrire dans le fichier Mail Data sur disque dès qu'un message transite par le serveur et il ne serait pas raisonnable d'envoyer trop de 'petits' mails de données vers la Mail In Database sous peine de perturber le trafic des messages.

Impact sur le serveur de messagerie

Contrairement aux antivirus qui utilisent eux aussi une DLL et une tâche pour traiter les messages qui passent sur un serveur, Mail Flow Analyzer ne ralentit pas le routage du message. Habituellement, les antivirus utilisent le code de leur DLL pour bloquer le message dans la Mail.box du serveur en modifiant le champ RoutingState du message (en le positionnant à DEAD) pour que le router ignore le message. La tâche de l'antivirus scanne la base Mail.box afin de récupérer les messages bloqués par la DLL, traite le message bloqué en analysant le contenu (fichiers attachés) et si le contenu est valide, la tâche 'libère' le message en ré-initialisant le contenu du champ RoutingState afin que le router puisse délivrer le message.

Cette technique ralentit évidemment le routage des messages, non seulement à cause du temps passé à l'analyse du message (plusieurs secondes), mais également par le fait de 'casser' la dynamique du router, qui est notifié par le serveur de l'arrivée de nouveaux messages déposés dans la Mail.box. Dans le cas présent, le router ne peut traiter aucun des messages car ceux-ci sont positionnés à DEAD. De plus, ce blocage entraîne une désynchronisation du router qui oublie parfois de traiter les messages libérés, avec comme conséquence l'accumulation de messages non délivrés dans la Mail.box du serveur.

MailFlow Analyzer ne bloque pas les messages du serveur lors de leur analyse, il ne modifie donc en rien la dynamique serveur / router. Il se contente de récupérer, en mémoire, les informations du message qui peuvent l'intéressé. Il n'y a pas de traitement coûteux en temps comme l'analyse du cors (Body) du message ou du contenu de ses fichiers attachés. Les Règles de Messagerie sont appliquées en temps réels sur les messages en mémoire et elles ne sont pas de nature à ralentir le routage des messages (à l'exception de ceux envoyés vers la base de quarantaine).

Même si l'architecture proposée sur les serveurs de messagerie semble identique aux logiciels antivirus (une DLL et une tâche), le mode de fonctionnement et les conséquences sur l'infrastructure sont complètement différents.

 

6. Mise en quarantaine des messages

Back to Top

L'analyse des messages traversant les serveurs de messagerie permet à Mail Flow Analyzer d'offrir un service d'analyse des messages en temps réel et en fonction des Règles de Messagerie définies, de modifier le routage du message en l'expédiant dans une base de quarantaine.

Les composants rentrant en jeu dans la mise en place des Règles de Messagerie sur un serveur de messagerie sont ceux déjà en place pour la capture des données des messages. Il n'y a rien à installer de plus au niveaux des serveurs de messagerie, juste du paramétrage à effectuer dans la base Mail Flow Collect.

Au niveau des serveurs de messagerie, nous utilisons :

• La DLL Mail Flow Lib, qui est également utilisée pour collecter les données des messages, va effectuer le travail d'analyse du contenu du message et va modifier l'adresse de destination du message si celui-ci doit être envoyé dans la base de quarantaine.
  
  
• La base Notes Mail Flow Collect héberge les documents Règles de Messagerie qui définissent les critères autorisant le blocage des messages. Elle contient également les informations de paramétrage de la DLL Mail Flow Lib.

Au niveau de l'infrastructure, nous utilisons également :

• La base Notes de Quarantaine (Quarantaine DB) qui est installée sur un des serveur de l'entreprise. Elle est déclarée comme une Mail-in database dans le Carnet d'Adresse et reçoit l'ensemble des messages qui ont été re-routés.
  
  
• Le moteur Mail Flow Engine de l'application qui tourne sur un des serveurs Domino. Il va régulièrement analyser le contenu de la base de Quarantaine pour traiter les messages reçus.

Le schéma suivant présente les composants utilisés pour le contrôle du routage des messages dans l'infrastructure de messagerie :

Le moteur de traitement (Mail Flow Engine) traite les messages stockés dans la base de quarantaine (Quarantine DB) afin notamment de notifier l'émetteur du message que son mail a été bloqué. Pour les messages qui n'ont été bloqués que quelques heures (respect des heures ouvrées), le moteur les libère après le délai de rétention. Le moteur de traitement effectue également les purges nécessaires pour les mails définitivement bloqués.

 

Back to Top