suppression de mails invalides dans une base ?

Patrick Mevzek

08/04/2006 à 10:26

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 ?

Normalement non, mais il me paraît plus logique de charger les DNS
(prévus pour ca dès le départ) que le MTA, qui a probablement des
choses plus passionnantes à faire.

Les DNS ont des mécanismes de cache, tant pour les réponses négatives
que positives. Un bon forwarder avec suffisamment de RAM va pouvoir en
contenir un paquet. Alors que chaque instance d'un MTA, c'est des
kilo-octets ou des mega-octets de RAM.

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

08/04/2006 à 17:49

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 ?

Normalement non, mais il me paraît plus logique de charger les DNS
(prévus pour ca dès le départ) que le MTA, qui a probablement des
choses plus passionnantes à faire.

Mais puisque le MTA recevra de toute façon une requête à la fin, tu ne
décharges pas le MTA en chargeant le DNS !

Les DNS ont des mécanismes de cache, tant pour les réponses négatives
que positives. Un bon forwarder avec suffisamment de RAM va pouvoir en
contenir un paquet. Alors que chaque instance d'un MTA, c'est des
kilo-octets ou des mega-octets de RAM.

Je pourrais argumenter que l'envoi d'une demande de confirmation à une
adresse n'est rien par rapport à l'envoi d'un spam à des millions de
personnes, mais je n'ai même pas besoin de cela. Il me suffit de
considérer que, pour p personnes qui cherchent à s'inscrire sur un
site web, il vaut mieux envoyer :
p requêtes au MTA
plutôt que :
p requêtes au MTA *plus* q requêtes au DNS
(et ce, quel que soit q > 0).

Si tu ne vois pas pourquoi le nombre de requêtes au MTA est le même,
relis le 4e paragraphe de mon article précédent.

Patrick Mevzek

08/04/2006 à 18:08

Mais puisque le MTA recevra de toute façon une requête à la fin,

Non, si le test DNS est négatif.

site web, il vaut mieux envoyer :
p requêtes au MTA
plutôt que :
p requêtes au MTA *plus* q requêtes au DNS
(et ce, quel que soit q > 0).

Sauf que p < q !

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

FightClub!

08/04/2006 à 19:02

Mais puisque le MTA recevra de toute façon une requête à la fin,

Non, si le test DNS est négatif.

site web, il vaut mieux envoyer :
p requêtes au MTA
plutôt que :
p requêtes au MTA *plus* q requêtes au DNS
(et ce, quel que soit q > 0).

Sauf que p < q !

Sans compter que la plupart des MTA normalement constitués vont
réessayer un certain temps avant de jeter le mail, à moins bien sur que
le MTA fasse la requete DNS lui-même => donc moi je dirais plutôt que q
est obligatoire, et p facultatif ;)

--

http://www.SD2i.com
_ Cabinet SD2i _

Olivier Miakinen

08/04/2006 à 22:18

Mais puisque le MTA recevra de toute façon une requête à la fin,

Non, si le test DNS est négatif.

Parce que tu crois vraiment que quelqu'un qui ne veut pas filer son
adresse n'essaiera pas une adresse au hasard en hotmail.com si on lui
refuse ?

site web, il vaut mieux envoyer :
p requêtes au MTA
plutôt que :
p requêtes au MTA *plus* q requêtes au DNS
(et ce, quel que soit q > 0).

Sauf que p < q !

C'est-à-dire q > p, et donc p+q > 2p. Tu confirmes donc qu'au lieu de
faire p requêtes on en fera non seulement plus que p, mais plus que 2p.
Tu m'objecteras alors que les q requêtes au DNS sont moins coûteuses que
les p au MTA, ce à quoi je te répondrai que les p au MTA seront faites
dans tous les cas, et on bouclera.

Par conséquent, à moins que quelqu'un n'apporte un éclairage différent
de tout ce qui a déjà été dit, je considère cette discussion comme
terminée en ce qui me concerne.

Patrick Mevzek

09/04/2006 à 00:15

site web, il vaut mieux envoyer :
p requêtes au MTA
plutôt que :
p requêtes au MTA *plus* q requêtes au DNS
(et ce, quel que soit q > 0).

Sauf que p < q !

