On Nov 2, 2008, at 10:16 AM, Wietse Venema wrote: > Thiyaga: >> Hi Wietse, >> >> Thanks a lot for your comments! >> >>> This looks like a standard replay attack. Such technique can't be >>> used to send SPAM on behalf of domains that don't sign SPAM (e.g., >>> porcupine.org). If a domain is willing to sign SPAM, then they >>> deserve that all their messages are handled with great prejudice. >> >> >> Yes, I agree. It can't be used to send SPAM on behalf of domains >> that don't sign SPAM. >> >> But if it signs SPAM unknowingly (which may happen in large ISPs -- > > If a domain is willing to sign SPAM, then they deserve that all > their messages are handled with great prejudice.
I do not agree. As long as the "on-behalf-of" field within the DKIM signature accurately reflects what a domain authenticates when accepting a message for signing, then only messages signed with that identifier should be at risk of becoming blocked. A large ISP's domain is unlikely to find the entirety of their messages blocked. This is why ADSP is so destructive. ADSP impairs a domain from always asserting an accurate "on-behalf-of" field whenever the identity differs from what is found in the From header. ADSP should have been defined to only require a signature from the domain of the From header and not require the use of an Author Signature. > DKIM provides domain-level signatures. It is not a replacement for > user-level authentication systems such as S/MIME or PGP. Agreed. Which is why the DKIM signature should not be forced to be "on-behalf-of" the From header field! Any DKIM signature should be able to assert opaque identities only understood by the signing domain. DKIM is _not_ about assuring the identity of the author as ADSP pretends. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
