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

MAS v0.1 experiment review (2026-10-08, provider pass 2026-10-18)

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/).

Provider pass (MAS-WP-0003, 2026-10-18): the same stack ran as a live MX for mas.coulomb.social on railiance01 (deploy/railiance/), with the statute at https://mas.coulomb.social/.well-known/mas. Real mail came from Gmail and Microsoft 365, and replies went out through Scaleway TEM. The evidence is the gateway's JSONL event log plus the Postfix log. Forwarding and mailing-list paths (T04) are still pending. Spec consequences are collected in docs/spec-change-proposals.md.

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.

Providers (tested, MAS-WP-0003): four address forms were sent from four sender setups:

• forms: ticket!callback@, ticket=ID@, ticket=ID+comments@, ticket=RE=2026-4711@;
• sender setups: Gmail web, the Gmail mobile app, and a Microsoft 365 tenant via both Outlook mobile and Outlook desktop.

Sender	Compose form	Envelope recipient and To header	Transport
Gmail web	accepted all 4 unquoted	byte-identical	209.85.x, STARTTLS, BDAT
Gmail mobile	accepted all 4 unquoted	byte-identical	same
M365, Outlook mobile	accepted all 4 unquoted	byte-identical	EOP 40.107.149.x
M365, Outlook desktop	accepted all 4 unquoted	byte-identical	EOP 52.101.171.x

• Nothing was rewritten, quoted, rejected or stripped. That covers !, a doubled = and the +comments facet. The gateway classified every message as the probe predicted: P2 function with callback → 201 created; P1 resource → 202; the facet was recognised.
• The reply direction also holds. The service replied From ticket=GS-85QJ8WC09P@mas.coulomb.social through Scaleway TEM. Gmail showed the = From address as sent, with SPF, DKIM (d=mas.coulomb.social) and DMARC all passing. A plain Gmail "Reply" went back to that address byte-identical, with correct In-Reply-To and References, and was correlated to the ticket (200).
• Not covered: consumer Outlook.com (the operator has no account; it uses the same Exchange Online path as M365), the Outlook-on-the-web compose form, and other providers such as Apple, Yahoo and GMX. Two providers is evidence that ! and = work in practice; it is not a survey.

Operational findings from the live run:

• Stock Postfix kills P2. smtpd_relay_restrictions must contain a reject-class entry, or smtpd refuses to start. Also, unless allow_untrusted_routing = yes, Postfix ignores access-map results for local-parts containing ! or % (it treats them as sender-specified routing). reject_unauth_destination then refuses every P2 address. The working MAS host config relays only @DOMAIN through an explicit regexp, turns off swap_bangpath and allow_percent_hack, and ends the list in reject. A host that "just enables MAS" on a default Postfix will silently lose all ! mail.
• A TEM "blackhole" MX swallowed inbound mail. Scaleway TEM's domain setup suggests MX 10 blackhole.tem.scaleway.com. Added next to the real MX at the same priority, it sent about half of all inbound mail to a discard host, and nobody got a bounce. Sending providers' setup wizards are a deliverability risk for MAS subdomains that receive mail.
• Outbound port 25 was blocked at the hosting provider (and on a second host). Replies need an authenticated submission relay.

Forwarding (T04, IONOS mail forward, 2026-10-18): this is the first real failure in the run.

• The IONOS forwarding form refuses = in the destination address. + is accepted. A resource address cannot be configured as a forward target at all.
• The form also forces lower case. It only accepts lower-case destinations and "corrects" input. The operator entered ticket--GS-85QJ8WC09P+comments@ (with -- standing in for =), and ticket--gs-85qj8wc09p+comments@ arrived. Under the spec's default exact comparison, a lower-cased identifier no longer matches its resource, even if the = had been allowed.
• SRS does not collide with =. IONOS rewrote the envelope sender to SRS0=ppc5=II=gmail.com=bernd.worsch@srs2.kundenserver.de. SRS never touches the recipient, so = in recipients is safe from it.
• The facet +comments survived forwarding.
• The header To: showed the forwarding address (mas-fwd@coulomb.social), so MAS receivers must classify the envelope recipient, as mas-gateway does.
• Result: the gateway classified the mail as an opaque target with a facet. The ticket service correctly declined it (404, not handled), because nothing in the statute gives ticket--… resource meaning. See SCP-6 (declared alternate separator) and SCP-7 (identifier case).

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

(Addendum from the live run: an intake address such as ticket!callback@ that auto-replies turns any forged From: into outbound mail to a third party. That is a backscatter/reflection vector at the application layer. The live deployment therefore caps all replies sent (300 in total, T06) and discards Postfix's own bounces. See SCP-5.)

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.

Decision gate (MAS-WP-0002)

Decided 2026-10-18 (founder): the recommendation below, plus the address composer pulled forward. Follow-up work: MAS-WP-0004 (Postfix profile), MAS-WP-0005 (spec errata and v0.2 drafts), MAS-WP-0006 (composer). MAS-WP-0007 retires the live test environment later.

Candidate	Demonstrated need?	Recommendation
Postfix/Exim integration	Yes. Default Postfix drops every P2 address, and the correct relay config is non-obvious	Build first: a documented, tested Postfix profile (later Exim) based on deploy/railiance/entrypoint.sh
Spec v0.1.1 errata	Yes, SCP-1 to SCP-7 (SCP-6 is an additive feature and could go to v0.2)	Do alongside the integration
Address composer	Partly. Mail clients accepted hand-typed addresses, but the IONOS forwarding form refused = and lower-cased input	Defer the tool; first settle SCP-6/SCP-7, then the generator emits the forwarder-safe form (mas_core.generator.for_destination, MAS-WP-0005 T09); the CLI/UI is MAS-WP-0006
Mail-client inspector	Not shown; nothing was rewritten that a user would need to see	Defer
TypeScript / Go implementations	Not shown; no consumer outside Python yet	Defer until a second consumer exists
Signed statutes	Not shown; pinned local statutes covered the operator case (see Discovery)	Defer
P3 economic profile	Not exercised	Defer

T04 confirmed the table: SRS and list bounce addresses never collided with MAS syntax, and the risks it found (forms refusing =, lower-casing) are covered by SCP-6/SCP-7 and the composer.