Idea for a web service allowing users to register chain-linked email addresses to protect against address deprecation

Idea for a web service allowing users to register chain-linked email addresses to protect against address deprecation

MrNycticorax, Twitter: @mrnycticorax

Problem

Your contract or institutional relation with an email provider is ending soon, but writing an email to your contacts to warn them seems cumbersome and/or out of place because, you know, many contacts to whom you bear all sorts of social relationships, and some of which you haven't seen for decades...

Yet you want to ensure that the contacts who will still be using the address after it's deprecated will be notified appropriatedly.

That's a problem everyone once faced (i.e. my parents are facing it as of this post), and here's a solution.

Solution

Description. First, you set up a web service (henceforth, 'the Service') able to:

(Authorize and validate in a 3-way schema) Receive authorization from both the email provider and the user, and validate email addresses before deprecation, so that emails sent to a deprecated address can be used at any point of time to identify a valid and non-deprecated address.
(Chain-link) Establish a chain of at-the-time authorized and validated emails stretching from an original email address to a unique valid, non-deprecated email address (= the very last in the chain), so that at any point of time, any email sent to a depecrated address can be used by the Service to identify an active email address.

Usage. A user registers to the web Service by subscribing a valid and active email address. The Service confirms the address by checking that it does not exist yet in the Service's database and by sending a confirmation email to that address. The confirmation email includes a confirmation link passing a one-use, short-lived token to the Service. The Service then asks the email provider if it agrees to subscribe the target address to the Service (just as it asked the user). If all conditions are met, the Service sends an email to the 'old' email address confirming the link to the newly added email address.

After subscription, whenever an email headed to a no longer valid email address is received by the provider's server, the provider can check against the Service if there is a 'new' address in the chain of the intended recipient. The Service replies to the provider with the last address present in the chain in which the deprecated address occurs. This allows the provider to compose a 'delivery failure' message including a new, valid adress, and send it as part of the response to the author of the original email. At the end of the day the author of the original email is provided with the last valid and active email address of the addressee.

Problems & fixes

Spammers.
They can abuse the system to get active addresses from deprecated ones. Fix: add spam-detection mechanism to the Service.)

Not a problem: Address-space thefts.
If someone chains an address A to which they are entitled to an address B to which they are not, the owner of B can no longer chain to B. Fortunately the short-lived confirmation token allows the Service to prune registered non-confirmed addresses after a short period of time).

Not a problem: Address-space saturation.
A provider might want to re-assign an address-name but apparently it cannot since it it is already subscribed to the original owner's chain. Fortunately the Service allows providers to subscribe addresses with a lifespan or an opt-out option. When the lifespan expires or the provider wants to re-assign, the original owner is notified and his/her chain pruned accordingly.

No extra credentials needed!
As described in the (Chain-link) paragraph, at any point of time a user can register a 'new' email address against the last email address in the chain associated with his/her account. The only requirement for adding a new address is that the Service does not have this address subscribed on any chain yet, and that the user is able to confirm he/she has independent access to the last email address in the chain (before the addition) as described above. So there is no requirement to create specific credentials for the user in the form of e.g. an identifier/password pair. The work of such credentials is simply played by the last email in the chain.

Summing up

Alice --- adds 'fresh@alice.email' as a successor of 'deprecated@alice.email' to her chain on ---> the Service website

Bob ---- sends email at ---> deprecated@alice.email

Anna's old provider determines that the address is no longer valid BUT it ---- checks 'deprecated@alice.email' against ---> Service

Service ---- looks for last successor of 'deprecated@alice.email' (i.e. 'fresh@alice.email') in ----> Service database

Alice's old provider ---- composes delivery failure reply with the last successor of 'deprecated@alice.email' (i.e. 'fresh@alice.email') to ---> Bob

NB: if 'deprecated@alice.email' exists in Service database, given the rules in force, this can only be because someone, who at some point of time had access to that address, registered it. Moreover, since any successor of that address in the chain was added by a person with (former or current) access to the now deprecated address, the system safely assumes that any successor of the deprecated address, is accessible to the same person. So the Service safely infers that the chain of addresses belongs to none other than Alice.

NB: In the example if Anna has added a successor to 'fresh@alice.email' by the time Bob writes her and has not added any address afterwards, then the Service returns that successor.

NB: Also, given the rules in force, the same address cannot occur on more than one chain/account.