[Emailcore] Re: [dispatch] DISPATCH guidance requested / Per-send sender identity verification for SMTP submission (SENDAUTH)

[John C Klensin <[e-mail]>]

Christopher,

While I'm responding to your message (started this many hours ago,
then had to put it aside), I've read and, where relevant, accounted
for, subsequent notes from you and others.  Nothing below responds,
other than very peripherally, to  the question, repeated by several
others, of whether you have evidence of significant interest to
implement this.
 
Not in any way speaking for DISPATCH, but my personal opinion on the
analogy to the STIR/SHAKEN approach and questions you raise toward
the end:

(1) Despite advice from others, not EMAILCORE.  "Core email
protocols" is defined very narrowly and message submission is out of
scope (as are extensions to it).  That WG is also getting very short
on energy and addressing your document would require a charter change
and open several cans of worms.  See John Levine's note on that
subject [1] as well.  While MAILMAINT is almost certainly the
existing WG that is closest to what you are looking for, it is
supposed to confine itself to work that is "too small to warrant
construction of a dedicated working group."  If my superficial
understanding of your proposal and where it fits into the scheme of
things, it is not that small, making a discussion with DISPATCH
appropriate.

(2) At least as far as I can tell, STIR/SHAKEN (and WebAuthn, etc.)
assume a real-time connection between message originator and
recipient.  Because email operates in a deliberately asynchronous
store and forward environment, the big challenge for any sender
(originator) authentication system isn't the identity verification at
message origination time but how the destination receiver (and
systems in between) can know and trust whatever authentication (and
authorization) has occurred in the communication between the message
originator and the MUA.  That has either involved tamper-proof
credentials or a situation in which everything further in the process
can know to trust the MUA.  In an environment in which every
intermediate (relay) system has the message and message headers in
clear and can tamper with them --at least to the extent needed to
create a false negative even if not a false positive-- that is a
relatively hard problem, one that has created serious (although too
often ignored, IMO) challenges for SPF, DKIM, DMARC, etc.  Easily
solved if one can do fairly direct handshakes between originator and
recipient (as in the STIR case), but, in the general case, email is
not like that.

(3) If your focus is really on the interaction between human and
client software, there is another problem.  For many years -- since
the early 1980s at least -- the IETF has carefully avoided getting
involved with the user interface side of MUAs.  The MUA-facing parts
of the message submission specification are, very deliberately, about
the interface between an MUA and a submission server.  How the MUA
gets whatever information it uses, even the formats of email messages
it is asked to process and where it obtains other information, are
not specified or even discussed.  There are many reasons for that but
two of them have been IETF recognition of its collective lack of
expertise in what are ultimately user interface rather that protocol
issues and the huge variety of MUAs and options for them.  The latter
is both something we have wanted to allow for and encourage and a
topic on which, if we took positions, we would probably be ignored.

So, for those reasons and ones discussed in more detail by others, I
don't see an easy path to IETF review and approval of this work. 

    john


[1]
https://mailarchive.ietf.org/arch/msg/emailcore/B06DkZv05yufAKIa6HH4O1zFAAY

--On Wednesday, September 2, 2026 01:27 -0400 [e-mail] wrote:

> I am preparing an Internet-Draft proposing a SENDAUTH extension to
> RFC 6409 (Message Submission for Mail) and am seeking DISPATCH
> guidance on the appropriate venue for this work and substantive
> feedback on the approach.
> 
> *Problem*
> 
> Existing email authentication standards, such as SPF (RFC 7208),
> DKIM (RFC 6376), and DMARC (RFC 7489), verify domains, not
> individuals. SMTP AUTH (RFC 4954) verifies identity at session
> login, but not at send time. This creates an exploitable window:
> any party with access to an authenticated session can send messages
> as the account holder without further identity challenge.
> 
> No current standard addresses per-send sender identity verification
> at the submission layer.
> 
> *Proposal*
> 
> The draft defines a SENDAUTH SMTP service extension that enables a
> Mail Submission Agent (MSA) to require real-time sender identity
> verification at the point of MAIL FROM. The key elements are:
> 
> -  A SENDAUTH EHLO keyword and challenge-response mechanism at
> submission time
> 
> -  A Sender Presence Attestation (SPA) format building on the
> WebAuthn/FIDO2 AuthenticatorAssertionResponse, adapted for the SMTP
> context
> 
> -  Two distinct submission classes: Human Submission Context
> (requires biometric, PIN, or hardware key verification per send)
> and Programmatic Submission Context (authenticated via machine
> credentials, exempt from per-send challenge)
> 
> -  A Sender-Verification-Result header field for downstream trust
> signaling, protected by DKIM signature
> 
> -  Mandatory support for fallback authenticators (PIN, hardware
> security key) where biometric hardware is unavailable
> 
> 
> *Precedent*
> 
> The approach parallels the STIR/SHAKEN framework (RFC 8224, 8225,
> 8226), which solved the analogous caller ID spoofing problem for
> voice telephony by requiring per-call identity attestation within a
> decentralized communication system. STIR/SHAKEN was subsequently
> mandated by the TRACED Act (2019), which passed with unanimous
> bipartisan support, establishing the precedent that standards-based
> identity verification can be imposed by legislation on a
> decentralized ecosystem.
> 
> The same standard-then-legislation path is envisioned here,
> following the model of BOD 18-01, which mandated DMARC adoption
> across federal .gov domains.
> 
> *Guidance Requested*
> 
> I would welcome feedback on the following:
> 
>    1. Is the appropriate venue for this work the emailcore WG, the
> DMARC    WG, or would a new effort (BOF) be warranted?
> 
>    2. Are there technical considerations or interactions with
> existing    standards that the draft should address?
> 
>    3. Is the human/programmatic submission distinction the right
> approach    for accommodating automated and transactional email?
> 
> The draft text (in kramdown-rfc format) is available at:
> https://github.com/email-sendauth/draft-sendauth.
> 
> Thank you for your time and consideration.
> 
> *Christopher Cocchiaraley*
> [e-mail]