Subject: [ietf-dkim] Output requirements

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 10:39:03 -0700

Here's a more comprehensive proposal for an output summary (excuse the "diff" output):

+4.9.  Output Requirements
+
+   For each signature that verifies successfully or produces a TEMPFAIL
+   result, the output of a DKIM verifier module MUST include the set of:
+
+   o  The domain name, taken from the "d=" signature tag; and
+
+   o  The result of the verification attempt for that signature.
+
+   The output MAY include other signature properties or result meta-data
+   for use by modules that consume those results.
+
+   See Section 7.1 for discussion of signature validation result codes.

Right before Section 6:

-   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.
+   Verifiers SHOULD ignore those signatures that produce a PERMFAIL
+   result (see Section 7.1), acting 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.

In Section 7.1, get rid of SMTP-specific instructions since some verifiers are not connected to MTAs:

-   this time but may be tried again later.  A verifier MAY either defer
-   the message for later processing, perhaps by queueing it locally or
-   issuing a 451/4.7.5 SMTP reply, or try another signature; if no good
-   signature is found and any of the signatures resulted in a TEMPFAIL
-   status, the verifier MAY save the message for later processing.  The
-   "(explanation)" is not normative text; it is provided solely for
-   clarification.
+   this time but may be tried again later.  A verifier MAY either
+   arrange to defer the message for later processing, or try another
+   signature; if no good signature is found and any of the signatures
+   resulted in a TEMPFAIL status, the verifier MAY save the message for
+   later processing.  The "(explanation)" is not normative text; it is
+   provided solely for clarification.

More of same later, in the verifier steps:

    2.  If the query for the public key fails to respond, the verifier
-       MAY defer acceptance of this email and return TEMPFAIL (key
-       unavailable).  If verification is occurring during the incoming
-       SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply
-       code.  Alternatively, the verifier MAY store the message in the
-       local queue for later trial or ignore the signature.  Note that
-       storing a message in the local queue is subject to denial-of-
-       service attacks.
+       MAY seek a later verification attempt by returning TEMPFAIL (key
+       unavailable).

And again:

-   In general, verifiers SHOULD NOT reject messages solely on the basis
-   of a lack of signature or an unverifiable signature; such rejection
-   would cause severe interoperability problems.  However, if the
-   verifier does opt to reject such messages (for example, when
-   communicating with a peer who, by prior agreement, agrees to only
-   send signed messages), and the verifier runs synchronously with the
-   SMTP session and a signature is missing or does not verify, the MTA
+   In general, modules that consume DKIM verification output SHOULD NOT
+   determine message acceptability based solely on a lack of any
+   signature or on an unverifiable signature; such rejection would cause
+   severe interoperability problems.  If an MTA does wish to reject such
+   messages during an SMTP session (for example, when communicating with
+   a peer who, by prior agreement, agrees to only send signed messages),
+   and a signature is missing or does not verify, the handling MTA
    SHOULD use a 550/5.7.x reply code.

-   If it is not possible to fetch the public key, perhaps because the
-   key server is not available, a temporary failure message MAY be
-   generated using a 451/4.7.5 reply code, such as:
+   Where the verifier is integrated within the MTA and it is not
+   possible to fetch the public key, perhaps because the key server is
+   not available, a temporary failure message MAY be generated using a
+   451/4.7.5 reply code, such as:
    451 4.7.5 Unable to verify signature - key server unavailable

And finally:

    While the symptoms of a failed verification are obvious -- the
    signature doesn't verify -- establishing the exact cause can be more
    difficult.  If a selector cannot be found, is that because the
    selector has been removed, or was the value changed somehow in
    transit?  If the signature line is missing, is that because it was
    never there, or was it removed by an overzealous filter?  For
    diagnostic purposes, the exact reason why the verification fails
-   SHOULD be made available to the policy module and possibly recorded
-   in the system logs.  If the email cannot be verified, then it SHOULD
-   be treated {DKIM 2} the same as all unverified email regardless of
-   whether or not it looks like it was signed.
+   SHOULD be made available and possibly recorded in the system logs.
+   If the email cannot be verified, then it SHOULD be treated {DKIM 2}
+   the same as all unverified email regardless of whether or not it
+   looks like it was signed.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Apr 2011 21:02:50 +0200

On 29/Apr/11 19:39, Murray S. Kucherawy wrote:
> Here’s a more comprehensive proposal for an output summary (excuse the
> “diff” output):
> 

How about mentioning ignored signatures, e.g.,

  The output MAY include further data, such as properties or result
  meta-data of any signatures, including ignored ones, for use by
  modules that consume those results at any stage of the verification
  process.

(Just to make clear that all the "SHOULD ignore" are not conflicting
with this.)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 12:18:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, April 29, 2011 12:03 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Output requirements
> 

Works for me.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 29 Apr 2011 15:21:11 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Friday, April 29, 2011 3:18 PM
> > From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Alessandro Vesely

I suppose I can grudgingly live with this.

Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 29 Apr 2011 13:48:15 -0700

>> (Just to make clear that all the "SHOULD ignore" are not conflicting

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions