[mail] envoi en masse incomplet

[Pascal PONCET]

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.

Ceci étant posé, j'ai pensé à plusieurs solutions mais j'aimerais un
partage d'expérience là-dessus :

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).

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.

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.
Elle est aussi très visuelle, car on a jamais d'informations sur ce que
fait le serveur quand on utilise les techniques habituelles.
Par contre, le temps global de traitement risque d'être beaucoup plus
long (jusqu'à 10 fois plus à mon avis). Mais ce n'est pas dramatique
dans mon cas, car sur un maximum de 10000 envois on passerait de 1 à 10
mn de traitement par jour.

Qu'en pensez-vous ?

Cordialement,
Pascal

[Olivier Miakinen]

Post by Pascal PONCET
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.

Post by Pascal PONCET
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

Post by Pascal PONCET
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.

[Pascal PONCET]

Post by Olivier Miakinen
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.

Post by Olivier Miakinen
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.

Post by Olivier Miakinen
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]

Post by Pascal PONCET
Bonjour,

Bonjour,

Post by Pascal PONCET
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.

Post by Pascal PONCET
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.

Post by Pascal PONCET
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 :-(

Post by Pascal PONCET
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.

Post by Pascal PONCET
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.

[Pascal PONCET]

Post by Pascal PONCET
Bonjour,

Bonjour et merci,

Post by Pascal PONCET
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.

Post by Pascal PONCET
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).

Post by Pascal PONCET
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.

Post by Pascal PONCET
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

[Antoine]

Post by Pascal PONCET
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).

[CrazyCat]

Post by Antoine
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.

[Thibault]

Post by Pascal PONCET

Post by Pascal PONCET
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.

Post by Pascal PONCET
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 :-)

Post by Pascal PONCET

Post by Pascal PONCET
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 ?).

Post by Pascal PONCET
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).

Post by Pascal PONCET
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 ?

[Pascal PONCET]

Post by Thibault
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

[Thibault]

Post by Pascal PONCET

Post by Thibault
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)

Visiblement c'est checkdnsrr() mais ça fait longtemps que je ne l'ai
pas utilisée, tu auras aussi besoin en premier de getmxrr() pour obtenir
les MX, checkdnsrr() devrait servir pour les A.

Post by Pascal PONCET
Parce qu'à un moment, j'ai cru que tu avais une liste de paramétrage des
principaux domaines (genre FAI).

