Une petite présentation des différents types de domaines pour les emails.

Postfix distingue trois sortes de domaines. Il s'agit d'un concept très important qu'il faut que vous compreniez. À-peu-près la moitié des questions posées par des lecteurs désespérés provient d'une mauvaise compréhension des concepts exposés ci-dessous. Cette page est uniquement pédagogique, elle ne contient aucune instruction à directement appliquer sur votre serveur. Voyez également la documentation sur les domaines virtuels du site web de Postfix.

Domaines locaux

Postfix est le composant logiciel qui « parle » SMTP et qui reçoit et envoie les mails depuis Internet. De façon classique Postfix connaît les domaines locaux (local domains dans la terminologie anglaise) et les utilisateurs locaux (local users dans la terminologie anglaise). Un utilisateur local est simplement un utilisateur normal du système - un de ceux listés dans le fichier /etc/passwd. Cela implique que tous les utilisateurs du système recevront des courriels de n'importe quel domaine local. L'option de configuration « mydestination » contient la liste de tous les domaines locaux. Par exemple vous pouvez avoir configuré...

mydestination = example.org, example.com, example.net

Admettons que vous ayez créé un utilisateur johndoe sur le système (en utilisant la commande adduser). Ce simple paramètrage autorisera Postfix à recevoir des mails pour :

• johndoe@example.org
• johndoe@example.com
• johndoe@example.net

Vous ne pouvez pas faire en sorte que le compte de johndoe ne fonctionne qu'avec un seul domaine. On ne peut utiliser cette configuration pour différents utilisateurs dans différents domaines. Cela ne fonctionnera pas non plus avec de très nombreux utilisateurs, car il faudrait leur créer à chacun un compte sur le système. C'est toujours une bonne idée que de configurer au moins un domaine local, en cas de difficulté de configuration ou de problèmes d'utilisation avec les autres types de domaines. Si vous manquez d'inspiration mydestination = localhost sera un bon choix. Postfix reçoit automatiquement les courriels pour ces utilisateurs et les sauve dans /var/mail/USERNAME.

Domaines Virtuels

Ce type de domaines est le type le plus important dans ce guide. Un domaine virtuel pour le courrier électronique est un domaine destiné à recevoir des courriels, mais qui n'utilise pas d'utilisateurs système (/etc/passwd) pour spécifier les adresses valides pour ce domaine. À la place vous dites explicitement à Postfix quelles sont les adresses à prendre en compte pour ce domaine. Une manière simple de configurer un tel domaine et ses utilisateurs est d'utiliser des fichiers texte. Considérons l'ensemble suivant d'adresses de réception de courriel sur le disque :

Vous avez deux domaines : example.com et exemple.org. La première chose à faire est d'indiquer à Postfix quels sont ces domaines. Ceci est obtenu par ce règlage dans votre configuration de Postfix :

virtual_mailbox_domains = example.org example.com

Ensuite vous devez dire à Postfix quelles sont les adresses pour lesquels vous êtes prêt à recevoir du courrier, et à quel endroit entreposer ces courriers sur le disque. Le fichier texte correspondant pourrait être placé dans /etc/postfix/virtual_mailbox_users et ressembler à ceci :

john@example.org  /var/vmail/example.org/john/Maildir
jack@example.org  /var/vmail/example.org/jack/Maildir
jack@example.com  /var/vmail/example.com/jack/Maildir

Comme vous pouvez le voir les adresses mail valables sont spécifiées dans la colonne de gauche. Et l'emplacement de stockage sur le disque pour chaque destinataires est indiqué dans la colonne de droite. Dans la littérature technique concernant Postfix vous pourrez trouver l'acronyme LHS pour l'anglais « Left Hand Side » (littéralement côté à main gauche) pour indiquer la colonne de gauche. Symétriquement RHS pour « Right hand side » (littéralement côté à main droite) indique la colonne de droite. Une telle table avec deux colonnes est également appellée « mapping » (littéralement cartographie) ou table de hash (on utilise parfois en français le néologisme anglicisant « table de hashage »).