C'est-à-dire q > p, et donc p+q > 2p. Tu confirmes donc qu'au lieu de
faire p requêtes on en fera non seulement plus que p, mais plus que 2p.

Sauf qu'on compare des carottes et des oranges, c'est la même couleur,
mais ca va pas coller.

Tu m'objecteras alors que les q requêtes au DNS sont moins coûteuses que
les p au MTA,

J'ai l'impression effectivement de répéter la même chose...

ce à quoi je te répondrai que les p au MTA seront faites
dans tous les cas, et on bouclera.

Non pas dans tous les cas, puisque le test DNS va supprimer certains
emails qui n'iront jamais du côté du MTA.

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

09/04/2006 à 01:45

Bon, j'avais dit que je considérerais cette discussion comme terminée,
mais je fais une dernière tentative car je crois que tu n'as simplement
pas pris le temps de lire ce que j'avais écrit, alors que si tu l'avais
lu tu comprendrais ce que je veux dire.

C'est-à-dire q > p, et donc p+q > 2p. Tu confirmes donc qu'au lieu de
faire p requêtes on en fera non seulement plus que p, mais plus que 2p.

Sauf qu'on compare des carottes et des oranges, c'est la même couleur,
mais ca va pas coller.

Oui. J'aurais mieux fait de ne pas répondre à ça, puisque cela nous
éloigne du point essentiel, qui est que le nombre de requêtes au MTA
par *visiteur* sera le même. ATTENTION : je parle bien du nombre de
requêtes au total, et pas du nombre de requêtes moyen par click des
visiteurs. Merci de lire *attentivement* ce qui suit, pour une fois.

Il y a différents cas.

1) Le visiteur qui ne veut pas entendre parle d'inscription, et qui ne
donnera jamais d'adresse de courriel sur un site.
Avec ma méthode : 0 requête au MTA
Avec ta méthode : 0 requête au MTA, 0 requête au DNS

2) Le visiteur qui veut s'inscrire et donne son adresse réelle.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 1 ou 2 requêtes au DNS

3) Le visiteur qui ne veut pas s'inscrire mais donne une adresse
au hasard d'un FAI connu (ou de son propre FAI), par exemple

Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 1 ou 2 requêtes au DNS

4) Le visiteur qui ne veut pas s'inscrire et qui commence par donner une
adresse invalide, puis une autre, jusqu'à finir par donner une adresse
au hasard d'un FAI connu (ou de son propre FAI).
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 2 à N requêtes au DNS

5) Bien sûr, il doit bien y avoir, une fois de temps en temps, un
visiteur qui ne veut pas s'inscrire, mais qui abandonnera après avoir
testé un certain nombre d'adresses invalides, sans penser à donner une
fausse adresse qui ressemble à une vraie.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 0 requête au MTA, 1 à N requêtes au DNS

Je prétends que le cas (5), le seul qui économise 1 requête au MTA,
doit être exceptionnel. Parmi les visiteurs qui rempliront vraiment le
formulaire au moins une fois alors qu'ils ne veulent pas s'inscrire, je
parierais bien qu'au moins 999 sur 1000 seront plutôt dans les cas (3)
et (4) que dans le cas (5).

Alors maintenant si tu veux débattre sur la pertinence de mon analyse tu
es le bienvenu. Mais si tu balayes tout en te contentant de répéter que
le test DNS va supprimer des requêtes au MTA, et que tu l'as déjà dit,
et que c'est de ma faute si je ne comprends pas ce que tu dis, et que
toi tu n'as pas à t'abaisser à essayer de comprendre ce que moi je dis,
je suis désolé mais je n'ai pas de temps à perdre à pisser dans un violon.

ce à quoi je te répondrai que les p au MTA seront faites
dans tous les cas, et on bouclera.

Non pas dans tous les cas, puisque le test DNS va supprimer certains
emails qui n'iront jamais du côté du MTA.

L'effet pervers du test de DNS, c'est de multiplier les essais de la
part du visiteur qui donne une fausse adresse, jusqu'au moment où il
finira par solliciter vraiment le MTA.

--
Olivier Miakinen

Bon, j'avais dit que je considérerais cette discussion comme terminée,
mais je fais une dernière tentative car je crois que tu n'as simplement
pas pris le temps de lire ce que j'avais écrit, alors que si tu l'avais
lu tu comprendrais ce que je veux dire.

