223 lines
10 KiB
Org Mode
223 lines
10 KiB
Org Mode
-*- mode: org; org-hide-emphasis-markers: t; -*-
|
|
|
|
#+TITLE: Description de normes autour des emails.
|
|
#+AUTHOR: Des nounous quelconques.
|
|
#+EMAIL: contact@crans.org
|
|
#+SEQ_TODO: TODO | in_progress | DONE
|
|
#+DESCRIPTION: Pfiou que c'est fastidieux d'apprendre à parler au monde entier.
|
|
#+INSTITUTE: Cr@ns
|
|
#+LANGUAGE: fr
|
|
#+STARTUP: overview
|
|
|
|
#+OPTIONS: broken-links:t
|
|
|
|
Description de plusieurs RFC intéressantes (ou non) autour des protocoles liés
|
|
aux emails. Lorsque ces normes sont en application au Cr@ns (ou ont
|
|
volontairement été repoussées à plus tard), les solutions techniques étudiées
|
|
seront décrites.
|
|
/Remarques préalables/ :
|
|
|
|
- SMTP est un protocole incontournable car largement utilisé. Malgré tous ses
|
|
défauts, il restera important pendant un bon bout de temps. Pour cette raison,
|
|
de nombreuses personnes ont cherché à augmenter la sécurité des emails tant
|
|
bien que mal, en proposant de chiffrer les mails qui transitent d'un MTA à un
|
|
autre, signant les mails émis par un serveur, ... Toutes ces techniques sont
|
|
mises en place autour du protocole mail, lequel ne change pas.
|
|
|
|
- Aujourd'hui, certains organismes influents ont le bon goût de rejeter les
|
|
mails issus de serveurs n'implémentant pas les protocoles les plus
|
|
importants. Quoi que l'on pense du poids de l'influence des géants, cela
|
|
permet d'élever les standards qualités des autres. Serons-nous un jour
|
|
spam-free ? Les publicités mentionnant nos informations personnelles (nom,
|
|
préférences, ...) seront-elles un jour toutes chiffrées ? Je ne sais pas,
|
|
mais je l'espère haha.
|
|
|
|
* Résumé
|
|
|
|
| | /Statut au Cr@ns/ ? | Adoption |
|
|
|---------+-------------------+------------------------------------|
|
|
| SPF | Implémenté | Large |
|
|
| DKIM | Implémenté | Large |
|
|
| SRS | Implémenté | ? |
|
|
| DMARC | Non-implémenté | Large |
|
|
| ARC | Non-implémenté | ? (Google l'utilise) |
|
|
| MTA-STS | Non-implémenté | ? (MS, Méta et Google l'utilisent) |
|
|
| DANE | Non-implémenté | Faible (requiert DNSSEC) |
|
|
|
|
Tous ce qui est discuté ci-dessous fonctionne de la manière suivante :
|
|
- l'infrastructure émettrice (le Cr@ns) publie des informations la concernant,
|
|
- les serveurs réceptionnant les mails (~MX~ des destinataires des mails émis par
|
|
le Cr@ns) peuvent vérifier les mails à l'aide de ces informations.
|
|
/NB/ : Je parle d'infrastructure ou d'organisation émettrice et non pas de serveur
|
|
émetteur car plus d'un service est souvent requis (/e.g./ un serveur DNS
|
|
autoritaire, un serveur Web, ...).
|
|
|
|
* TODO SPF
|
|
|
|
- [[https://www.rfc-editor.org/rfc/rfc7208][SPF]],
|
|
- [[https://en.wikipedia.org/wiki/Sender_Policy_Framework][Page Wikipédia]].
|
|
|
|
Le SPF (/Sender Policy Framework/) permet d'indiquer quels serveurs ont le droit
|
|
d'émettre des mails en ~crans.org~ (ou tout autre domaine, bien entendu).
|
|
|
|
** Implémentation (côté infrastructure émettrice)
|
|
|
|
Pour cela, nous publions un champ ~TXT~ pour ~crans.org~. Voici le contenu que l'on
|
|
obtient pour quelques associations (obtenues avec ~kdig -t TXT crans.org~ (~dig~
|
|
peut être utilisé à la place de ~kdig~) :
|
|
|
|
- Cr@ns: ~v=spf1 mx ip4:185.230.79.1 ip6:2a0c:700:2:0:ec4:7aff:fe59:a1ad ip4:185.230.79.38 ip6:2a0c:700:2::ff:fe01:3502 ~all~
|
|
|
|
Cela signifie que les serveurs mail du Cr@ns (~mx~) et les adresses listées (et
|
|
celles-ci uniquement) ont le droit d'envoyer des mails dont la source
|
|
prétendue est /...@crans.org/.
|
|
|
|
Utiliser /~all/ permet d'indiquer que si un mail provient d'une autre IP, il ne
|
|
faut pas rejeter le mail, mais le mettre en /permerror/.
|
|
|
|
- April: ~v=spf1 include:spf.mailjet.com mx ip4:62.73.5.35 include:spf.protection.outlook.com include:_spf.april.com ip4:37.71.69.68 ip4:37.71.69.69 ip4:37.71.69.70 include:_spf.salesforce.com -all~
|
|
|
|
Idem, avec des champs ~include:...~ en plus. Ces derniers permettent d'inclure
|
|
un autre enregistrement SPF (/e.g./ celui de ~spf.mailjet.com~).
|
|
|
|
Utiliser ~-all~ permet de demander aux serveurs récepteurs de rejeter tout mail
|
|
ne satisfaisant pas ce test.
|
|
|
|
D'autres mécanismes et formats existent, mais nous ne les présentons pas
|
|
ici. Se référer à la RFC ou la page Wikipédia pour leur description.
|
|
|
|
** Vérification (côté serveur récepteur)
|
|
|
|
Lorsque ~redisdead~ (~MX~ du Cr@ns) reçoit un mail, nous demandons à un service
|
|
externe de vérifier le SPF (via la variable ~smtpd_recipient_restrictions~). Le
|
|
service externe tourne sur la même VM et est ~postfix-policyd-spf-python~.
|
|
|
|
* TODO SRS
|
|
|
|
- [[https://www.libsrs2.org/srs/srs.pdf][Papier]],
|
|
- [[https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme][Page Wikipédia]].
|
|
|
|
* TODO DKIM
|
|
|
|
- [[https://www.rfc-editor.org/rfc/rfc6376.html][RFC]].
|
|
- [[https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail][Page Wikipedia]].
|
|
|
|
DKIM (/Domain Key Identified Mail/) permet au serveur émetteur de signer les
|
|
mails, et au serveur récepteur de vérifier cette signature, en utilisant des
|
|
méthodes de cryptologie asymétrique.
|
|
|
|
** Implémentation (côté émetteur)
|
|
|
|
*** Serveur Mail
|
|
|
|
Le serveur émetteur possède la clef privée. Il ajoute à tout mail sortant un
|
|
champ à l'en-tête de la forme suivante :
|
|
#+begin_src mail
|
|
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crans.org; s=mail;
|
|
t=1702660809; bh=NqcDLO2gkZU0IxcV+mE7uZ2NRnN/yfceH73Q1nhaFg4=;
|
|
h=From:To:Subject:Date:From;
|
|
b=ZjomU0jkljKVwA6sUhUioCemnxh/OhSGgwwr57irEn39Gfbv8/cLF8jmHc3hmv4ly
|
|
fLvJdj7iVTkeGlTVeW72H93wEA0qrB6LHHz81YBeHPb8eg63zm+9soDSOaP91Gux8J
|
|
UgeY1PWXvfjdfe+MJX9JqnlBKqd4JRgpD8AXaO852Lrq+fLJy4ewLOc/3dAqpNMrTf
|
|
swi5y6vV5QH89cuFjpjWqF3UcuD4a20RCQIpU/j5K1sxr1CTbdKjgqlsq5mt9/JSKx
|
|
OcvZ5WTmgPwdimKKz0DfjAeXQBMac9d7V9Kb5LvCZx84kSbLQEKboGxpRRhNWGdBsK
|
|
f3YZXjmpe8cl8cpbvuvdKYWOE7E6fRGu/CwQEyEQYqmrmljiklSYPaG8IKs5uYWKrA
|
|
A2D4VTisIYOwGvdljFTQP5zfhPsi4OnNbiN3RVX475lCHNWbnFMh8OCF/ugLj30dyk
|
|
s8MLAzDyYlgaccOD0uZ6VsdGJ0LK8+TCKbsc5H1ynjg0VejmRyVzZJ5TzAjXrzS6CC
|
|
Lj9eQQex1IaO6d7uGe4P/ULghjSP90tgBcZVNFLlU3r59ylkVQyAu7THDr4CDaxFO0
|
|
63QE7/GNDE2vZv0K5gp5Yz2veVC3wyaP1dJzIoAzZc1kZRoWz6QK9cH1Bfmnlx9nUs
|
|
j+G+VLDQbxi2NuoYAD/I2naA=
|
|
#+end_src
|
|
|
|
Le bloc contient une liste de clefs-valeurs :
|
|
- ~v~ indique la version du protocole,
|
|
- ~d~ le domaine attestant de la validité du mail,
|
|
- ~s~ le nom du sélecteur (/Cf/. plus bas),
|
|
- ~b~ et ~bh~ contiennent les signatures.
|
|
/Notes/ :
|
|
- Il est possible que le mail ne soit pas signé par le domaine correspondant à
|
|
l'adresse d'envoi, puisqu'il est possible d'autoriser autrui à envoyer un
|
|
mail à notre place (/Cf/. SPF plus haut).
|
|
- Se référer à la page Wikipédia, ou à la RFC pour une liste exhaustive des
|
|
clefs.
|
|
|
|
*** Serveur DNS
|
|
|
|
Il faut placer dans le serveur DNS un champ TXT dont la clef est
|
|
~sélecteur._domainkey.domain~, où ~domain~ (resp. ~sélecteur~) est la valeur de la
|
|
clef ~d~ (resp. ~s~) définie plus haut.
|
|
|
|
Par exemple, pour le champ fourni plus haut, nous pouvons lire :
|
|
#+begin_src mail
|
|
"v=DKIM1; k=rsa; " "p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtwkNVd9Mmz8S4WcfuPk0X2drG39gS8" "+uxAv8igRILgzWeN8j2hjeZesl8pm/1UTVU87bYcdfUgXiGfQy9nR5p/Vmt2kS7sXk9nsJ/VYENg" "b3IJQ6paWupSTFMyeKycJ4ZHCEZB/bVvifoG6vLKqW5jpsfCiOcfdcgXATn0UPuVx9t93yRrhoEM" "ntMv9TSodjqd3FKCtJUoh5cNQHo0T6dWKtxoIgNi/mvZ92D/IACwu/XOU+Rq9fnoEI8GukBQUR5A" "kP0B/JrvwWXWX/3EjY8X37ljEX0XUdq/ShzTl5iK+CM83stgkFUQh/rpww5mnxYEW3X4uirJ7VJH" "mY4KPoIU+2DPjLQj9Hz63CMWY3Ks2pXWzxD3V+GI1aJTMFOv2LeHnI3ScqFaKj9FR4ZKMb0OW2BE" "FBIY3J3aeo/paRwdbVCMM7twDtZY9uInR/NhVa1v9hlOxwp4/2pGSKQYoN2CkAZ1Alzwf8M3EONL" "KeiC43JLYwKH1uBB1oikSVhMnLjG0219XvfG/tphyoOqJR/bCc2rdv5pLwKUl4wVuygfpvOw12bc" "vnTfYuk/BXzVHg9t4H8k/DJR6GAoeNAapXIS8AfAScF8QdKfplhKLJyQGJ6lQ75YD9IwRAN0oV+8" "NTjl46lI/C+b7mpfXCew+p6YPwfNvV2shiR0Ez8ZGUQIcCAwEAAQ=="
|
|
#+end_src
|
|
|
|
** Vérification (côté récepteur)
|
|
|
|
Côté réception (~redisdead~ pour nous), nous utilisons le milter (filtre pour
|
|
mail) fourni par ~opendkim~. Ce milter écoute en local et est appelé par ~postfix~.
|
|
Lors de la réception d'un mail, postfix demande à ~opendkim~ quelle décision
|
|
prendre. Ce dernier va regarder les en-têtes du mail. S(il trouve une signature
|
|
DKIM, il va effectuer la requête DNS décrite plus haut, et vérifier la signature
|
|
du mail (valeurs des clefs ~b~ et ~bh~).
|
|
|
|
* TODO DMARC
|
|
|
|
- [[https://www.rfc-editor.org/rfc/rfc7489][RFC]],
|
|
- [[https://en.wikipedia.org/wiki/DMARC][Page Wikipédia]].
|
|
|
|
* TODO ARC
|
|
|
|
- [[https://www.rfc-editor.org/rfc/rfc8617.html][RFC]],
|
|
- [[https://en.wikipedia.org/wiki/Authenticated_Received_Chain][Page Wikipedia]].
|
|
|
|
* TODO MTA-STS
|
|
|
|
- [[https://datatracker.ietf.org/doc/html/rfc8461][RFC]],
|
|
- [[https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_MTA_Strict_Transport_Security][Section de page Wikipédia]].
|
|
|
|
Le MTA-STS consiste à publier les protocoles de sécurité supportés par les
|
|
serveur mail d'un certain domaine (pour nous, les mails en /...@crans.org/).
|
|
|
|
Contrairement au ~DANE~ (décrit plus bas), ce protocole ne demande pas la mise en
|
|
place de DNSSEC. En revanche, il demande d'avoir un serveur Web accessible en
|
|
~https~ (pour nous, ~https://crans.org~ doit être servi par un serveur Web).
|
|
|
|
** Implémentation (côté infrastructure émettrice)
|
|
|
|
*** Dans la zone DNS
|
|
|
|
Il faut ajouter un champ TXT accessible à ~_mts-sts.domain.tld~.
|
|
|
|
Quelques exemples:
|
|
- Gmail: ~v=STSv1; id=20190429T010101;~,
|
|
- Microsoft: ~v=STSv1; id=20190225000000Z;~,
|
|
- Outlook: ~v=STSv1; id=20190225000000Z;~.
|
|
|
|
*** Sur le serveur Web
|
|
|
|
Il faut que le serveur Web associé serve un fichier texte accessible à l'adresse
|
|
~https://mta-sts.domain.tld/.well-known/mta-sts.txt~
|
|
|
|
Quelques exemples :
|
|
+ [[https://mta-sts.gmail.com/.well-known/mta-sts.txt][Gmail]]
|
|
+ [[https://mta-sts.outlook.com/.well-known/mta-sts.txt][Outlook]],
|
|
+ [[https://mta-sts.microsoft.com/.well-known/mta-sts.txt][Microsoft]].
|
|
|
|
Le fichier texte contient une liste de clefs-valeurs. Ces clefs décrivent quel
|
|
protocole
|
|
|
|
** Vérification côté récepteur.
|
|
~postfix-mta-sts-resolver~ peut être utilisé ? N'ayant pas implémenté cette
|
|
solution pour le moment (ni au Cr@ns, ni personnellement), nous ne pouvons pas
|
|
commenter sur le sujet.
|
|
|
|
* TODO DANE
|
|
|
|
- [[https://www.rfc-editor.org/rfc/rfc6698][RFC]],
|
|
- [[https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities][Page Wikipédia]].
|