<snip>
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?
Please avoid this sort of comment moving forward.
Please also consider: https://datatracker.ietf.org/doc/statement-iesg-last-call-guidance-to-the-community-20210416/
> If substantive discussion of a technical comment is needed, then it is often appropriate to move that discussion to the WG list, once the comment has been made on the last-call list.
I encourage folks to take the deeper discussion of technical comments to the working group list.
--> > 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
