Home / Blogs

Fine Grained Mail Filtering With IPv6

John Levine

One of the hottest topics in the email biz these days (insofar as any topic is hot) is how we will deal with mail on IPv6 networks. On existing IPv4 networks, one of the most effective anti-spam techniques is DNSBLs, blackists (or blocklists) that list IP addresses that send only or mostly spam, or whose owners have stated that they shouldn't be sending mail at all. DNSBLs are among the cheapest of anti-spam techniques since they can be applied to incoming mail connections without having to receive or filter spam. On my system about 85% of incoming IPv4 mail connections are handled by DNSBLS, and I gather that number is pretty typical.

On IPv6, DNSBLs can't work the same way.

The problem is that the IPv6 address space is much, much larger. The IPv4 address space has 232 (4 billion) addresses of which maybe half are in use. Two billion is a lot of data for people, but not a big deal these days for computers, so large mail systems track every IP address that sends mail and has an opinion (the jargon word is reputation) about what kind of mail each IP sends.

IPv6, on the other hand, has 128 bit addresses. Usually each individual network, such as a home LAN or a single customer at a hosting provider, is assigned a 64 bit prefix, which means that each LAN has 264 addresses, way too many to track individually on any plausible computers. On the assumption that all of the 264 addresses are under the same control, a common plan for DNSBL operators is to disregard the low 64 bits of an address and just filter on the high half. Unfortunately, that doesn't really help, for two reasons. One is that even the remaining addresses are way too big to track. Currently there is about 53 bits allocated IPv6 networks (disregarding the low bits), and 253 of anything is still way too big to track. The other is that some hosting providers have ignored the standard configuration advice, and have put multiple customers in the same 64-bit LAN, so the 64 bit rule will treat all those customers as one. (The providers claim their routers made them do it.)

The thinking is that since IPv4 mail will continue to work for a very long time, we can be pickier about IPv6 mail and only accept it if it has DKIM signatures or otherwise makes itself easy to recognize. While I expect I'll be doing that, it occurs to me that the vast IPv6 address space offers senders and receivers a lot more finegrained whitelist and blacklist opportunities than we had before.

If I were providing public mail server like Gmail or Yahoo or Hotmail, there's plenty of bits to give every user a unique IP in a single /64. A recipient can treat the whole /64 as a unit, or if they want, they can track individual addresses, maybe all of them, or maybe just ones that come to their attention via spam complaints or the like. Recipients can use IP addresses to block mail from senders with a bad history, or maybe slow it down, or send it to different servers.

For ESPs (bulk mail service bureaus), we can add an extra level and assign IP bits both to users and mail campaign per user, perhaps like this:


The high 64 bits is the network number, same as any other IPv6 address. The low half has 8 spare high order bits for future cleverness, 40 bits of user (a trillion users per provider should be enough), and 16 bits to identify the campaign. If you want to handle one campaign specially, block, delay, or reroute or whatever, it has a unique IP. If you want to handle all of the user's mail specially, just ignore the low 16 bits and do something with that user's block of IPs.

Maybe this particular bit setup isn't ideal, but it's definitely worth thinking about what to do with all those address bits, beyond ignoring most of them and recreating techniques from IPv4.

By John Levine, Author, Consultant & Speaker. More blog posts from John Levine can also be read here.

Related topics: Email, IPv6, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


The cost of fragmenting IP addresses per campaign Alessandro Vesely  –  Jan 29, 2014 3:06 AM PDT

It is worth recalling the underlaying cost of using several addresses.  It forces an ESP to set up a sending strategy that is compatible with the user/campaign classification.  TCP and TLS connections cannot be kept alive across an IP change, so the latter might be seen as an overkill with respect to an (authenticated) originator email address change.

Besides technicalities, marketing campaigns —differently from discussion lists— tend to be short lived operations for some specific purpose.  The 16 bit campaign code has to match a moving target.  The difficulty of treating such identifier is similar to that of managing subscriptions.  A prospect buyer cannot subscribe to a campaign for the launch of a product that did not exist before, and a generic new products label is too broad of a mail stream identifier to be useful.  Perhaps, it would make sense to use something like the Global Industry Classification Standard codes, which would be independent of the issuing ESP.

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Promoted Post

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Port25 Announces Release of PowerMTA V4.5r5

New Case Study: Jobtome.com Replaces 30 Postfix Servers with a Single PowerMTA

An Update on Port25 and the Future of PowerMTA - One Year Later​

Encrypting Inbound and Outbound Email Connections with PowerMTA

V12 Group Sustains Customer Satisfaction by Deploying PowerMTA for Launchpad Platform

PowerMTA Now Offers Scheduled Delivery Control

DKIM for ESPs: The Struggle of Living Up to the Ideal

Reactivation Campaign: Shared vs. Dedicated IPs

To Where are Bounce Messages Sent?

An Open Source Perspective on Commercial MTAs

Five Essential PowerMTA Configuration Tips

What's New With Port25's PowerMTA v4.5

New Feature in PowerMTA v4.5: IP Based Rate Limiting

Case Study: Emergency Response Systems Rely on Timely Messaging Through PowerMTA

Port25 Announces Next Major Release of Its Email Delivery Solution, PowerMTA

Case Study: How PowerMTA Transparent Deliverability Metrics Paves Way for Email Service Provider

Case Study: MailChimp Achieves Efficient Execution and Reliability with PowerMTA

Case Study: Emma Swaps Its SMTP Infrastructure for PowerMTA to Handle Growing Mail Volume

Sponsored Topics