Hi folks, On 22/06/2013 17:33, Emmanuel Thierry wrote: > > Le 22 juin 2013 à 16:13, Eric Faurot <[email protected]> a écrit : >> >> What happens here is that there is a mail to be sent to a certain >> domain, the MTA resolves the MX list, which turns out to contain an >> IPv6 and IPv4 address. It starts a new connection on the first, and, >> after a while, on the second. The idea is that if the second is >> reachable immediatly, we don't have to wait for the first one to >> timeout if we can send the message on the second. So after having >> sent the message the second connection closes since there is nothing >> left to do. And later, the first connection attempts times out. >> > > By the way it's not far from what is proposed by the RFC 6555: > http://www.rfc-editor.org/rfc/rfc6555.txt. > There exists a very good explanation of this RFC and the reasons to do that > by Stéphane Bortzmeyer (for french speakers): > http://www.bortzmeyer.org/6555.html >
By the way, this article (from the same author) may interest you: https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong It shows how many RIPE atlas probes owners (https://atlas.ripe.net/), who are excepted to operate well managed networks, have a broken IPv6 connectivity: 10%. And on top of those 10%, 2/3 are not getting any error messages (ICMPv6...) and are just timeouting, before eventually failling back to IPv4 after numerous tries. Thus, it's pretty nice to know that opensmtpd will not suffers any issues on this kind of setup :). -- Mathieu Goessens
signature.asc
Description: OpenPGP digital signature
