Hi,
one thing the draft doesn't explain is that the presence of both MAIL-FROM: and
RCPT-TO: allows a chain to be constructed where the domain of the previous
RCPT-TO matches the next MAIL-FROM. Since DKIM does not mark the sequence of
signatures, this should be inferred from the position of the signatures in the
header, assuming no reordering has occurred.
Wei posted a spec on how a message addressed to multiple recipients specified
in the To: and Cc: header fields doesn't need a separate field or tag to repeat
them. The message can be sent with a single signature, in a single SMTP
transaction. Only in case of Bcc: does it become necessary to specify the
recipient's address in the header, which implies single recipient.
The IANA Considerations section doesn't specify the DKOR fields.
I think it would be incredibly useful to come out with a specification like
DKOR, which doesn't substantially change DKIM, but allows us to test how
effective this method can be in preventing replay. In fact, nothing stops a
replayer from adding a signature by a disposable domain for each target; in
theory, it's just a bit more time-consuming.
Best
Ale
On Sat 19/Apr/2025 10:18:28 +0200 Dave Crocker wrote:
Hi.
I've drafted a specification intended to provide a DKIM-based means of
controlling DKIM Replay, based on community discussions of what is needed. The
spec also includes the return address coverage that has been discussed, though
I am not yet clear enough about its use to have attempted detailed explanation
of how it works.
As with most initial specs I do, I believe the design is reasonable, but am
quite sure that the details will be somewhere between deficient and terrible.
Please adjust comments and suggestions accordingly, with attempts to avoid
declaring the mere fact of either condition being appreciated.
d/
-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-dkor-00.txt
Date: Sat, 19 Apr 2025 01:11:11 -0700
From: [email protected]
To: Dave Crocker <[email protected]>
A new version of Internet-Draft draft-crocker-dkor-00.txt has been
successfully submitted by Dave Crocker and posted to the
IETF repository.
Name: draft-crocker-dkor
Revision: 00
Title: DomainKeys Originator Recipient (DKOR)
Date: 2025-04-19
Group: Individual Submission
Pages: 7
URL: https://www.ietf.org/archive/id/draft-crocker-dkor-00.txt
Status: https://datatracker.ietf.org/doc/draft-crocker-dkor/
HTML: https://www.ietf.org/archive/id/draft-crocker-dkor-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-crocker-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 requirements by the signer and any receiving site
wishing to participate in DKOR services. Other DKIM receivers can
process the same DKIM signature without knowledge of DKOR.
--
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]
