Looking for a solution with regard to this statement:
,---
|4. Semantics of Multiple Signatures
|...
| Signers SHOULD NOT remove any DKIM-Signature header fields from
| messages they are signing, even if they know that the signatures
| cannot be verified.
'___
There should be additional advice provided allowing the signing
domain a means to avoid verification failures and the verifying
domain a means to avoid unnecessary verification attempts.
A process that verifies DKIM signatures should limit the number of
attempts. This comment however ignores the affect of a verification
limit or that there is a DDoS potential when reasonable limits are
not placed upon the verification process. One technique for
excluding invalid signatures would be to inspect the DKIM signature
header field bh= tag. The l= parameter could be compiled for all
signature verification candidates, and compared against the bh= tag
value during the hashing process when the l= tag is satisfied.
Checking the bh= tag in this manner offers a means exclude many
invalid signatures. The hashing process should be faster than
signature verification until the message exceeds some size, such as
100 KB for example. A trade-off based upon message size might also
rate limit the verification process.
Unfortunately, there is not a separate hash value (or even a simple
checksum) for headers. It is possible that a signing domain might
introduce a header, without altering the message body. If this added
header causes a set of signatures to become invalid that also contain
a valid body hash, this may result in the added signature not being
verified. Verification limits could be very low, especially
considering as much as 80% of email may be undesired.
There are possible strategies to avoid this situation. One technique
could intentionally obfuscate the bh= hash values to ensure known
invalid signatures do not consume verification attempts. The
obfuscation technique could overwrite the first base64 encoded bh=
value with the '!' character. This obfuscation technique allows
diagnostics a means to recover this value when attempting to
determine the cause of a signature failure. One other somewhat
intrusive strategy could prefix information to the message body to
ensure the bh= hash excludes the consideration of the signature. The
bh= value obfuscation technique seems significantly less intrusive.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html