IMAP and SMTP mail accounts

Metnos can use mailboxes from non-Google providers. Standard mail uses IMAP for reading and SMTP for sending; Google Workspace remains a separate backend for Gmail-specific functions.

Account identity

Each account has a stable name, such as work. Its encrypted vault binding is smtp_work; mail executors receive account="work". account="all" reads all configured accounts and aggregates the results; an explicit list of names is also valid.

Preferred configuration

Ask Metnos with a request like this example: “Explain how to configure a non-Google mail account named work with IMAP and SMTP, without putting the password in the message.”

The encrypted smtp_<name> record contains:

Field	Meaning
`user`, `password`	Mailbox credentials.
`imap_host`, `imap_port`	Read server; typical port 993.
`smtp_host`, `smtp_port`	Send server; typical SMTPS port 465. It may be omitted for a read-only account.
`verify_tls`	TLS verification, enabled by default; disabling it requires an explicit administrative decision.

Contract example, with secret values replaced by placeholders:

set_credentials(
  binding="smtp_work",
  fields={
    "user": "[email protected]",
    "password": "<password>",
    "imap_host": "imap.example.test",
    "imap_port": 993,
    "smtp_host": "smtp.example.test",
    "smtp_port": 465,
    "verify_tls": true
  }
)

During an interactive installation, the Sensitive data phase can create one or more accounts. After installation, the same structure can be stored with set_credentials; values enter the local encrypted vault, while responses and telemetry expose metadata only.

Compatibility with earlier configurations

A mode-0600 file at ~/.config/metnos/mail/<name>.env remains accepted with fields HOST_IMAP, PORT_IMAP, HOST_SMTP, PORT_SMTP, USER, PASS, and VERIFY_TLS. The encrypted vault takes precedence; the file is a compatibility and migration path.

Boundaries

read_messages reads IMAP; send_messages sends SMTP; move_messages manages IMAP folders. Gmail labels, Gmail threads, and other provider-specific features remain in the Google Workspace backend.

Passwords must not be placed in documentation, manifests, or logs. When supplied through a chat credential flow, they are extracted before the planner, encrypted, and replaced by a redaction marker.