Internet and e-mail policy and practice
including Notes on Internet E-mail


2014
Months
Jan

Click the comments link on any story to see comments or add your own.


Subscribe to this blog


RSS feed


Home :: Email


23 Jan 2014

Fine grained mail filtering with IPv6 Email

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:

|nnn--64--nnn|xx-8-xx|uuu--40--uuu|ccc-16-ccc|

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.


posted at: 00:22 :: permanent link to this entry :: 0 comments
posted at: 00:22 ::
permanent link to this entry :: 0 comments

comments...        (Jump to the end to add your own comment)

Add your comment...

Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.

 
Name:
Email: you@wherever (required, for confirmation)
Title: (optional)
Comments:
Show my Email address
Save my Name and Email for next time

Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

CAUCE
It turns out you don’t need a license to hunt for spam.
5 days ago

A keen grasp of the obvious
Italian Apple Cake
563 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse



© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.