PHWinfo - Afficher un message

28/07/2007, 22h42

Le 28/07/2007 10:26, Patrick Mevzek m'a répondu :
>>
>> 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.

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

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

> [...]
>
> 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.»

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

> [...] 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à.

> [...] 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. ;-)

28/07/2007, 22h42	#24
Olivier Miakinen Messages: n/a Hébergeur:	Re: tester validite adresse dans un form Le 28/07/2007 10:26, Patrick Mevzek m'a répondu : >> >> 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. >> 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. > 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). > [...] > > 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.» 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é. > [...] 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à. > [...] 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. ;-)