Bonjour,
J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel" de
l'expéditeur. Mais je reçois des spams expédiés par "azertyuiop" évidemment
!
Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse de
l'expéditeur du formulaire et en cas de non concordance, d'envoyer ce
dernier à une vraie fausse adresse ???
du genre : si "courriel saisi" <> adresse expéditeur, envoyer à
poubelle@hotmail.com
merci et bonne journée
alain

Le 27/07/2007 15:28, alainL a écrit :
>
> J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel" de
> l'expéditeur.

Ok.

> Mais je reçois des spams expédiés par "azertyuiop" évidemment !

Tu peux déjà vérifier que l'adresse est syntaxiquement correcte, mais ça
ne t'empêchera pas de recevoir des messages d'azerty@ui.op.
Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.

> Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse de
> l'expéditeur du formulaire

Non, parce que tu n'as évidemment aucun moyen de connaître la ou les
adresses de l'expéditeur du formulaire... si tant est qu'il en ait une.

> et en cas de non concordance, d'envoyer ce
> dernier à une vraie fausse adresse ???

À une adresse inexistante ou qui ne t'appartient pas, tu veux dire ?
Je ne vois vraiment pas pourquoi tu voudrais faire une énormité pareille.

> du genre : si "courriel saisi" <> adresse expéditeur, envoyer à
> poubelle@hotmail.com

Et l'adresse poubelle@hotmail.com, elle t'appartient ou pas ? Si elle ne
t'appartient pas, c'est toi qui spammes. Et même si elle t'appartient
mais que tu ne la consultes pas, je ne vois pas pourquoi tu chargerais
le réseau et les serveurs de hotmail.com pour rien.

Le 27/07/2007 15:28, alainL a écrit :
>
> J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel" de
> l'expéditeur.

Ok.

> Mais je reçois des spams expédiés par "azertyuiop" évidemment !

Tu peux déjà vérifier que l'adresse est syntaxiquement correcte, mais ça
ne t'empêchera pas de recevoir des messages d'azerty@ui.op.
Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.

> Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse de
> l'expéditeur du formulaire

Non, parce que tu n'as évidemment aucun moyen de connaître la ou les
adresses de l'expéditeur du formulaire... si tant est qu'il en ait une.

> et en cas de non concordance, d'envoyer ce
> dernier à une vraie fausse adresse ???

À une adresse inexistante ou qui ne t'appartient pas, tu veux dire ?
Je ne vois vraiment pas pourquoi tu voudrais faire une énormité pareille.

> du genre : si "courriel saisi" <> adresse expéditeur, envoyer à
> poubelle@hotmail.com

Et l'adresse poubelle@hotmail.com, elle t'appartient ou pas ? Si elle ne
t'appartient pas, c'est toi qui spammes. Et même si elle t'appartient
mais que tu ne la consultes pas, je ne vois pas pourquoi tu chargerais
le réseau et les serveurs de hotmail.com pour rien.

Le 27/07/2007 15:28, alainL a ecrit :
> Bonjour,
> J'ai un formulaire qui détecte l'oubli de saisie dans le champ
> "courriel" de l'expéditeur. Mais je reçois des spams expédiés par
> "azertyuiop" évidemment !

Hello,

Je crois pas qu'il soit possible de savoir si l'adresse que rentre le
visiteur soit vraiment la sienne ou pas, mais il est possible de tester
l'adresse qu'il a rentré.
J'utilise une petite fonction qui regarde si l'adresse mail est bien de
la forme "xxxxxxx@domaine.ext"
et ensuite, je teste si il y a bien un MX sur "domaine.ext"
ma fonction est :

function Test_email ($email)
{

$test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);
if ($test_mail)
{
list ($login, $domaine) = split ("@", $email,2);
if (checkdnsrr ($domaine, "MX")) return TRUE;
else return FALSE;
}
else return FALSE;
}


JC.

Le 27/07/2007 15:28, alainL a ecrit :
> Bonjour,
> J'ai un formulaire qui détecte l'oubli de saisie dans le champ
> "courriel" de l'expéditeur. Mais je reçois des spams expédiés par
> "azertyuiop" évidemment !

