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

Commençons par quelques bases théoriques à propos des domaines que Postfix peut manipuler. Postfix distingue entre trois sortes de domaines. C'est un concept très important que vous devez comprendre. Sans doute la moitié des demandes d'aide de lecteurs désespérés provient de la mauvaise compréhension de ce point. Donc s'il vous plaît ne sautez pas cette section et prenez le temps de comprendre son contenu.

Cette page est simplement destinée à expliquer le concept, vous n'aurez rien à faire sur votre serveur pendant sa lecture. Pour quelques explications encore plus embrouillantes voyez aussi la documentation sur les domaines virtuels du site de Postfix. :-)

Les domaines locaux

Postfix est le composant logiciel qui parle SMTP et envoit et reçoit les emails sur Internet. Typiquement Postfix connaît les domaines locaux et les utilisateurs locaux. Un utilisateur local est un utilisateur du système - un de ceux listés dans le fichier /etc/passwd. Cela signifie que tous les utilisateurs du système recevront des mails pour tous les domaines locaux. La variable de configuration mydestination contient la liste de tous les domaines locaux. Par exemple :

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

Disons que nous créons un utilisateur système « johndoe » (en utilisant la commande adduser). Cette simple action fera que Postfix recevra des mails pour :

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

Automatiquement Postfix recevra les mails pour ces adresses et les sauvera dans le répertoire /var/mail/johndoe. La limitation est que vous ne pouvez faire en sorte que le compte de johndoe ne fonctionne que pour un de ces domaines. On ne peut donc utiliser ce système pour différents utilisateurs sur différents domaines. Cela ne fonctionnera pas non plus avec de très nombreux utilisateurs car il faudrait créer autant de comptes sytème que d'utilisateurs. C'est toujours cependant une bonne idée que de configurer au moins un domaine local au cas de poblème de configuration ou de fonctionnement avec un autre type de domaine. Si vous ne vous sentez pas très créatif et que vous n'ayez pas réellement besoin d'un domaine local alors mydestination = localhost est un choix sûr.

Domaines de courier virtuels

Ce type de domaine est le plus important dans le cadre de ce guide. Un domaine de courrier virtuel (NdT : virtual mailbos domain en anglais) est un autre type de domaine utilisé pour recevoir du courrier électronique. Mais il n'utilise le fichier des utilisateurs système (/etc/passwd) pour désigner les adresses valides pour ce domaine. Au lieu de cela vous allez dire explicitement à Postfix quelles adresses sont valables. Une façon simple de configurer cela est d'utiliser des fichiers texte. Voyez la table de correspondance (NdT : mapping en anglais) suivante entre des adresses de réception de mail et des fichiers de boîte au lettre sur le disque (NdT : virtual_mailbox_maps en anglais).

Vous avez deux domaines : example.org et example.com. Il faut d'abord informer Postfix de l'existence de ces domaines. Ceci est effectué en mettant l'indication :

virtual_mailbox_domains = example.org example.com

dans votre configuration de Postfix. Vous devez ensuite informer Postfix des adresses mails pour lesquelles vous êtes prêt à recevoir du courrier et de l'endroit sur le disque où il doit ranger les courrier pour ces adresses. Le fichier devant recevoir ces informations devrait être /etc/postfix/virtual_mailbox_users et son contenu devrait 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 indiquées dans la colonne de gauche. Les emplacements sur le disque où stocker les emails pour chaque destinataire sont indiqués dans la colonne de droite. Dans la documentation de Postfix vous trouverez l'acronyme LHS pour « left hand side » (qui signifie côté main gauche), c'est à dire la colonne de gauche. Symétriquement RHS pour « right hand side » (côté main droite) correspond à la colonne de droite. Un tel fichier avec deux colonnes est appellé mapping ou hash table (NdT : mapping signifie littéralement cartographie et hash table est traduit par table de hachage).

Dans l'exemple ci-dessus j'ai simplement indiqué en dur dans le fichier de configuration de Postfix la configuration virtual_mailbox_domains = example.org example.com. Évidemment avec de nombreux domaines ceci n'est pas faisable. C'est pourquoi vous pouvez également utiliser un fichier de mapping pour configurer les domaines. Supposons que vous créiez un tel fichier, par exemple /etc/postfix/virtual_mailbox_domains, il devra ressembler à ceci :

example.org  OK
example.com  OK

Vous vous demandez peut-être pourquoi il ne suffit pas de lister simplement les domaines, un par ligne ? La raison est qu'un fichier de hachage doit toujours avoir deux colonnes. Dans ce cas d'un fichier de hachage concernant des données « uni-dimentionnelles » (une liste de domaines) Postfix ne s'occupe pas de la seconde colonne. Celle-ci pourrait contenir n'importe quoi à la place de la mention « OK », mais elle doit exister.

Si vous décidiez que ce système de fichiers texte est suffisant pour vos besoins il faudra encore les compiler en utilisant les commande postmap comme ceci :

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

postmap créera des fichiers supplémentaires portant les mêmes noms que ces fichiers mais avec un suffixe .db. Postfix ne le fait pas automatiquement, il faut le savoir, et Postfix n'obéit qu'aux fichiers *.db. N'oubliez donc pas de lancer la commande postmap après chaque modification d'une table de hachage. Pour que Postfix connaisse l'existence de ces fichiers vous devez rajouter ces lignes à son fichier de configuration main.cf :

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

