- Shipped
- September 23, 2026 at 7:50 AM UTC
- Author
- Kamo
- Commit
- 90af780
create/delete on an email alias, **************** on the org's sending domains, and **************** on a personal (self-hosted) mailbox all needed only a session — org scoping already existed, but nothing above it ever asked whether the caller was allowed to administer email accounts at all. Any authenticated member could mint a new alias address for a colleague, add a domain the mail relay would then send as (or remove the one the org actually verified), or reassign/delete a colleague's connected personal inbox. All of these now require MANAGE_EMAIL_ACCOUNTS — the same right MailboxController's equivalent personal-mailbox admin actions already enforce (2026-08-14) — mirroring that controller's denyUnless/hasRight helpers in each of the three controllers. Read-only endpoints (listDomains, getVerificationRecords, the personal-mailbox member-facing and IMAP/OAuth routes) are unchanged: their ownership check already lives where it belongs, keyed off session or the `?member=true` flag, and gating them further was not asked for and was not made here. AliasControllerRightsTest, DomainControllerRightsTest and **************** fail without the change — each admin action currently succeeds (200) for a bare session instead of being refused (403).