Postfix

Ce billet n’est certainement pas destiné aux administrateurs expérimentés de Postfix.
Il s’agit seulement d’aider ceux qui, notamment dans une petite entreprise, ont besoin d’un serveur mail interne pour par exemple :
- disposer d’une (ou plusieurs) boîte(s) à lettres interne(s) pour recevoir divers messages et notifications envoyés par d’autres serveurs internes : Apache, Nagios, ou autre;
- utiliser ce Postfix en relais SMTP pour envoyer des courriels fabriqués par un programme informatique.

Ce qui suit suppose :
- un Postfix installé sur une distribution Ubuntu récente;
- un réseau local accédant à internet par une connexion fournie par le FAI Orange.

Lors de l’installation du paquet Postfix (ou lors d’une reconfiguration, avec la commande dpkg-reconfigure postfix), le choix est entre :
- pas de configuration,
- « Site Internet » : ce Postfix sera un serveur mail. Mais, vers l’extérieur, la plupart des hébergeurs de boîtes à lettres refusent les courriels ne provenant pas d’un nom de domaine déposé : le plus simple est alors de s’appuyer sur un relais SMTP « honorablement connu », généralement celui de son FAI;
- « Site Internet avec un smarthost » : ce Postfix sera un serveur mail, utilisant un relais SMTP pour envoyer des courriels à l’extérieur.
- « Système satellite » : ce Postfix ne sera qu’un relais SMTP, par exemple vers l’extérieur.

Les questions alors posées à la suite de ce choix concernent quelques paramètres de configuration de Postfix, qu’on peut bien sûr définir aussi manuellement. Dans ce qui suit, on choisit « Internet avec un smarthost ».

1) Nom de courrier
C’est le nom de domaine qualifié du réseau interne, où se trouve ce serveur Postfix, par exemple : domaine_interne.com

2) Serveur relais SMTP
A ce stade, on saisit ici le nom du serveur SMTP d’Orange, entre [ ] : [smtp.orange.fr]
Il faut bien sûr que le serveur DNS utilisé par ce Postfix ne soit pas seulement une autorité pour le réseau local (domaine_interne.com), mais aussi un DNS cache pour les résolutions d’adresses extérieures.

3) Destinataire des courriels pour « root » et « postmaster ».
Il faut définir un autre destinataire que le « root », auxquels sont souvent envoyés des courriels par différents serveurs internes, par exemple Apache. Il est en effet déconseillé d’adresser réellement ces courriels à l’administrateur du système (compte « root ») hébergeant ce Postfix.
Il faut aussi définir un destinataire pour les courriels adressés à « postmaster » sinon ils seront enregistrés dans /var/mail/nobody, ce qui risque de les laisser inexploités. Or créer un compte d’utilisateur postmaster est peut-être d’une lourdeur inutile, d’autant que :
- on peut aussi recevoir d’autres courriels similaires, adressés à des destinataires de même nature, mais avec des noms légèrement différents,
- on souhaite généralement réunir tous ces courriels et les lire en se connectant avec un unique compte, sans avoir à se faire passer successivement pour un grand nombre d’utilisateurs de type « informatique ».
Le plus simple est alors de destiner tous ces courriels à un compte d’utilisateur du serveur Linux hébergeant ce Postfix, par exemple un compte appelé « informatique » : si, pour la réception des courriels, ce compte « informatique » est utilisé à la place par exemple de « root », ce compte « informatique » est alors appelé un « alias » de « root ». On peut définir des aliases pour tous les comptes utilisateurs du serveur Linux utilisé.
Cette redirection s’appuie sur le fichier /etc/aliases. A la réception d’un courriel destiné à l’utilisateur user1, Postfix l’enregistre dans le dossier /var/mail/user1/, sauf si le fichier /etc/aliases contient une entrée pour cet utilisateur user1 : dans ce cas le courriel est déposé dans le dossier /var/mail/alias_user1/, où alias_user1 est l’alias du compte >user1.
En fait, le fichier utilisé est /etc/aliases.db, qui se déduit du fichier /etc/aliases :
- /etc/aliases est un fichier texte, modifiable manuellement, dont chaque ligne a la structure :
nom_utilisateur: alias
(un « : » accolé au nom, puis au moins un espace, puis l’alias)
- si on a modifié manuellement /etc/aliases, il faut alors mettre à jour le fichier /etc/aliases.db par la commande newaliases (aucun paramètre n’est nécessaire),
- et penser alors à recharger la configuration de Postfix, par la commande : /etc/init.d/postfix reload
Si par exemple le compte « informatique » doit être un alias de « root » et de « postmaster », on peut organiser le fichier /etc/aliases comme suit :
postmaster: root
root: informatique
En cas de plusieurs autres comptes de type « postmaster », il est donc pratique de :
- tous les rediriger vers « root »,
- et définir ensuite « informatique » en tant qu’alias de « root » : changer « informatique », l’alias final de tous ces comptes, ne nécessiterait alors que de modifier une seule ligne du fichier /etc/aliases.
Ces fichiers de type /etc/aliases et /etc/aliases.db ne sont pas seulement utilisés par Postfix : d’autres logiciels de mail, comme Sendmail, utilisent aussi ce système. Par ailleurs, pour Postfix, le nom et l’emplacement de ces fichiers peuvent être ajustés manuellement, dans le fichier de configuration de Postfix appelé /etc/postfix/main.cf.

