The verifier should check the SSP record in cases where the message is insufficiently authenticated according to its local authorization policy. This could be because:
* There is no signature * The signature is present does not validate * The signature uses an algorithm that is deprecated by the receiver * The signature is not by the party that the receiver would want * The receiver feels like doing so It is not simply enough to have the three level policy 'I send nothing', 'I sign nothing', 'I sign everything'. That does not allow for algorithm agility which I believe is either an explicit security area requirement now or soon will be after the SHA-1 issue is addressed. We have to allow senders to configure their systems to securely support transitions from one algorithm to another. This affects cannonicalization, digest and signing. In addition we need an escape hole to allow senders to phase in use of DKIM rather than have it be all or nothing. Extending the policy record from the three level system to allow the selectors to be specified is a simple fix that addresses all the problems I list above and the transition use cases. With that extension in place any further adjustments to the policy space that may be required can be achieved through appropriate management of the key selector space. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
