The r= construct found in SSP is referenced from an email-address
domain contained within some message header field. One justification
for this mechanism was for phish reporting. Such reporting is better
done using an email-address convention such as dkim-abuse@ where
perhaps reports are also signed using DKIM (and perhaps formatted per
ARF) to be accepted. This added signature requirement would be to
avoid abuse of the abuse report vector and to provide better evidence
of abuse.
When mechanisms are intended to be specific to that of the key/
algorithm/access, allowing a unique location for publishing related
information allows groups or categories within the domain to be
established. For example, the construct of including a w=<group-
label> parameter within key indicates where within the domain this
group related information is published.
The access of this information could be based upon label prefixes to
further isolate various RRs.
The key is located using the construct found within the message as
follows:
signature parameters:
s=<label-a>.<label-b> d=<label-c>.<label-d>.<label-e>
The key is located at the following location:
<label-a>.<label-b>._domainkeys.<label-c>.<label-d>.<label-e>.
key parameter:
w=<group>
The group information is at the following location:
<group>._dkim_group.<label-c>.<label-d>.<label-e>.
In addition to this label being simply to group the keys, this also
allows reporting information to be specific tailored for the group.
At this location, various sub-grouping of keys could be
accomplished. Conventions established for group labels can
communicate associated vetting involved with this group of keys.
These standardized groups could be used in conjunction with message
annotations.
Some conventions for standardized labels could be:
admin: (restricted access)
user: (general access)
guest: (unrestricted access)
list: (list)
auto: (auto-response)
info: (promotional or general status information)
test: (for test only)
void: (no longer a valid group)
A large ISP could still have messages with the key within the admin
annotated as trustworthy, perhaps to indicate account status needs to
be updated or that the users system has been compromised. This added
level of trust would be desired when otherwise risky actions are
recommended. This type of message should be recognized separately
from those of just user, guest, list, auto, or info for example.
When non-standard groups are used, the annotation would be specific
for intra-domain use.
RR type TXT may provide the report vector. Other RR types could be
defined for future use.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html