On va parler un peu des mails sur l'infra d'ATILLA. Vous allez voir, normalement c'est très simple.

• Le B-A BA des mails
• Généralités
• Mail-prod
  • Postfix
  • OpenDKIM
  • Rspamd
  • Mailman3
    • Core
    • Mailman3-web
    • Hyperkitty
• Configuration des autres machines

Le B-A BA des mails

Quand on parle de mail, il y a un certain jargon. Ci-après quelques notions rapides sur comment fonctionne l'échange de mails. Si jamais vous souhaitez en savoir plus, je vous encourage vivement à consulter la page Wikipédia du protocole SMTP, qui est assez sympa pour comprendre les bases.

Quand souhaite envoyer un mail, celui-ci va devoir passer par plusieurs intermédiaires avant d'arriver dans la boîte de réception de son destinataire.

Dans un premier temps, on écrit son mail, le plus souvent dans un client mail, qui peut venir soit sous la forme d'un logiciel que vous avez installé (Thunderbird par exemple) ou via un site web spécifique (par exemple GMail). On appelle ce client mail un Mail User Agent (MUA). C'est lui qui se charge de parler avec le serveur mail chez qui vous avez un compte pour récupérer vos mails, et les envoyer.

Quand votre MUA souhaite envoyer un mail, il va contacter un Mail Submission Agent (MSA) : c'est lui qui va vérifier que vous avez bien le droit d'envoyer un mail en tant que monmail@mondomaine.net. La vérification peut-être faite de plein de manières différentes. Le MSA peut se baser sur votre adresse IP, sur un identifiant et un mot de passe, sur un certificat, etc … La communication entre le MUA et le MSA se fait via le protocole Simple Mail Transfer Protocol (SMTP). C'est également ce protocole qui va être utilisé pour une bonne partie de l'acheminement du mail jusqu'à la boîte de réception de son destinataire.

Admettons que votre mail a été accepté par votre MSA. Celui-ci va transférer le mail à un Mail Transport Agent (MTA). Le MTA est aux mails ce qu'est un routeur au traffic IP : en fonction du nom de domaine du destinataire du mail, le MTA va contacter le MTA du domaine du destinataire pour lui transférer ce mail. En fonction de la configuration de la réception des mails chez le destinataire, ce second MTA peut choisir de contacter un troisième MTA, etc … jusqu'à ce que le mail arrive à son MTA final. Les communications entre les MTA s'effectuent avec le protocole SMTP, et le plus souvent, un MTA va déterminer à quel autre MTA un mail doit être transféré en se basant sur les enregistrements DNS du domaine du destinataire.

Finalement, lorsqu'un mail atteint son MTA final, il va être transféré à un Mail Delivery Agent (MDA) qui va «livrer» le mail dans sa destination finale. Dans le cas le plus simple, le mail sera stocké sur un serveur, dans un dossier ou dans un fichier correspondant au destinataire du mail. Le destinataire pourra ensuite récupérer ce mail via un client mail (MUA).

La page Wikipédia du protocole SMTP dispose d'un schéma qui synthétise le tout :

Généralités

À ATILLA, on peut envoyer des mails avec trois domaines :

• atilla.org
• eistiens.net
• tekiens.net

On a un serveur central, qui contient toute la configuration nécessaire pour faire sortir des mails de l'infra d'ATILLA, depuis ces trois domaines. Avant, ce serveur était un serveur physique, comme Bill ou Laïka. Cependant, de manière à ne pas trop dépendre d'une machine qu'on peut un jour dé-racker, nous avons migré cette gestion centrale des mails sur une VM, mail-prod.prod.infra.atilla.org.

C'est sur cette machine qu'on trouvera :

• La configuration sortante des mails
• Les clés pour signer les mails sortants
• La gestion des listes de diffusion
• …

Un dernier point : à ATILLA, on utilise Postfix comme MTA, et non Exim4, qui est le MTA par défaut des distributions Debian. Ce choix a été fait simplement car Postfix se trouve être plus simple à maintenir sur le long terme, avec une configuration moins touffue, et plus accessible.

Mail-prod

Postfix

