I’m a guest at the MAAWG conference in San Francisco this week and several people have now mentioned to me the problem and the opportunity of anti-spam e-mail filtering for IPv6. Tomorrow is World IPv6 Day but since a bunch of the pieces have clicked together in my head I’ll post this a day early.

Default Allow or Default Deny?

There are more “bad” hosts sending unwanted e-mail than there are “good” hosts sending wanted e-mail, and if we had a clean slate (no installed base) then engineering economics would favour a “default deny” model whereby we’d maintain a list of “good” hosts and then reject traffic from everywhere else. This is because such a list would be smaller than a list of “bad” hosts and it would change less frequently. Of course we do not have a clean slate—by the time unwanted e-mail became a compelling problem the number of “good” e-mail senders was in the millions and there was no practical way to make a reliable list of them. As a result the e-mail reputation industry is based on a “default accept” model—any e-mail sender IP address who has no known reputation is presumed to be “good”. That’s statistically wrong of course but there’s no way to change the assumption at this late date.

At least, there’s no way to change it for IPv4. In IPv6 there are still only a smallish number of hosts who transmit e-mail and it is still practical to build a list of these. One of the reasons for that practicality is that there are no IPv6-only hosts yet. Every host who wants connectivity to “the Internet” is either IPv4-only or IPv6/IPv4 “dual stack”. This means any omissions in a list of “good e-mail senders” for IPv6 would simply cause mail from the omitted hosts to use IPv4 fallback mode until the list of known e-mail senders could be made more complete. Thus it is practical at this moment to consider a “default deny” model for IPv6 e-mail where a host having no known reputation could be presumed to be “bad”.

Guarding the Guardians

As the co-founder with Dave Rand of the first anti-spam company (MAPS) who created the first Internet e-mail reputation system (the RBL) I can tell you that being sued is a thrill best experienced vicariously. Anyone who deliberately causes someone else to lose money or to make less money can expect to hear from lawyers about it. Running a reputation service whose outcome is that some hosts and networks are considered “bad” is a touchy business. In particular, non-criminal enterprises engaging in non-criminal activity that looks a lot like unwanted e-mail have “standing” if someone deliberately prevents this activity. The appeal of a reputation system that only says good things seems obvious in that respect and yet the problem does not change—if someone wants to be “on the list” but the list’s maintainer think they are a spammer then they can still at least try to sue the list’s maintainer or the subscribers to that list. Therefore a list of good hosts would have to be extremely inclusive—anyone who wanted to be on it could be on it—just to limit the size of the legal budget for the list maintainer. That may sound useless but please read on.

Quite a bit of unwanted e-mail traffic is relayed through malware-infected computers (“bots”) whose owners are have no malicious intent and have not given their permission to have their computers used as “spambots”. A list of hosts whose owners wanted to be allowed to transmit e-mail would necessarily not include these spambots. Assuming that we can authenticate the requests to be added to the list, so that bot herders cannot ask for their victims to be allowed to send mail, we could change the shape of the spam distribution network using a “default deny” system. Authentication of that kind will soon be possible, since RPKI is working its way toward a globally deployed security framework for network operators.

Two Stage Filtering

It seems possible that some unwanted e-mail will also come from hosts and networks whose owners know exactly what they are sending, and who would therefore ask to have their hosts and networks added to a list of “good hosts”. In my model these requests would be accepted and these hosts and networks would indeed be added, as long as the requests are authentic in that they have come from the actual owner of the hosts and networks in question. Therefore if all goes as expected then some of the e-mail coming from “known e-mail senders” will be unwanted. That’s a necessary cost of a system that prohibits “spambot” transmissions without costing a zillion dollars a year in legal defense for whomever might publish a list of “good” hosts.

This is where the second stage filter comes in. Mail receivers who wish to reject e-mail from places they or their reputation providers think are likely to be sources of unwanted e-mail will still have to use a “default accept” list in which the hosts and networks on that list are considered “bad”. This may not seem like an improvement over the current state of affairs which in IPv4 is that no such list is adequate and the senders of unwanted e-mail can always find unlisted places to send it from or relay it through. If so, appearances are deceiving. There’s a huge improvement to be had, simply because there would never be a need to put something on the second stage “bad” list that was not also on the first stage “good” list. From an engineering economics perspective this is a giant win since the total size of the first stage “good” list will be infinitesimal compared to the size of the IPv6 address space.

Technical Minutiae

Internet Service Providers (ISPs) would in this two stage filtering still face a heavy load of outbound unwanted e-mail from their customers who are infected with malware and acting as “spambots” but that’s not worse than the present day situation—this is a problem they already have to solve.

Conclusion

I hope the e-mail industry considers all of their options and the cost/benefit of each as they stare into the very large IPv6 address space and contemplate their future. The ideas we originated with the MAPS RBL may have taken as far as they ought to. Fresh thinking is called for.