Services already ask people to make decisions by email. Mail Action Protocol describes those requests so an agent or inbox can understand them, check the current proposal and help you act.
A campaign is ready to send. An article needs permission to go live. The request arrives in the email you already read, with a description an agent can understand.
01
A request arrives
The message identifies the service, what needs a decision and the choices available. A shared type says what each choice will do.
Campaign Send Approval · Exact terms
02
Your rules come first
A connection you approved reads the current proposal. A campaign send still needs your account permission. Your agent or inbox follows your rules and asks you when a decision needs approval.
Connected account · Current proposal · Your policy
03
The service checks again
The service checks the terms and your permission as it records the decision. A changed audience, revoked permission or earlier decision stops the action.
Same terms · Permission checked · Decision recorded
The specification
MAP↗
MAIL ACTION PROTOCOLWorking draft
Mail Action Protocol
Describe it once.
A type gives a decision the same meaning across services. Campaign approval names what will be sent, by whom, to which audience and when. Each service keeps its own interface and permissions.
MAP defines what the email says and what must be checked before anyone acts. A connection you approved uses the service's existing operations.
A request arrives by email. MAP says what the decision means. The service can keep its existing API, tool or messaging system, provided it can check permission and the exact proposal when the decision is made.
The service checks permission and exact terms when it records the decision.
MAP can use existing service descriptions, account access and discovery. The interfaces shown here have been researched, not implemented as MAP integrations.
Sending a campaign, publishing an article, confirming an address and reporting unfamiliar account activity are different decisions. Each type says exactly what its choices mean.
If your service asks people to decide something by email, show the request and what each choice does. A useful type should work for more than one service.