On Dec 11, 2007, at 11:31 PM, Jim Fenton wrote:
SSP does require one additional semantic over that of DKIM-base: in
addition to taking responsibility for the message, those domains
that publish SSP records other than "unknown" must assert that, when
the address in the From: header field is really their domain, that
this is actually true. Whether this assertion extends to the local-
part of the address is the subject of another issue (1399) so let's
discuss that part separately.
What can be safely deduced when a signature is not "on-behalf-of" a
particular header's email-address?
The "all" assertion offers no assurance a signature is "on-behalf-of"
of any header. The "all" assertion does not require the "originator
signature" (soon "author's signature"). The "all" simply indicates
_all_ messages from the domain are signed by _some_ domain. Such an
assertion makes no assurance that identities related to email-
addresses contained within signed messages have been authenticated.
Such an assertion of authentication of identities related to email-
addresses goes well beyond DKIM WG's charter!
In other words, those publishing SSP records must make sure that
they don't sign spoofed messages claiming to come from their own
domain. Aside from that, no assertion is made regarding the
content. As I have frequently said, I would not want a DKIM
signature to authorize a transfer from my bank account.
Your bank _MUST NOT_ assume identities associated with email-addresses
contained within DKIM signed messages have been authenticated! Use of
DKIM may mean when there is a problem, those causing problems lose
access. Review DKIM WG's charter regarding strong external assurances
of identities related to email-addresses.
This new semantic only applies to those who deploy (publish) SSP
records and therefore does not extend to DKIM-base (and therefore
does not require a modification to 4871). This semantic is not
currently described in the SSP draft, and needs to be in my opinion.
I do not agree. A DKIM signature ONLY means the message was handled
by the domain adding the signature. Not even "strict" (should)
require a domain's signature be "on-behalf-of" the From header. A
"strict" assertion likely needs an exception for restricted keys where
the i= parameter must be "on-behalf-of" the From header. (Per user
keys will likely prove to be a mistake.) When a domain makes an SSP
"strict" assertion, a message with a From email-address containing
this domain should only require signature by this domain (or a parent
of) regardless of which or whether any "on-behalf-of" header can be
How domain's making "strict" assertions avoid the spoofing of email-
addresses within their domain is an internal matter for that domain.
While such a problem is a concern, SSP does not dictate how this is
NOTE WELL: This list operates according to