On 8/29/2023 10:35 PM, Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker <d...@dcrocker.net> wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
> On 8/29/23 9:02 PM, Dave Crocker wrote:
>
Rather than doing it in a header field, though, could it be done
simply with a new tag?
In terms of semantics, that would work too. In terms of overall design
approach, it is essentially the difference between CISC and RISC.
The feature under discussion has nothing to do with core DKIM
functionality. Even better, it is likely to be used by a limited set of
signers. So keep it out of the core specification and make it an add-on.
In practical terms, putting something into a core specification say that
everyone has to implement it. Even if the text says or implies otherwise.
> Let a domain establish a bad reputation. Especially if it's being
> used for sending messages that are considered to be questionable.
Establishing a reputation takes time. The likely behavior of a bad
actor is within a very short time-frame.
And it is a single account, not the entire domain, that is the
problem.
Or even a single message.
Indeed.
And I've never understood why people get enamored of the idea of
relying on bad reputations to spot bad actors. A bad actor who thinks
it has attracted a negative reputation need only move to a new name in
an otherwise gigantic public namespace (domain name or IP address) to
start over from zero.
> Just use different domains / keys to indicate different things.
>
> No new standards. No new code. No new config.
And no new information. Hence, current mechanisms only, which are
not
all that successful for this problem.
This also presumes that operators currently develop reputation based
on (d=, s=) pairs. Is that so? I thought it was mostly just the d=
that matters.
For the current DKIM spec, d= was specified as /the/ domain that DKIM
was offering as an identifier.
Further, s= does not have precise, reliable semantics. It is, in
essence, a cookie that might be delivered back to the signer.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim