Six steps to sending email over IPv6 – my Internet Draft
A couple of weeks ago, I published my first Internet Draft to the Internet Engineering Task Force (IETF). Today, I updated it, making it version 2 (but named version 01.txt). It is titled Recommendations for the use of whitelists for email senders transmitting email over IPv6.
Here’s a quick synopsis:
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.
Comments
Anonymous
May 23, 2012
The comment has been removedAnonymous
May 24, 2012
Thanks for your comment, Jonas. 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.Anonymous
May 26, 2012
The comment has been removedAnonymous
June 12, 2012
The comment has been removedAnonymous
October 13, 2013
it is difficult to understand send of email because it is lengthy process