A Plan for Email over IPv6, part 4 – Population of the whitelists
Population of the whitelists
How do email receivers go about populating whitelists?
The whole strength of email is that you can hear from people you’ve never heard from before; new people outside your normal circle can talk to you. But the whole weakness of email is that you can hear from people that you’ve never heard from before; spammers can send you junk.
The weakness of using whitelists – and blocking the rest of the world – is the “introduction problem.” How do you hear from new people? They have important things to say to you, yet you aren’t listening to them and that is by design.
In reality, this problem has analogies in real life. Think back to your own experiences; when you first started out your working career, nobody would hire you because they wanted people with experience. But how are you supposed to get experience if nobody will hire you? Another example is when Homer Simpson wanted to join the Stonecutters, he was stonewalled because to get into the club, you had to either be related to an existing member, or save the life of an existing member. Since the Stonecutters wouldn’t reveal their membership, and the odds of saving the life of anyone is extremely small, Homer initially couldn’t get into the club.
Fortunately, there are ways to get around the introduction problem, but all of these ways have their own degrees of difficulty. Below are some possible mechanisms to accomplish this:
Manually - Administrators may contact each other by email over IPv4, by telephone, by regular mail, by word-of-mouth, or any other form of communication. Both parties may agree to whitelist each other, or one party may whitelist the other without the other doing the same.
Difficulty: High (easy to implement but doesn’t scale)
Use a 3rd party - Administrators may rely on a third party reputation service that provides lists of IP addresses of known good senders of email over IPv6. An administrator may acquire this list and proactively whitelist all IP addresses on this list, or a subset of them.
Difficulty : High at first (nobody has such a list) but Low to Medium thereafter
Pre-populate your list yourself - Administrators can create their own lists. One way to do this is to maintain IP reputation statistics of senders over IPv4. By combining that with sending domains and SPF records, receivers can “guess” what IP addresses senders will use to transmit over IPv6 and use that to pre-populate a whitelist. They do this by looking up the SPF records of trusted domains and proactively adding any IPv6 addresses to the whitelist. Receivers who plan to use SPF or DKIM acceptance do not need to do anything, they simply take the list of trusted domains they were using for IPv4 and reuse them for IPv6.
Difficulty : High (but not in the case of DKIM or SPF whitelists)
Provide an easy way for senders to get onto the whitelist - Another way to populate the whitelists is to give email senders a way to do it themselves with as little human interaction as possible.
a) If a receiver rejects a sender, the bounce message might contain instructions on how to add themselves to the whitelist:
550 Access Denied. The sending IP [121::1] is not permitted to send email over IPv6. To attain permission to send over IPv6, please see the following web page: https://...
b) The web page contains a form that the sender can fill out and send to the receiver. The form would have standard sign-up security checks including a CAPTCHA plus another form of identification, whether it is SMS validation or sending an email to another email address requiring a second call to action (e.g., click this link).
c) Once the sender has passed multiple validations (filling in the CAPTCHA, responding to the text message to their phone or clicking on the link in the email), their IPv6 address is added to the receiver’s whitelist. This puts the responsibility on the sender to whitelist themselves and at the same time scales for the receiver so they are not endlessly managing whitelists using humans. If a sender truly needs to send email over IPv6, they will take the time to do it.
Difficulty : Medium for the receiver, Easy for the sender
Do it yourself by tracking reputation – Rather than rejecting mail from senders on IPv6, receivers might allow new senders transmitting over IPv6 but throttle them instead. The sender could send some mail over IPv6 and then fallback to IPv4 once they have reached their daily limits. By keeping track of a sending IP addresses’ reputation (ratio of spam to non-spam, passing authentication, etc.) over a period of time, a receiver can upgrade the sender from the Untrusted list to the Whitelist. The amount of mail they can send over IPv6 increases as their reputation increases.
This changes the concept from a binary whitelist (Accept/Deny) to a sliding-scale whitelist where a sender’s reputation is on a sliding scale. It works automatically; it does not require the sender or receiver to do anything whereas in the above web page method, some users or administrators won’t understand how to or won’t care to whitelist themselves. The drawback of this method is that it can take a long time to go from Bad to Good and during that waiting time, email delivery is sporadic. It also forces mailers to send mail over IPv6 and IPv4. While most mailers can do that, it is not necessarily true for everyone and those that cannot will not be able to send email.
Difficulty : Medium for the receiver, Medium for the sender
Any of these methods, or a combination of them, could be used for whitelist population.
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