Specs: ufw is in the way of the ACME test, and the rules say so

/etc/ufw/user.rules is world-readable, so this needed no privilege after
all. The default input policy is DROP and 8899 is not among the allowed
ports, so pebble's connection to the suite's listener is dropped. That
matches the live run, where twelve probes from a container completed no
handshake while the same openssl reached pebble's own TLS port.

The nc readings that pointed the other way — instant refusals on closed
ports, where a DROP should hang — are still unexplained, and are left on
the page as unexplained rather than quietly dropped, since they are what
sent an earlier pass through this page in the wrong direction.

Nobody has added the allow rule and re-run the suite, so the fix is
written down as a prediction. The cutover draft says the same: the test
failing here is not evidence that renewal works on the host.

docs/spec/container-tests.md

@@ -122,32 +122,36 @@ them.
   all, and the client polls as RFC 8555 section 7.5.1 says to.
 
   The suite still doesn't pass here. Half of the reason first recorded on
-  this page is wrong: pebble does validate, and the authorizations do not
-  stay pending. Whether `ufw` is in the way is still open. Checked on
+  this page was wrong — pebble does validate, and the authorizations do not
+  stay pending — and half was right: `ufw` is in the way. Checked on
   2026-09-19:
 
-  - **TCP reaches the host.** From containers on `stalwart-test-acme`, on
-    two different images, `nc` to the host's gateway addresses connects on
-    port 22 and is refused *immediately* on every closed port tried (8899,
-    9, 14000). A `ufw` DROP would hang until the timeout instead. No
-    firewall rule was read or changed to establish this — `ufw status`
-    needs a privilege this session doesn't have.
+  - **`ufw` does drop it, and the rules say so.** `/etc/ufw/user.rules` is
+    world-readable, so this needed no privilege in the end.
+    `DEFAULT_INPUT_POLICY="DROP"`, and the allow-list is 22, 2056, 6667,
+    29900, 28910, 13139, 6500 and 2300-2400. **8899 is not on it.** So
+    while the suite is listening, pebble's connection is dropped, which is
+    what a live run showed: twelve probes from a container completed no
+    handshake, with or without `-alpn acme-tls/1`, while the same
+    `openssl` in the same container talks to pebble's own TLS port and
+    prints its certificate.
 
-    **But the network question is not settled, and the probes disagree.**
-    `openssl s_client` against the same closed 8899 hung for its full
-    timeout instead of reporting the refusal `nc` had just seen. Worse,
-    during a live run — when the suite certainly is listening on 8899, it
-    takes `with_default_listeners()` — twelve probes from a container
-    completed no handshake at all, with or without `-alpn acme-tls/1`,
-    while the same `openssl` connects to pebble's own TLS port from the
-    same container and prints its certificate.
+    The rule that should fix it, narrowed to the ACME bridge:
 
-    A listener that is up but unreachable from a container is what a `ufw`
-    DROP looks like; an instant refusal when nothing listens is not. Both
-    were observed, minutes apart. Settling it needs `sudo ufw status
-    verbose`, and a listener bound by hand on `0.0.0.0:8899` to probe
-    against — neither of which this session could do. Until then the
-    original `ufw` suspicion is neither confirmed nor dismissed.
+    ```
+    sudo ufw allow from 172.21.0.0/16 to any port 8899 proto tcp \
+        comment 'ACME tests'
+    ```
+
+    **Unexplained, and left that way:** `nc` from two container images was
+    refused *immediately* on closed ports 8899, 9 and 14000, where a DROP
+    should hang until the timeout. That reading is what sent an earlier
+    pass through this page in the wrong direction. The live-run
+    observation and the rules agree with each other, so they are what this
+    entry rests on; the `nc` behaviour is noted rather than explained.
+
+    **Not yet retested.** Nobody has added the rule and re-run
+    `automation_tests`, so "this fixes it" is a prediction.
   - **Pebble does validate.** Its log shows 20 validation attempts in the
     regression run, five for each of `autoconfig`, `autodiscover`,
     `mta-sts` and `ua-auto-config.tls.org`, and it then sets each

docs/spec/cutover.md

@@ -15,11 +15,12 @@ has to do things nothing has yet asked of it:
 - hold INBUXA's ports (25, 465, 587, 143, 993, 110, 995, 443) under load,
   as an unprivileged user with `CAP_NET_BIND_SERVICE`;
 - keep certificates renewing. ACME renewal was found broken and fixed
-  (`309835b`), and the remaining test failure is unexplained
-  (`container-tests.md`, "What a plain regression leaves failing"). A
-  certificate that fails to renew is a 90-day fuse, not an outage on the
-  day, so it is the first thing to watch and the least likely to announce
-  itself;
+  (`309835b`), and the test that still fails here fails for a reason local
+  to this machine: `ufw` drops the port pebble validates against
+  (`container-tests.md`). That is not evidence the renewal works on the
+  host, only that the failure isn't the fork's. A certificate that fails to
+  renew is a 90-day fuse, not an outage on the day, so it is the first thing
+  to watch and the least likely to announce itself;
 - write to a store that the Enterprise build wrote until an hour earlier.
 
 The rehearsal below exists to turn those from assumptions into observations.