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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
