My understanding as well that subdomains should be a separator, not the
selector function
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Wednesday, July 26, 2006 3:08 PM
To: ietf-dkim
Subject: [ietf-dkim] domain (reputation) semantics: selectors vs.
sub-domains
Folks,
I've heard a number of different groups say that they plan to make
semantic
distinction based on selector. For example, they intend to send
transaction
mail under one selector and marketing mail under another. Their intent
is to
have reputation services distinguish between one domain+selector and
another.
I believe this defeats the purpose of the selector and would like to get
some
working group discussion and consensus about this.
My understanding of the purpose of the selector mechanism is that it is
for
enabling multiple keys under the same domain name, where the domain name
is the
basic unit of semantic reference. Hence, selectors are an
administrative
convenience, not a mechanism for public (semantic) distinction. One
example of
intended use is to make the transition to a new key. As soon as
selectors are
part of the reputation semantics, this capability for transition is
defeated.
As I understand the DKIM design, the way to make semantic distinctions
is with
sub-domains. Note that these are in the d= parameter of
domainkeys-signature
field, rather than in the rfc2822.From field. So, d=transac.example.com
should
get a different reputation from d=market.example.com. The fact that
DKIM has
the domain name be decoupled from any other RFC 2822 header field that
uses
domain names makes this model extremely convenient.
Comments?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html