What happens if spammers get on the whitelists?
The question arises – what happens if a spammer gets onto the whitelist? Maybe they have compromised an IP address of a good sender. Or maybe they snuck onto the list. What should be done if this is the case?
A whitelist model makes abuse tracking easier. In IPv4, all IPs are accepted and then the abusive ones are singled out and blocked, but the problem is a new IP address will arise the next day. In IPv6 whitelisting, the population of sending IPs is limited. There are only so many legitimate mailers on the web. If someone is spamming, you look at the list of permitted IPs and either:
- Kick the spammer off the whitelist.
- Lower the sender’s reputation which lowers their throttling limits in the case of a sliding-scale whitelist.
- Use the sending IP as part of a weight in the spam filter.
If a spammer does get kicked off the whitelist, they can’t just show up the next day on a new IP without going through one of the processes they went through to get onto the whitelist to begin with. Making the steps difficult for a machine to automate but easy enough for a human to do adds costs to a spammer’s business model. A spammer must be able to do things quickly and if getting onto a whitelist takes manual steps, it will cut into their bottom line and makes IPv6 spamming a less attractive target.
What about if a spammer takes the time to manually get onto the whitelist?
Some spammers are determined and are willing to spend the time to perform laborious steps. However, additional behavior checks can be implemented in the signup process (in the event no human is involved in whitelist addition), and traditional IPv4 spam and reputation techniques can be used to the same effect they are today. Spammers attempting to game the system is an existing problem and there are people working to combat it. It will be no different under an IPv6 whitelist model.
Thus, the mitigation for spammers compromising the whitelist is to track the reputation of the senders even after they have gotten onto the whitelist.
Summary of Differences
The following table represents the key differences between what we do in IPv4 vs what this plan proposes for IPv6:
Sharing Data
One of the most crucial components of the whitelist solution is data sharing. Large mail receivers need to share data to make this effective. If Microsoft does one thing, Comcast does another and Google does yet another, and each is different than whitelists, or even if they all do whitelists, it becomes a management nightmare with everyone doing their own thing.
(How standards proliferate – comic taken from xkcd).
Wouldn’t it be easier if the big players got together and decided that everyone shares lists with each other? Then, if someone got whitelisted at one big player, you automatically became whitelisted with a lot of other players, too? It would make it so much easier for legitimate people to send mail across IPv6 without having to get whitelisted everywhere.
It would mean that the industry is finally working together to stop the problem of spam. 25 years ago we never predicted that the Internet would become abused as much as it is today. As big a problem as IPv6 spam could be, we have a chance to do something different and stop it before it begins – designing with security in mind. Having everyone agree to the same process is a major step in this direction. It stops the spammers and helps everyone else which is the whole point of the antispam industry. It makes life easier for end users and for the email receivers.
But who should be responsible for this industry collaboration? Should private companies get together and form the standards? Should already-existing regulatory bodies (such as the Internet Engineering Task Force) do it? Should government oversee it?
This is a body of work that is ripe for exploration.
Conclusion
As the world transitions to IPv6 and Internet connected users and devices start to use it, email servers will eventually need to send email over IPv6 as well. However, the solutions for combatting spam over IPv6 cannot be the same as they are for IPv4.
The use of IPv6 whitelists to accept mail from reputable senders, rather than IPv4 blocklists to reject mail from disreputable senders, will help address one of the problems of spam over IPv6. It keeps the problem to a manageable size while ensuring that large email receivers can still scale their services without excessive hardware costs.
Yet the use of whitelists is not without its problems; how do you get onto a whitelist to begin with? The easier it is to get onto it, the more likely it is that spammers will abuse it. Yet making it more difficult will prevent the most useful feature of email – its ease of use. There are multiple ways to balance usability with security but ultimately email over IPv6 will look different than IPv4. It is still too soon to know how different it will be.
Fortunately, we are at a stage where we can decide how to build email protocols with security in mind. Had we done that 25 years ago, we might not even have needed to build such complex spam filters. With any luck, the decisions we make (or more importantly, don’t make) today will not need to be revisited 25 years from now.
The end.
Posts in this series:
- A Plan for Email over IPv6, part 1 – Introduction, and How Filters Work in IPv6
- A Plan for Email over IPv6, part 2 - Why we use IP blocklists in IPv4 and why we can't in IPv6
- A Plan for Email over IPv6, part 3 - A solution
- A Plan for Email over IPv6, part 4 - Population of the whitelists
- A Plan for Email over IPv6, part 5 – Removals, key differences and standards