MOOC qui au demeurant est fait par des gens très compétents, donc à recommander vivement !
J’en profite pour te demander comment tu fais pour avoir un DNS IPv6 à jour avec une freebox ? Sur mon serveur, toutes les IPv6 ont un lifetime d’un jour. Malgré une IPv4 fixe.
Le lifetime annoncé par ta box est d’un jour, mais est-ce que pour autant ton préfixe change ?
Personnellement je n’ai jamais vu mes préfixes IPv6 changer chez Free. Ensuite il suffit de fixer des IP statiques sur les machines à l’intérieur de son réseau et c’est terminé.
Le préfixe est le même ! Je m’en suis statiquement donné une dans le range et j’ai de la connectivité via cette IP 
Merci à vous
1 « J'aime »
Ok, tant mieux.
Par contre pour du mail il faut bien faire attention à configurer le MTA pour qu’il utilise l’IPv6 statique comme IP de sortie, parce que s’il y a des IPv6 temporary autoconfigurées sur l’interface, ce sera celles là qui seront utilisées par défaut pour le trafic sortant.
1 « J'aime »
Ah oui merci, je vais configurer ça 
Et tu risques de te faire re-toquer ton email IPv6 à pas mal d’endroits parce qu’il n’a pas de reverse DNS, et tu n’as pas moyen de le configurer chez Free (tu as seulement rDNS IPv4). Typiquement tu vas avoir le problème chez Gandi et Gmail au moins, du coup nous on reçoit en IPv6 mais on envoie en IPv4 car on peut pas savoir à l’avance ce que le serveur va penser de notre IPv6. Pour référence
Edit : voici des élements de contexte copié/collé de notre discussion, c’est pas de moi, je cite des gens, mais je ne sais pas si j’ai le droit de les créditer pour leur vie privée >< Arf c’est compliqué…
Le refus chez Gandi (semblable chez gmail de mémoire) :
host spool.mail.gandi.net[2001:4b98:e00::1]
said: 550 5.7.1 Client host rejected: cannot find your reverse hostname,
[2a01:e0a:28f:5e60::12] (in reply to RCPT TO command)
Il y a une issue chez Free pour le rDNS IPv6 mais elle est déjà bien bien bien pleine : FS#12749 : Personnalisation/Délégation reverse IPv6
L’idéal serait d’héberger nous-mêmes la zone DNS inverse. Pour ça il faut un FAI qui accepte de le faire, typiquement ceux qu’on trouve chez FFDN sont des bons candidats. Il suffirait alors de demander à ce FAI de déléguer le reverse DNS de notre préfixe vers nos serveurs DNS : ce serait une seule demande à faire qui serait valable pour toutes les IPv6 et futurs changements.
Et @n-peugnet, je suis en train de passer chez fdn.fr, je pourrai te dire comment ça se passe sur ce point. Et sur le chan infra de Deuxfleurs, normalement il y a des personnes de FFDN (au moins Aquilenet). En gros depuis quelques temps, c’est possible d’avoir une offre fibre sur (toute ?) la France Métropolitaine via un (petit) FAI associatif grâce aux offres activées dites « bitstream », donc tu es très probablement éligible. Voilà des assos qui en proposent à ma connaissance : FDN, Aquilenet, Rezine ou Milkywan. Ensuite, chez FDN, la délégation d’une zone inverse IPv6 est documentée dans leur page délégation dns de leur wiki.
2 « J'aime »
Ah, dans notre cas on a de rDNS ni en IPv4 ni en IPv6 et on envoie avec les deux et pas de problème avec gmail.com. j’ai pas encore vu pour Gandi, par contre on se fait tej par email.com, mais je soupçonne que ce soit des adresses mal tapées.
Franchement ceux qui rejettent les emails à cause du rDNS abusent vraiment, c’est carrément de la complicité entre gros hébergeurs au bout d’un moment vu à quel point c’est galère de juste pouvoir le configurer.
Mais bon ça reste quand-même un point sur lequel on pourrait améliorer notre service e-mail.
Oui c’est ce que je me disais aussi. Je vois pas trop d’autre solution pour IPv6.
Vous avez bien un rDNS IPv4, il n’est juste pas custom :
$ dig +short -x `dig +short A club1.fr`
31-39-157-76.abo.bbox.fr.
De mémoire, Gmail/Gandi s’accomodent d’un rDNS qui ne match pas ton domaine d’envoi, mais il veut un rDNS malgré tout.
Je ne vois pas de rDNS sur votre IPv6 par contre :
$ dig +short -x `dig +short AAAA club1.fr`
;; communications error to 127.0.0.53#53: timed out
Je suis donc surpris/curieux de savoir comment votre serveur arrive à livrer des emails en IPv6 chez Gandi/Gmail. Si vous avez des insights là dessus, ça nous sera bien utile 
Oui effectivement je n’avais pas fait cette distinction.
Ben écoute pour le moment je ne sais pas, ça fonctionne correctement depuis le début avec Gmail. Gandi c’est un peu plus difficile de savoir puisque c’est des domaines perso la plupart du temps. Pour l’instant j’ai juste fait un petit grep rapide pour voir et on envoie bien un petit paquet d’e-mail vers Gmail en IPv6 (plus qu’on en reçoit haha) :
$ sed -En 's/[a-zA-Z0-9.]*@gmail\.com/******@gmail.com/p' /var/log/mail.log
Sep 17 08:59:38 club1 postfix/smtp[1517287]: F001AB80327: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[66.102.1.27]:25, delay=1.5, delays=0.03/0.04/0.73/0.74, dsn=2.0.0, status=sent (250 2.0.0 OK 1694933978 r6-20020adfdc86000000b0031c7034fefcsi3293929wrj.806 - gsmtp)
Sep 17 17:38:19 club1 policyd-spf[1611002]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::e31; helo=mail-vs1-xe31.google.com; envelope-from=******@gmail.com; receiver=<UNKNOWN>
Sep 18 09:18:27 club1 postfix/smtp[1785754]: 947A0B802C0: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[66.102.1.26]:25, delay=1.1, delays=0.03/0.03/0.46/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 1695021507 j10-20020adfe50a000000b00311336c9893si2633179wrm.1079 - gsmtp)
Sep 18 14:30:03 club1 postfix/smtp[1849853]: 322B0B85C8D: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1b]:25, delay=1.2, delays=0.2/0.03/0.62/0.38, dsn=2.0.0, status=sent (250 2.0.0 OK 1695040203 v8-20020a5d43c8000000b0031ffd8d3f52si2733023wrr.174 - gsmtp)
Sep 18 19:22:14 club1 postfix/smtp[1914800]: 003F8B85EF8: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=1.5, delays=0.22/0.11/0.74/0.44, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057734 r12-20020adfce8c000000b0031ff20fa12dsi3942231wrn.989 - gsmtp)
Sep 18 19:22:14 club1 postfix/smtp[1914798]: F10B3B810ED: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=1.5, delays=0.2/0.08/0.76/0.47, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057734 m6-20020a7bca46000000b003fc08786b38si5743176wml.6 - gsmtp)
Sep 18 19:22:14 club1 postfix/smtp[1914801]: 02770B85EF9: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=1.7, delays=0.25/0.12/0.69/0.61, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057734 g3-20020a05600c308300b0040471d0b23csi5504808wmn.169 - gsmtp)
Sep 18 19:22:16 club1 postfix/smtp[1914806]: 9BD8FB85EF8: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=0.63, delays=0.08/0/0.1/0.45, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057736 u9-20020a05600c210900b003fe24cf012esi5746126wml.98 - gsmtp)
Sep 18 19:22:16 club1 postfix/smtp[1914808]: 9A910B810ED: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=0.84, delays=0.08/0/0.09/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057736 s7-20020a05600c318700b003f9d7ff24c9si5695191wmp.155 - gsmtp)
Sep 18 19:22:16 club1 postfix/smtp[1914884]: 269C8B85F11: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=0.84, delays=0.24/0.08/0.1/0.43, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057736 a8-20020a056000050800b0031437ee0120si4919027wrf.221 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914867]: 03B25B85F05: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=1.1, delays=0.18/0.06/0.12/0.72, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 a4-20020adffb84000000b0031f84cbf252si4736374wrr.659 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914921]: 53385B80405: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=0.82, delays=0.27/0.13/0.11/0.31, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 j2-20020adfff82000000b0031f9bdb79e3si2241787wrr.117 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914877]: 264E4B85F10: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[66.102.1.26]:25, delay=0.98, delays=0.18/0.06/0.18/0.56, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 p4-20020a05600c204400b00403cab5f2e4si6107252wmg.211 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914801]: 22145B85F0F: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[66.102.1.26]:25, delay=1.1, delays=0.21/0.06/0.19/0.68, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 k7-20020adfe3c7000000b0031800689addsi4747774wrm.52 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914926]: 795EBB85F1B: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[66.102.1.26]:25, delay=1, delays=0.24/0.21/0.09/0.49, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 q12-20020adff50c000000b0031771f5b613si4065486wro.276 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914884]: 7EC1CB85F1E: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=1.1, delays=0.24/0.25/0.09/0.5, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 a4-20020adffb84000000b00314113ad6e5si4707593wrr.647 - gsmtp)
Sep 18 19:22:17 club1 postfix/smtp[1914923]: 63572B85F04: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1a]:25, delay=1.3, delays=0.22/0.19/0.12/0.75, dsn=2.0.0, status=sent (250 2.0.0 OK 1695057737 u5-20020adff885000000b003180c1559adsi4355761wrp.884 - gsmtp)
Sep 19 09:56:16 club1 postfix/smtp[2090237]: 0B59AB861F6: to=<******@gmail.com>, relay=gmail-smtp-in.l.google.com[108.177.15.26]:25, delay=1.3, delays=0.11/0.03/0.65/0.54, dsn=2.0.0, status=sent (250 2.0.0 OK 1695110176 d4-20020a5d6444000000b0031ffa3836adsi4031940wrw.996 - gsmtp)
(oui bon ok c’est pas tant que ça par rapport à d’autres 
)
(oui je sais aussi que mon regex ne prend pas en compte toutes les adresses valides mais c’est pour se donner une idée)
1 « J'aime »
Merci d’avoir pris le temps de regarder 
On refera des tests alors 
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
2 « J'aime »
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 ?)
2 « J'aime »
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.