Hello,

Je crois pas qu'il soit possible de savoir si l'adresse que rentre le
visiteur soit vraiment la sienne ou pas, mais il est possible de tester
l'adresse qu'il a rentré.
J'utilise une petite fonction qui regarde si l'adresse mail est bien de
la forme "xxxxxxx@domaine.ext"
et ensuite, je teste si il y a bien un MX sur "domaine.ext"
ma fonction est :

function Test_email ($email)
{

$test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);
if ($test_mail)
{
list ($login, $domaine) = split ("@", $email,2);
if (checkdnsrr ($domaine, "MX")) return TRUE;
else return FALSE;
}
else return FALSE;
}


JC.

Le 27/07/2007 17:05, JC a écrit :
>
> Je crois pas qu'il soit possible de savoir si l'adresse que rentre le
> visiteur soit vraiment la sienne ou pas,

Le seul moyen, c'est de lui poser la question à cette adresse, et
d'attendre sa réponse.

> mais il est possible de tester l'adresse qu'il a rentré.
> J'utilise une petite fonction qui regarde si l'adresse mail est bien de
> la forme "xxxxxxx@domaine.ext"

C'est la fonction donnée dans la FAQ ? Je vais regarder ça.

> et ensuite, je teste si il y a bien un MX sur "domaine.ext"

Bof bof... Si le MX existe, tu ne seras pas plus avancé pour savoir
si l'adresse existe, et encore moins pour savoir si cette adresse
appartient bien à celui qui l'a saisie. Alors que si l'adresse répond
à une demande de confirmation, tu auras la preuve que le visiteur
avait saisi la bonne sans qu'il te soit nécessaire d'interroger les
DNS. Bref, ça ne sert à rien.

> $test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);

Bingo ! À tous les coups l'on perd !
1) Passe mon adresse dans ta moulinette, tu verras qu'elle la refuse.
2) Envoie-moi un courriel et je te répondrai, tu verras que mon adresse
est néanmoins valide.
Tes sites participent donc à la ségrégation dont je suis victime.

Cf. <http://faqfclphp.free.fr/#rub5.3>.

> if (checkdnsrr ($domaine, "MX")) return TRUE;

Et à la place de ce test il vaudrait mille fois mieux une demande de
confirmation par courriel.

Le 27/07/2007 17:05, JC a écrit :
>
> Je crois pas qu'il soit possible de savoir si l'adresse que rentre le
> visiteur soit vraiment la sienne ou pas,

Le seul moyen, c'est de lui poser la question à cette adresse, et
d'attendre sa réponse.

> mais il est possible de tester l'adresse qu'il a rentré.
> J'utilise une petite fonction qui regarde si l'adresse mail est bien de
> la forme "xxxxxxx@domaine.ext"

C'est la fonction donnée dans la FAQ ? Je vais regarder ça.

> et ensuite, je teste si il y a bien un MX sur "domaine.ext"

Bof bof... Si le MX existe, tu ne seras pas plus avancé pour savoir
si l'adresse existe, et encore moins pour savoir si cette adresse
appartient bien à celui qui l'a saisie. Alors que si l'adresse répond
à une demande de confirmation, tu auras la preuve que le visiteur
avait saisi la bonne sans qu'il te soit nécessaire d'interroger les
DNS. Bref, ça ne sert à rien.

> $test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);

Bingo ! À tous les coups l'on perd !
1) Passe mon adresse dans ta moulinette, tu verras qu'elle la refuse.
2) Envoie-moi un courriel et je te répondrai, tu verras que mon adresse
est néanmoins valide.
Tes sites participent donc à la ségrégation dont je suis victime.

Cf. <http://faqfclphp.free.fr/#rub5.3>.

> if (checkdnsrr ($domaine, "MX")) return TRUE;

Et à la place de ce test il vaudrait mille fois mieux une demande de
confirmation par courriel.

>
> $test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);
>

Super ! une fonction qui interdi des email valides et authorise des mail
invalide ^^

En fait, avant l'@, tu peut avec des lettres, des chiffres, mais aussi
des caracters spéciaux : & + / \ - .
sachant que la seul contrainte, c'est que ça ne peut pas commencer par un .

Par contre, apres le @, ça ne peut commencer par un chiffre, et apres
chaque . apres le @, il ne peut y avoir de chiffre. de plus, le TLD ne
peut (a ma connaissance) dépasser 5 caractères, ni (toujours a ma
connaissance) contenir de chiffre

pour les septiques, j'ai une adresse email avec un \, une autres avec un
+ et un &, et ces deux adresses marchent tres bien. sauf quand il faut
les rentrer dans des formulaire fait par des gens qui controlent
n'importe comment.

Le Fri, 27 Jul 2007 15:34:59 +0000, Olivier Miakinen a écrit:
>> if (checkdnsrr ($domaine, "MX")) return TRUE;
>
> Et à la place de ce test il vaudrait mille fois mieux une demande de
> confirmation par courriel.

S'il n'y a pas de MX (ou de A, cas oublié dans le test), la confirmation
risque d'avoir du mal à arriver...
Donc tester MX+A c'est bien, mais pas à la place du mail, en plus.
Cela permet de filtrer les erreurs manifestes, et déleste le MTA local.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Fri, 27 Jul 2007 17:07:44 +0000, Thief13 a écrit:
> de plus, le TLD ne
> peut (a ma connaissance) dépasser 5 caractères,

Vous allez faire plaisir à .MUSEUM et .TRAVEL ...
Il n'y a pas de telle limite, si ce n'est celle de 63 caractères pour
chaque élément du nom (entre deux points).

> ni (toujours a ma connaissance) contenir de chiffre

La technique ne l'empêche pas AFAIK.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le 27/07/2007 19:07, Thief13 a écrit :
>>
>> $test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);
>>
>
> Super ! une fonction qui interdit des emails valides et autorise des mails
> invalides ^^

Exactement ce que je disais, merci de me soutenir.

> En fait, avant l'@, tu peut avec des lettres, des chiffres, mais aussi
> des caracters spéciaux : & + / \ - .

Plus quelques autres : !#$%'*=?^_`{|}~

> sachant que la seul contrainte, c'est que ça ne peut pas commencer par un .

Ça ne peut pas non plus finir par un point ni avoir deux points consécutifs.

> Par contre, apres le @, ça ne peut commencer par un chiffre, et apres
> chaque . apres le @, il ne peut y avoir de chiffre.

Non, il peut y avoir des chiffres à n'importe quel endroit. Voir par
exemple <http://www.123.com/>.

> de plus, le TLD ne
> peut (a ma connaissance) dépasser 5 caractères, ni (toujours a ma
> connaissance) contenir de chiffre

Tous deux sont faux également. Le TLD museum comporte 6 caractères,
et rien n'interdit de créer un TLD avec plus de 6 caractères ou des
chiffres.

> pour les septiques, j'ai une adresse email avec un \, une autres avec un
> + et un &, et ces deux adresses marchent tres bien. sauf quand il faut
> les rentrer dans des formulaire fait par des gens qui controlent
> n'importe comment.

Voilà, c'est vraiment très pénible, surtout pour le « + » qui permet
d'avoir plusieurs adresses différentes sur un seul compte.

Encore une fois je redonne l'adresse de la FAQ, où l'expression
régulière proposée résulte d'une longue recherche dans les documents
de référence (RFC) : <http://faqfclphp.free.fr/#rub5.3>.

Le Fri, 27 Jul 2007 15:34:59 +0000, Olivier Miakinen a écrit:
>> if (checkdnsrr ($domaine, "MX")) return TRUE;
>
> Et à la place de ce test il vaudrait mille fois mieux une demande de
> confirmation par courriel.

S'il n'y a pas de MX (ou de A, cas oublié dans le test), la confirmation
risque d'avoir du mal à arriver...
Donc tester MX+A c'est bien, mais pas à la place du mail, en plus.
Cela permet de filtrer les erreurs manifestes, et déleste le MTA local.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Fri, 27 Jul 2007 17:07:44 +0000, Thief13 a écrit:
> de plus, le TLD ne
> peut (a ma connaissance) dépasser 5 caractères,

Vous allez faire plaisir à .MUSEUM et .TRAVEL ...
Il n'y a pas de telle limite, si ce n'est celle de 63 caractères pour
chaque élément du nom (entre deux points).

> ni (toujours a ma connaissance) contenir de chiffre

La technique ne l'empêche pas AFAIK.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le 27/07/2007 19:07, Thief13 a écrit :
>>
>> $test_mail=eregi('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$',$email);
>>
>
> Super ! une fonction qui interdit des emails valides et autorise des mails
> invalides ^^

Exactement ce que je disais, merci de me soutenir.

> En fait, avant l'@, tu peut avec des lettres, des chiffres, mais aussi
> des caracters spéciaux : & + / \ - .

Plus quelques autres : !#$%'*=?^_`{|}~

> sachant que la seul contrainte, c'est que ça ne peut pas commencer par un .

Ça ne peut pas non plus finir par un point ni avoir deux points consécutifs.

> Par contre, apres le @, ça ne peut commencer par un chiffre, et apres
> chaque . apres le @, il ne peut y avoir de chiffre.

Non, il peut y avoir des chiffres à n'importe quel endroit. Voir par
exemple <http://www.123.com/>.

> de plus, le TLD ne
> peut (a ma connaissance) dépasser 5 caractères, ni (toujours a ma
> connaissance) contenir de chiffre

Tous deux sont faux également. Le TLD museum comporte 6 caractères,
et rien n'interdit de créer un TLD avec plus de 6 caractères ou des
chiffres.

> pour les septiques, j'ai une adresse email avec un \, une autres avec un
> + et un &, et ces deux adresses marchent tres bien. sauf quand il faut
> les rentrer dans des formulaire fait par des gens qui controlent
> n'importe comment.

Voilà, c'est vraiment très pénible, surtout pour le « + » qui permet
d'avoir plusieurs adresses différentes sur un seul compte.

Encore une fois je redonne l'adresse de la FAQ, où l'expression
régulière proposée résulte d'une longue recherche dans les documents
de référence (RFC) : <http://faqfclphp.free.fr/#rub5.3>.

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46a9f686$1@neottia.net...
> Le 27/07/2007 15:28, alainL a écrit :
>>
>> J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel"
>> de
>> l'expéditeur.
>
> Ok.
>
>> Mais je reçois des spams expédiés par "azertyuiop" évidemment !
>
> Tu peux déjà vérifier que l'adresse est syntaxiquement correcte, mais ça
> ne t'empêchera pas de recevoir des messages d'azerty@ui.op.
> Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.
>
>> Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse
>> de
>> l'expéditeur du formulaire
>
> Non, parce que tu n'as évidemment aucun moyen de connaître la ou les
> adresses de l'expéditeur du formulaire... si tant est qu'il en ait une.

Bien dommage !!!!

>
>> et en cas de non concordance, d'envoyer ce
>> dernier à une vraie fausse adresse ???
>
> À une adresse inexistante ou qui ne t'appartient pas, tu veux dire ?
> Je ne vois vraiment pas pourquoi tu voudrais faire une énormité pareille.
>
>> du genre : si "courriel saisi" <> adresse expéditeur, envoyer à
>> poubelle@hotmail.com
>
> Et l'adresse poubelle@hotmail.com, elle t'appartient ou pas ? Si elle ne
> t'appartient pas, c'est toi qui spammes. Et même si elle t'appartient
> mais que tu ne la consultes pas, je ne vois pas pourquoi tu chargerais
> le réseau et les serveurs de hotmail.com pour rien.

De cette façon, le spam part et l'expediteur est satisfait !... et ne
cherche pas à modifier ses paramètres de saisie.
Bien sûr, la poubelle est à moi et serait vidée systématiquement .

