PB envois HTML avec mail() en php depuis OVH, réception chez free
19 réponses
Atelier Alupi
Hello,
Je suis complètement largué sur la fonction mail() de php.
J'ai besoin d'envoyer un mailing et il n'y a pas moyen de réussir l'envoi en
html. Le script indique que le mail est envoyé, certains destinataires le
reçoivent, mais moi-même je ne le reçois pas (je m'envoie le mail aussi à
moi-même). Mon provider pop est free et le site est hébergé sur 60gp chez
OVH.
if(!mail($dest,$obj,$mes,$headers))
{
echo "<br>Le mail à $rep n'a PAS été envoyé<br>";
}else{
echo "<br>Le mail à $rep a été envoyé<br>"; // C'est le message qui
s'affiche à chaque fois pourtant je ne le reçois pas dans ma BAL free.
}
Toutes les variables sont renseignées. C'est apparemment un problème de
headers car les messages envoyés en texte brut sont reçus.
On Tue, 21 Mar 2006 10:21:21 +0100, Atelier Alupi wrote:
bon on est pas là pour se faire la morale je crois,
Tu crois faux. C'est toi qui est venu discuter ici. Tu essaie de t'insérer à un groupe et tu en suis les us et coutumes. entre autre, on a coutume de lire de haut en bas, et donc de répondre en dessous: http://www.giromini.org/usenet-fr/repondre.html#2
je parle comme je veux, je m'en fous je suis libre
Et bien dans cette même optique, je fais la morale à qui je veux. Ben oui, si chacun fais ce qu'il veut. Maintenant imagine que chacun fasse comme il veut et ne se retienne pas.
On Tue, 21 Mar 2006 10:21:21 +0100, Atelier Alupi wrote:
bon on est pas là pour se faire la morale je crois,
Tu crois faux. C'est toi qui est venu discuter ici. Tu essaie de t'insérer
à un groupe et tu en suis les us et coutumes. entre autre, on a coutume de
lire de haut en bas, et donc de répondre en dessous:
http://www.giromini.org/usenet-fr/repondre.html#2
je parle comme je veux, je m'en fous je suis libre
Et bien dans cette même optique, je fais la morale à qui je veux.
Ben oui, si chacun fais ce qu'il veut.
Maintenant imagine que chacun fasse comme il veut et ne se retienne pas.
On Tue, 21 Mar 2006 10:21:21 +0100, Atelier Alupi wrote:
bon on est pas là pour se faire la morale je crois,
Tu crois faux. C'est toi qui est venu discuter ici. Tu essaie de t'insérer à un groupe et tu en suis les us et coutumes. entre autre, on a coutume de lire de haut en bas, et donc de répondre en dessous: http://www.giromini.org/usenet-fr/repondre.html#2
je parle comme je veux, je m'en fous je suis libre
Et bien dans cette même optique, je fais la morale à qui je veux. Ben oui, si chacun fais ce qu'il veut. Maintenant imagine que chacun fasse comme il veut et ne se retienne pas.
"Atelier Alupi" a écrit dans le message de news: 441f31b1$0$27069$
putain mec ça marche j'y crois pas, merci du fond du coeur pourquoi y a tant de conneries marquées sur le net ?
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou avec un provider (wanadoo en autre) autrement je ne recevais pas les mails, puis d'un coup cela ne fonctionnais pas après avoir jeter un oeil sur les entête reçu je me suis aperçu de la "connerie". donc si tu avais éditer un des mails tu t'en aurais sûrement vu le problème.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les logs :)
-jl-
-- Amicalement;)
"Atelier Alupi" <bonjour@atelieralupi.com> a écrit dans le message de news:
441f31b1$0$27069$626a54ce@news.free.fr...
putain mec ça marche j'y crois pas, merci du fond du coeur
pourquoi y a tant de conneries marquées sur le net ?
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les
entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou
avec un provider (wanadoo en autre) autrement je ne recevais pas les mails,
puis d'un coup cela ne fonctionnais pas après avoir jeter un oeil sur les
entête reçu je me suis aperçu de la "connerie". donc si tu avais éditer un
des mails tu t'en aurais sûrement vu le problème.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les
logs :)
"Atelier Alupi" a écrit dans le message de news: 441f31b1$0$27069$
putain mec ça marche j'y crois pas, merci du fond du coeur pourquoi y a tant de conneries marquées sur le net ?
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou avec un provider (wanadoo en autre) autrement je ne recevais pas les mails, puis d'un coup cela ne fonctionnais pas après avoir jeter un oeil sur les entête reçu je me suis aperçu de la "connerie". donc si tu avais éditer un des mails tu t'en aurais sûrement vu le problème.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les logs :)
-jl-
-- Amicalement;)
Mickaël Wolff
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou avec un provider (wanadoo en autre) autrement je ne recevais pas les mails,
Dans la RFC sur les courriels, c'est spécifié que toutes les lignes doivent s'achever par un retour chariot puis un retour à la ligne.
Sous Linux, PHP passe par un exe local qui sait que ce que tu lui fournit est un fichier texte, et que par conséquent les fin de ligne doivent être traduite dans le dialecte SMTP.
Sous Windows, PHP contact directement un serveur SMTP, et lui fournit les informations sans traduire les fins de ligne en retour chariot et fin de ligne.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les
logs :)
Quand on a la main dessus ;)
Au fait, je croyais être sur frih et non fclphp, on m'aurait mentit ? -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org ** Spécialiste Logiciels Libres **
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les
entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou
avec un provider (wanadoo en autre) autrement je ne recevais pas les
mails,
Dans la RFC sur les courriels, c'est spécifié que toutes les lignes
doivent s'achever par un retour chariot puis un retour à la ligne.
Sous Linux, PHP passe par un exe local qui sait que ce que tu lui
fournit est un fichier texte, et que par conséquent les fin de ligne
doivent être traduite dans le dialecte SMTP.
Sous Windows, PHP contact directement un serveur SMTP, et lui fournit
les informations sans traduire les fins de ligne en retour chariot et
fin de ligne.
PS. ne jamais faire confiance à un script si cela ne marche pas
regarde les
logs :)
Quand on a la main dessus ;)
Au fait, je croyais être sur frih et non fclphp, on m'aurait mentit ?
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
** Spécialiste Logiciels Libres **
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou avec un provider (wanadoo en autre) autrement je ne recevais pas les mails,
Dans la RFC sur les courriels, c'est spécifié que toutes les lignes doivent s'achever par un retour chariot puis un retour à la ligne.
Sous Linux, PHP passe par un exe local qui sait que ce que tu lui fournit est un fichier texte, et que par conséquent les fin de ligne doivent être traduite dans le dialecte SMTP.
Sous Windows, PHP contact directement un serveur SMTP, et lui fournit les informations sans traduire les fins de ligne en retour chariot et fin de ligne.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les
logs :)
Quand on a la main dessus ;)
Au fait, je croyais être sur frih et non fclphp, on m'aurait mentit ? -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org ** Spécialiste Logiciels Libres **
-jl-
"Mickaël Wolff" a écrit dans le message de news: 4420703b$0$4634$
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou avec un provider (wanadoo en autre) autrement je ne recevais pas les mails,
Dans la RFC sur les courriels, c'est spécifié que toutes les lignes doivent s'achever par un retour chariot puis un retour à la ligne.
Sous Linux, PHP passe par un exe local qui sait que ce que tu lui fournit est un fichier texte, et que par conséquent les fin de ligne doivent être traduite dans le dialecte SMTP.
Sous Windows, PHP contact directement un serveur SMTP, et lui fournit les informations sans traduire les fins de ligne en retour chariot et fin de ligne.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les
logs :)
Quand on a la main dessus ;)
Au fait, je croyais être sur frih et non fclphp, on m'aurait mentit ? -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org ** Spécialiste Logiciels Libres **
ba vi le RFC peut spécifier ce que l'on veut il n'y a rien de tel que l'expérience n'est ce pas mickael ;)
heu vi pour les log je voulais dire juste il suffit de regarder le mail que l'on reçois et d'afficher les propriétés
he pis d'abord tu devrais dormir à cette heure autrement tu vas être en retard demain matin :)))
-- Amicalement;) -jl-
"Mickaël Wolff" <mickael.wolff@laposte.net> a écrit dans le message de news:
4420703b$0$4634$636a55ce@news.free.fr...
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les
entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou
avec un provider (wanadoo en autre) autrement je ne recevais pas les
mails,
Dans la RFC sur les courriels, c'est spécifié que toutes les lignes
doivent s'achever par un retour chariot puis un retour à la ligne.
Sous Linux, PHP passe par un exe local qui sait que ce que tu lui
fournit est un fichier texte, et que par conséquent les fin de ligne
doivent être traduite dans le dialecte SMTP.
Sous Windows, PHP contact directement un serveur SMTP, et lui fournit
les informations sans traduire les fins de ligne en retour chariot et
fin de ligne.
PS. ne jamais faire confiance à un script si cela ne marche pas
regarde les
logs :)
Quand on a la main dessus ;)
Au fait, je croyais être sur frih et non fclphp, on m'aurait mentit ?
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
** Spécialiste Logiciels Libres **
ba vi le RFC peut spécifier ce que l'on veut il n'y a rien de tel que
l'expérience n'est ce pas mickael ;)
heu vi pour les log je voulais dire juste il suffit de regarder le mail que
l'on reçois et d'afficher les propriétés
he pis d'abord tu devrais dormir à cette heure autrement tu vas être en
retard demain matin :)))
"Mickaël Wolff" a écrit dans le message de news: 4420703b$0$4634$
Ce n'est pas des conneries mais passé un temps j'ai remarqué que dans les entêtes de mail il fallait mettre rn, sûrement un truc avec outlook ou avec un provider (wanadoo en autre) autrement je ne recevais pas les mails,
Dans la RFC sur les courriels, c'est spécifié que toutes les lignes doivent s'achever par un retour chariot puis un retour à la ligne.
Sous Linux, PHP passe par un exe local qui sait que ce que tu lui fournit est un fichier texte, et que par conséquent les fin de ligne doivent être traduite dans le dialecte SMTP.
Sous Windows, PHP contact directement un serveur SMTP, et lui fournit les informations sans traduire les fins de ligne en retour chariot et fin de ligne.
PS. ne jamais faire confiance à un script si cela ne marche pas regarde les
logs :)
Quand on a la main dessus ;)
Au fait, je croyais être sur frih et non fclphp, on m'aurait mentit ? -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org ** Spécialiste Logiciels Libres **
ba vi le RFC peut spécifier ce que l'on veut il n'y a rien de tel que l'expérience n'est ce pas mickael ;)
heu vi pour les log je voulais dire juste il suffit de regarder le mail que l'on reçois et d'afficher les propriétés
he pis d'abord tu devrais dormir à cette heure autrement tu vas être en retard demain matin :)))
-- Amicalement;) -jl-
Peter Pan
ok bravo les gars, vous avez tous raison, vive ovh
La question n'est certainement pas de savoir si OVH (ou tartempion.fr) est bien ou pas, mais : - de choisir tes fournisseurs en connaissance de cause - de comprendre les problèmes de façon globale - d'appréhender la notion de "mutualiser" un hébergement
-- Pierre http://www.1966.fr/
ok bravo les gars, vous avez tous raison, vive ovh
La question n'est certainement pas de savoir si OVH (ou tartempion.fr)
est bien ou pas, mais :
- de choisir tes fournisseurs en connaissance de cause
- de comprendre les problèmes de façon globale
- d'appréhender la notion de "mutualiser" un hébergement
ok bravo les gars, vous avez tous raison, vive ovh
La question n'est certainement pas de savoir si OVH (ou tartempion.fr) est bien ou pas, mais : - de choisir tes fournisseurs en connaissance de cause - de comprendre les problèmes de façon globale - d'appréhender la notion de "mutualiser" un hébergement
-- Pierre http://www.1966.fr/
LJVD
Atelier Alupi wrote:
ok bravo les gars, vous avez tous raison, vive ovh
Je trouve cela plutot courageux de la part d'un hébergeur, de mettre des contraintes techniques qui imposent aux webmasters de respecter les normes. C'est une forme de participation proactive à la lutte contre le spam. Je serais assez curieux de connaitre l'impact de ce choix sur la charge de travail du support d'ovh.
Qu'une partie de leurs clients n'apprécient pas est tout a fait compréhensible. D'autant que la gestion de base d'emails n'a rien de trivial.
J'y vois une conséquence à cours terme : - les clients sans compétence technique vont aller emmerder les hotline s d'autres hébergeurs.
Mauvais choix stratégique ? pas certain .. -- Laurent J.V. Dubois http://www.ljvd.com
Atelier Alupi wrote:
ok bravo les gars, vous avez tous raison, vive ovh
Je trouve cela plutot courageux de la part d'un hébergeur,
de mettre des contraintes techniques qui imposent aux webmasters de
respecter les normes. C'est une forme de participation proactive à la
lutte contre le spam.
Je serais assez curieux de connaitre l'impact de ce choix sur la charge
de travail du support d'ovh.
Qu'une partie de leurs clients n'apprécient pas est tout a fait
compréhensible. D'autant que la gestion de base d'emails n'a rien de
trivial.
J'y vois une conséquence à cours terme :
- les clients sans compétence technique vont aller emmerder les hotline s
d'autres hébergeurs.
Mauvais choix stratégique ? pas certain ..
--
Laurent J.V. Dubois
http://www.ljvd.com
ok bravo les gars, vous avez tous raison, vive ovh
Je trouve cela plutot courageux de la part d'un hébergeur, de mettre des contraintes techniques qui imposent aux webmasters de respecter les normes. C'est une forme de participation proactive à la lutte contre le spam. Je serais assez curieux de connaitre l'impact de ce choix sur la charge de travail du support d'ovh.
Qu'une partie de leurs clients n'apprécient pas est tout a fait compréhensible. D'autant que la gestion de base d'emails n'a rien de trivial.
J'y vois une conséquence à cours terme : - les clients sans compétence technique vont aller emmerder les hotline s d'autres hébergeurs.
Mauvais choix stratégique ? pas certain .. -- Laurent J.V. Dubois http://www.ljvd.com
oles
Atelier Alupi a écrit:
Fais gaffe car avec la nouvelle politique d'OVH avec les mails, tu peux te faire enc$£* si tu génères trop d'erreurs.
D'accord, je viens de voir ça... Si plus de 5% des mails reviennent en erreur : blocage des envois. Coool... On est pas dans la merde... Putain, mais c'est un hébergeur de clochards ! Je ne vois pas comment je pourrais supprimer toutes les adresses périmées de ma base !
lorsque tu generes les erreurs, nous on les recoit, on les comptes, on t'envoit un email de recap avec les emails qui ne fonctionnent pas. les clients adorent, les spammeurs ou les phising detestent car le systeme d'autobloque automatiquement. bref, depuis le mois de decembre nos mail-out ne sont plus blacklistés, la distribution des emails à partir des php/cgi vers l'internet est ultra rapide et fonctionne sans interuption (parcequ'on n'a plus à nettoyer les fils d'attente, vu qu'on bloque avant).
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils d'attente sur les emails entrant sur les comptes emails hébergés chez ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours. parceque qmail/postfix avec sa queue c'est bien mais si on veut faire des choses un peu plus complexes et à haute vitesse, ça bouffe plein des resources pour rien. autant tout reecrire et utiliser juste des bloques des .h/.c qui font des taches très precisses puis mettre du ciments à soi.
octave
-- Simplifiez la gestion de votre hebergement et telechargez MoM: http://www.ovh.com/fr/download pour Windows, Mac ou Linux. C'est gratuit !
Atelier Alupi <bonjour@atelieralupi.com> a écrit:
Fais gaffe car avec la nouvelle politique d'OVH avec les mails,
tu peux te faire enc$£* si tu génères trop d'erreurs.
D'accord, je viens de voir ça... Si plus de 5% des mails reviennent en
erreur : blocage des envois. Coool... On est pas dans la merde... Putain,
mais c'est un hébergeur de clochards ! Je ne vois pas comment je pourrais
supprimer toutes les adresses périmées de ma base !
lorsque tu generes les erreurs, nous on les recoit, on les comptes,
on t'envoit un email de recap avec les emails qui ne fonctionnent pas.
les clients adorent, les spammeurs ou les phising detestent car le
systeme d'autobloque automatiquement. bref, depuis le mois de decembre
nos mail-out ne sont plus blacklistés, la distribution des emails à
partir des php/cgi vers l'internet est ultra rapide et fonctionne
sans interuption (parcequ'on n'a plus à nettoyer les fils d'attente,
vu qu'on bloque avant).
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils
d'attente sur les emails entrant sur les comptes emails hébergés chez
ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours.
parceque qmail/postfix avec sa queue c'est bien mais si on veut faire
des choses un peu plus complexes et à haute vitesse, ça bouffe plein
des resources pour rien. autant tout reecrire et utiliser juste des
bloques des .h/.c qui font des taches très precisses puis mettre du
ciments à soi.
octave
--
Simplifiez la gestion de votre hebergement et
telechargez MoM: http://www.ovh.com/fr/download
pour Windows, Mac ou Linux. C'est gratuit !
Fais gaffe car avec la nouvelle politique d'OVH avec les mails, tu peux te faire enc$£* si tu génères trop d'erreurs.
D'accord, je viens de voir ça... Si plus de 5% des mails reviennent en erreur : blocage des envois. Coool... On est pas dans la merde... Putain, mais c'est un hébergeur de clochards ! Je ne vois pas comment je pourrais supprimer toutes les adresses périmées de ma base !
lorsque tu generes les erreurs, nous on les recoit, on les comptes, on t'envoit un email de recap avec les emails qui ne fonctionnent pas. les clients adorent, les spammeurs ou les phising detestent car le systeme d'autobloque automatiquement. bref, depuis le mois de decembre nos mail-out ne sont plus blacklistés, la distribution des emails à partir des php/cgi vers l'internet est ultra rapide et fonctionne sans interuption (parcequ'on n'a plus à nettoyer les fils d'attente, vu qu'on bloque avant).
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils d'attente sur les emails entrant sur les comptes emails hébergés chez ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours. parceque qmail/postfix avec sa queue c'est bien mais si on veut faire des choses un peu plus complexes et à haute vitesse, ça bouffe plein des resources pour rien. autant tout reecrire et utiliser juste des bloques des .h/.c qui font des taches très precisses puis mettre du ciments à soi.
octave
-- Simplifiez la gestion de votre hebergement et telechargez MoM: http://www.ovh.com/fr/download pour Windows, Mac ou Linux. C'est gratuit !
Nico
a écrit dans le message de news: 44231575$0$20304$
Atelier Alupi a écrit:
Fais gaffe car avec la nouvelle politique d'OVH avec les mails, tu peux te faire enc$£* si tu génères trop d'erreurs.
D'accord, je viens de voir ça... Si plus de 5% des mails reviennent en erreur : blocage des envois. Coool... On est pas dans la merde... Putain, mais c'est un hébergeur de clochards ! Je ne vois pas comment je pourrais supprimer toutes les adresses périmées de ma base !
lorsque tu generes les erreurs, nous on les recoit, on les comptes, on t'envoit un email de recap avec les emails qui ne fonctionnent pas. les clients adorent, les spammeurs ou les phising detestent car le systeme d'autobloque automatiquement. bref, depuis le mois de decembre nos mail-out ne sont plus blacklistés, la distribution des emails à partir des php/cgi vers l'internet est ultra rapide et fonctionne sans interuption (parcequ'on n'a plus à nettoyer les fils d'attente, vu qu'on bloque avant).
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils d'attente sur les emails entrant sur les comptes emails hébergés chez ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours. parceque qmail/postfix avec sa queue c'est bien mais si on veut faire des choses un peu plus complexes et à haute vitesse, ça bouffe plein des resources pour rien. autant tout reecrire et utiliser juste des bloques des .h/.c qui font des taches très precisses puis mettre du ciments à soi.
octave
Ok, maintenant moi je suis client et ignard, donc peut-être que ça vous arrange vous, mais moi, avec une base où il y a beaucoup d'emails erronés parce qu'ils datent de 2002 et que je n'envoie pas un mailing tous les jours, qu'est-ce que je dois faire pour éviter d'avoir mes emails bloqués ????
Est-ce que si je les envoie par paquet de 50 toutes les heures ça passe ? Est-ce que si je fais un script qui en envoie un par minute ça passe ??
Donnez-moi une solution, parce qu'avec votre système actuel, j'ai envoyé 200 mails. On me les a bloqués. On m'a dit que rien n'était supprimé et que ça allait se débloquer, mais ça fait déjà 4 jours et AUCUNE NOUVELLE, et je dois envoyer mon mailing ! Et c'est toujours bloqué parce que quand je m'envoie un email à moi-même je ne le reçois pas.
Alors pour les 200 suivantes, ça va être le même cirque ? Et de plus comment savoir exactement lesquelles vous avez essayé et lesquelles vous n'avez pas essayé d'envoyer ? Comment savoir qui a reçu le mail ? Enfin bref je suis en grosse galère à cause de cette histoire.
Merci de me répondre et surtout de me dire COMMENT faire pour éviter de bloquer mes envois sachant que j'ai BEAUCOUP d'adresses obsolètes dans la base et que je n'ai AUCUN moyen de savoir si telle ou telle adresse est obsolète autre que d'y envoyer un mail ! Le pire, c'est que vous avez supprimé la possibilité de spécifier une adresse de Return-Path et que je n'ai donc aucun autre moyen de connaitre les adresses erronées que d'attendre que vous bloquiez mes mails et que vous m'envoyiez un bilan.
Mettez-vous à ma place et donnez-moi une solution s'il vous plait.
Nicolas
PS : Ceci-dit le bilan est très bien fait et j'espère réussir à l'utiliser pour le lire avec un script et supprimer automatiquement les adresses erronées dans ma base. On m'a dit que vous alliez créer "une nouvelle interface pour ça" (Absence de Return-Path), et bien pourquoi ne feriez-vous pas un programme qui nous permette de supprimer automatiquement les mails erronés dans nos bases ? Là je retrouverais le sourire : )
<oles@ovh.net> a écrit dans le message de news:
44231575$0$20304$626a54ce@news.free.fr...
Atelier Alupi <bonjour@atelieralupi.com> a écrit:
Fais gaffe car avec la nouvelle politique d'OVH avec les mails,
tu peux te faire enc$£* si tu génères trop d'erreurs.
D'accord, je viens de voir ça... Si plus de 5% des mails reviennent en
erreur : blocage des envois. Coool... On est pas dans la merde... Putain,
mais c'est un hébergeur de clochards ! Je ne vois pas comment je pourrais
supprimer toutes les adresses périmées de ma base !
lorsque tu generes les erreurs, nous on les recoit, on les comptes,
on t'envoit un email de recap avec les emails qui ne fonctionnent pas.
les clients adorent, les spammeurs ou les phising detestent car le
systeme d'autobloque automatiquement. bref, depuis le mois de decembre
nos mail-out ne sont plus blacklistés, la distribution des emails à
partir des php/cgi vers l'internet est ultra rapide et fonctionne
sans interuption (parcequ'on n'a plus à nettoyer les fils d'attente,
vu qu'on bloque avant).
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils
d'attente sur les emails entrant sur les comptes emails hébergés chez
ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours.
parceque qmail/postfix avec sa queue c'est bien mais si on veut faire
des choses un peu plus complexes et à haute vitesse, ça bouffe plein
des resources pour rien. autant tout reecrire et utiliser juste des
bloques des .h/.c qui font des taches très precisses puis mettre du
ciments à soi.
octave
Ok, maintenant moi je suis client et ignard, donc peut-être que ça vous
arrange vous, mais moi, avec une base où il y a beaucoup d'emails erronés
parce qu'ils datent de 2002 et que je n'envoie pas un mailing tous les
jours, qu'est-ce que je dois faire pour éviter d'avoir mes emails bloqués
????
Est-ce que si je les envoie par paquet de 50 toutes les heures ça passe ?
Est-ce que si je fais un script qui en envoie un par minute ça passe ??
Donnez-moi une solution, parce qu'avec votre système actuel, j'ai envoyé 200
mails. On me les a bloqués. On m'a dit que rien n'était supprimé et que ça
allait se débloquer, mais ça fait déjà 4 jours et AUCUNE NOUVELLE, et je
dois envoyer mon mailing ! Et c'est toujours bloqué parce que quand je
m'envoie un email à moi-même je ne le reçois pas.
Alors pour les 200 suivantes, ça va être le même cirque ? Et de plus comment
savoir exactement lesquelles vous avez essayé et lesquelles vous n'avez pas
essayé d'envoyer ? Comment savoir qui a reçu le mail ? Enfin bref je suis en
grosse galère à cause de cette histoire.
Merci de me répondre et surtout de me dire COMMENT faire pour éviter de
bloquer mes envois sachant que j'ai BEAUCOUP d'adresses obsolètes dans la
base et que je n'ai AUCUN moyen de savoir si telle ou telle adresse est
obsolète autre que d'y envoyer un mail !
Le pire, c'est que vous avez supprimé la possibilité de spécifier une
adresse de Return-Path et que je n'ai donc aucun autre moyen de connaitre
les adresses erronées que d'attendre que vous bloquiez mes mails et que vous
m'envoyiez un bilan.
Mettez-vous à ma place et donnez-moi une solution s'il vous plait.
Nicolas
PS : Ceci-dit le bilan est très bien fait et j'espère réussir à l'utiliser
pour le lire avec un script et supprimer automatiquement les adresses
erronées dans ma base. On m'a dit que vous alliez créer "une nouvelle
interface pour ça" (Absence de Return-Path), et bien pourquoi ne feriez-vous
pas un programme qui nous permette de supprimer automatiquement les mails
erronés dans nos bases ? Là je retrouverais le sourire : )
a écrit dans le message de news: 44231575$0$20304$
Atelier Alupi a écrit:
Fais gaffe car avec la nouvelle politique d'OVH avec les mails, tu peux te faire enc$£* si tu génères trop d'erreurs.
D'accord, je viens de voir ça... Si plus de 5% des mails reviennent en erreur : blocage des envois. Coool... On est pas dans la merde... Putain, mais c'est un hébergeur de clochards ! Je ne vois pas comment je pourrais supprimer toutes les adresses périmées de ma base !
lorsque tu generes les erreurs, nous on les recoit, on les comptes, on t'envoit un email de recap avec les emails qui ne fonctionnent pas. les clients adorent, les spammeurs ou les phising detestent car le systeme d'autobloque automatiquement. bref, depuis le mois de decembre nos mail-out ne sont plus blacklistés, la distribution des emails à partir des php/cgi vers l'internet est ultra rapide et fonctionne sans interuption (parcequ'on n'a plus à nettoyer les fils d'attente, vu qu'on bloque avant).
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils d'attente sur les emails entrant sur les comptes emails hébergés chez ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours. parceque qmail/postfix avec sa queue c'est bien mais si on veut faire des choses un peu plus complexes et à haute vitesse, ça bouffe plein des resources pour rien. autant tout reecrire et utiliser juste des bloques des .h/.c qui font des taches très precisses puis mettre du ciments à soi.
octave
Ok, maintenant moi je suis client et ignard, donc peut-être que ça vous arrange vous, mais moi, avec une base où il y a beaucoup d'emails erronés parce qu'ils datent de 2002 et que je n'envoie pas un mailing tous les jours, qu'est-ce que je dois faire pour éviter d'avoir mes emails bloqués ????
Est-ce que si je les envoie par paquet de 50 toutes les heures ça passe ? Est-ce que si je fais un script qui en envoie un par minute ça passe ??
Donnez-moi une solution, parce qu'avec votre système actuel, j'ai envoyé 200 mails. On me les a bloqués. On m'a dit que rien n'était supprimé et que ça allait se débloquer, mais ça fait déjà 4 jours et AUCUNE NOUVELLE, et je dois envoyer mon mailing ! Et c'est toujours bloqué parce que quand je m'envoie un email à moi-même je ne le reçois pas.
Alors pour les 200 suivantes, ça va être le même cirque ? Et de plus comment savoir exactement lesquelles vous avez essayé et lesquelles vous n'avez pas essayé d'envoyer ? Comment savoir qui a reçu le mail ? Enfin bref je suis en grosse galère à cause de cette histoire.
Merci de me répondre et surtout de me dire COMMENT faire pour éviter de bloquer mes envois sachant que j'ai BEAUCOUP d'adresses obsolètes dans la base et que je n'ai AUCUN moyen de savoir si telle ou telle adresse est obsolète autre que d'y envoyer un mail ! Le pire, c'est que vous avez supprimé la possibilité de spécifier une adresse de Return-Path et que je n'ai donc aucun autre moyen de connaitre les adresses erronées que d'attendre que vous bloquiez mes mails et que vous m'envoyiez un bilan.
Mettez-vous à ma place et donnez-moi une solution s'il vous plait.
Nicolas
PS : Ceci-dit le bilan est très bien fait et j'espère réussir à l'utiliser pour le lire avec un script et supprimer automatiquement les adresses erronées dans ma base. On m'a dit que vous alliez créer "une nouvelle interface pour ça" (Absence de Return-Path), et bien pourquoi ne feriez-vous pas un programme qui nous permette de supprimer automatiquement les mails erronés dans nos bases ? Là je retrouverais le sourire : )
filh
wrote:
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils d'attente sur les emails entrant sur les comptes emails hébergés chez ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours. parceque qmail/postfix avec sa queue c'est bien mais si on veut faire des choses un peu plus complexes et à haute vitesse, ça bouffe plein des resources pour rien. autant tout reecrire et utiliser juste des bloques des .h/.c qui font des taches très precisses puis mettre du ciments à soi.
Sendmail X ?
FiLH -- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
<oles@ovh.net> wrote:
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils
d'attente sur les emails entrant sur les comptes emails hébergés chez
ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours.
parceque qmail/postfix avec sa queue c'est bien mais si on veut faire
des choses un peu plus complexes et à haute vitesse, ça bouffe plein
des resources pour rien. autant tout reecrire et utiliser juste des
bloques des .h/.c qui font des taches très precisses puis mettre du
ciments à soi.
Sendmail X ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
ça marche tellement bien qu'on va s'inspirer pour reecrire les fils d'attente sur les emails entrant sur les comptes emails hébergés chez ovh. on va eviter 99.99% des problemes qu'on recontre tous les jours. parceque qmail/postfix avec sa queue c'est bien mais si on veut faire des choses un peu plus complexes et à haute vitesse, ça bouffe plein des resources pour rien. autant tout reecrire et utiliser juste des bloques des .h/.c qui font des taches très precisses puis mettre du ciments à soi.
Sendmail X ?
FiLH -- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
