Architecture de postfix

Postfix (voir bigpicture.gif) est architecturé autour d'un module de réception des messages (voir inbound.gif) et de celui qui permet de délivrer ces messages (voir outbound.gif).

Figure 35.2. Architecture de Postfix

Architecture de Postfix

Figure 35.3. Réception des messages

Réception des messages

Figure 35.4. Traitement des messages

Traitement des messages

La réception des messages (entrées)

Quand un message doit être traité par un système Postfix, le passage obligé est la file incoming.

Si le message est posté localement, il est déposé dans un répertoire en accès “ écriture possible pour tout le monde ”. Le démon pickup le traitera à partir de là. Ce démon procède à une première phase d'analyse des couriers (headers) afin de protéger le reste du système.

Si le message provient d'un réseau, le message est traité par un serveur SMTP. Certaines règles de sécurité et de contrôles sont déjà effectuées.

Les messages peuvent être générés par Postfix lui même ou par un robot afin de prévénir l'administrateur des erreurs, adresses introuvables, tentatives de violations des règles, problèmes de protocoles...

Les messages peuvent être redistribués par des entrées dans les fichiers d'alias ou des fichiers .forward.

Le démon cleanup représente la période finale de traitement d'un message, notamment la vérification de l'entête du message (complétude user@fqdn), la réécriture d'adresse, le dépôt du message dans la file incoming, l'avertissement du gestionnaire de liste.

Délivrer les messages

Quand un message est arrivé dans la file incoming, l'étape suivante consiste à le délivrer. Ceci est pris en charge par le gestionnaire de file qui est le coeur du système de Postfix. Il contacte un agent (local, smtp, lmtp, pipe) chargé de délivrer les messages en lui communiquant des paramètres (localisation du message, nom/adresse de l'emetteur, nom(s)/adresse(s) du/des destinataires, machine hôte de destination...

Le gestionnaire de liste maintient une liste séparée pour les courriers ne pouvant être délivrés immédiatement (deferred).

Les messages ne pouvant être définitivement délivrés (bounces) génèrent une trace d'information dans les journaux.

Sur Linux, l'agent de traitement local des messages est le plus souvent procmail. Il doit pouvoir traiter des structures de boîtes aux lettres conformes au standard Unix, utiliser les aliases, les redirections .forward...

L'agent de traitement pour l'acheminement distant des messages s'appuie sur le protocole SMTP et utilise le port 25.

Les différents démons sont activés “ à la demande ” par un super serveur (master daemon) un peu à la façon d'inetd.

Une fonction / un programme

Chaque grande fonction de postfix est prise en charge par un programme indépendant.

  1. Lecture des messages locaux

  2. Réception SMTP

  3. Réécriture d'adresse

  4. Envoi SMTP

  5. Délivrance locale

  6. Traitement des erreurs (bounces)

  7. Gestion des files

Apports en termes de sécurité :

Cette option présente plusieurs avantages.

  1. Décomposition = programmes plus petits et plus lisibles

  2. Plus difficile à casser ou circonvenir

  3. Chroot plus facile

  4. Les programmes ne se font pas confiance : isolation de chaque fonction

Communication interprocessus par sockets Unix ou file (FIFO)

  1. Portabilité aisée

  2. Messages courts dans les sockets

  3. Ne pas faire confiance aux données

Semi résidence

  1. Les démons sont réutilisés et contrôlés par un super démon “ master ” qui les crée à la demande.

  2. Nombre maximum pour chaque fonction : contrôle précis du fonctionnement, sécurité contre le “ déni de service ” (DOS)

  3. Temps d'inactivité paramétrable

Files d'attente multiples

  1. maildrop : messages locaux postés par sendmail

  2. incoming : messages en cours de réécriture et de nettoyage

  3. active : messages en cours ou en attente de transport

  4. deferred : messages en attente

  5. defer : arborescence d'attente (hachée pour éviter les trop gros répertoires -- problème dans Sendmail)