Re: [fr@sympa] listes en erreur

[David Verdin <adresse@cachée>]

Le 23/01/2024 à 15:33, Mathieu Roquefort a écrit :

Merci David pour cet exposé complet. C’est beaucoup plus clair 😊

    Cool !

 

Et je suis content de ce complément sur l’expiration, car c’est justement un point qu’il me semblait avoir vu il y a longtemps, et qui me semble poser problème.

Je m’explique : sur des listes utilisées pour des groupes de travail qui échangent quotidiennement, remettre les compteurs à zéro tous les 10 jours peut se comprendre. Mais sur une newsletter avec 1 envoi par mois… Eh bien on supprime les erreurs avant d’avoir pu faire quoi que ce soit, et on ne désabonne jamais personne. Ou alors il faut baisser les seuils au point de désabonner une adresse à la première erreur 4xx, ce qui risque d’être un faux positif.

Il y a un moyen d’éviter ça ?

Oui mais c'est un peu bourrin.

Disons-le tout net : Sympa a des défauts de ce côté-là au niveau personnalisation, en particulier sur la granularité. Le seeul moyen de modifier l'espiration des bounces est de modifier la tâche d'expiration, et cette tâche ne peut être définie qu'au niveau du serveur.

Donc tu peux :

- copier <sympa>/default/tasks/expire_bounce.daily.task dans <sympa>/etc/tasks/expire_bounce.daily.task

- éditer <sympa>/etc/tasks/expire_bounce.daily.task

Son contenu est très simple :

title.gettext expire of bounces older than 10 days before message distribution

/ACTION
expire_bounce (10)
next ([execution_date] + 1d, ACTION)

Si tu remplace le expire_bounce (10) par expire_bounce (50) tes bounces n'expireront qu'au bout de 50 jours sans erreur.

Le problème, c'est que le serveur entier suivra cette règle. Donc tes taux d'erreurs vont augmenter sur toutes tes listes, y compris pour des erreurs qui ont eu lieu un mois plus tôt et sont résolues.

Il faut choisir son mal, là.

Je suppose que la bonne solution serait de pouvoir définir une durée d'expiration plus importante pour certaines listes ou tenir compte de l'activité de la liste au moment de l'expiration, mais ce n'est pas prévu dans le logiciel. À ma connaissance en tout cas.

Si tu en as le courage, tu peux faire un feature request sur Github auprès des développeurs actuels du produit. Ça ne doit pas être bien compliqué de trnasformer la tâche expire_bounce de tâche globale en tâche de liste. Ou une autre solution.

Bonne journée !

Cordialement,

David

 

Mathieu Roquefort
Chef de projet internet
Secours populaire français
Tél. : 33 (0)6 07 11 69 01
9/11 rue Froissart - 75140 Paris cedex 03
secourspopulaire.fr

    

De : adresse@cachée <adresse@cachée> de la part de David Verdin <adresse@cachée>
Date : mardi, 23 janvier 2024 à 15:26
À : adresse@cachée <adresse@cachée>
Objet : Re: [fr@sympa] listes en erreur

Eeeeet je m'aperçois immédiatement que j'ai oublié un détail : l'expiration.

Je complète donc : quand une adresse en erreur ne présente plus d'erreur pendant 10 jours, leurs erreurs sont effacées. La durée doit pouvoir être changée par un paramètre dont j'ai oublié le nom.

Le 23/01/2024 à 15:02, David Verdin a écrit :

Aaaaaaah... Une question sur les bounces, chouette ! 🙂

Cette partie de la doc a toujours été la plus mal fichue. Mea culpa, j'aurais dû l'améliorer depuis bien longtemps et maintenant ce n'est plus moi qui m'en occupe. On va rattraper ça dans ce message. Ça va être un peu long mais ça vaut le coup de lire jusqu'au bout.

1. Pourquoi Sympa gère-t-il les erreurs de messagerie (bounces - "rebonds" - en anglais) ?

En messagerie électronique, l'erreur est la norme. Du fait du grand nombre de fournisseurs de messagerie, d'outils et d'intermédiaires techniques sur le trajet d'un mail, il peut être rejeté à tout moment de son trajet et revenir à l'expéditeur. Les causes d'erreurs sont multiples : adresse inexistante, boîte mail pleine, classement en spam, etc.

Au temps anciens, c'était la personne ayant expédié le mail à la liste qui recevait ces erreurs. Outre le fait qu'il n'y comprenait la plupart du temps rien, il ne pouvait pas faire grand chose pour résoudre le problème.

