Nitrosend

kam@nitrosend.com

Nitrosend

george@nitrosend.com

Applications and Real-Time Individual Submission emailagentsstructured email Mail Action Protocol (MAP) describes actions offered by email, such as approval to publish an article. A type contract defines each decision and its effects. A trusted service binding connects that decision to an existing service operation. Before acting, a client reads the current proposal and applies the user's policy. The service checks permission and the exact terms when it records the decision. MAP uses Structured Email's MIME and JSON-LD representation. Core is independent of the interface used to call the service. This document specifies an HTTP binding, Registry discovery rules and an experimental capability binding for a limited set of actions without a service account connection. It defines no general action endpoint or replacement authentication system.

Introduction Mail Action Protocol (MAP) describes a service action in email. It tells a client what is proposed, which exact terms apply and which decisions are available. A type contract defines the meaning of those decisions. A trusted connector maps them to the service's existing operations. For example, a publication request can offer approval of one article revision. The client reads that revision and its publication terms from the service, applies the user's policy, and obtains confirmation when required. The service checks permission and the terms version when it records the decision. An approval for one revision cannot authorize another. MAP uses ordinary email delivery and service authentication. It defines the description and the rules for acting on it. The HTTP binding uses existing APIs; the optional capability binding permits a small set of actions without a service credential. Neither the message nor a Registry listing grants general permission to act.

Conventions and terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in and when, and only when, they appear in all capitals.

• A principal is the person or organization on whose behalf a client acts.
• A host is the application that enforces that principal's policy and obtains human decisions. A language model's output is not a human decision.
• A producer constructs and sends a MAP message. It may send on a service's behalf.
• A consumer extracts and processes MAP descriptions. It may present them in a mail client or to an agent host.
• A service owns the proposal, authorizes its operations, and applies their effects.
• An interaction is one proposal addressed to one recipient, using one contract and one terms version.
• A type contract is an immutable definition of an interaction's data, operations, effects, and client obligations.
• A service binding maps a type contract to the service's read and action operations. A connector implements that mapping, either as installed code or by interpreting a supported declarative binding.
• Service readback means reading the current proposal through the trusted service connection. It supplies the facts used to decide, independently of the email's claims.
• An effect is a semantic consequence declared by a contract, including downstream consequences directly authorized by the operation.
• A capability is an opaque bearer URL authorizing one narrowly limited operation. Possession, including possession of a forwarded copy, conveys that authority.

Type contracts

Contract identification A contract binds all normative semantics, its schemas, and its operation declarations in one JSON document. The digest is SHA-256 of its UTF-8 JSON Canonicalization Scheme representation, using and . The spelling is sha-256: followed by 64 lowercase hexadecimal characters. This hashes the canonical contract, not its download formatting and not the email description. A contract MUST NOT contain its own digest. The contract's id, version, and profile MUST match the description and the selected profile. A consumer MUST obtain the contract from a bundled or explicitly configured catalogue and verify its digest before use. The presence of an unfamiliar URI in email MUST NOT trigger retrieval, installation, or acceptance of a contract. Failure to resolve an exact digest makes that interaction non-actionable. A catalogue MAY be local, organizational, vendor-maintained, or public; MailSchema is not a required online dependency. Publication fixes the contract's canonical contents. An incompatible or compatible change to any normative content requires a new version and digest. A catalogue MAY update lifecycle metadata separately, including Draft, Experimental, Stable, Deprecated, or Superseded status and successor links. Such metadata MUST NOT rewrite a published contract or automatically authorize migration to its successor. Withdrawal from new use does not justify deleting artifacts required to interpret earlier messages.

Contract format and obligations A contract contains id, version, profile, name, summary, requirements, detailsSchema, and operations. requirements is a nonempty array of normative prose strings. It MUST state the exact terms covered, actor obligations, restrictions, and any semantic conditions that JSON Schema cannot express. Documentation outside the digest-bound contract MAY explain it but MUST NOT silently change its meaning. detailsSchema and each input schema use JSON Schema Draft 2020-12 . They MUST be self-contained: references MAY target fragments within that schema document, but MUST NOT require external retrieval. Validation MUST use the format-assertion vocabulary for formats the contract uses. Consumers MUST reject contracts whose keywords, formats, or semantic requirements they cannot enforce. Resource limits apply during validation; a schema is not permission to consume unbounded computation. Every operation object contains id, name, semantics, effects, bindings, actors, exactTerms, inputSchema, and outcomes. semantics is normative text, not text to execute. effects is a nonempty set of absolute HTTPS identifiers. bindings selects the permitted authority modes: credential, capability, or both. It does not enumerate service protocols; API calls, tool invocations and brokered commands can all use the credential mode. actors selects human, agent, or both; this declares permitted interfaces, not the caller's entitlement. exactTerms is a boolean. inputSchema is either a schema for one JSON input object or null, which means the operation accepts no caller-supplied semantic input. outcomes maps operation-local identifiers to their semantic meanings; these are not protocol response bodies or HTTP status codes. An operation that permits the capability binding also contains capability with kind and maxLifetimeSeconds. Its kind is one of refusal, protective-report, or address-confirmation, with the additional restrictions in that binding. No other operation may contain that member. A capability operation MUST have inputSchema: null and exactTerms: true. Every effect resulting directly from a successful operation or from work that it authorizes MUST be declared. Approval to send a campaign therefore declares external communication, even if sending occurs later. A service MUST NOT use a narrower label such as recording a decision to conceal that effect. A service binding MUST NOT broaden a contract's semantics or accept additional semantic inputs under its identifier. A host MUST NOT automatically approve an unrecognized effect. It MAY present such an operation for an explicit principal decision only if it understands and can accurately explain the complete contract. Otherwise it MUST refuse it. A model-generated explanation alone does not establish this understanding. Capability processing has a stricter, closed set of permitted effects.

Initial effect vocabulary The initial vocabulary uses identifiers under https://mailschema.org/effects/. These meanings are stable; adding identifiers does not change Core. The following suffixes have these meanings:

• communication: sending or publishing content to an external audience.
• disclosure: making information available to another principal or audience.
• payment: authorizing or causing a monetary charge, transfer, purchase, or use of prepaid value. The amount, currency, payee and funding source are separate terms that a contract must define where they matter.
• commitment: accepting an obligation on behalf of the principal.
• authorization: granting or changing another actor's permission.
• assertion: making a statement of identity, control, or fact attributed to the principal.
• state: changing a service record.
• protection: reporting or taking action intended to protect the principal.
• refusal: declining the stated proposal without authorizing its requested effect.

These labels are inputs to host policy, not a universal policy language. A contract MUST provide the typed facts needed to judge its effect. A host MUST NOT treat a category as sufficient authorization without those facts. Other maintainers MAY define stable effect identifiers in their own namespaces.

