[ietf-dkim] domain (reputation) semantics: selectors vs. sub-domains

[Douglas Otis]

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