Connect a mailbox
A mailbox in Alcarta is the configuration for one account at an external provider. It is not an IMAP folder and Alcarta does not import its messages.
Choose an authentication path
Section titled “Choose an authentication path”| Provider | Supported path |
|---|---|
| Gmail or Google Workspace | Provider OAuth, or an application password where the account permits it |
| Microsoft 365 | Provider OAuth |
| Fastmail | Application password |
| Generic IMAP + SMTP | Password or application password |
| JMAP provider | Provider-specific JMAP credential |
Microsoft 365 connections require OAuth. For Gmail and Microsoft 365, the deployment can offer a shared provider client, or an organization admin can register an organization-specific client.
Add the mailbox
Section titled “Add the mailbox”- In Mailboxes, select Add a mailbox.
- Choose a provider preset or enter the backend, host, port, and TLS settings explicitly.
- Save the mailbox. It begins in
unconfiguredstate. - Add its credential:
- For OAuth, choose Sign in with the provider and complete the provider consent flow.
- For a password or application password, store it on the mailbox page.
- Select Test connection.
The connection test opens each configured protocol, checks authentication, and discovers special
folders. A mailbox becomes active only after this test succeeds. A failed test returns per-protocol
diagnostics and leaves the mailbox unavailable to tools.
Check the folder map
Section titled “Check the folder map”Alcarta uses roles such as inbox, archive, trash, spam, sent, and drafts. Direct actions
like archive and trash resolve through this map; Alcarta never guesses a provider folder name.
Review the discovered map and correct missing roles before granting an agent access. An action that needs an unmapped role fails rather than creating a folder.
Credential behavior
Section titled “Credential behavior”Mailbox credentials are write-only. After storage, neither the REST API nor the web interface can return the plaintext. Replacing a credential writes a new encrypted value.
Provider and webhook destinations are protected by an outbound network guard. Hostnames are resolved and checked against denied private ranges and the allowed port policy before a connection is made.