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

Reply via email to