ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com 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.
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.
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.
Thoughts?
I haven't been tracking the list all that closely so I'm not entirely
sure I
know what proposed features you're talking about. The current SSP
draft doesn't
seem to have any features I would classify as having these sorts of
semantics
(which I agree would be bad).
The one recent SSP extension proposal I've seen is the reporting
address idea,
which seems largely orthogonal to this.
Unintentional implication that such a service is being offered is another
matter. This is an easy trap to fall into. Consider the use of the word
"signed", which is rampant in these specifications. Yes, we're using
digital
signatures as part of this, so the verb is technically correct, but a
lot of
people read "signed" as "validating the content".
This begs the question of misconstrued by _whom_? Are we talking about
the average Joe, or spam filter writers, or what? I don't think that the
average
Joe is especially relevant here, so it must be some other group. And if this
is indeed the case what bad things might this misunderstanding lead this
group of people to do? This is all way to vague, IMO.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html