[mail] envoi en masse incomplet

Le 10/02/2009 15:56, Pascal PONCET a écrit :

Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).

Le problème principal, c'est que PHP n'est pas fait pour administrer une
liste de diffusion.

Le site est hébergé en mutualisé chez OVH.

Je ne sais pas si l'offre est accessibles aux hébergements mutualisés
mais j'ai trouvé ça chez OVH : http://guides.ovh.com/AdministrerMailingList

Qu'en pensez-vous ?

J'en pense que tu devrais en parler avec ton hébergeur pour avoir
une vraie offre de liste de diffusion (avec en général gestion des
inscriptions et désinscriptions, traitement des adresses en erreur,
etc.) plutôt qu'un bricolage en PHP.

On 10 Feb 2009 14:56:11 GMT, Pascal PONCET wrote:

Bonjour,

Bonjour,

Je suis confronté à un problème de gestion des envois en masse d'e-mail,
à savoir que le serveur est dans les choux aux alentours du 2500e e-mail
(pas de message d'erreur, pas de retour HTTP, page blanche et script
arrêté).

J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.

Est-il possible, avec ta classe PHPMailer ou autre que tu pourrais y
substituer (je ne connais pas) de ne *pas* passer par un serveur HTTP,
qui est ici complètement inutile et potentiellement sources d'emmerdes
(d'ailleurs c'est ton cas).

L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.

