Small Clarification:
Hector Santos wrote:
My proposal is this:
We can reduce step 2 and 3 or short circuits the steps if the DKIM key
record obtained in step 1 contained the SSP policy information.
So in step 1, we can add a sub-steps:
1a) If we have a valid 3rd party signature or no signature, and
the key record contains a tag SSP=strict, then the message
is Suspicious and the algorithm terminates.
1b) If we have no signature, and the key record contains
a tag SSP=ALL, then the message is Suspicious
and the algorithm terminates.
To clarify these steps, requires the no-signature premise to be defined
as one resulting from where a key record was found but the DKIM
signature verification failed.
Allow me to change the sub-steps to say:
1a) If we have a valid 3rd party signature or no signature resulting
from a failed DKIM-signature validation, and the key record
contains a tag SSP=strict, then the message is Suspicious and
the algorithm terminates.
1b) If we have no signature resulting from a failed
DKIM-signature validation, and the key record contains
a tag SSP=ALL, then the message is Suspicious and the
algorithm terminates.
The point being is that a KEY record was obtained. We won't have a key
record when they is a "true, honest to god" no signature message, so
this proposal only applies when a message is "signed". When the message
is truly unsigned or the key record does not has the optional SSP= tag
it would continue with the step 2/3 SSP discovery process.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html