[spip-dev] envoi de mail

Salut,
j'ai un bout de code que je me traine depuis un moment pour utiliser le
webmail de free (avec la classe protomail) et une petite modif du header
pour eviter un filtre antispam.
Ca m'interesse donc de voir ton code pour voir ou on peut se "rebrancher"
facilement, voir si je peux faire pareil avec le header et valider qu'on
peut utiliser facilement la gestion par lot et le parametrage.
Comment c'est utilisé ?
Par le cron* ?
L'idée d'un systeme de notification modulaire et parametrable me plait bien,
en tous cas ...
Par contre, on parle de classes.
Quel est le niveau de PHP necessaire à ce code ?
Quel est le niveau de compatibilité souhaité pour Spip 1.8 ?

*A ce propos, y a-t-il un debut de doc qqpart sur le cron et les dernieres
modifs ?
Je dois avouer que je n'ai pas bien suivi les differences de fonctionnement
entre le lab et la cvs ni quelle action faisait quoi ...
Merci.

Jacques PYRAT a écrit :

BoOz wrote:

Mathieu Lecarme a écrit :
J'ai déjà fait la plupart de ces trucs as tu vu ?

http://demo.bloog.net/rubrique.php3?id_rubrique=1

Booz, tu voudrais pas mutualiser tes développements avec ceux de Mathieu.
Y'a matière a faire un truc super à vous deux :wink:

Ben si, la bloogletter est sous gnu/gpl.
Donc il est possible de regarder le code et d'y rajouter une fonction d'envoi par smtp, ou de mieux soigner les entetes mail par exemple.

Pour le reste des fonctions usuelles, je crois que la bloogletter fait déjà tout ce qu'il faut, et je suis perplexe sur l'opportunité de gérer automatiquement les retour d'erreurs, mais si vous voulez essayer les performances d'une uzine à gaz avec une boite pop vous me direz ce que ca donne.

Je retarde la sortie de la version 4 de mon script parce que j'y ai beaucoup travaillé, et que j'attends qu'une ou plusieurs institutions que ca interresse d'envoyer des mails sur des listes variées la finance.

Il faut pouvoir se permettre de passer du temps comme ca à développer du bien public, certains sur cette listes ont des plans pour financer leurs devs, pour le moment je n'en ai pas de définitifs pour ce projet.

Mais la version 3 de la blogletter est déjà distribuée, elle.

@+

BoOz

Jacques PYRAT a écrit :

BoOz wrote:

La gestion des bounces automatiques nécéssite un serveur de mail et
beaucoup de taches pour pas grand chose AMHA...