C'est pourquoi, assez rapidement, on a fait suivre le message aux propriétaires de la liste plutôt qu'à l'expéditeur. À l'époque (je parle de la fin des années 90) on attendait des propriétaires de listes suffisamment de compétences techniques pour comprendre le message d'erreur renvoyé et y remédier. En avertissant le destinataire en erreur, par exemple, ou bien en contactant son fournisseur de mail, ou encore en modifiant ou désabonnant l'adresse d'abonné en erreur.

Les listes prenant du volume, ce travail est rapidement devenu fastidieux. Les listes se généralisant, le nombre de propriétaires capables et désireux de comprendre les erreurs de messagerie diminuait. Par ailleurs, la manière de corriger une adresse en erreur était plus ou moins toujours la même : on tentait d'avertir le destinataire et si on y arrivait pas, on le désabonnait. Autant de raisons pour que ce soit une machine qui fasse le travail, libérant du temps de cerveau humain pour envoyer des images de chat.

2. Comment gère-t-on les bounces dans Sympa ?

Principe : Après avoir reçu un certain nombre d'erreurs pour une adresse donnée, Sympa commence à calculer une note d'erreur pour cette adresse, qui augmente à chaque nouvelle erreur. Une fois que la note dépasse un certain seuil, Sympa effectue un action sur l'adresse. Cette action peut-être un message d'avertissement ou désabonnement.

2.1. À quel moment commence-t-on à calculer une note ?

On ne calcule la note que si :

1.       le nombre d'erreurs reçues pour un adresse est supérieur à la valeur du paramètre minimum_bouncing_count (définit dans sympa.conf uniquement, donc global au serveur) 2.       le temps(en nombre de jours) entre le premier et le dernier bounce reçu est supérieur à la valeur du paramètre minimum_bouncing_period (définit dans sympa.conf uniquement, donc également global au serveur)

Tant que ces deux critères ne sont pas satisfaits, Sympa ne calcule pas de note d'erreur et n'entreprendra donc aucune action pour corriger les erreurs.

Une fois par jour, Sympa évalue le nombre d'erreurs reçues pour chaque adresse, les compare aux deux seuils ci-dessus et , s'ils dépassent les deux seuils, leur attribue une note.

2.2. Pourquoi ne pas calculer la note tout de suite ?

Pour éviter de désabonner des adresses qui auraient juste une erreur temporaire. Cette précaution remonte bien sûr à une période où l'écosystème de messagerie était beaucoup plus diversifié qu'il ne l'est aujourd'hui. Les erreurs temporaires sont sans doute un peu plus rares mais elles sont loin d'avoir disparu.

Même en réduisant les seuils au minimum, vous devez attendre au moins un jour avant que Sympa calcule une note d'erreur. Cette prudence peut vous gêner, notamment en laissant traîner des erreurs dues à des fautes de frappe dans une adresse au moment de l'abonnement.

Pour les impatients, Sympa dispose de moyens d'accélérer le désabonnement quand on reçoit une erreur au moment de l'abonnement ou du rappel d'abonnement.

Vous avez deux paramètres : "verp_welcome" et "verp_remind". Les deux valent "on" ou "off". Les deux peuvent être définis au niveau de chaque liste ou du serveur (sympa.conf).

·         si "verp_welcome" vaut "on", alors quand on abonne une adresse, si le message de bienvenue à la liste revient en erreur, elle est désabonnée tout de suite ·         si "verp_remind" vaut "on", c'est pareil, mais pour le message de rappel d'abonnement.

Ces deux paramètres permettent donc de désabonner des utilisateurs sans passer par l'algorithme normal de Sympa. Évidemment, on ne discrimine pas les erreurs temporaires ou permanentes et on peut donc désabonner abusivement. Mais ça évite de conserver trop longtemps des adresses qui n'existent plus ou ont été mal orthographiées à l'abonnement.

2.3. Le calcul de la note d'erreur

Cela dépend essentiellement de l'activité de la liste. Recevoir 2 erreurs en une semaine pour une adresse donnée n'a pas la même signification si la liste a envoyé 2 ou 100 messages sur le même période.

Tous les jours, au moment d'évaluer les erreurs, si une adresse remplit les conditions précisées en 2.1, on lui attribue la note suivante ('tention, voilà la formule !) :

note = nb_erreurs x type_dernière_erreur x pourcentage_erreurs

Où :

nb_erreurs = nombre d'erreurs enregistrées pour l'adresse depuis la date de sa première erreur jusqu'à celle de la dernière (qui n'a pas forcément eu lieu aujourd'hui)

