Murray S. Kucherawy wrote:
There might be a better way to characterize it, but I think the answer comes
from the errata RFC upon which we reached consensus a while back: The primary
payload delivered by a DKIM validation is the validated domain name.
Reputation, for example, would be checked against that, and not against the
body hash or some other part of the message.
That does not exclude any other functionalities.
The claim that it "binds elements related to the RFC5322 header fields with
the message body" is the means of the algorithm, not the end.
But the associations are still binding. They are direct associations,
especially 5322.FROM hence why author policy is still of interest for
the framework (and a WG work product).
I think these discussions get a little lost of how "applications"
should be applied. The out of scope Reputation Application is just
one of them, but it is not the only one. We got policy to work out at
some point and thats a WG item.
I posted this a while back but you will have input of various kinds
for the various "evaluators":
DKIM_RESULT = DKIM_VERIFY(MSG)
REP_RESULT = DKIM_REPUTATION(DKIM_RESULT, DKIM.D)
POLICY_RESULT = DKIM_POLICY(DKIM_RESULT, MSG.FROM, DKIM.D)
But these are not the only ones. You will see Expert System like
designs take place or systems with flexible rule based scripting
available to allow for local policy to be molded.
For example, an expert rule can be:
if a signature fails and has TESTING flag enabled,
then see if he stilling testing after __12__ months
then if so, negative classify this signer domain.
I indicated a long time ago that we be careful with t=y flag and add
guidelines track the usage. It was added.
Note, I think the focus with signer domain is fine for "trust" but it
must be recognize that there are other associations and efforts to
minimize it, I don't think will be well accepted to the layman market
place. Most will see what they see and DKIM signatures are passive
"extra" information.
All I like to distinguish is that attempting to only extract the valid
signer domain as good useful information must be mirrored with its faults.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html