C'est-à-dire q > p, et donc p+q > 2p. Tu confirmes donc qu'au lieu de
faire p requêtes on en fera non seulement plus que p, mais plus que 2p.

Sauf qu'on compare des carottes et des oranges, c'est la même couleur,
mais ca va pas coller.

Oui. J'aurais mieux fait de ne pas répondre à ça, puisque cela nous
éloigne du point essentiel, qui est que le nombre de requêtes au MTA
par *visiteur* sera le même. ATTENTION : je parle bien du nombre de
requêtes au total, et pas du nombre de requêtes moyen par click des
visiteurs. Merci de lire *attentivement* ce qui suit, pour une fois.

Il y a différents cas.

1) Le visiteur qui ne veut pas entendre parle d'inscription, et qui ne
donnera jamais d'adresse de courriel sur un site.
Avec ma méthode : 0 requête au MTA
Avec ta méthode : 0 requête au MTA, 0 requête au DNS

2) Le visiteur qui veut s'inscrire et donne son adresse réelle.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 1 ou 2 requêtes au DNS

3) Le visiteur qui ne veut pas s'inscrire mais donne une adresse
au hasard d'un FAI connu (ou de son propre FAI), par exemple
machintruc@hotmail.com.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 1 ou 2 requêtes au DNS

4) Le visiteur qui ne veut pas s'inscrire et qui commence par donner une
adresse invalide, puis une autre, jusqu'à finir par donner une adresse
au hasard d'un FAI connu (ou de son propre FAI).
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 2 à N requêtes au DNS

5) Bien sûr, il doit bien y avoir, une fois de temps en temps, un
visiteur qui ne veut pas s'inscrire, mais qui abandonnera après avoir
testé un certain nombre d'adresses invalides, sans penser à donner une
fausse adresse qui ressemble à une vraie.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 0 requête au MTA, 1 à N requêtes au DNS

Je prétends que le cas (5), le seul qui économise 1 requête au MTA,
doit être exceptionnel. Parmi les visiteurs qui rempliront vraiment le
formulaire au moins une fois alors qu'ils ne veulent pas s'inscrire, je
parierais bien qu'au moins 999 sur 1000 seront plutôt dans les cas (3)
et (4) que dans le cas (5).

Alors maintenant si tu veux débattre sur la pertinence de mon analyse tu
es le bienvenu. Mais si tu balayes tout en te contentant de répéter que
le test DNS va supprimer des requêtes au MTA, et que tu l'as déjà dit,
et que c'est de ma faute si je ne comprends pas ce que tu dis, et que
toi tu n'as pas à t'abaisser à essayer de comprendre ce que moi je dis,
je suis désolé mais je n'ai pas de temps à perdre à pisser dans un violon.

ce à quoi je te répondrai que les p au MTA seront faites
dans tous les cas, et on bouclera.

Non pas dans tous les cas, puisque le test DNS va supprimer certains
emails qui n'iront jamais du côté du MTA.

L'effet pervers du test de DNS, c'est de multiplier les essais de la
part du visiteur qui donne une fausse adresse, jusqu'au moment où il
finira par solliciter vraiment le MTA.

--
Olivier Miakinen

Vous avez filtré cet utilisateur ! Consultez son message

Bon, j'avais dit que je considérerais cette discussion comme terminée,
mais je fais une dernière tentative car je crois que tu n'as simplement
pas pris le temps de lire ce que j'avais écrit, alors que si tu l'avais
lu tu comprendrais ce que je veux dire.

C'est-à-dire q > p, et donc p+q > 2p. Tu confirmes donc qu'au lieu de
faire p requêtes on en fera non seulement plus que p, mais plus que 2p.

Sauf qu'on compare des carottes et des oranges, c'est la même couleur,
mais ca va pas coller.

Oui. J'aurais mieux fait de ne pas répondre à ça, puisque cela nous
éloigne du point essentiel, qui est que le nombre de requêtes au MTA
par *visiteur* sera le même. ATTENTION : je parle bien du nombre de
requêtes au total, et pas du nombre de requêtes moyen par click des
visiteurs. Merci de lire *attentivement* ce qui suit, pour une fois.

