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