On 5/5/10 5:22 PM, Murray S. Kucherawy wrote: >> On Behalf Of Douglas Otis Sent: Wednesday, May 05, 2010 8:59 AM >> >> It is clear that sharing DKIM keys will not scale, determining spoofed >> mailing-list by ISPs will not scale, publishing SPF address lists will >> not scale. However, since the publishing of hash labels can be >> automated or delegated, why would this be something that does not >> scale? >> > There are two points here that don't scale to me: > > 1) I don't think putting a burden on the users to register every list to > which they might want to subscribe, or become subscribed, is scalable. Most lists today require a subscription process. An exchange upon acceptance of a subscription could trigger the publication of TPA records for service domains. > They will forget, or do it wrong, or lists will relocate to different > domains, or a host of other scenarios, and then mail will start bouncing and > complaints will fly. > A list changing its domain will cause similar problems. Has anyone described lists changing their domain as causing a scaling issue? A mailing-list changing its domain in conjunction with use of ADSP "all" would cause users to receiving similar feedback and to raise similar complaints. Since third-party authorization eliminates a need for policy exceptions, use of ADSP "discardable" could be deprecated as a bad practice that causes lost messages. > 2) I don't think that a large organization with security-focused operations > people will think kindly of the idea of user-generated data making its way > into the DNS, whether that's an automated process or not. That doesn't even > touch on the issue that user-generated data is being used to publish some > kind of authorization of the use of that domain by others. > Unlike SPF authorizations that would include any message handled by a server, a DKIM third-party authorization is limited to the specific service domain. And unlike SPF authorizations, the service domain can be differentiated from servers of the Author Domain and annotated as such. The authorization of the third-party service only requests specific exceptions when applying restrictive ADSP policies.
By not leaving ADSP exceptions open to the discretion of any number of receiving domains, a security focused operation retains its ability to take effective actions when a problem is detected. In addition, unlike SPF authorizations, an automated audit of the third-party message handling should provide reasonable assurances against spoofing. No such assurance is possible with SPF authorizations. There was never a suggestion that user generated data be published in DNS, nor that automation exclude reputation checks or auditing procedures. It should be clear that being able to request specific ADSP exceptions for third-party services only _enhances_ security when governed by those having the greatest interest in protecting recipient trust. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
