Dave Crocker wrote:
However the real-world impact of such generalization of reputation
will be to defeat one of the major benefits of using domain names:
Differential reputations within a domain.
We *want* different reputations for transactions.paypal.com and
newsletter.paypal.com and corporate.paypal.com. Remember that these names
that are used to sign with DKIM are voluntarily chosen by the signer. If they
use different strings, they intend different assessment. If we assume an
inheritance, tree-based model for reputation, such as with paypal.com, we
eliminate this very useful ability to discriminate among different mail
streams coming from an organization.
I think the keyword in the above paragraph is "assume". People pro
assume that there is some relationship of some form between the parent
and child domain. It is a weak relationship at best because the mere
existence of an ADSP record obviates the need for such a check.
The above quoted text makes assumptions about how reputation systems
will work into the future. One thing we hear a lot about in other
contexts is reputation portability. If paypal were to create a new
service, it would want to borrow from its reputation. An ability to
express some means at the domain level would provide for that
portability. Absent that it has to go through the whole rigmarole all
over again.
But somewhere here I believe we've digressed into another issue...
This design ability with domain name-based reputation exactly matches the data
we have seen posted to the mailing list about actual reputation usage:
Reputation data for IP Addresses covers ranges, yes. But the statements about
domain name use say they are tied to a specific, complete name, not a string
that is the root of a sub-tree.
There is almost nothing there, and the field is nascent.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html