On Dec 21, 2007, at 3:56 PM, Michael Thomas wrote:
They're secret. And obvious.
Is there a reason this list should not be able to review a strategy
that significantly limits signature coverage in order to comply with a
policy assertion?
In addition, it is a matter of interpretation as to whether a
mailing-list should remove signatures prior signing. It is not
that far fetched to predict dependence upon permissive signature
settings and mailing lists not removing prior signatures is likely
a recipe for future policy compliance problems and represents valid
concerns when deciding upon policy assertions.
What part of RFC4871 section 4.1 paragraph 3:
Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified.
is not clear? Your fanciful leaps of what-if's fly in the face of my
field tested 99.6% pass rate, not to mention that you are simply
wrong about what rfc4871 says.
This was section 4.2. "Interpretation" of section 4. "Semantics of
Multiple Signatures".
Following this sentence is:
,---
Verifiers MAY process signatures in any order of their choice; for
example, some verifiers might choose to process signatures
corresponding to the _From_ field in the message header before other
signatures. See Section 6.1 for more information about signature
choices.
Verifiers SHOULD ignore failed signatures as though they were not
present in the message. Verifiers SHOULD continue to check signatures
until a signature successfully verifies to the satisfaction of the
verifier. To limit potential denial-of-service attacks, verifiers MAY
limit the total number of signatures they will attempt to verify.
'---
Section 6.1 tends to repeat the same advice:
,---
When a signature successfully verifies, a verifier will either stop
processing or attempt to verify any other signatures, at the
discretion of the implementation. A verifier MAY limit the number of
signatures it tries to avoid denial-of-service attacks.
'---
If or when spam begins to abuse DKIM signatures, an evaluation limit
of one may not be unusual, or the exclusion of evaluations from
sources emitting a high level of invalid signatures. Fully benefiting
from DKIM may require removal of signatures known to be invalid.
Evaluating DKIM signatures requires more of heavily taxed resources.
The "even if they know that the signatures cannot be verified" may
prove to be bad advice. Changing this advice to "unless they know
that the signatures cannot be verified" does _not_ affect your 99.6%
results. The "even if they know that the signatures cannot be
verified" necessitates expending additional resources per message
checked. Is this really wise when spam is the majority of message
traffic?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
