First part of relay step 5: the server object the console's Relays page reads.
inbuxa:RelayMessage/get, /query (filter relayId, direction; newest first) and /set (destroy only), with sysRelayQueueGet / sysRelayQueueUpdate. The asking node reads the relay's Inbound and Outbound over its own link; the blob is never shown.
Ids are stateless: relay id in the top 16 bits plus a 48-bit hash of the relay's message id, so every node names a message the same way and nothing is stored.
Destroying held mail discards it at the relay (refused while a node is taking it).
Cancelling an outbound message fails its recipients here first, with no DSN (like a queue cancel), so the queue never hands it over again, then destroys the relay's copy. If the relay is mid-attempt, it drops it at the next status: apply_relayed now returns Gone when no recipient still waits on the relay, and the follower destroys it.
Every destroy goes through the audit log with its reason; the privacy catalog lists the object.
Tested: unit test for the ids; relay_link_tests (local only, ignored in CI) reads the deferred outbound message with its remote reply and queue id, cancels it, and sees it gone from both queues with no DSN. relay_tests passes; smtp suite 78 passed in 3 of 5 runs. The other 2 failed lmtp_delivery, an upstream test that counts DSNs on a 100 ms sleep loop; it passes alone every time and touches nothing changed here. fmt, clippy on the touched files and the fork checks are clean.
First part of relay step 5: the server object the console's Relays page reads.
- `inbuxa:RelayMessage/get`, `/query` (filter `relayId`, `direction`; newest first) and `/set` (destroy only), with `sysRelayQueueGet` / `sysRelayQueueUpdate`. The asking node reads the relay's `Inbound` and `Outbound` over its own link; the blob is never shown.
- Ids are stateless: relay id in the top 16 bits plus a 48-bit hash of the relay's message id, so every node names a message the same way and nothing is stored.
- Destroying held mail discards it at the relay (refused while a node is taking it).
- Cancelling an outbound message fails its recipients here first, with no DSN (like a queue cancel), so the queue never hands it over again, then destroys the relay's copy. If the relay is mid-attempt, it drops it at the next status: `apply_relayed` now returns `Gone` when no recipient still waits on the relay, and the follower destroys it.
- Every destroy goes through the audit log with its `reason`; the privacy catalog lists the object.
Tested: unit test for the ids; `relay_link_tests` (local only, ignored in CI) reads the deferred outbound message with its remote reply and queue id, cancels it, and sees it gone from both queues with no DSN. `relay_tests` passes; smtp suite 78 passed in 3 of 5 runs. The other 2 failed `lmtp_delivery`, an upstream test that counts DSNs on a 100 ms sleep loop; it passes alone every time and touches nothing changed here. fmt, clippy on the touched files and the fork checks are clean.
The Relays page needs to show what waits at each relay, and to let an
administrator discard held mail or cancel an outbound message, without
ever talking to a relay itself (relay spec, "Registry objects").
inbuxa:RelayMessage has get, query and set (destroy only) under
urn:inbuxa:jmap, with sysRelayQueueGet and sysRelayQueueUpdate. The asking
node reads the relay's Inbound and Outbound over its own link, through a
new call on the link's sender, and shows each message's envelope, size,
times and state: the session and door checks for inbound mail, the
per-recipient status and retry state for outbound, and the message in
this server's queue it was handed from. Never the blob. Query filters by
relayId and direction, newest first. Nothing is stored: an id is the
relay's id (top 16 bits) and a hash of the relay's own message id, so
every node names a message the same way, and a lookup checks it against
the relay's queues. A relay this node can't reach is left out of a query
of all relays and is an error when asked for by itself.
Destroying held mail destroys it at the relay, unless a node is taking
it just then. Cancelling an outbound message fails its recipients here
first, with no DSN, the way a delivery cancelled in the queue does, so
the queue never hands it over again; then the relay drops it. If the
relay is sending it at that moment, it drops it at its next status: the
follower now also destroys the relay's copy when none of its recipients
waits on the relay any more. Every destroy is audited, with its reason.
Test: unit test for the ids. The relay system test reads the relay's
outbound queue, finds the deferred message with the remote server's
reply and its queue id and no blob, cancels it, and sees it gone from
both queues with no DSN; a second destroy is notFound and an update is
forbidden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
First part of relay step 5: the server object the console's Relays page reads.
inbuxa:RelayMessage/get,/query(filterrelayId,direction; newest first) and/set(destroy only), withsysRelayQueueGet/sysRelayQueueUpdate. The asking node reads the relay'sInboundandOutboundover its own link; the blob is never shown.apply_relayednow returnsGonewhen no recipient still waits on the relay, and the follower destroys it.reason; the privacy catalog lists the object.Tested: unit test for the ids;
relay_link_tests(local only, ignored in CI) reads the deferred outbound message with its remote reply and queue id, cancels it, and sees it gone from both queues with no DSN.relay_testspasses; smtp suite 78 passed in 3 of 5 runs. The other 2 failedlmtp_delivery, an upstream test that counts DSNs on a 100 ms sleep loop; it passes alone every time and touches nothing changed here. fmt, clippy on the touched files and the fork checks are clean.