Héberger son courriel en 2018

Cette dépêche n’a pas vocation à parler de tous les aspects du courriel : certains ont déjà été évoqués précédemment comme la configuration de base, la gestion du spam ou la configuration TLS, par exemple. On pourrait aussi parler

  • des fournisseurs de courriel qui limitent le nombre de courriels par seconde qu’ils acceptent en entrée (ce qui ralentit pas mal la distribution des messages sur une liste de diffusion, par exemple la lettre quotidienne de LinuxFr.org)
  • des divers filtres antispam mis en place par les autres fournisseurs qui bloquent à tort des messages
  • des listes noires ou des DNSBL/RBL
  • des services d’adresse de courriel temporaire
  • des serveurs primaire et secondaire de courriel

Bref le sujet est vaste, il se dit que ce serait même un métier (et il se dit aussi que les professionnels/spécialistes se feront un plaisir de corriger/compléter cette dépêche en cas d’oubli/erreur/imprécision).

Mais quelle serait la problématique, disons… d’une association de bénévoles passionnés qui voudraient avoir leurs propres serveurs de courriel et de listes de diffusion. Et qui voudraient interagir avec le reste du monde.

Sommaire

Ici on ne va pas raisonner en termes d’utilisateurs finaux / émetteurs / récepteurs des courriels, mais en termes de serveurs de courriel. Intéressons-nous à notre association fictive et baptisons ses serveurs/services linuxfr.example et lists.linuxfr.example (les deux pouvant être séparés ou fusionnés, ce qui a des conséquences sur les possibilités de redondance primaire/secondaire, ou la réécriture des alias par le gestionnaire de messagerie, sachant que l’on ne veut exposer que du @linuxfr.example).

On va causer SPF (qui peut émettre du courriel pour mon domaine), DKIM (authenticité du domaine expéditeur et intégrité du message) et DMARC (politique pour faire appliquer SPF et DKIM, et gérer les erreurs). La politique DKIM ou SPF peut être inexistante, tolérante (« si ce n’est pas comme prévu, ce n’est pas grave ») ou stricte (« si ce n’est pas comme prévu, rejetez svp ce courriel »).

Plusieurs cas se présentent à nous.

Schéma

Exemples de politiques

Politiques visibles dans les courriels reçus

L’en-tête Authentication-Results dans le courriel reçu permet d’avoir une vision au niveau DKIM/SPF : par exemple le champ spf pourra prendre des valeurs comme none (pas de politique), pass (ok), softfail (pas bon mais tant pis), etc. Le champ dmarc pourra aussi prendre des valeurs none, pass ou fail. De même pour le champ dkim on pourra trouver fail, neutral, none, pass, temperror, permerror. Évidemment ça suppose que le courriel est reçu, et non rejeté en amont…

Authentication-Results: someserver; auth=pass smtp.auth=xxxx
Authentication-Results: someserver; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dkim=fail reason="verification failed; insecure key"
Authentication-Results: someserver; dkim=neutral reason="verification failed; insecure key/testing"
Authentication-Results: someserver; dkim=none reason="no signature"; dkim-adsp=fail (insecure policy); dkim-atps=neutral
Authentication-Results: someserver; dkim=pass (1024-bit key; secure) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dkim=pass header.i=xxx header.s=xxx header.b=xxx;
Authentication-Results: someserver; dkim=pass reason="2048-bit key; unprotected key"
Authentication-Results: someserver; dkim=permerror (0-bit key) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dkim=permerror (bad message/signature format)
Authentication-Results: someserver; dkim=permerror reason="key not found"
Authentication-Results: someserver; dkim=temperror (0-bit key; unprotected) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dmarc=fail header.from=xxxx
Authentication-Results: someserver; dmarc=none header.from=xxxx
Authentication-Results: someserver; dmarc=pass header.from=xxxx
Authentication-Results: someserver; spf=none (sender IP is xx.xx.xx.xx) smtp.mailfrom=xxxx;
Authentication-Results: someserver; spf=pass (sender IP is xx.xx.xx.xx) smtp.mailfrom=xxxx
Authentication-Results: someserver; spf=softfail (sender IP is xx.xx.xx.xx) smtp.mailfrom=xxxx; dkim=fail (signature did not verify)

