Summary

When registration_email_suffix_whitelist is configured, the normal registration flow correctly rejects email domains outside the whitelist. However, the same policy does not appear to be enforced when an authenticated user binds or replaces their account email through the email identity binding flow.

This means a user can create an account with an allowed email suffix, then change the account email to a domain that would have been rejected during registration.

Expected behavior

The email suffix whitelist should be enforced consistently for account email identity changes, or there should be a separate explicit setting controlling whether post-registration email rebinding may use domains outside the registration whitelist.

At minimum, the same policy should be checked when:

• sending an email binding verification code
• completing email identity binding / replacing the bound account email

Observed behavior

• POST /api/v1/auth/register rejects disallowed domains when the whitelist is configured.
• Authenticated email identity binding can accept an email address whose domain is outside the configured registration whitelist.

Impact

Sites that rely on the registration email suffix whitelist for risk control, promotions, or closed signup can have that policy bypassed after signup.

Suggested fix

Apply validateRegistrationEmailPolicy or equivalent suffix whitelist validation in the email identity binding flow, for example around:

• SendEmailIdentityBindCode
• BindEmailIdentity

If preserving current behavior is desired, consider adding a separate setting such as email_binding_suffix_whitelist or enforce_registration_email_suffix_on_binding.