From 9970238ec9fb95079f82489893f54de9c0eeb0ca Mon Sep 17 00:00:00 2001 From: glevy Date: Wed, 23 Jul 2025 22:11:23 +0200 Subject: [PATCH] Corrections 2 --- services/mail/normes.md | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/services/mail/normes.md b/services/mail/normes.md index 56c0fb5..99d942b 100644 --- a/services/mail/normes.md +++ b/services/mail/normes.md @@ -38,7 +38,8 @@ seront décrites. 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 (les `MX` des destinataires des mails émis par +- les serveurs réceptionnant les mails (les `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 @@ -83,7 +84,12 @@ 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. C'est une politique plus sévère que `~all`, qui a l'avantage de filtrer plus efficacement les mails douteux et l'inconvénient de risquer des pertes de mails plus ou moins importants, en tout cas légitimes, émis par des domaines configurés avec un respect des standards mail plus léger. +ne satisfaisant pas ce test. +C'est une politique plus sévère que `~all`, qui a l'avantage de +filtrer plus efficacement les mails douteux et l'inconvénient +de risquer des pertes de mails plus ou moins importants, +en tout cas légitimes, émis par des domaines configurés +avec un respect des standards mail plus léger. 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. @@ -106,7 +112,8 @@ service externe tourne sur la même VM et est `postfix-policyd-spf-python`. - [La RFC](https://www.rfc-editor.org/rfc/rfc6376.html), - [La page Wikipédia](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail). -Le protocole DKIM (*Domain Key Identified Mail*) permet au serveur émetteur de signer les +Le protocole 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 cryptographie asymétrique. @@ -258,15 +265,15 @@ Pour mettre en place `DANE`, il suffit d'ajouter un champ DNS à sa zone : - Il faut que la zone soit signée DNSSEC. - Le champ à ajouter est : - + de type TLSA (TLS Authentication), - + de clef `_port._protoL4.domain.tld`. - + de valeur `x y z t`, où : - * `x` est appelé *certificate usage*, - * `y` est appelé *selector*, - * `z` est appelé *matching type*, - * `t` est appelé *certificate associated data*. + + de type TLSA (TLS Authentication), + + de clef `_port._protoL4.domain.tld`. + + de valeur `x y z t`, où : + * `x` est appelé `certificate usage`, + * `y` est appelé `selector`, + * `z` est appelé `matching type`, + * `t` est appelé `certificate associated data`. -### Format du champ TLSA. +### Format du champ TLSA #### Certificate usage @@ -274,10 +281,10 @@ L'objectif de ce champ est d'indiquer comment vérifier le certificat. | *Valeur* | *Signification* | |--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 0 | Le certificat doit être valide (root -> intermediate -> "cert"), et /associated data/ décrit l'un des certificats parents de "cert" | -| 1 | `associated data` décrit "cert", et le certificat doit aussi être valide /wrt/. un certificat racine de confiance. | -| 2 | `associated data` décrit un parent de "cert". Ce parent est supposé de confiance, et "cert" doit bien être son descendant. | -| 3 | `associated data` décrit "cert". Le certificat n'a pas besoin d'être valide par rapport à un certificat racine. Il a simplement besoin de correspondre à `associated data`. | +| 0 | Le certificat doit être valide (`root` -> `intermediate` -> `cert`), et `associated data` décrit l'un des certificats parents de `cert` | +| 1 | `associated data` décrit `cert`, et le certificat doit aussi être valide par rapport à un certificat racine de confiance. | +| 2 | `associated data` décrit un parent de `cert`. Ce parent est supposé de confiance, et `cert` doit bien être son descendant. | +| 3 | `associated data` décrit `cert`. Le certificat n'a pas besoin d'être valide par rapport à un certificat racine. Il a simplement besoin de correspondre à `associated data`. | #### Selector @@ -298,7 +305,8 @@ Ce champ indique comment vérifier `associated data` contre la donnée du certif | 0 | `associated data` doit être égal à la donnée. | | 1 | `associated data` doit être égal au sha256 de la donnée. | | 2 | `associated data` doit être égal au sha512 de la donnée. | -où "la donnée" est décrite par le `selector` et le choix de certificat décrit par + +où la donnée est décrite par le `selector` et le choix de certificat décrit par le `certificate usage`. #### Certificate associated data