On Jan 31, 2006, at 9:45 AM, Dave Crocker wrote:
Given that SSP pertains to a topic that has little, if any, Internet-scale standardization or operations history, and given that it pertains to human/organizational rules, rather than lower- level bit-twiddling, it is also not a surprise that discussion about it requires wandering around the concept space rather more.
Agreed. The successful verification of a signature should stand on its own.
Such a successful signature may allow messages to be marked "trusted" when the signing-domain is found within a list of known trustworthy domains. This could be independent of whether an email-address in the message is also within the signing-domain. A violation of trust can easily occur by what is found within the message content, where perhaps greater attention is received. What may be indicated within a email-address could be shown only as the display-name anyway. If there is abuse, there is a known, previously trusted entity that can be held accountable.
There is risk associated with marking messages solely upon a basis that an email-address is within the signing-domain. This would assume the recipient can clearly see and know a trustworthy email- address from that of the thousands of potential look-alikes. If there is a problem, the entity involved may be unknown.
On average, the contained email-address may not be within the signing- domain, with the common practice of allowing the free use of email- addresses by large providers serving the public. Domains with minimal vetting such as these should be excluded from being listed as trustworthy, regardless whether the email-address matches. Messages from these sources should undergo the same scrutiny as given today.
Whether any reduction in scrutiny can occur with a policy that the domain's email-address MUST be within their signing-domain eliminates some but not all sources of uncontrolled abuse. Countering this abuse, it is doubtful that "bad" signatures can be distributed from a centralized service at a high enough rate to control this potential problem.
-Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