Ben, quand tu as 100 abonnés, peut-être pas.
Mais sur www.tregouet.org avec + de 6000 abonnés, le taux de bounce n'est
pas exactement une sinécure (et la solution CleverMail non plus
d'ailleurs...).
Au CRU sur Sympa, certaines listes ateignent les 50% de bounces avec donc un
trafic entrant et sortant inutile non négligeable.

Comment font il pour avoir tant de déchet ?

Si tu en est là, rien ne t'empèche de rediriger les retours vers une boite pop et de faire le menage la dedans avec un script, mais je ne pense pas qu'on doive plomber les perf de spip et de la bloogletter avec ce script par défaut.

Je redigerai un truc expliquant comment faire cela à l'occasion.

@+

BoOz

Bonjour,

La gestion des bounces automatiques nécéssite un serveur de mail et
beaucoup de taches pour pas grand chose AMHA...

>

Ben, quand tu as 100 abonnés, peut-être pas.
Mais sur www.tregouet.org avec + de 6000 abonnés, le taux de bounce n'est
pas exactement une sinécure

C'est clair qu'avec pas mal d'abonnés, la gestion des bounces peut être problématique. Mais c'est surtout le cas si l'outil est utilisé pour du SPAM sur une liste d'adresses non vérifiées.

Dans le cas d'une "vraie" newsletter dans les règles, on envoi un mail lors de l'inscription pour valider l'adresse, donc les erreurs lors des envois suivants doivent être plutôt rares.

Du coup, il est à priori plus simple de gérer les retours à la main, vu qu'il n'y a aucune norme de message d'erreur, que tous les serveurs SMTP utilisent leurs propres messages ...

(et la solution CleverMail non plus d'ailleurs...).

CleverMail (et donc SPIP-Agora qui l'intègre) fait justement cette vérification d'adresse, mais ne propose en effet pas de gestion des bounces. Il faut dire qu'en quelques heures de développement, je ne lui ai fait faire que le minimum pour gérer des envois ... :wink:

Au CRU sur Sympa, certaines listes ateignent les 50% de bounces avec donc un
trafic entrant et sortant inutile non négligeable.

C'est qu'il y a un manque au niveau de l'administration des listes, peut-être, non ?

Quoi qu'il en soit, j'ai hâte moi aussi de voir cette Bloogletter 4 !!!

-Nicolas

Nicolas Hoizey a écrit :

Quoi qu'il en soit, j'ai hâte moi aussi de voir cette Bloogletter 4 !!!

Et moi de voir celle de spip-agora, que je n'ai toujours pas vu car je n'ai pas été foutu d'installer spip-agora sur mes machines :slight_smile:

@+
BoOz

Quoi qu'il en soit, j'ai hâte moi aussi de voir cette Bloogletter 4 !!!

Et moi de voir celle de spip-agora, que je n'ai toujours pas vu car je n'ai pas été foutu d'installer spip-agora sur mes machines :slight_smile:

Le tout est de présenter son problème sur la mailing-list, et en général les autres répondent pour t'aider ... :wink:

-Nicolas

LAURENT Stephane a écrit :

Salut,
j'ai un bout de code que je me traine depuis un moment pour utiliser le
webmail de free (avec la classe protomail) et une petite modif du header
pour eviter un filtre antispam.
Ca m'interesse donc de voir ton code pour voir ou on peut se "rebrancher"
facilement,

En théorie, c'est prévu pour, on va pouvoir voir si la pratique fonctionne.

voir si je peux faire pareil avec le header

La class a un attribut (une Array) où on empile les headers. Il est donc simple d'en rajouter.

et valider qu'on
peut utiliser facilement la gestion par lot

Pas encore fait.

et le parametrage.

Fait via les attributs et les metas.

Comment c'est utilisé ?
Par le cron* ?

oui.

L'idée d'un systeme de notification modulaire et parametrable me plait bien,
en tous cas ...

Ca, c'est la machine d'Antoine.

Par contre, on parle de classes.
Quel est le niveau de PHP necessaire à ce code ?

Pour garder la Spip attitude, les fonctions sont en français, les variables explicite, et il y a des _ dans les noms.
Le code est commenté en phpdoc.
Comme c'est une class, si l'on veut faire des actions bien spécifique, il suffit de créer une class qui hérite de la première et d'utiliser les méthodes publics, sans toucher au code de la class mère.

Quel est le niveau de compatibilité souhaité pour Spip 1.8 ?

maximal.

*A ce propos, y a-t-il un debut de doc qqpart sur le cron

http://lab.spip.net/spikini/CroN

et les dernieres
modifs ?
Je dois avouer que je n'ai pas bien suivi les differences de fonctionnement
entre le lab et la cvs ni quelle action faisait quoi ...

C'est le déclenchement qui varit. Un mail d'Antoine là dessus est passé il n'y a pas longtemps.

L'idée d'un systeme de notification modulaire et parametrable me plait

bien,

en tous cas ...

Ca, c'est la machine d'Antoine.

Non, non, je parle bien de ton boulot mais il y a 2 approches possibles :
celle d'Antoine, qui déspecialise le systeme de notification, et la tienne
qui remplace l'envoi de mail "classique" de Spip.
Selon la configuration, le systeme de notification finit par appeler la
fonction d'envoi d'email.
Si le systeme est bien fait, on peut se "rebrancher" en dessous pour faire
des choses differentes ou supplementaires (log, controle des bounces avant
envoi, ou pourquoi pas utilisation d'un outil de mailinglist)
Mais je suis peut etre à coté de la plaque par rapport à ce que tu as fait,
je vais attendre de voir ca avant de parler ...

Par contre, on parle de classes.
Quel est le niveau de PHP necessaire à ce code ?

Pour garder la Spip attitude, les fonctions sont en français, les
variables explicite, et il y a des _ dans les noms.
Le code est commenté en phpdoc.
Comme c'est une class, si l'on veut faire des actions bien spécifique,
il suffit de créer une class qui hérite de la première et d'utiliser les
méthodes publics, sans toucher au code de la class mère.

La question etait : quel est la version de PHP minimum pour faire tourner la
bete (et est-ce compatible PHP5 ?)

Quel est le niveau de compatibilité souhaité pour Spip 1.8 ?

maximal.

Meme question : version mini de PHP et de MySQL ?

Merci.

Mathieu Lecarme a écrit :

LAURENT Stephane a écrit :

Ca m'interesse donc de voir ton code pour voir ou on peut se "rebrancher"
facilement,

En théorie, c'est prévu pour, on va pouvoir voir si la pratique fonctionne.

voir si je peux faire pareil avec le header

La class a un attribut (une Array) où on empile les headers. Il est donc simple d'en rajouter.

et valider qu'on
peut utiliser facilement la gestion par lot

Pas encore fait.

Attention ici :

Par exemple, pour une liste d'info, ce qui m'interresse c'est de savoir ou j'en suis dans mon envoi (10%, 15 %) etc donc il me semble que la gestion des lots et de qui à recu quoi doit dépendre du script qui appelle la classe d'envoi de mail plutôt que de la classe elle même.

Qu'imagines tu comme système ?

Stephane LAURENT a écrit :

Non, non, je parle bien de ton boulot mais il y a 2 approches possibles :
celle d'Antoine, qui déspecialise le systeme de notification, et la tienne
qui remplace l'envoi de mail "classique" de Spip.
Selon la configuration, le systeme de notification finit par appeler la
fonction d'envoi d'email.
Si le systeme est bien fait, on peut se "rebrancher" en dessous pour faire
des choses differentes ou supplementaires (log, controle des bounces avant
envoi, ou pourquoi pas utilisation d'un outil de mailinglist)
Mais je suis peut etre à coté de la plaque par rapport à ce que tu as fait,
je vais attendre de voir ca avant de parler ...

Non, c'est tout à fait possible, tu es sur la bonne plaque

La question etait : quel est la version de PHP minimum pour faire tourner la
bete (et est-ce compatible PHP5 ?)

euh, le PHP de ma machine. C'est du PHP 4.3 la version standard je suppose,(hors Debian woody).
Je n'ai pas encore testé la compatibilité PHP5.
Pour bien faire, il faudrait une série de test unitaire pour valider sur les hebergements caracteriels ou exotiques.

Quel est le niveau de compatibilité souhaité pour Spip 1.8 ?
     

maximal.
   

Meme question : version mini de PHP et de MySQL ?

en utilisant les spip_query_db et autres abstractions, je vais confier la gestion du SQL à Spip. Et il n'y aura pas de SQL exotique

M.

Nicolas Hoizey wrote:

Bonjour,

C'est clair qu'avec pas mal d'abonnés, la gestion des bounces peut
être problématique. Mais c'est surtout le cas si l'outil est utilisé
pour du SPAM sur une liste d'adresses non vérifiées.

Dans le cas d'une "vraie" newsletter dans les règles, on envoi un mail
lors de l'inscription pour valider l'adresse, donc les erreurs lors
des envois suivants doivent être plutôt rares.

Tu n'imagine pas le nombre de personnes qui changent d'adresses email en
changeant de provider !
Et ce, même si les adresses ont été vérifiées au départ.

Tu n'imagine pas le nombre de personnes qui changent d'adresses email en
changeant de provider !
Et ce, même si les adresses ont été vérifiées au départ.

Bin oui, je sais bien, mais avec un envoi par semaine (c'est bien ça pour Tregouet ?), le nombre d'adresses modifiées à chaque fois ne doit pas être bien grand ...

-Nicolas

Je n'ai pas encore nettoyé cette partie du code, c'est trop tot pour rédiger la doc.
Pour les différences de fonctionnement entre les 2, c'est probablement équivalent bien que différent.

      Emmanuel