Another related example of multiple signers might be forwarding services, such as those commonly associated with academic alumni sites. INFORMATIVE EXAMPLE: A recipient might have an address at members.example.org, a site that has anti-abuse protection that is somewhat less effective than the recipient would prefer. Such a recipient might have specific authors whose messages would be trusted absolutely, but messages from unknown authors that had passed the forwarder's scrutiny would have only medium trust.
their choice; for example, some verifiers might choose to process signatures corresponding to the From field in the message header before other signatures. See Section 6.1 for more information about signature choices. INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate valid signatures with invalid signatures in an attempt to guess why a signature failed are ill-advised. In particular, there is no general way that a verifier can determine that an invalid signature was ever valid. 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.
RFC2045] before signing. Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm. If the message is submitted to the signer with any local encoding that will be modified before transmission, that modification to canonical [RFC2822] form MUST be done before signing. In particular, bare CR or LF characters (used by some systems as a local line separator convention) MUST be converted to the SMTP-standard CRLF sequence before the message is signed. Any conversion of this sort SHOULD be applied to the message actually sent to the recipient(s), not just to the version presented to the signing algorithm. More generally, the signer MUST sign the message as it is expected to be received by the verifier rather than in some local or internal form.
RFC2821] explicitly permits modification or removal of the Return-Path header field in transit. Signers MAY include any other header fields present at the time of signing at the discretion of the signer. INFORMATIVE OPERATIONS NOTE: The choice of which header fields to sign is non-obvious. One strategy is to sign all existing, non- repeatable header fields. An alternative strategy is to sign only header fields that are likely to be displayed to or otherwise be likely to affect the processing of the message at the receiver. A third strategy is to sign only "well known" headers. Note that verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. For this reason, signing fields present in the message such as Date, Subject, Reply-To, Sender, and all MIME header fields are highly advised. The DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed. Signers MAY claim to have signed header fields that do not exist (that is, signers MAY include the header field name in the "h=" tag even if that header field does not exist in the message). When computing the signature, the non-existing header field MUST be treated as the null string (including the header field name, header field value, all punctuation, and the trailing CRLF). INFORMATIVE RATIONALE: This allows signers to explicitly assert the absence of a header field; if that header field is added later the signature will fail. INFORMATIVE NOTE: A header field name need only be listed once more than the actual number of that header field in a message at the time of signing in order to prevent any further additions. For example, if there is a single Comments header field at the time of signing, listing Comments twice in the "h=" tag is sufficient to prevent any number of Comments header fields from being appended; it is not necessary (but is legal) to list Comments three or more times in the "h=" tag.
Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. INFORMATIVE EXAMPLE: If the signer wishes to sign two existing Received header fields, and the existing header contains: Received: <A> Received: <B> Received: <C> then the resulting DKIM-Signature header field should read: DKIM-Signature: ... h=Received : Received : ... and Received header fields <C> and <B> will be signed in that order. Signers should be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or otherwise reordered. Trace header fields (such as Received) and Resent-* blocks are the only fields prohibited by [RFC2822] from being reordered. In particular, since DKIM-Signature header fields may be reordered by some intermediate MTAs, signing existing DKIM- Signature header fields is error-prone. INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits header fields to be reordered (with the exception of Received header fields), reordering of signed header fields with multiple instances by intermediate MTAs will cause DKIM signatures to be broken; such anti-social behavior should be avoided. INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this specification, all end-user visible header fields should be signed to avoid possible "indirect spamming". For example, if the Subject header field is not signed, a spammer can resend a previously signed mail, replacing the legitimate subject with a one-line spam.
o Bcc, Resent-Bcc o DKIM-Signature Optional header fields (those not mentioned above) normally SHOULD NOT be included in the signature, because of the potential for additional header fields of the same name to be legitimately added or reordered prior to verification. There are likely to be legitimate exceptions to this rule, because of the wide variety of application- specific header fields that may be applied to a message, some of which are unlikely to be duplicated, modified, or reordered. Signers SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk. For example, e-commerce sites sending primarily purchase receipts, which are not expected to be processed by mailing lists or other software likely to modify messages, will generally prefer "simple" canonicalization. Sites sending primarily person-to-person email will likely prefer to be more resilient to modification during transport by using "relaxed" canonicalization. Signers SHOULD NOT use "l=" unless they intend to accommodate intermediate mail processors that append text to a message. For example, many mailing list processors append "unsubscribe" information to message bodies. If signers use "l=", they SHOULD include the entire message body existing at the time of signing in computing the count. In particular, signers SHOULD NOT specify a body length of 0 since this may be interpreted as a meaningless signature by some verifiers.
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. 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. INFORMATIVE NOTE: The rationale of this requirement is to permit messages that have invalid signatures but also a valid signature to work. For example, a mailing list exploder might opt to leave the original submitter signature in place even though the exploder knows that it is modifying the message in some way that will break that signature, and the exploder inserts its own signature. In this case, the message should succeed even in the presence of the known-broken signature. For each signature to be validated, the following steps should be performed in such a manner as to produce a result that is semantically equivalent to performing them in the indicated order.
INFORMATIONAL NOTE: The tags listed as required in Section 3.5 are "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a conflict between this note and Section 3.5, Section 3.5 is normative. If the DKIM-Signature header field does not contain the "i=" tag, the verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag. Verifiers MUST confirm that the domain specified in the "d=" tag is the same as or a parent domain of the domain part of the "i=" tag. If not, the DKIM-Signature header field MUST be ignored and the verifier should return PERMFAIL (domain mismatch). If the "h=" tag does not include the From header field, the verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed). Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired. Verifiers MAY ignore the DKIM-Signature header field if the domain used by the signer in the "d=" tag is not associated with a valid signing entity. For example, signatures with "d=" values such as "com" and "co.uk" may be ignored. The list of unacceptable domains SHOULD be configurable. Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (unacceptable signature header) for any other reason, for example, if the signature does not sign header fields that the verifier views to be essential. As a case in point, if MIME header fields are not signed, certain attacks may be possible that the verifier would prefer to avoid.
the order indicated (in some cases, the implementation may parallelize or reorder these steps, as long as the semantics remain unchanged): 1. Retrieve the public key as described in Section 3.6 using the algorithm in the "q=" tag, the domain from the "d=" tag, and the selector from the "s=" tag. 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. 3. If the query for the public key fails because the corresponding key record does not exist, the verifier MUST immediately return PERMFAIL (no key for signature). 4. If the query for the public key returns multiple key records, the verifier may choose one of the key records or may cycle through the key records performing the remainder of these steps on each record at the discretion of the implementer. The order of the key records is unspecified. If the verifier chooses to cycle through the key records, then the "return ..." wording in the remainder of this section means "try the next key record, if any; if none, return to try another signature in the usual way". 5. If the result returned from the query does not adhere to the format defined in this specification, the verifier MUST ignore the key record and return PERMFAIL (key syntax error). Verifiers are urged to validate the syntax of key records carefully to avoid attempted attacks. In particular, the verifier MUST ignore keys with a version code ("v=" tag) that they do not implement. 6. If the "g=" tag in the public key does not match the Local-part of the "i=" tag in the message signature header field, the verifier MUST ignore the key record and return PERMFAIL (inapplicable key). If the Local-part of the "i=" tag on the message signature is not present, the "g=" tag must be "*" (valid for all addresses in the domain) or the entire g= tag must be omitted (which defaults to "g=*"), otherwise the verifier MUST ignore the key record and return PERMFAIL (inapplicable key). Other than this test, verifiers SHOULD NOT treat a message signed with a key record having a "g=" tag any differently than one without; in particular, verifiers SHOULD NOT prefer messages that
seem to have an individual signature by virtue of a "g=" tag versus a domain signature. 7. If the "h=" tag exists in the public key record and the hash algorithm implied by the a= tag in the DKIM-Signature header field is not included in the contents of the "h=" tag, the verifier MUST ignore the key record and return PERMFAIL (inappropriate hash algorithm). 8. If the public key data (the "p=" tag) is empty, then this key has been revoked and the verifier MUST treat this as a failed signature check and return PERMFAIL (key revoked). There is no defined semantic difference between a key that has been revoked and a key record that has been removed. 9. If the public key data is not suitable for use with the algorithm and key types defined by the "a=" and "k=" tags in the DKIM- Signature header field, the verifier MUST immediately return PERMFAIL (inappropriate key algorithm).
5. Otherwise, the signature has correctly verified. INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to initiate the public-key query in parallel with calculating the hash as the public key is not needed until the final decryption is calculated. Implementations may also verify the signature on the message header before validating that the message hash listed in the "bh=" tag in the DKIM-Signature header field matches that of the actual message body; however, if the body hash does not match, the entire signature must be considered to have failed. A body length specified in the "l=" tag of the signature limits the number of bytes of the body passed to the verification algorithm. All data beyond that limit is not validated by DKIM. Hence, verifiers might treat a message that contains bytes beyond the indicated body length with suspicion, such as by truncating the message at the indicated body length, declaring the signature invalid (e.g., by returning PERMFAIL (unsigned content)), or conveying the partial verification to the policy module. INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body at the indicated body length might pass on a malformed MIME message if the signer used the "N-4" trick (omitting the final "--CRLF") described in the informative note in Section 3.4.5. Such verifiers may wish to check for this case and include a trailing "--CRLF" to avoid breaking the MIME structure. A simple way to achieve this might be to append "--CRLF" to any "multipart" message with a body length; if the MIME structure is already correctly formed, this will appear in the postlude and will not be displayed to the end user.
header fields added by attackers. To circumvent this attack, verifiers may wish to delete existing results header fields after verification and before adding a new header field.
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 rendered the same as all unverified email regardless of whether or not it looks like it was signed. RFC2434].
The initial entries in the body registry comprise: +---------+-----------------+ | TYPE | REFERENCE | +---------+-----------------+ | simple | (this document) | | relaxed | (this document) | +---------+-----------------+ DKIM-Signature Body Canonicalization Algorithm Registry Initial Values
The initial entry in the registry comprises: +------+-----------+ | TYPE | REFERENCE | +------+-----------+ | rsa | [RFC3447] | +------+-----------+ DKIM Key Type Initial Values FIPS.180-2.2002] | | sha256 | [FIPS.180-2.2002] | +--------+-------------------+ DKIM Hash Algorithms Initial Values
RFC3864]) for the "mail" protocol, using this document as the reference.