mail relay configured

docs/ENVIRONMENT.md

@@ -4,9 +4,9 @@ Specification for a Mechanical Compiler instance.
 
 | | |
 |---|---|
-| Revision | 5 (2026-08-16) |
+| Revision | 5.1 (2026-08-17) |
 | Supersedes | Revisions 1 through 4 |
-| Basis | Revision 4, reconciled against the proven staging build on `srv-b` |
+| Basis | Revision 4, reconciled against the proven staging build, then work order 002 |
 | Scope | **Host-agnostic.** Applies to any instance. |
 | Instance state | `STAGING-STATE.md`, and later `PRODUCTION-STATE.md` |
 | Failure evidence | `FAILURES.md` |
@@ -623,19 +623,45 @@ Nothing else.
 
 ## 12. Mail and monitoring
 
-**DEFERRED — end-to-end alerting is not accepted.** See F-023.
+**REQ** — **SMTP 250 from a relay and an empty local queue prove handoff, not
+delivery.** Alerting acceptance requires demonstrated end-to-end receipt, twice,
+with full headers captured. This is the whole content of F-023: a message can be
+accepted by every hop and still be rejected at the last one.
 
-**REQ when resumed** — **SMTP 250 from a relay and an empty local queue prove
-handoff, not delivery.** Alerting acceptance requires demonstrated end-to-end
-receipt. Until then, mail, disk monitoring and any mail-dependent backup
-alerting are unaccepted.
+**REQ** — Diagnose relay problems with **RCPT-only probes, over every address
+family, before and after any change**, with no message body sent. A `554`
+before and a `250` after proves the change caused the fix rather than
+coinciding with it.
+
+**REQ (F-024)** — On a Proxmox host, inspect mail logs with
+`journalctl -u postfix@-`. There is no `rsyslog` and no `/var/log/mail.log`.
+Automation that greps a logfile path finds nothing silently, which is worse than
+failing.
 
 **REQ** — Disk monitoring must be configured **explicitly per device** where the
 controller does not present members to automatic scanning. An active
 `smartmontools.service` monitoring zero devices is not monitoring, and is easy
-to mistake for success.
+to mistake for success. Acceptance is a delivered test alert, not an active
+unit.
 
----
+### 12.1 Downstream infrastructure is out of bounds
+
+**REQ** — An instance may configure its own relay client. It may not alter the
+mail infrastructure it relays through. Where a downstream change is genuinely
+required, it is escalated with evidence, not made locally.
+
+Two standing constraints apply to this estate:
+
+| Host | Constraint |
+|---|---|
+| The final mailbox host | Runs YunoHost. Its mail configuration must not be altered — which is the reason a separate relay exists. |
+| The relay MTA | Uses DANE. Its TLS and certificate configuration must not be broken. Client-trust changes such as `mynetworks` do not interact with DANE; certificate changes do. |
+
+**REQ (F-025)** — Record what a trust change **grants**, not only what it
+repairs. `permit_mynetworks` is destination-agnostic: authorising a client to
+fix one rejected recipient authorises it for every destination. Where an
+instance's containers have no reason to originate mail, block SMTP egress at the
+instance boundary rather than relying on downstream policy to refuse it.
 
 ## 13. Instance parameters
 
@@ -702,10 +728,12 @@ scaffolding survives a reboot.
 **PROVEN (F-021)** — the reboot is not optional. Connectivity can be perfect
 while boot is degraded.
 
-### Gate 2 — Deferred operational services
+### Gate 2 — Operational services
 
-Mail delivered **end to end and received**. Disk monitoring reporting a non-zero
-device count. Not gated on gate 1.
+Mail delivered **end to end and received twice**, with full headers captured, an
+empty queue and no deferred entries. Disk monitoring reporting a **non-zero
+device count** and a delivered test alert. Container SMTP egress blocked where
+the containers have no reason to originate mail. Not gated on gate 1.
 
 ### Gate 3 — Application runtime