Il y a différents cas.

1) Le visiteur qui ne veut pas entendre parle d'inscription, et qui ne
donnera jamais d'adresse de courriel sur un site.
Avec ma méthode : 0 requête au MTA
Avec ta méthode : 0 requête au MTA, 0 requête au DNS

2) Le visiteur qui veut s'inscrire et donne son adresse réelle.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 1 ou 2 requêtes au DNS

3) Le visiteur qui ne veut pas s'inscrire mais donne une adresse
au hasard d'un FAI connu (ou de son propre FAI), par exemple

Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 1 ou 2 requêtes au DNS

4) Le visiteur qui ne veut pas s'inscrire et qui commence par donner une
adresse invalide, puis une autre, jusqu'à finir par donner une adresse
au hasard d'un FAI connu (ou de son propre FAI).
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 1 requête au MTA, 2 à N requêtes au DNS

5) Bien sûr, il doit bien y avoir, une fois de temps en temps, un
visiteur qui ne veut pas s'inscrire, mais qui abandonnera après avoir
testé un certain nombre d'adresses invalides, sans penser à donner une
fausse adresse qui ressemble à une vraie.
Avec ma méthode : 1 requête au MTA
Avec ta méthode : 0 requête au MTA, 1 à N requêtes au DNS

Je prétends que le cas (5), le seul qui économise 1 requête au MTA,
doit être exceptionnel. Parmi les visiteurs qui rempliront vraiment le
formulaire au moins une fois alors qu'ils ne veulent pas s'inscrire, je
parierais bien qu'au moins 999 sur 1000 seront plutôt dans les cas (3)
et (4) que dans le cas (5).

Alors maintenant si tu veux débattre sur la pertinence de mon analyse tu
es le bienvenu. Mais si tu balayes tout en te contentant de répéter que
le test DNS va supprimer des requêtes au MTA, et que tu l'as déjà dit,
et que c'est de ma faute si je ne comprends pas ce que tu dis, et que
toi tu n'as pas à t'abaisser à essayer de comprendre ce que moi je dis,
je suis désolé mais je n'ai pas de temps à perdre à pisser dans un violon.

ce à quoi je te répondrai que les p au MTA seront faites
dans tous les cas, et on bouclera.

Non pas dans tous les cas, puisque le test DNS va supprimer certains
emails qui n'iront jamais du côté du MTA.

L'effet pervers du test de DNS, c'est de multiplier les essais de la
part du visiteur qui donne une fausse adresse, jusqu'au moment où il
finira par solliciter vraiment le MTA.

--
Olivier Miakinen

Patrick Mevzek

09/04/2006 à 16:30

Bon, j'avais dit que je considérerais cette discussion comme terminée,
mais je fais une dernière tentative car je crois que tu n'as simplement
pas pris le temps de lire ce que j'avais écrit, alors que si tu l'avais
lu tu comprendrais ce que je veux dire.

Sur la forme, ce n'est en général pas ce genre de remarques qui a
tendance à susciter une discussion utile... Plutôt le contraire, même.

C'est-à-dire q > p, et donc p+q > 2p. Tu confirmes donc qu'au lieu de
faire p requêtes on en fera non seulement plus que p, mais plus que
2p.

Sauf qu'on compare des carottes et des oranges, c'est la même couleur,
mais ca va pas coller.

Oui. J'aurais mieux fait de ne pas répondre à ça, puisque cela nous
éloigne du point essentiel, qui est que le nombre de requêtes au MTA
par *visiteur* sera le même. ATTENTION : je parle bien du nombre de
requêtes au total, et pas du nombre de requêtes moyen par click des
visiteurs. Merci de lire *attentivement* ce qui suit, pour une fois.

Pour le coup, je peux vous retourner la même remarque.
Ca ne sert *à rien* de juste comparer des nombres. Les deux actions ne
sont *pas* équivalentes, un appel DNS est selon moi beaucoup moins
coûteux que lancer un MTA...

Je ne le répéterai pas une troisième fois.

Maintenant vous pouvez arguer du contraire ad nauseam ou refaire un
étalage de nombres sans signification. Encore une autre info, sur la
forme : si on estime que la seconde partie ne comprend pas, en général
on y gagne à faire plus synthétique, pas plus délayé !

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

