site web forum documentation

CLUB1.FR

🇬🇧

Transfert d'email & Sender Policy Framework

Soit la configuration de SRS pour réparer ce que SPF a cassé

La première mise en place des emails n'était déjà pas une mince affaire. En effet, le système de courrier éléctronique se rapproche plus d'un patchwork de RFC qu'à un protocole tant il est rapiécé de toutes part. Il est vrai qu'on pourrait le dire d'un certain nombre de protocole d'internet, après tout c'est la manière dont ils sont créés, par itérations successives. Mais les emails conservent tout de même une place particulière.

Prenons par exemple le Web, utilisant le protocole HTTP. Comme pour SMTP, l'authentification n'a pas du tout été prise en compte dans les premières itérations du protocole, ce n'est qu'en passant à HTTPS que les réponses sont authentifiées. Mais une fois que HTTPS est configuré dans les options du serveur Web, c'est bon, le protocole est correctement sécurisé.

Pour SMTP il ne suffit pas de passer à une version sécurisée, il faut configurer plusieurs mécanismes d'authentification, les fameux SPF, DKIM et DMARC évoqués dans l'article [email]. Or aucun de ces mécanismes n'est intégré aux serveurs SMTP classiques, il faut les installer et les configurer chacun séparément.

Après avoir configuré ces trois mécanismes on peut enfin prétendre à un système d'authentification fonctionnel (après-tout il a correctement fonctionné jusqu'à aujourd'hui), mais c'est au moment de documenter une fonctionnalité de redirection que l'on s'est rendu compte d'un problème.

Pour faire simple :

  • SPF permet de lister les adresses IP des serveurs autorisés à envoyer des emails au nom d'un domaine.
  • DKIM permet de signer les emails pour garantir leur provenance (on peut déjà se poser la question de l'utilité de SPF lorsque les emails sont signés avec DKIM).
  • DMARC permet d'indiquer aux autres serveurs ce qu'ils doivent faire lorsque l'une ou l'autre de ces authentifications est invalide.

Tout cela fonctionne très bien dans les cas simples où le serveur qui envoie l'email est celui de l'auteur. Dans le cas d'une redirection en revanche, l'email passe par un serveur intermédiaire.

Ça ne pose aucun problème pour DKIM, car le serveur intermédiaire n'a pas à toucher au contenu du message, ni à sa signature. Au contraire, DKIM apporte ici un avantage supplémentaire permettant de garantir que le message n'a pas été altéré lors de sa redirection en plus de garantir qu'il a bien été émis par le bon serveur.

SPF par contre va échouer lamentablement, car le serveur intermédiaire n'est évidemment pas autorisé à envoyer des emails au nom des autres domaines. Comme ils le disent eux-même :

SPF "breaks" email forwarding.

SPF "casse" la redirection d'email.

OK.

SRS is a way to fix it.

SRS est un moyen d'y remédier.

Voilà autre chose, Yet Another Patch pour SMTP...

Bon en gros il s'agit presque d'un hack qui consiste à créer à la volée des adresses en @club1.fr pour tous les emails transférés, ce qui permet de faire croire que le message provient bien du bon serveur. Et il s'agit de la solution officiellement proposée par open-spf.org. De mon point de vue la solution serait plutôt de laisser tomber SPF et de ne garder que DKIM. Pour ceux qui voudraient une explicaiton plus détaillée (avec des jolies illustrations) voici un article (en anglais) qui explique SPF, SRS (et même DKIM).

Heureusement, l'installation et la configuration de SRS est plutôt aisée de nos jours, comme le montre cet article de Debian Facile. En résumé (le tout en root) :

apt-get install -y postsrsd
postconf -e "sender_canonical_maps = tcp:localhost:10001"
postconf -e "sender_canonical_classes = envelope_sender"
postconf -e "recipient_canonical_maps = tcp:localhost:10002"
postconf -e "recipient_canonical_classes= envelope_recipient,header_recipient"
systemctl reload postfix

C'est pas très joli, mais au moins ça fonctionne, ce qui permet de profiter de la fonctionnalité nouvellement documentée du fichier .forward !

Tous les articles CLUB1 concernant les emails :

Cet article à été consulté 982 fois