Email filters today use IP blocklists to stop most spam over IPv4. They are a little less effective than they were a couple of years ago as spammers have switched to compromised accounts but are still the primary line of defense. IP blocklists make spam filters more effective and save computer resources on more computationally expensive content filters.

IPv4 blocklists work because the total size of them isn’t that large. Worst case, there’s only about 4 billion IP addresses. Spam filters can manage lists of reasonable size. An IPv4 blocklist can grow to 70 or even 100 megs and size and this can stretch network limits – it takes a long time to process and store the list and it utilizes a lot of bandwidth to replicate the list in real time. Still, it is manageable.

IPv6 makes things much more challenging. Spammers have demonstrated proficiency at evading filters. Because the size of IPv6 address space is so large (over 340 trillion trillion trillion), this gives spammers options. They could send spam from one IP, discard it, and then move onto the next IP address and not run out because there are so many IPs.

This poses two problems for spam filters. The first problem is that they might end up building a IP blocklist so large that it is impossible to process the list and replicate it in real time if it grew to several gigabytes worth of data. The other problem is worse – IP blocklists are frequently reactive. A spammer spams someone, and then the IP is added to the list. If spammers rotated heavily through new IPs, discarding the old ones quickly, then an IP blocklist would always be blocking spamming IPs that are no longer in use. They’d always be one step behind the spammers, making them nearly useless.

The solution I propose as an interim solution is to use whitelists. Small mailers might be able to get away without them, but large mailers cannot. Rather than accepting mail from anyone over IPv6 and then figuring out if it is spam, reject mail from everyone sending email over IPv6 but punch holes for your friends. Only accept email from those who you know intend to send email over IPv6, and are not inadvertently sending it because they are part of a botnet.

This solution has precedent. Even today in IPv4 an email receiver cannot start sending lots of mail from a new IP address. Mail filters will think that this is a newly spamming IP address and either block the IP or throttle mail from it. Administrators get around this by asking other mail receivers to whitelist their IPs, or at least not block them. Whereas in IPv4 this is optional, in IPv6 this will be required.

That’s my Internet Draft in a nutshell. The Internet Draft contains a few more details but this hits the main points. I’ll also be talking about this plan at the Virus Bulletin conference in Dallas later this year.

But for now, please feel free to read my Internet Draft and send me feedback. The email community has been pitching this topic for a while now, this Internet Draft (and hopefully future RFC!) formalizes it.

Most email receiver aren't thrilled about receiving email over IPv6 for the reasons you mention in that link, and most also have the attitude of "Create a list and hope for the best." I don't that scales because it will work for some spammers, but not the really clever ones. I'm more confident in our ability to create a better spammer than I am in achieving the best results I am hoping for.

Wouldn't it be better to have some form of SPF/DNS based txt record type scheme to allow senders to stipulate which IP6 addresses will be used to send email from their domain? That way the "whitelisting request" is done dynamically in realtime with no recourse to phone/regular mail. If you trust their domain then you can trust their IP6 address just as you can trust their IP4 address to send from their domain. All you need is a new text record to specify the IP6 addresses allowed to send from a given domain. In this way people wanting to move to IP6 can just accept email from those domains they trust with an SPF record. So the receiver just specifies all the domains they already communicate with as requiring SPF (IP6) records. The sender can then manage their IP6 addresses themselves without having to notify anyone explicitly.

The alternative results in a strange new email ecosystem where the big senders/cloud based email systems can send to each other over IP6 whilst any smaller businesses can never move to IP6 as they will never be able to contact everyone they need to in order to be get whitelisted.

Personally I still don't understand why SPF isn't compulsory for sending email. At least it allows domain and IPs to be tied together in some way, and allows trust to be managed on the domain level instead of the IP level, which is way too technical for most users/sys admins and results in the problems you describe with larger and larger lists of IPs being required.

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses

(X) Mailing lists and other legitimate email uses would be affected

( ) No one will be able to find the guy or collect the money

( ) It is defenseless against brute force attacks

(X) It will stop spam for two weeks and then we'll be stuck with it

(X) Users of email will not put up with it

( ) Microsoft will not put up with it

( ) The police will not put up with it

( ) Requires too much cooperation from spammers

( ) Requires immediate total cooperation from everybody at once

(X) Many email users cannot afford to lose business or alienate potential employers