[doc, mails] Description SPF.
Arnaud Daby-Seesaram
parent
29c482a45c
commit
5362613c3c
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue