tester validite adresse dans un form

[alainL]

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 à
***@hotmail.com
merci et bonne journée
alain

[Olivier Miakinen]

Post by alainL
J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel" de
l'expéditeur.

Ok.

Post by alainL
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'***@ui.op.
Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.

Post by alainL
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.

Post by alainL
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.

Post by alainL
du genre : si "courriel saisi" <> adresse expéditeur, envoyer à

Et l'adresse ***@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.

[alainL]

Post by Olivier Miakinen

Post by alainL
J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel" de
l'expéditeur.

Ok.

Post by alainL
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
Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.

Post by alainL
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 !!!!

Post by Olivier Miakinen

Post by alainL
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.

Post by alainL
du genre : si "courriel saisi" <> adresse expéditeur, envoyer à

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]

Post by alainL

Post by Olivier Miakinen

Post by alainL
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 ???

Post by alainL

Post by Olivier Miakinen
[...]

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.

[alainL]

Post by Olivier Miakinen

Post by alainL

Post by Olivier Miakinen

Post by alainL
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 ???

............................
Que le visiteur reste anonyme, soit. Mais s'il veut envoyer un message, il
me semblerait normal que son adresse aparaisse , non ?
alainL

[Olivier Miakinen]

Post by alainL

Post by Olivier Miakinen
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 ???

Que le visiteur reste anonyme, soit. Mais s'il veut envoyer un message, il
me semblerait normal que son adresse apparaisse , non ?

Tout d'abord, si le visiteur veut envoyer un message, alors il utilise
son courrielleur. Comme la plupart du temps il attend une réponse par
courriel également, il a configuré son adresse dans le champ From.

Mais si c'est le concepteur d'un site web qui décide qu'un formulaire
déclenchera l'envoi d'un courriel, il ne demande pas son avis au
visiteur, qui peut très bien ne pas être au courant (et la CNIL non
plus). Il me semble normal, à moi, que ce soit le visiteur qui décide
ou non de fournir son adresse de courriel, et quelle adresse.

De toutes façons, vie privée ou pas, les navigateurs ne sont pas prévus
pour stocker des adresses de courriel à envoyer aux sites web. (Et
pourquoi pas le numéro de carte bleue, tant qu'on y est ?)

[alainL]

Post by Olivier Miakinen

Post by alainL

Post by Olivier Miakinen
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 ???

Que le visiteur reste anonyme, soit. Mais s'il veut envoyer un message, il
me semblerait normal que son adresse apparaisse , non ?

Tout d'abord, si le visiteur veut envoyer un message, alors il utilise
son courrielleur. Comme la plupart du temps il attend une réponse par
courriel également, il a configuré son adresse dans le champ From.

Lui n'est donc pas opposé à l'apparition de l'adresse !

Post by Olivier Miakinen
Mais si c'est le concepteur d'un site web qui décide qu'un formulaire
déclenchera l'envoi d'un courriel, il ne demande pas son avis au
visiteur, qui peut très bien ne pas être au courant (et la CNIL non
plus). Il me semble normal, à moi, que ce soit le visiteur qui décide
ou non de fournir son adresse de courriel, et quelle adresse.

Hélas, vu l'utilisation qu'en feraient certains, tu as peut-être raison :-((
mais pour moi, ça me laisse qd même un goût de lettre anonyme !

Post by Olivier Miakinen
De toutes façons, vie privée ou pas, les navigateurs ne sont pas prévus
pour stocker des adresses de courriel à envoyer aux sites web.

Ce qui règle le (mon) problème. Je vais potasser la possibilité d'inclure un
code à recopier....
A bientôt !

alainL

[Thierry B.]

--{ alainL a plopé ceci: }--

Post by alainL
Hélas, vu l'utilisation qu'en feraient certains, tu as peut-être raison :-((
mais pour moi, ça me laisse qd même un goût de lettre anonyme !

"Ce qu'il y a de bien avec Internet, c'est que personne ne sait
que vous êtes anonyme."

hop, on passe au bar...

[Rakotomandimby (R12y) Mihamina]

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

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

[alainL]

Post by Olivier Miakinen

Post by alainL
J'ai un formulaire qui détecte l'oubli de saisie dans le champ "courriel" de
l'expéditeur.

Ok.

Post by alainL
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
Cf. la FAQ : <http://faqfclphp.free.fr/#rub5.3>.

En attendant, j'ai placé ce code :

$pattern = ':^[.A-Za-z0-9!#$%&\'*+/=?^_`{|}~-]+@[.A-Za-z0-9-]+$:'; //modele
classique d'adresse
if($Courriel <> $pattern ) //si l'adresse n'est pas conforme au modèle
{
echo("<B>Courriel:</B> <FONT COLOR=red>Invalide</FONT> <A
HREF=form.php>Retour à saisie</A><BR>");
$required = 0;

mais une adresse du style ***@azer.cvb est refusée ?

Où est la coquille ????
Merci
alain

[Olivier Miakinen]

Post by alainL
classique d'adresse

Dans la FAQ il y avait :
$pattern = ':^[.A-Za-z0-9!#$%&\'*+/=?^_`{|}~-]+@[.A-Za-z0-9-]+$:';

Ça me semble bien.

Post by alainL
if($Courriel <> $pattern ) //si l'adresse n'est pas conforme au modèle

Dans la FAQ il y avait :
if (preg_match($pattern, $email)) { ... }

La différence est assez flagrante, non ?

Note que le test indiqué dans la FAQ répondra vrai si l'adresse est
correcte, tu devrais donc utiliser plutôt (!preg_match(...)).
Oui, parce que vu le genre de test la seule « adresse » possible est

Post by alainL
Où est la coquille ????

Cf. supra.

[alainL]

.............

Post by Olivier Miakinen

Post by alainL
if($Courriel <> $pattern ) //si l'adresse n'est pas conforme au modèle

if (preg_match($pattern, $email)) { ... }
La différence est assez flagrante, non ?
Note que le test indiqué dans la FAQ répondra vrai si l'adresse est
correcte, tu devrais donc utiliser plutôt (!preg_match(...)).
Oui, parce que vu le genre de test la seule « adresse » possible est

Ben voilà, quand on ne veut pas passer par les bases !
Mon test provisoire marche, donc.
Le mieux serait sans doute d'introduire un code à copier mais le script
trouvé me pose pour l'instant pas mal de questions ! Je potasse !

Merci pour ton aide et bonne journée.

[JC]

Post by alainL
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 "***@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.

[Olivier Miakinen]

Post by JC
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.

Post by JC
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

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

Post by JC
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.
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>.

Post by JC
if (checkdnsrr ($domaine, "MX")) return TRUE;

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

[Patrick Mevzek]

Post by Olivier Miakinen

Post by JC
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.

[Olivier Miakinen]

Post by Patrick Mevzek

Post by Olivier Miakinen
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.)

Post by Patrick Mevzek
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é.

[Patrick Mevzek]

Post by Olivier Miakinen

Post by Patrick Mevzek
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.

Post by Olivier Miakinen

Post by Patrick Mevzek
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é.

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.

[Olivier Miakinen]

Post by Patrick Mevzek
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.

Ah, là je dois reconnaître que tu as entièrement raison. Du coup, on
pourrait peut-être mettre à jour la FAQ. Tu aurais le temps et le
courage de nous pondre quelque chose pour corriger le texte actuel ?

Au fait, pour répondre à Thief13 il serait bien d'y rajouter aussi les
références vers les RFC, que je n'avais pas mises.

http://faqfclphp.free.fr/#rub5.3

Post by Patrick Mevzek
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.

Oui, je suis encore d'accord (comme quoi tu as bien fait d'insister). ;-)

Post by Patrick Mevzek

Post by Olivier Miakinen
Les erreurs les plus manifestes sont filtrées par le test de syntaxe.

Il est donc interdit de déposer un nom de domaine en www.quelquechose,
qui servira ensuite pour le courriel ?

Post by Patrick Mevzek
[...] 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.

Encore d'accord, mais j'émettais juste un doute sur l'importance de ce
gain. Mais bon, inutile de poursuivre sur ce point, puisque je reconnais
maintenant qu'il y a d'autres avantages à tester les DNS.

[Patrick Mevzek]

Post by Olivier Miakinen
Du coup, on
pourrait peut-être mettre à jour la FAQ. Tu aurais le temps et le
courage de nous pondre quelque chose pour corriger le texte actuel ?
Au fait, pour répondre à Thief13 il serait bien d'y rajouter aussi les
références vers les RFC, que je n'avais pas mises.
http://faqfclphp.free.fr/#rub5.3

Si je me permets de me donner mon avis, le
« et si l'adresse appartient bien à la personne qui vous l'a donnée »
me gêne.
Je découperai en deux : la validité technique (est-ce une adresse email ou
pas) et la validité sémantique (est-ce bien une adresse email qui
correspond à une boîte aux lettres existante, et plus particulièrement à la
personne qui vient de me la donner en prétendant que c'est la sienne).

Pour tester la validité technique, il faut filtrer, typiquement avec une
expression régulière plus ou moins complexe.
Pour tester la validité sémantique, il n'y a pas d'autre choix que
d'envoyer un message, avec un code dedans ou une URL (non devinables) et
attendre sur une certaine durée (au moins 5 jours, 48 heures ca peut être
un peu court, les MTAs peuvent être surchargés, il y en a au moins 2 de
concernés, et typiquement 4 ou 5. Un sendmail par défaut abandonne au
bout de 5 jours, même si les gros MTA ont évidemment tendance à
raccourcir cette période) s'il se passe quelque chose.

Un test DNS, optionnel, peut être fait et se situe entre les deux.
En vérifiant qu'un enregistrement MX ou A existe pour le nom à droite du @
(et que l'enregistrement en question a bien une adresse IP), on va un peu
plus loin que la validité technique car on assure que « quelque chose »
(un MTA) est effectivement désigné pour recevoir tous les emails envoyés à
cette adresse.
Ce n'est cependant pas suffisant pour assurer que tout envoi arrive au
port (le MTA final peut très bien répondre 500 à tout le monde), et encore
moins à bon port, c'est à dire chez la personne concernée.

En bref, je remplacerai juste
« 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. »
Par :
« Une interrogation des DNS (pour chercher un enregistrement de type MX ou
A sur la partie droite de l'adresse email) peut être éventuellement
effectuée après le filtrage et avant l'envoi d'un email. En cas d'adresse
incorrecte, cela a l'avantage d'avoir une réponse immédiate, exploitable
facilement dans l'application Web pour demander au visiteur de corriger,
alors qu'après l'envoi d'un email il peut falloir attendre plusieurs
heures pour une réponse négative, qui sera difficile à analyser, et on
n'aura alors plus moyen de contacter le visiteur de son site web.»


Ou un autre truc plus court/formulé différemment, pioché ou non dans ce
que je dis plus haut. L'essentiel c'est déjà que la FAQ présente des
filtrages possibles et meilleurs que la moyenne que l'on trouve sur le web.

Post by Olivier Miakinen

Post by Patrick Mevzek
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.

Oui, je suis encore d'accord (comme quoi tu as bien fait d'insister). ;-)

Mais a contrario, sur des applications nécessitant des hautes
performances, on a tendance à faire les requêtes DNS de manière asynchrone.
Bon bref, je suis d'accord pour dire que ce qui pêche le plus ce sont les
applications qui appliquent de mauvais filtres (expressions régulières
trop simplistes), et qu'une requête DNS ne peut pas remplacer ni un tel
filtre, ni l'envoi d'un email. Cependant, sans être absolument
indispensables, l'interrogation DNS, juste après le filtre et juste avant
l'envoi de l'email, peut être utile.

Comme dit précédemment, pour moi le point important c'est un filtrage pas
pourri (ni dans un sens ni dans un autre), donc c'est là qu'il faut
appuyer. Après si on fait une requête DNS ou pas, c'est moins grave (tant
que c'est pas à la place du filtrage ou de l'envoi), donc on peut juste
donner des pistes.

Post by Olivier Miakinen

Post by Patrick Mevzek

Post by Olivier Miakinen
Les erreurs les plus manifestes sont filtrées par le test de syntaxe.

Il est donc interdit de déposer un nom de domaine en www.quelquechose,
qui servira ensuite pour le courriel ?

Non, mais les débutants peuvent mélanger adresse de site web (URL) et
adresse de courrier électronique. D'un autre côté mon exemple est foireux
: le test DNS, s'il est correct, testera MX *et* A, et s'il n'y a pas de
MX pour www.example.com, il y aura très probablement un A ! Donc le test
sera toujours vrai, et il n'y aura que l'envoi pour départager.
Mais par exemple, sur des mailing-listes en @forums.example.com, il n'y
aura pas nécessairement de site web en www.forums.example.com auquel cas
@www.forums.example.com sera détecté au niveau DNS comme incorrect.

Et si on dépose example.com il est _rare_ (mais pas impossible
techniquement, nous sommes d'accord), que le mail soit pour de vrai en
@www.example.com (sauf erreurs de configuration aussi, cela arrive
parfois/souvent pour les emails qui partent du serveur web avec un From ou
un Return-Path pas très corrects, et donc qui se transforment parfois,
lors d'un bounce, en To: ... @www.example.com)

[Olivier Miakinen]

Post by Patrick Mevzek

Post by Olivier Miakinen
Au fait, pour répondre à Thief13 il serait bien d'y rajouter aussi les
références vers les RFC, que je n'avais pas mises.

Finalement, il y a : RFC 822 et 2822.

Post by Patrick Mevzek

Post by Olivier Miakinen
http://faqfclphp.free.fr/#rub5.3

Si je me permets de me donner mon avis, le
« et si l'adresse appartient bien à la personne qui vous l'a donnée »
me gêne.

C'est pourtant le plus important. Quand quelqu'un fournit une fausse
adresse dans un formulaire web, qu'elle soit fausse parce qu'il a tapé
un truc syntaxiquement incorrect, ou parce que le nom de domaine
n'existe pas, ou encore parce qu'il a choisi au hasard une adresse en
hotmail.com ou yahoo.fr qui existe mais qui ne lui appartient pas, le
résultat est le même : le propriétaire du site web ne devrait pas la
stocker dans sa base de données comme étant l'adresse du visiteur.

Post by Patrick Mevzek
Je découperai en deux : la validité technique (est-ce une adresse email ou
pas) et la validité sémantique (est-ce bien une adresse email qui
correspond à une boîte aux lettres existante, et plus particulièrement à la
personne qui vient de me la donner en prétendant que c'est la sienne).

Si tu veux, mais cette partie de la FAQ a déjà pas mal grossi par
rapport à la version précédente et je ne suis pas sûr que notre FAQteur
accepte qu'elle grossisse encore beaucoup. Pour info, la version
précédente est toujours là sur le site miroir (avec un seul r : c'est
une faute à corriger dans les deux versions).

Post by Patrick Mevzek
[...]
En bref, je remplacerai juste
« 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 interrogation des DNS (pour chercher un enregistrement de type MX ou
A sur la partie droite de l'adresse email) peut être éventuellement
effectuée après le filtrage et avant l'envoi d'un email. En cas d'adresse
incorrecte, cela a l'avantage d'avoir une réponse immédiate, exploitable
facilement dans l'application Web pour demander au visiteur de corriger,
alors qu'après l'envoi d'un email il peut falloir attendre plusieurs
heures pour une réponse négative, qui sera difficile à analyser, et on
n'aura alors plus moyen de contacter le visiteur de son site web.»

Un bout de code serait le bienvenu, en plus ou à la place de longues
explications. Bon, si tu me fournis le bout de code, je veux bien
rédiger le reste en tenant compte de ce que tu as déjà expliqué.

Post by Patrick Mevzek
[...] L'essentiel c'est déjà que la FAQ présente des
filtrages possibles et meilleurs que la moyenne que l'on trouve sur le web.

[Oui]
Le filtrage de la version précédente de la FAQ était meilleur que la
moyenne, mais apparemment trop laxiste pour être adopté par ceux qui
filtraient sur [A-Za-z0-9_-]. La version actuelle présente déjà
l'avantage d'être bien meilleure de ce point de vue là.

Post by Patrick Mevzek
[...] a contrario, sur des applications nécessitant des hautes
performances, on a tendance à faire les requêtes DNS de manière asynchrone.

Une application qui attend que le visiteur saisisse une adresse de
courriel dans un formulaire ne peut pas s'attendre à des hautes
performances sur cette partie du traitement. ;-)

[Thief13]

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.

[Olivier Miakinen]

Super ! une fonction qui interdit des emails valides et autorise des mails
invalides ^^

Exactement ce que je disais, merci de me soutenir.

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

[Thief13]

Post by Olivier Miakinen
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

[Denis Beauregard]

(comme c'est de moins en moins du PHP dans cette enfilade, je redirige
vers le forum pour les auteurs)

Post by Thief13

Post by Olivier Miakinen
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...

Tu n'as jamais reçu de spam chinois de 263.com ?

Post by Thief13
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 pense que la seule façon absolue, c'est en returnant un mot de
passe à celui qui veut envoyer un message. Le spam est en général
fait de façon massive avec une adresse de retour invalide, le
traitement à la main étant trop coûteux.

Post by Thief13
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

Pas encore de TLD avec un chiffre, mais rien n'empêche d'utiliser une
adresse IP pour recevoir des courriels, même si personne ne le fait.

Post by Thief13
- Un document qui recence tous les tld existant

Il y a un certain nombre de pages comme
http://www.chu-rouen.fr/dsii/html/pays.html qui date de 1998 et n'a
pas les TLD les plus récents. De plus, certains pays peuvent avoir
changé de nom depuis. Donc, il faut une liste datée de 2007.

Il faut aussi se méfier de certaines listes similaires mais pas
identiques. Par exemple, on trouve sur Wikipedia, une liste FIPS
qui est en fait celle utilisée dans d'autres listes.

La liste officielle doit être celle de l'IANA
http://www.iana.org/root-whois/index.html

Sur Wikipedia, on trouve par ailleurs des listes commentées des TLD:

http://fr.wikipedia.org/wiki/Domaine_national_de_premier_niveau
http://en.wikipedia.org/wiki/Country_code_top-level_domain#A

La liste en français a les codes sur une page mais il faut cliquer
pour chaque pays alors que la liste en anglais a les codes sur la
même page que le nom des pays.

Ces listes indiquent par exemple que certains TLD sont désuets mais
encore en usage et d'autres sont valides mais inutilisés.

Wikipedia a aussi une liste des TLD non nationaux

http://en.wikipedia.org/wiki/Generic_top-level_domain

mais avec .cat pour le catalan, je me demande si cette liste est
valide. Apparemment, le .cat semble tout de même valide (il y a bien
un site http://www.domini.cat/ ).

La page de wikipedia parle de tld commandités. En d'autres mots,
il y a maintenant des organismes qui peuvent revendiquer et obtenir
leur propre tld (les .cat sont un tel exemple). Verrons un jour
des sites comme www.quebec.qc, www.linux.linux ou même www.php.php ?

Par exemple, pour ceux qui lisent le catalan, la page d'accueil de
www.domini.cat souligne que ces noms de domaine peuvent comprendre
des lettres comme à, è, é, í, ï, ò, ó, ú, ü, ç, l·l qui sont
particulières au catalan (je ne sais pas si toutes ces lettres seront
lisibles dans mon message). Mais si on veut valider des noms de
domaine, il convient maintenant de tenir compte de ces nouvelles
particularités. Je me demande si les .fr permettront un jour les
accents eux aussi.
Il doit y avoir pratiquement tout. J'ai déjà essayé * et cela a
marché !


Denis

[Patrick Mevzek]

Post by Thief13
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 !

Parce qu'entre 1985 et 2000 (à la louche), on ne connaissait que les ccTLD
à 2 caractères et .COM/.NET/.ORG/.MIL/.GOV/.EDU/.INT (il y avait bien le
.ARPA, mais c'est pour la résolution inverse donc pas très visible), gTLDs
à 3 caractères.

Post by Thief13
Sinon, meme si aucune
norme ne l'interdit, existe t il un seul TLD avec un chiffre ?

Ce ne sont pas des TLDs au sens strict du terme, mais ip6.arpa et ip6.ont
ont existé/existe comme racine pour la résolution inverse IPv6.

Post by Thief13
- Un document qui recence tous les tld existant - une RFC qui décrit ce

Cf mes pistes dans
<46aa68e3$0$16631$***@news.free.fr>
juste postées dans
fr.comp.infosystemes.www.auteurs, ayant migré avec le fil.

[Patrick Mevzek]

Post by Patrick Mevzek
Ce ne sont pas des TLDs au sens strict du terme, mais ip6.arpa et ip6.ont
ont existé/existe comme racine pour la résolution inverse IPv6.

ip6.int bien entendu, pas .ont
et de même on note l'existence de e164.arpa dans la même catégorie (pas
TLDs au sens qu'ils sont au deuxième niveau, mais TLD racines pour
certains usages bien particuliers).

[Thierry B.]

--{ Thief13 a plopé ceci: }--

Post by Thief13

Post by Olivier Miakinen
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...

Moi aussi, je pense que cette restriction a existé, mais je
ne sais pas ce qu'elle est devenu. Foutou ?

[Patrick Mevzek]

Post by Thief13
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).

Post by Thief13
ni (toujours a ma connaissance) contenir de chiffre

La technique ne l'empêche pas AFAIK.

[Thierry B.]

--{ Thief13 a plopé ceci: }--

de plus, le TLD ne peut (a ma connaissance) dépasser 5 caractères,

.museum ?