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:** the MTA half of the email path was tested against a real
Postfix (3.7.11, Debian bookworm, in Docker). The setup was SMTP → Postfix
→ `pipe` transport → `mas-gateway` → reference ticket service
(`experiments/postfix-probe/`). Mailbox providers (Gmail, Outlook,
corporate gateways) and public DNS/MX were not involved. That half moves
to **MAS-WP-0003**.

## 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?
**Postfix (tested):** 14 address forms were sent through 5 Postfix
configurations (`experiments/postfix-probe/results/`):
- relay domain with defaults;
- local rewrite context, with and without `swap_bangpath` /
  `allow_percent_hack`;
- domain in `mydestination` (local delivery class), with and without those
  two settings.

The results:
- **13 of 14 forms arrived byte-identical in every configuration.** That
  includes `ticket!callback`, `ticket=ID+comments`, `ticket==X1`,
  `ticket=PR%2B42`, `ticket=ID+comments!callback` and `ticket=PR42$4.99`.
  `recipient_delimiter = +` does not change the envelope recipient that
  `pipe` passes on as `${recipient}`. Upper case is preserved.
- **The quoted local-part `"ticket=PR42"` arrived unquoted** as
  `ticket=PR42`. Postfix drops quotes that are not needed (RFC 5321
  treats the two forms as equivalent), so a form the spec calls
  non-canonical became canonical in transit. **Spec gap:** §4 should say
  that a quoted local-part whose content is a valid dot-string is
  equivalent to the unquoted form, because an MAS receiver after an MTA
  cannot tell them apart.
- **The `!` and `%` legacy rewrites did not trigger** for any MAS address,
  even with Postfix defaults and the domain in `mydestination`. In 3.7 the
  bang-path swap fired only for a bare `site!user` with no `@domain`
  (checked via local `sendmail`: it was rerouted to `site`). MAS addresses
  always carry an `@domain`. Setting `swap_bangpath = no` and
  `allow_percent_hack = no` is still a sensible hardening default for MAS
  hosts.
- `$` passed through SMTP untouched. Rejecting it is purely a MAS parser
  decision. The gateway forwarded it as `valid: false`, and the app
  ignored it.

**Still untested (MAS-WP-0003):**
- whether senders' providers and web forms accept `!` and `=` in recipient
  addresses;
- overlap with SRS (`SRS0=...`) and VERP when forwarding;
- facet stripping by providers.

### 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.

## Next step (MAS-WP-0003, before the decision gate)
Run the provider half on a real subdomain:
- an MX pointing to a Postfix configured like the probe;
- the statute served at `https://<sub>/.well-known/mas`;
- test mail from Gmail, Outlook and one corporate gateway to
  `ticket!callback@`, `ticket=ID@` and `ticket=ID+comments@`, plus replies
  to the service's `ticket=ID@` From address.