De mon côté, je me suis en effet fait jeter par GMail si j’utilisais du IPv6 sans rDNS, et ce dès le premier mail (je suis en solo sur le domaine concerné)
Un mauvais PTR n’est pas grave si le reste est bon (nom du serveur avec une résolution au niveau des DNS, DKIM, DMARC, SPF)
L’absence de PTR est par contre bloquant.
J’ai le soucis d’absences de PTR par les serveurs de Free.fr quand le serveur est derrière une connexion fibre de Free.fr.
Aucun soucis pour les autres serveurs.
Il est normal d’être bloqué par défaut dans les RBL avec les connexions via une IP domiciliaire. Il y a un formulaire automatique chez Spamhaus pour déclarer qu’on utilise un serveur mail avec l’IP, c’est à faire une fois par an en principe.
Note que les PTR avec les noms de domaines de Free, dans l’interface, fonctionnent si on interroge les DNS de Free.fr.
Depuis hier le rDNS est réparé en IPv4 chez free. Il semblerait que ce soit dut a une correction différente qui ai fait retomber en marche la fonctionnalité.
le ticket chez free: FS#26772 : Le REVERSE DNS ne fonctionne pas
Une explication: Framapiaf
J’ai regardé un peu plus en détail et il semble qu’on se fasse tout de même rejeter par quelques serveurs en IPv6 à cause de la non-existence du PTR (en plus de gmx.net en IPv4 à cause du PTR incorrect) :
$ zgrep -iE ': host .*(reverse|ptr|dns)' /var/log/mail.log.4.gz
Aug 27 00:18:41 club1 postfix/smtp[2258641]: 60B6CB88703: host mx01.gmx.net[212.227.17.4] refused to talk to me: 554-gmx.net (mxgmx106) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://postmaster.gmx.net/de/case?c=r0601&i=ip&v=31.39.157.76&r=1M1bUJ-1qXXZq3pHv-00FaAP
[...]
Aug 28 18:18:44 club1 postfix/smtp[2723044]: 60B6CB88703: host mx01.gmx.net[212.227.17.4] refused to talk to me: 554-gmx.net (mxgmx107) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://postmaster.gmx.net/de/case?c=r0601&i=ip&v=31.39.157.76&r=1M8jZB-1qfLuv3R33-004jNx
Aug 29 02:16:41 club1 postfix/smtp[2811970]: F27F0B85E82: host route1.mx.cloudflare.net[2606:4700:f5::c] refused to talk to me: 550 Sender IP reverse lookup rejected (2001:861:38c4:8d30::3).
Aug 29 02:16:42 club1 postfix/smtp[2812027]: 5C51BB86BFE: host route3.mx.cloudflare.net[2606:4700:f5::12] refused to talk to me: 550 Sender IP reverse lookup rejected (2001:861:38c4:8d30::3).
Aug 29 02:16:42 club1 postfix/smtp[2812027]: 5C51BB86BFE: host route3.mx.cloudflare.net[2606:4700:f5::13] refused to talk to me: 550 Sender IP reverse lookup rejected (2001:861:38c4:8d30::3).
Aug 30 15:58:52 club1 postfix/smtp[3225263]: EC1F5B8B03B: host route1.mx.cloudflare.net[2606:4700:f5::c] refused to talk to me: 550 Sender IP reverse lookup rejected (2001:861:38c4:8d30::3).
Aug 31 21:57:04 club1 postfix/smtp[107043]: 21A07B85E64: host efeu.mur.at[2a02:3e0::42] said: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:861:38c4:8d30::3] (in reply to RCPT TO command)
Le reverse ipv6 est toujours cassé chez free. Je crois que Aeris essaye de faire bouger un peu en interne pour que ce soit réparé (il travail chez Illiad et fait aussi de l’autohébergement )
Je ne serai pas aussi certain. Ce matin encore j’ai eu le problème, un PTR présent mais la résolution n’est pas bonne (=pas l’ip de provenance). Et qui bloque en face ? Free… le comble pour l’opérateur, chez qui c’est compliquer de modifier son PTR.
(delivery temporarily suspended: host mx2.free.fr[212.27.42.58] refused to talk to me: 421 Refused. Your reverse DNS entry does not resolve to your IP.)
David
Il y a une différence entre « ne résout pas », et « ne correspond pas ».
Là, typiquement, les serveurs SMTP de Free n’arrivent pas à effectuer le reverse, et le résultat est vide.
D’autre part, j’ai essayé d’utiliser le reverse non personnalisé de mon IP, et sur https://scanmy.email/ le résultat est pire que d’avoir un reverse qui ne correspond pas.
Le résultat n’est pas vide pour le coup, il est mauvais.
« your reverse DNS entry does not resolve to your IP. » pour moi c’est « votre entrée DNS inversée ne correspond pas à votre adresse IP. »
Moi je comprends qu’il parvient a résoudre (et c’est le cas, il y a bien un PTR) mais qui est mauvais / ne correspond pas…
Pour moi le message SMTP (pour une fois), dans ce que j’en comprend correspond à la réalité et me fait dire qu’une mauvais PTR est préjudiciable pour du mail.
David
Je confirme qu’on se fait bien jeter par Gandi en IPv6 à cause du PTR non présent :
host spool.mail.gandi.net[2001:4b98:e00::1] said: 550 5.7.1 Client host rejected: cannot find ur reverse hostname, [2001:861:38c4:8d30::3] (in reply to RCPT TO command)
Par contre par rapport à cette conf postfix, elle dépend visiblement de ce bloc du fichier master.cf
. Donc en gros l’idée dans votre cas c’est surtout de régler l’option inet_protocols
sur ipv4
.
Je suis tombé sur l’option smtp_address_preference
qui je pense me convient plus :
The address type (« ipv6 », « ipv4 » or « any ») that the Postfix SMTP client will try first, when a destination has IPv6 and IPv4 addresses with equal MX preference. This feature has no effect unless the inet_protocols setting enables both IPv4 and IPv6.
Postfix SMTP client address preference has evolved. With Postfix 2.8 the default is « ipv6 »; earlier implementations are hard-coded to prefer IPv6 over IPv4.
Ça permettrait de tout de même avoir la capacité de contacter des serveurs IPv6 only au cas où.
Edit: Ah en lisant le reste de la description de cette option il y a ça :
The setting « smtp_address_preference = ipv4 » is not a solution for remote servers that flag email received over IPv6 as more ‹ spammy › (the client IPv6 address has a bad or missing PTR or AAAA record, bad network neighbors, etc.). Instead, configure Postfix to receive mail over both IPv4 and IPv6, and to deliver mail over only IPv4.
/etc/postfix/main.cf: inet_protocols = all /etc/postfix/master.cf smtp ...other fields... smtp -o inet_protocols=ipv4
Donc en fait ce que vous avez fait chez DeuxFleurs , mais j’ai quand même envie de tester ce que ça donne avec ce réglage.
(bon désolé je dérive beaucoup sur les e-mail et des confs de postfix, mais en même temps à quoi sert le rDNS à part pour les e-mails ?)
Bonjour,
finalement, après avoir mis en place un VPN et configuré les routes pour y faire passer les emails à destination de Free.fr (et je pourrai en ajouter d’autres par la suite), les emails ont bien été accepté en provenance d’une IP de SFR avec un PTR qui ne correspond pas à l’IP.
Donc, mon hypothèse comme quoi les serveurs SMTP de Free.fr n’arrivent pas à obtenir le reverse (même mauvais) quand les emails proviennent d’un serveur derrière une ligne Fibre Free.fr, ce qui est différent de juste un mauvais reverse.