From 5362613c3c8a15b0c1b8d9a5e0a149eba993f23d Mon Sep 17 00:00:00 2001 From: Arnaud Daby-Seesaram Date: Fri, 15 Dec 2023 20:32:28 +0100 Subject: [PATCH] [doc, mails] Description SPF. --- critical/mail/normes.org | 91 +++++++++++++++++++++++++++++++++++----- 1 file changed, 80 insertions(+), 11 deletions(-) diff --git a/critical/mail/normes.org b/critical/mail/normes.org index 146a697..91abb3d 100644 --- a/critical/mail/normes.org +++ b/critical/mail/normes.org @@ -1,29 +1,98 @@ -*- 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é repousées à plus tard), je discuterai des solutions -techniques étudiées. +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é | ? (méta et Google l'utilisent) | -| DANE | Non-implémenté | Faible (requiert DNSSEC) | +| | /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 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 - [[https://www.rfc-editor.org/rfc/rfc7208][SPF]], - [[https://en.wikipedia.org/wiki/Sender_Policy_Framework][Page Wikipédia]]. +** 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 ~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~). + +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~. + +* TODO SRS + +- [[https://www.libsrs2.org/srs/srs.pdf][Papier]], +- [[https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme][Page Wikipédia]]. * TODO DKIM