On va aussi trouver des informations intéressantes dans les en-têtes DKIM-Filter:, DKIM-Signature: et Received-SPF: (et aussi d’autres parfois comme X-DKIM:, X-Google-DKIM-Signature:, X-Original-DKIM-Signature:, X-Original-DMARC-Record:, etc.).

DKIM-Filter: OpenDKIM Filter v2.11.0 mx2.ac-nancy-metz.fr 10D63249F
DKIM-Filter: OpenDKIM Filter v2.9.2 webmail.ntymail.com A4EC71E4121
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
Received-SPF: None (…)
Received-SPF: Pass (…)
Received-SPF: SoftFail (…)

Les politiques annoncées

Prenons les politiques annoncées (via DNS) pour (un des domaines des) dix fournisseurs de courriel les plus utilisés par nos visiteurs (plus linuxfr.org) :

Domaine SPF DMARC SPF
gmail.com v=spf1 redirect=_spf.google.com / v=spf1 include:_netblocks.google.com (…) ~all v=DMARC1; p=none; sp=quarantine; rua=mailto:(…) k=rsa; p=(…2048 bits…)
free.fr N/A N/A N/A
yahoo.com v=spf1 redirect=_spf.mail.yahoo.com / v=spf1 ptr:yahoo.com ptr:yahoo.net ?all v=DMARC1; p=reject; pct=100; rua=mailto:(…); k=rsa; p=(…2048 bits…)
hotmail.com v=spf1 ip4:157.55.9.128/25 include:spf.protection.outlook.com (…) ~all v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:(…); ruf=mailto:(…); fo=1 ?
laposte.net v=spf1 include:_spfbloc1.laposte.net (…) mx -all v=DMARC1;p=quarantine;sp=reject;rua=mailto:(…);ruf=mailto:(…);rf=afrf; v=DKIM1; k=rsa; p=(…2048 bits…)
wanadoo.fr N/A N/A N/A
orange.fr N/A N/A N/A
gmx.de v=spf1 ip4:213.165.64.0/23 (…) -all N/A
no-log.org N/A N/A N/A
protonmail.ch v=spf1 include:_spf.protonmail.ch ~all v=DMARC1; p=quarantine; fo=1; v=DKIM1; k=rsa; p=(…1024 bits…)
linuxfr.org v=spf1 a mx ~all v=DMARC1; p=none; fo=0; adkim=r; aspf=r; pct=100 v=DKIM1; k=rsa; p=(…2048 bits…)

On voit (enfin si on sait un minimum lire les politiques) que l’on trouve un peu de tout, entre rien et tout, du tolérant au très strict (par exemple pour SPF ?all est neutre, ~all signale uniquement les échecs et -all rejette).

Embrouillons tout ça

L’envoi entre tiers sans intérêt

alice.example envoie du courriel n’ayant aucun rapport avec linuxfr.example à bob.example. Rien de particulier à dire, et l’exemple est assez peu pertinent ici.

La réception directe

alice.example envoie du courriel à linuxfr.example, qui va respecter la politique SPF/DKIM de alice.example.

Cela couvre différent cas : les vraies boîtes d’utilisateur, les boîtes techniques (postmaster@, root@, etc.). Et on peut inclure les échanges avec le gestionnaire de listes de diffusion lui-même ((dés)abonnement, accès aux archives par courriel, etc.) ou tous les autres robots du même genre.

Par contre, si le courriel tente de se faire passer comme provenant de linuxfr.example (ou lists.linuxfr.example), c’est alors la même politique de linuxfr.example (ou de lists.linuxfr.example) qui sera respectée, conduisant vraisemblablement au rejet.

La réception sur alias pointant vers un autre domaine

alice.example envoie du courriel à l’adresse bob@linuxfr.example, qui est un alias de bobby@bob.example. linuxfr.example va se décider suivant la politique SPF/DKIM de alice.example ; et si ça passe, bob.example va voir arriver du courriel de linuxfr.example prétendant venir de alice.example. bob.example pourrait donc accepter ou rejeter suivant la politique SPF ou DKIM de alice.example (si les courriels en réponses partiront bien vers alice.example, le message de rejet sera bien reçu par linuxfr.example par contre).