Dans la version de Postfix utilisée pour écrire ce billet, le script de configuration de Postfix prétend mettre à jour le fichier /etc/aliases :
- il définit automatiquement « root » en tant qu’alias de « postmaster »,
- et il demande de saisir un alias pour « root ». Mais il n’écrit pas cet alias dans le fichier /etc/aliases, même si cet alias correspond à un compte d’utilisateur existant déjà.
Il faut donc laisser ce script n’effectuer qu’une partie du travail annoncé, puis créer éventuellement cet autre compte d’utilisateur et le définir manuellement dans /etc/aliases, en tant qu’alias de « root » (penser alors à mettre à jour le fichier /etc/aliases.db).

4) Domaines pour lesquels ce Postfix acceptera le courrier
Vérifiez que cette liste contient bien le nom de votre réseau local saisi au 1), que devrait alors vous proposer ici le script de configuration. Laisser les autres noms de type « localhost ».

5) Synchronisation de la file d’attente
Laisser la valeur par défaut.

6) Réseaux pour lesquels ce Postfix relaiera le courrier
NB : un réseau de classe C, par exemple 192.168.1.x, s’écrira ici 192.168.1.0/24
Attention : ce billet n’envisage pas le cas où ce Postfix serait accessible de l’extérieur (connexion SMTP entrante). Dans un tel cas, il faudrait prendre toutes les mesures de sécurité nécessaires pour éviter d’en faire un relais SMTP « ouvert », qui risquera alors d’être « blacklisté ».

7) Utiliser ou non procmail pour la distribution locale
Procmail sert, lors de la réception des courriels, à automatiser diverses opérations de tri, de classement, ou de réponses automatisées : à voir, selon la nature et le volume des courriels que recevra ce Postfix.

8) Taille maximale des boîtes aux lettres de ce Postfix

9) Caractère définissant une extension d’adresse locale
Laisser la valeur par défaut.

10) Protocole(s) internet à utiliser

 

A ce stade, on peut tester cette configuration de Postfix avec un compte d’utilisateur sur le serveur hébergeant ce Postfix, et par exemple le client mail mutt (inutile de créer le dossier proposé au lancement de mutt) :
- se connecter sous un compte d’utilisateur autre que « root », et s’envoyer à soi-même un courriel;
- se connecter aussi au compte d’utilisateur correspondant à l’alias de « root » défini à l’étape 3) ci-dessus, et envoyer des courriels entre ce compte d’utilisateur et celui utilisé ci-dessus.
Vérifier notamment que des courriels envoyés à root@domaine_interne.com et postmaster@domaine_interne.com parviennent bien aux aliases définis à l’étape 3).

Pour tester ensuite ce Postfix en tant que relais SMTP, le mieux est d’utiliser un client mail distant (Thunderbird, Mail de Mac OS X, Outlook, etc) paramétré avec une adresse mail de retour qui sera acceptée : le serveur SMTP d’Orange rejette les courriels dont l’adresse de retour n’appartient pas à un domaine qu’il connaît.
Sur le client mail distant utilisé, il suffit donc de modifier le paramétrage d’une boîte aux lettres hébergée chez Orange, en remplaçant le serveur SMTP habituel par ce Postfix. Le test consistera à envoyer un courriel à partir de cette boîte à lettres, mais donc « en passant » par le Postfix.

Le problème, concernant le SMTP d’Orange, c’est qu’il nécessite une identification si les 2 conditions suivantes ne sont pas réunies :
- utilisation d’une connexion internet de ce FAI,
- résolution d’adresse en utilisant un serveur DNS de ce FAI : or, si on utilise par ailleurs un serveur DNS cache pour les résolutions d’adresses extérieures, il est vraisemblable qu’il s’appuiera plutôt sur des DNS « racines ».

