DKIM2 Procedures for bounce processing

Bounce processing

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.

Return path

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 , 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.

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.

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: 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.

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.

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 RCPT TO: dest@foo.com DKIM2-Signature i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com To: dest@foo.com I hope this email reaches its destination ``` Forwarding of the message from foo.com to bar.com: ``` MAIL FROM: something@foo.com RCPT TO: 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 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 DKIM2-Signature: i=1 domain=bar.com rcpt=something@foo.com From: postmaster@bar.com To: 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 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 DKIM2-Signature: i=1 domain=foo.com rcpt=original@example.com From: postmaster@foo.com To: original@example.com Subject: DSN for ... DKIM2-Sig: i=1 domain=example.com rcpt=dest@foo.com From: Sender 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 --divider43541325151 Content-Type: message/rfc822 DKIM2-Signature i=1 domain=example.com rcpt=dest@foo.com From: Sender original@example.com To: dest@foo.com I hope this email reaches its destination --divider89869878-- ```

Security considerations To be covered in primary DKIM2 document.

IANA considerations To be covered in primary DKIM2 document.