On Jul 26, 2006, at 2:07 PM, J.D. Falk wrote:
On 2006-07-26 12:46, Mark Delany wrote:
In any event, the question is, what can be done about it? If we can't
stop it in the protocol, at best we can write unread admonishments.
I don't think anyone is /actually/ doing selector-based reputation
yet, though some of us have been thinking and even talking about it.
There could be a convention where only the right-most Selector is
considered when identifying the source. This would allow the left
most labels within the Selector to be used for key management. Just
as there was difficulty reaching consensus for more than three r=
values, Selector label names may be even harder, especially as this
also affects key handling.
The need is for a sender (who has been declared trustworthy by the
receiver via some entirely unrelated mechanism) to define different
classes of mail within the same user-facing domain. Doug tried to
answer this need with his r= proposal, but it made too many
assumptions about what those classes of mail would be and how
they'd be treated.
The r= permits partitioning sources using a common key when desired.
The r= proposal has been simplified from the first suggestion in
response to feedback, see:
http://www.ietf.org/internet-drafts/draft-otis-dkim-reliance-
level-00.txt
Much as with the Selector, the r= parameter couples with the key.
The basic concept this designation provides improved message
annotation in a fashion similar to that of Priority or Importance
headers.
r=1 (Assured)
r=0 (Normal or default)
r=-1 (Not Assured)
Perhaps a company wanting to retain a good reputation for their
Assured or high reliance assertions, limits which sources can obtain
the r=1 value. All other mail may normally receive nothing (r=0).
In cases where perhaps the source of the message is poorly vetted,
r=-1 could be used. Each of these separate categories can achieve a
separate reputation, and should also help the recipient when this is
included as part of the message annotation.
If subdomains can fill the need without adding any new complexity
-- and it sounds like they can -- then that's easy enough.
Sub-domains will likely introduce additional visual confusion.
People may not recognize accounts.example.com as being different from
accounts-example.com. When both name alterations become common, this
might actually increase a spoofing risk. What sub-domains should be
trusted? The parent or the sub-domain? What if the sub-domain is
signed by the parent?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html