type_dernière_erreur = vaut 1 si la dernière erreur était un code 5xx (erreur permanente) ou 0,5 si la dernière erreur était un code 4xx (erreur temporaire)

pourcentage_erreurs = nb_erreurs / nombre de message envoyés par la liste pendant la même période. C'est le "regularity_rate" dans la doc de Sympa

 

Exemple :

Première erreur reçue il y a 15 jours. Dernière il y a cinq jours. Pendant cette période, on a reçu 16 erreurs. La dernière erreur était une erreur temporaire (Par exemple, "422 mailbox full").

Pendant cette période, la liste a expédié 75 messages.

On a donc :

nb_erreurs = 16

type_dernière_erreur = 0,5

pourcentage_erreurs = 16 / 75

=> soit une note = 16 x 0,5 x 16/75 = 1,7

 

Supposons, pour la rigolade, que pendant cette période, la liste n'ait envoyé que 16 messages et que la dernière erreur ait été permanente (Disons "510 Bad email address").

on obtient la note = 16 x 1 x 16 / 16 = 16.

 

[Aparté : le fichier "msg_count". Présent dans le répertoire de chaque liste, son rôle est de tenir le compte, pour chaque jour, du nombre de messages diffusés dans la liste. Une ligne par jour. "C'est tout ?" Oui, c'est tout.]

Voilà comment on calcule la note. Et maintenant, voyons ce qu'on en fait.

De cette note.

2.4. Les deux seuils d'erreur

Au bout de tous ces traitements, on trouve la sanction sous forme de deux seuils, habilement nommés "niveau 1" (bouncers_level1) et "niveau 2" (bouncers_level2).

Un seuil est un paramètre de liste composé d'une valeur entière (rate), d'une action : prévenir, désabonner ou ne rien faire (action) et d'un type de personne à notifier : les propriétaires de liste, les administrateurs du serveur ou personne (notification).

Une fois par semaine, Sympa compare la note de chaque adresse en erreur à ces seuils, dans l'ordre : le niveau 2, puis le niveau 1 (on cherche le plus grave d'abord). Si cette note dépasse le seuil, elle effectue l'action, envoie la notification et s'arrête là.

Par exemple, avec la configuration suivante :

bouncers_level_1
rate 5
action notify_bouncers
notification owner

bouncers_level_2
rate 10
action remove_bouncers
notification listmaster

On aura le comportement suivant :

1.       les adresses en erreur dont la note dépasse 10 atteignent le seuil 2 : on les désabonne et on prévient les listmasters qu'ils ont été désabonnés 2.       les adresses en erreur dont la note dépasse 5 atteignent le seuil 1 : on leur envoie un mail d'avertissement et on prévient les propriétaires qu'il risquent d'être désabonnés. Ça laisse un peu de temps pour tenter de corriger l'adresse, chercher un collègue pour aider, on ne rien faire parce qu'on n'a de toutes façons pas le temps. 3.       pour les adresses en erreurs n'ayant pas de note ou dont la note est strictement inférieure à 5 : on n'atteint aucun seuil, donc on ne fait rien

 

Voilà, vous en savez autant que moi maintenant. Il reste des détails, comme le VERP que je peux expliquer si ça intéresse quelqu'un. Mais si vous avez compris tout ça, vous savez comment Sympa gère les erreurs.

Note 1 : la plupart des durées, fréquences, valeurs peuvent bien sûr changer. L'évaluation des adresses en erreur est faite une fois par semaine par défaut. On peut très bien la passer à une fois par jour ou une fois par heure. Mais la plupart des gens se satisfont des valeurs par défaut.

Note 2 : tous les paramètres de listes peuvent voir leur valeur par défaut changée au niveau du serveur, donc globalement; Si vous voulez abaisser le seuil de niveau 1 pour toutes vos listes, pas la peine de les modifier à la main : vous n'avez qu'à changer ou faire changer la valeur par défaut du serveur

Note 3 : puisqu'on en parle, les valeurs de seuil par défaut de Sympa sont très généreuses : 45 pour le niveau 1 et 75 pour le niveau 2. J'ai personnellement abaissé ces valeurs respectivement à 1 et 5 sur tous les domaines gérés par RENATER. Ça accélère bien le ménage.

 

Bonne journée !

Cordialement,

David Verdin

Le 23/01/2024 à 09:55, Mathieu Roquefort a écrit :

Bonjour,

 

Je me permets de réagir à cet échange.

