MTA Hooks
charter-ietf-mtahooks-00-00

Description of Working Group

The MTA Hooks Working Group will standardise an HTTP-based protocol
by which a Mail Transfer Agent (MTA) delegates per-message
processing decisions to one or more external services across the
whole lifetime of a message: from the SMTP conversation that
receives it, through routing and delivery, to the generation of
delivery status notifications. The Working Group will produce a
Standards Track protocol specification using request/response
semantics, capability negotiation and JSON or CBOR serialisation,
together with operational and deployment considerations.

Some contemporary MTAs are able to delegate processing decisions to
external services for spam and virus filtering, policy enforcement,
compliance capture, cryptographic signing and content
transformation. The mechanisms that exist for this today cover the
reception of a message, from connection through the end of DATA.
However, the de facto standard for this delegation does not
facilitate common modern capabilities not directly related to the
SMTP state machine.

A diverse ecosystem of capabilities and implementations has evolved
around this. This work introduces a standard protocol by which
filters and MTAs can negotiate and interoperate, with support for
extensions and capabilities beyond the de facto standard.

Building on HTTP allows this protocol to take advantage of the
broadly developed frameworks supporting HTTP and RESTful
interfaces, including authentication, load balancing, and
observability.

Scope

The Working Group will produce a Standards Track specification of
the MTA Hooks protocol, covering:

• the wire protocol (request and response formats, headers, error handling);
• the discovery mechanism (well-known endpoint and capability document);
• the registration mechanism between MTA and scanner;
• the set of inbound and outbound processing stages at which hooks
  may be invoked, including delivery, deferral and delivery status
  notification;
• delegation of routing decisions before delivery, including
  per-recipient routing, the splitting of a delivery job that this
  implies, and per-destination TLS policy selection;
• the modification model by which scanners influence MTA
  behaviour;
• failure semantics, including the time a hook call is allowed to
  take, what happens when it exceeds that, and whether an MTA
  proceeds or defers when a service is unavailable;
• the composition of multiple services in a chain, including
  ordering and which actions terminate it;
• the security model, including authentication, transport,
  authorisation, and the limits an operator can place on what a
  scanner is permitted to change.

The Working Group will also document the operational
considerations of deploying the protocol, either as part of the
protocol document or separately.

Out of Scope

The following are explicitly out of scope:

• Specifying the Milter protocol, or a translation layer between
  Milter and MTA Hooks.
• Mailbox-level filtering. Filtering performed after final
  delivery is the domain of Sieve (RFC 5228) and is unaffected by
  this work.
• Specific filtering rules, content signatures, scoring
  algorithms, or detection logic of any kind.
• Modifications to SMTP, JMAP, Sieve, or any other existing IETF
  protocol.
• Definition or registration of specific scanner products,
  vendor-specific extensions, or filtering policy languages.
• Mechanisms for human users to interact with quarantines, review
  queues, or scanner administrative interfaces.

Deliverables

1. MTA Hooks Protocol Specification.
   Standards Track. Based on draft-degennaro-mta-hooks.

2. Operational and deployment considerations, either as a section
   of deliverable 1 or as a separate Informational document:
   deployment guidance, monitoring, and rollout.

Considerations

Architecture: the protocol places an external service in the path
of a message. The specification must define what the MTA remains
authoritative for, how a chain of scanners composes, and how a
scanner discovers which stages a given MTA implements.

Security: a scanner that can modify messages and influence routing
sits inside the mail system's trust boundary. The specification
must define authentication and transport requirements, and must let
an operator bound what a given scanner may change, instead of
leaving that to deployment convention.

Operations and scaling: hooks are invoked in the SMTP path, so the
work must address the time a hook call is allowed to take, what
happens when it exceeds that, and the behaviour of a scanner chain
when one member is unavailable.

Manageability: hook invocations and delivery events are the point
at which a deployment becomes observable. The work must define
stable identifiers that correlate a message across stages, so that
operators are not left reconstructing this from logs.

Transition: adoption is incremental. An MTA may implement a subset
of stages, and capability negotiation is how a scanner discovers
this. Gateways in either direction between Milter and MTA Hooks are
expected to exist, but specifying them is out of scope.

Milestones

M+0 WG formed; adopt draft-degennaro-mta-hooks as a WG draft.
M+3 Decide whether operational considerations form part of the
protocol document or a separate draft, and adopt any
separate draft.
M+12 WGLC on the protocol specification.
M+15 Submit the protocol specification to the IESG.
WGLC on operational considerations, if a separate document.
M+18 Submit operational considerations to the IESG, if a separate
document.

Relationship to Other Work

• Sieve (RFC 5228 et seq): complementary; Sieve filters after
  delivery, MTA Hooks filters at MTA processing stages.
• JMAP (RFC 8620, RFC 8621): the message data model is reused; no
  changes to JMAP are proposed.
• DKIM2 (DKIM WG, in progress): a potential consumer of this work,
  not a dependency. Nothing in these deliverables requires DKIM2,
  and no changes to it are proposed.