Accounts, mailboxes, and confirmed changes
These terms explain who signs in, which data an action affects, and when a change is complete.
Login identity
Your login identity is the MailGen application account. The Account service creates the browser session through email/password or a configured social provider. A Microsoft or Google sign-in proves an application identity. It does not itself import a mailbox or grant access to another user's mail.
Operators configure this separately in account login setup.
Mailbox identity
A mailbox identity identifies the provider mailbox. Microsoft access requires Microsoft Graph setup. Personal Gmail uses a separate consent flow from Google Cloud setup.
A connected account links mailbox access to the application user. Mailbox ownership and feature permissions still restrict requests. A directory entry is not automatically an onboarded mailbox.
Onboarding creates the initial local mailbox data, file objects, search data, and synchronization state. It can continue after the user signs in.
Actor identity and permissions
The authorization actor is the application user who requests an action. The actor can differ from the mailbox subject. Group membership and grants determine what the actor can do. A provider administrator's identity does not bypass MailGen authorization checks.
A tenant is the deployment or organization boundary for authorization. Keep its stable identifier when you move existing data. An email address or display name does not replace this identifier.
Accepted and confirmed writes
Accepted means the application accepts or queues the request. It does not prove that the provider stores the requested state.
Confirmed means the operation reaches its documented confirmation condition. For Microsoft synchronization, inspect the operation and later synchronized state in the Sync Center. Local changes and provider changes can follow different paths. Support varies by operation and provider.
Kafka preserves background work. A queue record, published event, or running container is not a provider confirmation.
Keys and storage
The application session, personal email key, mailbox grant key, Graph delta key, webhook certificate, and Office signing key serve different purposes. A new password or login cannot replace a lost encryption key. Use personal-key backup and unlock for the owner's email key and encryption settings for its policy. Environment-secret backup covers different files and does not restore the personal key.
A Docker volume stores persistent service data. A stop or restart preserves it. A reset can delete it. Read daily commands before operating the stack.