alainL

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46a9f686$1@neottia.net...
> Le 27/07/2007 15:28, alainL a écrit :
>>
>> J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel"
>> de
>> l'expéditeur.
>
> Ok.
>
>> Mais je reçois des spams expédiés par "azertyuiop" évidemment !
>
> Tu peux déjà vérifier que l'adresse est syntaxiquement correcte, mais ça
> ne t'empêchera pas de recevoir des messages d'azerty@ui.op.
> Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.
>
>> Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse
>> de
>> l'expéditeur du formulaire
>
> Non, parce que tu n'as évidemment aucun moyen de connaître la ou les
> adresses de l'expéditeur du formulaire... si tant est qu'il en ait une.

Bien dommage !!!!

>
>> et en cas de non concordance, d'envoyer ce
>> dernier à une vraie fausse adresse ???
>
> À une adresse inexistante ou qui ne t'appartient pas, tu veux dire ?
> Je ne vois vraiment pas pourquoi tu voudrais faire une énormité pareille.
>
>> du genre : si "courriel saisi" <> adresse expéditeur, envoyer à
>> poubelle@hotmail.com
>
> Et l'adresse poubelle@hotmail.com, elle t'appartient ou pas ? Si elle ne
> t'appartient pas, c'est toi qui spammes. Et même si elle t'appartient
> mais que tu ne la consultes pas, je ne vois pas pourquoi tu chargerais
> le réseau et les serveurs de hotmail.com pour rien.

De cette façon, le spam part et l'expediteur est satisfait !... et ne
cherche pas à modifier ses paramètres de saisie.
Bien sûr, la poubelle est à moi et serait vidée systématiquement .

alainL

Le 27/07/2007 19:22, Patrick Mevzek a écrit :
>>
>> Et à la place de ce test il vaudrait mille fois mieux une demande de
>> confirmation par courriel.
>
> S'il n'y a pas de MX (ou de A, cas oublié dans le test), la confirmation
> risque d'avoir du mal à arriver...

.... donc elle n'arrivera pas, ce qui est bien le (non-)résultat attendu
dans le cas d'une adresse incorrecte ! La seule chose c'est que la
recherche de MX ou de A sera faite une seule fois, au moment de la
tentative d'envoi du courriel, et non deux fois. Et puis laisser faire
le MTA permet d'éviter les erreurs idiotes telles que chercher seulement
un MX en oubliant le A. Enfin, si un jour il faut chercher un troisième
type d'enregistrement, on risque de mettre à jour le MTA en oubliant les
bêtes scripts PHP. (Oui, je sais que ce dernier cas a toutes les chances
de ne jamais arriver, mais bon, on ne sait jamais.)

> Donc tester MX+A c'est bien, mais pas à la place du mail, en plus.
> Cela permet de filtrer les erreurs manifestes, et déleste le MTA local.

Les erreurs les plus manifestes sont filtrées par le test de syntaxe.
Quant au gain de performance sur le MTA local, j'aimerais bien avoir
des mesures sur un cas concret qui montre sa réalité.

Le 27/07/2007 19:24, alainL a écrit :
>>
>>> Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse
>>> de l'expéditeur du formulaire
>>
>> Non, parce que tu n'as évidemment aucun moyen de connaître la ou les
>> adresses de l'expéditeur du formulaire... si tant est qu'il en ait une.
>
> Bien dommage !!!!

Ah ? Place-toi donc du côté du visiteur plutôt que du côté de l'auteur
du site : tu aimerais que chaque site visité puisse obtenir ton adresse
de courriel aussitôt que tu cliques sur un bouton ???

>> [...]
>
> De cette façon, le spam part et l'expediteur est satisfait !... et ne
> cherche pas à modifier ses paramètres de saisie.
> Bien sûr, la poubelle est à moi et serait vidée systématiquement .

Un petit message « Votre spam^H^H^H^Hmessage a été envoyé » serait aussi
efficace pour contenter les éventuels spammeurs. Mais une demande de
confirmation de trois lignes avant de faire quoi que ce soit d'autre
serait quand même l'idéal.

