On 5/3/10 8:58 AM, Alessandro Vesely wrote: > On 02/May/10 13:33, Douglas Otis wrote: > >> To retain security, the sender's domain needs to assert domain specific >> exceptions for "all" or "discard-able" ADSP policies. >> > That's false, under several acceptations of "security". /Necessity/ of > such assertions only makes sense if "security" is meant to be the > ability of a domain to restrict legitimate uses of its name, such as > its users writing to mailing lists, or to their grandma's. > ADSP "all" or "discardable" with specific third-party authorizations by a sender's domain does not restrict who may receive their message. This relates to who is trusted to modify the sender domain's messages. Lacking a valid signature, specific third-party authorizations permit enhanced security for recipients while avoiding message loss.
Sender's specific third-party domain authorizations indicate trust in a third-party service not to make malicious modifications. When a sender has not found their messages spoofed to mislead their recipients, they may not see value in making ADSP "all" or "discard-able" assertions. When a domain's messages are being spoofed to mislead recipients, there is no reason to expect spoofing will be limited to transactional messages. As such, greater security becomes possible without disrupting services by including a specific third-party authorization mechanism. Rather than separately signing third-party authorizations within a message using headers that might be stripped, there would be less overhead and greater conformance permitted when retrieving a hashed label from the sender's domain. This would permit use of F2F services that were specifically authorized. DNS has a DNAME resource record, that when published at the _adsp node, can synthesize CNAMEs when needed to permit a vouching service a means to assert authorizations on behalf many other sender domains. Of course, each sender domain could selectively authorize third-party services being used as well. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