NOTE DE TRADUCTION : j'ai fait le choix dans la traduction de conserver quelques termes anglais comme « mapping », qui d'une part n'ont pas de traduction aussi concises que le terme anglais et qui surtout se retrouvent généralement dans toute la documentation technique. Une recherche sur Google avec Postfix et mapping donnera davantage de résultats pertinents qu'avec une périphrase du type « table d'allocation » ou « table de désignation ».

Dans l'exemple ci-dessus j'ai juste écris directement les domaines virtuels dans le fichier de configuration de Postfix (virtual_mailbox_domains = example.org example.com). Malheureusement avec de nombreux domaines ce n'est plus faisable. il vous faut donc également utiliser un fichier de « mapping » pour configurer les domaines. Admettons que vous l'ayez enregistré dans /etc/postfix/virtual_mailbox_domains et qu'il ressemble à cela :

example.org  OK
example.com  OK

Vous pouvez vous demander pourquoi on ne se contente pas de lister les domaines à raison d'un par ligne. La raison est qu'un fichier de « mapping » doit toujours avoir deux colonnes. Dans le cas « unidimentionnel » de la liste des domaines, Postfix ne s'occupe pas de la seconde colonne. Elle ne doit d'ailleurs pas obligatoirement contenir OK, en fait n'importe quelle chaîne de caractères peut convenir, mais il en faut une.

Si vous décidez que de tels fichiers textes conviennent à votre usage il vous reste encore à les compiler avec la commande postmap comme ceci :

postmap /etc/postfix/virtual_mailbox_domains
postmap /etc/postfix/virtual_mailbox_users

Postmap va créer des fichiers supplémentaires, dont le nom sera basé sur celui des fichiers ci-dessus, mais avec une extension .db. Postfix ne le fait pas automatiquement, c'est une erreur courante que d'oublier de les générer. Postfix n'obéira qu'aux fichiers *.db. Donc il ne faut pas oublier de lancer postmap après chaque changement d'un fichier de « mapping ». Pour faire connaître à Postfix ces « mappings » vous devriez rajouter ces lignes à votre fichier de configuration main.cf :

virtual_mailbox_domains = hash:/etc/postfix/virtual_mailbox_domains
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_users

Maintenant vous avez tous les outils nécessaires pour configurer des centaines de domaines et de comptes de courrier dans deux fichiers texte. C'est bien. Mais en fait j'avais promis que nous stockerions ces données dans une base de données MySQL. Heureusement ce n'est pas beaucoup plus compliqué que d'utiliser des fichiers texte comme ci-dessus. Souvenez-vous qu'un « mapping » est simplement un moyen pour assigner une valeur à une autre. Donc tout ce que nous avons à faire est de dire à Postfix comment accéder aux deux colonnes du « mapping » depuis une table de base de données. Pour faire cela il faut utiliser les fichiers .cf de Postfix (regardez également http://www.postfix.org/MYSQL_README.html ou lancez man 5 mysql_table dans une console.)

Example de fichier virtual_mailbox_maps.cf :

# Informations de connexion au serveur MySQL
user = someone
password = some_password
hosts = 127.0.0.1

# Le nom de la base de données sur les serveur MySQL
dbname = mailserver

# La requête SQL
query = SELECT mailbox_path FROM virtual_users WHERE email_address='%s'

Imaginez que vous ayez une table de base de données pour les utilisateurs virtuels qui contient deux colonnes. Le LHS (côté gauche) est la colonne email_adress dans cette table. Et le RHS (côté droit) correspond à la colonne mailbox_path dans cette table. Du coupt cette requête SQL récupère le RHS (mailbox_path) pour une certaine adresse de courriel (email_adress). Le "%s" est un garde place pour le LHS et est remplis par Postfix à chaque requête.

Notez qu'une requête ici doit renvoyer uniquement un tuple de la base de données. Postfix doit simplement savoir où se trouve le chemin de la boîte à lettres pour un utilisateur donné. Il existe d'autres « mappings » où il est permis d'avoir plusieurs éléments dans le RHS pour un même LHS - par exemple pour les « alias virtuels » que nous allons voir dans la section suivante.

