MTA Hooks support

[mdecimus]

• I already searched past issues
• I already checked the wiki/TODO page

Is your feature request related to a problem? Please describe.

Hi,

I am opening this issue to bring MTA Hooks (an emerging IETF specification) to your attention. It defines a standard, HTTP-based way for an MTA to delegate per-stage decisions (spam, virus, policy, DSN handling, etc.) to external services. The relevant audience is MTA implementers, which is why I am reaching out here. If you already have a Milter implementation, or have been asked for one and chosen not to build it, the rest of this issue is the part that matters.

At each SMTP processing stage (connect, ehlo, mail, rcpt, data on the inbound side; delivery, defer, dsn on the outbound side), the MTA sends an HTTP POST to a registered scanner. The request body carries the envelope, the parsed and raw message, authentication results, TLS state, and connection context. The scanner responds with an action (accept, reject, quarantine, etc.) and, optionally, a set of JSON Pointer modifications to apply to the request before processing continues. Multiple scanners can be registered against the same stage and run as a chain. Serialization is JSON or CBOR. The protocol is designed to be implementable from scratch in any language with an HTTP client or server library: no binary framing, no shared C library, no out-of-band channel, just HTTP over TLS with a documented schema.

Milter is the de facto integration point today, but it has known limitations that MTA Hooks is trying to address. Milter has no formal specification: it exists as a C library (libmilter) with undocumented wire semantics, and the two MTAs that support it (Sendmail and Postfix) have behaviourally divergent implementations. Milter has no concept of outbound or post-delivery hooks, whereas MTA Hooks covers delivery, defer, and DSN stages explicitly. Milter is awkward to implement outside C, while MTA Hooks is just HTTP, so it works with whatever HTTP stack, observability, auth, and proxy infrastructure you already have. Milter also has no capability negotiation, whereas MTA Hooks has a discovery document and per-registration capability negotiation, so MTAs and scanners can evolve independently without breaking each other.

A draft has been submitted to the IETF and a Working Group is being formed. The most recent revision is at https://datatracker.ietf.org/doc/draft-degennaro-mta-hooks/. There is an implementation in production in Stalwart Mail Server, and Rspamd has stated intent to implement scanner-side support.

If MTA Hooks is something your project would consider supporting, now or eventually, or if you have strong views one way or the other, please join the discussion list at https://mailman3.ietf.org/mailman3/lists/mtahooks.ietf.org/. The single most useful thing you can do is post a short note to the list saying that your project exists, that you are watching the work, and (if applicable) that you would consider implementing. That is genuinely useful: visible interest from MTA implementers is exactly what the IETF looks at when deciding whether the work should be standardised. You do not need to commit to anything, and you do not need to have read the draft in detail to post. If you do have time to read the draft and push back on anything in it, even better; implementer feedback at this stage shapes the protocol more than feedback at any later point.

Happy to answer questions here or on the list.

Thanks,
Mauro

[msimerson]

Well, that IS interesting, and it would be pretty straightforward to add support for it to Haraka. Shucks, it could almost be done entirely in a plugin.

[msimerson]

PS: congrats on stalwart, I've got an install with a couple canary domains running on it.

[mdecimus]

Thank you for checking MTA hooks and also for using Stalwart :)
Btw, are you on the modern email matrix room? If not you should join! The room address is #modern-email:matrix.org