"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46aa2dc2$1@neottia.net...
> 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 ???
>
.............................
Que le visiteur reste anonyme, soit. Mais s'il veut envoyer un message, il
me semblerait normal que son adresse aparaisse , non ?
alainL

Le Fri, 27 Jul 2007 18:38:28 +0000, Thief13 a écrit:
> 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.

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

> - Un document qui recence tous les tld existant - une RFC qui décrit ce
> qui est permit avant le @ d'un mail ?

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

--
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 20:32:32 +0000, Olivier Miakinen a écrit:
> 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.

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

>>> Les erreurs les plus manifestes sont filtrées par le test de syntaxe.
>>
>> Pas les @www. par exemple.
>
> 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)

--
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 22:53:38 +0000, Patrick Mevzek a écrit:
> 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).

--
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 23:27, alainL a écrit :
>>
>> 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 ?)

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46aa7a43@neottia.net...
> Le 27/07/2007 23:27, alainL a écrit :
>>>
>>> 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 !

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


> 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

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

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



--
Impedance is futile, you will be simulated into the triode of the
Borg. -- Robert Casey, Irish patriot

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