5.6 KiB
Description de normes autour des emails.
-- mode: org; org-hide-emphasis-markers: 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é repousé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 mentionant 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 (
MXdes destinateires 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
Implémentation (côté infrastructure émettrice)
Le SPF (Sender Policy Framework) permet d'indiquer quels serveurs ont le droit
d'émettre des mails en crans.org. 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 ~allCela 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 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 -allIdem, avec des champsinclude:...en plus. Ces derniers permettent d'inclure un autre enregistrement SPF (e.g. celui despf.mailjet.com). Utiliser-allpermet de demander aux serveurs récepteurs de rejeter tout mail ne satisfiant pas ce test.
D'autres méchanismes 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érififer le SPF (via la variable smtpd_recipient_restrictions). Le
service externe tourne sur la même VM et est postfix-policyd-spf-python.