tester validite adresse dans un form

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."
Patrice KARATCHENTZEFF

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

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

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 ?

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

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


Le 27 Jul 2007 18:38:28 GMT, Thief13 <Thief13@nospam.com> écrivait
dans fr.comp.lang.php:

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 ?

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.

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 :

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.

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

- une RFC qui décrit ce qui est permit avant le @ d'un mail ?

Il doit y avoir pratiquement tout. J'ai déjà essayé * et cela a
marché !


Denis

"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46aa2dc2$1@neottia.net...

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>

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

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>