Network Working Group A. Robinson Internet-Draft Google Inc. Intended status: Standards Track 18 March 2025 Expires: 19 September 2025 DKIM2 Procedures for bounce processing draft-robinson-dkim2-bounce-processing-00 Abstract This memo provides a description of the procedures for bounce processing that should be performed by any mail system that implements DKIM2, as part of the overall DKIM2 protcol definition. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Robinson Expires 19 September 2025 [Page 1] Internet-Draft DKIM2 Bounce processing March 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Bounce processing . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Forward path . . . . . . . . . . . . . . . . . . . . . . 2 2.2. Return path . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1. Bounce origination . . . . . . . . . . . . . . . . . 3 2.2.2. Bounce propagation . . . . . . . . . . . . . . . . . 3 2.2.3. Authentication of inbound bounce notifications . . . 3 2.2.4. DKIM2 signing of bounce notifications . . . . . . . . 4 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Security considerations . . . . . . . . . . . . . . . . . 6 2.5. IANA considerations . . . . . . . . . . . . . . . . . . . 6 3. Normative References . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction As part of the DKIM2 protocol, handling for Delivery Status Notifications (DSNs, defined in [RFC3461]) is necessary to ensure that systems receiving these notifications have a mechanism to both authenticate the contents of the DSN, and to determine if the system generating the DSN is authorized to do so for the message being returned. 2. Bounce processing 2.1. Forward path At a high level, the forward path in DKIM2 involves the addition of a new DKIM2-Signature header by each system that handles a message. This header declares that the message was originated by a system that has the right to do so, either because that system is the origin of the message, or because the system received the message from somewhere else and has decided to forward it to another system. In order to support injection-resistant bounce handling, each system must record in the DKIM2-Signature's mf= tag the return path identity of the message, along with all other values as required by the DKIM2 protocol. The return path identity for an incoming message should be the address included in the SMTP transaction's MAIL FROM command. This identity will be related to the last (highest i= value) DKIM2 signature in the message, so this address represents an authenticated destination for future bounce notifications related to the message. Robinson Expires 19 September 2025 [Page 2] Internet-Draft DKIM2 Bounce processing March 2025 2.2. Return path 2.2.1. Bounce origination Once a system decides that a bounce notification needs to be generated in response to a message that it previously accepted for delivery, a new message must be formed to notify the sender that the message was not delivered successfully. Per [RFC3461], the bounce notification message has a top-level MIME part of type multipart/ report. Among other things, that MIME part must contain a MIME part of type message/rfc822 that holds either the original message exactly as it was submitted by the sending system or just the headers for that message, so that the receiver of the bounce notification can authenticate the signatures associated with the original message before processing the bounce notification. 2.2.2. Bounce propagation A system that acts as an intermediary step for the handling of a message in the forward path may decide to propagate bounce notifications through the return path of the message in response to receiving a bounce notification. Same as the initial DSN, the intermediary system's generated bounce notification message must contain a MIME part of type message/report with a sub-part of type message/rfc822 that holds the original message or its headers. The bounce notification must be sent to the return path identity listed in this system's DKIM2-Signature header. An intermediary system must be able to recover at least the originally-submitted headers for a forwarded message, for the purposes of generating bounce notifications. These systems may choose to use the DKIM2 modifications they declared as part of the forward path to reconstruct the original message based on the inbound bounce notification, if it is desirable to return the full message and the inbound bounce notification also includes the full message. Forwarding systems that want to return the full message in all cases should retain the content required to do that as it is not guaranteed to be present in a received DSN. 2.2.3. Authentication of inbound bounce notifications When a system receives a DKIM2-signed bounce notification, and the included original message is also DKIM2-signed, the bounce receiver should verify that the original message was not altered. This means: Robinson Expires 19 September 2025 [Page 3] Internet-Draft DKIM2 Bounce processing March 2025 1) The DSN's DKIM2 signature must have a signing domain that is aligned with the recipient of the message that is being returned. The recipient's address is located in the rt= tag of the last (highest i= tag) DKIM2-Signature in the returned message. 1) The last (highest i= tag) DKIM2-Signature of the returned message must be one that was generated by the system receiving the bounce notification, determined by examining the d= and mf= tags of that signature header. 1) The signature in that DKIM2-Signature header must match the contents of the returned message. Verifiers must handle truncated or missing original message bodies gracefully, by using the body hash value included in the signature header without comparing it to the body contents. The exact details of how to perform DKIM2 signature validation are out of scope for this draft. In the event that the bounce notification contains unauthenticated content, the bounce receiver may decide to deem the bounce message itself as malicious and not propagate it through the return path declared in that message. 2.2.4. DKIM2 signing of bounce notifications Bounce notifications should be DKIM2-signed in exactly the same way as a newly-originated message. This signature must use i=1 since the system generating the notification is the originator of that message, and include an empty mf= tag to align with the SMTP transaction delivering the DSN. 2.3. Example The following is a very simplified description of the SMTP transactions involved in the forward and return paths for a message. Only the SMTP commands and headers related to DKIM2 bounce processing are mentioned. Message origination from example.com to foo.com: ``` MAIL FROM: original@example.com (mailto:original@example.com) RCPT TO: dest@foo.com (mailto:dest@foo.com) DKIM2-Signature i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com (mailto:original@example.com) To: dest@foo.com I hope this email reaches its destination ``` Forwarding of the message from foo.com to bar.com: Robinson Expires 19 September 2025 [Page 4] Internet-Draft DKIM2 Bounce processing March 2025 ``` MAIL FROM: something@foo.com (mailto:something@foo.com) RCPT TO: dest@bar.com (mailto:dest@bar.com) DKIM2-Signature i=2 domain=foo.com rcpt=newdest@bar.com mf=original@example.com DKIM2-Signature i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com (mailto:original@example.com) To: dest@foo.com I hope this email reaches its destination ``` Bounce notification from bar.com to foo.com: ``` MAIL FROM: <> RCPT TO: something@foo.com (mailto:something@foo.com) DKIM2-Signature: i=1 domain=bar.com rcpt=something@foo.com From: postmaster@bar.com (mailto:postmaster@bar.com) To: something@foo.com (mailto:something@foo.com) Subject: DSN for ... Content-Type: multipart/report; boundary="divider43541325151" --divider43541325151 Content-Type: text/plain This message is being returned. --divider43541325151 Content-Type: message/delivery-status --divider43541325151 Content-Type: message/rfc822 DKIM2-Signature i=2 domain=foo.com rcpt=newdest@bar.com mf=original@example.com DKIM2-Signature i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com (mailto:original@example.com) To: dest@foo.com I hope this email reaches its destination --divider43541325151-- ``` Propagated bounce notification from foo.com to example.com: ``` MAIL FROM: <> RCPT TO: original@example.com (mailto:original@example.com) DKIM2-Signature: i=1 domain=foo.com rcpt=original@example.com From: postmaster@foo.com (mailto:postmaster@foo.com) To: original@example.com (mailto:original@example.com) Subject: DSN for ... DKIM2-Sig: i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com (mailto:original@example.com) To: dest@foo.com Content-Type: multipart/report; boundary="divider89869878" --divider89869878 Content-Type: text/plain This message is being returned. --divider89869878 Content-Type: message/delivery-status Robinson Expires 19 September 2025 [Page 5] Internet-Draft DKIM2 Bounce processing March 2025 --divider43541325151 Content-Type: message/rfc822 DKIM2-Signature i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com (mailto:original@example.com) To: dest@foo.com I hope this email reaches its destination --divider89869878-- ``` 2.4. Security considerations To be covered in primary DKIM2 document. 2.5. IANA considerations To be covered in primary DKIM2 document. 3. Normative References [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . Appendix A. Changes from Earlier Versions [[This section to be removed by RFC Editor]] Author's Address Allen Robinson Google Inc. Email: arobins@google.com Robinson Expires 19 September 2025 [Page 6]