Synapse: restricting registration with email regex prevents adding/verifying nonconforming addresses after the account exists

[williamkray]

Description

If registrations_require_3pid and allowed_local_3pids is set in order to restrict new user registration to known domains, all other SMTP events fail for existing users.

Steps to reproduce

• enable registrations_require_3pid and set allowed_local_3pids to be restrictive regex
• create a local account via shared token/synapse-admin
• log in as new local account
• attempt to add an email address that does not conform to the allowed_local_3pids format

Expected behavior would be that, because the user account was already created externally, the user should be able to add any email address (e.g. work and personal). Only registration of new accounts should be restricted in order to prevent spam account creation.

Instead, users are unable to add a non-conforming address to their account. If an administrator adds their address for them, they cannot use that address for password-reset purposes because the server refuses to send the email.

Version information

• Homeserver: jobmachine.org

If not matrix.org:

• Version: 1.21.2

• Install method: official docker container
  

• Platform: linux VPS
  

[erikjohnston]

Interesting. I think one of the use cases here is for a work environment where they don't want to allow resetting of passwords outside of their work email addresses.

I guess we could add an option to allow adding non-confirming addresses, so long as they retain the confirming one, but I'd be interested in hearing your use case?

Adding an email address to an identity server to allow people to look you up via a non-conforming address should still be possible?

[williamkray]

this behavior should be similar to how slack historically has allowed for users to be invited _or_ anyone with an email address at a specified domain can sign up without requiring an invitation.

I have a homeserver for a private community of friends, and while some of them may have asked for an email address at the given domain we're associated with, others do not and prefer to use their personal email. for those with an appropriate email address, they should be able to sign up for a matrix account on my homeserver without requiring invitation. for those who still use their gmail/outlook/etc accounts, they should require an invitation to create their matrix account, but should not be unable to set their password or otherwise use the email features of the homeserver.

[erikjohnston]

OK, that sounds sane, thanks! We can add a configuration parameter to allow that, though the core team will unlikely get around to implementing it any time soon.