Poster et recevoir du courrier avec Postfix

À propos de ce document

Ce document, comme d'habitude, ne se veut pas être un guide de référence ou une adaptation française de la documentation de postfix, très bien faite au demeurant. Il se borne à relater les manipulations que j'ai été amené à faire pour configurer le logiciel afin que je puisse recevoir et poster du courrier avec lui. Toutes critiques, positives ou négatives sont évidemment les bienvenues. Le site de référence de cette documentation est Linux-France qui contiendra toujours la version la plus récente. À partir de cette page, vous pouvez télécharger les sources DocBook/XML, la version au format PostScript et la version au format PDF de ce document.

Présentation

La configuration décrite ici a été testée avec les systèmes d'exploitation Debian GNU/Linux, et FreeBSD.

En fait, le système utilisé a peu d'importance du moment qu'il est reconnu par Postfix. Ce qui est décrit ci-après devrait donc s'appliquer dans tous les cas, le cas échéant à quelques modifications mineures près. Notons que, pour Linux, des paquetages précompilés existent : la Debian, notamment, permet d'installer directement le programme via dpkg ou apt-get et j'imagine qu'il existe également des paquetages rpm. Le problème, avec ces paquetages binaires, est qu'ils ne permettent pas de suivre les fréquents changements du logiciel ; or, celui-ci étant en phase de développement, les nouvelles versions ajoutent de nouvelles fonctionnalités souvent fort intéressantes...

