Throwaway email blocklists want to block Firefox Relay: Here's an alternative

TLDR: I propose a way for email masking services like Firefox Relay, ThxNoThx or iCloud Hide My Email to help out services that need to uniquely identify users, without compromising user privacy

Disclosure: I am the founder of ThxNoThx, an alternative email masking service (obligatory marketing pitch: with advanced features like distraction free newsletter reading, one click unsubscribe from the inbox, and using addresses in your existing domain names)

This post is a response to https://github.com/disposable-email-domains/disposable-email-domains/pull/298 since they have (probably wisely :) locked down comments. They propose adding Firefox Relay domains to their blocklist.

Background

Throwaway email services allow users to generate new email addresses at will. They are often used when someone doesn't want to give a real email address to a website.

disposable-email-domains is one such list of throwaway email domains. It is used by SaaS services to prevent customers from using a throwaway email address when registering.

It was recently proposed that Firefox Relay be added to the list of blocked domains.

Email masking services like iCloud Hide My Email and Firefox Relay (and ThxNoThx!) are different from throwaway email services since they allow continued communication with the user, usually by forwarding emails on to the user's inbox.

In my last job I did work around account management at a site targeted by cryptominers (views expressed in this post are my own), and in my experience it's trivially easy for disposable email address providers to simply create new domain names. I just tried it: search for "burner email address" -> click the first link -> look at the generated email address (reamtv.com) and... it's not in the blocklist at disposable-email-domains.

What should the goals of a solution be?

Services using domain blocklists need:

• A way to uniquely identify users - for example, a user should only get one free trial. Email address is often used for this purpose, but it is not perfect.
• An open channel of communication with their users for marketing and transactional purposes. For example they need to contact you if there's a problem with an order or because they think you'd like a new feature they've added.

Users of email masking services need:

• Privacy - a random artisanal soap company on the internet does not need to have my real email address. I shouldn't have to trust they won't get hacked and leak my address or that they won't sell it to other companies.
• Control over their inbox - unsubscribe links in emails are great, but they ultimately rely on company's willingness to allow users to unsubscribe (in some places this is legally mandated, but it is an imperfect system)

I believe email masking services represent a good middle ground: businesses get an email address that is permanent and can reach the user when they need to, and if the user finds their marketing material helpful, they can keep their email address active.

However, email masking services also make it easy for users to generate multiple addresses, meaning that email addresses will be less useful for uniquely identifying users in the future.

Proposed Solution

Companies should be able to ask email masking services if the user behind an email address at an email masking service has previously registered with their company

The company that wants to know if a user has previously registered can send a query with the following info:

• A secret that is known only to the company, used in each and every query from that company (eg '123abcMySaasIsAwesome')
• The email address of the user that's trying to register
• A queryId - this can be used if there is a failure in communication and the same query needs to be sent again. This makes the query idempotent (the masking service stores the queryId of the first request of the user + service combo, thus preventing a false positive if a request needs to be resubmitted)

The email masking service simply replies with true/false that the user behind that email address has previously registered with the company identified by the secret.

An example

1. A user (Mary) goes to register for a Saas service (FeelingSaasy.com), and during account creation, she submits her email address as anon123@mary.thxnothx.com (ThxNoThx users can use any email address under @{username}.thxnothx.com)
2. FeelingSaasy sends the ThxNoThx the email address and a secret only known by FeelingSaasy in a request to ThxNoThx, asking if the user behind that email address has registered with the service behind that secret (FeelingSaasy). This would presumably be done via a simple HTTP request
3. The email masking service would respond to the request with true/false - from that, FeelingSaasy can decide whether or not to allow the request from the user.
4. Potentially the email masking service could inform the user of this request, as well as provide the user with the previous email address used. This might be helpful in "I forgot my login credentials" type situations as well as provide transparency to the user.

Some interesting aspects of this solution:

• FeelingSaasy.com never knows which previous email address was used - they only know that the user behind an email address has previously registered. (Currently Firefox Relay and ThxNoThx addresses can contain the username of the user in the domain name - and thus email addresses from the same user can be identified that way - but that may change in the future.)
• The email masking service does not know the identity of the company - the secret should just be a random string known only to the company

Opportunities

I would argue that email relay services solve the problem of uniquely identifying users better than existing solution because a user paid money to the email masking service. That raises the costs of switching between services or creating new accounts with the masking service.

We would notably still have a role for the blocklist to play: we need to know what domains support the unique user identification service.

We all benefit if the internet has a bit more privacy than it does today.

Challenges

This does represent more work for services to integrate with, however I believe it can be implemented via a single API call.

This is also work for the masking service: they need to have a service that responds to this request, but it's a fairly simple lookup easily supported by regular db indexes.

Attacks/Problems

A masking service decides to return bad results: (eg. falsely say no one has ever previously registered): This should be easily detectable by the other side, since they could simply create an account themselves and do a check (you'd only need a few folks in the eco system doing this to ensure good results). The possible response to this behavior (if/when detected) would be to add them to the proper blocklist.

A site with large # of calls to check identities at the email masking service: The service's secret would be a pretty good way to do rate limiting. If the email masking service needed to get the attention of the calling site, they could start returning 500s with a message :)

DDoS attacks and "someone stole our secret" both are issues, but those are always issues? I don't think the proposed service is any more vulnerable to those attacks than any other service on the internet.

I'm sure I'm missing something - please reach out as discussed below.

Next steps

If you're interested in discussing this further, please contact me at {myfirstname}@sunnyporch.dev, @stephensisk on twitter or by replying to this post.

Some things we'd need to do to make this real:

1. Someone needs to provide a spec for the request/response, and a canonical implementation (perhaps with a basic test suite to show compliance)
2. Email masking service providers: implement this request and provide the URL to domain blocklists.
3. Domain blocklists: provide a list of domains that support this, and the URL of the endpoint

If any service is interested in using this I'd be excited to work on this from the email masking service side.