Pas sûr d'avoir compris, mais cette « liste » c'est le DNS et c'est
accessible publiquement pour tout le monde (sinon on aurait du mal à
s'échanger du mail ;-). Grosso modo tu fais une requête DNS pour
connaître les MX d'un domaine donné, puis tu les essaye dans l'ordre un
par un.

Un petit exemple en PHP :

--------8<--------
#!/usr/bin/env php
<?php

array_shift($argv);

foreach ($argv as $domain) {
$t_mx = null;
$t_mx_w = null;

if (! getmxrr($domain, $t_mx, $t_mx_w)) {
print "unable to resolve $domain MX\n\n";
continue;
}

print "$domain MX answer :\n";
var_export($t_mx);
print "\n";
var_export($t_mx_w);
print "\n\n";
}

?>
-------->8--------

ce que ça donne :

$ ./get_mx.php free.fr google.com test
free.fr MX answer :
array (
0 => 'mx1.free.fr',
1 => 'mx2.free.fr',
)
array (
0 => 10,
1 => 20,
)

google.com MX answer :
array (
0 => 'smtp1.google.com',
1 => 'smtp2.google.com',
2 => 'smtp3.google.com',
3 => 'smtp4.google.com',
)
array (
0 => 10,
1 => 10,
2 => 10,
3 => 10,
)

unable to resolve test MX

Post by Pascal PONCET
C'est effectivement le dernier point qui me reste, envoyer les mails par
une socket SMTP, donc directement à chaque domaine.
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 ?

Si tu as moyen, mais seulement si c'est toi qui te charges de
délivrer directement le mail au MX, qui te dira de suite s'il le prend,
s'il ne le prend pas, ou s'il faut revenir plus tard et pourquoi (enfin
là faut pas trop rêver les codes et messages d'erreurs sont parfois
cocasses).

Dans le cas où tu utilise mail(), tu peux uniquement savoir si le mail
a bien été ajouté à la queue du MTA local, mais ça ne dit pas ce qu'il
deviendra plus tard (il n'a pas encore été délivré et tu ne sais pas
quand il le sera). Accessoirement je suppose que ça augmentera aussi le
nombre de bounces générés.

[Patrick Mevzek]

Post by Thibault
Pas sûr d'avoir compris, mais cette « liste » c'est le DNS et c'est
accessible publiquement pour tout le monde (sinon on aurait du mal à
s'échanger du mail ;-). Grosso modo tu fais une requête DNS pour
connaître les MX d'un domaine donné, puis tu les essaye dans l'ordre un
par un.

Sauf que cela ne suffit pas. On peut très bien envoyer un email sur un
domaine n'ayant pas de MX.
C'est le fallback vers les enregistrements A ...

Post by Thibault
if (! getmxrr($domain, $t_mx, $t_mx_w)) {
print "unable to resolve $domain MX\n\n";
continue;
}

Cf première note de la documentation de getmxrr :
« Note: Cette fonction ne doit pas être utilisée à des fin de vérification
d'adresses. »

[Thibault]

Post by Patrick Mevzek

Post by Thibault
Pas sûr d'avoir compris, mais cette « liste » c'est le DNS et c'est
accessible publiquement pour tout le monde (sinon on aurait du mal à
s'échanger du mail ;-). Grosso modo tu fais une requête DNS pour
connaître les MX d'un domaine donné, puis tu les essaye dans l'ordre un
par un.

Sauf que cela ne suffit pas. On peut très bien envoyer un email sur un
domaine n'ayant pas de MX.
C'est le fallback vers les enregistrements A ...

Tout à fait, c'est d'ailleurs pour cela que j'ai précisé que la
procédure évoquée (dans le script cité) était très loin d'être en accord
avec les standards couverts. Il y avait aussi les différents timeout pas
du tout respectés, les codes d'erreurs pas forcément bien traités et
plein d'autres choses.

Bref il vaut mieux lire http://tools.ietf.org/html/rfc5321 et non mes
exemples, mais c'est plus long :-)

Post by Patrick Mevzek

Post by Thibault
if (! getmxrr($domain, $t_mx, $t_mx_w)) {
print "unable to resolve $domain MX\n\n";
continue;
}

« Note: Cette fonction ne doit pas être utilisée à des fin de vérification
d'adresses. »

Ce n'est donc pas en désaccord, car la finalité n'était pas de
vérifier une adresse mail, mais de délivrer un mail :-) Mais on est
d'accord que cela ne fait pas tout comme tu l'as dit (A implicite).

[mpg]

Post by Pascal PONCET

Post by Thibault
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.

[Anthony]

Post by Pascal PONCET
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]

Post by Anthony
ê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.

Bonjour,

Oui, il y a certaines restrictions, bien naturelles du reste
(essentiellement anti-spam).
Mais tant que je suis en-dessous des 2500 mails par envoi, je n'ai pas
de problème (et ce depuis plus de 2 ans).
Sauf quand-même le fait que je ne dispose pas des notifications d'erreur
en retour des serveurs destinataires (pas de suivi d'adresses mortes par
ce canal).

Je reste ouvert à d'autres suggestions.
Un hébergeur plus performant, ou spécialisé, pour l'e-mailing ?

Cordialement,
Pascal

[Julien Arlandis]

Post by Pascal PONCET
Qu'en pensez-vous ?
Cordialement,
Pascal

J'en pense que tu gagnerais à passer par un logiciel de mailing, il en
existe de très bons reliés à ODBC pour l'interfaçage avec la base de
données. Vu que tu es sur du mutualisé et que le port mysql est surement
fermé, tu vas importer ta base de données et il te suffira d'importer ta
base dans un fichier csv juste avant l'envoi.