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 à
poubelle@hotmail.com
merci et bonne journée
alain
"Olivier Miakinen" <om+ a écrit dans le message de 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.
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
"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
46aa7a43@neottia.net...
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 !
"Olivier Miakinen" <om+ a écrit dans le message de 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.
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
Nicolas Krebs
Olivier Miakinen écrivit dans l'article news: dans news:fr.comp.lang.php
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 ?)
Vous ne connaissez pas P3P ?
- Mathieu O'Neil, « Internet, ou la fin de la vie privée », Le Monde diplomatique, septembre 1998, http://www.monde-diplomatique.fr/1998/09/O_NEIL/10914 - Marc Laimé, « Allons-nous devoir vendre nos données personnelles ? », uzine.net, octobre 2001, http://www.uzine.net/article1198.html - Platform for Privacy Preferences (P3P) Project, http://www.w3.org/P3P/ - P3P 1.0, traduction en français de J. Solari, http://www.yoyodesign.org/doc/w3c/p3p1/ (rechercher p3p ou carte ou card dans ces documents)
Olivier Miakinen écrivit dans l'article news:46aa7a43@neottia.net
dans news:fr.comp.lang.php
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 ?)
Vous ne connaissez pas P3P ?
- Mathieu O'Neil, « Internet, ou la fin de la vie privée »,
Le Monde diplomatique, septembre 1998,
http://www.monde-diplomatique.fr/1998/09/O_NEIL/10914
- Marc Laimé, « Allons-nous devoir vendre nos données personnelles ? »,
uzine.net, octobre 2001, http://www.uzine.net/article1198.html
- Platform for Privacy Preferences (P3P) Project, http://www.w3.org/P3P/
- P3P 1.0, traduction en français de J. Solari,
http://www.yoyodesign.org/doc/w3c/p3p1/
(rechercher p3p ou carte ou card dans ces documents)
Olivier Miakinen écrivit dans l'article news: dans news:fr.comp.lang.php
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 ?)
Vous ne connaissez pas P3P ?
- Mathieu O'Neil, « Internet, ou la fin de la vie privée », Le Monde diplomatique, septembre 1998, http://www.monde-diplomatique.fr/1998/09/O_NEIL/10914 - Marc Laimé, « Allons-nous devoir vendre nos données personnelles ? », uzine.net, octobre 2001, http://www.uzine.net/article1198.html - Platform for Privacy Preferences (P3P) Project, http://www.w3.org/P3P/ - P3P 1.0, traduction en français de J. Solari, http://www.yoyodesign.org/doc/w3c/p3p1/ (rechercher p3p ou carte ou card dans ces documents)
Thierry B.
--{ 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
--{ 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
de plus, le TLD ne peut (a ma connaissance) dépasser 5 caractères,
.museum ?
-- SuZE/Linux: première distribution sur bistrotwatch.com
Olivier Miakinen
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. ;-)
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. ;-)
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. ;-)
Thierry B.
--{ alainL a plopé ceci: }--
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...
-- <JX> je vais boire une adelscott <CleeK> jx : pareil pour moi <JX> et comme il ne faut JAMAIS boire le ventre vide <JX> je vais manger une Guinness avec
--{ alainL a plopé ceci: }--
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...
--
<JX> je vais boire une adelscott
<CleeK> jx : pareil pour moi
<JX> et comme il ne faut JAMAIS boire le ventre vide
<JX> je vais manger une Guinness avec
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...
-- <JX> je vais boire une adelscott <CleeK> jx : pareil pour moi <JX> et comme il ne faut JAMAIS boire le ventre vide <JX> je vais manger une Guinness avec
Olivier Miakinen
Le 28/07/2007 19:44, Nicolas Krebs a écrit :
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 ?)
Vous ne connaissez pas P3P ?
Non.
- Mathieu O'Neil, « Internet, ou la fin de la vie privée », Le Monde diplomatique, septembre 1998, http://www.monde-diplomatique.fr/1998/09/O_NEIL/10914 - Marc Laimé, « Allons-nous devoir vendre nos données personnelles ? », uzine.net, octobre 2001, http://www.uzine.net/article1198.html - Platform for Privacy Preferences (P3P) Project, http://www.w3.org/P3P/ - P3P 1.0, traduction en français de J. Solari, http://www.yoyodesign.org/doc/w3c/p3p1/ (rechercher p3p ou carte ou card dans ces documents)
Et si tu nous expliquais en deux mots de quoi il s'agit et quel rapport ça a avec la question posée, plutôt que de nous envoyer sur Internet ?
Le 28/07/2007 19:44, Nicolas Krebs a écrit :
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 ?)
Vous ne connaissez pas P3P ?
Non.
- Mathieu O'Neil, « Internet, ou la fin de la vie privée »,
Le Monde diplomatique, septembre 1998,
http://www.monde-diplomatique.fr/1998/09/O_NEIL/10914
- Marc Laimé, « Allons-nous devoir vendre nos données personnelles ? »,
uzine.net, octobre 2001, http://www.uzine.net/article1198.html
- Platform for Privacy Preferences (P3P) Project, http://www.w3.org/P3P/
- P3P 1.0, traduction en français de J. Solari,
http://www.yoyodesign.org/doc/w3c/p3p1/
(rechercher p3p ou carte ou card dans ces documents)
Et si tu nous expliquais en deux mots de quoi il s'agit et quel rapport
ça a avec la question posée, plutôt que de nous envoyer sur Internet ?
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 ?)
Vous ne connaissez pas P3P ?
Non.
- Mathieu O'Neil, « Internet, ou la fin de la vie privée », Le Monde diplomatique, septembre 1998, http://www.monde-diplomatique.fr/1998/09/O_NEIL/10914 - Marc Laimé, « Allons-nous devoir vendre nos données personnelles ? », uzine.net, octobre 2001, http://www.uzine.net/article1198.html - Platform for Privacy Preferences (P3P) Project, http://www.w3.org/P3P/ - P3P 1.0, traduction en français de J. Solari, http://www.yoyodesign.org/doc/w3c/p3p1/ (rechercher p3p ou carte ou card dans ces documents)
Et si tu nous expliquais en deux mots de quoi il s'agit et quel rapport ça a avec la question posée, plutôt que de nous envoyer sur Internet ?
ts
"T" == Thierry B writes:
T> Moi aussi, je pense que cette restriction a existé, mais je T> ne sais pas ce qu'elle est devenu. Foutou ?
RFC 1123
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.
En clair la 952 ne permettait pas d'avoir un chiffre comme premier caractère.
--
Guy Decoux
"T" == Thierry B <tth@prout.stex> writes:
T> Moi aussi, je pense que cette restriction a existé, mais je
T> ne sais pas ce qu'elle est devenu. Foutou ?
RFC 1123
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
En clair la 952 ne permettait pas d'avoir un chiffre comme premier
caractère.
T> Moi aussi, je pense que cette restriction a existé, mais je T> ne sais pas ce qu'elle est devenu. Foutou ?
RFC 1123
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.
En clair la 952 ne permettait pas d'avoir un chiffre comme premier caractère.
--
Guy Decoux
ts
"P" == Pascal Hambourg writes:
P> Cette restriction ne s'appliquait qu'aux noms d'hôtes, pas aux P> domaines de courrier.
Depuis quand un nom d'hôte ne peut pas être un domaine de courrier ?
P> Cette restriction ne s'appliquait qu'aux noms d'hôtes, pas aux P> domaines de courrier.
Depuis quand un nom d'hôte ne peut pas être un domaine de courrier ?
--
Guy Decoux
ts
"P" == Pascal Hambourg writes:
P> Pose plutôt la question dans le bon sens : depuis quand un domaine de P> courrier doit-il être un nom d'hôte ?
Si il existe une restriction sur un nom d'hôte alors cette restriction existe sur un domaine de courrier parce qu'un nom d'hôte peut être un domaine de courrier.
P> Pose plutôt la question dans le bon sens : depuis quand un domaine de
P> courrier doit-il être un nom d'hôte ?
Si il existe une restriction sur un nom d'hôte alors cette restriction
existe sur un domaine de courrier parce qu'un nom d'hôte peut être un
domaine de courrier.
P> Pose plutôt la question dans le bon sens : depuis quand un domaine de P> courrier doit-il être un nom d'hôte ?
Si il existe une restriction sur un nom d'hôte alors cette restriction existe sur un domaine de courrier parce qu'un nom d'hôte peut être un domaine de courrier.
