A major objective of DKIM is to uncover spoofed messages. Often the
well-known domain-name establishes trust in messages. Atlas, not all
messages from well-known domain-names are always fully vetted, and
currently DKIM offers _no_ information on the level of vetting used
by the well-known domain-name for the source of the message. Some
have suggested sub-domains can isolate sources of differing vetting
levels. Some have adopted similar looking hyphenated domain-names.
Unfortunately, both practices will not indicate to the recipient
which domain-name should be trusted. The resulting profusion of
additional domain-names stemming from this glaring over-sight only
increases the likelihood of people being duped, thwarting the major
objective of DKIM.
DKIM already has an x= parameter designed to limit the time interval
of trust defined by the sender, over-riding the time intervals used
by recipients. There is unfortunately no r= reliance parameter. The
r= parameter can prevent a dangerous reaction where a number of
additional domain-names are deployed in an effort to restore trust
when damaged by poorly vetted sources. The r= parameter would allow
10 separate levels of trust to be accommodated by a single well-known
domain.
: The r= parameter is defined by the signer as a simple number
: of 0-9, where 0 is the default offering the lowest reliance
: level. To ensure control in the case of MUA signing, this r=
: parameter in the signature MUST always be less than or equal
: to the key r= level. If there are no r= parameters found in
: the key, the highest r= parameter allowed in the signature
: would be r=0. An instance where the key r= parameter is less
: than that of the signature, the signature is invalid.
At some later date, conventions for the assignment of the reliance
parameter, and the type of related message annotations could be
included in a BCP document.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html