Il s'agit du MTA de mail-prod, et c'est un peu la «plaque tournante» des mails d'ATILLA. La grande majorité de la configuration de Postfix est définie dans /etc/postfix/main.cf.

Dans cette configuration, on trouvera certains éléments importants, notamment :

• La liste des domaines pour lesquels on peut envoyer ou recevoir un mail depuis l'infrastructure
• Une configuration masquerade_domains, qui s'assure que les mails ne sortent pas de l'infrastructure d'ATILLA avec un nom de domaine qui ne passerait pas de vérification SPF ou DKIM. Typiquement, un mail envoyé d'une machine virtuelle avec une adresse type root@webstatic-prod.prod.infra.atilla.org va apparaître comme provenant de root@atilla.org s'il doit quitter l'infrastructure.
• La configuration milters. Un milter, c'est essentiellement un filtre qu'on va appliquer sur des mails entrants ou sortants. On utilise les milters pour signer les mails sortants avec OpenDKIM, et vérifier les mails entrants avec Rspamd.

OpenDKIM

Lorsqu'on envoie un mail à l'extérieur de notre infra, le MTA du destinataire doit pouvoir vérifier que le mail qu'il reçoit vient bien d'ATILLA : il s'agit de vérifier :

• qu'un mail venant d'atilla.org vient bien des propriétaires du domaine atilla.org
• qu'un mail venant de tekiens.net vient bien des propriétaires du domaine tekiens.net
• etc …

Pour effectuer cette vérification, il existe pluiseurs standards dont :

• Le Sender Policy Framework (SPF)
• Le DomainKeys Identified Mail (DKIM)
• Le Domain-based Message Authentication, Reporting and Conformance (DMARC)

Ici, OpenDKIM permet de gérer la partie … DKIM . Le DKIM fonctionne de la manière suivante :

• Tout d'abord, on crée une paire de clé publique / clé privée qu'on va utiliser pour signer l'en-tête des messages sortants de l'infra

• Dans les enregistrements DNS du domaine utilisé pour l'envoi des mails, on publie la clé publique que l'on vient de générer. Par exemple, pour le domaine atilla.org, la clé publique est publiée dans l'enregistement TXT de 2022._domainkey.atilla.org :

  caubin@t580:~ % dig +short TXT 2022._domainkey.atilla.org
  "v=DKIM1; h=sha256; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtsCEbOfzl7/sYohDqHK+TbrgRwVadggsIK38FjzuIf1yVEQpCsxpwLBRDmIaNrCn7iaxMTkiXkK5ybHhWvZKW/2TVlsS3rrGgeZVOyiAJz8k8F7EotmQBgciHaN/LUZonBNHNdhqiCYVy7+D8zbzcGxS05o0hTXV3TxuOY/Nmws6+i/htY8xi9+nqomK8ReStrDhkxnR5Sn0A/" "abZpm73zVIxvYJP7vAntWCds1vaYzXtesC92MMi+FdkY2c11Nq3zGpE67raJR/NfAccGDW4wVFYwIqXR75u18dVNkjsCN89FhpdsJFd908VzdWXqfhsnhe3s4StpvHxWpxC6+PNQIDAQAB"
• Ensuite, on configure OpenDKIM pour :
  • Qu'il signe l'en-tête From des messages sortants avec cette clé
  • Qu'il indique (également dans l'en-tête du mail) l'identifiant de la clé à utiliser (ici, il s'agit de 2022._domainkey)
• Lorsque le MTA de destination reçoit le mail, il va vérifier la signature de l'en-tête From avec la clé publique qu'il récupèrera via une requête DNS.

Rspamd

Mailman3

Core

Mailman3-web

Hyperkitty

Configuration des autres machines

Les autres machines de l'infrastructure ont leur configuration mail définie automatiquement via Puppet : chaque machine va disposer d'un serveur Postfix qui transfère tous les mails de la machine à mail-prod, qui se charge ensuite de la re-distribution.

L'exception à cette règle, c'est Bill : il s'agit du MTA utilisé comme point d'entrée pour les mails de l'infrastructure. Sa configuration est très simple : il redirige tous ses mails (à l'exception de ceux destinés explicitement à bill.atilla.org) vers mail-prod, qui ensuite se débrouille.