Patrick Mevzek

09/04/2006 à 16:30

Bon, j'avais dit que je considérerais cette discussion comme terminée,
mais je fais une dernière tentative car je crois que tu n'as simplement
pas pris le temps de lire ce que j'avais écrit, alors que si tu l'avais
lu tu comprendrais ce que je veux dire.

Je me permets un ajout car je pense que votre prose détaillée oublie un
détail technique fort important : les réponses aux requêtes DNS sont
mises en cache (sauf cas pathétiques).

Donc la situation requête DNS hors MTA + requête DNS dans MTA (la même)
+ travail du MTA (situation que vous jugez majoritaire, ce qui n'est
qu'une interprétation qui mériterait discussion) n'est que marginalement
plus coûteuse que requête DNS dans MTA + travail du MTA, car avec ses
deux requêtes DNS identiques rapprochées, la deuxième est quasimment
une noop.

Alors que dans l'autre situation (qui vous paraît minoritaire, mais vous
ne devez pas connaître les robots qui passent sur le web pour abuser des
formulaires...) la requête DNS avant exécution du MTA fera gagner
énormément car on remplace quelque chose de coûteux par quelque chose
qui l'est beaucoup moins.

Petite perte négligeable d'un côté, gros gain de l'autre : je pense que
la balance penche clairement d'un côté.

Ce qui illustre, vivement, ce que je vous répète depuis le début : ca
ne sert à rien de juste comparer des nombres, car vous comparez des
carottes et des oranges.
J'arrêterai le «débât» ici, car je préfère les oranges.

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

09/04/2006 à 23:15

Je me permets un ajout car je pense que votre prose détaillée oublie un
détail technique fort important : les réponses aux requêtes DNS sont
mises en cache (sauf cas pathétiques).

Même si une requête MTA coûte 1000000 quand une requête DNS ne coûterait
que 0,000001, p requêtes MTA plus q requêtes DNS coûteront toujours plus
que p requêtes MTA. Pas beaucoup plus, certes, mais en tout cas pas
moins non plus ( (10^6).p + (10^-6).q > (10^6).p ).

Il reste à savoir si, comme je le prétends, on a vraiment p requêtes MTA
dans les deux cas, ou si comme tu le prétends c'est plutôt l'exception.

[...]

Alors que dans l'autre situation (qui vous paraît minoritaire, mais vous
ne devez pas connaître les robots qui passent sur le web pour abuser des
formulaires...) la requête DNS avant exécution du MTA fera gagner
énormément car on remplace quelque chose de coûteux par quelque chose
qui l'est beaucoup moins.

Ah, enfin un argument nouveau qui répond vraiment à mon objection
principale. Merci pour cela.

Tout d'abord, on peut essayer de protéger d'abord ses pages de
formulaires contre les robots malveillants. Certes, ce ne sera pas
100 % efficace. Mais ensuite, pour qu'un robot déclenche un appel
au MTA déjouable par une requête DNS, il faudrait que la valeur
fournie remplisse simultanément les deux conditions suivantes :
- syntaxiquement proche d'une vraie adresse de courriel (sinon la
regexp la refusera sans aucun accès réseau) ;
- pourvue d'un nom de domaine inexistant.

Je veux bien que les spammeurs soient cons, mais quand même : s'ils
sont assez futés pour mettre une valeur qui ressemble à une adresse de
courriel, pourquoi seraient-ils stupides au point de ne pas mettre une
adresse du genre ???

Petite perte négligeable d'un côté, gros gain de l'autre : je pense que
la balance penche clairement d'un côté.

Je n'ai aucune statistique pour dire quelle proportion exacte d'adresses
vraisemblables -- mais sur des domaines inexistants -- sont fournies par
des robots. Tu aurais ça dans ta besace ?

Cordialement,
--
Olivier Miakinen

Je me permets un ajout car je pense que votre prose détaillée oublie un
détail technique fort important : les réponses aux requêtes DNS sont
mises en cache (sauf cas pathétiques).

Même si une requête MTA coûte 1000000 quand une requête DNS ne coûterait
que 0,000001, p requêtes MTA plus q requêtes DNS coûteront toujours plus
que p requêtes MTA. Pas beaucoup plus, certes, mais en tout cas pas
moins non plus ( (10^6).p + (10^-6).q > (10^6).p ).

