On Wed, Mar 26, 2025 at 3:09 PM Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
> On 3/26/2025 9:42 AM, Eric Rescorla wrote:> >
> > I believe the following paragraph should have a reference to DKIM,
> > which also provides a signature over the message.
>
> A continuing question, through these discussions is why? What is the
> goal for this topic, in this document, for these readers?
To accurately represent the technical situation.
> > up to the claim of the sender (in the signed From field), and in practice
>
> Having DKIM cover the From: field does not carry any assertion of
> authenticity.
The d= field alone is in fact a form of authenticity. Otherwise it
wouldn't be useful. I don't dispute that the authenticity properties
are complicated, but I don't think that's an argument for exclusion.
> > the mail server operator will often be able to control who gets
> > a credential for a given user at that domain.
>
> Sure. All sorts of good practices. Entirely outside the DKIM spec.
Actually, this sentence was talking about the fact that the owner
of the domain is generally free to reassign accounts to other people
and thus application-layer signing systems such as S/MIME
may not provide protection from the owner of the domain
impersonating a given user.
> DKIM was designed to permit any handler of the message to do signing,
> including the MUA, or other components that are not MTAs.
>
> Ultimately language such as you suggest promotes a misunderstanding of
> what DKIM does and does not do. This misunderstanding is pervasive, and
> very much counterproductive.
This seems like an argument for accurately stating those properties
in the relevant paragraph that talks about other signing mechanisms,
rather than just omitting it entirely.
-Ekr
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
