Bonjour,

j’ai installé votre plugin, mais malheureusement je recois un erreur :

TLS/SSL failure for pop.monserveur.com : SSL negotiation failed

j’ai configuré dans cfg comme dans mon thunderbird (où l’adresse fonctionne), avec
Securité : none
Option de sécurité : no valdate certificat

Est-ce que vous savez pourquoi je recois cet erreur ? Puisque je n’employe pas TLS ni SSL ..

Des idées qu’est-ce qui coince ?
Merci pour vos lumières

joz

Bonjour,

avant d’installer ce plugin je voudrais bien savoir comment le Listes-Cleaner traite les réponses automatiques genre "je ne reçois pas votre message car je suis abtent du bureau pour 2 semaines". Est ce que Listes-Cleaner distinge ce genre de réponse d’un réponse "failure notice" ou "Delivery Status Notification (Failure)" ?

Je ne veux pas risque que mes abonnés ne peuvent pas partir tranquillement en vacances sans risquer d’être irradié de la mailing liste ;-)

merci pour l’éclaircissement
joz

pour la cohérence entre auteurs et auteurs_élargis, problème que j’ai rencontré aussi...

je ne suis pas un pro de sql, mais un truc du genre

delete * from spip_auteurs where not in (select * from `spipcont`.spip_auteurs_élargis where...)

devrait marcher...

c’est ce que j’ai fait une fois, mais je ne suis pas sûr de la syntaxe exacte...

pam

Réponse rapide pour te permettre d’avancer, je n’aurai pas plus de temps avant la semaine prochaine.

1.2 SVN [28993] = version maintenant installée automatiquement.

Dans la page / ?exec=cfg&cfg=spiplistescleaner
je ne vois pas les nouvelles options.

Oui, il faut bien faire attention et configurer très bien au niveau du serveur de courriel pour que ça marche. >> mode d’emploi à rédiger.

Y a t’il une possibilité de supprimer tous les auteurs absents de la table spip_auteurs et encore présents dans spip_auteurs_élargis ?

C,est peut être pas mal de boulot, mais si on pouvait déclencher manuellement ton plugin puis suivre les étapes de son foctionnement, cela aiderais à le comprendre et à débugger des config qui dépendent de la config plugin/serveur. Idéalement on pourrait voir :
-  l’établissement de la connexion avec le serveur
-  les courriels qu’il y trouve
-  ceux qu’il identifie comme étant à traiter
-  l’action qu’il propose d’entreprendre ...
-  la validation de ces actions pourrait être manuelle en période de test, automatisée ensuite.
ce suivi serait bien placé dans les pages de gestion du plugin.

Chaque bounce identifié pourrait donner des points, (idéalement plus de points si l’adresse est inconnue du serveur que la boite pleine). Si un courriel arrive avant ce maximum atteint, réduction ou remise à zéro des points. A un certain nombre de points, adresse supprimée ou mise à la corbeille (avec idication de la date et de la cause de la mise au panier).

Il manque plus qu’une bonne page de suivi des auteurs pour identifier les auteurs bannis, donner la possibilité de les récupérer ou de les jetter, vérifier ceux qui ont des points de bannissement ....

Mais j’imagines que c’est plus facile à demander qu’a programmer

Je te reviens la semaine prochaine
Merci pour le boulot

Voilà tu es co-auteur de l’article, c’est avec grand plaisir que j’accepte ton aide. Par contre étant donné que j’ai développé ce plugin pour une boite Australienne dans laquelle je travail actuellement, il est important d’essayer d’avoir une copie exacte de la doc en Anglais (j’espère que cela n’est pas trop une grosse contrainte pour toi).

Au moment ou j’écris le chargement automatique du plugin n’est pas passé à la version 1.2, Je reverrai cela demain ou la semaine prochaine ...

=> Peu être un bug ? Je n’ai eu aucun problèmes de mon coté.

Le risque que les messages soient relevés par notre logiciel de messagerie avant d’avoir été traités par ton plugin existe toujours il me semble.

=> Je ne vois aucune solution viable à intégrer dans le plugin pour éviter cela. La 1ere solution comme tu l’as dit est de faire un compte rebond dédié à cela. La deuxième est de paramétrer le client pop pour qu’il laisse les mails sur le serveur en attendant qu’ils soient supprimé sur le client (option disponible dans thunderbird par exemple).

J’ai pas encore pu tester l’option "la méthode de suppression des auteurs " on en reparlera au besoin.

=> dans les deux méthodes les tables spip_auteurs_listes et spip_auteurs_elargis sont nettoyé, la seul différence est dans spip_auteurs où les enregistrements ne sont pas supprimé mais marqué "5poubelle" en statu.

Ton nettoyage de la table spip_auteurs_elargis va t’il aussi enlever les scories qui y sont actuellement ou juste pour les prochains nettoyages ?

=> Le nettoyage de la table spip_auteurs_elargis supprime bêtement les enregistrements lié a l’id d’un auteur. Mais j’ai peur de ne pas avoir compris ta question.

L’utilisation du plugin pour nous est sur le long terme. Le "once shot" qui a motivé son développement initial ne correspond pas au besoin de maintenir une base d’abonnés sur le long terme. Le principe de la riposte graduée est préférable, Mailman offre une approche exemplaire sur cette question, tu peux t’en inspirer.

=> Que penses tu si je rajoute une option avec le nombre de bounces mail minimum reçu avant de supprimer l’auteur ?

Mais le pire c,est que j’ai pas détecté si il m’avait bien fait le travail suite à mon dernier envoi. Je sais pas trop ou controler quoi pour savoir ce qui a coinçé. Pourrait il y avoir des points de contrôle ? un déroulement étape par étape du processus, un documentation plus précise pour que l’on s’y retrouve ... ?

