Corrections 2

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