Design a durable Haraka application handoff
Choose the queue boundary, preserve envelope recipients and raw mail, and avoid acknowledging SMTP before required work is safely stored.
Reviewed
A plugin can inspect SMTP events, but an application integration also needs a durability contract. Decide exactly which component owns accepted mail and retries when a downstream parser or HTTP endpoint is unavailable.
Choose the acceptance boundary
- Review Haraka’s plugin and queue documentation linked from the official guide.
- Select the appropriate message/queue hook for your installed release. Recipient policy belongs before acceptance; durable message handoff must complete according to the queue plugin contract.
- Persist the original message and authoritative envelope metadata, or require a successful durable downstream acceptance before returning SMTP success.
- Define temporary failure, permanent rejection, timeout, and duplicate-processing behavior explicitly.
Do not invoke an LLM or slow external workflow directly inside the SMTP transaction. Queue bounded work and process it asynchronously after durable acceptance. Never return success simply because a network request was started.
Authenticate the downstream service
Use an authenticated transport and independently configured secret. A custom Haraka HTTP POST does not automatically carry MailKite’s signature or payload contract; use the real implemented receiver protocol.
Test an unavailable store, duplicate delivery, malformed MIME, multiple envelope recipients, and an HTTP timeout using controlled fixtures. Protect raw content and impose size limits. Confirm which component retries and how operators recover stuck work. IMAP access and reply sending remain separate capabilities, not consequences of a plugin returning successfully.