]> Inveigle.net

Auckland New Zealand cs@inveigle.net

Applications dkim Internet-Draft This document proposes using the DKIM2 ESMTP extension to pass a signature for each intended recipient through the SMTP session rather than splitting email at the time of signing. This approach meets the DKIM2 objective of preventing email replay, while also preserving existing SMTP delivery logic, maintaining compatibility with DKIM and avoiding multiple calls to the DKIM2 filter. Also proposed is a method of signing the next domain in the DKIM2 chain of custody independently from the DKIM2-Signature. As per RFC5321, "... each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs". The requirements outlined herein ensure the majority of DKIM2 logic can be implemented within filters or supporting code, with only minimal and isolated changes in SMTP code.

Introduction DomainKeys Identified Mail v2 (DKIM2) requires a signature for each recipient as a means to prevent message replay. Because recipients may not appear in the headers and the need to avoid revealing their existence if they are not disclosed, the DKIM approach of creating a single signature for each email is insufficient. This deficiency can be addressed by splitting messages prior to signing, however, that approach would lead to sub-optimal implementations. By generating a separate signature for each recipient to be passed through the SMTP session, it is possible to verify the intent to send to the final recipient while preserving existing SMTP delivery logic, without having to create multiple instances of the email prior to signing or needing to invoke the DKIM2 filter more than once. Deliveries between DKIM2-capable SMTP implementations can continue using existing delivery logic to optimize delivery based on the route. All DKIM2-specific logic can be isolated within the DKIM2 filters and the delivery phase of SMTP. Passing signatures through the SMTP session preserves the ability of systems to sign and forward, as is possible with DKIM. This is necessary for systems that for security or policy reasons must sign messages independently from other domain email, or systems that always forward email via another host or third party for delivery, including MUAs and systems sending signed transactional or notification emails. DKIM2 also proposes a method for signing the next domain handling the email. By decoupling this record from the DKIM2-Signature and signing it independently, this information can be added to the headers once routing details are known by way of a lightweight DKIM2 stub that only performs basic header hashing, signing and addition. This approach avoids additional DNS lookups attempting to relate domains to specific hosts, eliminates the need for DNS records that may leak information about how a domain routes email and only requires relays to sign using a single key (in typical configurations), regardless of how many domains (or selectors) a system provides service for.

The DKIM2 service extension The extension mechanism for SMTP is defined in Section 2.2 of the current SMTP specification . The name of the extension is DKIM2. Servers implementing this extension advertise DKIM2 as a keyword in the response to EHLO.

SMTP Command Line Length This extension increases the minimum SMTP server command line length of 1000 octets, in accordance with , section 4.5.3.1.4. This is sufficient to accommodate 4096 bit RSA keys while leaving reasonable space for existing extensions. RSA keys larger than 2048 bits, the maximum DKIM verifiers are required to support, are rare.

The DKIM2RCPT RCPT parameter A DKIM2RCPT parameter is calculated for each recipient and passed between DKIM2-capable systems via the RCPT command. This value is calculated the first time an email signed and is typically retained until delivery, provided the message remains within the DKIM2 ecosystem. During email delivery or on handover to a system which isn't DKIM2-capable, this value is transferred to the email headers. The requirements for transferring this value to headers are described in . Tags defined for the DKIM2RCPT parameter are below: i= Sequence number (from 1 to N) corresponding to the current (highest) i= value, matching that of the DKIM2-Signature(s) added to the email by the current domain (REQUIRED). ABNF: s= The name of the selector used to sign the DKIM2RCPT (REQUIRED). ABNF: bcc Indicates that the recipient is included via BCC. This tag MUST be present if the recipient is not listed in the To or Cc header fields. A DKIM2-capable implementation MAY use this tag to split recipients when handing over to a system that does not support DKIM2, in lieu of performing its own header parsing. b= Signature over hash value of strings. ABNF:

Creating and verifying the DKIM2RCPT signature A signer will nominate a DKIM2-Signature added by the domain and use the corresponding key to sign the DKIM2RCPT parameter. The i= and s= tags in DKIM2RCPT shall match those of the nominated DKIM2-Signature. A signer SHOULD NOT select an RSA-signed signature if an alternative is available. A signer MAY use different keys when sending to multiple recipients. A signer MUST NOT set the DKIM2RCPT parameter when signing with an i= value greater than 1 unless it has declared itself to have exploded the message in the corresponding DKIM2-Signature or it has explicit signing authority granted by the DKIM2-NextDomain header. The following steps will be applied, in order, to generate or verify the DKIM2RCPT signature:

