Create settings to allow user to restrict and audit all aliasing for the account.

While aliasing is useful , it can be a double-edged sword.

Email compromise is always a possibility and this feature set is aimed at ensuring, not assuming, that the user has full control of their inbox. Also providing visibility for abuse on other platforms, giving the user information to address the abuse.

Attack (and risk) scenario:
1. An attacker compromises a users device.
2. On that same device, they access the users mailbox. (in a very stealthy fashion)
3. They create/stage accounts (on other target web services) leveraging +aliases (that are unknown to the mailbox owner).
4. The attacker swiftly validates the inbound email validation requirement (that is a standard control these days).
5. The attacker swiftly deletes all evidence of the emails.
6. The attacker proceeds with the fraud/abuse on the target web service(s).
7. The user access their mailbox and notices nothing odd at all. Potentially including in the security log, due to the timing of the incident.
8. At some future time, user is contacted regarding crimes committed and/or losses incurred.

Feature Proposal:

I propose a set of features in Settings that permit users to create explicit lists of any alias formats permitted by the tier they are on. The user will have full control to add/remove entries from that list to allow INBOUND email receipt. In addition, the feature(s) should be treated like a sensitive account change, causing notifications to the users preferences.

If an alias is removed from the user account, all future emails to that alias MUST be refused/denied/bounced by Proton as appropriate.

Finally, there MUST exist a log or manner to ensure visibility of any usage of any format alias, including the To, From, Subject and DateTime, plus IP and other Sentinel level data (for Sentinel users). That log should persist for a certain timeframe, such that it is reasonable for the user to view any alias usage of concern. I propose the log contains 7 days listing all unique alias usages at a minimum. POssibly having a "# times used in last 7 days" column if desired to shrink the row count. The key is that this log cannot be deleted or purged by the user/attacker, where emails are trivial to permanently delete.

UI/storage considerations:

So for +aliases I imagine it would be a list of entries the user wishes to permit. From zero entries up to some limit. A balance needs to be struck on this specific feature as +aliases are technically unlimited, but you cannot have an infinitely long list of approved aliases. So I propose a list of up to 100 (initially) for +aliases. Based on usage you could change that number. I feel this is the alias type where the attack scenario is real.

Alternate Feature:

If Proton cannot introduce this type of granular control on aliases, then I propose they offer the ability to individually disable each of the various alias features on an account by account basis. Again making this a sensitive account change, causing notifications to the users preferences.