Step 4d of the relay spec, the downstream side of outbound (RL-20, RL-24).
What it does
sendThrough on any enabled relay sends every non-local recipient through relays: the enabled ones not marked inboundOnly that this node is linked to, one message after another in turn. A relay that refuses for now passes the message to the next. A refusal for good (tooLarge, forbiddenFrom) fails those recipients. With no relay linked, mail waits in the queue and is retried as usual.
Hand-over: the message is uploaded, then Outbound/set create over the delivering node's link. Its recipients stay in this server's queue, flagged, and show "Handed to relay ‹name›", then the remote server's reply. They aren't handed over again while they wait.
Follow: the link asks for Outbound push, and the lowest linked node checks every message handed to that relay from any node. A final status is recorded in the queue, which sends the DSNs as it does for its own deliveries. The relay's copy is then destroyed. If the relay has lost a message (after a reset), it is handed over again. A message cancelled here is destroyed on the relay too.
DeliveryStatus gains mx, the host the reply came from, so DSNs and the queue name the real remote server.
REQUIRETLS mail isn't handed to a relay yet; it takes its usual route.
Tests
System test relay_link_tests, which runs the real relay binary built with the new test-mx feature (all mail goes to one local port, and it is never in a release). Jane submits to a scripted MX. The relay delivers to bob, refuses nobody (550), and the downstream sends exactly one DSN (RL-T11). The message leaves both queues. A 451 deferral stays queued here, showing the remote server's reply. The test also runs relay_tests.
Unit tests: rotation skipping inboundOnly, an old link leaving a newer one in place, and reply parsing.
smtp suite: 78 passed, 3 ignored. Also fmt, clippy on the touched crates (no new warnings), and the fork checks.
Not in this PR (in the spec as still to come in step 4): the named inbuxaRelay route type, TLS-RPT reports from the relay's outbound.tls events, and REQUIRETLS through relays. A message handed to a relay that is then deleted waits here until it expires.
To build the test relay: cargo build -p inbuxa-relay --features test-mx.
Step 4d of the relay spec, the downstream side of outbound (RL-20, RL-24).
**What it does**
- `sendThrough` on any enabled relay sends every non-local recipient through relays: the enabled ones not marked `inboundOnly` that this node is linked to, one message after another in turn. A relay that refuses for now passes the message to the next. A refusal for good (`tooLarge`, `forbiddenFrom`) fails those recipients. With no relay linked, mail waits in the queue and is retried as usual.
- Hand-over: the message is uploaded, then `Outbound/set` create over the delivering node's link. Its recipients stay in this server's queue, flagged, and show "Handed to relay ‹name›", then the remote server's reply. They aren't handed over again while they wait.
- Follow: the link asks for `Outbound` push, and the lowest linked node checks every message handed to that relay from any node. A final status is recorded in the queue, which sends the DSNs as it does for its own deliveries. The relay's copy is then destroyed. If the relay has lost a message (after a reset), it is handed over again. A message cancelled here is destroyed on the relay too.
- `DeliveryStatus` gains `mx`, the host the reply came from, so DSNs and the queue name the real remote server.
- REQUIRETLS mail isn't handed to a relay yet; it takes its usual route.
**Tests**
- System test `relay_link_tests`, which runs the real relay binary built with the new `test-mx` feature (all mail goes to one local port, and it is never in a release). Jane submits to a scripted MX. The relay delivers to `bob`, refuses `nobody` (`550`), and the downstream sends exactly one DSN (RL-T11). The message leaves both queues. A `451` deferral stays queued here, showing the remote server's reply. The test also runs `relay_tests`.
- Unit tests: rotation skipping `inboundOnly`, an old link leaving a newer one in place, and reply parsing.
- smtp suite: 78 passed, 3 ignored. Also fmt, clippy on the touched crates (no new warnings), and the fork checks.
**Not in this PR** (in the spec as still to come in step 4): the named `inbuxaRelay` route type, TLS-RPT reports from the relay's `outbound.tls` events, and REQUIRETLS through relays. A message handed to a relay that is then deleted waits here until it expires.
To build the test relay: `cargo build -p inbuxa-relay --features test-mx`.
With sendThrough on, every non-local recipient is handed to a linked
relay that may send, in turn, skipping inboundOnly ones; with none
linked the mail waits in the queue (RL-20, RL-24). The queue marks the
recipients as handed to the relay and shows its replies. The lowest
linked node follows Outbound by push, records each final status so the
queue sends the DSNs, and destroys the relay's copy.
DeliveryStatus gains mx, the host a reply came from. The relay's
test-mx feature sends all mail to one local port for the system test,
which now covers hand-over, delivery, one DSN for a refusal (RL-T11),
and a deferral shown in the queue.
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.
Step 4d of the relay spec, the downstream side of outbound (RL-20, RL-24).
What it does
sendThroughon any enabled relay sends every non-local recipient through relays: the enabled ones not markedinboundOnlythat this node is linked to, one message after another in turn. A relay that refuses for now passes the message to the next. A refusal for good (tooLarge,forbiddenFrom) fails those recipients. With no relay linked, mail waits in the queue and is retried as usual.Outbound/setcreate over the delivering node's link. Its recipients stay in this server's queue, flagged, and show "Handed to relay ‹name›", then the remote server's reply. They aren't handed over again while they wait.Outboundpush, and the lowest linked node checks every message handed to that relay from any node. A final status is recorded in the queue, which sends the DSNs as it does for its own deliveries. The relay's copy is then destroyed. If the relay has lost a message (after a reset), it is handed over again. A message cancelled here is destroyed on the relay too.DeliveryStatusgainsmx, the host the reply came from, so DSNs and the queue name the real remote server.Tests
relay_link_tests, which runs the real relay binary built with the newtest-mxfeature (all mail goes to one local port, and it is never in a release). Jane submits to a scripted MX. The relay delivers tobob, refusesnobody(550), and the downstream sends exactly one DSN (RL-T11). The message leaves both queues. A451deferral stays queued here, showing the remote server's reply. The test also runsrelay_tests.inboundOnly, an old link leaving a newer one in place, and reply parsing.Not in this PR (in the spec as still to come in step 4): the named
inbuxaRelayroute type, TLS-RPT reports from the relay'soutbound.tlsevents, and REQUIRETLS through relays. A message handed to a relay that is then deleted waits here until it expires.To build the test relay:
cargo build -p inbuxa-relay --features test-mx.