1. Augmenter le timeout sur le serveur. Ça parait la solution simple et
idéale, vu que le serveur actuel permet de passer par "set_time_limit".
Le problème, c'est qu'il faut tester cette solution et que c'est très
gênant de balancer 10000 e-mails dans la nature sans savoir ce qu'ils
deviennent (au cas où ça ne fonctionne toujours pas). Et puis je reste
tributaire du paramétrage serveur (un safe-mode et c'est foutu).

Tu ne log pas la réponse du serveur de mail distant ? Comment sais-tu
alors s'ils ont bien été acceptés ? Et ceux qui ne l'auraient pas été ?

Cela dit si tu tiens absolument à passer par la chaîne navigateur >
serveur httpd > PHP, c'est à mon avis cette solution la meilleure. Mais
il faut bien sûr s'assurer de la bonne/mauvaise livraison des mails,
gérer les erreurs et stocker tout ça quelque part pour le ré-exploiter.

2. Créer un fichier d'envoi, comprenant les coordonnées des
destinataires, et découper ce fichier par tranche (de 2000 contacts par
exemple). Puis lancer autant de fois le script qu'il y a de tranches.

3. Créer un fichier d'envoi unique, et gérer un point d'arrêt tous les
2000 contacts. Ça peut se faire simplement en marquant les coordonnées
servies, ou en les effaçant successivement du fichier pour traiter ceux
qui restent.

Ces deux solutions sont un contournement :-(

4. Faire un script qui, après avoir enregistré les coordonnées des
contacts (dans un fichier ou une table BDD), affichera une page WEB qui
va gérer les envois un par un.
Cette page appellera pour chaque contact, en AJAX récursif, un autre
script chargé d'envoyer l'e-mail et de retourner l'identifiant du
contact suivant. Cette page pourrait aussi afficher successivement les
coordonnées des contacts servis, pour suivre les envois en temps réel.

La dernière solution, un peu plus complexe à mettre en ½uvre, a
l'avantage de fonctionner à tous les coups et quelque soient les
limitations du serveur.

AMHA non car tu es tout autant dépendant de ton HTTPd, mais d'une
autre manière. Et cela nécessite toujours un navigateur... pour envoyer
une liste de diffusion.

Elle est aussi très visuelle, car on a jamais d'informations sur ce que
fait le serveur quand on utilise les techniques habituelles.

J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.


Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.

Olivier Miakinen a écrit :

Le problème principal, c'est que PHP n'est pas fait pour administrer une
liste de diffusion.

Bonjour Olivier,

Je n'ai pas trop le choix, car toute l'application est en PHP, et que
l'e-mailing doit être entièrement interfacé avec l'existant.

Je ne sais pas si l'offre est accessibles aux hébergements mutualisés
mais j'ai trouvé ça chez OVH : http://guides.ovh.com/AdministrerMailingList

Ok, mais comment gérer un suivi complet avec ce type de service ?
Par exemple :
- Ouverture des e-mails.
- Click sur les liens de l'e-mail.
- Désinscription enregistrée dans la fiche contact.

J'en pense que tu devrais en parler avec ton hébergeur pour avoir
une vraie offre de liste de diffusion (avec en général gestion des
inscriptions et désinscriptions, traitement des adresses en erreur,
etc.) plutôt qu'un bricolage en PHP.

Dans ce cas, je préfèrerais sous-traiter à un prestataire spécialisé qui
me donnerait accès à une API pour le suivi.
Mais, pour l'instant, je voudrais absolument éviter ça.

Merci,
Pascal

Thibault a écrit :

Bonjour,

Bonjour et merci,

Est-il possible, avec ta classe PHPMailer ou autre que tu pourrais y
substituer (je ne connais pas) de ne *pas* passer par un serveur HTTP,
qui est ici complètement inutile et potentiellement sources d'emmerdes
(d'ailleurs c'est ton cas).

L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.

Je n'ai pas autant de libertés sur un serveur mutualisé. Hélas, mais la
migration vers un dédié n'est pas à l'ordre du jour.

Tu ne log pas la réponse du serveur de mail distant ? Comment sais-tu
alors s'ils ont bien été acceptés ? Et ceux qui ne l'auraient pas été ?

Cela dit si tu tiens absolument à passer par la chaîne navigateur >
serveur httpd > PHP, c'est à mon avis cette solution la meilleure. Mais
il faut bien sûr s'assurer de la bonne/mauvaise livraison des mails,
gérer les erreurs et stocker tout ça quelque part pour le ré-exploiter.

C'est un des problèmes, je n'ai aucune vue sur le traitement des envois,
toujours à cause du mutualisé. Et pas plus sur les retours (OVH est
censé me retourner automatiquement les notifications d'erreurs, mais
sans garantie de service).

J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.

J'aimerais bien en savoir plus sur ta technique !
L'application est en PHP ? Comment sont déclenchés les envois d'e-mail ?
Les retours sont gérés par la même application ? etc.

Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.

Ok, mais comment faire lorsque la plateforme de gestion des contacts (et
des campagnes par e-mailing) est déjà écrite en PHP ?
Olivier suggérait l'utilisation de la gestion de listes de diffusion
chez OVH. Certes, le service existe bien, mais alors je ne disposerais
d'aucune connectivité applicative entre ce service et ma gestion de
contacts existante (ou alors je ne sais pas faire).

En résumé, ma question est toujours : comment résoudre le problème de
capacité d'envoi d'e-mails en masse sur un serveur mutualisé, tout en
conservant l'intégration de ce service dans l'application existante qui
gère tout le reste ?

Cordialement,
Pascal

Pascal PONCET <poncet.pascal@club-internet.fr> wrote :

En résumé, ma question est toujours : comment résoudre le problème
de capacité d'envoi d'e-mails en masse sur un serveur mutualisé,
tout en conservant l'intégration de ce service dans l'application
existante qui gère tout le reste ?

La question revient souvent ; elle avait longuement été débattue sur
les forums de feus phpinfo.net et phpapps.org. Avec tes contraintes,
la seule solution consiste à saucissonner ie envoyer les mails par
paquet par exemple de 100 à 200 mails et à appeler le script autant
de fois que nécessaire. Si ton hébergeur n'autorise pas le cron en
mutualisé, il existe des services en ligne qui permettent d'y
pallier (par exemple webcron).

--
Antoine

Antoine wrote:

La question revient souvent ; elle avait longuement été débattue sur
les forums de feus phpinfo.net et phpapps.org. Avec tes contraintes,
la seule solution consiste à saucissonner ie envoyer les mails par
paquet par exemple de 100 à 200 mails et à appeler le script autant
de fois que nécessaire. Si ton hébergeur n'autorise pas le cron en
mutualisé, il existe des services en ligne qui permettent d'y
pallier (par exemple webcron).

J'interviens sûrement en retard, mais pour moi la solution la plus
simple est d'avoir les données (adresses email) en base, avec en plus
une colonne "flag" binaire.
Toutes les adresses utilisées sont flaggées à 1 (envoi effectué), les
autres à 0.
Ainsi, indépendemment de la méthode de découpage, je ne vais prendre que
les adresses qui ont un flag à 0.
Et l'utilisation de Cc ou Bcc pour envoyer 50 mails à la fois est très
pratique, ça limite l'utilisation de mail() et permet de réduire la
queue dans le sendmail (ou exim ou n'importe quoi).

Il faut bien sûr penser à remettre le flag à 0 à la création d'un
nouveau mass-mail.


--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces webmasters : http://www.c-p-f.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr

On 11 Feb 2009 09:24:52 GMT, Pascal PONCET wrote:

J'utilise une technique basique et « habituelle », toutes les infos
sur la liste, les contacts et les retours des serveurs sont dans une
base de données et j'ai un front qui me sort des informations et
statistiques de tout ça en temps réel donc je sais à peu prêt comment
les choses se passent, ainsi que mes clients.

J'aimerais bien en savoir plus sur ta technique !
L'application est en PHP ? Comment sont déclenchés les envois d'e-mail ?

Je peux pas te donner le schéma de la base mais grosso mode tu as une
table pour les différents mailing (les headers, le body, le multipart
éventuel...), puis une autre pour les adresses mail liées à ces mailing
(et les infos liée à une adresse, tracking, message customisé...). Après
la base se fait attaquer par plusieurs « morceaux » :

* une partie pour ceux qui gèrent les mailing, en PHP, accessible par le
web, qui permet de les programmer, preview, gérer les adresses,
résultats tracking etc...

* une partie pour ceux qui reçoivent les mailing, quelques scripts PHP
pour répondre à ce que peut inclure (lien, images) le mail final reçu :

* désinscription (pour répondre au lien idoine)
* tracking ouverture
* tracking de liens
* ...

* le mailer proprement dit, qui actuellement itère régulièrement sur une
partie de la base en étant exécuté périodiquement par cron. Il ne
soumet pas les mails au MTA local, mais contacte directement les hôtes
distants en SMTP.

Les deux premières parties sont donc en PHP car cela faisait parti de
la contrainte.

Les retours sont gérés par la même application ? etc.

Si c'est la réponse du SMTP distant, je la stock en base et je la
ré-exploite quand nécessaire. Si c'est un éventuel bounce, je ne vois
pas comment un outil peut le traiter (correctement).

La seule partie que je peux diffuser est une version du mailer :

http://pastie.org/386474

Attention car ceci a été écrit un peu à l'arrache, c'est pas très
beau, pas très performant, et surtout pas très conformes aux RFCs (je
l'avais fait de mémoire), mais ça peut donner une idée du schéma de la
base ou du système dans son ensemble.
Si j'avais le temps j'écrirais ça sous la forme d'un daemon
multi-thread :-)

Je suis d'accord avec Olivier pour dire que ce n'est pas forcément la
meilleure approche, bien qu'il soit possible de faire un truc propre en
PHP ce n'est sûrement pas la vocation première de ce langage.

Ok, mais comment faire lorsque la plateforme de gestion des contacts (et
des campagnes par e-mailing) est déjà écrite en PHP ?

Si elle se limite à ces tâches ce n'est pas gênant, seul l'envoi des
mails te pose problème donc il suffit de faire un script à part pour
cette tâche, mais en mettant à jour les données gérées par la
plateforme (des fichiers textes j'avais cru comprendre, il n'y a pas du
tout de DB ?).

Olivier suggérait l'utilisation de la gestion de listes de diffusion
chez OVH. Certes, le service existe bien, mais alors je ne disposerais
d'aucune connectivité applicative entre ce service et ma gestion de
contacts existante (ou alors je ne sais pas faire).

Ou utiliser un prestataire qui répond à tous tes besoins (pour ne plus
avoir besoin de tes outils).

En résumé, ma question est toujours : comment résoudre le problème de
capacité d'envoi d'e-mails en masse sur un serveur mutualisé, tout en
conservant l'intégration de ce service dans l'application existante qui
gère tout le reste ?

Je ne suis pas sûr qu'il soit solvable, vouloir faire de l'envoi SMTP
par l'intermédiaire d'une prestation d'hébergement *HTTP* *mutualisée*
ça me semble logique que ça coince à un moment surtout qu'on est
fortement dépendant de l'hébergeur.

Si la sécurité n'est pas un critère, peut-être voir du côté des dédiés
pas chers ou VPS ?

Thibault a écrit :

La seule partie que je peux diffuser est une version du mailer :

http://pastie.org/386474

Merci, très intéressant (même si je ne maîtrise pas Ruby).

Connais-tu l'équivalent PHP de "dns.getresources" ? (ligne 140)
Parce qu'à un moment, j'ai cru que tu avais une liste de paramétrage des
principaux domaines (genre FAI).
C'est effectivement le dernier point qui me reste, envoyer les mails par
une socket SMTP, donc directement à chaque domaine.

Sinon, j'ai mis au point le système de découpe du fichier d'envoi par
une fonction XmlHttpRequest récurente. C'est très efficace.
J'ai aussi prévu, dans le traçage des mails (géré en BDD), d'indiquer
que l'e-mail est supposé avoir été envoyé.
Une précision pour être sûr que j'ai bien compris : tu n'as aucun moyen
de savoir si l'e-mail a été effectivement distribué, ni d'obtenir et de
gérer une notification d'erreur du serveur destinataire ?

@+,
Pascal

Pascal PONCET a écrit :

J'utilise la classe PHPMailer, avec la méthode d'envoi par défaut
"mail". Les e-mails sont rédigés en HTML. Le site est hébergé en
mutualisé chez OVH.

Qu'en pensez-vous ?

Cordialement,
Pascal

êtes vous au courant que le mutualisé, chez OVH, est très restrictif
concernant les mails ? en gros, mauvais hébergeur pour ce type de mailling.

anthony

Pascal PONCET scripsit:

L'idée serait de lancer ton script directement en ligne de commande, à
la main, ou de programmer par CRON une exécution régulière de ce
dernier.

Je n'ai pas autant de libertés sur un serveur mutualisé

Pour le cron, si. (Dans le manager, section hébergement, icône « tâches
planifiées ».) Pour la ligne de commande, c'est un peu plus compliqué :
tu as un accès ssh à une machine avec tes fichiers, et une dizaine de
versions de PHP en ligne de commande, mais où la fonction mail() est
désactivée. Tu peux peut-être t'en sortir en configurant ton instance de
PHPMailer pour utiliser un serveur SMTP externe si tu en as un.


--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/