2.  Postfix

2.1.  Anatomie de Postfix

2.1.1. Introduction

Postfix est constitué pour une part d'un petit nombre de programmes qui s'interfacent avec les processus utilisateurs (sendmail, postsuper, postqueue ...) et pour une part d'un nombre plus important de programmes qui s'éxecutent en tâches de fond [background]. Ces derniers sont gérés par un « super » daemon appelé master, dont le rôle est double : déterminer la nature des tâches à réaliser et confier ces tâches à des processus spécialisés.

Pour mieux comprendre le rôle de Postfix on peut utiliser une analogie (c.f. chap. V de [1]) ; à savoir que Postfix agit comme un routeur. Rappelons qu'un routeur est chargé de router (i.e. déterminer le chemin) un paquet IP (unité d'information manipulé par le routeur) en fonction d'informations comme l'adresse IP de destination, l'adresse IP source, l'interface sur laquelle le paquet a été reçu et d'une table de routage (qui met en correspondance des addresses IP avec des interfaces réseaux (de sortie)) vers une destination. Un routeur possède en général plusieurs interfaces réseaux.

Figure 3. Postfix comme routeur de courriers

Postfix comme routeur de courrier, accepte et établit différents types de connexion pour acheminer des emails.


Postfix est en mesure de recevoir des messages (l'email; est l'unité d'information manipulé par Postfix) en provenance de sources multiples et en fonction de paramètres comme l'adresse de destination [envelope recipient en terminologie SMTP], l'adresse de l'expéditeur [envelope sender] et des informations stockées dans ses tables[1] [aka maps] de les remettre au(x) destination(s) appropriée(s).

2.1.2. Les daemons Postfix

Figure 4. Interactions entre les différents daemons Postfix.

Les relations entretenues entre les daemons Postfix.


Tableau 2.  Les daemons Postfix

Nom Description
master

Processus maître chargé de coordonner l'activité de tous les autres daemons Postfix. Il attend l'arrivée de tâches et les delègue aux processus spécialisés. Il contrôle le nombre d'instances s'éxecutant concurremment (en fonction de la charge de travail), le nombre de fois où Postfix peut les réutiliser et la période d'inactivité avant la terminaison d'une instance.

Ce daemon fonctionne à l'instar du « super » daemon inetd des machines Unix.

qmgr

Ce daemon est chargé de la gestion des files d'attentes [queues] de Postfix : c'est le cœur de ce système.

Il distribue les tâches de remise de messages aux différents daemons : local, smtp, lmtp, pipe tout en veillant

  • à éviter toute famine en terme de ressources ; en maintenant une petite file d'attente active contenant juste quelques messages à délivrer, laquelle fait figure de fenêtre d'activité limitée servant de frontal à des files potentiellement plus importantes (comme les files incoming et deferred) permettant d'éviter que qmgr se retrouve à court de mémoire lors des montées en charge.

  • à maintenir la stabilité du système. Si Postfix ne réussit pas à délivrer un message il le transfère dans la file deferred. Conserver les messages momentanément non délivrables dans une file séparée contribue à une meilleure efficacité du système (pas d'incidence sur la file des messages délivrables outgoing).

Il utilise bounce et error pour retourner les messages défitivement non délivrables aux utilisateurs listés dans la table relocated.

bounce, defer

Un MTA doit prévenir l'expéditeur des messages qui n'ont pu être délivrés à leur destination. Dans Postfix cette fonctionnalité est du ressort des daemons bounce et defer.

Deux types d'évènements conduisent à ce type de notification sont les erreurs non récupérables et les destinations momentanément inaccessibles (ce type conduit à l'émission de warnings) ; ils sont reçus par le qmgr qui déclenche alors bounce et defer.

flush

Ce daemon est chargé de vider les files d'attentes des messages qui y sont stockés. Ces messages sont soit dans l'état pending (état normal) soit en état deferred.

showq

Ce daemon permet de lister les différentes listes d'attentes de Postfix. C'est ce processus qui s'exécute lorsque l'on sollicite l'utilitaire mailq [ aka sendmail -bp ].

Ce daemon est rendu necéssaire par le fait que les files d'attentes Postfix ne sont pas universellement accessibles en lecture et que par conséquent les programmes non setuid ne peuvent y accéder or Postfix conçu dans un contexte de sécurité ne possède pas de binaires setuid.

error

Ce daemon est un MDA spécialisé qui informe le daemon bounce de l'inaccessibilité d'une destination.

Généralement, il n'est pas directement utilisé, sauf à configurer un domaine inaccessible en le redirigeant sur ce daemon.

trivial-rewrite

Ce daemon agit sur sollicitation du daemon cleanup dans le but de transformer des adresses non standards en adresses email standards du type user@fqdn. Ce daemon est par ailleurs sollicité par le qmgr pour la résolution des adresses de destination.

local

Ce daemon est responsable de la remise des emails locaux ; il peut écrire dans les boîtes dans le style mbox ou Maildir et tirer partie des alias de type sendmail et des fichiers .forward

Ce daemon peut éventuellement déleguer la remise locale des emails à un LDA, comme procmail ou maildrop, lequel dispose généralement de fonctionnalités plus avancées telles que le filtrage.

proxymap

Ce daemon permet l'accès en lecture des tables de recherche [maps] aux processus client Postfix. Ce partage entre les clients induit deux effets :

  • la levée des restrictions liées aux environnments chrootés.

  • la réduction du nombre de table de recherche simultanément ouvertes.

spawn

Ce processus crée des processus non-Postfix à la demande, il peut se mettre à l'écoute sur un socket TCP ou un socket Unix, ou encore un mécanisme FIFO liés soit aux flux d'entrée, de sortie ou d'erreur standard.

Ce daemon est sollicité par les systèmes de filtrages externes utilisés par Postfix.

virtual

Ce daemon aussi appelé VDA [Virtual Delivery Agent] est une version allégée du daemon local spécialisé dans la remise locale des emails. Il n'assure pas ni l'expansion des alias, ni l'expansion des .forward et en ce sens constitue un des daemon les plus sûrs de l'environnement Postfix. Il permet par ailleurs la remise à des domaines multiples.

lmtp

Ce daemon communique avec les serveurs de boîtes de mails locales et distantes avec le protocole LMDP [Local Mail Delivery Protocol] défini par le RFC 2033.

L'intérêt d'utiliser une telle solution (client Postfix LMTP) et que Postfix s'occupe de la gestion toutes les files d'attentes ; une machine Postfix peut « nourrir » plusieurs serveurs de boîtes à mails (lesquels ont alors besoin d'un daemon lmtp) via LMTP.

pipe

Le client pipe est une interface de sortie aux autres mécanismes de transport (de mails). Il invoque les programmes avec des paramètres et « pipe » le corps du message dans leur entrée standard.

smtp

Ce daemon est un client SMTP dont le rôle est d'acheminer les couriers sortants vers leurs destinations (distantes). Typiquement, ce daemon récupère les adresses des serveurs d'emails, requête de type MX d'une destination donnée, les trie, et tente chaque adresse jusqu'à l'obtention d'une réponse.

Sur un système Postfix relativement chargé, plusieurs instances de ce daemon s'exécutent simultanément.

smtpd

Ce daemon est chargé des communications avec les clients de mails qui délivre leurs messages via SMTP. Il effectue des vérifications qui protège le reste du système Postfix et peut être configuré pour implémenter des contrôles UCE [Unsolicited Commercial Emails], des recherches DNS, des contrôles basés sur des blacklists réseaux...

Après avoir accepté un message, smtpd le place dans la file incoming et qmgr se charge de la suite des opérations.

qmqpd

Ce daemon Postfix implémente le protocole QMQP [Quixk Mail Queuing Protocol], ce qui rend Postfix compatible avec qmail™ et le gestionnaire de liste ezmlm.

pickup

Ce daemon reprend les messages placés dans la file maildrop par le programme client local sendmail. Après avoir effectué quelques vérifications « sanitaires », il passe les messages au daemon cleanup.

cleanup

Ce daemon réalise les traitements terminaux sur les nouveaux messages. Il ajoute les entêtes manquants requis, il assure la ré-écriture des adresses et extrait optionnellement les adresses de destination des entêtes. Il insère alors le résultat dans la file incoming et informe le daemon qmgr de l'arrivée de nouveaux messages.

sendmail

Cette commande Postfix remplace et émule le MTA Sendmail™. Le but est de fournir une interface compatible Sendmail™ aux applications utilisant /usr/sbin/sendmail. Elle interagit avec le binaire postdrop pour placer les messages dans la file maildrop gérée par pickup.

anvil

C'est un élément préliminaire dans la défense contre les clients de mails et les attaques DoS [Denial-of-Service] qui inonde les serveurs SMTP de tentatives simultanés ou successives. Muni d'une whitelist autorisant sans restrcitions les clients légitimes, il permet de mettre en place une limitation de débit sur le reste des clients.


2.1.3. Les files d'attentes de Postfix

Postfix possède des files d'attentes localisées usuellement dans le répertoire /var/spool/postfix (c.f. la variable queue_directory du fichier main.cf). Tous les messages gérés par Postfix sont stockés dans ces files avant d'être remis.

Exemple 4. Le répertoire /var/spool/postfix sur une machine FreeBSD


$  ls  /var/spool/postfix/
active   corrupt  deferred hold     maildrop private  saved
bounce   defer    flush    incoming pid      public   trace


Tableau 3.  Les principales files d'attente Postfix

Nom Description
incoming

Tous les messages entrant dans le système Postfix sont stockés dans cette file d'attente par le daemon cleanup. Les nouvelles files sont créées avec pour propriétaire l'utilisateur non privilégié Postfix et pour mode 0600 (accès en L/E au seul utilisateur Postfix). Dès que ces files sont aptes à être traitées le daemon cleanup modifie leur mode en 0700 et prévient le daemon qmgr de l'arrivée de nouveaux messages[a]

Le daemon qmgr examine la file incoming et déplace les messages qui s'y trouve dans la file active, tout en veillant à ne jamais dépasser les limites de ces ressources. Par défaut, la file active est limitée au stockage de 20000 messages.

maildrop

Cette file stocke les messages soumis par la commande sendmail. Il est possible d'ajouter des messages à cette file même si Postfix ne s'exécute pas ; une fois démarré celui-ci examine le contenu de cette file.

Périodiquement ou sur notification du daemon postdrop, le daemon pickup examine et traite cette file. Le programme postdrop qui est setgid permet à la commande non privilégiée sendmail d'ajouter des messages dans la file maildrop et il notifie le daemon pickup de l'arrivée de nouveaux messages.

active

Les messages stockés dans cette file sont prêts à être envoyés. Le gestionnaire de file (qmgr) est un ordonnanceur qui assure une remise rapide et équitable des messages à l'ensemble des destinations dans la limite imposée sur les ressources dont il dispose.

hold

Les messages stockés dans cette file le sont jusqu'à l'intervention de l'administrateur. Aucune tentative périodique de remise n'est exécutée sur cette file. La commande postsuper permet d'ajouter des messages de cette file ou de les retirer pour les mettre dans la file deferred

Les messages placés dans cette file peuvent y rester pour un temps supérieur au paramètre maximal_queue_lifetime[b] .

deferred

Si les messages possèdent des destinations [recipients] pour lesquelles la remise n'a pu avoir lieu, alors Postfix les met dans cette file. Le daemon qmgr examine périodiquement (la période est donnée par le paramètre queue_run_delay) cette file pour pour enlever les messages de cette file et les placer dans la file active.

Si l'examen des files deferred et incoming survient au même moment, alors qmgr alterne le traitement sur les deux files par message.

corrupt

Ce répertoire contient les files endommagées permettant ainsi à l'administrateur de les inspecter avec la commande postcat. Postfix signale ces problèmes par des avertissements dans les logs lors de son démarrage.

[a] Lequel ignore toute file d'attente dont le mode est 0600.

[b] Paramètre qui détermine l'intervalle de temps après quoi les messages non délivrés à destination sont retournés [bounced] à l'expéditeur).


2.1.4. Les tables [Maps] de Postfix

Les Maps sont des fichiers et bases de données que Postfix utilises pour ses recherches d'information. Elles ont des usages différents mais possèdent toute une syntaxe identique de type clé [a.k.a LHS Left Hand Side] associée à une valeur [a.k.a RHS Right Hand Side], en voici quelques exemples :

Tableau 4.  Quelques couples LHS, RHS

Clé LHS Valeur RHS
root:pascal
pascal@chuck.es.homepascal@seth.homeunix.net
hotmail.comREJECT
/[!%\@].*\@/550 This server disallows weird address syntax.
europort@wanadoo.fr554 W.A.S.T.E.


Format des maps

La liste des formats de maps dépend de la manière dont Postfix a été compilé sur un système. A titre d'exemple, sur ma machine FreeBSD « de base », j'ai la liste suivante :


$ postconf -m
btree
cidr
environ
hash
ldap
pcre
proxy
regexp
static
unix

Maps de type btree, dbm, hash ...

Les maps indexées sont des fichiers binaires obtenus à partir de simples fichiers au format texte et utilisées par les commandes telles que newaliases, postalias et postmap.

Ces fichiers binaires permettent à Postfix de faire des recherches efficaces. Pour de meilleures performances les maps sont lues au démarrage du système Postfix ; elles ne sont relues que si un changement est détecté par le système sur les fichiers correspondants stockés sur le filesystem. Dans ce cas le daemon en cours est terminé et un nouveau est relancé par le master daemon.

Les maps indexées classiques sont générées à partir des fichiers textes suivants : aliases, canonical, transport, relocated et sasl_passwd. Typiquement, la map indexée correspondant au fichier aliases et dénotée aliases.db (la génération est effectuée avec la commande postalias).

Maps de type PCRE, regexp, CIDR et fichier plat

Ces maps sont des fichiers texte régulier, que Postfix lit entièrement à son démarrage. Attention, l'ordre de lecture est (contrairement au cas précédent) déterminant. La première correspondance trouvée détermine en effet le comportement de Postfix (celui ignore les lignes qui suivent la première correspondance qu'elles s'appliquent ou non). Voici un exemple simple :


/foo\.bar@example\.net/        OK
/example\.net/                 REJECT

La recherche de la clé foo.bar@exemple.net retourne OK. Cela permet donc d'atteindre cet utilisateur particulier à l'exclusion de tous les autres (pour ce domaine). Par contre, si on intervertit ces deux lignes, comme dans ce qui suit :


/example\.net/                 REJECT
/foo\.bar@example\.net/        OK

Alors tout le domaine example.net est non joignable, l'utilisateur foo.bar@exemple.net est maintenant rejeté par la première correspondance.

Les changements sur les fichiers ne sont pas répercutés sur les daemons en cours d'exécution, autrement pour prendre en compte un changement sur ces fichiers il faut redémarrer Postfix ou exécuter la commande $ sudo postfix reload. Les fichiers typique relevant de cette catégorie sont : header_check, body_check et mime_header_check

Maps de type SQL (PostgreSQL, MySQL) et LDAP

--- T O D O : ...

Sources externes

--- T O D O : ...

2.1.5.  Les commandes Postfix

Au delà des commandes compatibles sendmail telles que sendmail, mailq, newaliases, le système Postfix dispose de son propre jeu de commandes, qui dans un soucis de cohérence, sont toutes nommés postcmd.

postfix

Cette commande réservée au super-utilisateur permet d'arrêter, de démarrer, de redémarer, de vérifier, ... le système Postfix.

postalias

Cette commande gère les bases de données d'alias du système Postfix. C'est ce programme qui est sollicité lors de l'exécution de la commande newaliases.

postcat

Cette commande permet d'afficher le contenu des files d'attente Postfix.

Par exemple,


$  mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
B26AC1CC37     1378 Wed Jan 04 21:26:37  pascal@seth.homeunix.net
           (connect to seth.homeunix.net[81.248.241.149]: Operation timed out)
                                         jpi@totor.net

-- 1 Kbytes in 1 Request.

Pour examiner le contenu du message dont l'identifiant est B26AC1CC37, on exécute la commande suivante :


$  sudo postcat -q  B26AC1CC37
Password:
*** ENVELOPE RECORDS deferred/B/B26AC1CC37 ***
message_size:            1378             146               1               0
message_arrival_time: Wed Jan 04 21:26:37 2006
sender_fullname: Corto Inc
sender: pascal@seth.homeunix.net
original_recipient: jpi@totor.net
recipient: jpi@totor.net
*** MESSAGE CONTENTS deferred/B/B26AC1CC37 ***
Received: by chuck.es.home (Postfix, from userid 666)
        id B26AC1CC37; Wed, 04 Jan 2006 21:26:37 +0400 (RET)
Date: Wed, 04 Jan 2006 21:26:37 +0400
From: Pascal <pascal@seth.homeunix.net>
To: jpi@totor.net
Subject: status of postfix delivery
Message-ID: <20060125172637.GA3873@chuck.tp-exemple.net>
Reply-To: pascal@seth.homeunix.net
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Organization: Corto Inc [K&M].
X-Operating-System: FreeBSD 6.0-RELEASE


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Bla ..
--=20

Rule of Silence: When a program has nothing surprising to say, it=20
should say nothing.
        [from TAOUP - EsR - http://www.catb.org/~esr/writings/taoup/]
---------------------------------------------------------------------
--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFD17TNyDInPaFxN4IRApc7AJ4hS1xzzF+avkD+NcHtyK8UfG0u+ACfc692
41ftXvHR6Hki8Pm+t/i0Zdc=
=1Rtr
-----END PGP SIGNATURE-----

--Kj7319i9nmIyA2yE--
*** HEADER EXTRACTED deferred/B/B26AC1CC37 ***
*** MESSAGE FILE END deferred/B/B26AC1CC37 ***

postconf

Cette commande permet d'afficher et de mettre à jour les informations du fichier main.cf. Elle permet aussi d'afficher des informations concernant les méthodes de vérouillage de fichiers ainsi que les types supportés pour les maps Postfix.

Un extrait de la configuration Postfix sur une machine FreeBSD :


$ postconf -v | less
postconf: dict_eval: const  chuck.es.home
postconf: dict_eval: expand $myhostname, localhost -> chuck.es.home, localhost
postconf: dict_eval: const  host
postconf: name_mask: ipv4
postconf: name_mask: host
postconf: inet_addr_local: configured 3 IPv4 addresses
postconf: been_here: 127.0.0.1/32: 0
postconf: been_here: 172.16.141.5/32: 0
postconf: mynetworks: 127.0.0.1/32 172.16.141.5/32 
2bounce_notice_recipient = postmaster
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map = 
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = postmaster
address_verify_service_name = verify
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = hash:/etc/aliases  mailbox file relative to a user's home directory. The default
alias_maps = hash:/usr/local/etc/postfix/aliases
allow_mail_to_commands = alias, forward
allow_mail_to_files = alias, forward
allow_min_user = no
allow_percent_hack = yes
allow_untrusted_routing = no
alternate_config_directories = 
always_bcc = 
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
...

postqueue

Cette commande est exécutée lors de l'utilisation de la commande sendmail, elle permet de stocker les messages dans la file maildrop.

postkick

Cette commande rend disponibles certains canaux de communication internes Postfix à des shell scripts par exemple.

postlock

Cette commande fournie un mécanisme de vérouillage compatible Postfix à des shell scripts par exemple.

postqueue

Cette commande fournie un mécanisme de logging compatible Postfix à des shell scripts par exemple.

postmap

Cette commande maintient les tables (maps) Postfix telles canonical, virtual ...

postqueue

Cette commande est exécutée par les commandes sendmail, mailq pour lister ou vider les files d'attentes Postfix.

Par exemple :

  • pour vider toutes les files d'attentes, on exécute : # postqueue -f équivalent formel à postfix flush.

  • pour lister le contenu des files d'attente, on exécute : # postqueue -p équivalent formel à mailq.

postsuper

Cette commande privilégiée (réservée au super-utilisateur) maintient les files d'attente Postfix. Elle peut être exécutée même si le processus Postfix n'est pas en cours d'exécution.

On l'utilise souvent pour supprimer un message d'une file d'attente :


$ sudo postsuper -d B26AC1CC37
Password:
postsuper: B26AC1CC37: removed
postsuper: Deleted: 1 message

2.2. [TP] Mise en œuvre d'un serveur SMTP uni-domaine

2.2.1. Principes

Postfix doit être en mesure de gérer le mail pour un domaine seul (tp-exemple.net). On supposera que l'hôte qui exécute les daemons Postfix fait la liaison entre un LAN et un WAN, qu'il est connecté de manière permanente au WAN et possèdent des adresses IPv4 statiques. On supposera, par ailleurs, que ce serveur possède des enregistrements DNS corrects de types A [forward record] et PTR [reverse record].

Figure 5. Réseau Postfix uni-domaine

Schéma de principe d'un serveur de mails Postfix uni-domaine.

Les étapes de principes sont les suivantes :

  1. Configurer Postfix pour les salutations (messages HELO/EHLO) ;

  2. Configuer Postfix pour qu'il accepte les mails du domaine tp-exemple.net ;

  3. Configuer Postfix pour qu'il rajoute le domaine tp-exemple.net au mail envoyé avec le nom d'utilisateur seul ;

  4. Configuer Postfix pour qu'il délivre les mails adressés à root à un autre compte ;

  5. Configuer Postfix pour qu'il délvre les mails envoyés aux adresses emails aux utilisateurs appropriés ;

  6. Définir les permissions de Postfix pour qu'il ne relaie que le mail du LAN.

  7. Tester la validité de la solution.

2.2.2. Mise en œuvre

[Note]Note

Lorsque Postfix transporte des messages vers d'autres serveurs de mails, il agit comme un client de mails.

La configuration principale de Postfix se fait dans le fichier main.cf qui se trouve selon la distribution soit dans /etc/postfix (Debian GNU/Linux, OpenBSD), soit dans /usr/local/etc/postfix (FreeBSD).

Paramétrer la bannière SMTP

Lors d'un échange client et serveur de mails commence leur dialogue ar des « salutations », ils se présentent en annonçant leurs noms DNS. Nous devons donc paramétrer le serveur Postfix pour qu'il se présente par son nom.

Il y deux manières (exclusives l'une de l'autre) de faire pour spécifier le nom avec Postfix : la première par le paramètre myhostname et la seconde par le paramètre mydomain


# /usr/local/etc/postfix/main.cf

myhostname = mail.tp-exemple.net

Postfix est dès lors en mesure d'en déduire le domaine (ici tp-exemple.net), il procède en éliminant la chaîne qui précède le premier point [dot].

La deuxième méthode consiste à paramétrer le domaine seul :


# /usr/local/etc/postfix/main.cf

mydomain = tp-exemple.net

Postfix est dès lors en mesure d'en déduire le nom de la machine, il utilise pour ce faire la commande uname -n

Paramétrer le domaine pour lequel le mail est accepté

Postfix va servir de relai pour notre réseau, autrement dit il va accepter le mail pour des domaines pour lesquels il n'est pas la destination finale. Dans notre cas cela signifie qu'il faut positionner le paramètre mydestination. Il va aussi servir à gérer tout le mail à destination du du domaine tp-exemple.net


# /usr/local/etc/postfix/main.cf

mydestination = $mydomain,
     $myhostname

Dans cet exemple, on montre qu'il est possible de séparer les valeurs en passant à la ligne. La seule contrainte à respecter est que la nouvelle ligne doit commencer par un caractère d'espacement, au moins (la valeur n'est pas reconnue sinon).

Plutôt que de « hard-coder » les valeurs, nous utilisons les variables internes (et renseignées) de Postfix.

Paramétrer le domaine qui doit être ajouté aux messages sortants

Les daemons locaux (par exemple cron) ou les utilitaire en ligne de commande (telle la commande mail) ne précisent pas (généralement) des adresses emetrices ou destinatrices complètes, le plus souvent il s'agit juste du nom de login (seul). Tant que la remise est strictement locale cela ne présente pas de problème, mais si le message est envoyé à un autre hôte, c'est problématique. Postfix dispose d'un paramètre qui peut être ajouté aux adresses émetrices ou destinatrices non totalement qualifiées : le paramètre myorigin lequel vaut par défaut $myhostname.


# /usr/local/etc/postfix/main.cf

myorigin = $mydomain

Rediriger le mail destiné au compte root vers une autre boîte

Postfix peut remettre le mail directement à tous les utilisateurs, y compris root, cependant Postfix ne donnera pas les privilèges root aux programmes externes pendant la remise du mail. Il n'est donc pas possible d'utiliser les LDAs (tels procmail ou maildrop) pour la remise de mails pour root, parce que Postfix, pour des raisons de sécurité, n'exécutera pas ces programmes avec les privilèges root, mais avec les droits d'un utilisateur par défaut tel que précisé par le paramètre default_privs (généralement nobody). Cela ne signifie pas qu'il n'est pas possible de remettre du mail à root. Pour se faire, il suffit de créer un compte sans privilèges particuliers qui recevra les mails destiné au compte root (notre compte sysop est fait pour cela).

Le paramètrage s'effectue dans le fichier $PREFIX/postfix/aliases (avec $PREFIX qui vaut /etc ou /usr/local/etc).


# /usr/local/etc/postfix/aliases

root:      sysop

Il faut alors recréer la version hashée de ce fichier $PREFIX/postfix/aliases.db, en exécutant la commande postalias hash:$PREFIX/postfix/aliases ou bien newaliases (sans paramètres).

Paramétrer le mappage des adresses email avec les comptes utilisateurs

Par défaut, Postfix ne remet le mail qu'aux utilisateurs du serveur de mails. Les noms d'utilisateurs (login) utilisés lors de la phase d'authentification précédent le relevé du mail, correspondent rarement aux nom utilisés dans les échanges d'emails, c'est pourquoi Postfix a besoin d'un mécanisme pour établir les correspondances : les alias.

Supposons que je veuille, d'une part, recevoir du mail avec les adresses suivantes : pascal@tp-exemple.net, pascal.picard@tp-exemple.net ou ppicard@tp-exemple.net et d'autre part, le mail à destination du groupe sysadmin (dont les autres membres sont Thierry et Diane). Mon login de connexion étant pascal. Il convient alors d'ajouter les entrées suivantes dans le fichier $PREFIX/postfix/aliases :


# /usr/local/etc/postfix/aliases

# users
ppicard:        pascal
pascal.picard:  pascal

# groups
sysadmin:       thierry, diane, pascal

Ne pas oublier de recréer la version hashée ($PREFIX/postfix/aliases.db), via par exemple la commande postalias hash:$PREFIX/postfix/aliases.

Définir les permissions pour le relai des emails

Le but ici est d'éviter de faire de Postfix un relai ouvert (open relays). PAr défaut, Postfix ne relaie que les messages provenant d'adresses IP internes au(x) réseau(x) au(x)quel(s) la machine est connectée (Postfix fait des vérification sur les interfaces réseaux de la machine). Tant que les machines et le serveur sont sur le même réseau cela ne pose pas de soucis, mais à mesure que la topologie du réseau s'agrandie et se complexifie, des changements sont à faire dans la configuration de Postfix.

Deux paramètres Postfix permettent de spécifier les permissions (en les restreignant ou en les expansant) : mynetworks_style (représentatif de la topologie du réseau : classe ...) et mynetworks (permettant de spécifier une liste d'adresses IP ou d'intervalles CIDR).

Permissions de relai génériques. Elles concernent le paramètre mynetworks_style, lequel peut prendre trois valeurs : class, subnet et host.

  • class : la restriction se fait alors sur la classe compléte (A, B ou C). A supposer que Postfix s'éxecute sur une machine d'addresse IPv4 : 172.17.1.141, alors avec ce paramètre mynetworks_style = class, Postfix fera confiance à tous les hôtes de la plage d'adresses (de classe B), i.e. 172.17.0.0/16 et il permettra le relayage.

  • subnet : la restriction se fait sur le sous-réseau dont fait partie Postfix. Si notre machine Postfix s'éxecute sur une machine dont l'adresse réseau est 172.17.1.141/25 et que le paramètre mynetworks_style = subnet, alors seuls les hôtes de ce sous-réseaux seront permis (i.e. intervalle [172.17.1.128, 172.17.1.254]).

  • host : la restriction se fait sur l'adresse IPv4 (y compris localhost) de l'hôte exécutant Postfix. Ainsi, si notre machine a toujours pour adresse 172.17.1.141/25, avec le paramètre mynetworks_style = host, alors les seules adresses relayées seront 172.17.1.141/32 et 127.0.0.1/32.

Permissions de relai individuelles. Le paramètre mynetworks permet l'ajustement individuel en spéciifant une liste d'adresses IPv4. Par exemple :


# /usr/local/etc/postfix/main.cf 

mynetworks = 172.17.1.128/25, 192.168.1.0/24, 127.0.0.0/8

Si la liste devient (très) longue, il vaut mieux la placer dans un fichier à part, référencé ainsi dans $PREFIX/etc/postfix/main.cf, mynetworks = hash:$PREFIX/postfix/mynetworks, attention cependant dans ce cas la notation CIDR n'est pas supportée. Si on a besoin de cette notation, il convient d'utiliser un autre format : mynetworks = cidr:$PREFIX/postfix/mynetworks.

2.2.3. Tests

Démarrer, recharger une configuration et arrêter Postfix

Démarrer. Sous FreeBSD, le démarrage se fait, par (on doit évidemment ajouter la ligne ci-contre postfix_enable="YES" dans le fichier de configuration canonique /etc/rc.conf) :


$ sudo /usr/local/etc/rc.d/postfix start
postfix/postfix-script: starting the Postfix mail system

Rechargement. Si Postfix est déjà démarré, la prise en compte des changements de configuration dans le fichier $PREFIX/etc/postfix/main.cf se fait par l'option reload ; sous FreeBSD :


$ sudo /usr/local/etc/rc.d/postfix reload
Reloading postfix config files.

Arrêter. Sous FreeBSD :


$ sudo /usr/local/etc/rc.d/postfix stop
postfix/postfix-script: stopping the Postfix mail system

mails pour le compte root

Utilisation de la commande sendmail de PostfixOn tape la séquence suivante :


# echo "test email for root" | /usr/sbin/sendmail -f root root && tail -f /var/log/maillog

Aug 14 20:52:43 chuck postfix/pickup[3806]: C8C3261CE4: uid=0 from=<root>
Aug 14 20:52:43 chuck postfix/cleanup[3938]: C8C3261CE4: message-id=<20060814165243.C8C3261CE4@mail.tp-exemple.net>
Aug 14 20:52:43 chuck postfix/qmgr[3807]: C8C3261CE4: from=<sysop@mail.tp-exemple.net>, size=304, nrcpt=1 (queue active)
Aug 14 20:52:43 chuck postfix/local[3941]: C8C3261CE4: to=<sysop@mail.tp-exemple.net>, orig_to=<root>, relay=local, delay=0.04, delays=0.02/0.01/0/0.01, dsn=2.0.0, 
status=sent (delivered to command: /usr/local/bin/procmail -f %F - ${HOME}/.procmailrc)
Aug 14 20:52:43 chuck postfix/qmgr[3807]: C8C3261CE4: removed

Le mail peut être lu via le MUA mutt (par exemple) :


From root  Mon Aug 14 20:52:43 2006
Return-Path: <sysop@mail.tp-exemple.net>
X-Original-To: root
Delivered-To: root@mail.tp-exemple.net
Received: by mail.tp-exemple.net (Postfix, from userid 0)
        id C8C3261CE4; Mon, 14 Aug 2006 20:52:43 +0400 (RET)
Message-Id: <20060814165243.C8C3261CE4@mail.tp-exemple.net>
Date: Mon, 14 Aug 2006 20:52:43 +0400 (RET)
From: sysop@mail.tp-exemple.net (Charlie Root)
To: undisclosed-recipients:;
Status: RO
Content-Length: 20
Lines: 1

test email for root

[Note]Note

[FreeBSD] Nous utilisons bien la commande sendmail de Postfix. A l'installation de ce paquetage, les commandes du programme sendmail sont « remplacées » par les équivalents Postfix.

Test distant. On effectue ce test avec la commande telnet, on préfère ici en prenant un outils de bas niveau se passer (certes du confort, mais aussi) des clients de mails boggués.

$ telnet mail.tp-exemple.net 25

Trying 172.16.1.141...
Connected to mail.tp-exemple.net.
Escape character is '^]'.
220 mail.tp-exemple.net NO UCE ESMTP Postfix
HELO chuck.tp-exemple.net
250 chuck.tp-exemple.net
MAIL FROM: <pascal@mail.tp-exemple.net>
250 2.1.0 Ok
RCPT TO: <root@mail.tp-exemple.net>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Ceci est un test
Et une autre ligne
.
250 2.0.0 Ok: queued as 3EB6F61C35
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Une vérification via mutt, compte sysop (ou à défaut dans /var/mail/sysop) :


From pascal@chuck.tp-exemple.net  Mon Aug 14 21:19:53 2006
Return-Path: <pascal@chuck.tp-exemple.net>
X-Original-To: root@mail.tp-exemple.net
Delivered-To: sysop@mail.tp-exemple.net
Received: from chuck.tp-exemple.net (mail.tp-exemple.net [172.16.1.141])
        by mail.tp-exemple.net (Postfix) with SMTP id 3EB6F61C35
        for <root@mail.tp-exemple.net>; Mon, 14 Aug 2006 21:18:29 +0400 (RET)
Message-Id: <20060814171912.3EB6F61C35@mail.tp-exemple.net>
Date: Mon, 14 Aug 2006 21:18:29 +0400 (RET)
From: pascal@chuck.tp-exemple.net
To: undisclosed-recipients:;

Ceci est un test
Et une autre ligne

2.3. [TP] Mise en œuvre d'un serveur SMTP uni-domaine sur une liaison WAN intermittente

Le but ici est de configurer un serveur Postfix sur un réseau interne qui centralise le dépôt de tous les mails vers des destinations externes. A chaque connexion sur le WAN (Internet) notre serveur remettra l'ensemble des messages au relai (du FAI [ISP]), pour les utilsateurs authentifiés.

Les serveurs de mails exterieurs ne peuvent pas directement nous délivrer les messages dans la mesure où notre connexion n'est qu'intermittente. C'est donc le FAI qui stockera les messages jusqu'à ce qu'un client POP ou IMAP (ou fetchmail) le retire pour le remettre au MTA local ou ...

Figure 6. Réseau Postfix uni-domaine avec connexion WAN intermittente

Schéma de principe d'un serveur Postfix uni-domaine avec liaison WAN intermittente.

2.3.1. Etapes de principe

  1. Désactiver la résolution DNS.

  2. Vérifier les permissions de relai de notre machine (mynetworks), éviter de devenir un relai ouvert !

  3. Définir le relai externe.

  4. Reporter la remise des messages sortants (defer_transports).

  5. Déclencher la remise des messages, lors d'une connexion au WAN (voir le /etc/ppp/ppp.linkup ou équivalent se déclenchant lors de l'établissement de la connexion ppp).

  6. Configurer les permissions de relai du relai (pop avant smtp, ou imap avant smtp ou authentification smtp).

2.3.2. Eléments de correction

2.4. Restrictions sur le transfert de messages

2.4.1. Principes

Voici la liste des groupes de restrictions Postfix :

  • smtpd_client_restrictionsS'applique sur l'adresse IP ou sur le nom d'hôte ou sur les deux à la fois (du client). Par défaut, Postfix autorise tous les clients.

  • smtpd_helo_restrictionsS'applique sur l'argument de la commande HELO/EHLO du client et sur l'adresse IP ou sur le nom d'hôte ou sur les deux à la fois. Par défaut, Postfix autorise tous les arguments.

  • smtpd_sender_restrictionsS'applique sur l'expéditeur de l'enveloppe, sur l'argument de la commande HELO/EHLO et sur le client. Par défaut, Postfix autorise tous les expéditeurs à envoyer des messages.

  • smtpd_recipient_restrictionsS'applique sur le destinataire d'enveloppe, l'expéditeur de l'enveloppe, sur l'argument de la commande HELO/EHLO et sur le client (adresse IP ou sur le nom d'hôte ou sur les deux à la fois). Par défaut, Postfix autorise toutes les destinations pour les clients membres du réseau défini par le paramètre mynetworks et sinon de permettre les seules destinations définies par le paramètre relay_domains et ceux de mydomains. Cela permet d'éviter que Postfix soit un relai ouvert.

  • smtpd_data_restrictionsPermet de détecter les clients qui envoit leutr données avant que Postfix n'est répondu à la commande DATA. Pas de restriction par défaut.

  • smtpd_etrn_restrictionspermet de restreindre les clients qui demande à Postfix de flusher la file d'attente des mails. Par défaut, Postfix autorise tous les clients à envoyer des comandes ETRN.

Figure 7. Etapes classiques de la communication SMTP entre un client et un serveur, restrictions Postfix

Etapes classiques de la communication SMTP entre un client et un serveur et rectrictions Postfix.


Types de groupes de restrictions

Postfix propose de nombreuses restrictions que l'on peut classifier dans 4 groupes présentés ci-dessous.

Groupe de restriction générique. 

  • permitPermettre une requête.

  • deferDifférer une requête.

  • rejectRejeter une requête.

  • warn_if_rejectSi une restriction placée après ce paramètre conduit à un rejet, alors Postfix imprime un message reject_warning dans un log plutôt que de rejeter réellement le message.

  • reject_unauth_pipeliningRejete la requête quand le client envoit des commandes SMTP en ignorant que Postfix supporte réellement le pipelining de commandes ESMTP. Cela permet de stopper les logiciels de mails qui utilisent de manière inadéquate le pipelining de commandes ESMTP pour accélerer leurs envois.

Groupe de restrictions commutables. Ces restrictions sont activables ou désactivables. Une fois activée un tel commutateur vérifie si une condition est remplie. Dans ce qui suit, nous en présentons quelques uns.

  • smtpd_helo_requiredCette restriction requiert du client l'envoi d'une commande HELO ou EHLO en début de session SMTP, conformément aux standards définis par les RFCs 821 et 2821.

  • strict_rfc821_envelopesCette restriction permet l'ajustement de tolérance de Postfix vis-à-vis des erreurs dans les adresses communiquées avec les commandes MAIL FROM et RCPT TO. Malheureusement le programme sendmail™ (très répandu) tolère des comportements non standards qui ont conduit à la prolifération de clients de mails peu regardant quant aux standards. Aussi, cette restriction permet de stopper tout mail non voulu mais a pour effet de bord de stopper des mails légitimes provenant de clients mal écrit.

  • disable_vrfy_commandLa commande SMTP VRFY autorise un client à s'assurer que le destinataire existe. Cette restriction permet de désactiver cette commande.

  • allow_percent_hackCette restriction contrôle les ré-écritures de la forme user%domain en user@domain.

  • swap_bangpathCette restriction contrôle les ré-écritures de la forme user!domain [UUCP] en user@domain

Groupe de restrictions personnalisables. Ces restrictions sont des tables fonctionnant comme des filtres. Chaque entrée comporte une clé (de filtrage) et une valeur (action à entreprendre si le filtre est applicable) associée. En voici quelques exemples :

  • HELO/EHLO hostname restrictionsLimitattion sur le nom d'hôte qui suit la commande HELO/EHLO.

  • Client hostname/address restrictionsLimiter les clients susceptibles d'établir une communication SMTP avec le serveur de mails.

  • Sender address restrictionsLimiter les addresses d'expéditeur (d'enveloppes) que Postfix accepte avec la commande MAIL FROM.

  • Recipient address restrictionsLimiter les addresses de destinations (d'enveloppes) que Postfix accepte avec la commande RCPT TO.

  • ETRN command restrictionsLimiter les clients susceptibles d'utiliser les commandes ETRN.

  • Header filteringLimiter ce qui est autorisé dans les entêtes du message. Les motifs sont applicables sur les entêtes logiques complets même si ceux-ci s'étendent sur plusieurs lignes physiques.

  • Body filteringRestreindre le texte qui peut apparaître dans les lignes du corps.

  • DNSBL-style blacklistsRestreindre les connections des clients dont les adresses IP sont référencées dans les DNSBL-style blacklists.

  • RHSBL-style blacklistsInterdire les expéditeurs dont le domaine (enveloppe d'expéditeur) est référencé dans les RHSBL-style blacklists.

Paramètres de contrôle UCEUCE signifie Unsolicited Commercial Emails. Permet d'introduire de nouvelles restrictions ne faisant pas partie des restrictions standards de Postfix. Nous en listons quelques unes dans ce qui suit :

  • default_rbl_replyPermet de définir un modèle de réponse à utiliser quand la requête d'un client SMTP est bloquée par la restriction reject_rbl_client ou reject_rhsbl_sender.

  • permit_mx_backup_networksLimiter l'utilisation du permit_mx_backup pour les destinations dont les premiers hôtes MX correspondent à une liste de réseaux bloqués.

  • rbl_reply_mapsSpécifie les tables de recherche (indéxées par domaine DNSBL) avec les modèles de requêtes DNSBL. Si aucun modèle n'est trouvé, Postfix utilise le modèle default_rbl_reply.

  • relay_domainsInforme Postfix d'accepter le mail pour ces domaines, même si le serveur n'est pas la destination finale.

  • smtpd_sender_login_mapsSpécifier l'utilisateur autorisé à utiliser une adresse spécifique d'expéditeur d'enveloppe (MAIL FROM). Pour utiliser cette restriction, Postfix doit donc connaître le nom d'utilisateur ce qui suppose que le client se soit identifié lors de la phase d'authentification SMTP.

Portée d'applications des restrictions. Pour utiliser correctement les restrictions il est impératif de bien connaître à quelle étape de la communication SMTP on peut les appliquer. Certaines restrictions n'ont pas de sens pour certaines étapes. Nous explicitons dans le tableau suivant les restrictions par étape :

Tableau 5.  Portée d'applications des groupes de restrictions

Etape Restrictions
Client (adresse IP et/ou nom d'hôte)

check_client_access

reject_rbl_client

reject_rhsbl_client

reject_unknown_client

HELO/EHLO hostname

check_helo_access

permit_naked_ip_address

reject_invalid_hostname

reject_non_fqdn_hostname

reject_unknown_hostname

Envelope Sender

check_sender_access

reject_non_fqdn_sender

reject_rhsbl_sender

reject_unknown_sender_domain

reject_unverified_sender

Envelope Recipient

check_recipient_access

reject_auth_destination

reject_mx_backup

reject_non_fqdn_recipient

reject_unauth_destination

reject_unknown_recipient_domain

reject_unverified_recipient

DATA

reject_unauth_pipelining


Construire des restrictions

Avertissement et conseils. Les restrictions peuvent devenir complexes et entraîner un dysfonctionnement (subtile ou non) du serveur de mails si elles sont manipulées/« triturées » sans connaissance suffisante. Voici quelques règles à garder en tête quand on construit des restrictions :

  • Attention à l'étape d'évaluation.

  • L'ordre d'apparition des restrictions dans un groupe est significatif. Les premières actions influencent la manière dont les restrictions suivantes sont évaluées.

  • Une notation brouillone rend les rectrictions ineffectives.

Notation. Les notations suivantes sont équivalentes :


restriction_trigger = conditional_restriction, customizable_restriction \
maptype:/path/to/the/map, general_restriction

ou bien :


restriction_trigger = 
    conditional_restriction, 
    customizable_restriction maptype:/path/to/the/map, 
    general_restriction

ou encore (sans les virgules qui sont optionnelles) :


restriction_trigger = 
    conditional_restriction
    customizable_restriction maptype:/path/to/the/map
    general_restriction

Evaluation. 

Influence des actions sur l'évaluation des restrictions. 

Ralentir les « sales » [bad] clients. 

2.4.2. Mise en œuvre

2.4.3. Tests

2.5. [TP] Passerelle de mails

Une passerelle de mails qu'on nomme aussi un smarthost est un serveur qui connecte différents réseaux logiquement séparés. Classiquement, cette passerelle apparaît comme la destination finale, du point de vue des enregistrements DNS pour les autres serveurs de mails de l'Internet au point que ces derniers n'ont aucune idée de qu'il y a reéllement derrière cette passerelle. Les FAI [ISP] et autres compagnies utilisent des smarthosts pour contrôler le trafic SMTP entrant dans/sortant de leur réseau. Le trafic a destination du port 25 (port SMTP) est redirigé vers le(s) smarthost(s), le(s) firewalls bloque(nt) et redirige(nt) le trafic, tandis que le(s) smarthost(s) relaye(nt) les emails.

2.5.1. Une mise en œuvre simple

Postfix s'exécute sur un hôte accessible de l'exterieur et il relaie le mail destiné à certains domaines vers un autre serveur de mails interne. Les étapes de principe du paramètrage du smarthost sont les suivantes :

  1. Permettre au serveur de mails interne d'utiliser la passerelle comme relai.

  2. Définir le(s) domaine(s) pour le(s)quel(s) les mails seront relayés en interne (paramètre relay_domains).

  3. Définir l'hôte pour lequel les mails seront relayés (paramètre relayhost).

  4. Définir les destinataires [recipients] qui seront relayés en interne (paramètre relay_recipient_maps).

Permission sur le smarthost

Supposons que le serveur de mails interne possède l'adresse IPv4 192.168.100.2, alors on positionne le paramètre mynetworks dans le fichier main.cf du smarthost :

# main.cf

mynetworks = 127.0.0.1/8, 192.168.100.2/32

En limitant l'accès au smarthost à l'adresse locale (localhost) et au serveur de mails interne, toutes les autres machines du réseau interne ne peuvent pas utiliser le smarthost comme relai (elles devront passer par le serveur interne).

Définir le(s) domaine(s) de relai sur le smarthost

Il s'agit ici d'indiquer au smarthost d'accepter le mail en provenance d'un réseau extérieur pour un hôte du réseau interne et ce même si le smarthost n'est pas la destination finale pour le(s) domaine(s). Postfix dispose pour cela du paramètre relay_domains. Si on veut relayer le mail pour le domaine tp-exemple.net, on l'indique de cette manière dans le fichier main.cf du smarthost :

# main.cf

relay_domains = tp-exemple.net

Définir le serveur interne sur le smarthost

Maintenant que le smarthost sait qu'il doit accepter le mail pour un domaine donné, il faut lui indiquer où il doit le remettre, et donc préciser l'hôte interne effectif. Dans le cas où le smarthost doit remettre le mail à destination du domaine tp-exemple.net à la machine (interne) mailer.tp-exemple.net, on doit adopter la démarche suivante :

  • Créer un fichier transport map, $PREFIX/etc/postfix/transport, contenant :

    # $PREFIX/etc/postfix/transport
    
    tp-exemple.net     smtp:[mailer.tp-exemple.net]
    
    

    Le paramètre smtp indique le protocole utilisé. Les crochets sont importants, ils empêchent le smarthost de faire une requête de type MX sur le domaine, laquelle répondrait sûrement en indiquant le smarthost lui même et du coup on aurait une boucle dans la remise !

  • Il faut ensuite créer la version indexée de ce fichier, en faisant :

    
    $ sudo postmap hash:$PREFIX/etc/postfix/transport
    
    

  • Et finalement, référencer cette « map » dans le fichier main.cf (du smarthost) :

    # main.cf
    
    transport_maps = hash:$PREFIX/etc/postfix/transport
    
    

Définir les destinataires du domaine

Une passerelle classique accepte tous les messages pour toutes les destinataires qu'ils existent (ou soient valides) ou non. Le smarthost peut obtenir la liste des destinataires valides par le(s) serveur(s) interne(s). Le paramètre à utiliser dans ce cas est relay_recipient_maps. A supposer que la liste des utilisateurs valides soit définie dans le fichier hash:$PREFIX/etc/postfix/relay_recipients, on l'ajoute alors dans le fichier main.cf :

# main.cf

relay_recipient_maps = hash:$PREFIX/etc/postfix/relay_recipients

Typiquement cette map hashée contiendra des lignes de ce type :

# $PREFIX/etc/postfix/relay_recipients

pascal@tp-exemple.net     OK
jacques@tp-exemple.net    OK
#
joe@tp-exemple.net        554 Delivery not permitted

2.5.2. Améliorer la sécurité de la passerelle de mails

Il s'agit ici de désactiver complètement la remise sur le smarthost.

  1. Indiquer à Postfix qu'il n'est pas la destination finale en positionnant le paramètre mydestination (à vide) comme suit :

    # main.cf
    
    mydestination = 
    
    

  2. Positionner le paramètre local_recipient_maps à vide pour empêcher Postfix de faire des recherches sur les destinataires locaux :

    # main.cf
    
    local_recipient_maps = 
    
    

  3. Le positionnement du paramètre précédent à vide désactive tous les desstinataires locaux, cependant notre passerelle doti rester conforme aux RFCs, il faut donc faire suivre les adresses pour les destinataires postmaster et abuse vers le serveur interne.

    Il faut créer une map qui correpsondra au paramètre virtual_alias_maps, par exemple sous le nom $PREFIX/etc/postfix/virtual et contenant :

    # $PREFIX/etc/postfix/virtual
    abuse           abuse@tp-exemple.net
    postmaster      postmaster@tp-exemple.net
    
    

    Comme d'habitude, il convient d'en faire une version hashée postmap hash:$PREFIX/etc/postfix/virtual que l'on référencera dans le fichier main.cf du smarthost :

    # main.cf
    
    virtual_alias_maps = hash:$PREFIX/etc/postfix/virtual
    
    

  4. Indiquer aux clients qui tenteraient de remettre du mail au smarthost que la remise locale est désactivée par le paramètre local_transport. La ligne suivante permet d'envoyer tous les messages locaux au daemon error :

    # main.cf
    
    local_transport = error:local mail delivery is disabled 
    
    

  5. La configuration obtenue jusqu'ici ne permet la remise locale qu'aux utilisateurs abuse et postmaster. Cependant les daemons locaux (tels cron ...) continuent d'utiliser Postfix pour leur envoi de mails en utilisant des adresses faisant référence au nom d'hôte du smarthost. En changeant le paramètre myorigin que Postfix ajoute comme domaine aux adresses emails et en le positionnant au domaine possédant un serveur de mails (et à condition que celui possède les boîtes et alias pour ces comptes) on peut empêcher les utilisateurs de répondre à ces applications, ici on indique :

    # main.cf
    
    myorigin = tp-exemple.net
    
    

  6. Enfin, on peut empêcher le master daemon de démarrer l'agent de remise locale, en commentant la ligne le concernant dans le fichier $PREFIX/etc/postfix/master.cf :

    # master.cf
    
    # ==========================================================================
    # service type  private unpriv  chroot  wakeup  maxproc command + args
    #               (yes)   (yes)   (yes)   (never) (100)
    # ==========================================================================
    smtp      inet  n       -        n       -       -       smtpd
    pickup    fifo  n       -        n       60      1       pickup
    tlsmgr    unix  -       -        n       1000?   1       tlsmgr
    showq     unix  n       -        n       -       -       showq
    error     unix  -       -        n       -       -       error
    #local     unix  -       n       n       -       -       local
    ...
    
    

Après le rechargement de la configuration de Postfix ce dernier n'acceptera plus de remise locale.

2.6. [TP] Serveur de mails multi-domaines

c.f. séances.



[1] Elles ne servent pas seulement là où doivent aller les messages, mais permettent d'imposer des restrictions et vérifications sur les différents paramètres du message.