On Dec 4, 2007, at 4:43 PM, Steve Atkins wrote:
If it starts being deployed and we discover that the SSP false-
positive rate is too high we'll lose a huge amount of time rolling
back deployment of SSPv1 and working on a more realistic SSPv2.
The SSP false-positive rate will be driven primarily by the DKIM
false-negative rate. As that's a critical piece of data needed to
complete the SSP design to a level of quality suitable for
widespread deployment the wisest course of action would seem to be
to wait until we have wider DKIM deployment and more DKIM
operational experience, and then to gather that data.
Any domain asserting All or Strict will also likely cause false-
positives when their domain signs for headers other than the From but
the From also contains their domain. A domain dedicated to
transactional messages could ensure other headers are not signed
(perhaps by deprecating i= parameter use to make all signatures
ambiguous within the domain). This domain could also ensure only
trustworthy entities hold their private keys. One wonders whether
keys should have had a scope assertion to constrain which headers are
qualified to be signed. The header scope assertion could be placed
within SSP with a negligible increase in overhead. As it is now, SSP
will be checked in the case where the From header is not signed. An
SSP scope could indicate whether an exception should be made.
If a key is restricted with g=, a signature for anything other than
the From could be noted and serve as a filtering input. It seems
doubtful, in the general case, rejecting or placing these messages
into a junk folder will be the best choice. As it is now, poor
treatment of these messages is likely become common. This issue may
also prevent domain's wishing to assure recipients, to be unable to
consistently use the i= parameter. :^(
A key or SSP scope policy could indicate only From headers are valid,
and applied as a follow-on solution when ignoring i= parameters prove
problematic. Being generous in what is accepted for valid signatures
from the From domain seems like the best solution.
John Levine's suggestion of using i= identities as opaque identities
is very attractive, but this also prevents a domain of ever indicating
they sign everything when the definition of signed MUST include
matches with the i= parameter. Perhaps there should be a draft
created to offer a u= extension to hold opaque identifiers. This
would offer a consistent signed location where the domain and
identifier are assured to be related.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html