diff --git a/services/mail/normes.md b/services/mail/normes.md
index 40a2165..e6f9129 100644
--- a/services/mail/normes.md
+++ b/services/mail/normes.md
@@ -100,11 +100,29 @@ Lorsque `redisdead` (le `MX` du Cr@ns) reçoit un mail, nous demandons à un ser
 externe de vérifier 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
+## SRS
 
 - [Le papier d'origine](https://www.libsrs2.org/srs/srs.pdf),
 - [La page Wikipédia](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme).
 
+Au Cr@ns comme ailleurs, on aime bien les mailing-lists
+et les transferts automatiques de mails par `.forward`.
+Le problème, c'est qu'intercaler un serveur entre l'expéditeur et
+le destinataire final est parfois peu distingable d'une usurpation.
+
+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. 
+
+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)
+
+
 *Note :* les adresses générées par `postsrsd` sont valides pendant 21 jours.
 
 ## DKIM