Douglas Otis wrote:
On Sep 21, 2006, at 11:15 AM, Michael Thomas wrote:
Douglas Otis wrote:
On Sep 21, 2006, at 11:02 AM, Michael Thomas wrote:
Douglas Otis wrote:
o DKIM Strict: the state where the domain holder believes that all
legitimate mail purportedly from the domain are sent with a
valid DKIM signature and that non-compliant services are avoided.
What is difficult to understand with this definition? Is a
definition needed for non-compliant services?
How does this differ from scenario #1?
This definition better pertains to scenario #1 than does DKIM
Signer Complete which fails to offer assurances that non- compliant
services are believed to have been avoided. This defined state
allows greater clarity when attempting to differentiate between
Scenario #1 and #2. The term "Strict" was borrowed from Eric's
draft.
So is this an issue of just wanting to inject the word "strict"
somewhere into scenario #1?
If so, I've already said why I don't think that's helpful.
The term "DKIM Strict" is an alias for a defined state that excludes
non-compliant services.
Scenario #1 and #2 must be able to declare a different state to
ensure proper handling of their messages. Being able to
differentiate between these two states allows the 1% of instances
where different handling of signature failure is desired, without
potentially jeopardizing the delivery integrity of a domain that
asserts the "DKIM Signer Complete" state.
In the case of scenario #2, knowing non-complaint services are used
then permit all such known and well run non-compliant sources. These
sources will be rather easy to identify and list. However, making
this allowance for Scenario #1 would seriously reduced the desired
security being sought. If "DKIM Signer Complete" is allowed, then
"DKIM Strict" must also be allowed or this introduces a serious
security flaw when considering how a "DKIM Signer Complete" state
might be handled in practice.
I've read this three times and can't figure out how it is responsive to my
question.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html