Le 27/07/2007 19:22, Patrick Mevzek a écrit :
>>
>> Et à la place de ce test il vaudrait mille fois mieux une demande de
>> confirmation par courriel.
>
> S'il n'y a pas de MX (ou de A, cas oublié dans le test), la confirmation
> risque d'avoir du mal à arriver...

.... donc elle n'arrivera pas, ce qui est bien le (non-)résultat attendu
dans le cas d'une adresse incorrecte ! La seule chose c'est que la
recherche de MX ou de A sera faite une seule fois, au moment de la
tentative d'envoi du courriel, et non deux fois. Et puis laisser faire
le MTA permet d'éviter les erreurs idiotes telles que chercher seulement
un MX en oubliant le A. Enfin, si un jour il faut chercher un troisième
type d'enregistrement, on risque de mettre à jour le MTA en oubliant les
bêtes scripts PHP. (Oui, je sais que ce dernier cas a toutes les chances
de ne jamais arriver, mais bon, on ne sait jamais.)

> Donc tester MX+A c'est bien, mais pas à la place du mail, en plus.
> Cela permet de filtrer les erreurs manifestes, et déleste le MTA local.

Les erreurs les plus manifestes sont filtrées par le test de syntaxe.
Quant au gain de performance sur le MTA local, j'aimerais bien avoir
des mesures sur un cas concret qui montre sa réalité.

Le 27/07/2007 19:24, alainL a écrit :
>>
>>> Est-il possible de comparer l'adresse saisie dans ce champ avec l'adresse
>>> de l'expéditeur du formulaire
>>
>> Non, parce que tu n'as évidemment aucun moyen de connaître la ou les
>> adresses de l'expéditeur du formulaire... si tant est qu'il en ait une.
>
> Bien dommage !!!!

Ah ? Place-toi donc du côté du visiteur plutôt que du côté de l'auteur
du site : tu aimerais que chaque site visité puisse obtenir ton adresse
de courriel aussitôt que tu cliques sur un bouton ???

>> [...]
>
> De cette façon, le spam part et l'expediteur est satisfait !... et ne
> cherche pas à modifier ses paramètres de saisie.
> Bien sûr, la poubelle est à moi et serait vidée systématiquement .

Un petit message « Votre spam^H^H^H^Hmessage a été envoyé » serait aussi
efficace pour contenter les éventuels spammeurs. Mais une demande de
confirmation de trois lignes avant de faire quoi que ce soit d'autre
serait quand même l'idéal.

Le Fri, 27 Jul 2007 17:43:13 +0000, Olivier Miakinen a écrit:
>> S'il n'y a pas de MX (ou de A, cas oublié dans le test), la confirmation
>> risque d'avoir du mal à arriver...
>
> ... donc elle n'arrivera pas, ce qui est bien le (non-)résultat attendu
> dans le cas d'une adresse incorrecte !

Sauf que la requête DNS est synchrone, et peu coûteuse, par rapport à
donner un mail à traiter au MTA.
Le résultat de la requête DNS peut être traitée immédiatement dans
l'application web, et présenter par exemple un beau message d'erreur et
laisser l'utilisateur corriger.
Une fois l'email donné au MTA, celui-ci peut le mettre de côté et tenter
l'envoi seulement plus tard, s'il est surchargé par exemple. On n'aura
donc la réponse que de manière asynchrone, dans un délai non garanti, et
surtout ne permettant pas simplement de présenter le problème au client.

>> Donc tester MX+A c'est bien, mais pas à la place du mail, en plus.
>> Cela permet de filtrer les erreurs manifestes, et déleste le MTA local.
>
> Les erreurs les plus manifestes sont filtrées par le test de syntaxe.

Pas les @www. par exemple.

> Quant au gain de performance sur le MTA local, j'aimerais bien avoir
> des mesures sur un cas concret qui montre sa réalité.

