DKIM2 Procedures for bounce processing

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

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