inbuxa Relay: relay events in the trace, and the link-down alert #255
Assignees
jcoffey-dev (John Coffey)
Clear assignees
jcoffey-dev (John Coffey)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: inbuxa/inbuxa-server#255
Reference in new issue
Block a user
The rest of steps 2 and 3 of docs/spec/features/relay.md, apart from
inbuxa:RelayMessage ("The link service", RL-T23):
labels and explanations: relay.session, relay.message-accepted,
relay.message-refused, relay.message-expired (warning),
relay.joined, relay.recipients-replaced, relay.event for any other
type the relay reports, relay.link-down (warning) and relay.link-up.
Each names the relay by its id and public hostname.
the lowest id (by the link records, fresh within three minutes) reads
the relay's events, emits them as relay.* events, and acknowledges
them, so the relay forgets them (RL-22). Events wait on the relay
until one node takes them, so none is lost while no node is linked.
relay.link-down once, with the last error, and relay.link-up when the
link is back. Both reach the log, webhooks and OpenTelemetry. A relay
that never joined holds no mail and raises nothing.
once Outbound exists to show beside Inbound (spec status updated).
large_futures).
event while the link was off, and that every event was acknowledged
once it was back. Unit test for the alert's timing.
Stacked on #254: it carries #254's commit until that one merges, so
merge #254 first.
Checks run locally: both relay system tests, the trc and services unit
tests, rustfmt, clippy on the changed files, expr-schema --check, and the
fork checks. The relay.* events' own text isn't asserted by a test; the
system test shows they were read and acknowledged.
The third server-side part of docs/spec/features/relay.md ("Live mode", "Handing held mail down", "Ingest with session context"): - The link service asks for Inbound push as well as Relay, so the relay is live while a node is linked (RL-12). It claims up to eight messages at a time with a 300 s lease (RL-15), downloads each on its own connection, and unseals it with the downstream's sealing key (RL-21). - smtp::inbound::relayed plays the relay's session through this server's own handlers: connect (rate limits, scripts, milters), EHLO, MAIL FROM, each RCPT TO, then DATA, on port 25 with the original sender's address, port and HELO (RL-23). SPF, reverse IP, DMARC, DNSBL, the spam filter, the AI classifier, Sieve and the directory see the real facts. The relay's TLS shows in the Received header and in is_tls, and a new expression variable, relay, is the relay's name (id 92, in the connect, EHLO, MAIL FROM and RCPT contexts, with its schema label). - Live: this server's reply is the verdict. Accepted, the message is destroyed on the relay and the sender hears 250; refused, the relay gives the sender this server's reply. - Held: spam over the reject threshold goes to Junk with X-Inbuxa-Relay: held, over reject threshold, never refused or dropped (RL-17). Recipients refused for good get a DSN only when the sender passed SPF or DMARC here (RL-18); a refusal for now is tried again after the lease. - Every message taken is recorded before the relay is told, and one offered again is destroyed without a second delivery (RL-16). The records are forgotten after heldMaxAge and a day, and with the relay. - On the relay, a message waiting for its verdict stays pending when claimed, so the downstream knows to answer it (spec table updated). - The spec records the external-directory decision: such domains list only the accounts already seen, with no catch-all. - The link system test now sends mail through the real inbuxa-relay: live delivery before 250, a live refusal (too many Received headers) that reaches the sender as 450 4.4.6 with nothing kept, and a message held while the link was off, delivered once when it came back.The rest of steps 2 and 3 of docs/spec/features/relay.md, apart from inbuxa:RelayMessage ("The link service", RL-T23): - A new trace event category, relay, ids 650 to 658, with schema labels and explanations: relay.session, relay.message-accepted, relay.message-refused, relay.message-expired (warning), relay.joined, relay.recipients-replaced, relay.event for any other type the relay reports, relay.link-down (warning) and relay.link-up. Each names the relay by its id and public hostname. - The link service asks for RelayEvent push too. The linked node with the lowest id (by the link records, fresh within three minutes) reads the relay's events, emits them as relay.* events, and acknowledges them, so the relay forgets them (RL-22). Events wait on the relay until one node takes them, so none is lost while no node is linked. - RL-T23: a node with no link to a joined relay for an hour raises relay.link-down once, with the last error, and relay.link-up when the link is back. Both reach the log, webhooks and OpenTelemetry. A relay that never joined holds no mail and raises nothing. - inbuxa:RelayMessage moves to step 5, with inbuxa-admin's Relays page, once Outbound exists to show beside Inbound (spec status updated). - The relayed message's judging and ingest futures are boxed (clippy large_futures). - The link system test checks the relay recorded the held message's event while the link was off, and that every event was acknowledged once it was back. Unit test for the alert's timing.