La question ne se pose même pas.
La requête DNS a lieu forcément, au moins à un endroit. Entre la faire
dans le processus actuel ou lancer un autre processus, complétement
indépendant, qui doit faire la requête, forcément le deuxième cas est
davantage coûteux.
Et dans le cas où elle réussit, la requête aura bien lieu deux fois, sauf
qu'avec le cache local, la deuxième fois récupérera (a priori) les
résultats de la première, donc la deuxième requête est quasimment nulle en
coût. On gagne sur les deux cas de figure.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Fri, 27 Jul 2007 17:43:13 +0000, Olivier Miakinen a écrit:
>> S'il n'y a pas de MX (ou de A, cas oublié dans le test), la confirmation
>> risque d'avoir du mal à arriver...
>
> ... donc elle n'arrivera pas, ce qui est bien le (non-)résultat attendu
> dans le cas d'une adresse incorrecte !

Sauf que la requête DNS est synchrone, et peu coûteuse, par rapport à
donner un mail à traiter au MTA.
Le résultat de la requête DNS peut être traitée immédiatement dans
l'application web, et présenter par exemple un beau message d'erreur et
laisser l'utilisateur corriger.
Une fois l'email donné au MTA, celui-ci peut le mettre de côté et tenter
l'envoi seulement plus tard, s'il est surchargé par exemple. On n'aura
donc la réponse que de manière asynchrone, dans un délai non garanti, et
surtout ne permettant pas simplement de présenter le problème au client.

>> Donc tester MX+A c'est bien, mais pas à la place du mail, en plus.
>> Cela permet de filtrer les erreurs manifestes, et déleste le MTA local.
>
> Les erreurs les plus manifestes sont filtrées par le test de syntaxe.

Pas les @www. par exemple.

> Quant au gain de performance sur le MTA local, j'aimerais bien avoir
> des mesures sur un cas concret qui montre sa réalité.

La question ne se pose même pas.
La requête DNS a lieu forcément, au moins à un endroit. Entre la faire
dans le processus actuel ou lancer un autre processus, complétement
indépendant, qui doit faire la requête, forcément le deuxième cas est
davantage coûteux.
Et dans le cas où elle réussit, la requête aura bien lieu deux fois, sauf
qu'avec le cache local, la deuxième fois récupérera (a priori) les
résultats de la première, donc la deuxième requête est quasimment nulle en
coût. On gagne sur les deux cas de figure.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

> Non, il peut y avoir des chiffres à n'importe quel endroit. Voir par
> exemple <http://www.123.com/>.
>
Ha c'est étrange, j'avais lu dans une rfc que l'on ne pouvais pas...

En tout cas, merci pour tout ces précisions : pour en arriver là,
j'avais fait pas mal de recherche, mais c'est dur de trouver de bonnes
sources d'information car les fonctions filtres que l'on trouve sur le
net sont toujours bidons, j'en ai jamais trouvé une vraiment bien, alor
je me suis documenté comme j'ai pu a travers les moult rfc.
tout ce que tu m'a dit va me permettre d'affiner ma fonction de filtre.

Je n'étais pas bien sur pour mes 2 dernières allégation, c'est pour ça
que j'ai rajouté à ma connaissance. d'ailleur, au niveau de la taille
des TLD, j'ai déjà des problème avec le .info : c'est dingue le nombre
de filtre qui n'accepte pas plus de 3 caractères ! Sinon, meme si aucune
norme ne l'interdit, existe t il un seul TLD avec un chiffre ? et ou
peut t on trouver :
- Un document qui recence tous les tld existant
- une RFC qui décrit ce qui est permit avant le @ d'un mail ?

merci

alainL - <46aa297d$0$21151$7a628cd7@news.club-internet.fr> :

> De cette façon, le spam part et l'expediteur est satisfait !

Ca va pas, non?
Le spam ne doit PAS partir. Point.

--
"C'est très facile d'avoir des idées de partage quand on n'a rien."
PatriceKARATCHENTZEFF

alainL - <46aa297d$0$21151$7a628cd7@news.club-internet.fr> :

> De cette façon, le spam part et l'expediteur est satisfait !

Ca va pas, non?
Le spam ne doit PAS partir. Point.

--
"C'est très facile d'avoir des idées de partage quand on n'a rien."
PatriceKARATCHENTZEFF