Il reste à savoir si, comme je le prétends, on a vraiment p requêtes MTA
dans les deux cas, ou si comme tu le prétends c'est plutôt l'exception.

[...]

Alors que dans l'autre situation (qui vous paraît minoritaire, mais vous
ne devez pas connaître les robots qui passent sur le web pour abuser des
formulaires...) la requête DNS avant exécution du MTA fera gagner
énormément car on remplace quelque chose de coûteux par quelque chose
qui l'est beaucoup moins.

Ah, enfin un argument nouveau qui répond vraiment à mon objection
principale. Merci pour cela.

Tout d'abord, on peut essayer de protéger d'abord ses pages de
formulaires contre les robots malveillants. Certes, ce ne sera pas
100 % efficace. Mais ensuite, pour qu'un robot déclenche un appel
au MTA déjouable par une requête DNS, il faudrait que la valeur
fournie remplisse simultanément les deux conditions suivantes :
- syntaxiquement proche d'une vraie adresse de courriel (sinon la
regexp la refusera sans aucun accès réseau) ;
- pourvue d'un nom de domaine inexistant.

Je veux bien que les spammeurs soient cons, mais quand même : s'ils
sont assez futés pour mettre une valeur qui ressemble à une adresse de
courriel, pourquoi seraient-ils stupides au point de ne pas mettre une
adresse du genre 65tyry43r@hotmail.com ???

Petite perte négligeable d'un côté, gros gain de l'autre : je pense que
la balance penche clairement d'un côté.

Je n'ai aucune statistique pour dire quelle proportion exacte d'adresses
vraisemblables -- mais sur des domaines inexistants -- sont fournies par
des robots. Tu aurais ça dans ta besace ?

Cordialement,
--
Olivier Miakinen

Vous avez filtré cet utilisateur ! Consultez son message

Je me permets un ajout car je pense que votre prose détaillée oublie un
détail technique fort important : les réponses aux requêtes DNS sont
mises en cache (sauf cas pathétiques).

Même si une requête MTA coûte 1000000 quand une requête DNS ne coûterait
que 0,000001, p requêtes MTA plus q requêtes DNS coûteront toujours plus
que p requêtes MTA. Pas beaucoup plus, certes, mais en tout cas pas
moins non plus ( (10^6).p + (10^-6).q > (10^6).p ).

Il reste à savoir si, comme je le prétends, on a vraiment p requêtes MTA
dans les deux cas, ou si comme tu le prétends c'est plutôt l'exception.

[...]

Alors que dans l'autre situation (qui vous paraît minoritaire, mais vous
ne devez pas connaître les robots qui passent sur le web pour abuser des
formulaires...) la requête DNS avant exécution du MTA fera gagner
énormément car on remplace quelque chose de coûteux par quelque chose
qui l'est beaucoup moins.

Ah, enfin un argument nouveau qui répond vraiment à mon objection
principale. Merci pour cela.

Tout d'abord, on peut essayer de protéger d'abord ses pages de
formulaires contre les robots malveillants. Certes, ce ne sera pas
100 % efficace. Mais ensuite, pour qu'un robot déclenche un appel
au MTA déjouable par une requête DNS, il faudrait que la valeur
fournie remplisse simultanément les deux conditions suivantes :
- syntaxiquement proche d'une vraie adresse de courriel (sinon la
regexp la refusera sans aucun accès réseau) ;
- pourvue d'un nom de domaine inexistant.

Je veux bien que les spammeurs soient cons, mais quand même : s'ils
sont assez futés pour mettre une valeur qui ressemble à une adresse de
courriel, pourquoi seraient-ils stupides au point de ne pas mettre une
adresse du genre ???

Petite perte négligeable d'un côté, gros gain de l'autre : je pense que
la balance penche clairement d'un côté.

Je n'ai aucune statistique pour dire quelle proportion exacte d'adresses
vraisemblables -- mais sur des domaines inexistants -- sont fournies par
des robots. Tu aurais ça dans ta besace ?

Cordialement,
--
Olivier Miakinen

suppression de mails invalides dans une base ?

10 réponses

Veuillez sélectionner un problème