Connecting an IMAP and SMTP server
Any IMAP and SMTP server can be a Connect mailbox. You supply the incoming and outgoing server details and the credentials; providers.build() constructs the adapter from the mailbox's transport and config, and everything after that — canonicalisation, triage, drafting, autonomy, audit — is identical to Gmail. A saved connection is a beginning, not a verdict.
Two protocols, two directions#
This is the one provider where you configure both directions yourself, because IMAP and SMTP are separate protocols on separate ports that fail separately. Gmail and Microsoft hide that behind a single API; your own server does not, and half a working connection is a real state you can end up in.
- Incoming (IMAP)
- The host, port and encryption your provider publishes, plus the account's credentials. This is what fetches mail into
tenant_*before the bridge canonicalises it. - Outgoing (SMTP)
- Usually a different host or at least a different port, sometimes different credentials. This is what
outbound.pyhands a message to when anything — Connect or a person — sends. - The address itself
- The identity the mailbox represents, which is what threads attach to and what a recipient sees.
The protocols themselves have their own background pages under Technology reference; this page is about what Connect does with a server that speaks them. The practical point is that the two halves are worth testing independently, because the symptom of a broken IMAP half and a broken SMTP half look nothing alike: one is silence, the other is drafts that never leave.
What saving proves, and what it does not#
A connection form can establish that a host answered, that it negotiated encryption, and that it accepted the credentials. Every one of those can be true of a mailbox that will never work for you — the account can be right and empty, the server can accept a login and refuse the folder, the SMTP host can authenticate and then reject the envelope for a sender it does not consider yours.
| Rung | What it proves | What it still does not |
|---|---|---|
| Saved without error | The details are well-formed and the servers were reachable | That any message will ever move |
| First sync completes | IMAP reads, and the bridge is producing canonical threads | That anything can be sent |
| Threads appear in Conversations | Canonicalisation and contact resolution ran | That the mailbox is the right one |
| One message sent, acknowledged | SMTP accepts your envelope and the provider acknowledged the handoff | What happens to it after your server — that is not something Connect can see or promise |
| Health verdicts settle | The row is reporting on what actually happened, over time | Nothing further — this is as far as the evidence goes |
Where IMAP differs from the API providers#
IMAP has no history ID. Where a Gmail mailbox resumes from a point in a change log, an IMAP mailbox resumes from a UID cursor, and the rules around that cursor carry real consequences — including the one that keeps a refused batch from being lost. IMAP UID and cursor lifecycle is the page for that, and it is worth reading before you connect a busy server rather than after.
There is also no write-back. Marking read and labelling are Gmail API actions; an IMAP mailbox has flags and folders of its own, and what Connect does with them is a property of the adapter rather than of the channel. Nothing about replying depends on it either way — a write-back failure never blocks a reply, and its absence does not either.
Credentials#
What you type into the connection form is sealed by settings_store on save and never echoed back to a screen, so it cannot be read out of Connect afterwards by anyone, including you. Re-entering is the way to change it.
If your server supports an application-specific password or a dedicated service account, prefer it to a person's own login. That is not a Connect requirement — it is the usual advice for any long-lived integration, and it makes the eventual disconnection a one-line change on your side rather than a password reset that surprises somebody.
Questions#
My server accepted the login but no mail appears.
Reaching the account is not the same as reading the right folder, and an authenticated mailbox that returns nothing is a recognised state rather than an error — see A quiet mailbox. Check that mail is actually arriving in the account, then the folder the adapter reads.
Can I use IMAP for reading and Gmail for sending?
No. A mailbox is one transport, and providers.build() constructs one adapter from it. Two transports means two mailbox rows, which would also mean two identities and two sets of threads.
Does Connect guarantee my mail is delivered once SMTP accepts it?
It cannot, and does not claim to. What is recorded is the provider's own acknowledgement of the handoff — that is what 'sent' means here. Anything after your server is between your server and the recipient's.