On peut s’en convaincre en envoyant un courriel manuellement, par une session telnet, quel que soit l’ordinateur utilisé (un ordinateur distant, ou le serveur hébergeant Postfix).
Si l’ordinateur utilisé est configuré pour que les résolutions de noms (à l’extérieur du domaine domaine_interne.com) utilisent les DNS d’Orange, il suffit d’ouvrir une session telnet avec le serveur smtp.orange.fr, sur le port tcp standard (port 25, donc inutile de le préciser en paramètre de la commande telnet) :
commande : telnet smtp.orange.fr
réponse : 220 mwinf5d44 ESMTP server ready (ou quelque chose d’approchant)
commande : helo c’est moi (le nom que vous vous attribuez ici n’a aucune importance)
réponse : 250 mwinf5d44 hello [xxx.xxx.xxx.xxx], pleased to meet you (xxx.xxx.xxx.xxx est votre adresse ip sur internet, donc celle « du côté extérieur » de votre passerelle vers internet)
Vous pouvez alors envoyer votre courriel :
commande : mail from: adresse@orange.fr adresse » est une de vos boîtes à lettres fournie et hébergée par ce FAI)
réponse : 250 2.1.0 <adresse@orange.fr> sender ok (Orange vous a reconnu comme étant un émetteur « honorable » de courriel)
commande : rcpt to: autre_adresse@destination.fr
réponse : 250 2.1.5 <autre_adresse@destination.fr> recipient ok (mais Orange ne garantit évidemment pas que votre mail ainsi rédigé manuellement ne sera pas considéré comme étant du « spam » chez votre destinataire…)
commande : >data
réponse : 354 enter mail, end with “.” on a ligne by itself
Pour la suite, il s’agit donc d’un envoi de mail classique par telnet…

Mais si vos résolutions de noms (à l’extérieur du domaine domaine_interne.com) n’utilisent pas les DNS d’Orange :
- mais par exemple ceux de Google,
- ou un serveur DNS interne en mode « cache», qui s’appuierait sur les DNS « racines »,
alors la session ci-dessus ne sera pas permise, car il faudra vous identifier après la réponse du SMTP d’Orange à votre « helo ».
Cette identification prend la forme d’échanges de messages avec le serveur SMTP d’Orange, des messages codés – dans les deux sens – en Base64. Ceci vous oblige à préparer un peu à l’avance votre session telnet, en notant le résultat ainsi codé du nom d’utilisateur et du mot de passe associé d’une de vos boîtes à lettres fournie et hébergée par Orange. Ce login n’est pas nécessairement celui de la boîte à lettres que vous utilisez en tant qu’émetteur de ce mail : vous pouvez utiliser le login de n’importe laquelle de vos boîtes à lettre ouvertes chez Orange.
On trouve aisément sur internet divers utilitaires permettant de coder et de décoder en Base64. Le site http://www.dcode.fr/base-64, parmi d’autres, offre aussi ces opérations en ligne.
Un conseil : si, pour obtenir de l’aide, vous postez sur un forum le log d’un envoi de mail (que ce soit par telnet, par Postfix, ou autre), n’oubliez pas de cacher votre login : n’importe quel utilisateur de ce forum saura décoder en Base64 ce login…

Par telnet, l’identification (après la réponse d’Orange à votre « helo ») se déroule ainsi :
commande : auth login
réponse : 334 VXNlcm5hbWU6 (autrement dit, « username: » codé en Base64)
commande : XXXXXXXXXXX (votre nom d’utilisateur, codé en Base64)
réponse : 334 UGFzc3dvcmQ6Password: » codé en Base64)
commande : YYYYYYYYYYY (votre mot de passe, codé en Base64)
réponse : 235 2.7.0 … authentification succeeded
Vous pouvez ensuite envoyer votre courriel, comme lors de la session telnet précédente.

La configuration de Postfix issue du script d’installation de Postfix décrit ci-dessus permet d’utiliser en relais le SMTP d’Orange si :
- on utilise une connexion internet fournie pas ce FAI,
- le serveur Postfix effectue des résolutions de noms (externes à domaine_interne.com) en utilisant les DNS d’Orange.

Si une de ces 2 conditions n’est pas remplie, ce qui suit permet alors de configurer Postfix pour qu’il utilise Orange en relais SMTP, avec identification : vous utiliserez pour ce faire le login d’une de vos boîtes à lettres fournies et hébergées par ce FAI.

