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.
NOTE WELL: This list operates according to