SRS, fin de l'explication générique

services/mail/normes.md

@@ -25,7 +25,7 @@ seront décrites.
 
 ## Au Cr@ns
 
-|         | *Statut au Cr@ns ?* | Adoption                           |
+|         | Statut au Cr@ns ? | Adoption                           |
 |---------|-------------------|------------------------------------|
 | SPF     | Implémenté        | Large                              |
 | DKIM    | Implémenté        | Large                              |
@@ -43,7 +43,7 @@ Tous ce qui est discuté ci-dessous fonctionne de la manière suivante :
   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
+émetteur car plus d'un serveur est souvent requis (*e.g.* un serveur DNS
 autoritaire, un serveur Web,...).
 
 ## SPF
@@ -114,17 +114,69 @@ Cas d'usage : un expéditeur envoie un mail à une mailing-list (du Cr@ns),
 qui retransmet aux adresses abonnées, qu'elles soient ou non au Cr@ns.
 Un problème survient, empêchant un abonné de recevoir le mail
 (à tout hasard, le quota de stockage est dépassé).
-Ce problème génère un *bounce*, un mail automatique d'erreur. 
+Ce problème génère un *bounce*, un mail automatique d'erreur.
 
 Question : qui doit recevoir ce *bounce* ?
 Logiquement, l'expéditeur d'origine, c'est lui qui a envie
 de savoir qu'un destinataire n'a pas lu son message.
 
-(À continuer)
+Pour cela, le serveur intermédiaire va conserver le champ `Envelope-From`
+d'origine et passer le mail tel quel au serveur final.
+Or, ce choix bien intentionné se heurte, comme annoncé,
+aux politiques anti-usurpation à base de `SPF`.
+Si le serveur de l'expéditeur applique une politique `SPF`
+strice (`-all`) et que le serveur d'arrivée suit les instructions,
+le mail transféré sera refusé en raison de son champ `SPF` invalide.
 
+Comment faire ? Réfléchissons à partir de nos contraintes :
+dans le pire des cas, on doit s'adapter à une politique `SPF`
+stricte pour ne perdre aucun mail d'adhérent.
+On doit donc montrer patte blanche en transférant le mail
+avec un champ `Envelope-From` dans notre domaine,
+de sorte que le mail soit accepté à l'arrivée.
+
+Conséquence : c'est à nous que reviendront les
+éventuels *bounces* qui nous motivaient à l'origine.
+Sauf qu'ils ne nous intéressent pas directement,
+on doit trouver un moyen de les renvoyer à l'expéditeur.
+
+C'est là que `SRS` entre en jeu : il fabrique,
+en suivant un schéma de nommage normalisé,
+une adresse temporaire qui va encoder l'adresse de
+l'expéditeur d'origine, plus quelques métadonnées,
+dans la partie "compte" (avant le `@`) de l'adresse fabriquée.
+
+Prenons un exemple, éhontément pris de la page Wikipédia.
+Alice, détentrice de l'adresse `alice@nane.in`,
+veut envoyer un mail à son ami Bob, détenteur de
+l'adresse `bob@crans.org`.
+Ce qu'Alice ne sait pas (et n'a pas besoin de savoir),
+c'est que Bob est en train de passer ses contacts
+sur son adresse ENS, `bob@ens-cachan.fr`.
+Il transfère donc tous ses mails Cr@ns vers sa
+boîte ENS, sans avoir besoin de prévenir qui que ce soit.
+
+À la réception d'un mail d'Alice, le serveur du Cr@ns (`redisdead`)
+va lire l'instruction de forwarding de Bob et va changer le champ
+`Envelope-From` de `alice@nane.in` (origine) à
+`SRS0=HHH=TT=nane.in=alice@crans.org`.
+Le `HHH` est un hash d'identification, le `TT`
+un marqueur temporel.
+Il est à noter que si un utilisateur a l'idée saugrenue de prendre
+un alias commençant par `SRS0=`, on va peut-être avoir un problème.
+Prions pour que ça n'arrive pas.
+
+Si la boîte mail ENS de Bob est pleine, le *bounce* part sur
+l'adresse `SRS` et est ensuite retransféré à Alice, dont
+l'adresse est clairement extractible de l'adresse `SRS`.
+Et voilà !
 
 *Note :* les adresses générées par `postsrsd` sont valides pendant 21 jours.
 
+### Implémentation
+
+**TODO**
+
 ## DKIM
 
 - [La RFC](https://www.rfc-editor.org/rfc/rfc6376.html),