**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
# Howto Postfix
Le MTA (Mail Transport Agent) est l'élément principal d'un serveur de courriers électroniques. Tout courrier électronique transite forcément par un MTA. Il existe de nombreux MTA, appelés plus communément "serveurs mail". L'une des implémentations la plus connue est sendmail, qui est Open Source (écrit sous Sendmail license). Les alternatives sont les logiciels Postfix (écrit sous IBM PUBLIC LICENSE Version 1.0), Exim (écrit sous GNU General Public License), Qmail (distribué avec des restrictions), Courier (écrit sous GNU General Public License) ainsi que des logiciels propriétaires tels que Microsoft Exchange, Sun Java System Messaging Server, IBM Lotus Domino, etc.
Postfix est un logiciel écrit par Wietse Venema, un chercheur d'IBM, en alternative au fameux sendmail. Placé sous IBM PUBLIC LICENSE Version 1.0, sa première version date de 1998. Il a été conçu pour être sûr, rapide et facile à administrer. À l'heure où ces lignes sont écrites, la version stable est la version 2.7.
## Sommaire
* Installation
* Configuration de base
* Restrictions
* Authentification SMTP
* Support SSL/TLS
* Fichier main.cf détaillé
* Maintenance
* Utilisation avec un annuaire LDAP
* Postfix dans un chroot
## Installation
Postfix s'installe sur de nombreux systèmes (de nombreux UNIX, Linux, etc.) à partir des sources. Il existe un bon nombre d'extensions disponibles (Berkeley DB, LDAP, MySQL, PCRE, PostgreSQL, SASL, TLS, IPv6). Des paquets existent pour de nombreux systèmes (distributions Linux, *BSD, Mac OS X, Solaris, HP-UX, etc.).
Il faut avoir à l'esprit que Postfix, au contraire de Sendmail, n'a pas une architecture monolithique. En effet, par défaut, seul le processus master tourne en permanence et gère le démarrage d'autres processus qui ont des tâches dédiées (cleanup, smtpd, pickup, etc.) notamment la transition entre les différentes files d'attente de Postfix (incoming, active, deferred, corrupt, hold). La configuration de ces processus se trouve dans le fichier _master.cf_. Pour une configuration de base, il n'est pas utile d'éditer ce fichier.
La configuration générale de Postfix se trouve dans le fichier _main.cf_ dont voici un exemple (très) minimal :
[FQDN] correspond au nom de la machine complété du domaine auquel elle appartient. Par exemple hote.example.com est un nom d'hôte pleinement qualifié. Il faut absolument préciser un nom d'hôte pleinement qualifié (FQDN) à la variable myhostname si la commande hostname renvoie le nom d'hôte de la machine sans le domaine.
Il faut s'assurer que la base de données d'aliases existe, c'est-à-dire que le fichier _/etc/aliases_ existe (même vide, mais il est conseillé au minimum de l'utiliser pour les comptes système). Voici un exemple :
Ensuite, il faut générer la base de données _aliases_ à l'aide de la commande _newaliases_. Le paramètre _alias_maps_ contient normalement par défaut _nis:mail.aliases_. Il faut donc préciser ce paramètre dans le fichier (très) minimal si l'on n'utilise pas NIS, sous peine d'obtenir des messages suivants : _warning: dict_nis_init: NIS domain name not set - NIS lookups disabled_
Avec cette configuration minimale, Postfix fonctionne. Pour une utilisation un peu plus aisée, vous pouvez préciser quelques paramètres supplémentaires :
[domain.tld] correspond au domaine auquel la machine appartient et [adresses IP] est la liste des adresses IPv4 attachées aux interfaces de la machine sur lesquelles le serveur mail écoute. La paramètre mydestination permet de spécifier à Postfix la liste des noms et des adresses IP qu'il devra considérée comme locale. Ainsi, si vous envoyez un message avec une adresse non présente dans cette liste (mais pointant pourtant vers la machine), vous obtiendrez l'erreur suivante : mail for [adresse_non_listee] loops back to myself et le message ne sera pas délivré.
Restrictions
Pour de multiples raisons, il n'est pas question d'autoriser n'importe qui à envoyer un courrier électronique n'importe où. Il faut restreindre les courriers entrants à cause des courriers électroniques non sollicités, ainsi que les courriels sortants pour éviter que le service soit utilisé par des personnes non-dignes de confiance.
On peut avoir des restrictions à différents niveaux :
~~~
smtpd_client_restrictions Rejete toutes les commandes du client
smtpd_helo_restrictions Rejete les informations HELO/EHLO
smtpd_sender_restrictions Rejete l'information MAIL FROM
smtpd_recipient_restrictions Rejete l'information RCPT TO
smtpd_data_restrictions Rejete la commande DATA
smtpd_etrn_restrictions Rejete la commande ETRN
~~~
Les restrictions que l'on pourra imposer le seront par des tables d'accès, contrôle de la syntaxe utilisée, élements de la transaction, vérification DNS, RDNSBL, etc. Elles permettront d'exclure certains clients non désirables (non respect des normes de l'échange avec le serveur, adresses IP non résolues, etc.) et de permettre à d'autres d'envoyer des courriers à n'importe qui (authentification par adresses IP). Voici quelques arguments :
* check_X_access type:table où X = client, helo, recipient ou sender
* permit_X où X = auth_destination, mynetworks, mx_backup
* reject_X où X = unauth_destination, invalid_hostname, non_fqdn_hostname, non_fqdn_recipient, non_fqdn_sender, unauth_pipeling, unknown_client, unknown_hostname, unknown_recipient_domain, unknown_sender_domain
Ainsi, chaque serveur impose ses restrictions selon les contraintes imposées. Des restrictions raisonnables peuvent être :
# Attendre la commande 'RCPT TO' avant d'evaluer les restrictions ?
# (peut poser pb avec certains clients et permet d'avoir renseignements suppl)
#par defaut, = yes
#smtpd_delay_reject =
# Definition des plages IP appartenant a mynetworks
#par defaut, toutes les plages d'adresses IPv4 (et IPv6) des interfaces
mynetworks = 127.0.0.0/8,[::1]/128,10.0.0.0/16
# Exiger la commande HELO/EHLO
#par defaut, = no
smtpd_helo_required = yes
# Exiger syntaxe conforme dans les commandes MAIL FROM ou RCPT TO
#par defaut, = no
#strict_rfc821_envelopes =
# Rejeter le courrier provenant d'une adresse inexistante ?
#par defaut, = no
#smtpd_reject_unlisted_sender =
# Rejeter le courrier a destination d'une adresse inexistante ?
#par defaut, = yes
#smtpd_reject_unlisted_recipient =
~~~
### Utilisation avec un annuaire LDAP
Les bases de données d'utilisateurs et de leurs paramètres peuvent être stockés dans une base de données externe. On peut ainsi utiliser une base de donnée ou un annuaire LDAP. Dans le cas de Postfix, on peut l'utiliser avec MySQL ou OpenLDAP.
Dans le fichier main.cf de Postfix, on utilisera une configuration type :
Cette solution est décrite dans la RFC 2554 : SMTP Service Extension for Authentication. Il faut néanmoins prendre garde, car cette possibilité fait baisser le niveau de sécurité de votre service. En effet, tout repose désormais sur les paramètres d'authentification et, outre des moyens sociaux, il faut veiller à ce que ces paramètres ne soient pas interceptés, c'est-à-dire ne circulent pas en clair sur des canaux non sécurisés. Il sera donc prudent de rajouter une couche de chiffrement, ou alors d'exclure certains types d'authentification comme les types PLAIN ou LOGIN.
Un mécanisme d'authentification souvent utilisé est SASL (Simple Authentication and Security Layer), librairie développée par le projet Cyrus. La lecture du document Cyrus SASL for System Administrators donnera des élements pour installer et configurer conrrectement une authentification basée sur la librairie Cyrus. L'installation se fera à partir des sources ou de paquets (sasl2-bin libsasl2 libsasl2-modules). Certains modules sont optionnels et permettent d'utiliser diverses méthodes d'authentification (libsasl2-modules-gssapi-heimdal libsasl2-modules-kerberos-heimdal). Sous Debian Sarge, on installera le paqut postfix-tls qui contient notamment les extensions SASL pour Postfix.
Plusieurs bases d'authentification sont possibles selon les configurations :
* *shadow* : authentification basée sur le fichier _/etc/shadow_
* *pam* utilise directement les librairies PAM (on peut donc par exemple utiliser LDAP ou RADIUS)
* *pwcheck* : authentification basée sur le deamon pwcheck utilisant aussi le fichier /etc/shadow (précision pour Debian Sarge : saslauthd est dans le paquet cyrus-common)
* *saslauthd* : authentification basée sur le deamon saslauthd qui est plus flexible que pwcheck et peut utiliser PAM (mais aussi shadow, ldap, kerberos, etc,.) (précision pour Debian Sarge : saslauthd est dans le paquet sasl2-bin)
La configuration s'effectue dans dans _/etc/default/saslauthd_ :
Note : attention, sous Debian Sarge, _testsaslauth_ ne tient apparemment pas compte du mécanisme passé en paramètre de saslauthd, c'est OK depuis Etch
saslauthd utilise le fichier pam.d/smtp (ou pam.d/other) dans ce cas (quelques modifications sont nécessaires si Postfix est chrooté, voir section CHROOT)
* *auxprop* (ou sasldb pour SASL version 1) : utilisation de /etc/sasldb(2)
C'est l'authentification utilisée par défaut par Postfix (si aucun paramètre pwcheck_method n'est précisé dans le smtpd.conf)
Commandes : sasldblistusers(2), saslpasswd(2)
Note : possibilité d'utiliser une base de données avec l'option auxprop_plugin: sql (quelques modifications sont nécessaires si Postfix est chrooté, voir section CHROOT)
Si vous utilisez une authentification non disponible, vous obtiendrez probablement :
Note concernant Debian Sarge : le paquet authsasld ne permet que les types PLAIN et LOGIN. Si l'on autorise un autre type, il cherchera le fichier /etc/sasldb2 (a priori, le paquet n'a pas été compilé avec les options --enable-cram --enable-digest).
Postfix, lorsqu'il communique avec d'autres serveurs en tant que client, peut avoir besoin de s'authentifier. On peut donc lui passer des paramètres d'authentifications pour certains serveurs :
Enfermer Postfix dans un chroot permet de restreindre les accès à d'autres applications en cas de faille de sécurité. Cette protection s'indique au fichier master.cf. Par défaut, cette protection est activée sous Debian. Le répertoire de chroot se situe dans _/var/spool/postfix_
L'utilisation de chroot impose quelques modifications, notamment si l'on utilise l'authentification SMTP :
* saslauthd
Pour SASL avec la méthode saslauthd, il faut préciser la directive suivante dans le fichier _/etc/default/saslauthd_ :
Ne pas oublier de mettre des droits de lecture sur les répertoires _/var/spool/postfix/var/_ et _/var/spool/postfix/var/run/_ afin d'autoriser l'utilisateur _postfix_.
L'utilisateur _postfix_ sera ajouté au groupe _sasl_ si nécessaire (si le répertoire saslauthd appartient à _root:sasl_). Sans ces changements, on obtiendra un message :
Le fichier _/etc/resolv.conf_ est copié dans _/var/spool/postfix/etc/resolv.conf_. Il faut le tenir synchronisé en cas de modification (notamment en cas d'installation sur un réseau différent du réseau final).