On Apr 26, 2006, at 4:05 PM, Michael Thomas wrote:
Douglas Otis wrote:
Being able to differentiate better vetted sources _within_ the
well- known domain restores a level of trust when messages are
both signed by the well-known domain, and also marked as
restricted (either transactional or administrative). This
assumes the well-known domain protects this trust by limiting
access to these special keys (denoted by special selectors). The
well known service provider or institution could have their
administrative or transactional messages obtain a trust
annotation, without fearing one of their millions of customers or
less trustworthy employees will spoof other customers by sending
a hazardous message asking to apply a browser plug-in, for example.
Why would this need standardization? All a domain needs to do is
decide for itself which selector subdomains to organize the
different kinds of traffic it views as, well, different, and
reputation systems ought to be able to figure this out for
themselves. Indeed, they MUST be able to independently establish that.
Standardizing selector tags to represent the signatures of messages
from vetted sources, allows a generic email viewing application to
limit annotations of trust to such sources without being specifically
tailored for each individual domain.
The generic indication of a message coming from a vetted source would
be independent of any third-party assessments. This would be
exclusively a signer assertion. The recipient could easily establish
what domains they consider well-known. To ease setup, well-known
domain lists could be shared among users. By establishing this
convention, only the well-known domain name is listed. Confusion
created by endless details of all possible key selectors, sub-
domains, and special email-addresses can thus be avoided.
The effort at restoring trust among consumers should not require
reputation services. Any violation of trust from a well-known domain
would likely become news worthy, prompting users to edit their own
lists as required.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html