5.5 KiB

Raw Blame History

Description de normes autour des emails.

Résumé
SPF
- Implémentation (côté infrastructure émettrice)
- Vérification (côté serveur récepteur)
SRS
DKIM
DMARC
ARC
Sender Rewriting Scheme (SRS)
MTA-STS
DANE

-- 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 (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

SPF,
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.