coulomb/mail-address-semantics
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

MAS-WP-0003-T04: Google Groups results (lower-cases members); T04 done

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 252470@bnt-lap001
Assistant-Session: ad628c8f-4be2-4979-94c9-76c7ed6f8241
This commit is contained in:
tegwick 2026-10-18 14:07:14 +02:00
parent 57d9bedf25
commit 482fdee287
3 changed files with 46 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

25
docs/experiment-review.md
View file

@ -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

12
docs/spec-change-proposals.md
View file

@ -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