A couple of enhancements to Plugin::DKIM (in the attached patch), prompted
by recent enhancements to the underlying module Mail::DKIM, which now also
supports DomainKeys signatures in addition to DKIM signatures, and is being
actively maintained, unlike Mail::DomainKeys.

- separate a signature verification from fetching a policy, which makes it
  possible to avoid one DNS lookups (by not fetching a policy) for each
  unverified message by setting score to 0 for all policy-related rules
  (DKIM_POLICY_SIGNALL, DKIM_POLICY_SIGNSOME, and DKIM_POLICY_TESTING).

  I also suggest that default scores for these three rules becomes 0.

  Currently the sender-provided policy is pretty much useless as it is
  mostly missing, or when available everybody has a testing flag turned on.
  This area of SSP is still pretty much in the clouds. Currently the
  only practical use is verifying a signature and providing a hand-crafted
  local equivalent of a policy and trust by rules and whitelist.


- let the check_dkim_testing() also take into account a testing flag
  in a public key, not just the one in a policy record (still lacks
  the final support in Mail::DKIM (missing a documented method),
  but the plugin is now ready). This is an equivalent change that
  was already made to Plugin::DomainKeys.


- skip fetching a policy (SSP) if a signature does verify, according
  to draft-allman-dkim-ssp-02: If the message contains a valid Originator
  Signature, no Sender Signing Practices check need be performed:
  the Verifier SHOULD NOT look up the Sender Signing Practices
  and the message SHOULD be considered non-Suspicious.
  This is an equivalent change that was already made
  to Plugin::DomainKeys.

- make some debugging messages more informative or concise;

- bug fix: protect fetching/parsing a policy record by eval { }
  to prevent a syntax error in a policy record from invalidating
  an already verified good signature;

- bug fix: if an identity tag (i=) is missing (this tag is optional),
  it should default to an '@' prepended to a domain (d=),
  according to draft-ietf-dkim-base-09; previously dkim whitelisting
  check was skipped when identity was not explicit ('i' tag missing);

- squash code in _check_dkim_whitelist() in half by factoring out
  duplicate code sections;


The patch does not introduce any incompatibilities with current use
or rules, nor does it depend on a particular version of Mail::DKIM.
It is just that DomainKeys checking is unavailable if the underlying
version of Mail::DKIM does not provide it.

Perhaps in the next major release of SA the use of Plugin::DomainKeys
should be discouraged in the docs, pointing out that Plugin::DKIM can
now cover for both.

   Mark