Dave Crocker wrote:
6. Signature Semantics
DKIM was devised to provide a means of declaring an (organization's)
that is taking "responsibility" for placing a message into the
This is a very constrained semantic for the signature, and really
no more than a delivery decision.
In reviewing the apparent semantics of full SSP use, I believe it
move a DKIM signature, which uses the same domain name as is in the From
field, into the realm of declaring content to be valid. This is a
demanding semantic and, I believe, moves the DKIM/SSP service into
competition with S/MIME and PGP. At best, this seems entirely
At the least, it is considerably more ambitious than the initial
discussed for SSP. For an initial version of a standard, more
To the extent that the above is not sufficiently clear:
As discussion on the mailing list this past week has made clear,
there is continuing working group disparity about the semantics of
using DKIM, with or without SSP. The use of SSP's handling options
clearly moves things into statements about message content. This
exceeds the semantics for which DKIM was designed. See, for example:
Before SSP can be stabilized the working group must reach consensus on
basic issues of semantics for the mechanism.
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
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.
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.
NOTE WELL: This list operates according to