Traduction de la page : https://workaround.org/ispmail/stretch/types-of-email-domains

Cette partie est la plus ennuyeuse mais aussi la plus importante de tout ce guide. La plupart des problèmes rencontrés par les lecteurs avec leur serveur de courrier sont causés par une mauvaise compréhension des différents types de domaines de mail. Vous n'avez pas à toucher à votre serveur pour le moment. Allongez-vous simplement et délassez-vous et assurez-vous de lire et de comprendre parfaitement cette page. Cela vous évitera des frustrations. Prêts ? C'est bien.

Postfix est le composant logiciel qui parle SMTP et envoit et reçois des mails, vers et depuis Internet. Il distingue trois sortes de domaines :

1. Les domaines locaux (local domains) ;
2. Les domaines virtuels (Virtual mailbox domains) ;
3. Les alias de domaines virtuels (Virtual alias domains).

Voyons ça en détail

Les domaines locaux (Local domains)

Dans les cas simples, Postfix utilise simplement un domaine local et des utilisateurs locaux. "local" ici fait référence au serveur. Un utilisateur local est simplement un utilisateur normal de la machine, un de ceux qui sont énumérés dans le fichier /etc/passwd. Tous les utilisateurs du système seront capables de recevoir des emails pour tous les domaines locaux. Supposons que vous disiez à Postfix que son domaine de mail local est "example.org" et que vous avez un utilisateur sur le système qui s'appelle "john". Postfix acceptera les mails pour johne@example.org est rangera les mails reçus dans le répertoire /var/mail/john. Cela pourrait sembler une bonne solution, mais elle a ses revers :

1. Vous devriez alors créer des comptes sur le système pour tous les utilisateurs désirant recevoir des mails. Chaque utilisateur sur le système représente un potentiel risque pour la sécurité car il peut avoir la possibilité de lancer un shell. Si l'utilisateur choisit un mot de passe faible cela revient exactement à inviter des attaquants à s'en prendre à vote système.
2. Si vous voulez héberger dix mille comptes mails, cela devient impossible.
3. Postfix ne peut distinguer les domaines locaux. Si vous avez trois domaines locaux example.org, example.com et example.net alors tous ces domaines aboutiront dans une seule et même boîte mail : john@example.org, john@example.com et john@example.net. Vous ne pourrez donc pas utiliser différents domaines pour des usages différents. Pour indiquer à Postfix quels domaines vous considérez comme local, vous les énumérez dans la rubrique de configuration mydestination dans votre fichier de configuration main.cf. Par exemple :

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

La chose la plus importante à garder à l'esprit est que vous ne devez jamais faire figurer dans mydestination aucun domaine qui sera un domaine virtuel. Vous auriez une alerte dans vos fichiers de log et Postfix se comportera bizarrement. Un domaine ne peut avoir qu'une seule utilisation.

Il est cependant courant d'utiliser le nom d'hôte du serveur en tant que domaine local. Si votre serveur s'appelle « scully.example.com » vous pourriez choisir mydestination = scully.example.com. Vous pouvez aussi choisir mydestination = localhost si vous voulez utiliser mydestination = scully.example.com en tant que domaine virtuel.

Les domaines virtuels (Virtual mailbox domains)

Ce type de domaine est celui que nous utiliserons le plus. Un domaine virtuel est destiné à recevoir du courrier. Mais vous n'utilisez pas les utilisateurs système (/etc/passwd) pour spécifier les adresses email valides à la différence des domaines locaux. À la place vous indiquez librement à Postfix quelles adresses vous considérez comme valides. On peut fournir ces informations à Postfix de plusieurs façons. Vous pouvez utiliser des fichiers texte, ou lui dire de récupérer cette information depuis une base de données. Mais le principe est toujours le même.

Observez le tableau suivant qui montre quelles adresses mail sont disponibles et où elles se situent sur le disque :

Vous avez deux domaines : example.org et example.com. La première chose à faire est de dire à Postfix que vous êtes prêt à recevoir des mails pour ces domaines. Cela se fait par le réglage ci dessous dans votre configuration de Postfix :

virtual_mailbox_domains = example.org, example.com

