IMAP is a stateful mailbox protocol, not a REST API and not a sending protocol; a production connector must pair it with secure authentication, SMTP submission, capability discovery, and mailbox-specific sync state.
IMAP lists and manipulates mailboxes and messages. Outbound mail requires SMTP submission or a provider API. Keep the two connection checks and error states separate even when the product presents one mailbox account.
IETF guidance treats cleartext mail access and submission as obsolete and recommends TLS 1.2 or later, with implicit TLS preferred. OAuth can be carried through SASL, but server support and provider setup vary; never silently downgrade to cleartext.
IMAP sequence numbers can change during a session and are not durable IDs. A cached message identity must include the mailbox and UID validity state; when UIDVALIDITY changes, the connector must rebuild that mailbox's mapping.
Servers differ in supported extensions, flags, folder conventions, limits, IDLE behavior, and authentication. Test capability responses, reconnect idle connections, reconcile periodically, and retain raw server responses for support.
No. Sequence numbers can be reassigned. Use the mailbox plus UIDVALIDITY and UID, and rebuild the mapping if UIDVALIDITY changes.
The standards define SASL OAuth mechanisms, but each provider and server decides what it supports and how applications are registered. Capability and configuration checks are required.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.