[Postfix](http://www.postfix.org/) est serveur [SMTP](HowtoSMTP) libre et populaire sous GNU/Linux et BSD. Il a été développé en 1999 par [Wietse Venema](http://www.porcupine.org/wietse/) comme une alternative plus facile à administrer et plus sécurisée que l'historique _Sendmail_.
## Installation
~~~
# apt install postfix
# postconf -d | grep ^mail_version
mail_version = 2.11.3
~~~
## Configuration
Postfix s'appuie principalement sur le fichier `/etc/postfix/master.cf` (configuration des process de Postfix) et le fichier `/etc/postfix/main.cf` (configuration des options).
L'utilitaire **postconf** permet de lister/vérifier les options du `main.cf`.
Un serveur web va souvent envoyer des emails, et notamment vers des fournisseurs d'accès connus (gmail.com, orange.fr, etc.). On conseille donc d'ajouter les options suivantes dans `main.cf` pour gérer le rythme d'envoi :
Il faut également créer le fichier `/etc/postfix/transport` et indiquer des domaines vers lesquels le rythme d'envoi sera plus lent (à cause de restrictions de leur côté) :
On peut ensuite vérifier que la configuration est bien prise en compte en regardant dans les logs de Postfix. On doit pouvoir observer des processus « postfix-slow » pour tous les domaines concernés.
Pour l'envoi d'emails depuis des clients SMTP authentifiés (*smtpd_sasl_auth_enable=yes*), on active en général le port TCP/587 (appelé _SMTP Submission_) qui n'accepte que des connexions chiffrées (*smtpd_tls_security_level=encrypt*) et le port TCP/465 (appelé _SMTPS_) qui n'accepte que des connexions SMTP over TLS (*smtpd_tls_wrappermode=yes*). Ces activations se font en décommentant les lignes appropriées dans `/etc/postfix/master.cf`.
Postfix envoie une trace de ses actions à _Syslog_ avec la facility *LOG_MAIL*. On retrouve donc les fichiers de journalisation définis dans le fichier `/etc/rsyslog.conf` :
Postfix utilise différentes files d'attente (ou queues). Les files d'attente principales sont _incoming_, _active_ et _deferred_ :
~~~
incoming : première étape pour tous les nouveaux messages (après un passage par cleanup)
active : messages en cours de livraison (provenant principalement d'incoming ou deferred)
deferred : messages non délivrés lors du premier essai
~~~
Il existe aussi d'autres files d'attente, qui servent beaucoup moins fréquemment : _corrupt_ (messages invalides) et _hold_ (messages mis de côté).
Ces files d'attente sont des répertoires situés dans `/var/spool/postfix`dans lesquels chaque message est stocké dans un fichier (sur une seule ligne), avec une arborescence de 16 répertoires (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F) pour optimiser lorsqu'un grand nombre de messages est dans une file d'attente. On peut gérer ces files d'attente grâce à des commandes d'administration.
*Note* : le `BEGIN { RS = "" }` est nécessaire car la sortie de mailq peut être sur plusieurs lignes, et le `tr -d '*!'` permet de ne pas prendre les messages en « hold ».
**Lister les messages dans la file d'attente _deffered_ :**
/!\\ Attention, `postsuper -d ALL` et `mailq -q` réactivent immédiatement l'ensemble des messages en file d'attente, il faut donc les utiliser avec modération, surtout sur les serveurs avec des files d'attentes chargées.
La commande `postsuper -r` est pratique dans les cas où l'on a modifié des alias ou des ré-écritures, elle va déposer les messages concerné dans la queue _maildrop_ et lui attribuer un nouveau <queue_id>. Attention, cela ne va pas provoquer un envoi immédiat car le traitement des files d'attente est différé. Si l'on veut un ré-envoi immédiat d'un message :
/!\\ Attention, pour un serveur recevant pas mal de messages, cela peut générer pas mal de notifications. Si nécessaire, ajuster ainsi pour avoir un minimum d'alertes :
Postfix est découpé en plusieurs processus (qmgr, pickup, smtp, smtpd, bounce, cleanup, error, etc.) contrôlé par un processus nommé `master`. Chaque processus est défini dans le fichier de configuration `master.cf`.
Sur un serveur inactif, vous verrez au minimum les processus suivants :
~~~
|-master,432636 -l -t unix -u
| |-qmgr,5036 -l -t unix -u-u -c
| `-pickup,9162 -l -t unix -u -c
~~~
Sur un serveur actif, vous verrez de nombreux processus, par exemple :
* Le processus **bounce** gère les messages de non-livraison qui sont stockés dans les répertoires `/var/spool/postfix/bounce/*`, `/var/spool/postfix/defer/*` ou encore `/var/spool/postfix/trace/*` selon les types de message.
Par exemple pour mettre un message personnalisé (et en Français) des DSN du type « successful delivery ».
Installer le paquet `postfix-doc`, copier le fichier `bounce.cf.default` dans `/etc/postfix/bounce.cf`, éditer le fichier comme voulu et ajouter la directive `bounce_template_file = /etc/postfix/bounce.cf` à postfix.
La surveillance régulière des fichiers de journalisation ainsi que des files d'attente s'avère nécessaire, éventuellement à l'aide d'outils permettant de générer des statistiques, des courbes, etc. On peut ainsi citer l'outil **mailgraph** qui trace des courbes _rrdtool_ à partir du fichier de journalisation, ou encore **Munin** qui trace des courbes selon l'état des files d'attente.
### mailgraph
~~~
# apt install mailgraph
~~~
[mailgraph](http://mailgraph.schweikert.ch/) fait tourner un démon Perl qui analyse `/var/log/mail.log`, on peut ensuite visualiser des courbes RRDtool via un script CGI `/usr/lib/cgi-bin/mailgraph.cgi`.
Pour diverses raisons, si l'on ne veut pas avoir de module CGI on pourra utiliser un script Shell à placer en crontab :
* Utiliser une adresse de retour valide (expéditeur d'enveloppe ou **Return-Path**) et traiter les retours régulièrement voire dynamiquement en cas de gros volume
* Pour Hotmail/Outlook/Microsoft/Office365, faire un ticket support depuis [sender.office.com](https://sender.office.com/) et ce formulaire <https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75> pour autoriser IPv4.
[SPF](https://fr.wikipedia.org/wiki/Sender_Policy_Framework) est une norme pour vérifier l'adresse IP expéditrice d'un email.
La vérification se fait en utilisant le nom de domaine de l'expéditeur d'enveloppe et en récupérant un enregistrement DNS qui va lister les adresses IP autorisées.
Voici un exemple d'enregistrement DNS autorisant des adresses IP pour une adresse en `@example.com`
~~~
@ IN TXT "v=spf1 a mx ptr ip4:192.0.2.142 ip4:192.0.2.0/24 ip6:2001:db8::/32 ~all"
~~~
Voici un exemple d'enregistrement DNS autorisant l'envoi de n'importe où :
On peut utiliser un `include:` vers un autre enregistrement TXT, pratique pour la gestion ou éviter d'avoir des enregistrements TXT [dépassant 255 caractères](https://kb.isc.org/docs/aa-00356). Voici un exemple, les deux chaines de caractères seront concaténées donc il ne faut pas oublier qu'au moins une des deux chaine doit contenir une espace libre :
~~~
@ IN TXT "v=spf1 a mx ptr ip4:192.0.2.142 ip4:192.0.2.0/24" " ip6:2001:db8::/32 ~all"
Chez Evolix, on utilise ainsi `include:spf.protection.evolix.net`. Si vous utilisez [Mailchimp](https://mailchimp.com/developer/transactional/docs/authentication-delivery/) vous devez ajouter `include:spf.mandrillapp.com` par exemple.
Cet entête pourra notamment être utilisé par des filtres, SpamAssassin, etc.
> *Note* : attention, pour les emails locaux, cela n'ajoutera pas l'entête `Received-SPF` ce qui peut poser des soucis avec les outils s'appuyant dessus, notamment SpamAssassin ou OpenDMARC.
Pour vérifier manuellement un enregistremnt SPF vous pouvez utiliser `spfquery` fourni par le paquet du même nom. La commande necessite 3 arguments et s'utilise comme suit :
L'utilitaire [`spf`](https://github.com/jschauma/spf/) permet aussi d'avoir une vision synthétique sur la configuration SPF d'un domaine. Écrit en Perl il est facile à installer et fonctionne presque partout.
*`p=none` si l'on ne veut pas que les emails non conformes soient rejetés
*`p=reject` si l'on veut que les emails non conformes soient rejetés
*`p=quarantine` si l'on veut que les emails non conformes soient mis de côté (dans une sous-boîte Spam en général)
Attention, si vous spécifiez `rua=mailto:dmarc@example.com` vous recevrez pas mal de rapports
`Report domain` de Google, Outlook, etc. vous notifiant des emails non conformes.
Les rapports incluent un fichier XML, on peut le lire via des outils comme [mxtoolbox](https://mxtoolbox.com/DmarcReportAnalyzer.aspx) ou [easydmarc](https://easydmarc.com/tools/dmarc-aggregated-reports).
Voici un exemple d'un enregistrement DNS plus avancé :
Par défaut, la taille d'un message est limitée à 10 Mo, cela se modifie avec le paramètre `message_size_limit`.
Attention, lorsqu'une pièce jointe est dans un format binaire (exemples : JPG, PDF, etc.), les emails sont traduits en caractères texte (conversion [uuencode](https://fr.wikipedia.org/wiki/Uuencode)) ce qui provoque une augmentation de la taille jusqu'à 40%.
Voici par exemple le paramètre que l'on conseille de mettre si l'on veut autoriser les messages jusqu'à 20 Mo :
Attention, la taille par défaut de la mailbox est de 50 Mo (`mailbox_size_limit = 51200000`). Si vous définissez `message_size_limit`> `mailbox_size_limit` (sauf si la taille est illimitée avec `mailbox_size_limit = 0`), Postfix bloquera les mails dans la queue (avec un `*`).
De façon similaire aux fichiers `.htaccess` pour Apache, un utilisateur UNIX peut créer un fichier `.forward` à la racine de son home-directory pour faire passer tous ses emails reçus dans une moulinette : renvoi automatique vers une autre adresse, traitement via Procmail, envoi d'un message d'absence, etc. Attention, cela ne fonctionne que pour Postfix en mode local, cela ne fonctionne pas en mode virtual.
Pour ré-envoyer tous les emails vers une autre adresse `jdoe@example.com` on mettra simplement :
~~~
$ cat ~/.forward
jdoe@example.com
~~~
Pour envoyer tous les emails vers une autre adresse MAIS garder une copie sur sa boîte `foo` :
~~~
$ whoami
foo
$ cat ~/.forward
\foo,jdoe@example.com
~~~
Pour faire traiter tous ses emails reçus par le logiciel Procmail :