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

Reply via email to