Section 8, Evaluating Behavior, seems to require an exact match. It says:
3. Compare the values to the corresponding DKOR header field
attribute values.
4. If either value does not match, then DKOR fails.
And the example in appendix A3 is wrong; it says:
Routed through a mailing list.
DKOR: i=1; [email protected]; [email protected]
DKOR: i=2; [email protected]; [email protected]
Using real addresses the second line would have been:
DKOR: i=2; [email protected]; [email protected]
Some lists use more complicated VERP addresses; some sites use SRS.
An alternative would be to compare only the domain part. However, for
large sites, the domain name alone would be a bit vague. DKOR (and
DKIM2) could impose a different criterion, so that a more rigorous
comparison can be made.
What's the idea?
Best
Ale
On 27/05/2025 01:13, Dave Crocker wrote:
Folks,
This revises DKOR to use a single header field, and to support the
addition of that field at each handling node along the way.
The draft has fleshed out both technical and documentation details quite
a bit. Also, it uses the alternative draft naming scheme, as requested.
I've taken a subset of the header field definition from Bron's draft.
/(As happens in such cases, this raises issues of document
authorship, should this draft proceed. I hope we get to the point
where that really is an issue. Based on having danced this
particular jig a number of times before, I doubt it will be a problem.)/
-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-dkim-dkor-00.txt
Date: Mon, 26 May 2025 16:05:53 -0700
From: [email protected]
To: Dave Crocker <[email protected]>
A new version of Internet-Draft draft-crocker-dkim-dkor-00.txt has been
successfully submitted by Dave Crocker and posted to the
IETF repository.
Name: draft-crocker-dkim-dkor
Revision: 00
Title: DomainKeys Originator Recipient (DKOR)
Date: 2025-05-26
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/archive/id/draft-crocker-dkim-dkor-00.txt
Status: https://datatracker.ietf.org/doc/draft-crocker-dkim-dkor/
HTML: https://www.ietf.org/archive/id/draft-crocker-dkim-dkor-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-crocker-dkim-dkor
Abstract:
DKIM associates a domain name with a message stream, using
cryptographic methods, to permit reliable and accurate reputation-
oriented analysis of the stream. It is possible for an authorized
user to conspire for additional distribution of a message, leveraging
the domain name reputation for promoting spam. This is called DKIM
Replay. DKOR defines a means of limiting that ability, by
associating original addressing information with the message's DKIM
signature, to detect distribution beyond the intended recipient.
DKOR uses existing DKIM services and only requires implementation of
the additional DKOR features by the signer and any receiving site
wishing to participate in DKOR services. Other DKIM receivers can
successfully process the same DKIM signature without knowledge of
DKOR.
The IETF Secretariat
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