Message trust and recipient control

Qualifying message authentication Before exposing an actionable MAP control or making a MAP-driven service read, a consumer MUST establish one qualifying DKIM signature as specified in . That same signature MUST satisfy all of the following:

1. Its signing domain aligns with the RFC 5322 author domain under . Relaxed alignment suffices for credentialed operations unless local policy requires strict alignment. Capability operations require strict alignment. An SPF-only or aggregate DMARC pass is insufficient.
2. It verifies the entire body and contains no l= body-length tag, even if that tag happens to cover the received body.
3. It covers From, To, Subject, Date, Message-ID, MIME-Version, and Content-Type, all of which MUST be present, and Cc, SUPERSEDES, and Expires when present. A producer SHOULD oversign From to detect an added instance. Consumers MUST reject duplicate occurrences of these fields rather than choose the convenient copy.
4. It uses a currently acceptable DKIM algorithm and key. Implementations MUST reject rsa-sha1 and RSA keys shorter than 1,024 bits in accordance with . Producers SHOULD use RSA keys of at least 2,048 bits or Ed25519; consumers MUST support verification of ed25519-sha256 as specified in .

There MUST be exactly one author mailbox in From, parsed according to . Display names do not participate in authentication. Failure of these requirements disables MAP actions; it does not change general mail-delivery policy. A consumer MAY verify the received message itself or rely on its trusted receiving pipeline. In the latter case, a locally configured authserv-id and the trust-boundary rules of apply. The pipeline MUST supply evidence for all requirements above for the same signature and bind that evidence to the message and MAP part being processed. A bare dkim=pass does not prove absence of l=, header coverage, or preservation of the MAP data. This specification introduces no new Authentication-Results property; an implementation can retain the verified original message and signature metadata or use an authenticated receiver interface. An intervening trusted transformation MAY change readable links or formatting only if the pipeline preserves the authenticated MAP bytes and security-relevant header values, or supplies the authenticated original for MAP processing. A consumer MUST NOT treat modified machine data as the signed original. A rewritten capability URL is unusable unless the trusted pipeline supplies the authenticated original URL; the consumer MUST NOT discover it by following the wrapper URL. An attacker-supplied Authentication-Results field, or a field merely containing a familiar authserv-id, MUST NOT be accepted across an untrusted boundary.

Recipient and copy handling The consumer MUST establish through its trusted mailbox context that the message was delivered to the mailbox named by recipient and that its principal controls that mailbox. A visible To address is insufficient evidence of delivery or control. Aliases and shared mailboxes require explicit provider or administrator mappings. A service MUST separately establish the principal's authority for the proposal; mailbox access alone does not supply service permission. A forwarded copy does not establish control of its original recipient. Automatic forwarding is not reliably detectable and is not a separate protocol test: recipient control, original delivery evidence, and the service checks remain REQUIRED. A client creating an ordinary reply or manual forward MUST remove the active MAP part. Forwarded-as-attachment originals remain inert. This is a MAP-specific requirement in addition to Structured Email's treatment of non-representative data on forwarding. Valid signed messages can be replayed. Message identifiers and DKIM verification are not freshness or single-use proofs. Clients SHOULD suppress duplicate prompts for the same service, tenant, recipient, interaction, and terms version. Services MUST enforce expiry, current authorization, decision state, and exact terms regardless of delivery count.

Credentialed processing

Binding independence Core does not require an HTTP API or a particular tool protocol for credentialed operations. A service binding MUST satisfy the following processing rules using its chosen interface. It MUST document the trusted connection, account and tenant, current-proposal read, operation and input mapping, atomic version check, native outcomes and retry behaviour. The service's HTTPS origin identifies the authority; it does not select the execution transport. The installed binding supplies the actual connection and credential destination. A consumer MUST refuse a binding it cannot enforce. The email MUST NOT select another protocol or connection as a fallback. A binding MUST establish the authenticity of authoritative service data and protect the integrity of submitted decisions and results. It MUST protect credentials from disclosure outside their authorized audience. Its documentation MUST state how its native transport and authentication satisfy these requirements, including any intermediaries. An additional binding can be specified independently of Core and the type contract when it preserves their semantics. Queued or delegated execution MUST preserve the same authorization and exact terms. Receipt by a broker, agent or intermediary MUST NOT be reported as the service's decision or completed effect without evidence that establishes that state. The service MUST establish the original principal's authority at the decision; authenticating an intermediary alone is insufficient. Results MUST be authenticated and correlated with the decision, service, tenant and principal through the installed binding. Delegation MUST NOT broaden the selected operation, semantic input or approved terms.

Trusted service implementation A consumer MUST use a service binding enabled by its principal or administrator for service.id and, when needed, service.tenant. Neither authenticated email nor a Registry record can install that implementation or extend its credential destinations. The mapping MUST bind the exact type contract digest it implements. A change to its code or manifest is subject to the host's normal installation and review policy; a message cannot select an unreviewed mapping revision. The mapping identifies the service's existing read and action operations, authenticated principal, tenant interpretation, credential destination, request-value sources, expected-version mechanism, and response interpretation. It MUST establish these from trusted configuration and service information. It MUST NOT take an HTTP method, endpoint, tool name, executable template, or constant tool arguments from email. Parsing a service identifier or resource identifier MUST NOT permit it to override the mapped origin, path structure, or tenant. A multi-tenant service MAY send through customer-owned domains. DKIM authenticates the sender domain; it does not prove that a resource belongs to the service or tenant. The implementation and service readback establish that relationship. A trusted sender-domain list MAY impose an additional restriction but does not replace readback.

Authoritative readback and decision The host MUST authorize the service read under local policy. Message arrival alone does not grant network access. When permitted, the connector MUST read current service state with an existing, appropriately scoped credential before evaluating an operation for execution or asking the principal to authorize it. The read MAY use a synchronous response or an authenticated, correlated reply through the installed binding. The host MUST complete it before evaluating or submitting the decision. No new MAP read endpoint or response envelope is required. The binding MUST establish the following facts from the service and its documented API behaviour. Copying them from the email is insufficient:

1. The interaction exists for the stated service and tenant, concerns the stated subject and proposal, and was offered to the intended recipient.
2. The authenticated principal is permitted to inspect it and has the relevant relationship to that recipient.
3. Its type identifier, version, and contract digest match the description.
4. Its current terms identifier and version match the description, and it has not expired, been withdrawn, or been superseded.
5. The currently offered operations and the current typed details are known.

