relay: TLS-RPT reports from relays' TLS results

jcoffey-dev commented

2026-10-30 17:03:17 +00:00

Owner

Step 4d-2, part 2: the downstream's TLS-RPT reports (RFC 8460) include the relay's sessions. Stacked on #262, which is stacked on #261. Merge #261, then #262, then this.

What it does

Relay: each outbound.tls event now carries the policy that applied as structured data: tlsa (the TLSA records) for DANE, or sts (the MTA-STS policy). policyStrings stays as before for people to read.
Downstream: the node that takes a relay's events turns each outbound.tls into a TlsEvent for its report scheduler. The policy type and policy come from the event, and so do the result type (TLS-RPT names, anything unknown becomes other), the MX host, the IP and the reason. A success counts as a successful session.
Same rules as the server's own sessions: the TLS report send frequency is evaluated for the recipient domain, and nothing is reported unless the domain publishes _smtp._tls.

Tests

Unit test for the event → TlsEvent mapping: no policy with success, DANE with a validation failure (records, MX, IP, reason), MTA-STS with an unknown result type, and an event with no domain is ignored.
Relay delivery tests now check that the DANE and MTA-STS events carry the structured policy.
System test relay_link_tests: remote.test publishes TLS-RPT. The relay's STARTTLS failure for REQUIRETLS mail shows up in the downstream's queued TLS report as starttls-not-supported. The downstream never connects to remote.test itself, so that entry can only have come from the relay.
smtp suite: 78 passed, 3 ignored. Also fmt, clippy on the touched crates and the fork checks.

One difference from the server's own deliveries: the server leaves report messages out of TLS reports. Relay events don't say which message a session carried, so sessions that delivered reports are counted too.

Left in step 4: the named inbuxaRelay route type.

Step 4d-2, part 2: the downstream's TLS-RPT reports (RFC 8460) include the relay's sessions. **Stacked on #262, which is stacked on #261. Merge #261, then #262, then this.** **What it does** - **Relay:** each `outbound.tls` event now carries the policy that applied as structured data: `tlsa` (the TLSA records) for DANE, or `sts` (the MTA-STS policy). `policyStrings` stays as before for people to read. - **Downstream:** the node that takes a relay's events turns each `outbound.tls` into a `TlsEvent` for its report scheduler. The policy type and policy come from the event, and so do the result type (TLS-RPT names, anything unknown becomes `other`), the MX host, the IP and the reason. A success counts as a successful session. - **Same rules as the server's own sessions:** the TLS report `send` frequency is evaluated for the recipient domain, and nothing is reported unless the domain publishes `_smtp._tls`. **Tests** - Unit test for the event → `TlsEvent` mapping: no policy with success, DANE with a validation failure (records, MX, IP, reason), MTA-STS with an unknown result type, and an event with no domain is ignored. - Relay delivery tests now check that the DANE and MTA-STS events carry the structured policy. - System test `relay_link_tests`: `remote.test` publishes TLS-RPT. The relay's STARTTLS failure for REQUIRETLS mail shows up in the downstream's queued TLS report as `starttls-not-supported`. The downstream never connects to `remote.test` itself, so that entry can only have come from the relay. - smtp suite: 78 passed, 3 ignored. Also fmt, clippy on the touched crates and the fork checks. **One difference from the server's own deliveries:** the server leaves report messages out of TLS reports. Relay events don't say which message a session carried, so sessions that delivered reports are counted too. Left in step 4: the named `inbuxaRelay` route type.

jcoffey-dev added 3 commits 2026-10-30 17:03:17 +00:00

relay: hand outbound mail to relays and follow its status

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 10m26s

Details

dd2554aa82

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.

relay: send REQUIRETLS mail through relays

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 13m46s

Details

fc2923fd48

The downstream hands REQUIRETLS mail to a relay with the parameter
instead of keeping it off relays. The relay treats it as the server's
own delivery does: TLS required with a WebPKI certificate unless DANE
applies, never retried in the clear, and REQUIRETLS passed on where
the next server offers it. Its TLS failures report no-policy-found
unless an MTA-STS policy applied.

relay: TLS-RPT reports from relays' TLS results

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 32m27s

Details

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

19dd3725c4

The relay's outbound.tls events carry the TLSA records or MTA-STS
policy that applied. The node taking a relay's events turns each into
a TlsEvent for this server's TLS-RPT reports, with the same send
frequency, only for domains that publish a TLS-RPT record.

jcoffey-dev merged commit d674b41ee6 into main

2026-10-30 17:36:32 +00:00

jcoffey-dev deleted branch relay/outbound-tlsrpt

2026-10-30 17:36:32 +00:00

relay: TLS-RPT reports from relays' TLS results #263