1. Determine the hashing algorithm to use, based on that used by the nominated DKIM2-Signature.
2. Hash the chosen DKIM2-Signature header after applying "relaxed" canonicalization.
3. Add the email address of the intended recipient, enclosed in angled brackets (RCPT syntax).
4. Create the DKIM2RCPT record (including the DKIM2RCPT= prefix), with all required tags, leaving the value of the b= tag empty, and add the resulting record to the hash.

A signer would perform the following additional steps:

1. Sign the hash using the same key as the nominated DKIM2-Signature.
2. Base64 encode the signature and insert the resulting string into the b= tag of the DKIM2RCPT record.

A verifier would:

1. Decode the base64 signature from the b= tag of the DKIM2RCPT record.
2. Use the resulting signature to verify the hash.

Transfer to headers In order to preserve the ability to perform end-to-end verification of an email, the DKIM2RCPT parameter along with the email address it signs, must be transferred to email headers under certain conditions. A DKIM2 implementation MUST transfer DKIM2RCPT to a DKIM2-Recipient header on:

1. Handover for delivery
2. Handover to systems which do not support DKIM2
3. Generating a bounce message

A DKIM2 implementation SHOULD transfer DKIM2RCPT to a DKIM2-Recipient when on-sending with a new RCPT TO value, such as when:

1. Forwarding
2. Sending to mailing list recipients

An implementation MAY include multiple DKIM2-Recipient headers where the DKIM2RCPT bcc tag is not specified, but MUST create a separate instance of a message for each recipient where the bcc tag is specified. Example of the resulting header: DKIM2RCPT=i=1;s=selector;bcc;b=xXBUvPKVXejLi8mdvCeccD0gFlzWzBe2JM/enQ13xJKAK+VbPHSvuvKa0WEwXgdDR1nSqw2/D1NIwatzf2rRAg== ]]> The DKIM2RCPT parameter MUST NOT be sent to any upstream host that does not advertise DKIM2 support.

The DKIM2-NextDomain header A signer will insert a DKIM2-NextDomain header to sign its intent to send email to the next domain. The next domain will be obtained by removing the hostname from the A/AAAA record referencing the host, or a statically configured value if the host is configured to relay via another server. Tags defined for the DKIM2-NextDomain header are below: i= Sequence number (from 1 to N) corresponding to the current (highest) i= value, matching that of the DKIM2-Signature(s) added to the email by the current domain (REQUIRED). ABNF: s= The name of the selector used to sign the DKIM2-NextDomain header (REQUIRED). ABNF: sa= This tag explicitly grants signing authority for the specified domain to sign on behalf of the sender. This value may only be added to a DKIM2-NextDomain signature with an i= value of 1 and may have a value of either 1 or 0 (true or false). If the sa flag is set, a signer MUST generate new DKIM2RCPT signatures for each recipient and verifier MUST accept the DKIM2-Signature as authoritative if the DKIM2-NextDomain signature can be verified. b= Signature over hash value of strings. ABNF:

Creating and verifying the DKIM2-NextDomain signature A signer will use a key to sign its intent to send email to the next domain. This key will be identified by the s= value from the DKIM2-NextDomain header and the d= value from any DKIM2-Signature with a corresponding i= value. The specified selector DOES NOT have to appear in a DKIM2-Signature header. A signer SHOULD NOT use an RSA key if an alternative is available. The following steps will be applied, in order, to generate or verify DKIM2-NextDomain signature:

1. Hash all instances of DKIM2-Signature with the corresponding i= after applying "relaxed" canonicalization. Headers are hashed from the bottom up.
2. Create the DKIM2-NextDomain header with all required tags, leaving the value of the b= tag empty, before adding the header to the hash.

A signer would perform the following additional steps:

1. Sign the hash using the nominated key.
2. Base64 encode the signed hash and insert the resulting string into the b= tag of the DKIM2-NextDomain header.

A verifier would:

1. Decode the base64 signature from the b= tag of the DKIM2-NextDomain header.
2. Use the resulting signature to verify the hash.

