On Wed, 2008-05-28 at 12:44 -0700, Dave Crocker wrote: > PRO > --- <snip>
> > It's mission-critical to prevent ADSP from complete uselessness through > > affixing an arbitrary host value to a domain that otherwise has done > > everything ADSP allows to protect itself. Please understand that an > > attackers use of "[EMAIL PROTECTED]" *still reflects badly* on > > paypal.com and the domain owner of paypal.com would definitely put a stop > > to that if he could. ADSP doesn't require reputation, so I think the above is out of scope. > CON > --- <snip> > The "still reflects badly" statement asserts that such unauthorized use of an > unregistered name will hurt the reputation of an organization's "root" > domain. > The assumption is that a specific domain name and all of the names under it > will share the same reputation. Again ADSP doesn't require reputation so I don't see this as a valid CON. Are there any other objections to the other PROs that were listed? > In terms of the affirmative, proactive model of DKIM and ADSP, seeking to > protect unregistered names creates is, therefore, wasted overhead. This is going with the assumption that such checks were done beforehand. Would there be less objection if the existence check was optional IF such test was done by a previous component? > An existence query might be worthwhile in terms of other concerns and models, > but it has nothing to do with the scope of this working group. Worse, it sets > entirely inaccurate expectations for DKIM and ADSP. If ADSP was the only component done in conjunction with SMTP, would the above statements still be true? The only expectation I have for DKIM is it provides a verifiable identity. Nothing more. Does DKIM seek to prevent other protocols from using this identity as they see fit? -- :: Jeff Macdonald | Director of Messaging Technologies :: e-Dialog | [EMAIL PROTECTED] :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
