On Nov 27, 2007, at 12:26 PM, Arvel Hathcock wrote:
> It is SSP's way of trying to give direction about the behavior
> of receive-side filters.)
It is SSP's way of offering input for use with the receive-side's
decision making tree. Receivers can decide whether and how much
import to place on such offered input (if any at all). We must
resist the tendency to think that doing so is unprecedented (it's
not) or somehow out-of-bounds (it isn't).
Agreed.
Message filtering is likely how DKIM will be initially used. Abuse of
DKIM may restrict validation of signatures to those domains considered
trustworthy. If so, any DKIM related annotations may convey more than
it should to a recipient. Allowing SSP to assert the scope of
identity authentication might help mitigate mistakes made when the
localpart of the email-address is otherwise annotated as
"authenticated" simply because it was included within the i=
parameter, although not actually authenticated at the author
granularity, but rather at the group.
MUAs may seek to annotate those elements of a message asserted valid
by a DKIM signature. These MUAs will likely delve into what i=
semantics convey with respect to the From header. The From header is
being protected by SSP assertions from being spoofed after all.
DKIM does not clarify who added the signature, the MUA or the MSA.
Finding the localpart within the DKIM signature i= parameter means
what? When the recipient wants better clarification, should the DKIM
WG say DKIM NEVER assures identify validation? Have expectations
changed and authentication of the From header is considered out-of-
scope? The base draft left this issue cloudy. It seems SSP should
shed light on this rather basic DKIM semantic.
Can the DKIM signature make a specific assurance that the related From
email-address user has been authenticated? If so, this necessitates
some type of assertion within the key, or SSP record. As illustrated
by the TPA-SSP draft, SSP can be very flexible and much easier to
manage.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html