=> Le plugin est sensé écrire dans les logs de spip mais j’ai remarqué que cela ne fonctionnait que quand SPIP-Listes-Cleaner est appelé par le CRON. Comment vois-tu l’implémentation de cette fonctionnalité ? Écrire le résultat de chaque étapes en html lors de l’appel de la fonction action serrait-elle suffisante ? Je n’ai malheureusement pas beaucoup de temps pour écrire de la documentation, je surf sur plein de projet en même temps, mais je reste ouvert à toutes évolutions.

super réactif, bravo.

Au moment ou j’écris le chargement automatique du plugin n’est pas passé à la version 1.2, Je reverrai cela demain ou la semaine prochaine ...

Pour les courriels, avec l’option au moins on sait ce qu’on fait et c’est toujours mieux, sinon ce n’était qu’un probléme de compréhension. Le risque que les messages soient relevés par notre logiciel de messagerie avant d’avoir été traités par ton plugin existe toujours il me semble. On doit pouvoir l’éviter en faisant renvoyer les rebonds sur un comte courriel que l’on ne reléve pas automatiquement. C’est une question de config à notre niveau, mais un manuel détaillé devrait être fourni dans l’article. Si tu veux que j’y participe, met moi co-auteur de l’article.

J’ai pas encore pu tester l’option "la méthode de suppression des auteurs " on en reparlera au besoin.

Ton nettoyage de la table spip_auteurs_elargis va t’il aussi enlever les scories qui y sont actuellement ou juste pour les prochains nettoyages ?

Mais j’arrives au plus important ...
-  L’utilisation du plugin pour nous est sur le long terme. Le "once shot" qui a motivé son développement initial ne correspond pas au besoin de maintenir une base d’abonnés sur le long terme. Le principe de la riposte graduée est préférable, Mailman offre une approche exemplaire sur cette question, tu peux t’en inspirer.
-  Mais le pire c,est que j’ai pas détecté si il m’avait bien fait le travail suite à mon dernier envoi. Je sais pas trop ou controler quoi pour savoir ce qui a coinçé. Pourrait il y avoir des points de contrôle ? un déroulement étape par étape du processus, un documentation plus précise pour que l’on s’y retrouve ... ?

// T’aurais pas du me dire "n’hésite pas à proposer des modifications" ;-) //

Passage en version 1.2 :
-  Ajout de deux option :
1) supprimer ou non les mails du serveur mail.
2) la méthode de suppression des auteurs
-  Correction d’un bug : maintenant la table spip_auteurs_elargis est aussi nettoyé

-  les adresses seront éliminées dés le premier rebond, même si ce n’est au’une boite aux lettres pleine ?
=> Surment, je n’ai pas fait l’essaie, il détecte tous les mails failure delivery (du moins plus de 90% d’entre eux).

-  peut on retrouver la trace des enregistrements éliminés avec une possibilité de réhabilitation ... idéalement après avoir pu changer l’adresse de la personne.
=> SPIP-Listes-Cleaner à tendance a cleaner peu être un peu trop car il supprime les enregistrements dans la bdd. A l’origine ce plugin a était crée pour une société qui achetait des fichiers client avec un tas d’adresses emails plus valide, donc c’était plus coherent de supprimer les enregistrement dans la bdd.

-  penser aussi à la table spip_auteurs_elargis qui contien notamment le format de chaque utilisateur. Maintenant chez moi elle contient plus d’enregistrements que spip_auteurs
=> je corrige ça d’ici la semaine prochaine

-  les courriels lus sur le serveur en pop3 ou en imap n’y sont pas éliminés ... On retrouvera ses messages en relevant nos courriels ( et avec pop3 on risque d’empêcher le plugin de les voir). Il faut vraiment que l’on puisse controler ce que le plugin a déja traité comme rebond pour ne retraiter manuellement que ce qui ne l’a pas déja été.
=> la je ne comprend pas. Normalement à partir du moment qu’il a supprimé quelque chose dans la bdd il va aussi supprimer le mail sur le serveur pop3 ou imap. Donc normalement tu ne devrai retrouver que les mails qu’il n’a pas pu traiter.

-  Pardon si je suis en train d’alourdir le cahier des charges, les choses merveilleuses ne se construisent pas en un jour ;-)
=> n’hésite pas à proposer des modifications ou à en faire sur le serveur SVN.

-  Surpris par un retour aussi rapide pour ce plugin (qui est en passant mon 1er plugin spip) :)

Ouaoo, je suis le premier à laisser un message sur ce plugin. Bienvenue, la gestion manuelle des retours était vraiment une contrainte avec SpipListes.

Questions et interrogations ...
-  les adresses seront éliminées dés le premier rebond, même si ce n’est au’une boite aux lettres pleine ?
-  peut on retrouver la trace des enregistrements éliminés avec une possiblité de réhabilitation ... idéalement après avoir pu changer l’adresse de la personne.
-  penser aussi à la table spip_auteurs_elargis qui contien notamment le format de chaque utilisateur. Maintenant chez moi elle contient plus d’enregistrements que spip_auteurs
-  les courriels lus sur le serveur en pop3 ou en imap n’y sont pas éliminés ... On retrouvera ses messages en relevant nos courriels ( et avec pop3 on risque d’empêcher le plugin de les voir). Il faut vraiment que l’on puisse controler ce que le plugin a déja traité comme rebond pour ne retraiter manuellement que ce qui ne l’a pas déja été.

Pardon si je suis en train d’alourdir le cahier des charges, les choses merveilleuses ne se construisent pas en un jour ;-)