Nous utilisons au Secours populaire un serveur Sympa depuis plus de 10 ans. Il est infogéré, donc nous n’administrons pas tout. Mais nous essayons de comprendre le fonctionnement autant que possible.

Je n’ai jamais compris le fonctionnement des bounce, qui me semble largement perfectible.

Je viens de lire la page envoyée par Simon, et cela se confirme : je n’y comprends rien.

Il y a un calcul qui est expliqué, mais il est incompréhensible, car on y multiplie des choux avec des carottes. Le « Regularity rate » détient la palme du cryptique, car on sait juste qu’il est « déduit des donnés du fichier msg_count ». La belle affaire…

 

Je deviens un peu sarcastique, pardon.

Mais la question du désabonnement des adresses inactives est essentielle dans un système de listes. Et elle m’a l’air d’être défaillante avec sympa. J’ai régulièrement des listes avec des dizaines d’adresses en erreur depuis des semaines, et qui ne sont toujours pas désabonnées. Mais comme je ne comprends rien au fonctionnement, il m’est impossible de le corriger. On fait donc tout ça à la main, c’est infernal.

 

Est-ce qu’il y a des personnes qui y voient clair sur cette question ?

 

Bien à vous,

 

Mathieu Roquefort
Chef de projet internet
Secours populaire français
Tél. : 33 (0)6 07 11 69 01
9/11 rue Froissart - 75140 Paris cedex 03
secourspopulaire.fr

 

    

De : adresse@cachée <adresse@cachée> de la part de Simon Elbaz <adresse@cachée>
Date : mardi, 23 janvier 2024 à 09:23
À : Cyrille Giquello <adresse@cachée>
Cc : fr <adresse@cachée>
Objet : Re: [fr@sympa] listes en erreur

Bonjour,

 

La gestion des bounce (rejets) est décrite dans le lien suivant: https://www.sympa.community/manual/customize/bounce-management.html

 

Simon

 

On Tue, Jan 23, 2024 at 9:13 AM Cyrille Giquello <adresse@cachée> wrote:

Bonjour,

Je gère depuis quelques années listes.comptoir.net qui est utilisé par des collectifs citoyens. Le service est parfois bloqué par des fournisseurs car des emails inexistantes sont abonnées.

Ma question est comment trouver les listes avec des erreurs de distribution sans les inspecter une par une ? Effectivement il y a un soixantaine de listes hébergées. Comment procédez-vous pour surveiller les mauvaises distributions, qui risquent après quelques temps de bloquer l'ip du service ?

Merci de vos lumières :-)

Cyrille.

-- 

  Cyrille Giquello - 06 32 33 02 18 - adresse@cachée - FR37 Tours

 (¯`·._.·[  Coopérateur @ Artefacts - https://artefacts.coop  ]·._.·´¯)

ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¸¸,ø¤º°`°º¤ø¸¸,ø¤º°`°º¤ø

 Pour améliorer l'impact climatique du numérique informez vous:

 - https://librairie.ademe.fr/cadic/250/infographie-comment-teletravailler-leger.pdf

 - https://www.qqf.fr/infographie/69/pollution-numerique-du-clic-au-declic

  Pour toute question relative au bon usage et à la rectification

 de vos données à caractère personnel n'hésitez pas à me contacter.

--
"À un certain niveau, le sport n'a plus rien à voir avec le fair-play.
Il met en jeu la haine, la jalousie, la forfanterie, le mépris de toutes
les règles et le plaisir sadique que procure le spectacle de la violence.
En d'autres termes : c'est la guerre, les fusils en moins."
- Georges Orwell
 
David Verdin
La Fabrique
Direction des Services Applicatifs
RENATER - Rennes
            
--
"À un certain niveau, le sport n'a plus rien à voir avec le fair-play.
Il met en jeu la haine, la jalousie, la forfanterie, le mépris de toutes
les règles et le plaisir sadique que procure le spectacle de la violence.
En d'autres termes : c'est la guerre, les fusils en moins."
- Georges Orwell
 
David Verdin
La Fabrique
Direction des Services Applicatifs
RENATER - Rennes
          
        
      
    
-- 
"À un certain niveau, le sport n'a plus rien à voir avec le fair-play.
Il met en jeu la haine, la jalousie, la forfanterie, le mépris de toutes
les règles et le plaisir sadique que procure le spectacle de la violence.
En d'autres termes : c'est la guerre, les fusils en moins."
- Georges Orwell

David Verdin
La Fabrique
Direction des Services Applicatifs
RENATER - Rennes

Attachment: smime.p7s
Description: Signature cryptographique S/MIME