Ensuite vous devriez dire à Postfix pour quelles adresses mails vous acceptez de recevoir du courrier et où ranger les mails reçus sur le disque. Le fichier texte qui indique cela 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 constater le fichier a deux entrées par ligne. L'adresse mail est spécifiée dans la colonne de gauche. Et l'emplacement de rangement des mails sur le disque pour chaque destinataires est indiqué dans la colonne de droite. Dans la littérature technique concernant Postfix vous pourrez trouver l'abréviation 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. Ce genre de tableau avec deux colonnes est très courant dans le fonctionnement de Postfix. Il porte le nom de « mapping » (littéralement cartographie).

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 simplement noté en dur les domaines virtuels dans le fichier de configuration de Postfix (virtual_mailbox_domains = example.org, example.com). Évidemment avec beaucoup de domaines, ce n'est pas très pratique à utiliser. C'est pour cela que vous pouvez emmagasiner les informations à un autre endroit, tel une base de données ou un fichier texte. Mais si Postfix attend toujours des mappings à deux colonnes, alors comment allez vous spécifier une liste de domaines ? Postfix attend toujours deux colonnes, mais il ne fait pas forcément attention à ce que vous placez dans la seconde colonne. Un fichier texte listant des domaines pourrait ressembler à cela :

example.org  OK
example.com  OK

Le « OK » n'a pas de signification spéciale. Vous pouvez écrire ce que vous voulez tant qu'il existe une deuxième colonne.

Nous n'allons pas réellement utiliser des fichiers texte, nous allons utiliser une base de données MySQL. Mais si vous décidez d'utiliser des fichiers texte alors il faut savoir que Postfix ne peut accéder directement aux fichiers texte. Vous devez d'abord les compiler en leur appliquant la commande postmap comme ci-dessous :

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

Cela créra de nouveaux fichiers basés sur ceux ci-dessus mais avec un suffixe en .db. Postfix ne fait pas cette conversion automatiquement - c'est un avertissement général à garder en tête. Postfix ne lit que les fichiers *.db. Donc n'oubliez pas de lancer postmap après avoir changé un fichier de mappage.

Pour que Postfix sache que ces fichiers de mappage existent il faudrait ajouter les lignes suivantes à votre fichier de configuration :

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

