Local Identity Registration Is Not Provider Authorization
Local identity registration is not provider authorization
A client can record which identity an account is allowed to claim. Only the
remote provider can decide whether the account's credentials may use that
identity.
Those checks look similar because both talk about ownership. They answer
different questions.
Two gates
The local gate maps an identity to an account. It can drive direction
inference, defaults, UI choices, audit output, and protection against an
arbitrary From address.
The provider gate decides whether the authenticated account may use that
identity on the network. For email, the mailbox or alias must exist at Zoho,
Gmail, or the SMTP provider. Domain authentication and provider policy still
apply.
Passing the first gate does not configure the second.
Account scope is not sender identity describes the decision inside the
local gate: first choose the transport account, then choose an owned sender
within it. Provider authorization is the next boundary out.
A dry-run stops at the provider boundary
A good dry-run can prove the exact account and sender identity the application
will hand to its provider adapter. It cannot prove that the provider will
accept the message or that another server will deliver it.
This does not weaken Same-Code-Path Preview. It names the edge of the
promise: preview is execution minus the side effect inside the application.
The remote service's decision only exists once the side effect reaches it.
The mxr example
Mxr keeps primary addresses and aliases in its local account-address
registry:
mxr accounts addresses add --account consulting admin@planetaryescape.xyz
mxr compose --from admin@planetaryescape.xyz --to bhekanik@gmail.com \
--subject "Alias check" --body "Dry-run only." --dry-run --format json
In mxr 0.6.12, the compose path resolves an exact owned address to both its
account and its per-message From. Ambiguous aliases require --account.
Unregistered addresses fail before send. The daemon then passes the resolved
address to the SMTP or Gmail provider.
That makes mxr's registry a useful local safety boundary. It still does not
create a Zoho alias or grant Gmail send-as permission. In this case the Zoho
aliases were configured separately before mxr used them.
Design consequences
- Call a locally stored identity "registered" unless the product really
verifies it with the provider. - Show the resolved identity in previews and audit output.
- Keep provider rejection distinct from local ownership errors.
- Document which layer creates the identity and which layer merely selects it.
The pattern is not limited to email. A deployment tool can register a cloud
role, a payment client can store a merchant id, and a webhook runner can name a
remote endpoint. None of those local records grants authority in the remote
system.