La réception sur une liste de discussion/diffusion

alice.example envoie du courriel à team@lists.linuxfr.example, qui est une liste de diffusion/discussion. linuxfr.example va se décider suivant la politique SPF/DKIM de alice.example. Et maintenant il doit diffuser vers tous les abonnés à la liste. Deux grands choix s’offrent à lui :

  • il rajoute ses propres infos au courriel mais sans modifier les infos initiales ; se faisant il prétend être alice.example devant plein de fournisseurs différents. Il court alors le risque que la politique SPF/DKIM de alice.example soit stricte et l’interdise. Auquel cas il reçoit des messages de rejet, et certains abonnés (ceux des fournisseurs qui respectent les politiques DKIM/SPF) ne recevront pas le message initial.
  • il modifie le courriel pour dire que c’est lui qui l’envoie. Auquel cas il est plus ou moins difficile de répondre à alice.example (le nom ou l’adresse peuvent être masqués par exemple).

Par exemple voir le paramétrage DKIM et DMARC pour Sympa >= 6.1.

L’envoi direct

linuxfr.example envoie un courriel à alice.example, qui peut (ou non) le vérifier par rapport à la politique SPF/DKIM de linuxfr.example. Dans cette catégorie, on va trouver les envois depuis les comptes des utilisateurs, les envois automatiques (cron par exemple) et autres robots.

L’envoi depuis le mauvais serveur à un tiers

alice.example envoie du courriel à bob.example en prétendant envoyer un message de la part de admin@linuxfr.example (ça peut être légitime s’il s’agit de l’utilisateur admin@linuxfr.example qui envoie son courriel via son propre fournisseur alice.example, ou ça peut être frauduleux comme un spammeur usurpant cette adresse par exemple). Si bob.example ne prend pas de précautions particulières, le message sera diffusé. Si maintenant bob.example respecte la configuration SPF ou DKIM de linuxfr.example, alors le message pourra être rejeté (suivant ladite configuration). Par contre on voit que linuxfr.example ne peut pas faire grand-chose si bob.example ne respecte pas la politique qui a été mise en place.

L’envoi depuis le gestionnaire de listes de diffusion

lists.linuxfr.example peut transiter par linuxfr.example pour envoyer un courriel à alice.example, qui peut (ou non) vérifier les politiques SPF/DKIM des deux domaines. Dans cette catégoire, on va trouver par exemple l’envoi de la version agrégée des échanges d’une liste de diffusion.

Conclusion

Normalement à ce stade, vous devriez vous dire que le courriel en 2018 c’est trivial et mettre en place votre propre infrastructure, avec serveur d’envoi et serveur de listes de discussion… Ou vous poser des questions du type puis-je utiliser la politique SPF d’un domaine pour écrire sur un alias, me faire rejeter volontairement mon courriel et en déduire le domaine de l’adresse cachée derrière l’alias. Ou bien avoir envie d’une aspirine.

C’est là que je replacerais subrepticement cet extrait de l’introduction de cette dépêche :

« Bref le sujet est vaste, il se dit que ce serait même un métier (et il se dit aussi que les professionnels/spécialistes se feront un plaisir de corriger/compléter cette dépêche en cas d’oubli/erreur/imprécision). »

Et que je rappellerais qu’une association de bénévoles passionnés ayant ses propres serveurs de courriel et de listes de diffusion rencontre parfois deux ou trois difficultés, mais que c’est très formateur. C’est d’ailleurs l’origine de cette dépêche : un courriel envoyé sur une liste LinuxFr.org depuis un domaine avec une politique SPF stricte, relayé tel que par notre Sympa, et qui était rejeté par GMail ; ainsi qu’une lettre quotidienne qui était subitement classée comme spam par Free ce qui a entraîné une relecture et une modification de notre configuration.

Commentaires :
voir le flux atom
ouvrir dans le navigateur

(Source: LinuxFr.org : les dépêches)
Logo