Jim,
Please read the following carefully and assume, just as a hypothetical, that I
might actually have a legitimate basis for the assessment being offered and
that there is a chance that your views are not automatically correct:
Jim Fenton wrote:
The goal of SSP is to determine the practices of the (alleged) author of
the message.
That certainly describes the engineering focus that has been taken for the
current draft. It does not necessarily represent the precise goal of SSP:
RFC 5016:
While a DKIM signed message
speaks for itself, there is ambiguity if a message doesn't have a
valid first party signature (i.e., on behalf of the [RFC2822].From
address): is this to be expected or not?
This requirements statement is actually self-contradictory, since the words
"speaks for itself" rather explicitly means that any signature is sufficient,
while the rest of the sentence seems to mean that the wishes of the purported
author dominate.
In any event, "on behalf of" is key wording that permits more flexibility than
you seem to be acknowledging. Note, for example, that the agent specified in
the Sender field is acting "on behalf of" the author.
Whereas SSP began as a simple idea as a means of deciding whether an unsigned
message should have been signed, it has morphed into an effort to validate the
From field. That is a very, very different goal.
While DKIM has the goal of assigning *any* identity to a message, so that that
identity can be assessed, the current work on SSP is attempting to instead
validate authorship.
For the purposes of ensuring the presence of any valid identity, using the
Sender: field is just as acceptable as From:. It also has the appeal of being
far simpler and, by the way, supporting a wider range of legitimate usage
scenarios.
Rather than deal with the problems caused by rigidly insisting on using the
author string, you seem intent on ignoring the feedback about those problems
and the remarkably simple and useful suggestion to switch to the Sender: field.
But, then, this focus on using author information goes back to a belief that
SSP can somehow be useful directly to end-users, in spite of there being no
empirical basis for believing this and plenty of empirical basis for knowing
that it will be trivial for bad actors to bypass this bit of "protection".
Let's pay some attention to likely efficacy, please.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html