URL: https://linuxfr.org/news/heberger-son-courriel-en-2018 Title: Héberger son courriel en 2018 Authors: Benoît Sibaud Davy Defaud, ZeroHeure et olivierweb Date: 2018年04月03日T22:28:54+02:00 License: CC By-SA Tags: spf, dkim, dmarc, courriel et smtp Score: 27 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](https://linuxfr.org/news/heberger-son-courriel), la [gestion du _spam_](https://linuxfr.org/news/spam-spam-spam-spam-et-aussi-le-spam#par-courriel) ou la [configuration TLS](https://linuxfr.org/news/du-chiffrement-et-de-la-securite-sur-linuxfr-org-statut-au-24-11-2013), 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 anti‐pourriel mis en place par les autres fournisseurs qui bloquent à tort des messages ; * des listes noires ou des [DNSBL/RBL](https://fr.wikipedia.org/wiki/DNS_Black_Listing "DNS Black Listing") ; * des services d’adresse de courriel temporaire ; * des serveurs primaire et secondaire de courriel ; * etc. Bref, le sujet est vaste. Il se dit que ce serait même un métier (et il se dit aussi que les professionnels et spécialistes se feront un plaisir de corriger ou compléter cette dépêche en cas d’oubli, d’erreur ou d’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 ? ---- [Blog de Seboss666 : Faire du mail en 2018, c’est une tannée...](https://blog.seboss666.info/2018/03/faire-du-mail-en-2018-cest-une-tannee/) [DLFP: Héberger son courriel (2013)](https://linuxfr.org/news/heberger-son-courriel) [Breaking DKIM - on Purpose and by Chance (2017)](http://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html) ---- Ici, on ne va pas raisonner en termes d’utilisateurs finals, d’émetteurs et de destinataires 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 et 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](https://fr.wikipedia.org/wiki/Sender_Policy_Framework "Sender Policy Framework") (qui peut émettre du courriel pour mon domaine), [DKIM](https://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail "Domain‐keys Identified Mail") (authenticité du domaine expéditeur et intégrité du message) et [DMARC](https://fr.wikipedia.org/wiki/DMARC "Domain‐based Message Authentication, Reporting and Conformance") (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, veuillez rejeter ce courriel_ »). Plusieurs cas se présentent à nous : ![Schéma](http://pix.toile-libre.org/upload/original/1525295248.png) # 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... ```smtp 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](https://linuxfr.org/statistiques/users#stats_courriel) (plus _linuxfr.org_) : Domaine | SPF | DMARC | DKIM | -------------|-----|-------|-----| 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 l’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](https://fr.wikipedia.org/wiki/Sender_Policy_Framework "Sender Policy Framework") `?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érents cas : les vraies boîtes d’utilisateurs, les boîtes techniques (_postmaster@_, _root@_, etc.). Et l’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. En revanche, 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 en revanche bien reçu par `linuxfr.example`). ## 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](https://sympa-community.github.io/manual/customize/dkim-arc.html) et [DMARC](https://sympa-community.github.io/manual/customize/dmarc-protection.html) pour Sympa (version >= 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). En revanche, 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 replacerai 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 et spécialistes se feront un plaisir de corriger ou compléter cette dépêche en cas d’oubli, d’erreur ou d’imprécision). » Et que je rappellerai 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é par notre Sympa, et qui était rejeté par GMail ; ainsi qu’une lettre quotidienne qui était subitement classée comme pourriel par Free, ce qui a entraîné une relecture et une modification de notre configuration.

AltStyle によって変換されたページ (->オリジナル) /