(Non, ici vous n'utilisez pas le nom en .db. Postfix ajoutera le suffixe .db automatiquement.)

Vous me suivez encore ? Bien. Oublions les fichiers texte maintenant. Je vous ai promis que l'on rangerai nos informations de contrôle dans une base MySQL. Donc regardons comment tout ça fonctionne. Postfix attend toujours un fichier de mapping à deux colonnes comme on l'a vu ci-dessus. Mais au lieu de placer ces informations dans un fichier texte nous devons indiquer à Postfix où trouver ces deux colonnes dans la base de données. On réalise cela via des fichiers de configuration.

Par exemple le 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 le serveur MySQL
dbname = mailserver

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

Imaginez que vous ayez une base de données pour les utilisateurs virtuels avec deux colonnes. Le côté gauche (LHS) contient la colonne email_adresse que l'on trouvait dans le tableau. Et le côté droit (RHS) correspond à la colonne mailbox_path du tableau. C'est exactement la même chose que ce qu'on avait fait avec les fichiers texte. La requête SQL renvoit donc le LHS (mailbox_path) pour une adresse mail donnée (email_adress). Le %s est un garde place pour le LHS et est remplacé par Postfix par la valeur demandée à chaque interrogation de la base.

Notez bien ici que chaque interrogation de la base ne doit ramener qu'une seule ligne. Postfix a uniquement besoin de savoir quel est le chemin du dossier de la boîte mail d'un utilisateur donné. Il existe d'autres mappings où il est autorisé d'avoir plusieurs réponses RHS pour une donnée LHS. C'est le cas par exemple des alias virtuels comme nous allons le voir dans la section suivante.

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

virtual_mailbox_maps = mysql:virtual_mailbox_maps.cf

Si vous trouvez que ce mapping ne fonctionne pas comme vous l'espériez alors la commande postmap -q sera votre amie. Vous pouvez demander à Postfix la valeur RHS pour une valeur LHS donnée. Disons que vous voudriez connaître le chemin de la boîte mail de 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 comme argument votre john@example.org :

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

Le résultat devrait être :

/var/vmail/example.org/john/Maildir

Dans ce guide nous allons utiliser une légère variante de cette requête SQL :

query = SELECT 1 FROM virtual_users WHERE email='%s

Postfix est capable de ranger les mails arrivant directement sur le disque. Mais nous laissons Postfix transmetre le mail au programme Dovecot qui a des fonctionnalités supplémentaires. Du coup nous ne sommes pas réellement intéressés par le chemin de la boîte mail. Il nous suffit de savoir si une adresse est valide. Nous obtiendrons donc « 1 » comme résultat ce qui est suffisant pour que Postfix considère que l'adresse email est valide et accepte le courrier pour ce destinataire.

Les domaines d'alias virtuels (Virtual alias domains)

Dans une grande structure on vous demandera de créer des adresses mail qui renvoient les mails entrants vers une autre adresse. Ces adresses de redirection sont appelées alias. Si vous dites à Postfix qu'un certain domaine est un domaine d'alias virtuels vous lui indiquez que chaque adresse de ce domaine est un alias destinés à renvoyer le courrier entrant vers une autre adresse. Les mails pour ce domaine ne seront pas stockés sur le disque. Cela rend les domaines d'alias assez rigides. Je suis certain que vous aurez besoin d'alias mais que vous ne désirerez pas perdre un domaine entier pour ce besoin. C'est pourquoi nous n'utiliserons pas ce type de domaines sur notre serveur de mail.

Fort heureusement les adresses et les alias d'adresse peuvent toujours être mélangées dans un même domaine. Par exemple vous pouvez recevoir des mails pour john@example.org sur votre disque et faire de webmaster@example.org un alias qui transfère les mails à john. Dans ce cas nous déclarerons example.org comme boîte aux lettres virtuelle et pas comme domaine virtuel. Les alias fonctionneront pour les domaines de courrier standards.

Comme toujours vous aurez besoin d'une table à deux colonnes (un mapping) pour ces adresses de redirection. Et la syntaxe est assez simple :

alias-adresse1 destinataire-adresse1
alias-adresse2 destinataire-adresse2
alias-adresse3 destinataire-adresse3

Ça semble simple non ? C'est un mapping typique que nous définissons comme virtual_alias_maps dans Postfix. Ce mapping est plus souple, quoi que... Supposons que vous vouliez renvoyer les courriers reçus par une adresse d'alias à plusieurs destinataires. Postfix supporte que votre mapping retourne plusieurs destinataires en RHS pour une seule source LHS (le destinataire original). Quelques exemples :

Exemple 1 : rediriger tous les mails pour john@example.org vers jeff@example.com

john@example.org   jeff@example.com

Il s'agit d'un exemple simple. Vous avez la source (john@example.org) et la destination du transfert (jeff@example.org). John ne recevra jamais cet email.

Exemple 2 : rediriger tous les mails pour john@example.org vers jeff@example.com mais en en gardant une copie.

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

C'est un peu plus tordu. Si Postfix interroge le mapping pour john@example.org il obtiendra deux réponses. (Postfix est assez futé pour ne pas créer une boucle sans fin et comprendre que vous voulez garder une copie du mail). C'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 : rediriger tous les mails pour n'importe quel utilisateur dans le domaine example.org vers joe@example.com (catch-all) :

@example.org   joe@example.com

On appelle cela un alias « attrape-tout » (catch-all en anglais). Il acceptera les mails pour n'importe quel utilisateur dans le domaine example.org et les transmettra à joe@example.com. Si jill@example.org n'est pas un utilisateur déclaré explicitement en utilisateur virtuel, tout mail pour cette adresse inexistante devrait être rejeté, mais il sera pourtant récupéré par ce catch-all et transféré à joe@example.com.

Attention : les alias attrape-tout attrapent surtout du spam, beaucoup de spam. Ils peuvent sembler pratiques parce qu'ils transmettent tous les mails vers une seule adresse sans avoir besoin de créer quantité d'alias. Mais les spammeurs ont l'habitude d'essayer de deviner des adresses types sur un domaine donné. Et avec un catch-all vous recevrez le spam pour toutes ces adresses d'essai qui en fait n'existent pas. Évitez-les et définissez plutôt des adresses email existantes. Même si cela représente plus de travail.