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

Le 27/07/2007 20:38, Patrick Mevzek a écrit :
>
> 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...premier_niveau
http://en.wikipedia.org/wiki/Country...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