On Apr 29, 2008, at 8:36 AM, Eliot Lear wrote:
Steve Atkins wrote:
It doesn't contain any operational justification or goal for
SSP. It describes what (one person) wants from SSP, it
does not explain why, and it definitely doesn't provide the
operational problem that SSP is intended to mitigate.
Well, I really don't know where to begin. Here's the text.
DomainKeys Identified Mail [RFC4871] defines a message level
signing
and verification mechanism for email. 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? For email, this is an
especially difficult problem since there is no expectation of a
priori knowledge of a sending domain's practices. This ambiguity
can
be used to mount a bid down attack that is inherent with systems
like
email that allow optional authentication: if a receiver doesn't
know
otherwise, it should not assume that the lack of a valid
signature is
exceptional without other information. Thus, an attacker can take
advantage of the ambiguity and simply not sign messages. If a
protocol could be developed for a domain to publish its DKIM
signing
practices, a message verifier could take that into account when it
receives an unsigned piece of email.
Put another way, you can't tell the difference between "doesn't use
DKIM" with "this is a forged message" without either SSP or some out-
of-band (and unmentioned) mechanism. If you're asking for more
specifics about what YOU should do with a message once it's
determined to (a) not have a valid signature and (b) have a policy
of signing all messages, I'm afraid that Dave and others have
befuddled this group into thinking that's a bad idea and somehow out
of scope.
And what's the actual operational goal for this?
If you can't give me the general goal, a concrete example or
two would be a good start.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html