mail-address-semantics/docs/spec-change-proposals.md

MAS v0.1 spec change proposals (from MAS-WP-0002/0003)

Status: draft for review. These are proposals against mas-v0.1-spec/. The spec bundle stays unchanged until they are accepted, because mas_conformance/ and mas_core/schema/ are vendored copies and the tests check them for drift. Evidence references point to docs/experiment-review.md.

Proposed target: a v0.1.1 errata release for SCP-1 to SCP-3 and SCP-5, which clarify or tighten without changing what canonical addresses mean. SCP-4 is informative only.

---

SCP-1: quoted local-parts that are valid dot-strings are equivalent

Sections: §4 Canonical ASCII local-part, §8 Address equivalence.

Evidence: Postfix delivered "ticket=PR42"@… as ticket=PR42 in all five probe configurations (RFC 5321 treats unnecessary quoting as equivalent). A receiver behind an MTA cannot tell which form the sender used.

Proposed text (§4, after the second paragraph):

A quoted local-part whose content, after removing the quotes and with no quoted-pairs, is a valid canonical MAS local-part is equivalent to that unquoted form. Receivers MUST treat the two identically. Generators MUST emit the unquoted form.

Impact: clarification only. No parser change, since quoted input still does not parse. A new conformance fixture should record the equivalence.

---

SCP-2: resource-type names are lower-case

Sections: §6.1 Resource types, grammar resource-type, §8.

Evidence: the ABNF accepts Ticket=PR42, but the statute schema only registers lower-case type names. The address parses but can never match a declared type, even under ascii-insensitive.

Options:

• (a) recommended: restrict resource-type in the grammar to lower-case ALPHA, DIGIT and -. Ticket=PR42 then parses as an opaque target, which is the safe outcome under §6.1 ("no semantics solely because of =").
• (b) keep the grammar and state in §8 that the statute's equivalence policy also applies to the type name.

(a) keeps the type a protocol token rather than user data, and it matches the schema. (b) makes type matching depend on the statute, which is exactly the hidden inference §8 tries to avoid.

Impact: (a) is a grammar tightening. None of the 31 shared conformance fixtures uses an upper-case type, so a new fixture (Ticket=PR42 → opaque) records the change. No repo test uses one either. Live traffic in MAS-WP-0003 used only lower-case types.

---

SCP-3: type-intake semantics for TYPE!MODE

Section: §7 Interaction semantics.

Evidence: in ticket!callback, the target ticket is an opaque target with no defined link to the resource type ticket. The canonical §7 example implies one. In the experiment, the statute had to register ticket as a function (registry key) and the service had to know what that means. Live, ticket!callback@mas.coulomb.social worked from Gmail and M365 only because of that registry entry.

Proposed text (§7, new paragraph):

An opaque target that equals a resource type declared in the statute, and that the statute also registers as a function, is that type's intake: mail to it requests creation or selection of a resource of that type. Without such a registration the target has no intake semantics, even if it equals a declared resource type.

Also add a statute-schema field such as "intake_for": "ticket" on registry entries, so the link is declared rather than implied by equal names.

Impact: additive; the schema gains an optional field. The policy resolver reports intake_for when it is present.

---

SCP-4 (informative): deliverability evidence for ! and =

Section: §12 Deliverability and rewriting.

Evidence: Gmail (web and app) and Microsoft 365 (Outlook mobile and desktop) accepted and delivered all four test forms byte-identical. That includes !, a doubled = and a + facet, both inbound and in a reply to an = From address. Postfix 3.7 never applied the legacy !/% rewrites to MAS addresses carrying an @domain. Pending: SRS and VERP (MAS-WP-0003 T04).

Proposal: keep the normative text. Add an informative note recording the tested paths, and an implementation note that a default Postfix relay configuration rejects every local-part containing ! (see SCP-5 and the review's operational findings). The "cooperating environments" wording for ! stays until T04 has covered forwarding.

---

SCP-5: intake auto-replies are a reflection vector

Section: §14 Security (items 4 and 5).

Evidence: an intake address that answers every request (as ticket!callback@ does with "your request is now ticket …") sends mail to whatever From: the request carried. A forged From: makes the service send mail to a third party, which is backscatter in all but name. §14.5 only says "avoid backscatter" and is usually read as covering MTA bounces. The live deployment had to add an application-level cap (T06) and discard MTA bounces to keep the relay bounded.

Proposed text (§14, new item):

10. A receiver that automatically replies to mail sent to an intake or interaction address SHOULD reply only when the sender is authenticated (for example DMARC alignment pass), and MUST bound the volume of such replies (rate limits or caps). Replies MUST NOT be sent to automated mail (Auto-Submitted, Precedence).

Impact: normative for receivers. The reference ticket service already skips automated mail and has a send cap. A DMARC check would need the gateway to pass Authentication-Results in the event, which is a small event-schema addition.

---

Lower-priority gaps (no proposal yet)

Recorded in the review, not urgent:

• interaction-mode names allowed by the value grammar but not by the schema (call.back, a=b);
• registry keys containing = or leading/trailing dots, which need semantic lint;
• discovery: whether the content type is checked, and the exact redirect same-origin rule;
• statute-declared facets.