On Nov 27, 2007, at 10:17 AM, Dave Crocker wrote:
Folks,
This note is about an old topic that seems to remain unresolved.
I'm posting it to see where the working group is on the matter:
Mechanisms like OpenPGP and S/MIME essentially validate the
authenticity of content. DKIM does not. For example, a DKIM
signature does not contain the semantics that claim that the From
field is correct, nevermind that it does not distinguish between
"brands" such as are often implied by the display string in the
From field, versus the email address in it.
DKIM is a mix of the two (as are pgp and s/mime).
It's setup to not only say "this message came from THIS recipient",
but also "THIS message came from this recipient".
Rather, DKIM's task is to allow an organization to say this it has
some responsibility for the message; that is, come to them if there
is a problem.
That, to me, is it's *intended* use, sure, but there's no denying
that a validly signed DKIM message asserts that the content has not
been tampered with since it was signed (within some fairly well-
defined limitations).
PGP, S/MIME and DKIM all make the same basic statement: "*this*
sender sent you *this* message and it's not been tampered with since
they signed it". Intended usage may be different, but the basic
function is the same.
In looking at the range of features that have been added to SSP, I
keep thinking that this distinction is not clear. It seems to me
that there is tendency to want to build "the content is valid"
mechanisms into SSP.
That's an entirely different question to the one you started with.
PGP and S/MIME make no assertions about unsigned messages, and nor
does DKIM.
SSP is primarily about making negative assertions about mail with a
particular from address that is not dkim signed. Given it makes
negative assertions I don't see how it can really be used as part of
a "the content is valid" mechanism other than by discriminating
between "I assert the content is invalid" and "I make no assertion
about the content".
Cheers,
teve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html