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.
ê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
Anthony a écrit :
ê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 ?
ê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
Thibault
On 12 Feb 2009 11:16:29 GMT, Pascal PONCET wrote:
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)
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.
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.
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.
On 12 Feb 2009 11:16:29 GMT, Pascal PONCET wrote:
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)
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.
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.
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.
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)
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.
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.
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
Le Thu, 12 Feb 2009 13:58:04 +0000, Thibault a écrit:
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 ...
if (! getmxrr($domain, $t_mx, $t_mx_w)) { print "unable to resolve $domain MXnn"; 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. »
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Le Thu, 12 Feb 2009 13:58:04 +0000, Thibault a écrit:
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 ...
if (! getmxrr($domain, $t_mx, $t_mx_w)) {
print "unable to resolve $domain MXnn";
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. »
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
Le Thu, 12 Feb 2009 13:58:04 +0000, Thibault a écrit:
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 ...
if (! getmxrr($domain, $t_mx, $t_mx_w)) { print "unable to resolve $domain MXnn"; 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. »
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Thibault
On 12 Feb 2009 18:41:11 GMT, Patrick Mevzek wrote:
Le Thu, 12 Feb 2009 13:58:04 +0000, Thibault a écrit:
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 :-)
if (! getmxrr($domain, $t_mx, $t_mx_w)) { print "unable to resolve $domain MXnn"; 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. »
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).
On 12 Feb 2009 18:41:11 GMT, Patrick Mevzek wrote:
Le Thu, 12 Feb 2009 13:58:04 +0000, Thibault a écrit:
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 :-)
if (! getmxrr($domain, $t_mx, $t_mx_w)) {
print "unable to resolve $domain MXnn";
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. »
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).
On 12 Feb 2009 18:41:11 GMT, Patrick Mevzek wrote:
Le Thu, 12 Feb 2009 13:58:04 +0000, Thibault a écrit:
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 :-)
if (! getmxrr($domain, $t_mx, $t_mx_w)) { print "unable to resolve $domain MXnn"; 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. »
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).
Julien Arlandis
Pascal PONCET a écrit :
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.
Pascal PONCET a écrit :
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.
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.
