---
name: sender-rules-enforce-on-053-cutover
description: 0.53.0 cutover silently activates previously-inert sender-endpoint access rules — a refused message reads exactly like a delivery bug
metadata: 
  node_type: memory
  type: project
  originSessionId: 6412c22c-6c07-47a0-9145-4b336e1e8135
  modified: 2026-08-04T21:51:31.268Z
---

On 0.53.0, sender-endpoint access rules that were INERT on earlier versions become ENFORCED
(`ACCESS_SENDER_RULES_NOW_LIVE` — perri's finding, relayed by deployah 2026-08-04 during the fleet
roll). A node carrying a pre-cutover sender rule starts enforcing it SILENTLY the moment it runs
the new version: no migration notice, no rule change — the version IS the behavior change.

**Why:** the W2b authenticated sender stamp made tier-1 (sender-endpoint subject) matchable; rules
written while the tier was structurally inert (fed `None`, never matched) were unfalsifiable
no-ops, so stale/wrong rules could accumulate without symptom.

**How to apply:** when hunting a phantom delivery failure on or after a node's 0.53.0 cutover —
message QUEUED-then-vanished, SENT with no receipt, one peer unreachable while others work — run
`spt endpoint access` on the RECEIVING side BEFORE debugging transport. A refusal by a
newly-live sender rule is indistinguishable from a delivery bug at the sender. Fleet roll is
per-node (see [[unbound-endpoint-unwedge-procedure]] census), so mixed-version subnets show this
asymmetrically: the same rule inert on one node, enforced on its rolled peer.