Skip to end of metadata
Go to start of metadata

You need to think through all the interactions before enabling IPv6 on a mail server.

Ket Crispin posted this to the IETF list:

I was presenting what I thought was an interesting example
of a subtle problem that can come up in ipv6 deployment.

The mailserver in question uses a default redhat enterprise
build (actually centos). ipv6 is either enabled by default,
or just has a single check box, with no further information.
The fact that ipv6 is enabled so trivially carries the implication
that just enabling ipv6 won't actually damage anything.

Now I know different. Just enabling ipv6 on an otherwise
correctly configured and functioning ipv4 box will cause
damage – it will cause mail that would have been delivered
to not be delivered. I could be wrong, but this strikes me
as a trap that lots of people could fall into.

As I mentioned, my servers actually do reject mail if they
can't find a reverse dns for the senders IP. Some of those
servers use ipv6; in light of all this I'm going to have
to rethink that decision. For a server, the combination of
enabling ipv6 and using this particular anti-spam technique may
drastically increase the number of false positives – especially
as ipv6 gets more widely deployed.

Paul Warren adds:

Google mail servers reject mail with no IPv6 reverse DNS.  This means that a) if you adopt this measure then you're in good company, and b) if you enable IPv6 on your mail server, then it's very important that you have working IPv6 reverse DNS.

When enabling IPv6 on a mail server, you need to consider all the places where you might have IP-based access restrictions in place, as even if you don't modify add any AAAA records to point at your server, it will start using IPv6 for outgoing connections.  One place to consider is SPF records for any domains for which your server sends mail.

  • No labels