I built an API (private for now) which offers a solution to these scenarios, and may work as an alternative to passive email validation.
Instead of receiving an email, users are asked to send an email to a unique email address to confirm their email address (this - by the way - also filters out temporary receive-only email addresses)
A proof of concept can be found here: https://confirm-email.progresso-ict.nl. I can imagine the API to be used for account creation, password recovery, signing up for newsletters, etc.
Even though, with a clickable mailto address, the amount of steps are equal or similar to receiving a confirmation email, my girlfriend tells me the method is cumbersome.
So, what does the HN community think? Other questions I still have to investigate are mainly security-related. Emails are spam-filtered by Amazon SES, yet have to test for spoofing.
This way I have a server to ignore all the confirmation emails.
If I understand the use case correctly, I give out your system generated emails instead of giving my emails correct? And then your service forwards all emails you receive to my email?
The use case of my API is not quite as you describe, but I get the confusion. Instead, my case needs the platforms at which you register to implement the new method of confirmation. That means you can't just use this for every existing software.
It goes like this:
- You register at platform A with your own real email address
- Platform A asks you to confirm your email address, but instead of sending you an email, it shows you an email address to which you can send an email.
- You send an email using your own real email address.
- Platform A receives an event from my API that they received an email at the given email address from the email address they expected, so email address confirmed.
What you see at the provided URL is simply a demo of what could be part of any registration form.
