Nous savons envoyer des messages vers le reste du monde, si le reste du monde veut bien accepter notre serveur. Malgré toutes nos précautions, il peut se faire que notre serveur soit rejeté dans certains domaines destinataires. Dans un tel cas, il faudra faire relayer les messages à ce domaine par le serveur SMTP de notre fournisseur d'accès. Ceci peut se réaliser en utilisant le paramètre transport_maps. Plus radical, nous pouvont tout faire relayer par le MTA de notre fournisseur d'accès, en l'indiquant avec le paramètre relayhost.
Nous ne gérons pas de boites aux lettres dans notre domaine, hormis le compte administratif qui va collecter les messages émis par les divers services tournant sur notre hôte. Du fait de notre liste d'alias /etc/aliases, tous ces messages doivent se retrouver dans la même boite. Il nous faudra créer des boites aux lettres et installer un moyen d'y accéder à distance.
Nous verrons tout ceci dans la prochaine étape.
Nous avons vu ce ces messages sont stockés au format « mailbox » (tous les messages à la suite, dans un seul fichier). Ce n'est pas terrible, de nos jours où le nombre d'entrées dans les catalogues des systèmes de fichiers n'est plus trop un problème. Il vaudrait mieux exploiter le format Maildir, où chaque message est stocké dans un fichier différent.
Nous n'avons pas installé de serveur POP ni IMAP, ce qui fait que le compte administratif n'est consultable que localement. Il nous faudra prévoir quelque chose de plus souple.
Les boîtes-aux-lettres nécessitent l'existence d'un compte Unix correspondant. Pas bien pratique et même dangereux, si dans l'avenir nous devons créer de nombreuses boîtes. Ça deviendra même impossible si nous devons gérer plusieurs domaines de messagerie sur le même serveur. Ce serait pas mal que l'on puisse créer des boîtes et les stocker sur la machine sans pour autant devoir créer un compte Unix. Pour le faire, il faudra que Postfix puisse, d'une manière ou d'une autre avoir conscience de l'existence de ces boîtes, il faudra aussi que nos futurs serveurs POP ou IMAP aient un moyen d'identifier ces utilisateurs pour leur donner l'accès à leur boîte.
Nous allons passer au format « Maildir », plus sympatique,et installer un serveur POP/IMAP. Nous avons le choix :
Dovecot est un excellent serveur, plein de possibilités bien qu'encore jeune ;Courier propose tout ce qu'il faut pour faire un serveur POP/IMAP de qualité ;Cyrus est un peu « usine à gaz », mais propose énormément de fonctionnalités. Nous garderons celui-ci pour la fin.Dans l'étape suivante, Dovecot fera parfaitement l'affaire.
Dans cet exemple très simple d'utilisation de Postfix, 13 lignes suffisent à configurer le MTA, si l'on omet les quelques lignes concernant TLS que nous avons laissées dans la configuration, mais sans les utiliser.
Les étapes suivantes vont nous montrer que Postfix est bien plus configurable et propose bien plus de possibilités, mais au prix d'un fichier de configuration qui va progressivement s'allonger et se compliquer.
Le secret de l'apparente simplicité de cet exemple réside dans les paramètres par défaut de Postfix. Une très grande quantité de paramètres est définie à notre place de façon implicite (invisible dans le fichier de configuration) d'où l'apparente grande simplicité de l'exemple.
L'inconvénient d'une telle approche est que l'on peut acquérir le sentiment que la configuration d'un MTA est facile, ce qui n'est pas du tout le cas. Nous mettons ici une confiance aveugle dans des choix de paramétrage faits à notre place par l'équipe du projet Postfix. Nous pouvons nous le permettre, ce choix étant tout à fait judicieux, mais mieux vaut le savoir. Si nous nous arrêtons ici, nous devons être conscients que nous ne savons encore pratiquement rien de Postfix.