LAB02 : part 01 : présentation de la plateforme TMC

De Pegasus45

Au boulot, on m'a demandé de concevoir une architecture de messagerie avec les fonctionnalités suivantes:

  • recevoir des mails dont les adresses mail ne sont pas connues,
  • stocker les mails dans des boîtes aux lettres et pouvoir les lire dans un webmail,
  • pouvoir regrouper les mails en fonction de la machine émettrice des mails,
  • accorder un espace de stockage limité aux boîtes aux lettres en fonction de la machine émettrice.

L'intérêt de cette plateforme est de proposer un service de réception et de stockage de mails qui permettra à diverses équipes de tests et de qualification applicative de pouvoir faire des tests d'envoi afin de vérifier que les mails sont bien formatés. Comme ces équipes travaillent avec des vraies données, donc avec de vraies adresses mails (internes et externes), il ne faudrait pas que ces mails partent dans la nature et arrivent chez les destinataires. Par conséquent, il faut que la plateforme accepte tous les mails venant de ces serveurs applicatifs.

Autre contrainte, ces adresses mails ne sont pas connues à l'avance par la plateforme. Il n'est pas question de faire un export de toutes les adresses de la base SQL ou de l'annuaire LDAP, ni de toucher à ces adresses. Par conséquent, la plateforme devra donc accepter tous les mails, même ceux qui ne connait pas encore, et de créer une boites aux lettres sur le serveur IMAP (et donc de créer un compte dans la base SQL du serveur IMAP). A chaque réception d'un mail, Postfix exécutera un script qui vérifiera dans la base SQL du serveur IMAP que le compte existeet si ce n'est pas le cas, il le crée.

Un webmail, RoundCube, sera installé pour permettre au responsable du serveur applicatif de visualiser les mails qu'il vient d'envoyer.

2e contrainte, comme il s'agit d'une seule et unique plateforme, il faudra qu'on puisse distinguer les mails venant des divers serveurs applicatifs. La solution consiste à affecter un domaine de messagerie fictif à chaque IP qui envoi des mails. Par conséquent, à chaque serveur applicatif, on associe un domaine de messagerie fictif. Et à chaque domaine de messagerie fictif, on associe à une instance Postfix dédiée, car chaque instance aura une configuration spécifique. Comme l'affectation à un domaine fictif ne se fait qu'au niveau de la connexion SMTP, le contenu des mails n'est pas modifié (donc les adresses de From et de To restent intactes).

3e contrainte, pour éviter qu'un serveur applicatif n'envoie trop de mails, et donc risque de saturer l'espace de stockage du serveur IMAP, il faudra que la plateforme puisse proposer un espace limité de stockage pour chaque domaine de messagerie fictif. Pour cela, on va utiliser LVM (Logical Volume Manager) afin de créer un LV pour chaque domaine de messagerie.

L'architecture retenue est la suivante:

  • un serveur de relais, RELAY01, qui va contrôler l'IP du serveur applicatif (pour voir s'il est autorisé à envoyer des mails vers cette plateforme), qui va associer un domaine de messagerie fictif à tous les mails reçus, et qui va envoyer ces mails au 2e serveur sur un port SMTP dédié de ce domaine de messagerie,
  • un serveur IMAP, BACKEND01, qui va avoir autant d'instances Postfix que de domaine de messagerie fictif, qui va vérifier la présence, voir créer à la volée à chaque réception de mail, la boites aux lettres, qui va stocker les mails dans les boites aux lettres, qui va proposer un webmail pour pouvoir visualiser les mails.


Messagerie tmc.png


Listes des articles associés: