[ipv6-wg] Real-world IPv6 SMTP experience

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?

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

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

If v6.mail.enyo.de returns a 4xx then the client will try
v4.mail.enyo.de, which only has an IPv4 address.

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

> The v4.mail MX host is needed because some MTAs suppress
> A record lookup if they discover an AAAA record (even if there's no v6
> connectivity available).

Then those implementations are wrong and need to be fixed.

Thus simply use the following as in the RFC:

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>

Correct implementations will then first try mx1.enyo.de's IPv6 address,
if the IPv6 connect fails it will try mx1's IPv4. If mx1 gives 4xx it
will try mx2's IPv6, if that IPv6 connect fails it falls back to mx2's IPv4.

This works flawlessly. If there is an implementation/setup that doesn't
work with the above setup then contact them to let them fix it.

I haven't seen any issues with setups of the above form btw and I have
been running a A/AAAA setup for almost 4 years now on several domains.

Also note that you might want to have more than 1 physically separated
MX. If your sole machine now dies your mail will not be delivered.
Having a separated MX will allow it to be directly delivered at that
place and not entering queues at remote sites. Unless you loadbalance
and have a 99.999999999999999% SLA on the link to the internet of course.

Greets,
 Jeroen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/ipv6-wg/attachments/20051221/d35735c3/attachment.sig>