Module mailer 

Mailer capability trait. See plan/ecosystem/02-capabilities.md.

A MailerPlugin sends transactional email. The trait is shaped so that vendor-specific details never leak: @bext/mailer-smtp (lettre-backed) and @bext/mailer-ses (AWS SES) both satisfy the same surface, and a project can swap between them by editing bext.config.toml without touching code.

Design notes

• Pre-rendered bodies. Callers hand the mailer a fully rendered text and/or html body. Templating lives in the future Template capability; the mailer is a transport.
• Opaque message id. SendOutcome::id is a vendor-assigned string (SMTP Message-ID, SES MessageId, …) that callers treat as an opaque correlation handle. The trait makes no promises about its structure.
• Batch as a first-class op. SES natively sends many messages per API call and the cost difference matters. The default send_batch impl loops over send for transports that don’t batch natively.
• Generic error shape. MailerError variants classify failures in a way both SMTP and API backends can populate. No ses_error_code, no smtp_reply_code; backends that want to surface their own detail pass it in the variant’s String.

Structs

Address

An RFC 5322 mailbox: an email address plus an optional display name. Both SMTP and SES accept the same shape; neither drives the field layout.

Attachment

A single file attached to an outgoing message.

Message

A message to send. Pre-rendered: callers supply finished bodies.

SendOutcome

Result of a successful send.

Enums

MailerError

Why a send failed, classified in a backend-neutral way.

Traits

MailerPlugin

A plugin that sends transactional email.

Type Aliases

BatchOutcome

Per-message outcome for a batch send: success with an id, or failure with a classified error. The index in the returned vector lines up 1:1 with the index in the input vector, so callers can correlate partial failures.