Y a-t-il un moyen de tester les adresses emails d'une base de données MySql
avec php et de supprimer les mails qui reviennent "Undelivered" ? Si
quelqu'un opère ce tour de magie, chapeau !
"Mickael Wolff" a écrit dans le message de news: 442077ab$0$29027$
Je crois que je vais plutôt chercher un hébergeur qui accepte qu'on maile des tonnes d'adresses invalides ! Vous ne trouverez pas un tel pigeon ;) Il vaut mieux demander à
quelqu'un de vous développer un tel script pour nettoyer votre base. ............
Toutes les variables sont à tester.
Si votre formulaire ne fait aucun tests, il est certain que c'est un spammeur potentiel... ou en puissance. Votre hébergeur risque de vous suspendre d'un moment à un autre.
Bon ben j'ai tenté l'envoi et je me suis fait bloquer direct au bout de 200 mails, vous les avez pas mis au courant de mon projet par hasard ? : P
L'avantage, c'est qu'il m'ont envoyé un message où ils listaient toutes les adresses erronnées, reste plus qu'à faire un script php qui me les récupère dans une variable et à les supprimer de la base. Evidemment, c'est de mails qui datent de 2002.
Le problème, c'est que moi j'ai pas l'habitude de harceler de pubs les gens qui ont rempli mon formulaire, donc c'est très rare que je fasse un tel envoi. Par conséquent, il y a pas mal d'adresses qui ne sont plus valables quand ça arrive. Mais comment faire, car certaines sont valable et je ne veux pas les louper. Donc je n'ai pas d'autre choix que de tout envoyer et de me faire bloquer par l'hébergeur je pense ! Jusqu'à ce que j'ai ainsi purgé toute ma base... Autrement, comment savoir si l'adresse est périmée ou non ? Impossible !
"Mickael Wolff" <mickael.wolff@laposte.net> a écrit dans le message de news:
442077ab$0$29027$636a55ce@news.free.fr...
Je crois que je vais plutôt chercher un hébergeur qui accepte qu'on maile
des tonnes d'adresses invalides !
Vous ne trouverez pas un tel pigeon ;) Il vaut mieux demander à
quelqu'un de vous développer un tel script pour nettoyer votre base.
............
Toutes les variables sont à tester.
Si votre formulaire ne fait aucun tests, il est certain que c'est un
spammeur potentiel... ou en puissance. Votre hébergeur risque de vous
suspendre d'un moment à un autre.
Bon ben j'ai tenté l'envoi et je me suis fait bloquer direct au bout de 200
mails, vous les avez pas mis au courant de mon projet par hasard ? : P
L'avantage, c'est qu'il m'ont envoyé un message où ils listaient toutes les
adresses erronnées, reste plus qu'à faire un script php qui me les récupère
dans une variable et à les supprimer de la base.
Evidemment, c'est de mails qui datent de 2002.
Le problème, c'est que moi j'ai pas l'habitude de harceler de pubs les gens
qui ont rempli mon formulaire, donc c'est très rare que je fasse un tel
envoi.
Par conséquent, il y a pas mal d'adresses qui ne sont plus valables quand ça
arrive. Mais comment faire, car certaines sont valable et je ne veux pas les
louper. Donc je n'ai pas d'autre choix que de tout envoyer et de me faire
bloquer par l'hébergeur je pense ! Jusqu'à ce que j'ai ainsi purgé toute ma
base... Autrement, comment savoir si l'adresse est périmée ou non ?
Impossible !
"Mickael Wolff" a écrit dans le message de news: 442077ab$0$29027$
Je crois que je vais plutôt chercher un hébergeur qui accepte qu'on maile des tonnes d'adresses invalides ! Vous ne trouverez pas un tel pigeon ;) Il vaut mieux demander à
quelqu'un de vous développer un tel script pour nettoyer votre base. ............
Toutes les variables sont à tester.
Si votre formulaire ne fait aucun tests, il est certain que c'est un spammeur potentiel... ou en puissance. Votre hébergeur risque de vous suspendre d'un moment à un autre.
Bon ben j'ai tenté l'envoi et je me suis fait bloquer direct au bout de 200 mails, vous les avez pas mis au courant de mon projet par hasard ? : P
L'avantage, c'est qu'il m'ont envoyé un message où ils listaient toutes les adresses erronnées, reste plus qu'à faire un script php qui me les récupère dans une variable et à les supprimer de la base. Evidemment, c'est de mails qui datent de 2002.
Le problème, c'est que moi j'ai pas l'habitude de harceler de pubs les gens qui ont rempli mon formulaire, donc c'est très rare que je fasse un tel envoi. Par conséquent, il y a pas mal d'adresses qui ne sont plus valables quand ça arrive. Mais comment faire, car certaines sont valable et je ne veux pas les louper. Donc je n'ai pas d'autre choix que de tout envoyer et de me faire bloquer par l'hébergeur je pense ! Jusqu'à ce que j'ai ainsi purgé toute ma base... Autrement, comment savoir si l'adresse est périmée ou non ? Impossible !
Patrick Mevzek
Pourquoi ne pas exploiter le travail réalisé par Olivier Miakinen récemment ?
Parce qu'il n'est pas encore officiellement publié ?
Tout est déjà chez Google.
Quand elle aura été approuvée, la nouvelle version devrait ressembler à ceci : <http://www.miakinen.net/tmp/faqfclp2#rub5.3>.
Dommage, je suis moyennement d'accord avec : Oubliez donc toute tentative de vérification basée sur l'interrogation d'enregistrements DNS de type MX, tentative qui sera aussi coûteuse qu'inefficace.
Pour moi il y a un double problème : - d'abord ca laisse croire que MX suffit : c'est faux, il faut MX *ou* A (cette ancienne compatibilité est toujours dans le protocole) - d'autre part, *après* la vérification syntaxique avec une regex, le test DNS me paraît tout à fait justifié. Question inefficacité, le MTA fera de toute façon la même chose avant l'envoi, donc autant le faire avant lui.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pourquoi ne pas exploiter le travail réalisé par Olivier Miakinen
récemment ?
Parce qu'il n'est pas encore officiellement publié ?
Tout est déjà chez Google.
Quand
elle aura été approuvée, la nouvelle version devrait ressembler à ceci :
<http://www.miakinen.net/tmp/faqfclp2#rub5.3>.
Dommage, je suis moyennement d'accord avec :
Oubliez donc toute tentative de vérification basée sur l'interrogation d'enregistrements DNS de type MX, tentative qui sera aussi coûteuse qu'inefficace.
Pour moi il y a un double problème :
- d'abord ca laisse croire que MX suffit : c'est faux, il faut MX *ou* A
(cette ancienne compatibilité est toujours dans le protocole)
- d'autre part, *après* la vérification syntaxique avec une regex, le
test DNS me paraît tout à fait justifié.
Question inefficacité, le MTA fera de toute façon la même chose avant
l'envoi, donc autant le faire avant lui.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pourquoi ne pas exploiter le travail réalisé par Olivier Miakinen récemment ?
Parce qu'il n'est pas encore officiellement publié ?
Tout est déjà chez Google.
Quand elle aura été approuvée, la nouvelle version devrait ressembler à ceci : <http://www.miakinen.net/tmp/faqfclp2#rub5.3>.
Dommage, je suis moyennement d'accord avec : Oubliez donc toute tentative de vérification basée sur l'interrogation d'enregistrements DNS de type MX, tentative qui sera aussi coûteuse qu'inefficace.
Pour moi il y a un double problème : - d'abord ca laisse croire que MX suffit : c'est faux, il faut MX *ou* A (cette ancienne compatibilité est toujours dans le protocole) - d'autre part, *après* la vérification syntaxique avec une regex, le test DNS me paraît tout à fait justifié. Question inefficacité, le MTA fera de toute façon la même chose avant l'envoi, donc autant le faire avant lui.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Olivier Miakinen
Bon ben j'ai tenté l'envoi et je me suis fait bloquer direct au bout de 200 mails, [...]
Evidemment, c'est de mails qui datent de 2002.
Je ne comprends pas. Pourquoi diable as-tu besoin de tester (hors de tout envoi d'information) des adresses que tu avais déjà en 2002 ?
Le problème, c'est que moi j'ai pas l'habitude de harceler de pubs les gens qui ont rempli mon formulaire,
Nous n'en doutons pas.
donc c'est très rare que je fasse un tel envoi.
Bon, eh bien la fois où tu feras l'envoi, par paquets dont le nombre est limité par ton FAI ou FSI, tu verras bien si tu reçois un bounce ou pas, et basta !
Par conséquent, il y a pas mal d'adresses qui ne sont plus valables quand ça arrive. Mais comment faire, car certaines sont valable et je ne veux pas les louper. Donc je n'ai pas d'autre choix que de tout envoyer et de me faire bloquer par l'hébergeur je pense ! Jusqu'à ce que j'ai ainsi purgé toute ma base... Autrement, comment savoir si l'adresse est périmée ou non ? Impossible !
Si tu fais un test aujourd'hui, tu sauras quelles adresses sont valides aujourd'hui. Mais si tu n'en as pas besoin avant demain, pourquoi le faire ?
Bon ben j'ai tenté l'envoi et je me suis fait bloquer direct au bout de 200
mails, [...]
Evidemment, c'est de mails qui datent de 2002.
Je ne comprends pas. Pourquoi diable as-tu besoin de tester (hors de
tout envoi d'information) des adresses que tu avais déjà en 2002 ?
Le problème, c'est que moi j'ai pas l'habitude de harceler de pubs les gens
qui ont rempli mon formulaire,
Nous n'en doutons pas.
donc c'est très rare que je fasse un tel envoi.
Bon, eh bien la fois où tu feras l'envoi, par paquets dont le nombre est
limité par ton FAI ou FSI, tu verras bien si tu reçois un bounce ou pas,
et basta !
Par conséquent, il y a pas mal d'adresses qui ne sont plus valables quand ça
arrive. Mais comment faire, car certaines sont valable et je ne veux pas les
louper. Donc je n'ai pas d'autre choix que de tout envoyer et de me faire
bloquer par l'hébergeur je pense ! Jusqu'à ce que j'ai ainsi purgé toute ma
base... Autrement, comment savoir si l'adresse est périmée ou non ?
Impossible !
Si tu fais un test aujourd'hui, tu sauras quelles adresses sont valides
aujourd'hui. Mais si tu n'en as pas besoin avant demain, pourquoi le faire ?
Bon ben j'ai tenté l'envoi et je me suis fait bloquer direct au bout de 200 mails, [...]
Evidemment, c'est de mails qui datent de 2002.
Je ne comprends pas. Pourquoi diable as-tu besoin de tester (hors de tout envoi d'information) des adresses que tu avais déjà en 2002 ?
Le problème, c'est que moi j'ai pas l'habitude de harceler de pubs les gens qui ont rempli mon formulaire,
Nous n'en doutons pas.
donc c'est très rare que je fasse un tel envoi.
Bon, eh bien la fois où tu feras l'envoi, par paquets dont le nombre est limité par ton FAI ou FSI, tu verras bien si tu reçois un bounce ou pas, et basta !
Par conséquent, il y a pas mal d'adresses qui ne sont plus valables quand ça arrive. Mais comment faire, car certaines sont valable et je ne veux pas les louper. Donc je n'ai pas d'autre choix que de tout envoyer et de me faire bloquer par l'hébergeur je pense ! Jusqu'à ce que j'ai ainsi purgé toute ma base... Autrement, comment savoir si l'adresse est périmée ou non ? Impossible !
Si tu fais un test aujourd'hui, tu sauras quelles adresses sont valides aujourd'hui. Mais si tu n'en as pas besoin avant demain, pourquoi le faire ?
Olivier Miakinen
Quand elle aura été approuvée, la nouvelle version devrait ressembler à ceci : <http://www.miakinen.net/tmp/faqfclp2#rub5.3>.
Dommage, je suis moyennement d'accord avec : Oubliez donc toute tentative de vérification basée sur l'interrogation d'enregistrements DNS de type MX, tentative qui sera aussi coûteuse qu'inefficace.
Une FAQ est vivante, on peut toujours modifier des choses, hein !
Pour moi il y a un double problème : - d'abord ca laisse croire que MX suffit : c'est faux, il faut MX *ou* A (cette ancienne compatibilité est toujours dans le protocole)
Quoi ??? Alors c'est que je me suis *très* mal exprimé. Ce que je dis c'est qu'il ne faut *pas* faire ce genre de test (ni MX, ni A, ni quoi que ce soit d'autre) car cela ne sert à rien.
- d'autre part, *après* la vérification syntaxique avec une regex, le test DNS me paraît tout à fait justifié. Question inefficacité, le MTA fera de toute façon la même chose avant l'envoi, donc autant le faire avant lui.
Il faudra vraiment que tu me dises comment je dois tourner la FAQ pour faire passer l'info, alors. La vérification syntaxique est là juste pour éviter de s'encombrer de failles de sécurité potentielles (sauts de ligne par exemple), alors que l'envoi d'un *vrai* message est indispensable -- et rend donc inutile toute tentative de vérification par test de DNS.
Quand
elle aura été approuvée, la nouvelle version devrait ressembler à ceci :
<http://www.miakinen.net/tmp/faqfclp2#rub5.3>.
Dommage, je suis moyennement d'accord avec :
Oubliez donc toute tentative de vérification basée sur l'interrogation
d'enregistrements DNS de type MX, tentative qui sera aussi coûteuse
qu'inefficace.
Une FAQ est vivante, on peut toujours modifier des choses, hein !
Pour moi il y a un double problème :
- d'abord ca laisse croire que MX suffit : c'est faux, il faut MX *ou* A
(cette ancienne compatibilité est toujours dans le protocole)
Quoi ??? Alors c'est que je me suis *très* mal exprimé. Ce que je dis
c'est qu'il ne faut *pas* faire ce genre de test (ni MX, ni A, ni quoi
que ce soit d'autre) car cela ne sert à rien.
- d'autre part, *après* la vérification syntaxique avec une regex, le
test DNS me paraît tout à fait justifié.
Question inefficacité, le MTA fera de toute façon la même chose avant
l'envoi, donc autant le faire avant lui.
Il faudra vraiment que tu me dises comment je dois tourner la FAQ pour
faire passer l'info, alors. La vérification syntaxique est là juste
pour éviter de s'encombrer de failles de sécurité potentielles (sauts
de ligne par exemple), alors que l'envoi d'un *vrai* message est
indispensable -- et rend donc inutile toute tentative de vérification
par test de DNS.
Quand elle aura été approuvée, la nouvelle version devrait ressembler à ceci : <http://www.miakinen.net/tmp/faqfclp2#rub5.3>.
Dommage, je suis moyennement d'accord avec : Oubliez donc toute tentative de vérification basée sur l'interrogation d'enregistrements DNS de type MX, tentative qui sera aussi coûteuse qu'inefficace.
Une FAQ est vivante, on peut toujours modifier des choses, hein !
Pour moi il y a un double problème : - d'abord ca laisse croire que MX suffit : c'est faux, il faut MX *ou* A (cette ancienne compatibilité est toujours dans le protocole)
Quoi ??? Alors c'est que je me suis *très* mal exprimé. Ce que je dis c'est qu'il ne faut *pas* faire ce genre de test (ni MX, ni A, ni quoi que ce soit d'autre) car cela ne sert à rien.
- d'autre part, *après* la vérification syntaxique avec une regex, le test DNS me paraît tout à fait justifié. Question inefficacité, le MTA fera de toute façon la même chose avant l'envoi, donc autant le faire avant lui.
Il faudra vraiment que tu me dises comment je dois tourner la FAQ pour faire passer l'info, alors. La vérification syntaxique est là juste pour éviter de s'encombrer de failles de sécurité potentielles (sauts de ligne par exemple), alors que l'envoi d'un *vrai* message est indispensable -- et rend donc inutile toute tentative de vérification par test de DNS.
jpll
Le Tue, 21 Mar 2006 08:01:02 +0000, Atelier Alupi a écrit :
Bonjour à tous,
Y a-t-il un moyen de tester les adresses emails d'une base de données MySql avec php et de supprimer les mails qui reviennent "Undelivered" ? Si quelqu'un opère ce tour de magie, chapeau !
Nicolas
IMHO. Je suis assez nul (autodidacte qui essai de suivre ;)) mais pourquoi de ne pas envoyer toute ta base par séquences. Des paquets de X*100 < blocage spam, à partir d'une adresse créée pour l'occasion, avec un petit message "blah... blah...ne répondez pas, mise à jour blah... blah...", puis récupérer qq minutes après, les entêtes Undelivered avec un petit script/filtre basé sur imap_headerinfo() qui mettrait à jour la base? Je pense qu'on peut utiliser cron pour ça, non?
Le Tue, 21 Mar 2006 08:01:02 +0000, Atelier Alupi a écrit :
Bonjour à tous,
Y a-t-il un moyen de tester les adresses emails d'une base de données
MySql avec php et de supprimer les mails qui reviennent "Undelivered" ? Si
quelqu'un opère ce tour de magie, chapeau !
Nicolas
IMHO.
Je suis assez nul (autodidacte qui essai de
suivre ;)) mais pourquoi de ne pas envoyer toute ta base par séquences.
Des paquets de X*100 < blocage spam, à partir d'une adresse créée
pour l'occasion, avec un petit message "blah... blah...ne répondez pas,
mise à jour blah... blah...", puis récupérer qq minutes après, les
entêtes Undelivered avec un petit script/filtre basé sur
imap_headerinfo() qui mettrait à jour la base? Je pense qu'on peut
utiliser cron pour ça, non?
Le Tue, 21 Mar 2006 08:01:02 +0000, Atelier Alupi a écrit :
Bonjour à tous,
Y a-t-il un moyen de tester les adresses emails d'une base de données MySql avec php et de supprimer les mails qui reviennent "Undelivered" ? Si quelqu'un opère ce tour de magie, chapeau !
Nicolas
IMHO. Je suis assez nul (autodidacte qui essai de suivre ;)) mais pourquoi de ne pas envoyer toute ta base par séquences. Des paquets de X*100 < blocage spam, à partir d'une adresse créée pour l'occasion, avec un petit message "blah... blah...ne répondez pas, mise à jour blah... blah...", puis récupérer qq minutes après, les entêtes Undelivered avec un petit script/filtre basé sur imap_headerinfo() qui mettrait à jour la base? Je pense qu'on peut utiliser cron pour ça, non?
Olivier Masson
Il faudra vraiment que tu me dises comment je dois tourner la FAQ pour faire passer l'info, alors. La vérification syntaxique est là juste pour éviter de s'encombrer de failles de sécurité potentielles (sauts de ligne par exemple), alors que l'envoi d'un *vrai* message est indispensable -- et rend donc inutile toute tentative de vérification par test de DNS.
ça me semble clair dans ta #rub5.3.
De toutes façons, pas besoin d'être très futé pour comprendre qu'une verif DNS et champ MX n'est vraiment pas idéale puisque bcp, comme moi, tapent (en estimant que le pauvre bob a abandonné depuis longtemps son adresse) dans les champs mail qui sentent le spam.
Il faudra vraiment que tu me dises comment je dois tourner la FAQ pour
faire passer l'info, alors. La vérification syntaxique est là juste
pour éviter de s'encombrer de failles de sécurité potentielles (sauts
de ligne par exemple), alors que l'envoi d'un *vrai* message est
indispensable -- et rend donc inutile toute tentative de vérification
par test de DNS.
ça me semble clair dans ta #rub5.3.
De toutes façons, pas besoin d'être très futé pour comprendre qu'une
verif DNS et champ MX n'est vraiment pas idéale puisque bcp, comme moi,
tapent bob@hotmail.com (en estimant que le pauvre bob a abandonné depuis
longtemps son adresse) dans les champs mail qui sentent le spam.
Il faudra vraiment que tu me dises comment je dois tourner la FAQ pour faire passer l'info, alors. La vérification syntaxique est là juste pour éviter de s'encombrer de failles de sécurité potentielles (sauts de ligne par exemple), alors que l'envoi d'un *vrai* message est indispensable -- et rend donc inutile toute tentative de vérification par test de DNS.
ça me semble clair dans ta #rub5.3.
De toutes façons, pas besoin d'être très futé pour comprendre qu'une verif DNS et champ MX n'est vraiment pas idéale puisque bcp, comme moi, tapent (en estimant que le pauvre bob a abandonné depuis longtemps son adresse) dans les champs mail qui sentent le spam.
jr_work75
function isDomainValid($adresse) { list($part, $domain) = explode('@', $adresse); if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A')) { return true;} else {return false;}
}
function isDomainValid($adresse)
{
list($part, $domain) = explode('@', $adresse);
if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A'))
{ return true;}
else
{return false;}
function isDomainValid($adresse) { list($part, $domain) = explode('@', $adresse); if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A')) { return true;} else {return false;}
}
Olivier Miakinen
function isDomainValid($adresse) { list($part, $domain) = explode('@', $adresse); if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A')) { return true;} else {return false;}
}
Quel est l'intérêt de cette fonction, sachant que : (1) il *faut* envoyer une demande de confirmation et recevoir cette confirmation ; (2) il *suffit* d'envoyer une demande de confirmation et recevoir cette confirmation ?
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
function isDomainValid($adresse)
{
list($part, $domain) = explode('@', $adresse);
if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A'))
{ return true;}
else
{return false;}
}
Quel est l'intérêt de cette fonction, sachant que : (1) il *faut*
envoyer une demande de confirmation et recevoir cette confirmation ;
(2) il *suffit* d'envoyer une demande de confirmation et recevoir
cette confirmation ?
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
function isDomainValid($adresse) { list($part, $domain) = explode('@', $adresse); if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A')) { return true;} else {return false;}
}
Quel est l'intérêt de cette fonction, sachant que : (1) il *faut* envoyer une demande de confirmation et recevoir cette confirmation ; (2) il *suffit* d'envoyer une demande de confirmation et recevoir cette confirmation ?
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Patrick Mevzek
function isDomainValid($adresse) { list($part, $domain) = explode('@', $adresse); if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A')) { return true;} else {return false;}
}
Quel est l'intérêt de cette fonction, sachant que
Moins charger le MTA avec des emails qu'on sait n'avoir aucune chance d'être déliverable ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
function isDomainValid($adresse)
{
list($part, $domain) = explode('@', $adresse);
if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A'))
{ return true;}
else
{return false;}
}
Quel est l'intérêt de cette fonction, sachant que
Moins charger le MTA avec des emails qu'on sait n'avoir aucune chance
d'être déliverable ?
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
function isDomainValid($adresse) { list($part, $domain) = explode('@', $adresse); if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A')) { return true;} else {return false;}
}
Quel est l'intérêt de cette fonction, sachant que
Moins charger le MTA avec des emails qu'on sait n'avoir aucune chance d'être déliverable ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Olivier Miakinen
if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A'))
Quel est l'intérêt de cette fonction, sachant que
Moins charger le MTA avec des emails qu'on sait n'avoir aucune chance d'être déliverable ?
Bof. Le MTA est-il si fragile qu'on doive le protéger à tout prix, en particulier au prix de requêtes qui, elles, chargeront le DNS ?
En outre, le seul cas où cela évite d'envoyer le courriel, c'est quand le domaine est inexistant aussi bien en MX qu'en A. Dans ce cas, on fait deux requêtes au DNS pour en éviter une au MTA.
Dans tous les autres cas, que l'adresse existe ou non et appartienne ou non à la personne qui en a fait la demande, il y aura toujours une requête au MTA, précédée soit d'une, soit de deux requêtes au DNS, selon que l'enregistrement existe ou non en MX.
Il y a pire : la personne qui file une adresse fausse sciemment le fera peut-être d'abord avec un nom de domaine inexistant (2 requêtes au DNS), puis voyant que c'est refusé donnera une adresse au hasard en free.fr ou hotmail.com pour que ce soit accepté (1 ou 2 requêtes supplémentaires au DNS, plus un courriel), ce qui chargera encore plus le DNS *et* chargera autant le MTA.
Bref : j'attends toujours un argument convaincant pour faire autre chose que l'envoi d'une demande de confirmation par courriel (une seule, bien sûr).
Cordialement, -- Olivier Miakinen
if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A'))
Quel est l'intérêt de cette fonction, sachant que
Moins charger le MTA avec des emails qu'on sait n'avoir aucune chance
d'être déliverable ?
Bof. Le MTA est-il si fragile qu'on doive le protéger à tout prix, en
particulier au prix de requêtes qui, elles, chargeront le DNS ?
En outre, le seul cas où cela évite d'envoyer le courriel, c'est quand
le domaine est inexistant aussi bien en MX qu'en A. Dans ce cas, on fait
deux requêtes au DNS pour en éviter une au MTA.
Dans tous les autres cas, que l'adresse existe ou non et appartienne ou
non à la personne qui en a fait la demande, il y aura toujours une
requête au MTA, précédée soit d'une, soit de deux requêtes au DNS, selon
que l'enregistrement existe ou non en MX.
Il y a pire : la personne qui file une adresse fausse sciemment le fera
peut-être d'abord avec un nom de domaine inexistant (2 requêtes au DNS),
puis voyant que c'est refusé donnera une adresse au hasard en free.fr ou
hotmail.com pour que ce soit accepté (1 ou 2 requêtes supplémentaires au
DNS, plus un courriel), ce qui chargera encore plus le DNS *et* chargera
autant le MTA.
Bref : j'attends toujours un argument convaincant pour faire autre chose
que l'envoi d'une demande de confirmation par courriel (une seule, bien
sûr).
if (checkdnsrr($domain, 'MX') or checkdnsrr($domain, 'A'))
Quel est l'intérêt de cette fonction, sachant que
Moins charger le MTA avec des emails qu'on sait n'avoir aucune chance d'être déliverable ?
Bof. Le MTA est-il si fragile qu'on doive le protéger à tout prix, en particulier au prix de requêtes qui, elles, chargeront le DNS ?
En outre, le seul cas où cela évite d'envoyer le courriel, c'est quand le domaine est inexistant aussi bien en MX qu'en A. Dans ce cas, on fait deux requêtes au DNS pour en éviter une au MTA.
Dans tous les autres cas, que l'adresse existe ou non et appartienne ou non à la personne qui en a fait la demande, il y aura toujours une requête au MTA, précédée soit d'une, soit de deux requêtes au DNS, selon que l'enregistrement existe ou non en MX.
Il y a pire : la personne qui file une adresse fausse sciemment le fera peut-être d'abord avec un nom de domaine inexistant (2 requêtes au DNS), puis voyant que c'est refusé donnera une adresse au hasard en free.fr ou hotmail.com pour que ce soit accepté (1 ou 2 requêtes supplémentaires au DNS, plus un courriel), ce qui chargera encore plus le DNS *et* chargera autant le MTA.
Bref : j'attends toujours un argument convaincant pour faire autre chose que l'envoi d'une demande de confirmation par courriel (une seule, bien sûr).
