New aliases created automatically when an address is first used

[pendantry]

Just to see what would happen, I sent an email addressed to 'test@' my mozmail.com subdomain.

The email was forwarded by Firefox Relay. When I looked, I found that it had autogenerated a new alias for this address all by itself.

I believe that this is definitely incorrect behaviour, as it opens the door for email spam once a spammer has access to a subdomain name within mozmail.com.

Picture the situation: a spammer autogenerates many (hundreds? thousands? MILLIONS?) of emails of the form mailbomb[n]@subdomain.mozmail.com. The poor user gets deluged with unwanted emails, AND has to then deal with individually blocking each and every new alias created in this manner. Such an attack would make Firefox Relay unworkable for that user account – and possibly overload it completely!

Instead of forwarding the email and autogenerating a new alias, I think Firefox Relay should either:

1. seek verification from the account holder beforehand, or
2. [my preference] block (or bounce?) any such emails, requiring the user to generate all subdomain aliases proactively

[Vinnl]

Hi @pendantry, this is expected behaviour, and it's one of the reasons why we recommend using random (non-subdomain) aliases whenever possible. The intended use case for subdomain aliases is when you are somewhere physically and need to provide an email addresses, and where you can't really open up the Relay website to generate a new alias on the fly. In other words, you're trading some privacy for convenience.

Whenever possible, using a non-subdomain alias that cannot be correlated with your other aliases is recommended. We are looking for ways to make this more clear.

[pendantry]

Hi @Vinnl , thanks for your response.

You say that this is 'expected behaviour', but if so, I would suggest that it is poor design for the reasons I gave above.

A better solution would surely be to autogenerate the alias but hold any emails sent to it pending confirmation from the account holder that the alias is to be enabled fully. Such a system would avoid the 'trading some privacy for convenience' issue entirely.

If such a system is not to be implemented then I would like to have the option to block all email to 'my' subdomain to avoid it being abused.

[Vinnl]

Thanks @pendantry, I relayed (:drum:) your comments to the team, so it will serve as input as we consider how to deal with this going forward. Thanks for sharing!

Edit: oh, one challenge with your proposal that I do know off the top of my head, is that that would require us to hold on to the email while we're waiting for the approval, whereas we're trying not to store unnecessary personal data. Just to give you some insight into the type of trade-offs that we're considering :)

[pendantry]

one challenge with your proposal [...] is that that would require us to hold on to the email while we're waiting for the approval, whereas we're trying not to store unnecessary personal data.

I can understand that. But I believe that your system is already set up to hold emails (for up to three days, if memory serves). In the scenario you pose (ie 'when you are somewhere physically and need to provide an email address'), I would think that's adequate time for the user to approve the alias. I would assume that the system would warn the user of the consequences of not approving the alias.

[ndo360]

Greetings! @Vinnl ^_^

I recently discovered your service and I fell in love with it. I was wondering if allowing end-users to manually whitelist prefixes for their subdomains mask could help mitigate the risk of potential email flooding.

For clarity I am visualizing a setting where, when enabled, the end-user would provide a series of prefixes for their subdomain that are whitelisted and as such are allowed to forward any incoming emails to the actual personal email. While any incoming emails that attempt to make contact with a non-whitelisted prefix would be discarded / rejected and not forwarded

(For example one could say “food, games, and school” are all three different whitelisted prefixes for their own personal subdomain, and as such any email sent to their subdomain without using one of those three prefixes would be blocked and not forwarded. )

This way the end-used could decide if they want the ability to setup said “ad-hoc” emails in the moment, like it currently is, or if they’d rather use a whitelist system with manually set prefixes ahead of time and allow more control.