[ipv6-wg] Real-world IPv6 SMTP experience

* 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.