On Mon 21/Apr/2025 23:51:05 +0200 Richard Clayton wrote:
In message <[email protected]>, Dave Crocker
<[email protected]> writes
I've drafted a specification intended to provide a DKIM-based means of
controlling DKIM Replay, based on community discussions of what is needed.
I think you may have overlooked some aspects of what is needed to make a
difference to the current situation.
Your design records and signs the RCPT TO of the original email and
insists that there is only one recipient per email -- so far so good.
However, you do not capture whether an intermediate system has
intentionally replayed the message (and what their identity might be).
So, in DKOR, a mailbox provider will be aware -- just as today -- if
multiple copies of the same message turn up. They can tell if the
message arrived directly -- which is helpful.
What do you mean by "just as today"? Signing the recipients seems to be
exactly what DKOR seeks to bring. Kind of like Google's darn=, which also
doesn't reveal chains well.
However, there are numerous scenarios (often loosely described as
"forwarders" and "mailing lists" where the original RCPT TO is not the
address of the mailbox for which an email arrives.
In the DKIM2 design (which we have outlined and of which more RSN),
there is an explicit indication that an email has been "exploded" to
many recipients. In the DKIM2 design it is immediately possible to
identify (when a second copy arrives by whatever means) that a
unacknowledged replay ("explosion") is occurring. It would be expected
(local policies permitting) that later copies of the same message will
be rejected out of hand.
My quick look at the specs missed that explicit indication.
I know DKIM2 has many other features, but it is not clear which of them are
related to DKIM replay. The modification algebra, for example, doesn't matter,
since replayed messages are not modified.
When an explosion has occurred it may well be appropriate to deliver
every copy (some mailing lists are quite popular!) andthis is currently
done by manual configuration of the DKIM signature counting mechanisms.
The DKIM2 design, by attributing the "explosion" to a particular entity
means that configuration can be more straightforward -- essentially the
entity is asking permission to deliver multiple copies -- and local
policy will determine whether or not that permission is granted (and
perhaps rescinded thereafter, depending on receiver reaction) -- and
that same local policy will determine how many copies will be deemed
"too many" for an entity that has not been seen before.
I'm pretty lost here. How can a receiver predict how many copies of an
exploded message follow? And what kind of method can be used to determine the
maximum number of messages a policy can accept from a given, possibly
disposable, intermediate domain?
Furthermore, small domains won't receive many copies anyway.
Additional, the compulsory use of timestamps (which is not present in
DKOR) assists in timing out caches of DKIM2 signatures.
Adding compulsiveness to timestamps should be an easy task.
Instead of waiting for a perfect DKIM2 to be released, it might be useful to
check in advance what workarounds spammers will come up with.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
