* Jeroen Massar:
Florian Weimer wrote:
Hi,
is there any document that contrasts RFC 3974 with the real world?
No, because that setup works perfectly well. Do you have reason to believe that it doesn't?
Yes, real-world experiments with v6-enabled MX hosts which send and receive significant volumes of mail flatly contradict this document. The last DNS example in Section 2 breaks sender domain verification in Sendmail 8.12 (and others).
try to create a set of MX RRs which includes an IPv6 MX host, does not negatively impact reachability from v4-only hosts (or v6-enabled hosts without v6 connectivity), prefers v6 over v4 when possible, and does not waste any IPv4 addresses.
Then do it like described in the above RFC.
I did, it doesn't work.
This is what I've come up with so far:
deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de.
v6.mail.enyo.de. 172800 IN A 212.9.189.167 v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 v4.mail.enyo.de. 172800 IN A 212.9.189.167
This will (normally) never hit v4.mail.enyo.de as the SMTP client will try v6.mail.enyo.de IPv6's address, if that connect fails it will try v6.mail.enyo.de's IPv4 address.
In the world, different things happened because AAAA records can mask the existence of A records. Sure, it's a bug, but I would expect that
The A RR of v6.mail is necessary because some broken anti-spam checks reject mail from deneb.enyo.de if they cannot find an A record for the primary MX.
Blame the broken implementation. Not much you can do about except contacting them to fix their setup.
I wish publish DNS which is as conservative as possible, while still enabling IPv6. This shouldn't be impossible. If it is, we simply need some other transition mechanism. If I must choose between "SMTP over IPv6" and "reliable Internet mail", my choice is clear, and most people will share my preferences.
Then those implementations are wrong and need to be fixed.
Sure, but the ETA for that fix on real machines is mid-2007 to the end of 2008, and these estimates only deal with one piece of software (Exim in Debian). The other requirement (for interoperability, the primary MX MUST have an A record) is not amenable to a fix because it is rather widely implemented and not clearly a bug.
Thus simply use the following as in the RFC:
There are several examples in that RFC, and I've tried most of them.
deneb.enyo.de. MX 10 mx1.enyo.de. deneb.enyo.de. MX 20 mx2.enyo.de.
mx1.enyo.de. A 212.9.189.167 AAAA 2001:14b0:202:1::a7 mx2.enyo.de. A <second mx's IPv4 address> AAAA <second mx's IPv6 address>
Doesn't work, it suffers from the same AAAA-masks-A problem I mentioned.
Correct implementations
Real-world implementations behave differently, I'm afraid. And in the end, I receive my mail from real-world implementations which are not necessarily completely correct.
This works flawlessly.
No, it doesn't.
If there is an implementation/setup that doesn't work with the above setup then contact them to let them fix it.
Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests itself even if there is no working IPv6 connectivity. It has been gradually introduced to the general mail server population since mid-2004, and since June 2005, there should be a measurable number of hosts affected by it.