La méthode d’identification exposée ci-dessus au cours de la seconde session telnet a été standardisée sous le nom de Simple Authentification and Security Layer (SASL). Les implémentations les plus connues de ce mécanisme sont :
- GNU SASL
- Cyrus SASL
- Dovecot SASL
Cyrus est un serveur IMAP, et Dovecot est un serveur POP3 et IMAP. Pour relever son courrier auprès de tels serveurs, l’identification généralement nécessaire se fait aussi selon cette méthode SASL, ce qui explique que ces logiciels incorporent des bibliothèques SASL, que Postfix peut alors, lui aussi, utiliser :
- pour s’identifier auprès d’un relais SMTP,
- mais aussi pour forcer les clients de ce Postfix à s’identifier eux aussi.
Dans les fichiers de configuration de Postfix, on note ainsi la présence de commandes similaires, mais légèrement différentes :
- les commandes commençant par « smtp_ » concernent la partie « client » de Postfix, en tant que client d’autres serveurs SMTP vers lesquels il relaie les courriels qu’on lui confie;
- les commandes commençant par « smtpd_ » concernent la partie « serveur » de Postfix, en tant que serveur SMTP utilisé par des clients lui confiant leurs courriels à envoyer.
Postfix peut donc sans problème :
- s’identification auprès d’un serveur SMTP d’Orange vers lequel il relaie les courriels qu’on lui a confiés,
- et accepter que les utilisateurs qui lui envoient des courriels n’aient pas à s’identifier auprès de lui.
Un tel réglage de Postfix peut sembler dangereux, mais ce billet concerne le cas d’un serveur Postfix utilisé par des clients qui sont en fait des programmes informatiques :
- divers messages et notifications sont envoyés, en interne, à ce Postfix, à destination de l’équipe informatique : certains logiciels à l’origine de ces messages et de ces notifications peuvent poser des problèmes si ce Postfix exige une identification;
- il en est de même si ce Postfix est chargé de relayer vers l’extérieur des courriels fabriqués par un programme informatique.
Dans un tel contexte, les risques d’abus sont très limités, de la part d’utilisateurs internes disposant de toute façon d’un logiciel permettant d’envoyer des courriels, sans passer par ce Postfix. Et si un de ces utilisateurs arrivait à envoyer des mails (en interne ou vers l’extérieur) en utilisant ce Postfix, il ne faut pas oublier que l’en-tête de ces mails permettrait de l’identifier par son adresse ip locale (ou éventuellement le nom de sa machine).
Bien évidemment, cette question de sécurité prendrait une toute autre ampleur si ce Postfix était accessible de l’extérieur…

Puisqu’on veut ici aussi recevoir quelques messages et notifications de provenance interne, il faut donc installer aussi un serveur permettant de relever ces courriels à distance, à partir d’une autre machine interne (on évitera ainsi autant que possible d’avoir à ouvrir une connexion sur un serveur) : dans ce billet, on utilisera Dovecot.
Les bibliothèques SASL de Dovecot sont maintenant disponibles sous forme d’un paquet autonome : dovecot-common. On pourrait ainsi utiliser SASL pour Postfix, sans être obligé d’installer Dovecot en entier.
Mais puisqu’on veut ici pouvoir aussi relever ses courriels à partir d’un ordinateur distant, il faut de toute façon installer la version complète de Dovecot : apt-get install dovecot-postfix
L’intérêt est aussi que le script d’installation de ce paquet complet configure Dovecot, mais configure aussi Postfix pour qu’il utilise ces bibliothèques SASL.

Ceci fait, il suffit ensuite d’ajuster le contenu de quelques fichiers de configuration.

Dans le fichier /etc/postfix/main.cf, ajouter les lignes suivantes (par exemple, après la ligne relayhost = [smtp.orange.fr]) :
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl-passwords

Dans le dossier /etc/postfix/sasl/, créer un fichier texte nommé sasl-passwords, contenant la ligne suivante :
[smtp.orange.fr] username:password
username:password est le login de celle de vos boîtes à lettres fournie et hébergée par Orange, dont vous aurez choisi le login pour que Postfix puisse s’identifier auprès du SMTP de ce FAI.
Ce n’est qu’un login d’identification auprès du SMPT d’Orange. Vos courriels ainsi relayés par Orange ne proviendront pas de l’adresse mail correspondant à ce login : l’adresse de retour de ces courriels restera celle de la boîte à lettres utilisée par le logiciel client distant du SMTP Postfix (y compris un programme informatique), qui lui aura transmis ces courriels pour les envoyer à l’extérieur.
Après une modification du fichier /etc/postfix/sasl/sasl-passwords, il faut reconstruire son hash, par la commande :
postmap hash:/etc/postfix/sasl/sasl-passwords

Après toute modification de la configuration de Postfix, penser à recharger cette configuration par la commande : /etc/init.d/postfix reload.