From 6b765c7b2c2208cd42b39ccb8cb1d544a52e1111 Mon Sep 17 00:00:00 2001 From: glevy Date: Wed, 23 Jul 2025 22:49:58 +0200 Subject: [PATCH] =?UTF-8?q?D=C3=A9but=20de=20SRS?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- services/mail/normes.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) 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