Email Gatekeeper lets users permanently reserve arbitrary mailbox names

[kyler505]

Summary

The Email Gatekeeper lets any authenticated user permanently reserve any valid mailbox local part. A user who claims a name first prevents the intended owner from claiming it later, and disconnecting does not release the name. On a deployment where all users can use the Email Gatekeeper, this creates a mailbox-name reservation/denial-of-service risk.

Evidence

packages/gatekeeper-email/src/email.ts accepts a canonical /mailbox/<name> URL in GatekeeperUserImpl.getGatekeeperClassFor() (around lines 386-438), then calls EmailAddress.claim(userAccountId) before recording the association in the caller's UserAccount.

EmailAddress.claim() (around lines 614-627) stores the first caller as owner and rejects every different caller. Its comments describe that owner as permanent. GatekeeperUserImpl.revoke() (around lines 441-449) deliberately disconnects hooks without releasing address claims, so the reservation survives disconnecting.

Reproduction from the current source

1. Authenticate two different Workshop users on the same deployment.
2. Have user A create an Email Mailbox binding for target-name.
3. Have user B create a binding for the same canonical URL.
4. User B receives This email address is claimed by another user.
5. Repeat with other valid names. User A can reserve names without proving control of the corresponding email address.

This is based on the current source path and ownership comments; I have not run this against a deployed SMTP/Email Routing setup.

Impact and design question

This is not an auth bypass: it prevents another user from claiming a name rather than granting the attacker access to the victim's mailbox. It is a namespace reservation problem that can block legitimate mailbox setup and may be exploitable by iterating names.

Please decide which policy is intended:

• only deployment admins may reserve mailbox names;
• claims should be released when an account disconnects, with safeguards for active routing; or
• users must prove control of an address before claiming it.

I am not proposing a PR because the correct fix changes mailbox ownership semantics, and CONTRIBUTING.md asks external contributors to report bugs rather than submit design-level patches.

[kyler505]

Local end-to-end reproduction

I launched the real local stack with pnpm run-local on http://127.0.0.1:8787 and drove the Cap'n Web WebSocket API used by the browser.

1. Created two local users.
2. Connected the Email Gatekeeper for both users by completing each returned local connection URL (HTTP 200).
3. User A created a workspace binding for:
   http://localhost:8787/gatekeeper/email/mailbox/claimrepro1786076859065
4. User A disconnected the Email account.
5. User B requested the same mailbox URL.

Observed result:

{
  "firstBindingResource": "http://localhost:8787/gatekeeper/email/mailbox/claimrepro1786076859065",
  "secondAttemptAfterDisconnectError": "This email address is claimed by another user"
}

The mailbox remained unavailable after the original account disconnected, confirming the claim persists independently of the connected account lifecycle. The mailbox suffix is generated per run; the output above is from the local run on 2026-08-06.