From 482fdee287bb3557124195c5f0e79e7b87ce9f9c Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 18 Oct 2026 14:07:14 +0200 Subject: [PATCH] MAS-WP-0003-T04: Google Groups results (lower-cases members); T04 done Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 252470@bnt-lap001 Assistant-Session: ad628c8f-4be2-4979-94c9-76c7ed6f8241 --- docs/experiment-review.md | 25 ++++++++++++++++++++- docs/spec-change-proposals.md | 12 ++++++++-- workplans/MAS-WP-0003-provider-live-test.md | 14 ++++++++++-- 3 files changed, 46 insertions(+), 5 deletions(-) diff --git a/docs/experiment-review.md b/docs/experiment-review.md index b9e7d7a..7f08e0d 100644 --- a/docs/experiment-review.md +++ b/docs/experiment-review.md @@ -172,7 +172,30 @@ real failure in the run. nothing in the statute gives `ticket--…` resource meaning. See SCP-6 (declared alternate separator) and SCP-7 (identifier case). -**Still untested (T04):** a mailing list (VERP). +**Mailing list (T04, Google Groups, 2026-10-18):** +- **The member form accepted `=` and capitals:** + `ticket=GS-85QJ8WC09P+comments@` was accepted. The invitation was + delivered to it byte-identical (Auto-Submitted: auto-generated) and was + correlated to the ticket. +- **After acceptance, Google stored the member in lower case.** The list + post arrived for `ticket=gs-85qj8wc09p+comments@`. The envelope sender + was the per-message bounce address + `coulomb-social+bncBDG…@googlegroups.com`, which tags the list's own + local-part and does not touch ours, so there is no collision with `=` + or `+`. +- **With exact comparison the post did not match the ticket.** The service + quarantined it as an unknown resource and did not reply + (`Precedence: list`). That is correct under v0.1, but the post was lost + to the ticket. + +**T04 conclusion:** +- SRS and list bounce addresses never collide with MAS syntax, because they + rewrite or tag the *sender*. +- Facets survived every path. +- The real risks are **provider forms**: IONOS refuses `=`, and **two of + two** forwarding/list providers (IONOS, Google Groups) lower-case the + recipient. Case-sensitive resource identifiers do not survive + forwarding or lists, which makes SCP-7 the most consequential proposal. ### Resource addressing: did it improve correlation? Yes. The service replies *from* `ticket=GS-…@great-service.example`, so an diff --git a/docs/spec-change-proposals.md b/docs/spec-change-proposals.md index 72ea463..228210a 100644 --- a/docs/spec-change-proposals.md +++ b/docs/spec-change-proposals.md @@ -100,7 +100,9 @@ to MAS addresses carrying an `@domain`. Pending: SRS and VERP (MAS-WP-0003 T04). **Counter-evidence (T04):** the IONOS forwarding form refused `=` and -forced lower case (SCP-6, SCP-7). Mail *clients* preserved MAS syntax; +forced lower case. Google Groups accepted `=` but lower-cased the member +address (SCP-6, SCP-7). SRS and list bounce addresses never collided with +`=` or `+`. Mail *clients* preserved MAS syntax; provider *configuration forms* did not. **Proposal:** keep the normative text. Add an informative note recording @@ -176,11 +178,17 @@ A candidate for v0.2 rather than errata. **Sections:** §6.2 Resource identifiers, §8 Address equivalence, §13. **Evidence:** the IONOS forwarding form forces destination addresses to -lower case: `GS-85QJ8WC09P` became `gs-85qj8wc09p`. With the spec default +lower case: `GS-85QJ8WC09P` became `gs-85qj8wc09p`. Google Groups did the +same after a member accepted the invitation: the invitation was delivered +mixed-case, but list mail went to the lower-cased address and was +quarantined as an unknown resource. With the spec default (exact comparison) and a statute declaring `case: exact`, the identifier no longer matches. Many systems treat local-parts as case-insensitive in practice, despite RFC 5321. +**Priority:** highest of this set. Two of two forwarding/list providers +lower-cased the recipient. + **Proposal:** - §6.2: "Generators SHOULD use resource identifiers whose meaning does not depend on letter case (for example lower-case only, or a case-insensitive diff --git a/workplans/MAS-WP-0003-provider-live-test.md b/workplans/MAS-WP-0003-provider-live-test.md index a57689e..418b92e 100644 --- a/workplans/MAS-WP-0003-provider-live-test.md +++ b/workplans/MAS-WP-0003-provider-live-test.md @@ -167,7 +167,7 @@ address and what envelope recipient arrives. ```task id: MAS-WP-0003-T04 -status: progress +status: done priority: medium state_hub_task_id: "97c88b4f-14c3-5f6c-8f31-6b9fc3afd236" ``` @@ -188,7 +188,17 @@ or are stripped. separator; the operator endorses the mapping) and SCP-7 (case-robust identifiers). Gmail forwarding: skipped (optional; would only add a second forwarder - that accepts `=`). Still open: one mailing list (VERP). + that accepts `=`). +- 2026-10-18, Google Groups (`coulomb-social@googlegroups.com`): the member + form accepted `ticket=GS-85QJ8WC09P+comments@` unchanged. The invitation + (11:58:20Z) arrived byte-identical and was correlated; no auto-reply was + sent (Auto-Submitted). After acceptance, the list post (12:05:37Z) + arrived for the **lower-cased** `ticket=gs-85qj8wc09p+comments@`. Its + envelope sender was `coulomb-social+bnc…@googlegroups.com`, which does + not collide with our syntax, and the facet survived. Exact comparison + missed the ticket, so the post was quarantined with no reply + (Precedence: list). Correct per v0.1, but lost to the ticket. This is + the second provider to lower-case, so SCP-7 is now the highest priority. ## Cap total outbound mail