Cover other mailboxes without hiding protocol differences

The planned protocol connector pairs IMAP mailbox access with SMTP submission, negotiates each server's capabilities, and maps confirmed changes into the shared email model. It is not implemented.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Capability boundary

IMAP/SMTP is a planned open-protocol connector

The catalog defines target mailbox reads, updates, sends, folders, and received/updated events. TLS-only credential handling, capability negotiation, provider fixtures, and real mailbox tests remain release gates.

Catalog status and access: IMAP and SMTP — planned, open protocol
Authentication: Each account needs explicit secure server settings and a provider-supported password, app password, or OAuth/SASL mechanism. DewEngine must validate certificates and never downgrade to cleartext access or submission.
Resources: mailboxes, threads, emails, drafts, folders, attachments
Target actions: email.list, email.get, email.send, email.update, folder.list
Target events: email.received, email.updated
Limitations and failures: No IMAP or SMTP runtime is implemented; IMAP reads mail but does not submit messages; Capabilities, flags, folders, notifications, and authentication vary by server
Release gates: IMAP and SMTP — TLS-only credential handling and provider capability negotiation

Protocol split

Use IMAP for mailbox state and SMTP for submission

The connection model must store and test both sides when sending is required. A healthy IMAP login does not prove SMTP authorization, sender identity, delivery behavior, or that the provider permits the same credentials for submission.

Secure connection

Negotiate authentication and capabilities without fallback

The connector should validate TLS, discover server capabilities, select an explicitly configured authentication mechanism, and fail closed when the server cannot satisfy the customer's security policy.

Mailbox state

Track each folder with provider-native identity

Folder names, UID validity, flags, and server extensions vary. A future worker needs per-folder checkpoints, stable provider keys, deletion handling, and a controlled rebuild when mailbox identity changes.

Change detection

Publish events only after a change is confirmed

A server may support a long-lived notification mechanism or require scheduled checks. DewEngine should translate confirmed mailbox changes into received or updated events while reconciliation remains the source of completeness.

Operations

Make server variation and reconnect work visible

Certificate failures, authentication changes, connection limits, oversized messages, folder renames, timeouts, and partial command results need raw diagnostics and normalized recovery states. Provider-specific fixtures are required before claiming broad compatibility.

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Does IMAP send email?+

No. The planned connector pairs IMAP mailbox access with SMTP submission for sending.

Will every IMAP server behave identically?+

No. Authentication, extensions, folder semantics, flags, limits, and notification behavior require capability negotiation and provider-specific tests.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