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.
It is a rare privilege to see someone formulate such an efficient case of mutual insult.
Alas, a generic response that applies to literally all work in the IETF lacks any substance or specificity relevant to the current topic.
Perhaps you could try a bit harder and a be bit more productive?
> > 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 itwouldn't be useful. I don't dispute that the authenticity properties
Yes it is and does.
But that is not what folk mean when they say it 'authenticates' a message.
> > 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.
Interesting point. How is it relevant to the suggestion that the SMTP spec cite DKIM?
> 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.
First explain why there needs to be any text at all about DKIM in the SMTP spec, where SMTP has literally nothing to do with DKIM and DKIM ha literally nothing to do with SMTP.
When you've created a compelling case(*) for that, it will make sense to haggle over price.
d/
(*) ie, established clear technical and/or operational need for
text about this capability to be in this specification, including
dealng with my original questions of who needs to consume that
information, relative to this document, and what they are expected
to do with it.
-- Dave Crocker Brandenburg InternetWorking bbiw.net bluesky: @dcrocker.bsky.social mast: @dcrocker@mastodon.social
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
