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:

  1. 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.

  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 (5)

  1. Jonas Falck says:

    Whitelisting could be part of acceptance though there are security concerns.

    Last year we blogged about our (Halon Security) approach and ideas, .

    We have many customers using IPv6 and try to push Virus Bulletin to bring up focus around IPv6.

    Jonas Falck

    Halon Security

  2. tzink says:

    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.

  3. Hexamail says:

    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.

  4. Craphound says:

    Your post advocates a

    (X) technical ( ) legislative ( ) market-based ( ) vigilante

    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

    (X) Spammers don't care about invalid addresses in their lists

    ( ) Anyone could anonymously destroy anyone else's career or business

    Specifically, your plan fails to account for

    ( ) Laws expressly prohibiting it

    (X) Lack of centrally controlling authority for email

    ( ) Open relays in foreign countries

    ( ) Ease of searching tiny alphanumeric address space of all email addresses

    ( ) Asshats

    ( ) Jurisdictional problems

    ( ) Unpopularity of weird new taxes

    ( ) Public reluctance to accept weird new forms of money

    ( ) Huge existing software investment in SMTP

    ( ) Susceptibility of protocols other than SMTP to attack

    ( ) Willingness of users to install OS patches received by email

    ( ) Armies of worm riddled broadband-connected Windows boxes

    (X) Eternal arms race involved in all filtering approaches

    ( ) Extreme profitability of spam

    ( ) Joe jobs and/or identity theft

    ( ) Technically illiterate politicians

    ( ) Extreme stupidity on the part of people who do business with spammers

    ( ) Dishonesty on the part of spammers themselves

    ( ) Bandwidth costs that are unaffected by client filtering

    ( ) Outlook

    and the following philosophical objections may also apply:

    ( ) Ideas similar to yours are easy to come up with, yet none have ever

    been shown practical

    ( ) Any scheme based on opt-out is unacceptable

    ( ) SMTP headers should not be the subject of legislation

    ( ) Blacklists suck

    (X) Whitelists suck

    ( ) We should be able to talk about Viagra without being censored

    ( ) Countermeasures should not involve wire fraud or credit card fraud

    ( ) Countermeasures should not involve sabotage of public networks

    ( ) Countermeasures must work if phased in gradually

    ( ) Sending email should be free

    ( ) Why should we have to trust you and your servers?

    ( ) Incompatiblity with open source or open source licenses

    ( ) Feel-good measures do nothing to solve the problem

    ( ) Temporary/one-time email addresses are cumbersome

    ( ) I don't want the government reading my email

    (X) Killing them that way is not slow and painful enough

    Furthermore, this is what I think about you:

    (X) Sorry dude, but I don't think it would work.

    ( ) This is a stupid idea, and you're a stupid person for suggesting it.

    ( ) Nice try, assh0le! I'm going to find out where you live and burn your

    house down!

  5. sowmya says:

    it is difficult to understand send of email because it is lengthy process

Skip to main content