Step 4d-2, part 1: REQUIRETLS (RFC 8689) through relays. Stacked on #261. Merge #261 first; until then this diff includes #261's commit.
What it does
Downstream: REQUIRETLS mail is no longer kept off relays. It is handed over with REQUIRETLS on mailFrom.
Relay: it applies the same rule as the server's own delivery. TLS is required with a WebPKI certificate valid for the MX host, unless DANE applies, and the message is never retried in the clear. REQUIRETLS is passed on MAIL FROM only when the next server offers it, as the server does.
TLS events: a REQUIRETLS failure with no MTA-STS policy is reported as no-policy-found, not sts.
Tests
Relay unit test: REQUIRETLS mail to a scripted MX with a self-signed certificate stays queued and isn't sent. Its TLS event says no-policy-found. A MAIL FROM test covers when the parameter is sent.
System test relay_link_tests: a submission with REQUIRETLS, sent through the relay to the scripted MX, which offers no STARTTLS. It stays queued on the downstream with "doesn't offer STARTTLS" and never reaches the MX. Before this, mail without REQUIRETLS went to that same MX in the clear.
smtp suite: 78 passed, 3 ignored. Also fmt, clippy on the touched crates and the fork checks.
A choice to check: like the server, the relay still delivers REQUIRETLS mail to a server that doesn't advertise REQUIRETLS, as long as TLS checks out. RFC 8689 §4.2.1 says to fail instead. Tightening that would be a separate change to both paths.
Still to come in step 4: the named inbuxaRelay route, and TLS-RPT reports built from the relay's outbound.tls events.
Step 4d-2, part 1: REQUIRETLS (RFC 8689) through relays. **Stacked on #261. Merge #261 first;** until then this diff includes #261's commit.
**What it does**
- **Downstream:** REQUIRETLS mail is no longer kept off relays. It is handed over with `REQUIRETLS` on `mailFrom`.
- **Relay:** it applies the same rule as the server's own delivery. TLS is required with a WebPKI certificate valid for the MX host, unless DANE applies, and the message is never retried in the clear. `REQUIRETLS` is passed on `MAIL FROM` only when the next server offers it, as the server does.
- **TLS events:** a REQUIRETLS failure with no MTA-STS policy is reported as `no-policy-found`, not `sts`.
**Tests**
- Relay unit test: REQUIRETLS mail to a scripted MX with a self-signed certificate stays queued and isn't sent. Its TLS event says `no-policy-found`. A MAIL FROM test covers when the parameter is sent.
- System test `relay_link_tests`: a submission with REQUIRETLS, sent through the relay to the scripted MX, which offers no STARTTLS. It stays queued on the downstream with "doesn't offer STARTTLS" and never reaches the MX. Before this, mail without REQUIRETLS went to that same MX in the clear.
- smtp suite: 78 passed, 3 ignored. Also fmt, clippy on the touched crates and the fork checks.
**A choice to check:** like the server, the relay still delivers REQUIRETLS mail to a server that doesn't advertise REQUIRETLS, as long as TLS checks out. RFC 8689 §4.2.1 says to fail instead. Tightening that would be a separate change to both paths.
Still to come in step 4: the named `inbuxaRelay` route, and TLS-RPT reports built from the relay's `outbound.tls` events.
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.
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.
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-2, part 1: REQUIRETLS (RFC 8689) through relays. Stacked on #261. Merge #261 first; until then this diff includes #261's commit.
What it does
REQUIRETLSonmailFrom.REQUIRETLSis passed onMAIL FROMonly when the next server offers it, as the server does.no-policy-found, notsts.Tests
no-policy-found. A MAIL FROM test covers when the parameter is sent.relay_link_tests: a submission with REQUIRETLS, sent through the relay to the scripted MX, which offers no STARTTLS. It stays queued on the downstream with "doesn't offer STARTTLS" and never reaches the MX. Before this, mail without REQUIRETLS went to that same MX in the clear.A choice to check: like the server, the relay still delivers REQUIRETLS mail to a server that doesn't advertise REQUIRETLS, as long as TLS checks out. RFC 8689 §4.2.1 says to fail instead. Tightening that would be a separate change to both paths.
Still to come in step 4: the named
inbuxaRelayroute, and TLS-RPT reports built from the relay'soutbound.tlsevents.