Depuis quelques temps, certains MX demandent un reverse DNS valide pour
accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas
de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon
serveur SMTP, il ne me revoit rien.
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez
l'ISP qui fourni l'IP ?
Depuis quelques temps, certains MX demandent un reverse DNS valide pour accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon serveur SMTP, il ne me revoit rien. erffectivement..
perso j'ai fait un truc genre dig -tptr monip ou set q=ptr dans unb nsllop ou encore un host monip ;)
ne pas avoir de PTR est aussi un source de mise au RBL
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez l'ISP qui fourni l'IP ? yep, encore faut il que le FAI veuille bien vouloir modifier son DNS
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
On 2005-03-11, Stef <kury@free.fr> wrote:
Depuis quelques temps, certains MX demandent un reverse DNS valide pour
accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas
de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon
serveur SMTP, il ne me revoit rien.
erffectivement..
perso j'ai fait un truc genre dig -tptr monip ou set q=ptr dans unb
nsllop ou encore un host monip ;)
ne pas avoir de PTR est aussi un source de mise au RBL
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez
l'ISP qui fourni l'IP ?
yep, encore faut il que le FAI veuille bien vouloir modifier son DNS
Snarf
--
"L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un
voulant le defier "
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Depuis quelques temps, certains MX demandent un reverse DNS valide pour accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon serveur SMTP, il ne me revoit rien. erffectivement..
perso j'ai fait un truc genre dig -tptr monip ou set q=ptr dans unb nsllop ou encore un host monip ;)
ne pas avoir de PTR est aussi un source de mise au RBL
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez l'ISP qui fourni l'IP ? yep, encore faut il que le FAI veuille bien vouloir modifier son DNS
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Stef
yep, encore faut il que le FAI veuille bien vouloir modifier son DNS
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant à ma plage d'adresse les PTR ?
merciii
stef
yep, encore faut il que le FAI veuille bien vouloir modifier son DNS
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant
à ma plage d'adresse les PTR ?
yep, encore faut il que le FAI veuille bien vouloir modifier son DNS
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant à ma plage d'adresse les PTR ?
merciii
stef
Pascal
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant à ma plage d'adresse les PTR ?
C'est l'organisation qui a la délégation finale de la zone DNS inverse en in-addr.arpa. En général c'est le FAI, mais il peut aussi déléguer au client, soit directement dans le cas d'un bloc suffisamment gros (/24), soit indirectement grâce au mécanisme défini dans la RFC 2317. Par exemple, mon FAI m'a donné la délégation pour les zones inverses en ip6.int et ip6.arpa de mon bloc /48 IPv6.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant
à ma plage d'adresse les PTR ?
C'est l'organisation qui a la délégation finale de la zone DNS inverse
en in-addr.arpa. En général c'est le FAI, mais il peut aussi déléguer au
client, soit directement dans le cas d'un bloc suffisamment gros (/24),
soit indirectement grâce au mécanisme défini dans la RFC 2317. Par
exemple, mon FAI m'a donné la délégation pour les zones inverses en
ip6.int et ip6.arpa de mon bloc /48 IPv6.
--
Pascal
Vous pouvez me tutoyer.
Piège à spam : boite-a-spam@plouf.fr.eu.org
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant à ma plage d'adresse les PTR ?
C'est l'organisation qui a la délégation finale de la zone DNS inverse en in-addr.arpa. En général c'est le FAI, mais il peut aussi déléguer au client, soit directement dans le cas d'un bloc suffisamment gros (/24), soit indirectement grâce au mécanisme défini dans la RFC 2317. Par exemple, mon FAI m'a donné la délégation pour les zones inverses en ip6.int et ip6.arpa de mon bloc /48 IPv6.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Stef
Ok merci de cette info !
Rien a voir, mais tu routes de l'IPV6 sur internet ? Je pensais qu'ipv6 n'etait pas encore suffisament deployé pour ça !
merci ! stef
"" a écrit dans le message de news: d0s2n2$rjc$
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant à ma plage d'adresse les PTR ?
C'est l'organisation qui a la délégation finale de la zone DNS inverse en in-addr.arpa. En général c'est le FAI, mais il peut aussi déléguer au client, soit directement dans le cas d'un bloc suffisamment gros (/24), soit indirectement grâce au mécanisme défini dans la RFC 2317. Par exemple, mon FAI m'a donné la délégation pour les zones inverses en ip6.int et ip6.arpa de mon bloc /48 IPv6.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Ok merci de cette info !
Rien a voir, mais tu routes de l'IPV6 sur internet ? Je pensais qu'ipv6
n'etait pas encore suffisament deployé pour ça !
merci !
stef
"Pascal@plouf" <pascal@plouf.invalid> a écrit dans le message de news:
d0s2n2$rjc$1@biggoron.nerim.net...
Donc c'est l'ISP qui rentre dans la zone de recherche inversée
correspondant à ma plage d'adresse les PTR ?
C'est l'organisation qui a la délégation finale de la zone DNS inverse en
in-addr.arpa. En général c'est le FAI, mais il peut aussi déléguer au
client, soit directement dans le cas d'un bloc suffisamment gros (/24),
soit indirectement grâce au mécanisme défini dans la RFC 2317. Par
exemple, mon FAI m'a donné la délégation pour les zones inverses en
ip6.int et ip6.arpa de mon bloc /48 IPv6.
--
Pascal
Vous pouvez me tutoyer.
Piège à spam : boite-a-spam@plouf.fr.eu.org
Rien a voir, mais tu routes de l'IPV6 sur internet ? Je pensais qu'ipv6 n'etait pas encore suffisament deployé pour ça !
merci ! stef
"" a écrit dans le message de news: d0s2n2$rjc$
Donc c'est l'ISP qui rentre dans la zone de recherche inversée correspondant à ma plage d'adresse les PTR ?
C'est l'organisation qui a la délégation finale de la zone DNS inverse en in-addr.arpa. En général c'est le FAI, mais il peut aussi déléguer au client, soit directement dans le cas d'un bloc suffisamment gros (/24), soit indirectement grâce au mécanisme défini dans la RFC 2317. Par exemple, mon FAI m'a donné la délégation pour les zones inverses en ip6.int et ip6.arpa de mon bloc /48 IPv6.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Snarf
On 2005-03-11, Stef wrote:
Rien a voir, mais tu routes de l'IPV6 sur internet ? Je pensais qu'ipv6 n'etait pas encore suffisament deployé pour ça ! /me se concentre ..
/me est devin
/me pense que pascal est chez nerim comme moi ;)
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
On 2005-03-11, Stef <kury@free.fr> wrote:
Rien a voir, mais tu routes de l'IPV6 sur internet ? Je pensais qu'ipv6
n'etait pas encore suffisament deployé pour ça !
/me se concentre ..
/me est devin
/me pense que pascal est chez nerim comme moi ;)
Snarf
--
"L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un
voulant le defier "
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Rien a voir, mais tu routes de l'IPV6 sur internet ? Je pensais qu'ipv6 n'etait pas encore suffisament deployé pour ça ! /me se concentre ..
/me est devin
/me pense que pascal est chez nerim comme moi ;)
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Stef
/me pense que pascal est chez nerim comme moi ;) ca veut dire que vous faites de l'ipv6 de nerim à nerim, ou avec d'autres
fai qui route aussi l'ipv6, avec nerim ?
stef
/me pense que pascal est chez nerim comme moi ;)
ca veut dire que vous faites de l'ipv6 de nerim à nerim, ou avec d'autres
/me pense que pascal est chez nerim comme moi ;) ca veut dire que vous faites de l'ipv6 de nerim à nerim, ou avec d'autres
fai qui route aussi l'ipv6, avec nerim ?
stef
Snarf
On 2005-03-11, Stef wrote:
/me pense que pascal est chez nerim comme moi ;) ca veut dire que vous faites de l'ipv6 de nerim à nerim, ou avec d'autres
fai qui route aussi l'ipv6, avec nerim ? ça veux dire que nerim fourni de l'ipv6 si ton routeur/passerelle/whatever le
supporte et que tu as access au reseau ipv6 en general.
d'ailleurs faut que j'active tout ça sur mes serveurs;)
Snarf,
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
On 2005-03-11, Stef <kury@free.fr> wrote:
/me pense que pascal est chez nerim comme moi ;)
ca veut dire que vous faites de l'ipv6 de nerim à nerim, ou avec d'autres
fai qui route aussi l'ipv6, avec nerim ?
ça veux dire que nerim fourni de l'ipv6 si ton routeur/passerelle/whatever le
supporte et que tu as access au reseau ipv6 en general.
d'ailleurs faut que j'active tout ça sur mes serveurs;)
Snarf,
--
"L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un
voulant le defier "
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
/me pense que pascal est chez nerim comme moi ;) ca veut dire que vous faites de l'ipv6 de nerim à nerim, ou avec d'autres
fai qui route aussi l'ipv6, avec nerim ? ça veux dire que nerim fourni de l'ipv6 si ton routeur/passerelle/whatever le
supporte et que tu as access au reseau ipv6 en general.
d'ailleurs faut que j'active tout ça sur mes serveurs;)
Snarf,
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Pascal
Rien a voir, mais tu routes de l'IPV6 sur internet ?
Oui. Enfin, c'est plutôt mon FAI qui le route entre moi et le reste du monde, et je laisse ma passerelle le router sur mon réseau local. Moi, je ne fais qu'en profiter. :)
Je pensais qu'ipv6 n'etait pas encore suffisament deployé pour ça !
C'est certain que le déploiement d'IPv6 est encore limité. Quand il n'y a pas de connectivité directe en IPv6 natif entre deux réseaux, on peut toujours monter entre eux un tunnel IPv6 sur IPv4 à travers le réseau internet "classique". Les performances ne sont pas géniales mais c'est mieux que rien, on peut ainsi atteindre des réseaux IPv6 à situés à l'autre bout du monde. Mais la connectivité n'est pas tout, il reste aussi du travail pour rendre les logiciels compatibles IPv6.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Rien a voir, mais tu routes de l'IPV6 sur internet ?
Oui. Enfin, c'est plutôt mon FAI qui le route entre moi et le reste du
monde, et je laisse ma passerelle le router sur mon réseau local. Moi,
je ne fais qu'en profiter. :)
Je pensais qu'ipv6
n'etait pas encore suffisament deployé pour ça !
C'est certain que le déploiement d'IPv6 est encore limité. Quand il n'y
a pas de connectivité directe en IPv6 natif entre deux réseaux, on peut
toujours monter entre eux un tunnel IPv6 sur IPv4 à travers le réseau
internet "classique". Les performances ne sont pas géniales mais c'est
mieux que rien, on peut ainsi atteindre des réseaux IPv6 à situés à
l'autre bout du monde. Mais la connectivité n'est pas tout, il reste
aussi du travail pour rendre les logiciels compatibles IPv6.
--
Pascal
Vous pouvez me tutoyer.
Piège à spam : boite-a-spam@plouf.fr.eu.org
Rien a voir, mais tu routes de l'IPV6 sur internet ?
Oui. Enfin, c'est plutôt mon FAI qui le route entre moi et le reste du monde, et je laisse ma passerelle le router sur mon réseau local. Moi, je ne fais qu'en profiter. :)
Je pensais qu'ipv6 n'etait pas encore suffisament deployé pour ça !
C'est certain que le déploiement d'IPv6 est encore limité. Quand il n'y a pas de connectivité directe en IPv6 natif entre deux réseaux, on peut toujours monter entre eux un tunnel IPv6 sur IPv4 à travers le réseau internet "classique". Les performances ne sont pas géniales mais c'est mieux que rien, on peut ainsi atteindre des réseaux IPv6 à situés à l'autre bout du monde. Mais la connectivité n'est pas tout, il reste aussi du travail pour rendre les logiciels compatibles IPv6.
-- Pascal Vous pouvez me tutoyer. Piège à spam :
Dominique Blas
Bonjour,
Depuis quelques temps, certains MX demandent un reverse DNS valide pour accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon serveur SMTP, il ne me revoit rien.
Ce n'est pas tout à fait exact. Ce n'est pas le MX qui réclame quoi que ce soit ce sont les dispositifs antispam (en l'occurrence des listes noires) placés autour du serveur de courriels qui bloquent. Et ils ne bloquent pas particulièrement les IP sans reverse mais les IP possédant un reverse appartenant à une FAI. Exemple : *.abo.wanadoo.fr, *.free, etc. Pour ne pas être embêté, il est nécessaire et suffisant de ne pas avoir de reverse appartenant à ces domaines.
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez l'ISP qui fourni l'IP ?
Sur le serveur de noms du FAI lui-même car c'est lui qui pilote son adressage et donc les reverses associés.
db
Bonjour,
Depuis quelques temps, certains MX demandent un reverse DNS valide pour
accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas
de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon
serveur SMTP, il ne me revoit rien.
Ce n'est pas tout à fait exact.
Ce n'est pas le MX qui réclame quoi que ce soit ce sont les dispositifs
antispam (en l'occurrence des listes noires) placés autour du serveur de
courriels qui bloquent.
Et ils ne bloquent pas particulièrement les IP sans reverse mais les IP
possédant un reverse appartenant à une FAI.
Exemple : *.abo.wanadoo.fr, *.free, etc.
Pour ne pas être embêté, il est nécessaire et suffisant de ne pas avoir
de reverse appartenant à ces domaines.
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez
l'ISP qui fourni l'IP ?
Sur le serveur de noms du FAI lui-même car c'est lui qui pilote son
adressage et donc les reverses associés.
Depuis quelques temps, certains MX demandent un reverse DNS valide pour accepter l'envoi de mails (mesure antispam je presume). Et moi, je n'ai pas de reverse DNS valide. Typiquement, sur le domaine public, si je ping -a mon serveur SMTP, il ne me revoit rien.
Ce n'est pas tout à fait exact. Ce n'est pas le MX qui réclame quoi que ce soit ce sont les dispositifs antispam (en l'occurrence des listes noires) placés autour du serveur de courriels qui bloquent. Et ils ne bloquent pas particulièrement les IP sans reverse mais les IP possédant un reverse appartenant à une FAI. Exemple : *.abo.wanadoo.fr, *.free, etc. Pour ne pas être embêté, il est nécessaire et suffisant de ne pas avoir de reverse appartenant à ces domaines.
Mais ou doit-etre declaré l'enregistrement neccessaire au reverse DNS, chez l'ISP qui fourni l'IP ?
Sur le serveur de noms du FAI lui-même car c'est lui qui pilote son adressage et donc les reverses associés.
db
Jacques Caron
Salut,
On Fri, 11 Mar 2005 23:19:02 +0100, Dominique Blas wrote:
Ce n'est pas le MX qui réclame quoi que ce soit ce sont les dispositifs antispam (en l'occurrence des listes noires) placés autour du serveur de courriels qui bloquent.
Le MTA le plus courant (sendmail) intègre depuis longtemps des tests sur la reverse de l'originateur de la connexion. Je suppose que c'est le cas des autres aussi, d'ailleurs.
Et ils ne bloquent pas particulièrement les IP sans reverse mais les IP possédant un reverse appartenant à une FAI.
Certains bloquent ou peuvent être configurés pour bloquer des connexions depuis des IP sans reverse ou dont le reverse "n'existe pas" (i.e. le nom donné dans le PTR ne peut être résolu), ou encore dont le reverse ne repointe pas sur la même IP (mais là ça pose beaucoup de problèmes).
Je vous conseille par exemple les lignes suivantes d'un sendmail.cf relativement standard (dans SRelay_ok): R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily denied. Cannot resolve PTR record for " $&{client_addr} R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP name possibly forged " $&{client_name} R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP name lookup failed " $&{client_name}
Exemple : *.abo.wanadoo.fr, *.free, etc.
Heureusement pour eux dans la plupart des cas ce n'est pas du tout en se basant sur le nom de domaine mais sur l'appartenance de l'IP à certains pools qu'ils se basent.
Pour ne pas être embêté, il est nécessaire et suffisant de ne pas avoir de reverse appartenant à ces domaines.
Et ne pas avoir une IP dans un pool dialup, et ne pas être sur une RBL, et avoir une reverse, et avoir une reverse qui existe, et de préférence qui repointe sur la même adresse...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Fri, 11 Mar 2005 23:19:02 +0100, Dominique Blas <db@internet.invalid>
wrote:
Ce n'est pas le MX qui réclame quoi que ce soit ce sont les dispositifs
antispam (en l'occurrence des listes noires) placés autour du serveur de
courriels qui bloquent.
Le MTA le plus courant (sendmail) intègre depuis longtemps des tests sur
la reverse de l'originateur de la connexion. Je suppose que c'est le cas
des autres aussi, d'ailleurs.
Et ils ne bloquent pas particulièrement les IP sans reverse mais les IP
possédant un reverse appartenant à une FAI.
Certains bloquent ou peuvent être configurés pour bloquer des connexions
depuis des IP sans reverse ou dont le reverse "n'existe pas" (i.e. le nom
donné dans le PTR ne peut être résolu), ou encore dont le reverse ne
repointe pas sur la même IP (mais là ça pose beaucoup de problèmes).
Je vous conseille par exemple les lignes suivantes d'un sendmail.cf
relativement standard (dans SRelay_ok):
R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily
denied. Cannot resolve PTR record for " $&{client_addr}
R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP name
possibly forged " $&{client_name}
R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP name
lookup failed " $&{client_name}
Exemple : *.abo.wanadoo.fr, *.free, etc.
Heureusement pour eux dans la plupart des cas ce n'est pas du tout en se
basant sur le nom de domaine mais sur l'appartenance de l'IP à certains
pools qu'ils se basent.
Pour ne pas être embêté, il est nécessaire et suffisant de ne pas avoir
de reverse appartenant à ces domaines.
Et ne pas avoir une IP dans un pool dialup, et ne pas être sur une RBL, et
avoir une reverse, et avoir une reverse qui existe, et de préférence qui
repointe sur la même adresse...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Fri, 11 Mar 2005 23:19:02 +0100, Dominique Blas wrote:
Ce n'est pas le MX qui réclame quoi que ce soit ce sont les dispositifs antispam (en l'occurrence des listes noires) placés autour du serveur de courriels qui bloquent.
Le MTA le plus courant (sendmail) intègre depuis longtemps des tests sur la reverse de l'originateur de la connexion. Je suppose que c'est le cas des autres aussi, d'ailleurs.
Et ils ne bloquent pas particulièrement les IP sans reverse mais les IP possédant un reverse appartenant à une FAI.
Certains bloquent ou peuvent être configurés pour bloquer des connexions depuis des IP sans reverse ou dont le reverse "n'existe pas" (i.e. le nom donné dans le PTR ne peut être résolu), ou encore dont le reverse ne repointe pas sur la même IP (mais là ça pose beaucoup de problèmes).
Je vous conseille par exemple les lignes suivantes d'un sendmail.cf relativement standard (dans SRelay_ok): R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily denied. Cannot resolve PTR record for " $&{client_addr} R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP name possibly forged " $&{client_name} R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP name lookup failed " $&{client_name}
Exemple : *.abo.wanadoo.fr, *.free, etc.
Heureusement pour eux dans la plupart des cas ce n'est pas du tout en se basant sur le nom de domaine mais sur l'appartenance de l'IP à certains pools qu'ils se basent.
Pour ne pas être embêté, il est nécessaire et suffisant de ne pas avoir de reverse appartenant à ces domaines.
Et ne pas avoir une IP dans un pool dialup, et ne pas être sur une RBL, et avoir une reverse, et avoir une reverse qui existe, et de préférence qui repointe sur la même adresse...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