An existing API need not store a literal MAP object. A connector MAY derive these facts from authenticated records under an unambiguous, documented mapping. It MUST NOT manufacture a missing fact from message content. A read that returns only a generally readable subject is insufficient evidence that the principal was offered this proposal. The connector MUST validate the details read from the service against the contract. The host MUST base policy and confirmation on those details, including any additional content retrieved through the trusted mapping that the policy needs. It MUST NOT treat the email's preview as evidence that a content, destination, or audience restriction passed. It MUST distinguish service-supplied user content from service assertions. An operation MUST be offered by all three: the email, the selected contract and the service's current proposal. The service cannot add an action to the email by returning it in readback. A mismatch in identity, digest, version, or authority makes the interaction non-actionable. The consumer MUST NOT silently upgrade it to a newer proposal. The host MUST apply the principal's standing policy to the complete operation, typed values, declared effects, and actor restrictions. If that policy does not authorize the operation, the host MUST obtain an explicit human decision through a trusted interface. A language model MUST NOT supply or simulate that decision. Any changed action-relevant value invalidates the decision and requires reevaluation. Free-form message text, contract prose, and service-returned content MUST NOT alter host instructions, permissions, connector configuration, or confirmation policy.

Client readiness A client MUST distinguish an unsupported action from a refused or completed action. When a profile, exact contract, binding or required semantic rule is unsupported, it MUST disable that operation and MAY continue displaying the ordinary email. Unknown fields or operations MUST NOT be discarded to make an otherwise unsupported action executable. If the service is not connected, the host MAY offer a separate setup flow under the Registry and discovery rules. The email MUST NOT authorize setup. Once setup completes, the client MUST repeat message, contract, recipient and service checks before offering an action. Credential acquisition during explicit setup does not grant permission to execute the waiting proposal. A client MUST make missing permission, changed terms, expiry and an unknown execution result distinguishable to its user or calling application. Its interface MAY use different wording, but MUST preserve those meanings. It MUST NOT silently substitute a newer proposal or retry an operation whose effect is uncertain.

Exact terms and service enforcement Every operation whose effect depends on proposal content MUST declare exactTerms: true. The service-issued version MUST change whenever a value that affects the action changes. This includes referenced content, destinations, audience membership and schedule. These values are the proposal's exact terms. A mutable document URL, audience label, or count alone is not an exact terms binding. A service MAY keep immutable referenced revisions or include their state in its version calculation. For such an operation, the connector MUST convey the readback version through the trusted binding. Before committing the effect or authorizing the work, the service MUST check the acting account, recipient relationship, expiry, decision state and terms version together. These checks and the decision MUST be atomic: no intervening change may invalidate a check before the decision commits. A mismatch MUST commit no effect. A separate read followed by an unconditional write does not conform. Revocation or loss of permission between read and commit MUST take effect at commit. When work is asynchronous, accepting the decision MAY authorize a job rather than complete its external effect. The job MUST remain bound to the accepted immutable terms; it MUST NOT later resolve a mutable audience, content revision, or destination to different terms. The binding MUST distinguish acceptance, pending work, completion, refusal, and indeterminate execution using the service's existing semantics. MAP does not promise exactly-once delivery or define a job protocol. Services MUST prevent conflicting terminal decisions from both taking effect. Repetition MUST NOT repeat a terminal effect. Services MAY use their existing transaction, idempotency, and decision-record mechanisms. A consumer MUST NOT retry an indeterminate operation unless its trusted binding establishes that doing so cannot duplicate the effect.

Semantic conditions and updates A type defines successful decisions and the service-specific outcomes an implementation must interpret. These common conditions have the following meaning wherever reported: already-decided means a terminal decision exists; superseded means another interaction replaces this one; stale means the presented version is not current; expired means the allowed lifetime ended; declined means a refusal was recorded; and withdrawn means the service removed the proposal. They are semantic conditions, not six required HTTP problem types. A valid decline is a successful decision, not a transport failure. A binding MUST preserve the distinction between failure before execution, acceptance with work pending, a known terminal outcome, and an unknown outcome. It MUST NOT represent lack of an error as proof of completion. It MUST expose no result details beyond the principal's current authorization. Interaction expiry limits when a decision may be accepted. It does not by itself cancel work already authorized before expiry. A contract or the accepted schedule can impose an execution deadline; the service MUST preserve that deadline with the accepted terms and enforce it. Clients MUST NOT promise that recalling an email cancels an already accepted service operation. When terms change, the producer MUST issue a new interaction identifier and version. It MUST use Structured Email's SUPERSEDES mechanism to associate a replacement with the previous message. A signed replacement header MAY inform presentation; it MUST NOT itself grant authority, revoke service state, or cause execution. Services enforce withdrawal and supersession independently of whether the recipient receives an update. Clients MUST NOT act on a recalled, empty structured representation as though it were an operation.

Human route The human URL MUST lead to a page that displays the current proposal without performing the action. GET and HEAD MUST be safe in the sense of . Merely fetching a link, loading its subresources, opening a preview, or passing through an authentication redirect MUST NOT approve, decline, confirm an address, or consume a capability. The URL in the email is a sender claim. A qualifying DKIM signature does not establish that its destination belongs to the named service. A consumer MAY show it as an ordinary email link with its actual origin visible. To present it as a verified service review route or use it for a MAP control, the consumer MUST establish the permitted route through its trusted service binding. An unconnected client cannot make that claim. The page MUST require an explicit confirmation submitted by an unsafe method before applying the operation. It MUST check current authorization, expiry, proposal state, and exact terms at that submission. Consequential actions MUST require service authentication; the narrow bearer operations permitted by the capability binding MAY instead use an equivalent server-side bearer confirmation flow. A bearer flow MUST preserve all effect and lifetime limits and MUST NOT turn its initial GET into a decision. An authenticated page MUST protect the confirmation against CSRF and clickjacking. It MUST use the application's established CSRF defenses and restrict framing to trusted origins, for example with CSP frame-ancestors. Cookie SameSite behavior alone MUST NOT be its only authorization check. A confirmation MUST be bound to the principal's session and exact proposal; a previously authorized form MUST NOT approve revised terms. The page and any native action control MUST display the destination service origin, recipient or acting account, material terms, and effect before confirmation. Display names MUST NOT substitute for origins or account identity. A host SHOULD warn about confusable identifiers using Unicode security mechanisms; it MUST escape or visibly flag bidirectional and invisible formatting controls in display text. Display defenses MUST NOT rewrite identifiers used for security comparisons.

