[Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Joe Peterson writes:

 > With DKIM, according to my understanding, you are supposed to treat a
 > "bad" sig the same way you'd treat "no" sig.

I don't think the spec says that.  It says:

   A verifier SHOULD NOT treat a message that has one or more bad
   signatures and no good signatures differently from a message with
   no signature at all; such treatment is a matter of local policy and
   is beyond the scope of this document.

Ie, the *verifier* must treat those cases in the same way, but that
clearly refers to passing the message on to the policy agent.
Verifiers MAY note that a signature failed and that fact MAY be
considered in subsequent processing (ie, by the policy agent):

   Verifiers SHOULD ignore any DKIM-Signature header fields where the
   signature does not validate.  Verifiers that are prepared to
   validate multiple signature header fields SHOULD proceed to the
   next signature header field, should it exist.  However, verifiers
   MAY make note of the fact that an invalid signature was present for
   consideration at a later step.

and

   An MTA who has performed verification MAY communicate the result of
   that verification by adding a verification header field to incoming
   messages.  This considerably simplifies things for the user, who
   can now use an existing mail user agent.  Most MUAs have the
   ability to filter messages based on message header fields or
   content; these filters would be used to implement whatever policy
   the user wishes with respect to unsigned mail.

   A verifying MTA MAY implement a policy with respect to unverifiable
   mail, regardless of whether or not it applies the verification
   header field to signed messages.

I think the intent here is that conceptually the MTA might wish to
refuse to accept mail that is unverifiable, but that it may not make a
distinction between no signature and a broken signature *at that
stage*.  (Of course the distinction between correct and broken
signatures is ambiguous in the presence of multiple signatures. *sigh*)

It is unfortunate that the draft conflates verifiers with policy
agents.  (Of course it makes sense that the same *application* might
implement both verification and policy enforcement; conceptually they
should be kept separate.  This is especially important with respect to
MTAs because milters are very frequently used to implement policy, and
they should not be subject to these restrictions.)

 > Personally, I think DKIM would be a whole lot more effective and
 > powerful if we *could* treat bad sigs as bad.

*You* (as a user or a site admin) can.  This is explicitly left up to
local policy.

 > Also, I think there is danger of people reacting to bad signatures
 > negatively.  Personally, I'd eye a failed sig with a more
 > suspicious eye than no sig.

Certainly.  What we really want is policy agents that are smart enough
to say to the user

  This message has a signature which verified successfully and one
  which failed.  According to the Received trace and the List-Id
  header, and correlated with the SENDER_IS_MAILMAN_BOUNCE heuristic,
  the successful signature was added by the Mailman Users mailing
  list.  The wooz.1april signature failed.

  In similar cases in the future for this mailing list, should I

  (o) Rely on the verified signature and silently accept the message
  ( ) Ask how to treat the message
  ( ) Silently discard the message

  [[Accept this message]]  [Discard this message]

(Of course if it's a milter it would have to be rule-based.)

YMMV, but HTH

Steve