Concernant les autres Unix, il n'y a aucune raison pour que le fonctionnement soit différent : la documentation cite d'ailleurs une liste de tous les systèmes pris en charge. Je n'ai personnellement vu aucune différence entre l'installation sous Linux et sous FreeBSD (dont les scripts d'initialisation sont bien distincts).

La distribution officielle de Postfix peut être récupérée sur son site officiel, ou sur l'un des sites miroirs français. La distribution actuelle est postfix-19991231.08.

Il ne sera pas traité ici de la récupération du courrier venant de l'extérieur (du serveur de courrier de son fournisseur d'accès si l'on est, comme moi, relié via une connexion téléphonique). Pour cela, d'autres documentations existent, consultez notamment le site Linux-France.

Installation à partir de la distribution source

Utilisation de paquetages pré-compilés

Si vous préférez utiliser des paquetages rpm ou deb, vérifiez les emplacements des différents fichiers et adaptez les chemins utilisés ici à votre configuration.

Oublier sendmail !

Pour que postfix devienne votre agent de transport de courrier, vous devrez probablement désactiver sendmail. Même si vous ne l'avez jamais activé ou configuré, il y a fort à parier que ce dernier ait été installé par votre distribution Linux !

Pour cela, il suffit, encore une fois, de suivre ce que propose le fichier INSTALL :

# cd /usr/sbin
# mv sendmail sendmail.OFF
# ./sendmail.OFF -q
# mv /usr/bin/newaliases /usr/bin/newaliases.OFF
# mv /usr/bin/mailq /usr/bin/mailq.OFF
# chmod 0 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF \
       /usr/bin/mailq.OFF
# ln -s /usr/local/sbin/sendmail /usr/sbin/sendmail
# ln -s /usr/local/sbin/sendmail /usr/bin/mailq 
# ln -s /usr/local/sbin/sendmail /usr/bin/newaliases

Et c'est fini...

Ces quelques lignes sauvegardent les exécutables originaux de sendmail, vident sa file d'attente, ôtent toutes les permissions pour les protéger, et créent des liens symboliques ayant les mêmes noms que les originaux vers la commande sendmail de postfix.

Small is beautiful...

La première chose qui frappe, quand on se plonge dans la documentation fournie avec postfix est son apparente simplicité... Finie la syntaxe ésotérique du sendmail.cf, finie la nécessité de passer par un ensemble de macros pour oser espérer comprendre un tant soit peu ce que l'on est en train de configurer : avec postfix tout se passe par l'adaptation d'un seul fichier, main.cf, normalement placé, comme tous ses autres fichiers de configuration, dans le répertoire /etc/postfix/ (ou /usr/local/etc/postfix/). Enfin, presque... nous verrons plus tard que d'autres fichiers doivent être adaptés, mais tous sont humainement lisibles et richement commentés.

À la différence de sendmail, programme monolithique par excellence, postfix est composé de nombreux petits programmes réalisant chacun une tâche bien définie. Pour la plupart, ces programmes ne sont pas vus de l'utilisateur mais appelés directement par le programme serveur /usr/sbin/postfix. Le lancement de celui-ci au démarrage du système dépend de l'Unix utilisé : avec un System V (Linux en fait partie, sauf la distribution Slackware), il est lancé via le script /etc/init.d/postfix selon la méthode habituelle des runlevels ; sur FreeBSD, il est lancé via la ligne sendmail_enable="YES" dans le fichier /etc/rc.conf (vous comprendrez plus loin ce que sendmail vient faire ici...). Sur les systèmes BSD, on peut également utiliser le fichier /etc/rc.local  :

% cat /etc/rc.local

postfix start

Démarrage de postfix

Ainsi que nous venons de le dire, quel que soit le système utilisé, c'est un script qui lance le serveur /usr/sbin/postfix en lui passant le paramètre start. Celui-ci lance à son tour le serveur principal, /usr/libexec/postfix/master qui prend alors les choses en main et lancera les autres démons lorsque cela sera nécessaire. Ces derniers se termineront après avoir accompli leurs tâches ou après une certaine période d'inactivité. Seul, le démon de gestion de la file d'attente, /usr/libexec/postfix/qmgr reste en permanence en activité.

Tout ceci peut se vérifier par une simple commande ps (ici sous FreeBSD, d'où la présence de ces serveurs sous /usr/local/) :

% ps axf

...
583  ?  S    0:00 /usr/local/libexec/postfix/master
584  ?  S    0:00  \_ pickup -t fifo -c 
585  ?  S    0:00  \_ qmgr -t fifo -u -c 
...

qui met en évidence la présence du démon master et le fait qu'il a lui-même lancé les démons pickup et qmgr (la commande ps utilisée ici est celle de GNU, l'option -f n'a pas la même signification avec un ps BSD).

pickup est responsable de la récupération des courriers locaux : comme nous l'écrivions plus haut, pour des raisons de compatibilité, postfix utilise un programme nommé /usr/sbin/sendmail (qui n'est pas le programme sendmail bien connu, mais un homonyme). Ce programme est utilisé pour déposer les courriers locaux dans la file d'attente maildrop : tous les courriers qui sont postés par tous les utilisateurs sont déposés dans cette file.

pickup les récupère alors et les passe au démon cleanup qui remplira les en-têtes manquants, gérera les enveloppes des messages et les déposera enfin dans une autre file d'attente, nommée incoming. Puis cleanup avertira le gestionnaire de file d'attente, qmgr, qu'un nouveau courrier est arrivé.

qmgr s'occupera alors de délivrer le courrier dans les boîtes aux lettres de leurs destinataires et de gérer les erreurs.

Nous verrons plus loin les autres démons entrant en jeu dans la délivrance du courrier. Passons maintenant à une configuration minimum pour tester localement postfix.

Configuration minimale

Notre but, ici, est d'arriver à poster et recevoir du courrier en local : par exemple, root doit pouvoir poster un message à l'utilisateur babe. Ce dernier doit pouvoir récupérer le message, le lire et répondre à root. Pour simplifier, nous utiliserons le programme canonique mail.

Nous supposerons que notre machine s'appelle alex et que notre domaine s'appelle linux-france.org. Vérifions tout de suite que c'est le cas :

% hostname
alex.linux-france.org

Ainsi que nous l'avons déjà dit, la majeure partie du travail de configuration consiste à adapter le fichier /etc/postfix/main.cf (ou /usr/local/etc/postfix/main.cf) à nos besoins. Bien entendu, tout cela doit se faire sous le compte root.

La première chose à faire est de sauvegarder le fichier original :

# cp /etc/postfix/main.cf /etc/postfix/main.cf.0

Puis, chargez main.cf dans votre éditeur de texte favori.

Normalement, un certain nombre d'options sont déjà en place. Certaines conviennent, d'autres non. Voici les lignes qui nous intéressent (les commentaires et les lignes non modifiées ont été supprimés) :

# INFORMATIONS SUR LES REPERTOIRES LOCAUX
queue_directory = /var/spool/postfix
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix

# POSSESSION DES FILES D'ATTENTE ET DES PROCESSUS
mail_owner = postfix

# NOMS DE LA MACHINE ET DU DOMAINE
myhostname = alex.linux-france.org                                          

# POUR L'ENVOI DU COURRIER
myorigin = $myhostname

# MODE DE TRANSPORT
default_transport = smtp

# GESTION DES ALIAS
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases

# DELIVRANCE DU COURRIER
mailbox_command = /usr/local/bin/procmail

Assurez-vous que toutes les autres possibilités pour ces lignes soient considérées comme des commentaires en les faisant précéder du caractère dièse (#) et ne modifiez pas les autres.

Avant de tester tout cela, détaillons rapidement les options choisies (pour des renseignements plus précis, reportez-vous aux pages de manuel et à la documentation fournie avec le programme).

La première section sert à spécifier les emplacements :

La deuxième section précise qui est le propriétaire de la file d'attente et de la plupart des processus serveurs de postfix. Ici, nous avons conservé la proposition, après avoir créé l'utilisateur postfix. Voici son entrée dans notre fichier /etc/passwd :

postfix:x:101:101::/var/spool/postfix:/bin/false

Le 'x' dans la partie mot de passe vient du fait que nous utilisons les « shadow passwords ». Le groupe 101 correspond au groupe postfix, lui aussi créé pour l'occasion :

# grep 101 /etc/group
postfix:x:101:

La troisième section sert à indiquer le nom complet de notre machine.

La section suivante concerne l'envoi du courrier : elle permet de renseigner postfix sur la machine qui a posté. Pour le moment, nous considérerons que c'est ce que contient la variable $myhostname.

Nous précisons ensuite le protocole utilisé pour l'acheminement du courrier. Pour l'instant, postfix ne reconnaît que smtp et uucp (en réalité, on peut créer des transports dans /etc/postfix/master.cf, ce qui permet de changer des paramètres en fonction de multiples critères. On peut ainsi dupliquer le transport smtp et en changer les caractéristiques en fonction des courriers entrants ou sortants ce qui est très souple. Toutefois, ne l'ayant pas pratiqué, je n'en dirais pas plus... ).

La gestion des alias peut faire appel au fichier /etc/aliases utilisé par ses prédécesseurs mais nous préférons en utiliser un autre : /etc/postfix/aliases (ou /usr/local/etc/postfix/aliases). La commande man aliases vous renseignera en détail sur le format de ce fichier. Disons simplement que, comme son nom l'indique, il permet de définir des alias entre des noms de destinataires. Ainsi, par exemple, un serveur de news poste quotidiennement un rapport sur ses activités à l'utilisateur news (ou usenet). Supposons que babe soit l'administrateur des news sur alex : pour qu'il puisse recevoir ces messages, et si root est d'accord, bien entendu, il suffit d'indiquer que les destinataires news et usenet ont pour alias babe. Ceci est réalisé par l'ajout de la ligne suivante dans /etc/postfix/aliases :

news: babe
usenet: babe

Pour des raisons d'optimisation, postfix, comme ses prédécesseurs, demande à ce que ce fichier soit traité comme une base de données au format DBM ou DB. Pour générer ces formats, on utilise l'utilitaire /usr/sbin/postalias (qui, rappelons-le, est un lien vers /usr/local/sbin/postalias). Ma machine ne reconnaissant pas le format DBM, j'ai donc opté pour le second et produit la base à l'aide de la commande :

# postalias hash:/etc/postfix/aliases

qui a engendré le fichier /etc/postfix/aliases.db.

La section concernant la délivrance du courrier local indique ici que nous souhaitons utiliser procmail pour cette tâche. Tout autre programme ayant la même fonction peut convenir (deliver, par exemple), mais procmail est le plus connu dans le monde Linux et FreeBSD. Cette section ne concerne que l'acheminement local du courrier, ie. son écriture dans les boîtes aux lettres des destinataires.

Test de la configuration locale

Après toute modification de l'un des fichiers que nous venons d'étudier, il faut demander à postfix de relire sa configuration :

# postfix reload

À l'aide de la commande ps ax, vérifiez la présence des démons master, pickup et qmgr. Si vous ne les voyez pas, c'est qu'il y a eu un problème : consultez les fichiers /var/log/mail.* pour tenter d'en rechercher la cause.

Si tout s'est bien passé, root va pouvoir envoyer un courrier à babe :

# mail babe -s test
premier test local
.
Cc: 
#

Immédiatement, babe a dû recevoir ce courrier :

% mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/spool/mail/babe": 1 message 1 new
>N  1 root@alex.linux-france.org.  Wed Jan 20 01:46  12/424   "test"
& 1
Message 1:
From root@alex.linux-france.org Wed Jan 20 01:46:10 1999
Delivered-To: babe@alex.linux-france.org
To: babe@alex.linux-france.org
Subject: test
Date: Wed, 20 Jan 1999 01:46:10 +0100 (CET)
From: root@alex.linux-france.org

premier test local
& d
& q

On notera la présence d'un champ Delivered-To: : il est ajouté par postfix afin d'éviter les boucles dans la délivrance du courrier et ne sera pas affiché par défaut avec la plupart des logiciels de lecture du courrier (en tous cas, avec Gnus et Netscape...).

Essayons encore : maintenant postez sous le compte babe un message à root et vite, très vite, faites ps axf. Sous Linux, vous devriez voir les lignes suivantes :

1271  ?  S    0:00 /usr/local/libexec/postfix/master
1272  ?  S    0:00  \_ pickup -t fifo -c 
1273  ?  S    0:00  \_ qmgr -t fifo -u -c 
1286  ?  S    0:00  \_ cleanup -t unix -u -c 
1287  ?  S    0:00  \_ trivial-rewrite -n rewrite -t unix -u -c 
1288  ?  S    0:00  \_ local -t unix

Assez rapidement, vous remarquerez, si vous faites la même commande, que cleanup et local se sont terminés, tandis que trivial-rewrite survit plus longtemps, puis se termine.

Tout ceci correspond ce que nous disions plus haut : pickup a récupéré le message et l'a passé à cleanup. trivial-rewrite s'est chargé de réécrire l'adresse en rajoutant le nom de la machine locale derrière le nom de l'utilisateur. local est le démon responsable de la délivrance locale du message dans la boîte aux lettres du destinataire. C'est à ce moment que le fichier des alias est pris en compte et, si le destinataire utilise un fichier ~/.forward, local le fait suivre à l'adresse indiquée. C'est local qui ajoute le champ Delivered-To: pour éviter un bouclage intempestif et c'est lui qui remplit le champ From de l'enveloppe (à ne pas confondre avec le champ From:...).

Pour finir cette partie, il ne vous reste plus qu'à essayer de faire la même chose avec vos logiciels de lecture de courrier favoris : cela ne devrait pas poser de problème puisque local délivre les messages à l'endroit où la plupart des logiciels s'attendent à les trouver.

Les files d'attente

Lorsqu'on a l'habitude d'utiliser sendmail, la multiplicité des files d'attente de postfix a tendance à dérouter. En effet, en lieu et place du classique et unique /var/spool/mqueue/ on se retrouve avec l'arborescence suivante :

# tree /var/spool/postfix/
/var/spool/postfix/
|-- active
...

|-- deferred
|   |-- 048ED779D1
|   |-- 09085779E0
|   |-- 17101779D6
|   |-- 31DE0779DA
|   |-- 3D15D779D4
|   |-- 4D2BD779D7
|   |-- 7BFA6779D3
|   |-- 7C65D779CF
|   |-- B10C3779D0
|   `-- C3272779D2
...

|-- incoming
...

|-- maildrop
...

Nous avons abrégé la sortie de cette commande pour ne retenir que les noms de répertoires qui nous intéressent ici.

postfix utilise quatre files d'attentes :

De plus, le répertoire /var/spool/postfix/defer contient les mails en attente plus longue et des répertoires qui sont « hachés » afin de ne pas avoir des répertoires contenant trop de fichiers : ainsi, le fichier 7B345AC0B1, par exemple, sera dans defer/7/B/7B345AC0B1.

La documentation HTML de la distribution postfix dispose d'un schéma présentant clairement les interactions entre les différentes files d'attente et les différents démons. C'est d'ailleurs de lui que je me suis inspiré...

Le contenu de la file d'attente peut être consulté avec la commande mailq (les habitués de sendmail ne seront pas dépaysés...) : normalement celle-ci ne doit produire que les messages dont la délivrance n'a pas encore eu lieu (dans notre cas, les 10 messages contenus dans la file deferred).

Les commandes de postfix

Nous avons déjà vu que postfix s'invoquait en lui passant un paramètre qui précisait l'action à entreprendre. Ainsi, les paramètres stop et start arrêtent et démarrent le serveur, respectivement. D'autres commandes existent :

Enfin, last but not least, la distribution postfix fournit le programme postconf pour afficher les paramètres modifiés par notre configuration (postconf -n), les valeurs par défaut du logiciel (postconf -d) et l'ensemble des valeurs courantes des paramètres (postconf). Voici, à titre d'exemple, ce que donne la première commande sur ma configuration personnelle actuelle :

# postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 10
default_transport = smtp
defer_transports = smtp
local_destination_concurrency_limit = 2
mail_owner = postfix
mailbox_command = /usr/local/bin/procmail
myhostname = alex.linux-france.org
myorigin = $myhostname
program_directory = /usr/local/libexec/postfix
queue_directory = /var/spool/postfix
relayhost = [smtp.mon.fai]
sender_canonical_maps = hash:/etc/postfix/canonical

Nous n'avons pas encore vu certains de ces paramètres ? C'est normal. Nous allons maintenant nous en occuper...

Envoyer du courrier non local

Bien, nous savons maintenant que postfix fonctionne correctement avec les adresses locales à notre machine (si ce n'est pas le cas, n'allez pas plus loin et revenez ici lorsque le problème sera réglé...). Allons maintenant à la conquête du monde...

La meilleure chose à faire, tant que tous nos tests n'ont pas donné satisfaction, est d'utiliser un « écho » : ie. une adresse où nous pourrons envoyer un courrier qui nous sera retourné tel qu'il a été reçu. Ceci nous permettra de vérifier au moins deux choses :

<echo@cnam.fr> est une adresse de ce type, et nous l'utiliserons ici.

Tout le courrier sortant de notre machine est d'abord envoyé au serveur de courrier de notre fournisseur d'accès qui se chargera ensuite de l'envoyer sur l'Internet. Dans la terminologie classique, cela s'appelle un hôte relais (ou relayhost, en anglais). Il faut donc indiquer à postfix le nom de cet hôte relais. Si l'on suppose que nous sommes abonnés au fournisseur d'accès bien connu mon.fai et que la machine s'occupant du courrier chez ce fournisseur s'appelle smtp.mon.fai, il faut modifier le fichier main.cf, rechercher les lignes contenant relayhost, en décommenter une et mettre :

relayhost = [smtp.mon.fai]

Le format indiqué ici suppose que nous utilisons SMTP (spécifié par la variable default_transport) pour transporter notre courrier. En réalité, le format de relayhost permet aussi d'indiquer une machine UUCP bien que le transport par défaut reste SMTP pour un intranet local, par exemple (voir les commentaires associés à cette variable dans main.cf pour connaître toutes les possibilités).

Puis, comme à chaque modification de ce fichier, il faut faire postfix reload.

Essayons maintenant la commande suivante :

% mail echo@cnam.fr -s test
essai d'envoi de courrier via postfix
.
Cc: 
%

Puis, examinons la file d'attente :

% mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
9C26D779D0      351 Wed Jan 20 21:23:55  babe@alex.linux-france.org
(Name service error for domain cnam.fr: Host not found, try again)

N'étant relié à l'Internet qu'épisodiquement, via une connexion PPP à un fournisseur d'accès (F.A.I.), le domaine cnam.fr ne pourra être connu que lorsque nous serons connectés, par consultation du serveur de noms de notre F.A.I. Ce n'était pas le cas ici, et ce ne le sera pas souvent : pour économiser sur la facture téléphonique, on a tout intérêt à composer son courrier en étant déconnecté et à tout expédier d'un seul coup lors de la connexion suivante.

postfix nous prévient de cet état de fait grâce au message Name service error for domain cnam.fr de la commande mailq. Lors de notre prochaine connexion, il suffira simplement d'appeler la commande postfix flush (ou sendmail -q pour les nostalgiques...) pour que le courrier en attente soit à nouveau délivré.

Attention

sur ma machine, par exemple, seul root a le droit de faire postfix flush, un utilisateur normal devra utiliser /usr/sbin/sendmail -q pour envoyer les messages. La documentation de postfix vous expliquera pourquoi.

Lorsque l'on est, comme moi, connecté épisodiquement, le mieux est donc d'indiquer à postfix de déférer la délivrance des courriers. Ceux-ci seront alors placés dans la file d'attente et il ne tentera plus de les envoyer sauf si on le lui demande explicitement via un sendmail -q. Ce type de fonctionnement est tout à fait adapté aux connexions épisodiques (on peut mettre le sendmail -q dans un script de post-connexion) et est piloté par la variable defer_transports du fichier main.cf :

defer_transports = smtp

Ceux qui se sont longtemps battu pour contourner ce problème avec sendmail, le vrai, apprécieront cette simplicité...

Nous pouvons aussi aller directement inspecter le contenu des files d'attente de postfix : vous noterez alors que le numéro 9C26D779D0 apparaît en deux endroits :

Il existe une commande, assez primitive pour l'instant, appelée postcat qui permet d'afficher sous une forme plus lisible les messages dans les files de postfix.

Énoncé du problème

Vous avez passez probablement passé beaucoup de temps à trouver un nom pour votre chère machine, et vous êtes sûr d'avoir fait preuve d'imagination en l'ayant appelé warlordz.kill.windows : je doute que ce soit original, mais cela change de localhost.localdomain...

Quoi qu'il en soit, un problème va maintenant se poser : avec cette configuration, et un tel nom de machine, le champ From: de vos courriers sera, par exemple bugs@warlordz.kill.windows, ou lamer@warlordz.kill.windows. Cela ne posera pas de problème quand l'utilisateur bugs postera un courrier à lamer puisqu'il s'agira d'une délivrance locale, mais cela risque d'en poser lorsque bugs enverra un courrier à postmaster@site.serieux... En effet, pour éviter les courriers indésirables (aka SPAM ou UCE) postés par de tristes sires, le système de courrier de site.serieux a sûrement mis en place une protection toute simple : tout message dont l'adresse d'expéditeur n'appartient pas à un domaine connu sera directement mis au panier (il y a même des sites qui vont plus loin en bannissant les messages venant de domaines connus... pour être assez laxistes quant à l'émission de ces fameux SPAMs).

Qu'est-ce qu'un « domaine connu » ? Un domaine dûment enregistré auprès des instances de l'Internet et je suppose que vous n'avez pas payé le NIC pour déposer le domaine warlordz.kill.windows, non ? En conséquence, site.serieux, lorsqu'il recevra un message venant de votre domaine, recherchera dans ses tablettes s'il connaît ce nom et, comme ce ne sera pas le cas, votre précieuse missive ira se perdre dans les oubliettes de l'histoire, sans même que vous en soyez averti..

Un autre problème est que, même si le message n'était pas rejeté et que postmaster@site.serieux lui répondait, le message de réponse serait donc envoyé à bugs@warlordz.kill.windows. Là encore, le site n'étant pas connu, pas même de votre fournisseur d'accès, la réponse se perdra dans la nature (ou plutôt non, elle reviendra à postmaster@site.serieux, ce qui ne manquera pas de l'agacer...).

Pour corriger ces deux problèmes, il faut donc faire en sorte que l'adresse bugs@warlordz.kill.windows soit remplacée, lors de l'expédition du message par une adresse valide au sens de l'Internet, donc dûment déclarée.

Pour ce faire, nous supposerons que vous êtes abonné au fournisseur d'accès fai.fr (qui, lui, est enregistré et donc connu de tous les sites Internet). Lorsque vous vous êtes abonné, le fournisseur vous a octroyé un nom pour votre boîte aux lettres (selon les cas, c'est vous qui proposez le nom, ou bien lui qui vous l'impose). Admettons que cette adresse soit jdupont@fai.fr (ce qui, je vous l'accorde, est bien moins fun que bugs@warlordz.kill.windows... que les Dupont me pardonnent, mais ce n'est qu'un exemple).

Nous avons trois méthodes pour régler le problème :

La réécriture et le masquage du champ From:

postfix, comme son prédecesseur, permet de modifier le champ From:, qui contient l'adresse de l'expéditeur. Par défaut, cette option n'est pas active et il va donc falloir modifier notre configuration pour l'utiliser.

Le principe est très simple :

Et c'est tout... Il reste à notre ami Jean Dupont, euh... pardon, à bugs à envoyer un message de test (local ou à une adresse écho) afin de vérifier si la réécriture s'est bien effectuée.