On 10/27/2005 05:49 pm, Douglas Otis wrote: > 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
Was that a yes or a no? Scott K _______________________________________________ ietf-dkim mailing list http://dkim.org
