DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures
This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community.
Experimental, not a standard. Published to be tried rather than relied on. Implementations may legitimately disagree.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 13 must, 6 should, 3 may.
4.1 Hash Selection
- MUSTThe Author ADMD MUST select a digest ("hash") method currently supported by DKIM (see Section 7.7 of [DKIM]), and this selection needs to be communicated to the ATPS Signer, as it is used in generation of the third-party signatures.
- MUSTWhere the encoding mechanism is not used, the ATPS Signer MUST use a hash name of "none".
4.2 Extension to DKIM
- MUSTWhen the ATPS Signer generates a DKIM signature for another ADMD, it MUST put its own domain in the signature's "d" tag, and include an "atps" tag that has as its value the domain name of the ADMD on whose behalf it is signing.
- MUSTThis tag MUST also be included, as it is required as part of the algorithm that will be enacted by the Verifier.
4.3 ATPS Query Details
- MUSTThe match MUST be done in a case-insensitive manner.
- MUSTIf they do not match, the "atps" tag MUST be ignored.
- MAYWhere multiple DKIM signatures including valid "atps" tags are present, these queries MAY be done in any order or MAY be done in parallel.
- SHOULDWhere the RFC5322.From field contains multiple addresses, this process SHOULD be applied if the "atps" tag's value matches any of the domains found in that field.
- MAYThese MAY be done in any order.
4.4 ATPS Reply Details
- SHOULD NOTFurther queries SHOULD NOT be initiated.
- MUSTIn this case, the Signer has not been authorized to act as a third-party Signer for this ADMD, and thus the Verifier MUST continue to the next query, if any.
- SHOULDThe Verifier SHOULD stop processing and defer the message for later processing, such as requesting a temporary failure code from the Mail Transfer Agent (MTA).
- RECOMMENDEDd: Domain (plain-text; RECOMMENDED).
- REQUIREDv: Version (plain-text; REQUIRED).
- MUSTThe record MUST be ignored if the value is not "ATPS1".
5 Interpretation
- SHOULDFor each DKIM signature that verifies (see Section 6 of [DKIM]), if a Verifier succeeds in confirming that the Author's ADMD authorized the ATPS Signer using this protocol, then the Verifier SHOULD evaluate the message as though it contained a valid signature from the Author's ADMD.
- MAYIt MAY also independently evaluate the ATPS Signer when determining message disposition.
- SHOULDTherefore, a module assessing reputation that is based on DKIM signature verification SHOULD apply the reputation of the Author's ADMD domain instead of, or in addition to, that of the ATPS Signer domain.
6 Relationship to ADSP
- MUSTA Verifier implementing both Author Domain Signing Practices (ADSP) and ATPS MUST test ATPS first.
- MUSTIf ATPS indicates a valid delegation, the Verifier MUST act, with respect to ADSP, as though the message has a valid Author Domain Signature (because that's what the delegation means), and no ADSP test is required.
8.1 ATPS Tag Registry
- MUSTNew registrations or updates MUST be made in accordance with the "Specification Required" guidelines described in [IANA].
- MUSTSuch registry changes MUST contain the following information: