mail-address-semantics/docs/experiment-review.md

# MAS v0.1 experiment review (first pass, 2026-10-08)

Status of MAS-WP-0002, Milestone 9. The answers below come from building
`mas_core`, the `mas` CLI, `mas-gateway` and the reference ticket service,
and from running the test suite (135 tests, all offline except the
loopback fixture servers).

**Scope caveat:** every "email path" here is simulated. Raw RFC 5322
messages go through the real `mas-gateway pipe` entrypoint, but no
production MTA or mailbox provider was involved. The *Email infrastructure*
question is therefore still open and needs the live test described at the
end.

## Answers to the review questions

### Syntax: did the parser stay simple?
Yes. The parser is about 100 lines with no I/O. It always uses the maximal
(P2) grammar and records `required_profile`, so `ticket!callback` parses
without knowing anything about the namespace. All 31 spec fixtures and 27
added property cases pass.

Gaps found in the spec:
- **Resource-type case.** The ABNF allows `Ticket=PR42`, but the statute
  schema only registers lower-case type names. Such an address parses, but
  it can never match a declared type, even when the statute says
  `ascii-insensitive`. The spec should either make resource types
  lower-case in the grammar, or state that the equivalence policy also
  applies to the type name.
- **Interaction-mode names.** The value grammar allows `call.back` and
  `a=b`. The schema's mode-name pattern does not. Those modes parse but can
  never be enabled. This is harmless, but it should be documented.
- **Registry keys.** The schema pattern already blocks `+ ! $ ^`, but it
  still allows `=` and leading or trailing dots. Semantic lint is needed to
  reject a key like `ticket=GS-1` (`registry-key-resource`).

### Discovery: was exact-host metadata sufficient?
For this experiment, yes. Implementation choices the spec does not settle:
- `application/json` (or `+json`) is required as the content type
  (`InvalidContentType`). The spec only asks for 2xx plus the schema. It
  should say whether the content type is checked.
- Redirects are followed only when scheme, host and port all match. That
  is stricter than "same host". A port change counts as `CrossHostRedirect`
  and an https→http change as `SchemeDowngrade`.
- `mas_version` is checked before the schema runs, so a future version is
  reported as `UnsupportedVersion` and not as a schema error.
- **Operational finding:** a service must not depend on discovering *its
  own* statute. If the statute endpoint is down, the ticket service sees
  `namespace_confirmed = false` and correctly refuses to act. The mail is
  then declined. Operators should pin their own statute in local
  configuration (`mas-gateway --statute`). Discovery is for third-party
  namespaces.

### Policy: could all inference stay explicit?
Yes. Policy is a pure function. Without a statute, `kind` is always
`opaque`, `=` alone gives no resource semantics, and `!` stays
"unconfirmed". `mas explain` lists each of these as an *unknown*.
Folding is applied only when a statute declares it, and dot folding never
touches resource identifiers.

Facets have no statute declaration at all, so they are always reported as
"application-defined". A later version could let statutes list the facets
they recognise.

### Email infrastructure: which forms were rewritten or rejected?
**Not yet tested.** Known risks to check:
- `=` overlaps with SRS (`SRS0=...`) and VERP encodings.
- `!` is UUCP bang-path syntax. Some validators and web forms reject it.
- Postfix `recipient_delimiter = +` strips the facet for lookups. That fits
  the facet-degradation design.

### Resource addressing: did it improve correlation?
Yes. The service replies *from* `ticket=GS-…@great-service.example`, so an
ordinary reply lands on the resource address. Correlation uses the address
only. The tests send an unrelated subject and a facet-stripped address,
and both correlate.

### Subject lines: could identifiers disappear?
Yes. Replies use the customer's own subject, and no ticket id is ever put
in it (asserted in the tests).

### Lifecycle: did closed resources stay understandable?
Yes. A closed ticket stays addressable. Mail to it is archived separately
and the ticket is not changed. A single notice goes only to the original
requester, and never to automated senders (`Auto-Submitted`,
`Precedence`). Mail to an unknown resource is quarantined with no reply.
For an MTA pipe, the gateway exits 0 when the app declines and 75 when the
app is unreachable, so it never generates a bounce (no backscatter).

### Interaction: was `!callback` useful?
Partly. It expresses intent cleanly, but the service still needs a phone
number and a time. The address cannot carry those, so the first reply has
to ask by email. `!callback` therefore starts a negotiation; it does not
replace one.

The bare `ticket` in `ticket!callback` is an **opaque** target. It has no
defined link to the resource type `ticket`. The spec's canonical example
(§7) implies such a link. The statute has to register `ticket` as an
intake function, and the service has to know what that means. The spec
should either say this explicitly, or define "type intake" semantics for
an opaque target that names a declared resource type.

### Security: did any address start acting like a capability?
Not for reading or control. Knowing a ticket address grants no read access
and no admin action. It does let anyone **append correspondence** to an
open ticket, which is the intended function of a communication endpoint.
That is also an injection and spam vector. Ticket ids are non-guessable
(10 Crockford base32 characters), but sender policy belongs to the
application, not to MAS.

## Recommended next step (before the decision gate)
Run the live path: a real domain, the static statute served at
`/.well-known/mas`, Postfix with the `mas-gateway pipe` transport, and test
mail sent from Gmail, Outlook and one corporate gateway to
`ticket!callback@`, `ticket=ID@` and `ticket=ID+comments@`. Record which
addresses arrive unchanged. That evidence answers the open
*Email infrastructure* question.