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: > > > > Why not re-use the existing DKIM solution, just with a different > > domain / set of keys? > > Because it does not provide the affirmative information that I am > postulating/guessing the originating platform can supply. > I have to agree. It's compelling to consider that a high-trust domain might flag something for my extra consideration. This could be done per-message, rather than per-key, which was Grant's counterproposal; the equivalent is to generate a selector per message, which appears at least on the surface to suffer problems of scale. Rather than doing it in a header field, though, could it be done simply with a new tag? > 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. 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. -MSK, participating
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
