Oct 202012
Spend 30 minutes with IPv6 every Friday!

During the last year, I’ve been spending a large amount of my free time on moving my own servers and services to IPv6. I started with DNS, then the web sites and after that came E-mail. I added IPv6 to my Postfix servers, added new AAAA records in my DNS zone for the  email server that was already used in MX. And then I started looking at the logs. The first few mails over IPv6 where from IETF mailing lists. After that a mail server hosted by Patrik Fältström, TCP/IP and Internet guru. No surprises there. What surprised me was what came next – spam. My graylist software did not support IPv6, but I though I’ll take the risk and assumed that we where ahead of the spammers. Obviously not. Let’s talk IPv6, E-mail and spam!

IPv4 spamlist: Real time Black lists in DNS

In IPV4, almost all mail servers subscribe to a pay-for or free service that lists hosts that are known to be a source of spam in a DNS database. By doing a DNS lookup for every connection on the mail server, we check whether it’s a known spammer or not. Using DNS provides caching, distribution and much more. It’s a system that provides the first level filters for spam. It builds upon a lot of trust in the management of the DNS data. A badly managed blacklist can cause a lot of harm.

When moving to IPv6, the natural thing to do is to ask for the IPv6 versions of the blacklists in DNS. It seems like a very logical thing, moving the system from IPv4 to IPv6 – it’s just a longer address, but still an address. Yes, and No.

With IPv6 spammers, like everyone else, get a vast amount of addresses

When the spammers get IPv6 access, they do no longer get one address or just a few that are easy to block. They get millions. With a tiny bit of intelligence, they’ll find out that they can use one address per mail. If you block one address, they will already be using something completely different. To block that, we need very large DNS zones and very fast systems. Well, why not block subnets then? The risk of blocking something that is not used for spamming will be huge, and may cause more harm than it already does in the IPv4 mail world.

A presentation by an unknown person for IETF 83 discusses the problem in detail. It’s a very good presentation, so take a moment to go through it. An IETF draft document about e-mail migration to IPv6 points out that this is a chicken-and-egg problem. We don’t know anything before we actually deploy IPv6-email servers:

“The lack of a full understanding of all abuse threats SHOULD NOT preclude the adoption of IPv6 for mail. A comprehensive understanding of threats will not be available until implementation.”

The Register published an article in 2011 titled “IPv6 intro creates spam-filtering nightmare” by John Leyden that discussed the problem. Michael Kassner reacts on this article and asks around for more opinions in his article “IPv6 blacklisting: Will it be harder to fight spammers?” where some people recommend blocking whole subnets, others claim that blacklisting in DNS doesn’t work well in IPv4 either and it’s time to move on to new methods. Scott Hogg writes about the problem in NetworkWorld under the title “Should you allow inbound e-mail over IPv6?

In search of other ways to fight spam in IPv6

The realization that we can not fight spam in IPv6 the way we do in IPv4 has lead to two very separate ideas on how to handle it. The first one is obviously to try to solve it by moving to a more trusted system where e-mail servers has to identify themselves. The number of e-mail servers aren’t as big compared with the number of IP addresses. Applying DNSsec-based trust or old-fashioned TLS makes sense. With that we can verify the that an email server for a domain only sends mail it is authorized to send by the DNS zone. Graylisting has helped quite a lot too.

The other groups has come to the conclusion that coming up with a trustworthy solution for e-mail in IPv6 will take quite some time. So their line of thought is to keep e-mail on IPv4. Servers will run dual stack and receive outbound mail from IPv6 clients, but the Internet-wide relay federation will still run on IPv4 where the current DNS-based blacklist system works. This is a short-term solution as it will become expensive for new companies to get access to IPv4 addresses and set up their mail servers. They will run on IPv6 only and complain over your e-mail systems lack of reachability.

Personally, I haven’t formed any opinion on the right way to go. As a technology promotor, I want IPv6 everywhere, now. But I also understand the arguments from larger organizations that it’s not possible to open up the flood gates today. The IPv6 crowd will just have to come up with better solutions and prove them. Considerable amount of effort is put into this, in the IETF and by vendors and Open Source projects. Let’s follow the progress, participate and hope for a solution soon.