Vous avez maintenant tous les outils nécessaires à la configuration de milliers de domaines et de comptes mail dans deux fichiers texte. C'est chouette. Mais en fait je vous ai promis que nous mettrions ces données dans une base MySQL. Par chance ce n'est pas beaucoup plus difficile que d'utiliser des fichiers texte. Souvenez-vous : une table de hachage est simplement un moyen d'associer une valeur à une autre. Tout ce que vous avez à faire est donc de demander à Postfix de prendre les deux colonnes de cette table de hachage dans deux colonnes d'une table d'une base de données. On fait cela avec des fichiers de congiguration en .cf (voyez aussi la page http://www.postfix.org/MYSQL_README.html ou lancez la commande « man 5 mysql_table » dans un shell).

Voici par exemple un fichier virtual_mailbox_maps.cf contenant :

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

 # Nom de la base MySQL à laquelle se connecter
 dbname = mailserver

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

Imaginez que vous ayez une table de base de données pour enregistrer vos utilisateurs virtuels avec deux colonnes. Le LHS est la colonne « email_address » de votre table et le RHS la colonne « mailbox_path ». La requête SQL ci-dessus récupère le RHS (correspondant au chemin du dossier de courrier, « mailbox_path ») à partir d'une adresse de courrier (« email_address ») qui correspond au LHS. Les caractères « %s » représentent le garde place par lequel est transmis à la requête la valeur du LHS à rechercher et qui est fournie par Postfix lors de chaque relève de courrier.

Note : ici une recherche ne doit retourner qu'une ligne de la base de données. Postfix n'a besoin que de savoir où se trouve le dossier de courrier d'une utilisateur donné. Il existe d'autres tables de hachage qui peuvent renvoyer plusieurs valeurs RHS pour une valeur de LHS donnée, donc plusieurs lignes de la base de données pour une requête, comme par exemple dans la recherche d'alias virtuels, comme nous allons le voir dans la section suivante.

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

virtual_mailbox_maps = mysql:virtual_mailbox_maps.cf

Si par la suite vous trouvez que cette table de hachage ne fait pas ce que vous attendiez qu'elle fasse, vous pouvez utiliser la commande « postmap -q » pour demander à Postfix quelle valeur de colonne droite correspond à une valeur de colonne de gauche donnée. Disons que vous voulez connaître la valeur du champ mailbox_path pour l'adresse john@example.org :

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

Postfix va alors lancer 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 le courrier directement. Au lieu de cela il passera la main à Dovecot sur les mails entrants. Nous n'utiliserons donc pas de virtual_mailbox_maps dans ce guide. Il n'en est pas moins important que vous compreniez comment Postfix traite les utilisateurs virtuels.

Domaines d'alias virtuels

Les domaines d'alias virtuels sont utilisés pour rediriger les courriers d'une adresse mail à une ou plusieurs autres adresses mail. Les domaines d'alias virtuels ne peuvent donc recevoir des emails et les enregistrer sur le disque de votre serveur. Ils se contentent de rediriger cet email ailleurs. La table de hashage virtual_alias_maps contient les redirections (source, destination) d'utilisateurs ou de domaines vers d'autres adresses email ou vers des domaines entiers. Incidemment les indications des virtual_alias_maps sont suivies par n'importe que email reçu. Du coup, dans la plupart des cas, vous n'avez par vraiment besoin de domaines d'alias virtuels puisque vous pouvez déclarer tous les domaines comme virtual mailbox domains et utiliser les tables de hashage d'alias virtuels pour les besoins de redirection. Techniquement, définir un domaine comme domaine d'alias virtuel a pour conséquence que Postfix accepte tous les emails pour ce domaine, mais vous avez toujours besoin d'une entrée dans la table de hashage virtual_alias_maps pour dire à Postfix où il doit renvoyer le mail.

A noter que les virtual_alias_maps peuvent retourner plusieurs destinations RHS (vers lesquelles transmettre le mail) pour une seule source LHS (le destinataire d'origine). Vous pouvez utiliser cette propriété pour transférer un mail vers plusieurs destinataires.

Exemple 1 : transférer tous les email à destination de john@example.org vers jeff@example.com

john@example.org   jeff@example.com

Ceci est un simple exemple. Vous avez la source (john@example.org) et le destinataire (jeff@example.com) de la redirection. John ne recevra jamais de courrier.

Exemple 2 : transférer tous les emails pour john@example.org vers jeff@example.com mais faire en sorte qu'il en reçoive lui aussi une copie.

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

Voilà qui est un peu plus rusé. Si Postfix interroge la table de hashage pour john@example.org il obtiendra deux résultats (Postfix est assez malin pour ne pas boucler mais pour comprendre que vous désirez une copie du mail). Ceci est l'équivalent d'une seule ligne contenant les destinataires séparés par des virgules :

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

Exemple 3 : transférer tous les courriers pour n'importe quel nom d'utilisateur dans le domaine example.org vers joe@example.com

@example.org   joe@example.com

C'est ce qu'on appelle un alias « catch-all » (Ndt : en français un attrape-tout). Il acceptera tous les mails pour n'importe quel utilisateur dans le domaine example.org et les renverra sur joe@example.com. Si par exemple jill@example.org ne correspond pas à un utilisateur virtuel explicitement défini, alors ce mails sera intercepté par l'alias attrape-tout et transféré vers l'adresse joe@example.com.

ATTENTION : ces alias attrape-tout (Catch-all) attrapent surtout du spam. Beaucoup de spam. Ils peuvent sembler pratiques parce qu'ils permettent de rediriger tous les mails vers une seule adresse sans avoir à créer d'aliases. Mais les spammeurs souvent tentent de deviner des adresses mail sur des domaines connus (par exemple en essayant des noms et prénoms courants etc.). Et avec un alias catch-all vous allez recevoir tout le spam destiné à ces tentatives de « devinettes » qui ne correspondent à aucun utilisateur réel. Évitez-les et définissez plutôt des adresses électroniques existantes. Même si cela représente davantage de travail.