One of the important projects I have been working on for the past few months is supporting email over IPv6. Long time readers of this blog (all four of you) will remember that last year I wrote a series of posts on email over IPv6:
Part 1 – Introduction Part 2 – Why we can’t use IP blocklists in IPv6 Part 3 – A solution: Whitelists Part 4 – Population of the whitelists Part 5 – Removals, key differences, and standards
Part 1 – Introduction
Part 2 – Why we can’t use IP blocklists in IPv6
Part 3 – A solution: Whitelists
Part 4 – Population of the whitelists
Part 5 – Removals, key differences, and standards
In case you can’t tell by the above, the backbone of the solution was using IPv6 whitelists and maintaining a list good senders, and then sharing that list amongst the major receivers.
I now entirely refudiate* that idea.
We now have a new solution in mind. I can’t claim credit for inventing any of it. The basic algorithm was developed in close participation with other bright minds in the industry, and the performance issues are addressed and acknowledged by people within my own company.
The new solution is better than the previous one: it is more scalable, easier to manage, and builds upon what is already there in IPv4. However, unlike the previous solution, there is more uncertainty involved with regards to its performance when it comes to running the service.
This series of blog posts will go into the problem of email over IPv6, a technical solution to the problem, and technical considerations into implementing that solution.
Stay tuned for more.
* It’s a word, look it up.
Looking forward to reading this.
Btw, this site works badly using HTTPS - looks like the CSS isn't loaded. (I use the FF HTTPS-everywhere add-on.) That isn't really you to blame, I know, but I needed to tell someone. :-)
I don't have any control over the https layout of this site. I have considered moving this blog platform to another one because I'm pretty sure that this one is not actively maintained.