Tag Lists The DKIM2-NextDomain header uses the same syntax as the DKIM2-Signature as defined in . The DKIM2RCPT parameter uses a modified form of the DKIM tag-list that is suitable for inclusion as a RCPT command parameter. All values are strings containing either plain text or "base64" text as defined in . White space MUST NOT be present in a DKIM2RCPT parameter. Tags MUST be interpreted in a case-sensitive manner. Values MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity. Tags with duplicate names MUST NOT occur within a single dkim2rcpt-tag-list; if a tag name does occur more than once, the entire dkim2rcpt-tag-list is invalid. Unrecognized tags MUST be ignored. Tags that have an empty value are not the same as omitted tags. An omitted tag is treated as having the default value; A tag with an empty value explicitly designates the empty string. Tags for which no dkim2rcpt-tag-value is specified are boolean; true if included, false if omitted.

Examples Keys used for examples Private key (PEM) Public key (DNS) Delivery to a system with DKIM2 capabilities. S: 250 2.0.0 OK C: rcpt to: DKIM2RCPT=i=1;s=ed25519;b=I1/77hTpktZA5URnD/5WAMDnrNgtE4uzqNaq/BvFJKeEiONDD9BDTda4OeRIP1Jsi6+0RkyDVx69WGp1JrW5Bw== S: 250 OK C: data S: 354 Go C: DKIM2-NextDomain: i=1; s=ed25519; nd=nextdomain.example; C: b=+fBe1mhGbmishVq1nqPENvRivXX3bH5cwDOlZaK6c4npu/N5NJn/KLvoNuGysofLuXeQ/Rulk5bY C: U4hANn6ZBA== C: DKIM2-Signature: i=1; a=ed25519-sha256; t=1763059498; C: s=ed25519; d=example.com; C: h=Date:Subject:From:To:Message-ID; C: bh=fdkeB/A0FkbVP2k4J4pNPoeWH6vqBm9+b0C3OY87Cw8=; C: b=kiuvOIgXlvP0lIgcRj0CXPrz5o1cpgj6Dh8ASIUz/xQMfXZCRsCyQq/Af0M7uKnLeqFlc/7M0xqP C: iFuSgjMXDA== C: Date: Thu, 13 Nov 2025 18:44:58 GMT C: Subject: Test C: From: sender@example.com C: To: user@example.com C: Message-ID: C: Content-Type: text/plain; charset=us-ascii C: Content-Transfer-Encoding: 7bit C: C: Test C: . S: 250 Accepted ]]> Delivery to a system without DKIM2 capabilities. S: 250 2.0.0 OK C: rcpt to: S: 250 OK C: data S: 354 Go C: DKIM2-Recipient: DKIM2RCPT=i=1;s=ed25519;b=I1/77hTpktZA5URnD/5WAMDnrNgtE4uzqNaq/BvFJKeEiONDD9BDTda4OeRIP1Jsi6+0RkyDVx69WGp1JrW5Bw== C: DKIM2-NextDomain: i=1; s=ed25519; nd=nextdomain.example; C: b=+fBe1mhGbmishVq1nqPENvRivXX3bH5cwDOlZaK6c4npu/N5NJn/KLvoNuGysofLuXeQ/Rulk5bY C: U4hANn6ZBA== C: DKIM2-Signature: i=1; a=ed25519-sha256; t=1763059498; C: s=ed25519; d=example.com; C: h=Date:Subject:From:To:Message-ID; C: bh=fdkeB/A0FkbVP2k4J4pNPoeWH6vqBm9+b0C3OY87Cw8=; C: b=kiuvOIgXlvP0lIgcRj0CXPrz5o1cpgj6Dh8ASIUz/xQMfXZCRsCyQq/Af0M7uKnLeqFlc/7M0xqP C: iFuSgjMXDA== C: Date: Thu, 13 Nov 2025 18:44:58 GMT C: Subject: Test C: From: sender@example.com C: To: user@example.com C: Message-ID: C: Content-Type: text/plain; charset=us-ascii C: Content-Transfer-Encoding: 7bit C: C: Test C: . S: 250 Accepted ]]>

References Normative References This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Informative References Fastmail Yahoo Google This memo provides a rationale for building a new email accountability mechanism, based on the lessons learned from implementing the ARC experiment from RFC 8617 and other experiences from email system operators.