Email representation A producer MUST include exactly one MAP description for the message's recipient. It MUST use an application/ld+json MIME part with the parameter profile="https://mailschema.org/profiles/map/0.3" and Content-Purpose: Machine-readable. The description MUST be a partial representation within multipart/related, together with the readable content it describes, as specified by Structured Email . MIME processing follows and . The related root MUST be readable content, which MAY itself be multipart/alternative. Ordinary attachments MAY occur outside that related entity in an enclosing multipart/mixed. The machine part MUST use base64 or quoted-printable transfer encoding as specified in . A consumer MUST reject ambiguous MIME headers or duplicate security-relevant parameters on that part, rather than let different parsers select different profiles or encodings. Size limits apply after transfer decoding; the receiver SHOULD also bound encoded message size and MIME nesting before extraction. A consumer MUST associate the part with its containing outer message. It MUST NOT activate MAP data inside an attached message, including message/rfc822, or inside an entity marked as an attachment. It MUST NOT extract actionable MAP data from HTML, quoted text, or an arbitrary JSON attachment. More than one designated MAP part makes the message non-actionable. An unrecognized MAP profile MUST NOT be interpreted as this profile. The readable content MUST describe the same proposal and offer a link to the human route. A producer MUST NOT conceal a materially different effect in the machine-readable part. A consumer MAY continue displaying ordinary readable email when MAP processing fails; it MUST NOT present that failure as a verified or authorized action.

JSON processing limits After MIME transfer decoding, the description MUST be UTF-8 I-JSON as specified in , with no byte order mark. Its decoded size MUST NOT exceed 65,536 octets. Container depth MUST NOT exceed 32, counting the root object as depth 1 and each nested object or array as one additional level. Duplicate member names, including names equal after JSON escape decoding, MUST be rejected before a parser discards them. Unpaired surrogates, Unicode noncharacters, and U+0000 in strings or member names MUST be rejected. Numbers MUST be finite IEEE 754 binary64 values in the range -9007199254740991 through 9007199254740991. A numeric token MUST NOT exceed 64 ASCII characters. Producers MUST encode identifiers, exact decimal quantities, and integers outside that range as strings under their type contract. Consumers MUST reject tokens that underflow to zero or overflow during binary64 conversion. These restrictions are checked on the original JSON tokens, before canonicalization or schema validation. They also apply to contract documents; a contract MAY occupy up to 262,144 UTF-8 octets. The root MUST be an object in the compact form defined here. JSON-LD expansion, alternate term aliases, additional contexts, and equivalent RDF serializations are not alternate wire forms of MAP 0.3. Consumers MUST resolve the fixed JSON-LD 1.1 context from their configured profile artifacts and MUST NOT retrieve a context because an email names it. Nested type-defined data is represented as JSON data by the context; it cannot introduce an executable or remotely resolved context.

Description members All members in the following list are REQUIRED except service.tenant. Members not specified by this profile MUST be rejected at the root and in its fixed objects. A type defines allowed members within details; it cannot add execution instructions to the core objects.

• @context: exactly https://mailschema.org/contexts/map-0.3.jsonld.
• @type: exactly MailAction.
• @id: an absolute URI identifying this interaction, unique within the service. A producer SHOULD use a UUID URN as specified in . A new recipient, contract, proposal, or terms version requires a new interaction identifier. Retransmission of an unchanged interaction preserves the identifier.
• profile: exactly https://mailschema.org/profiles/map/0.3.
• type: an object containing id, an absolute HTTPS contract identifier; version, its version string; and contractDigest, its digest as defined under Contract identification ().
• issuedAt and expiresAt: UTC timestamps in the restricted form YYYY-MM-DDTHH:MM:SSZ, with valid calendar values and seconds from 00 through 59. Expiry MUST be later than issuance. The consumer MUST NOT act before issuance or at or after expiry. A local clock tolerance MAY be used for issuance, up to 300 seconds; it MUST NOT extend expiry. A service MUST enforce expiry independently using its own clock.
• inLanguage: a well-formed BCP 47 language tag as specified in , identifying the language of display text. It does not change identifier comparison or operation semantics.
• service: an object containing id, the service's HTTPS origin, and optionally tenant, an absolute URI that distinguishes a tenant. An origin contains a scheme, host, and optional port, with no path, query, fragment, or user information. A multi-tenant implementation MUST require tenant wherever omission would make the authority ambiguous.
• recipient: a single mailbox in addr-spec form without a display name, comments, or a group. Internationalized mailboxes use the UTF-8 form of . A consumer MUST compare mailbox identity using its trusted mailbox provider's rules; it MUST NOT infer aliases, discard subaddress tags, case-fold local parts, or infer control from a header alone.
• subject: an object containing id, an absolute URI for the object being acted on, and title, plain display text. The title is not an identifier.
• terms: an object containing id, an absolute URI for the proposal, and version, a nonempty opaque service-issued token of at most 1,024 ASCII characters in the range U+0020 through U+007E. The consumer MUST preserve the token exactly. It is not necessarily an entity-tag or a digest.
• details: an object conforming to the selected contract's detailsSchema. Its values in email are claims available for preview, not authoritative service state.
• operations: a nonempty array of at most 32 objects, each with a unique id declared by the contract. An object MAY also contain capability, exactly as defined by the Experimental capability binding (). Operation identifiers contain 1 to 64 ASCII characters, start with a lowercase letter, and thereafter contain only lowercase letters, digits, or hyphens. Array order MAY guide presentation; it MUST NOT indicate a preferred decision.
• human: an object containing url, the absolute HTTPS URL of the service's review page. Navigating to it does not perform the operation.

Except for the opaque version token, security-sensitive identifiers MUST NOT contain whitespace, control characters, Unicode bidirectional formatting controls, or invisible formatting characters. Network URLs MUST NOT contain user information or fragments. Hosts MUST use ASCII DNS labels, including valid IDNA A-labels where necessary; IDNA processing follows . IP-literal service origins are not permitted in this profile. An implementation MUST NOT normalize an opaque identifier or token to make a comparison succeed. Origin comparison follows ; other identifiers compare exactly unless their defining standard explicitly provides an equivalence rule. Identifiers are not instructions to fetch. In particular, subject.id, terms.id, a type URI, and an effect URI can identify something without being a client-accessible resource. The client MUST resolve service objects through its trusted mapping.

HTTP binding This binding maps a contract's credentialed operations to an existing HTTPS API. It does not prescribe a MAP endpoint, URL layout, request body, or response format. The client and service MUST satisfy Core's credentialed processing requirements in addition to this section.

HTTP implementation mapping A trusted implementation MUST document its service origin, tenant interpretation, supported contract digest, authenticated principal mapping, read operation, and each action operation. It SHOULD identify API operations by stable references to the service's API documentation or OpenAPI description. A reference is documentation or installed configuration, not something an email can cause the client to fetch or execute. For the read, the mapping MUST identify the existing resource lookup and the service-backed sources establishing the interaction, recipient, subject, type, contract digest, terms, expiry, decision state, operations, and typed details. Where the API returns several resources, the mapping MUST define a coherent proposal version over them. A collection of independently changing reads cannot establish exact terms unless the service binds the resulting snapshot. For each action, the mapping MUST specify the existing method and resource selection; the placement and encoding of the expected version; the sources of request values; authentication and tenant context; permitted success and pending-work responses; terminal and nonterminal error interpretation; and retry or idempotency behavior. Each semantic value MUST come from validated authoritative readback, a validated principal input, or trusted configuration. Email-provided identifiers MAY select records only within the independently authorized service and tenant. They MUST NOT provide request templates, method names, credentials, headers, or executable expressions. The mapping MAY be ordinary connector code. If distributed as an implementation manifest, its immutable contents MUST be addressed by digest and accepted through the host's installation policy. Native API descriptions can identify the operations and their schemas; this draft defines no general mapping language. Service bindings gives implementation guidance. Services need no MAP discovery endpoint.

HTTP origin and credential protection The client MUST use HTTPS with authenticated server identity and the service's existing authentication. The credential MUST already be authorized for the selected service resource and principal. A message cannot cause acquisition of a new credential or enlarge its audience, scopes, or tenant access. When OAuth is used, the client and service SHOULD use resource-restricted tokens, with the audience protections described in and . The client MUST send credentials only to origins independently authorized by the installed connector. The ordinary case is service.id; any additional origin MUST have an explicit trusted mapping and suitable credential audience. The client MUST NOT automatically follow redirects for a credentialed read or action, including same-origin redirects. A connector MAY interpret a documented relocation only as a new independently authorized operation, after repeating origin and method checks, without forwarding credentials merely because a response names a destination. Clients MUST bound response size and processing time. They MUST NOT execute scripts or fetch response-supplied locations except through the installed mapping. Cookies, client certificates, proxy credentials, and ambient browser sessions are credentials for these rules, not exceptions to them.

HTTP exact terms An implementation MAY use If-Match when the service-issued version is the strong entity-tag of the selected representation for the action request, as defined by . In that case it MUST use the exact strong tag, MUST NOT use a weak tag or *, and MUST perform strong comparison before the effect. A false precondition is reported as 412 Precondition Failed under RFC 9110. The client MUST NOT automatically replace the failed version and retry the decision. RFC 9110 also permits a success response when the server can determine that the same requested change has already succeeded. An implementation using that exception MUST report the prior decision without applying the effect again. It MUST NOT use the exception to accept changed terms or a different operation. An entity-tag obtained from a campaign resource is not automatically a precondition on a different approval resource. A binding MUST NOT send such a tag to the latter and claim that HTTP semantics bind the former. The API must explicitly support the relationship or expose the selected proposal representation with the appropriate tag. An existing API MAY instead accept an expected revision in its normal body, query, or service-defined header. The mapping MUST specify that mechanism and demonstrate its atomic enforcement. Its native conflict response MAY differ from 412; the connector MUST interpret it as a stale proposal without changing HTTP's meaning. A successful preliminary GET, an email digest, or a client-side comparison is not a substitute for service enforcement.

HTTP decisions, retries, and outcomes Safe methods MUST NOT perform MAP decisions. An action uses the existing unsafe method appropriate to the service operation. The service MUST recheck current authentication, authorization, recipient relationship, expiry, and proposal state at the decision boundary. It MUST reject any caller input that violates the contract even if the client already validated it. A 202 Accepted response establishes acceptance, not completion. Polling, callbacks, job identifiers, Location, and Retry-After retain their service and HTTP meanings. A connector MUST use only documented, trusted result operations and MUST preserve an unknown outcome after a timeout or lost response. It MUST NOT turn every 2xx into a completed semantic effect. If the API has an idempotency mechanism, the connector MUST follow its scope, lifetime, and request-identity rules. A retry of the same decision MUST preserve its idempotency identity and exact terms. A changed input, operation, or version is a new decision, not a retry. Without demonstrated replay safety, an indeterminate request MUST NOT be retried automatically. The client MAY read current decision state through its authorized mapping. Services MAY use problem details, ordinary status codes, or existing domain responses. This binding requires no new problem type. The mapping MUST distinguish an accepted decline from an error, an already recorded decision from permission to repeat its effect, and stale terms from retryable transport failure. It MUST NOT expose unauthorized resource existence or details while interpreting those responses.

HTTP example The MIME-to-service walkthrough uses an existing API described by OpenAPI and a native expected_revision argument. The following smaller example shows the alternative: an API that already supports HTTP conditional requests. Suppose an installed connector reads GET /v1/proposals/p7 at its configured service origin and receives an authorized proposal with the strong tag "p7-r4". The API documents PATCH /v1/proposals/p7 as a conditional update of that same representation. The host displays the current typed terms and obtains a decision. The connector then uses the API's existing update format: Authentication is omitted from this illustration. The path, PATCH method, and decision member belong to that hypothetical API; they are not MAP wire requirements. If the proposal changes before PATCH, the service applies nothing and responds with 412. An API that uses expected_revision in its existing body can conform without adopting this example's resource layout.

Experimental capability binding This optional binding permits a small class of decisions without a preexisting service credential. An operation carries a bearer URL in its capability.url member. No other member is allowed in that object. This URL is the sole exception to Core's rule that email cannot supply an executable destination. Implementations MUST explicitly opt into the binding. Unsupported capability data MUST NOT be executed or reinterpreted as a human link. This mechanism is not an extension to one-click unsubscribe and MUST NOT be advertised as RFC 8058 compatible. It uses the fixed-body and safe-navigation lessons of . Subscription removal remains a use case for that existing protocol, not a reason to define a parallel MAP contract.

Capability eligibility The exact contract MUST permit capability for the offered operation, declare all its effects, set exactTerms: true, and accept no semantic input. Its capability.kind MUST be one of the following:

• refusal: declines the exact proposal. Permitted effect identifiers are https://mailschema.org/effects/refusal and https://mailschema.org/effects/state, both REQUIRED. The refusal MUST NOT execute the proposed work, change access rights, cancel an independent commitment, or instruct communication to another audience.
• protective-report: records that the recipient reports the specified activity as unrecognized. The REQUIRED effects are https://mailschema.org/effects/protection and https://mailschema.org/effects/state. The report MUST NOT by itself lock or delete an account, revoke credentials, transfer assets, disclose protected data, or otherwise make a consequential account change.
• address-confirmation: confirms control of the addressed mailbox solely for a matching request previously initiated by the principal. The REQUIRED effects are https://mailschema.org/effects/assertion and https://mailschema.org/effects/state. It MUST NOT authenticate a session, reset a password, grant access, link an account, add a recovery authenticator, or confirm an unsolicited request.

No additional or unrecognized effect is permitted for these capability kinds. A human decision cannot waive this restriction. An operation with communication, disclosure, commitment, authorization, payment, or caller-supplied input MUST use an appropriately authorized credentialed or human route instead. The service MAY acknowledge the decision to the same principal through its ordinary receipt mechanism; it MUST NOT use that exception to deliver the proposal's content or notify a new audience. The contract MUST set a positive integer maximum lifetime. This binding imposes upper bounds of 604800 seconds for refusal, 259200 seconds for a protective report, and 86400 seconds for address confirmation. These are conservative MAP limits, not claims that another standard defines limits for all three effects. A type or service MAY choose a shorter limit. Expiry MUST be no later than issuedAt plus the permitted lifetime and no later than the interaction's expiresAt.

Capability origin and delivery All Core message-authentication and recipient rules apply, with strict DKIM author-domain alignment. The URL MUST be an absolute HTTPS URL without user information or fragment and MUST have the same origin as service.id. That host and the strictly aligned signing domain MUST have the same Organizational Domain under RFC 9989's discovery rules. A client MUST NOT substitute a last-two-label heuristic. An unresolved or ambiguous organizational relationship MUST fail closed. Local policy or a contract MAY require the exact same host or a previously approved first-party relationship. The producer MUST address the message to exactly one intended mailbox in To, with no Cc or Bcc, and MUST NOT send it through a mailing list or distribution group. There MUST be exactly one envelope recipient. The receiver cannot in general prove that no other envelope recipient existed; producer conformance covers this fact, and clients MUST NOT claim otherwise. A client MUST reject visible groups, additional recipients, known list delivery, or a mismatch with its trusted original-recipient evidence. It MUST NOT rely on the absence of a Bcc header to prove exclusive delivery. The capability MUST occur only in the designated machine part and MUST NOT be placed in readable links, tracking pixels, quoted prose, or the human URL. Each capability MUST bind one recipient, interaction, tenant where applicable, type contract digest, operation, terms identifier and version, and expiry. A service MUST generate at least 128 bits of cryptographically secure randomness, store only a cryptographic digest of the secret or an equivalently protected verifier, support revocation, and prevent secret disclosure through logs, telemetry, errors, or referrers. Possession is sufficient bearer authority. A recipient check by a compliant client does not stop a holder from copying the URL into another HTTP client. The contract's limited effects MUST therefore remain acceptable when exercised by anyone possessing the message. DKIM replay protection and non-transferability are not claimed.

Capability decision and request The host MUST validate the complete description and contract and obtain an explicit principal decision or apply an existing standing policy scoped to the understood effect, recipient, service, tenant, and typed values. Authentication of a previously unseen sender is not standing policy. The host MUST display the service origin and the limited effect for a human decision. It MUST treat the message's details as signed sender claims, not as an authoritative credentialed readback. For address confirmation, the host MUST additionally correlate the service origin, mailbox, purpose, and request identifier with a request recorded when its principal initiated it. The recorded request MUST be independent of the confirmation email. A human route can satisfy this rule using the authenticated or session-bound initiation flow; merely asking whether an unsolicited email looks familiar is insufficient. If the host cannot establish the match, it MUST NOT submit the capability. The client then sends exactly this request body, without a trailing newline: The method MUST be POST and the Content-Type MUST be application/x-www-form-urlencoded. No semantic parameters, alternate encodings, operation identifiers, or user input are permitted. The request MUST contain no cookies, HTTP authentication, client-certificate authentication, or Referer header. Clients MUST use an HTTP context isolated from browser sessions and ambient credentials. They MUST NOT follow redirects, including same-origin redirects. A service MUST NOT redirect a capability request. Before connecting, the client MUST apply its egress policy and reject loopback, private, link-local, unspecified, multicast, and otherwise non-public destinations. DNS resolution and connection establishment MUST be bound so DNS rebinding cannot bypass that check. TLS certificate and hostname validation remain REQUIRED. Clients MUST bound response size and time, MUST NOT execute or render response content, and MUST NOT fetch response links. A public HTTPS name and domain alignment alone do not make a destination safe.

Capability service processing The service MUST accept only the exact POST representation above. It MUST NOT perform the operation on GET, HEAD, OPTIONS, a form with extra fields, or a request with the wrong media type. It MUST resolve the token server-side and atomically check its scope, expiry, revocation, current proposal version, and decision state before applying the bound effect. A stale, withdrawn, expired, or superseded token MUST apply nothing. No client-provided field can change the operation or recipient bound to the token. The operation MUST be idempotent. Address confirmation MUST consume its confirmation authority on first successful use; subsequent uses MUST NOT create another confirmation, extend its validity, or authorize anything else. A service MAY return a non-sensitive acknowledgement for a repeated identical request. It MUST NOT reveal protected account, recipient, or decision details to a bearer. A consumer MUST NOT infer completion merely from an opaque response; it may claim only what the documented service response establishes. A lost response leaves the outcome unknown unless a safe retry or established service route resolves it. The fixed POST is not a replacement for CSRF protection on the human route. Services MUST keep its bearer validation separate from ambient authenticated browser authority. Link scanners normally issue safe requests, but a scanner or intermediary that extracts and POSTs bearer URLs can exercise them; the protocol cannot prevent that misuse by a bearer. This limitation is a reason for the narrow effect classes, not a reason to make GET actionable.

From a type to a service A type catalogue answers "what does this action mean?" An implementation record answers "which service supports it, and how can a client connect?" A host may use MailSchema's Registry, an organization catalogue or a locally installed collection. A client MUST select catalogues through its own configuration. Identifiers in email are lookup keys within those catalogues, not permission to fetch or install arbitrary resources. If no configured catalogue supplies the exact contract, the action remains unsupported. The Registry holds descriptions and evidence. Account permissions remain with the service; installation and execution policy remain with the host.

Type records A type record identifies the contract's URI, version, profile and canonical digest, together with a download reference, lifecycle status and maintainers. Examples and explanatory material MAY accompany it. The contract supplies the name, semantics and schemas; a record MUST NOT override them. Before use, a client MUST verify the downloaded contract's identity and digest. Matching a digest establishes which bytes were obtained. It does not establish that the publisher is trustworthy or that the client can enforce the contract's semantics.

Implementation records An implementation record MUST identify:

• the service origin and the party maintaining the integration;
• the exact contract identifier, version and digest;
• the operation identifiers it supports;
• the binding it implements;
• its lifecycle status, documentation and a support declaration or report.

If a record distributes an installable integration, it MUST also identify the artifact's location and digest, the exact digest procedure, and the supported host interface or declarative format. Built-in service support does not require a downloadable connector or public source code. A service listing describes support; it does not itself supply an executable connection. The binding value is an HTTPS identifier for its binding specification or documented service binding, not a closed transport enumeration. A client must explicitly support that binding; the identifier does not trigger a fetch. A declarative integration names the specific description or workflow format and profile it uses. A code integration names its actual host interface and version. Clients MUST NOT assume either form supports an unlisted contract version, operation or host. Records MUST distinguish a publisher's support declaration from an implementation report. A declaration states the scope claimed by the maintainer. A report identifies the implementation revision, tested roles and operations, setup, observations and missing coverage so others can reproduce it. The record MUST disclose common ownership when making an interoperability claim. A listing is not certification. A consumer-only report states its actual role; it is not a service implementation record.

First connection When the service is unconnected, a client MAY offer setup separately from the email's action. Setup MUST use a binding obtained through configured discovery and selected under host installation policy. The host MUST show the service identity, integration publisher, requested account access and supported effects before the principal grants access. An administrator can perform this setup for an organization under its policy. Authentication follows the service's existing mechanism. For OAuth, clients can use Protected Resource Metadata to discover authorization configuration for an independently selected resource. Such metadata does not attest to a MAP contract or authorize an action. MAP introduces no identity provider or DNS record. After setup, the consumer MUST restart Core processing for the waiting message. It MUST obtain current service state and reevaluate permission, terms, expiry and the offered operation. Approval to connect an account is not approval to carry out that message. If setup is unavailable or declined, the client MAY retain the readable email and its ordinary links. It MUST NOT present an unverified link as the service's trusted review route or fall back to another protocol, account or bearer action merely to make the operation succeed.

Client states Clients can use their own presentation and internal APIs, but MUST preserve these distinctions:

Situation	Required behaviour
Unsupported profile, contract or binding	Keep ordinary email readable; do not execute the action.
Service not connected	Offer explicit setup or the ordinary review link with its actual origin visible; do not label the link verified.
Permission missing	Explain that the current account cannot perform this operation.
Confirmation needed	Present the service's exact terms and requested effect.
Terms changed	Stop; obtain a new proposal and a new decision.
Expired, withdrawn or superseded	Disable the old action.
Decision accepted or work pending	Report acceptance or progress without claiming completion.
Outcome unknown	Preserve uncertainty; recover only through a trusted service mechanism.

A human route remains a separate service interaction. Its page must enforce Core's safe-navigation and confirmation requirements; opening it never performs the operation.

Versions and lifecycle

Separate identities Core, contracts and service bindings have separate identities. Adding a type does not change Core. Adding a service binding does not change the type. An implementation MUST list the exact contract digests it supports; support for a name or a numeric version range is insufficient. A published contract version fixes all its canonical bytes, including normative prose. Changing those bytes requires a new version and digest. A published binding revision likewise retains its original artifact. A record that offers an installable integration uses artifact.digestMode: canonical-json for an RFC 8785 representation or bytes for the exact downloaded artifact; both use SHA-256. The declared format determines which procedure applies; a JSON artifact is not implicitly canonicalized. Code artifacts use bytes. Consumers MUST verify the declared digest before installation and MUST NOT infer a different procedure to make it match. Lifecycle metadata, evidence and successor references can change without changing those definitions. Development previews MUST be labelled as drafts. A catalogue MUST distinguish a mutable preview from an immutable published revision. Clients MUST pin exact artifacts before execution, including when evaluating a draft. A publisher MUST NOT replace an immutable revision with a changed preview under the same identity.

Moving to a new version A successor record is a discovery hint. It MUST NOT rewrite an earlier message's contract, convert a prior decision or silently extend standing permission. The host can review and install support for the successor under its ordinary policy. A proposal using that successor needs its own current terms and decision. An older message may remain usable only while its exact contract and binding are supported and the service still authorizes its proposal. Retaining history does not oblige a service to keep accepting an old operation. Conversely, ending support does not justify deleting the published definition needed to interpret past messages. Core additions require a new profile when they change interpretation of the fixed description. Type-specific fields belong in the type's details or input schema. New transports have their own bindings. A consumer MUST refuse required features it cannot enforce; it MUST NOT guess a compatible interpretation.

Maturity labels A catalogue SHOULD distinguish Draft, Experimental, Stable, Deprecated and Superseded records. Draft means a definition is under review. Experimental means implementation experience is being gathered. Stable requires the publisher's stated evidence and review criteria. Deprecated discourages new use. Superseded identifies a replacement without authorizing migration. A status label alone proves none of those claims. Records MUST link the evidence or policy on which they rely. The current MailSchema contracts remain Draft, and illustrative mappings are kept separate from implementation listings.

Security considerations DKIM establishes domain responsibility for signed content, not the honesty of the sender or correctness of a proposal. A malicious domain can authenticate its own mail. Credentialed readback, independently selected connectors, narrow capability rules, and host policy are therefore separate requirements. A compromise of the authorized service or connector is outside the protection offered by the email description. The entire message is untrusted input to an agent. Producers and consumers MUST NOT interpret descriptive text as instructions to install tools, change policy, reveal secrets, contact new endpoints, or waive confirmation. Schema-valid text can still contain prompt injection. A host MUST retain control of tool selection and execution independently of model-generated text. Consumers MUST NOT automatically fetch or unfurl identifiers, human links, images, contexts, schemas, manifests, or response links because they occur in email. Authorized connector reads and approved capability requests remain subject to egress controls and response-size limits. Connectors MUST validate identifier placement so path traversal, query injection, cross-tenant access, and server-side request forgery cannot redirect their authority. A type MUST NOT request passwords, authentication codes, private keys, or payment-card credentials as operation input. Hosts SHOULD deduplicate, rate-limit, and group repeated prompts. They MUST NOT treat dismissal, timeout, a model's recommendation, or a prior unrelated approval as consent. Standing policies SHOULD be narrowly scoped to a trusted service, tenant, contract, operation, recipient, effect, and relevant typed values. Unknown effects and changed contract digests do not inherit approval. Sender-domain alignment does not distinguish tenants sharing a domain, and a TLS certificate does not prove that a particular tenant issued a request. Recipient, tenant, proposal, and principal binding MUST be checked independently. A capability copied or leaked from an otherwise authentic message remains usable by a bearer; clients cannot make it non-transferable by checking headers.

