Sommaire
J’héberge mon propre courrier électronique. Le faire correctement n’est pas une chose triviale à faire et on est amené à apprendre l’existence de plusieurs mécanismes. Ce matin, j’ai reçu un courriel de non-livraison étrange de la part de Gmail et c’est l’occasion de parler de ces mécanismes, puis on décortiquera ce courriel étrange.
SPF, DKIM, et DMARC
Ces trois technologies servent à lutter contre le courrier indésirable.
SPF : Sender Policy Framework
SPF prend la forme d’un enregistrement DNS sur un nom de domaine. Cet enregistrement définit la liste des adresses IP autorisées à envoyer du courriel en utilisant ce nom de domaine. On peut être plus ou moins strict.
Voici par exemple mon entrée SPF, anonymisée :
$ dig example.org TXT
[…]
example.org. 600 IN TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -all
[…]
Je donne mon adresse IPv4, mon adresse IPv6, et -all indique que n’importe quel autre expéditeur doit être rejeté, et de façon stricte à cause du tiret « - ».
Si j’avais voulu dire « Si vous recevez un courriel d’une autre adresse, peut-être que celui-ci est illégitime », j’aurais plutôt mis un tilde « ~ ».
Pour plus de détails, voir par exemple [https://fr.wikipedia.org/wiki/Sender_Policy_Framework].
DKIM : DomainKeys Identified Mail
DKIM fonctionne avec un système de clé privée et prend également la forme d’un enregistrement DNS.
$ dig default._domainkey.example.org TXT
[…]
default._domainkey.example.org. 3600 IN TXT "v=DKIM1; k=rsa; s=email; h=sha256; p=LONGUE_CLEF_PUBLIQUE" "QAB"
[…]
Sur le serveur d’envoi, certains entêtes et le contenu du courriel sont signés avec la clé privée puis le serveur destinataire peut vérifier que le contenu et les entêtes n’ont pas été modifiés à l’aide de la clé publique.
Pour plus de détails, voir par exemple
[https://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail
DMARC : Domain Message Authentication Reporting & Conformance
DMARC prend également la forme d’un enregistrement DNS.
$ dig _dmarc.example.org TXT
[…]
_dmarc.example.org. 3600 IN TXT "v=DMARC1; p=reject;adkim=s; aspf=s; fo=1; rua=mailto:dmark-report@example.org; ruf=mailto:dmark-report@example.org"[…]
DMARC indique aux serveurs destinataires que faire avec les mails (illégitimes) entrant : à quel point les règles DKIM et SPF doivent être respectés, et comment (rejet du message ?). DMARC est aussi un mécanisme de rapport : un rapport est envoyé par les serveurs destinataires implémentant cette fonctionnalité à l’adresse indiquée pour tous les courriels qui concernent le nom de domaine concerné. La manière dont le rapport est envoyé est également spécifié.
Voici un exemple de rapport envoyé par Yahoo (un peu adapté pour faire apparaître du courriel valide) :
Pour : dmarc-report@example.org
Sujet : Report Domain: example.org Submitter: yahoo.fr Report-ID:
Contenu : This is an aggregate report from Oath
Pièce jointe : yahoo.fr!example.org!1546473600!1546559999.xml
<?xml version="1.0"?>
<feedback>
<report_metadata>
<org_name>Yahoo! Inc.</org_name>
<email>postmaster@dmarc.yahoo.com</email>
<report_id>1546565007.991476</report_id>
<date_range>
<begin>1546473600</begin>
<end>1546559999 </end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.org</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>YYY.YYY.YYY.YYY</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>reject</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>domaine-spammeux.fr</domain>
<result>neutral</result>
</dkim>
<spf>
<domain>domaine-spammeux.fr</domain>
<result>softfail</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx</source_ip>
<count>5</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.org</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>example.org</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>On voit qu’un courriel a été rejeté parce qu’il provenait d’une mauvaise adresse IP et avait une signature DKIM invalide. 5 courriels valides ont été acceptés.
Digression
Ces mécanismes sont utiles et heureusement qu’ils sont là. Ils évitent des usurpations d’identités et permettent de bloquer du courrier indésirable. Ils posent des problèmes avec les listes de diffusions et les transferts de courrier. Des gens se penchent sur ces problèmes avec un mécanisme en court de standardisation : ARC.
Décorticage
Revenons sur ce courriel de non-livraison étrange, intitulé « Delivery Status Notification (Delay) » de la part de Gmail. Dans la suite, on va considérer que example.org est mon domaine.
En ouvrant le courriel, on voit :
Delivery incomplete
There was a temporary problem delivering your message to xxxx@[HIDDEN].fr. Gmail will retry for 140 more hours. You'll be notified if the delivery fails permanently.
LEARN MORE
The response was:The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720 [XX.YY.ZZ.AA XX.YY.ZZ.AA: 421 No SMTP service here ]
J’ai censuré l’adresse destinataire du courriel original, certainement valide.
On découvre que Gmail a essayé d’envoyer un message à l’adresse IP XX.YY.ZZ.AA, celle qui est derrière l’hôte mail.[HIDDEN].fr, et s’est fait jeté.
Le contenu du message est bien spammesque et un peu obscure. L’adresse d’expédition (nom changé), d’après le champ FROM du mail, est:
From: Jean Bidon <BidonJean@nl.champagne-ardenne.cci.fr>
Regardons le champ SPF :
[…]
$ dig nl.champagne-ardenne.cci.fr TXT
nl.champagne-ardenne.cci.fr. 3501 IN TXT "spf2.0/mfrom mx ip4:83.206.208.128/25 ip4:81.252.92.0/23 ip4:86.64.210.0/23 ip4:195.62.74.0/23 ~all"
nl.champagne-ardenne.cci.fr. 3501 IN TXT "v=spf1 mx ip4:83.206.208.128/25 ip4:81.252.92.0/23 ip4:86.64.210.0/23 ip4:195.62.74.0/23 ~all"
nl.champagne-ardenne.cci.fr. 3501 IN TXT "google-site-verification=ix9iAaNJuQ-0jzi-p8Na6bE0r3S4X9-h1W-gu03Mbj0" ""
[…]
Une résolution de ces adresses IP donne des fournisseurs Orange, SFR et NP6. Gmail n’est pas impliqué.
Regardons l’enregistrement DMARC :
$ dig _dmarc.nl.champagne-ardenne.cci.fr TXT
[…]
_dmarc.nl.champagne-ardenne.cci.fr. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@mailperformance.com"
[…]
p=none: Un mail illégitime ne sera pas bloqué avec le mécanisme DMARC.
L’adresse To est cassée (j’ai changé le nom et un peu le nom de domaine (la partie bidon), au cas où la personne existe réellement, et le nom de domaine d’origine existe bien).
To: "Marie Dupont" <@bidon-habitat.fr>
Bon, pour l’instant, je ne suis pas impliqué alors. Et Gmail non plus, en regardant les enregistrements SPF derrière bidon-habitat.fr.
Mon domaine example.org apparaît dans quelques entêtes :
Received-From-MTA: dns; leypond.smufkat.choossfroost-criftfruch-@example.org
ARC-Authentication-Results: i=1; mx.google.com;
dkim=temperror (no key for signature) header.i=@example.org header.s=trantpiy header.b=rh7rWrS4;
spf=fail (google.com: domain of leypond.smufkat.choossfroost-criftfruch-@example.org does not designate EE.FF.GG.HH as permitted sender) smtp.mailfrom=leypond.smufkat.choossfroost-criftfruch-@example.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nl.champagne-ardenne.cci.fr
Return-Path: <leypond.smufkat.choossfroost-criftfruch-@example.org>
Received: from example.org ([EE.FF.GG.HH])
by mx.google.com with ESMTP id w11si16063308plz.327.2019.01.04.21.22.34
for <xxxx@[HIDDEN].fr>;
Fri, 04 Jan 2019 21:22:36 -0800 (PST)
Received-SPF: fail (google.com: domain of leypond.smufkat.choossfroost-criftfruch-@example.org does not designate EE.FF.GG.HH as permitted sender) client-ip=EE.FF.GG.HH;
Authentication-Results: mx.google.com;
dkim=temperror (no key for signature) header.i=@example.org header.s=trantpiy header.b=rh7rWrS4;
spf=fail (google.com: domain of leypond.smufkat.choossfroost-criftfruch-@example.org does not designate EE.FF.GG.HH as permitted sender) smtp.mailfrom=leypond.smufkat.choossfroost-criftfruch-@example.org;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nl.champagne-ardenne.cci.fr
OK, on apprend que c’est certainement un spammeur qui a pris mon nom de domaine comme adresse de retour, a utilisé une adresse complètement farfelue et qui a essayé de forger une signature DKIM avec mon nom de domaine. Bien sûr, ça a fait râler Gmail (« Authentication-Results: mx.google.com; dkim=temperror (no key for signature) »).
La vérification SPF a également échoué bien sûr, puisque le courriel vient d’une autre IP que la mienne (et en voyant ça, ça m’a rassuré, j’ai écarté l’hypothèse « mon serveur s’est fait piraté »).
De ce que j’ai compris, le serveur EE.FF.GG.HH (qui s’est certainement fait piraté ou est le serveur d’un spammeur) essaie d’envoyer un mail via Gmail à xxxx@[HIDDEN].fr en se faisant passer pour mon nom de domaine. Tordu. [HIDDEN].fr bloque la tentative de connexion de Gmail.
Gmail m’informe que sa tentative de connexion a échoué à l’adresse leypond.smufkat.choossfroost-criftfruch-@example.org à cause de l’entête Return-Path.
C’est original. Ça ressemble à du pourriel horriblement mal géré. Pourquoi le spammeur s’est servi de mon nom de domaine et comment il est tombé dessus ? Mystère complet ! Est-ce une tentative d’envoyer un spam en pervertissant le mécanisme de Return-Path ? S’il faut se fader le déchiffrage des entêtes et décoder du base64, c’est quand même poussé !!
Et puis je n’ai rien à faire avec xxxx@[HIDDEN].fr ni avec la CCI de Champagne Ardennes qui n’existe plus…
# coquille ?
Posté par xavier Granveaux . Évalué à 4.
Si je peux proposer une petite correction humblement:
DMARC : DomainKeys Identified Mail
--> Domain Message Authentication Reporting & Conformance
Au delà de ceci, si on lit toutes ces propositions, comment est-ce possible qu'il y ait encore autant de spam ?
Sont-ce de nouvelles belles idées trop complexes (et donc trop chères) et finalement pas, ou très peu, implémentées, ce qui impose le support d'une rétro-compatibilité éternelle qui voue ces initiatives à de belles intentions ?
( IPv6, DNSSEC, … )
[^] # Re: coquille ?
Posté par Samuel (site web personnel) . Évalué à 1.
Je connais au moins un gros serveur du marché, Microsoft Exchange, qui n'implémente que partiellement ces technologies (pour la version "sur site"):
Outlook365 (la version "cloud" d'Exchange) par contre permet l'utilisation de DKIM.
[^] # Re: coquille ?
Posté par xavier Granveaux . Évalué à 2.
Est-ce à dire que le problème majeur du Mail est son aspect décentralisé ? Qui veut que ça devrait fonctionner pour n'importe quelle petite entreprise (ou particulier ?) qui souahiterait héberger son server de messagerie.
Le mond…web serait-il plus sûr si les mails n'étaient gérés uniquement par les entreprises qui en avaient la taille / les compétences ?
Héberger ses mails avec YunoHost serait-il criminel ?
Même si je carricature un peu, il faut reconnaitre que la mise en oeuvre de ces dispositifs, aussi louables soient-ils, n'est pas à la portée de chaque setup SMTP…
[^] # La complexité de l'auto-hébergement des mails
Posté par Samuel (site web personnel) . Évalué à 5.
Il me semble que c'est le cas, oui. À une plus petite échelle, c'est le sujet d'une Réflexion autour de l’auto-hébergement et des CHATONS d'Aeris qui défend ce point de vue.
Après, la complexité du sujet n'est pas à sur-estimer :
- pour un utilisateur de base ou geek un peu plus avancé (développeur, …) le rapport coût/avantage (vs. solution gérée par un pro) est défavorable.
- pour quelqu'un dont l'administration systèmes/réseau est l'activité principale, il y en a pour une petite semaine d'auto-formation (1) (s'il n'a pas les connaissances initiales) et autant de mise en place si l'infrastructure est compliquée.
Donc les PME devraient avoir les moyens de mettre ça en place à partir du moment où elles ont un service informatique (même petit), de même que les assos de passionnés (chatons).
(1) : et encore … cet article est une bonne introduction au sujet, il y a juste à creuser chaque aspect pour comprendre les détails des règles et implémentations. Du coup, ça peut aller assez vite.
[^] # Re: coquille ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Si seul un petit nombre d'entreprise gérait les mails, il y aurait rapidement des incompatibilités et le mail cesserait d'être le seul outil universel de communication sur le net.
(Ce n'est pas une spéculation, c'est le sort qu'a subi XMPP avec les forks/abandons de Google, Whatsapp & co).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: coquille ?
Posté par barmic . Évalué à 8.
C'est déjà le cas, hein ? Gmail a sa propre implémentation d'IMAP pour que ça lui plaise mieux sur mobile par exemple.
Pour les compatibilités, le fait de te faire blacklister régulièrement est une forme d'incompatibilité.
Hum ? Je vois pas le rapport. XMPP peut être déployé par n'importe qui.
[^] # Re: coquille ?
Posté par barmic . Évalué à 3.
J'ai l'impression que c'est plus une question de protocole. Le principe d'utiliser un serveur SMTP autre que celui qui tiens ton adresse email pose amha un vrai problème. Ça a était fait pour que tu puisse accepter un mail de la part de user@example.net depuis un serveur exemple.org, ça avait du sens a une époque mais ça fait 15 ans que ce n'est plus d'actualité. Et ça ne simplifie pas du tout l'authentification. XMPP est décentralisé mais n'a pas ce problème par exemple.
J'ai entendu parler de JMAP récemment, je ne sais pas quels implications il aurait là dessus (vu qu'il veut remplacer à la fois SMTP et IMAP).
[^] # Re: coquille ?
Posté par flan (site web personnel) . Évalué à 2.
JMAP ne veut pas remplacer le SMTP.
JMAP veut remplacer le SMTP entre le client final et son premier relais.
Le but n'est pas du tout de corriger les problèmes de SMTP (ce qui est loin d'être simple), mais de simplifier la vie de l'utilisateur final pour qu'il n'ait qu'un seul compte à configurer, comme sur Exchange.
L'idée est donc de faire du JMAP entre ton client et ton serveur mail, puis du SMTP entre ton serveur mail et le prochain relais SMTP.
[^] # Re: coquille ?
Posté par barmic . Évalué à 4.
Ok comme il était question de gérer l'auth pour l'envoi je pensais qu'il le remplaçait complètement.
Qu'est-ce qui est si compliqué dans SMTP ?
[^] # Re: coquille ?
Posté par flan (site web personnel) . Évalué à 3.
L’historique ; c’est facile de mettre en place un serveur JMAP à côté du couple IMAP/SMTP, tout comme on a déjà des Exchange. Ça n’affecte que ton client et tu peux donc changer ton serveur sans rien demander à personne.
Remplacer SMTP va demander un peu plus de coordination.
[^] # Re: coquille ?
Posté par barmic . Évalué à 2.
Mettre en place une négociation du protocole me paraît être le B-A-BA des protocoles réseaux.
[^] # Re: coquille ?
Posté par flan (site web personnel) . Évalué à 2. Dernière modification le 08 janvier 2019 à 06:49.
Mais dans ce cas, pourquoi faire ?
JMAP apporte quelque chose par rapport à IMAP + SMTP (même s'il restera toujours loin derrière ActiveSync/Exchange en termes de possibilités). En revanche, qu'apporte concrètement JMAP par rapport à SMTP ?
[^] # Re: coquille ?
Posté par barmic . Évalué à 2. Dernière modification le 08 janvier 2019 à 10:42.
Tu marque un point (mais j'ai pas dis que JMAP doit remplacer SMTP en particulier juste que faire un protocole qui remplace SMTP n'est pas forcément si compliqué).
Depuis le petit bout de ma lorgnette, j'ai l'impression qu'une énorme partie des problèmes des mails vient de 2 points :
FROM:rend l'authentification compliquéeSi on avait un protocole qui interdit à un serveur d'envoyer un mail au nom d'un autre serveur. C'est ce que DKIM tente de faire mais sous forme d'une rustine. Ça pourrait être fait de manière bien plus forte. Par exemple le serveur peut signer tous les mails qu'il envoi et réécrire le
FROM:avec le nom d'utilisateur du serveur. Oui ça a des implications en tant qu'utilisateur si tu veux toi-même signer ton mail, il va falloir que tu signe une enveloppe qui sera ré-enveloppée par le serveur (pour qu'il puisse indiquer leFROM:sans casser ta signature) et tous les post-traitements (du coté du serveur qui reçoit) le mail devront travailler autour du mail sans le modifier pour ne pas casser les signatures. Ça ne me paraît pas incroyablement complexe.Avec ce genre de choses un serveur qui reçoit à la fois des mails SMTP et des mails de cet hypothétique protocoles peut simplement indiquer une bien meilleure confiance pour ce dernier mail.
[^] # Re: coquille ?
Posté par flan (site web personnel) . Évalué à 2.
Fondamentalement, tu as raison. Cependant, je pense que comme les rustines fonctionnent suffisamment bien et que de toute façon il faudra conserver le SMTP pendant longtemps (en partie à cause de toutes les applications qui utilisent SMTP pour envoyer des alertes automatiques), les gens vont être vraiment frileux à l'idée de déployer autre chose.
Enfin, ça finira bien par changer un jour, on ne va pas conserver SMTP pendant des siècles…
[^] # Re: coquille ?
Posté par xavier Granveaux . Évalué à 2.
"Enfin, ça finira bien par changer un jour, on ne va pas conserver SMTP pendant des siècles…"
Un peu comme IPv4 et la rustine qu'on appelle NAT quoi :)
[^] # Re: coquille ?
Posté par barmic . Évalué à 2.
Et DNSSec… Je trouve ça déprimant.
[^] # Re: coquille ?
Posté par eingousef . Évalué à 4.
genre Microsoft ?
*splash!*
[^] # Re: coquille ?
Posté par Yves (site web personnel) . Évalué à 3.
Certainement pas. Quand je me suis lancé là-dedans, j’ai pu constater que SPF, DKIM et DMARC sont vraiment simples à configurer sur un serveur :
http://yalis.fr/cms/index.php/post/2014/01/31/Why-buy-a-domain-name-Secure-mail%2E
En revanche, et peut-être plus compliqué à corriger, cette configuration « naïve » pose des problèmes :
Au moins, avec la configuration en lien ci-dessus, je suis averti de chaque occurrence de ces situations, ET j’ai le mail en pièce jointe (heureusement, car sinon, impossible de s’en sortir dans la 3ème situation !).
[^] # Re: coquille ?
Posté par Sufflope (site web personnel) . Évalué à 6. Dernière modification le 07 janvier 2019 à 16:28.
C'est déjà trop complexe pour les barbus fossilisés admins de mailing-list qui ne veulent pas changer leur soft à la noix qui te met en From: quand il relaie, donc tu te fais tej par ceux qui respectent DMARC. C'est dommage en plus parce qu'aussi archaïques qu'ils soient, sympa et compagnie sont capables de ne pas faire cette connerie de relayer avec le From: d'origine, mais non, on te répond "c'est ton domaine qui est cassé"…
[^] # Re: coquille ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: coquille ?
Posté par raphj . Évalué à 1.
Merci, échec de copier-coller !
[^] # Re: coquille ?
Posté par raphj . Évalué à 2. Dernière modification le 08 janvier 2019 à 21:45.
Merci pour la coquille :-)
Je vois plusieurs possibilités :
tout le monde n'implémente pas ça strictement. Dans mon université, pas de spf, dkim, dmarc et ils refusent de l'implémenter. On peut se faire passer pour n'importe qui ayant une adresse électronique de cette université y compris le président. Je pense que c'est vrai dans beaucoup d'universités.
ces mécanismes servent surtout à empêcher l'usurpation d'identité et la modification des messages. On peut faire du spam qui respectent ces mécanismes même si ce n'est régulièrement pas le cas.
# Anonymisation ratée
Posté par Glandos . Évalué à 4.
Je vais pas mettre les projecteurs dessus, mais on voit ton nom de domaine. Comme tu avais envie de le cacher, c'est dommage. Bref.
Bon article.
Notons que ARC est bien avancé, et déjà implémenté dans rspamd.
[^] # Re: Anonymisation ratée
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Anonymisation ratée
Posté par raphj . Évalué à 1.
Merci à vous deux :-)
# Certificat SSL
Posté par ilip . Évalué à 1.
Bonjour, question un peu hors sujet désolé mais y a t'il un intérêt de mettre un certificat SSL signé dans un serveur mail comme let's encrypt ? J'utilise les certificats auto-signés et ça ne semble pas poser de problème
[^] # Re: Certificat SSL
Posté par raphj . Évalué à 3.
L'intérêt immédiat pour moi est que j'utilise déjà letsencrypt pour les sites que j'héberge donc un certificat de plus c'est facile à mettre en place.
Je serais intéressé de savoir s'il y a d'autres intérêts :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.