Pour utiliser le fichier de configuration ci-dessus vous devez le déclarer dans le fichier de configuration de Postfix main.cf :

virtual_mailbox_maps = mysql:virtual_mailbox_maps.cf

Si par la suite vous trouvez que ce « mapping » n'a pas l'effet que vous attendez, la commande postmap -q pourra vous permettre de savoir quelle RHS est renvoyée pour un LHS donné. Disons que vous cherchiez la valeur de mailbox_path pour une email_adress contenant « john@example.org » :

postmap -q john@example.org mysql:virtual_mailbox_maps.cf

Postfix lancera la requête SQL ci-dessus avec votre argument « john@example.org » :

SELECT mailbox_path FROM virtual_users WHERE email_address='john@example.org'

Le résultat devrait être :

/var/mail/example.org/john/Maildir

Note : dans ce guide nous ne laisserons pas Postfix délivrer les courriels directement. Il reviendra à Dovecot de délivrer les courriels entrants. Nous n'utiliserons donc pas le fichier virtual_mailbox_maps dans ce guide. Il reste cependant important de comprendre comment Postfix gère les utilisateurs virtuels.

Domaines virtuels d'alias

Les domaines virtuels d'alias sont utilisés pour transférer des courriels depuis une adresse vers une ou plusieurs autres. Les domaines virtuels d'alias ne reçoivent pas directement de courriels. Ils ne font que les transférer ailleurs. Les « mappings » virtual_alias_maps contiennent les informations de transfert (source, destination) d'utilisateurs ou de domaines vers d'autres utilisateurs ou des domaines entiers.

Incidemment les virtual_alias_maps sont sollicités par tous les courriels entrants. Ainsi dans la plupart des cas vous n'avez pas réellement besoin d'alias virtuels de domaines puisque vous pouvez déclarer tous les domaines comme des domaines de courrier virtuels et utiliser le « mappings » virtual_alias_maps pour indiquer à Postfix où renvoyer le courriel.

Une remarque sur les virtual_alias_maps : ils peuvent renvoyer plusieurs destinations (RHS vers lesquelles transférer) pour un LHS (le destinataire original). Vous pouvez utiliser cela pour transférer un courrier à plusieurs destinataires et contrôler si vous désirez en garder une copie.

Exemple 1 : transférer tous les courriels pour john@example.org vers jeff@example.com

john@example.org   jeff@example.com

Celui-ci est simple. Vous avez la source (john@example.org) et (jeff@example.com) la destination de transfert. John ne verra jamais le courriel.

Exemple 2 : transférer tous les courriels pour john@example.org vers jeff@example.com mais également en recevoir une copie

john@example.org   john@example.org
john@example.org   jeff@example.com

C'est un peu plus biscornu. Si Postfix interroge ce « mapping » pour john@example.org il obtiendra deux résultats. (Postfix est assez malin pour ne pas créer une boucle mais comprendre que vous voulez envoyer une copie du courriel.) Le résultat est le même que si l'on avait une seule ligne avec les destinataires séparés par une virgule :

john@example.org   john@example.org, jeff@example.com

Exemple 3 : transférer tous les courriels destinés à example.org vers joe@example.com

@example.org   joe@example.com

C'est ce que l'on appelle un alias catch-all en anglais (littéralement attrape tout). Il acceptera tous les courriels pour n'importe quel utilisateur dans le domaine example.org et les transfèrera vers joe@example.com. Si jill@example.org n'est pas un utilisateur virtuel explicitement déclaré alors les courriels qui lui sont destinés seront interceptés par l'alias catch-all et renvoyés à joe@example.com.

Attention : les alias catch-all récupèrent du pourriel. Beaucoup de pourriels. Ils peuvent sembler pratiques car ils transfèrent tous les courriels à une seule personne sans avoir besoin de créer d'autres alias. Mais les spammeurs essaient souvent de deviner des noms d'utilisateur pour un domaine connu. Et avec un alias catch-all vous allez recevoir le pourriel pour chacune de ces tentatives. Essayez de les éviter et définissez plutôt des adresses mail valides. Même si cela semble représenter plus de travail.