From 1ba7379590114ec51301cf96dc041499b0b844e6 Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 19 Oct 2026 10:10:23 +0200 Subject: [PATCH] INTENT.md: phase 2 (experiment passed, spec workbench role, auto-reply principle, open P2 question) Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 5787@bnt-lap001 Assistant-Session: 5db26b82-138b-40cc-9856-4d5eb0f752fd --- INTENT.md | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 102 insertions(+), 2 deletions(-) diff --git a/INTENT.md b/INTENT.md index 5ca0c97..1f66b7e 100644 --- a/INTENT.md +++ b/INTENT.md @@ -1,6 +1,15 @@ # MAS — Mail Address Semantics -## Intent +## Status + +**Phase 1 (reference experiment) passed** its decision gate on 2026-10-18 +(MAS-WP-0002, `docs/experiment-review.md`). All ten success criteria were +met, including the live run through Gmail, Microsoft 365 and Postfix. +**Phase 2** is described in *Phase 2 intent* below. The phase-1 sections +are kept as the record of what was tested; where phase 2 changes them, it +says so. + +## Intent (phase 1) Build the smallest practical implementation of **Mail Address Semantics (MAS) v0.1** that can prove whether the specification is useful in real email workflows. @@ -265,6 +274,25 @@ No implementation work on price, reward, conditions, offers, contracts, or settl --- +### 10. Auto-reply endpoints are gated and capped + +*(Added in phase 2, from the live run.)* + +An address that answers automatically, such as `ticket!callback@`, turns +any forged `From:` into outbound mail to a third party. Any endpoint that +replies automatically therefore: + +- replies only when the sender is authenticated (DMARC pass, read from + trusted `Authentication-Results`); +- never replies to automated mail or to the null sender; +- caps how much it can send in total. + +This is application policy, not MAS syntax. But a MAS deployment that +leaves it out reflects mail at third parties, and the reference +implementation must show how to avoid that. + +--- + ## Initial architecture The first repository should contain only the pieces needed for the experiment. @@ -439,7 +467,10 @@ Later mail must not silently reopen or mutate the resource unless application po --- -## Explicit non-goals +## Explicit non-goals (phase 1) + +*Phase 2 removes the address composer and the MTA integration profile +from this list (see Phase 2 intent). The rest still applies.* The initial implementation does not include: @@ -477,6 +508,75 @@ The first experiment succeeds if: --- +## Phase 2 intent + +Phase 1 showed that the convention works through ordinary infrastructure +once the MTA is configured correctly, and that resource addressing is the +strongest part of MAS. Phase 2 turns the experiment into a usable +reference. It still stays narrow. + +### Role of this repository + +This repository is the **spec workbench** as well as the reference +implementation. It maintains the normative bundles (`mas-v0.1-spec/` as +v0.1.1 errata, and the `mas-v0.2-spec/` draft) and records every change as +a proposal in `docs/spec-change-proposals.md`. Every spec change needs: + +- evidence from a test or a live run; +- conformance fixtures in the bundle; +- an implementation in `mas_core`. + +Implementation and spec move together. A version is declared final only +after a second implementation or deployment has passed its corpus +unchanged. + +### Goals + +1. **Adoptable integration.** A documented, tested MTA profile, so that + P2 addresses survive. Default Postfix drops them. Postfix is done; Exim + only on demand. +2. **Forwarder-safe generation.** Provider forms refuse `=` and fold case. + The generator and `mas compose` emit the canonical form and, where the + statute allows it, a forwarder-safe form. When that form would be + misread, they refuse to emit it. +3. **v0.2 to final.** Settle stand-ins, destination transforms and + `resource_id_case`. Finalize once an independent implementation + validates the corpus. +4. **Safe reference behavior.** The reference service demonstrates + principle 10. + +### Open question: the value of interaction (P2) + +Phase 1 proved resource addressing strongly, and interaction only partly. +`!callback` states the intent, but the service still has to ask for a +number and a time. The link from the opaque intake target `ticket` to the +resource type `ticket` exists only through a statute registry entry. +Phase 2 must decide one of two things: + +- define "type intake" semantics, so that an opaque target naming a + declared resource type has a specified meaning; or +- narrow P2 to a pure preference hint, and stop adding mechanism for it + (such as the `---` stand-in) until a use case needs it. + +### Still not in phase 2 + +Other language implementations (except one used to validate v0.2), a +policy daemon, a central registry, mail-client plugins, signed statutes, +implicit parent inheritance, and economic semantics. A web composer is out +until something asks for one. + +### Phase 2 is done when + +1. a fresh Postfix install, using only `integrations/postfix/`, delivers + the full corpus unchanged and refuses relaying; +2. `mas compose` produces correct forms for every destination observed so + far, and refuses the rest; +3. v0.2 is declared final, or is withdrawn with recorded reasons; +4. the P2 question above is decided and recorded in the spec; +5. the live test environment is retired, with its evidence archived. + +--- + ## Longer-term direction If the experiment validates the concept, MAS may later grow into: