On Oct 27, 2005, at 1:52 PM, Scott Kitterman wrote:
Doug,
So is it your view that DKIM roughly at it stands, with SSP and
without your
"Opaque identifier" is fatally flawed and shouldn't go forward?
SSP, as it is currently defined, will cause a reduction in the
integrity of email delivery which, before this strategy, managed in
spite of inordinate abuse. This policy placed exclusively on the
From header will eventually coerce domain owners into making the
only protective assertion available that will _prevent_ the use of
most services and the loss of legitimate messages.
A rather simple remedy would also avoid overlapping OpenPGP and S/
MIME efforts in identifying the originator. Allow the DKIM SSP
policy assertion be referenced from the header associated with the
domain that "introduced" the message (Resent-Sender, Resent-From,
Sender, or From), and not the domain associated with the originator
(From).
With respect to DKIM, there should be greater consideration afforded
strategies needed to repel DoS and Abusive Message Replays (AMR).
The opaque-identifier could be an option readily available when
abusive replay becomes a problem. Revoking the message key is not
practical in most cases. Retention of binding information, dealing
with "throw-away" domains, DoS protections, and anti-message replay
strategies can work well together, and permit a plausible solution.
See Section 9.6 Message Replay Attack in:
http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.html
and
7. Protecting Recipients without using Mailbox-domain Authorization
8. Detecting a Path Change in:
http://www.sonic.net/~dougotis/id/draft-otis-mass-reputation-03.html
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org