-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.
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 is 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.
Additional, the compulsory use of timestamps (which is not present in
DKOR) assists in timing out caches of DKIM2 signatures.
>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.
I trust your wish has been honoured
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaAa9yWHfC/FfW545EQLeigCgqErU9sZzzqs/JyjCYsxOrxoZ1jAAmwSa
o71RpmRSTYauCQ3usfnFgfAn
=lLp/
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
