66 lines
3.3 KiB
Markdown
66 lines
3.3 KiB
Markdown
# Queue, routing, and delivery
|
|
|
|
`bongoqueue` durably owns messages after SMTP or the external collector has
|
|
accepted them and before every recipient has reached a final destination. It
|
|
coordinates filtering, local Store delivery, remote SMTP, and LMTP; it is not
|
|
a public submission protocol.
|
|
|
|
## Message flow and durability
|
|
|
|
Queue data lives below `/var/lib/bongo/spool`. An accepted message remains
|
|
there while a temporary scanner, Store, DNS, SMTP, LMTP, or quota-dependent
|
|
delivery condition is retried. Permanent failures produce the configured
|
|
delivery-status response or bounce. The Queue must not acknowledge a message
|
|
to its upstream path before the payload and recipient state are durable.
|
|
|
|
Enabled filtering agents register for Queue stages. Antivirus,
|
|
SpamAssassin, rules/Sieve, and final local or remote delivery therefore see a
|
|
common envelope and message rather than independent copies. External POP3 or
|
|
IMAP collection enters this same path and may delete a source message only
|
|
after Bongo has committed it successfully.
|
|
|
|
The internal Queue protocol defaults to TCP 8670. Bind and firewall it as a
|
|
private service interface. It does not authenticate arbitrary Internet
|
|
clients and must never be exposed as an SMTP alternative.
|
|
|
|
## Limits and failure handling
|
|
|
|
The suffixless `queue` document controls spool free-space reservation,
|
|
message lifetime, retry interval, worker concurrency, trusted/hosted domains,
|
|
and bounce policy. `minimumfreespace` prevents normal acceptance from
|
|
consuming the filesystem's final space. Per-user Store quota is separate: a
|
|
full mailbox defers or rejects that recipient without corrupting other
|
|
recipient state.
|
|
|
|
A scanner outage is a delivery-policy decision, not permission to silently
|
|
bypass inspection. ClamAV and SpamAssassin failures leave the message queued
|
|
for the configured retry path. Likewise, a per-recipient LMTP temporary error
|
|
must preserve only that recipient for retry and must not redeliver recipients
|
|
which already returned a final success.
|
|
|
|
Queue control-file rewrites use a same-directory work file and an atomic
|
|
rename. The original is retained unless every buffered write and close
|
|
succeeds. A failed submission flush or final rename is rejected and its
|
|
partial entry discarded, so the submitting SMTP peer remains responsible for
|
|
retrying the message instead of receiving a false success.
|
|
|
|
## Administration and shutdown
|
|
|
|
Use `bongo-queuetool` to inspect and perform documented queue operations; do
|
|
not edit spool files manually. A service stop first prevents new work and asks
|
|
the managed agents to finish or abandon their current transaction safely.
|
|
Queue and Store state must be included in a consistent backup.
|
|
|
|
`bongo-queuetool message` exports the exact Queue-owned bytes. The
|
|
`hold-local`, `deliver-local`, and `delete` commands provide a bounded recovery
|
|
and diagnostic path: target 999 is not part of normal routing,
|
|
`deliver-local` retains its source entry, and `delete` must finish the
|
|
operation explicitly. The STQ-02 fixture uses these commands to compare the
|
|
Queue payload against the Store document, including the intentional Queue
|
|
trace header.
|
|
|
|
The 0.7 release matrix exercises byte preservation, disk exhaustion, retry,
|
|
expiry, bounce, hold/release, concurrency, invalid commands, quota mapping,
|
|
and collector floods under STQ-02 through STQ-12. SMTP and LMTP rows add their
|
|
protocol-specific recipient and retry cases.
|