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 ?
J> Je vous conseille par exemple les lignes suivantes d'un sendmail.cf J> relativement standard (dans SRelay_ok): J> R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily J> denied. Cannot resolve PTR record for " $&{client_addr} J> R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP J> name possibly forged " $&{client_name} J> R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP J> name lookup failed " $&{client_name}
Euh si je ne me trompe pas ce test correspond à un test de relai, ce n'est pas le test qui était indiqué.
Certaines bécanes sont en effet configurées pour refuser des messages (à délivrer localement) si le client n'a pas de reverse ou si les 2 enregistrements du DNS ne correspondent pas et c'est nullement en standard dans sendmail. Pour la simple raison qu'une grande partie des serveurs SMTP n'ont pas un enregistrement correct : la gestion du DNS étant catastrophique.
--
Guy Decoux
[[ followup sur fcms ]]
"J" == Jacques Caron <jc@imfeurope.com> writes:
J> Je vous conseille par exemple les lignes suivantes d'un sendmail.cf
J> relativement standard (dans SRelay_ok):
J> R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily
J> denied. Cannot resolve PTR record for " $&{client_addr}
J> R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP
J> name possibly forged " $&{client_name}
J> R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP
J> name lookup failed " $&{client_name}
Euh si je ne me trompe pas ce test correspond à un test de relai, ce n'est
pas le test qui était indiqué.
Certaines bécanes sont en effet configurées pour refuser des messages (à
délivrer localement) si le client n'a pas de reverse ou si les 2
enregistrements du DNS ne correspondent pas et c'est nullement en standard
dans sendmail. Pour la simple raison qu'une grande partie des serveurs
SMTP n'ont pas un enregistrement correct : la gestion du DNS étant
catastrophique.
J> Je vous conseille par exemple les lignes suivantes d'un sendmail.cf J> relativement standard (dans SRelay_ok): J> R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily J> denied. Cannot resolve PTR record for " $&{client_addr} J> R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP J> name possibly forged " $&{client_name} J> R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP J> name lookup failed " $&{client_name}
Euh si je ne me trompe pas ce test correspond à un test de relai, ce n'est pas le test qui était indiqué.
Certaines bécanes sont en effet configurées pour refuser des messages (à délivrer localement) si le client n'a pas de reverse ou si les 2 enregistrements du DNS ne correspondent pas et c'est nullement en standard dans sendmail. Pour la simple raison qu'une grande partie des serveurs SMTP n'ont pas un enregistrement correct : la gestion du DNS étant catastrophique.
--
Guy Decoux
Dominique Blas
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.
C'est vrai et les autres aussi. A l'époque où je << jouais >> avec Sendmail j'avais constaté que ce dernier effectuait une vérification en boucle, ce qui est très bien au passage : partant de l'adresse IP il prenait le reverse puis vérifiait que le nom correspondait bien à l'adresse IP d'origine.
Mais ça se désactive et je me demande bien quelle est la proportion de MTA configurés ainsi car 1. je pense que cela excluerait ainsi d'emblée bon nombre d'autres MTA légitimes ! En effet, un petit audit montre rapidement que bien souvent IP => reverse et reverse => IP' != IP 2. mon expérience personnelle, en 2004, montre que même sans reverse seuls 0,02% des courriels sont refusés (et il s'agissait d'universités françaises).
2 raisons pour lesquelles je n'ai pas évoqué ce type de configuration pourtant bien raisonnable mais halas inapplicable de nos jours.
En parlant du protocole SMTP maintenant, il en va de même des Hellos qui ne respectent pas toujours la syntaxe d'un nom de domaine du type a.b (genre XRVEXCH pour un serveru Exchange) ce qui interdit de filtrer sur ce genre de comportement. Il y a également d'autres non-respects des RFC de la part de nombre de MTA pourtant légitimes ce qui empêche de disposer de règles antispam d'enveloppe strictes. Mais c'est un autre sujet.
[...]
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.
Je ne pense vraiment pas pour 2 raisons : 1. la partie haute du reverse est constante et facile à découvrir alors que des pools il s'en ajoute tous les jours chez les grands FAI : très difficile à découvrir et à maintenir pour un administrateur ;
2. mon expérience personnelle : je figure sur un vieux pool de dialup de Free (*) et dispose d'un reverse perso et n'ai jamais été bloqué par un FAI tel que AOL ou club-internet (je touche du bois) alors que d'autres abonnés de Free (n'apportenant pas au même pool il est vrai) le sont régulièrement.
Bien entendu ceci est vrai aujourd'hui. Il peut en être différemment dans 1 mois, 6 mois ou 2 ans ou pour d'autres fournisseurs mais la raison 1 fait qu'il y a peu de chance. Et je parle même pas d'IPv6 !
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...
Dans ce post je n'évoquais que le cas de refus de réception d'un FAI. C'est vrai que j'ai éludé le cas de l'abonné ne possédant pas de reverse mais j'ai failli écrire que cela était extrêmement rare de nos jours chez un FAI grand public. Mais il est vari courant chez un FAI tel que, par exemple, Complétel qui s'obstine à croire qu'un reverse n'est nécessaire que lorsqu'on héberge un site Web (d'où le 0,02% de tout à l'heure); mais bon, c'est normal après tout ce sont des téléphonistes pas des gens de l'Internet.
Enfin, peu de grands FAI français pratique le RBL à ma connaissance tout bonnement parce que peu de ces FAI propose l'antispam. Free a probablement commencé à le faire depuis la mise en route de son antispam mais Wanadoo j'en joute. Enfin c'est une suppositino je n'ai pas refait d'audit en ce sens depuis 2 ans.
db
(*) Il figure encore en tant que tel dans des vieilles RBL.
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.
C'est vrai et les autres aussi. A l'époque où je << jouais >> avec
Sendmail j'avais constaté que ce dernier effectuait une vérification en
boucle, ce qui est très bien au passage :
partant de l'adresse IP il prenait le reverse puis
vérifiait que le nom correspondait bien à l'adresse IP d'origine.
Mais ça se désactive et je me demande bien quelle est la proportion de
MTA configurés ainsi car
1. je pense que cela excluerait ainsi d'emblée bon nombre d'autres MTA
légitimes ! En effet, un petit audit montre rapidement que bien souvent
IP => reverse et reverse => IP' != IP
2. mon expérience personnelle, en 2004, montre que même sans reverse
seuls 0,02% des courriels sont refusés (et il s'agissait d'universités
françaises).
2 raisons pour lesquelles je n'ai pas évoqué ce type de configuration
pourtant bien raisonnable mais halas inapplicable de nos jours.
En parlant du protocole SMTP maintenant, il en va de même des Hellos qui ne
respectent pas toujours la syntaxe d'un nom de domaine
du type a.b
(genre XRVEXCH pour un serveru Exchange) ce qui interdit de filtrer sur
ce genre de comportement.
Il y a également d'autres non-respects des RFC de la part de nombre de
MTA pourtant légitimes ce qui empêche de disposer de règles antispam
d'enveloppe strictes. Mais c'est un autre sujet.
[...]
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.
Je ne pense vraiment pas pour 2 raisons :
1. la partie haute du reverse est constante et facile à
découvrir alors que des pools
il s'en ajoute tous les jours chez les grands FAI : très
difficile à découvrir et à maintenir pour un administrateur ;
2. mon expérience personnelle : je figure sur un vieux pool de
dialup de Free (*) et dispose d'un reverse perso et n'ai jamais
été bloqué par un FAI tel que AOL ou club-internet (je touche du
bois)
alors que d'autres abonnés de Free (n'apportenant pas au même
pool il est vrai) le sont régulièrement.
Bien entendu ceci est vrai aujourd'hui. Il peut en être différemment
dans 1 mois, 6 mois ou 2 ans ou pour d'autres fournisseurs mais la
raison 1 fait qu'il y a peu de chance.
Et je parle même pas d'IPv6 !
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...
Dans ce post je n'évoquais que le cas de refus de réception d'un FAI.
C'est vrai que j'ai éludé le cas de l'abonné ne possédant pas de reverse
mais j'ai failli écrire que cela était extrêmement rare de nos jours
chez un FAI grand public.
Mais il est vari courant chez un FAI tel que, par exemple, Complétel qui
s'obstine à croire qu'un reverse n'est nécessaire que lorsqu'on héberge
un site Web (d'où le 0,02% de tout à l'heure); mais bon, c'est normal
après tout ce sont des téléphonistes pas des gens de l'Internet.
Enfin, peu de grands FAI français pratique le RBL à ma connaissance tout
bonnement parce que peu de ces FAI propose l'antispam.
Free a probablement commencé à le faire depuis la mise en route de son
antispam mais Wanadoo j'en joute.
Enfin c'est une suppositino je n'ai pas refait d'audit en ce sens depuis
2 ans.
db
(*) Il figure encore en tant que tel dans des vieilles RBL.
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.
C'est vrai et les autres aussi. A l'époque où je << jouais >> avec Sendmail j'avais constaté que ce dernier effectuait une vérification en boucle, ce qui est très bien au passage : partant de l'adresse IP il prenait le reverse puis vérifiait que le nom correspondait bien à l'adresse IP d'origine.
Mais ça se désactive et je me demande bien quelle est la proportion de MTA configurés ainsi car 1. je pense que cela excluerait ainsi d'emblée bon nombre d'autres MTA légitimes ! En effet, un petit audit montre rapidement que bien souvent IP => reverse et reverse => IP' != IP 2. mon expérience personnelle, en 2004, montre que même sans reverse seuls 0,02% des courriels sont refusés (et il s'agissait d'universités françaises).
2 raisons pour lesquelles je n'ai pas évoqué ce type de configuration pourtant bien raisonnable mais halas inapplicable de nos jours.
En parlant du protocole SMTP maintenant, il en va de même des Hellos qui ne respectent pas toujours la syntaxe d'un nom de domaine du type a.b (genre XRVEXCH pour un serveru Exchange) ce qui interdit de filtrer sur ce genre de comportement. Il y a également d'autres non-respects des RFC de la part de nombre de MTA pourtant légitimes ce qui empêche de disposer de règles antispam d'enveloppe strictes. Mais c'est un autre sujet.
[...]
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.
Je ne pense vraiment pas pour 2 raisons : 1. la partie haute du reverse est constante et facile à découvrir alors que des pools il s'en ajoute tous les jours chez les grands FAI : très difficile à découvrir et à maintenir pour un administrateur ;
2. mon expérience personnelle : je figure sur un vieux pool de dialup de Free (*) et dispose d'un reverse perso et n'ai jamais été bloqué par un FAI tel que AOL ou club-internet (je touche du bois) alors que d'autres abonnés de Free (n'apportenant pas au même pool il est vrai) le sont régulièrement.
Bien entendu ceci est vrai aujourd'hui. Il peut en être différemment dans 1 mois, 6 mois ou 2 ans ou pour d'autres fournisseurs mais la raison 1 fait qu'il y a peu de chance. Et je parle même pas d'IPv6 !
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...
Dans ce post je n'évoquais que le cas de refus de réception d'un FAI. C'est vrai que j'ai éludé le cas de l'abonné ne possédant pas de reverse mais j'ai failli écrire que cela était extrêmement rare de nos jours chez un FAI grand public. Mais il est vari courant chez un FAI tel que, par exemple, Complétel qui s'obstine à croire qu'un reverse n'est nécessaire que lorsqu'on héberge un site Web (d'où le 0,02% de tout à l'heure); mais bon, c'est normal après tout ce sont des téléphonistes pas des gens de l'Internet.
Enfin, peu de grands FAI français pratique le RBL à ma connaissance tout bonnement parce que peu de ces FAI propose l'antispam. Free a probablement commencé à le faire depuis la mise en route de son antispam mais Wanadoo j'en joute. Enfin c'est une suppositino je n'ai pas refait d'audit en ce sens depuis 2 ans.
db
(*) Il figure encore en tant que tel dans des vieilles RBL.
