Michael Thomas wrote:
Dave Crocker wrote:
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.
No it isn't. A signed message is a signed message. It doesn't say about
any relationship to any outside address. It speaks for itself. SSP is
about the subset of signatures that have a relationship with the From
address. Any signature is not sufficient by definition.
You are ignoring the "While... there is ambiguity" language, which ties these
two issues together.
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.
This is revisionist history. I've pointed to both of the historical
documents of IIM and DK which directly contradict you.
Evidently you missed the massive number of discussions both in the working
group and elsewhere that agreed that SSP was about unsigned messages. And,
just for the heck of it, note that you missed the "error" about this in the
DKIM Overview draft that has been circulating for quite a few months.
Given how little serious discussion has taken place in this working group, and
how little effort there has been to summarize discussions, it is not
surprising that you are quite convinced that you know exactly what the right
perspective is. You haven't been pressed to consider that the views you prefer
are seriously challenged.
Such certitude as greatly facilitated by strong language that persistently
dismisses contrary views, as has been the pattern for this working group.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html