Privacy considerations Email may be retained, indexed, copied, and read by intermediaries. Producers SHOULD include only the preview information needed to understand the proposal and keep sensitive material behind the service's existing authorization. An opaque subject identifier is preferable to putting a secret or personal information in a URL. Digests do not conceal low-entropy personal data and MUST NOT be treated as anonymization. Readback and capability use reveal activity to the service. Hosts MUST apply local network policy before making those requests and SHOULD explain this behavior when a principal enables automation. Services SHOULD minimize retention of decision records and SHOULD disclose their retention policy. Audit records SHOULD identify the contract digest, exact terms, principal, and decision without logging credentials, bearer URLs, or unnecessary message content. Conformance fixtures MUST use synthetic identities and inert endpoints.

Conformance A claim MUST identify the MAP profile, supported roles, exact type contract digests, implemented bindings, and the evidence available. Core producer conformance covers description construction, MIME placement, readable correspondence, and message authentication. Core consumer conformance covers parsing, trust, recipient control, contract resolution, host decision, and applicable processing rules. Service conformance covers current state, authorization, exact terms, expiry, and decision integrity. Human-route conformance covers safe navigation and confirmed submission. HTTP and capability conformance add their respective binding requirements. A parser or schema validator alone MUST NOT claim consumer or service conformance. Passing an example or a vector subset MUST NOT be described as passing the complete profile. Evidence MUST distinguish executable tests from scenario skeletons and identify missing adapters. Shared ownership between implementations MUST be disclosed when reporting interoperability. Implementation reports MUST identify the tested profile version; evidence from another version does not establish conformance.

IANA considerations This document requests no IANA action. It uses the existing application/ld+json media type and HTTPS. Content-Purpose and SUPERSEDES are used through Structured Email and its referenced specifications; this document does not register duplicate fields. MAP defines no DNS record, well-known URI, OAuth metadata parameter, global HTTP problem type, or new authentication mechanism. Its profile, contract, and vocabulary identifiers use ordinary HTTPS URIs controlled by their publishers. Structured Email remains work in progress. Its applicable MIME and designation rules, and any resulting registration requirements for this vocabulary, need coordination with that work before RFC publication. The use of its container does not imply adoption of MAP by the SML working group.

Implementation Status This section follows and is to be removed before publication as an RFC. The specification source, four Draft Registry contracts, schemas, examples, and conformance scenarios are at . Artifact checks establish shape, digest consistency, and offline JSON-LD interpretation. Runtime scenarios are unimplemented skeletons. No MAP 0.3 runtime conformance or independent interoperability is claimed. Schema checks alone do not establish service behaviour. Feedback is sought on receiver authentication evidence, existing API readback mappings, atomic version enforcement, and the limited capability binding. The latter requires explicit opt-in and remains experimental pending implementation evidence. No MCP binding is specified here; the companion MCP walkthrough is illustrative. This document is prepared as an individual submission; it does not assert adoption by the Structured Email working group.

Normative References Informative References

Illustrative type contract This pinned contract revision illustrates how a type defines operations, effects, exact terms and permitted bindings. It is an example, not a required MAP type. The versioned JSON contract is its authoritative definition.

Publication Approval Authorize publishing one immutable content revision at stated destinations and visibility. Identifier: https://mailschema.org/types/publication-approval. Version: 0.1. Profile: https://mailschema.org/profiles/map/0.3. Canonical contract digest: sha-256:de91a49de4cba91209be253456e7c56709791fff877a060560d4eada0cc9468c. The service MUST bind the subject, recipient, service tenant, contract digest, and all action-relevant details to terms.version. Every decision MUST atomically compare that version and enforce current authorization, expiry, and proposal state. The service MUST freeze the referenced content revision and all other action-relevant inputs for accepted asynchronous work. If it cannot execute those exact terms it MUST stop that work; it MUST NOT substitute current mutable values. The host MUST obtain the actual immutable content and relevant destination or audience information through the trusted service binding before claiming a policy check over those values. A digest, title, preview, count, or identifier alone does not demonstrate content-policy compliance. The service MUST permit at most one terminal decision for the proposal. approve, decline, and request-changes are mutually exclusive terminal decisions for that proposal version. A revised proposal requires a new interaction and new decision. The request-changes operation MUST only record the supplied feedback and close this proposal as requiring revision. It MUST NOT generate, edit, approve, send, or publish revised content automatically. Feedback remains untrusted text. A capability offered for decline MUST be independently scoped to that refusal and exact proposal, expire within seven days of issuedAt and no later than expiresAt, and convey no authority to approve or supply feedback. Exact terms MUST cover all content and attachments, publication destinations and accounts, visibility, schedule, and the existing revision being replaced, if any. A change to any of these values requires new terms. The destination list MUST enumerate the exact locations affected. A mutable collection label MUST NOT authorize new locations added after approval. For restricted publication, audience.id and audience.revision MUST identify an immutable authorized readership; a vague label such as team is insufficient. Content digest MUST identify the immutable publication artifact. The trusted implementation MUST document its representation and verify the artifact. Approval of a title or an inaccessible digest alone MUST NOT be presented as review of the content. Publication approval MUST NOT change account permissions, purchase promotion, schedule unrelated content, or publish a subsequent revision. This contract authorizes publication. Approval under a different contract MUST NOT be treated as permission to publish without a new, explicit publication decision. Approve (approve). Authorize publishing this content on the exact terms displayed. Acceptance may queue the work; the connector MUST distinguish acceptance from completion. This decision does not grant standing permission for later proposals. Bindings: credential. Actors: human, agent. Exact terms: required. Effects: https://mailschema.org/effects/communication, https://mailschema.org/effects/disclosure, https://mailschema.org/effects/state. Input: none.

• accepted: The service accepted the exact decision; the authorized work may still be pending.
• completed: The service confirms publishing this content completed under the accepted terms.
• failed: The authorized work failed; the connector preserves the service's partial-progress information and MUST NOT claim that no external effect occurred.

Decline (decline). Refuse this exact proposal and close it without authorizing the requested work. The service MUST NOT execute the proposed work as a consequence of refusal. Bindings: credential, capability. Actors: human, agent. Exact terms: required. Effects: https://mailschema.org/effects/refusal, https://mailschema.org/effects/state. Input: none. Capability kind: refusal; maximum lifetime: 604800 seconds.

• declined: The service recorded refusal of this proposal.

Request changes (request-changes). Record specific feedback and close this proposal as requiring revision, without authorizing the proposed work or a future revision. Bindings: credential. Actors: human, agent. Exact terms: required. Effects: https://mailschema.org/effects/state. Input: an object validated by the contract's input schema.

• changes-requested: The service recorded the feedback; a revised proposal requires a new decision.

Description example This generated example uses synthetic identities and an inert service. The content digest is illustrative. Long code lines are folded as described in ; unfold them before parsing. The complete contract documents and schemas are maintained alongside the specification source.

Fixed JSON-LD context The following context defines the compact representation. Consumers resolve it locally, never from an email-triggered network request.