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