DKIM2 Message Examples

Introduction This draft provides a collection of email message scenarios, along with the proposed way that DKIM2 could operate under those scenarios.

Document Conventions Terminology from is used extensively throughout this document.

"Transaction" represents an interaction between two ADMDs.
"Origin" refers to the first ADMD involved in the delivery of the message.
"Destination" refers to the final ADMD involved in the delivery of the message.
"DKIM2-Signature" as the header field name is a placeholder. The standardization process will involve coming to consensus on a name for the field.
DKIM2-Signature field values will not contain the bh= tag.
DKIM2-Signature field values will contain a simplified b= tag, where "PASS" means the signature can be verified against the message as-is, "PASS_AFTER_UNDO_MODS" means pass after applying DKIM2 modification algebra to the message, and "FAIL" means an unrecoverable signature.
DKIM2-Modification is a human-consumable description of the changes, in lieu of having a rough definition of what the machine-consumable modification algebra should look like.
DKIM-Signature header fields are not included. These can safely be present in DKIM2 messages, but do not contribute to the DKIM2-oriented handling of a message.
The destination address header fields 5322.To, 5322.Cc, 5322.Bcc are left out. These are not relevant to DKIM2, since there is no requirement that 5321.To have any relationship to the values contained in those header fields.
Other mandatory headers fields that aren't relevant to DKIM2 processing will also be left out.
"Alignment" needs further definition in the context of DKIM2, but for now it is being used with the same meaning as DMARC alignment, as defined in .
==== delimiters are used to indicate the start and end of the SMTP () transaction, and are not part of the transaction's content.

Scenarios

Direct delivery This is the common case for email. The initial ADMD has a message to be delivered somewhere, and the ADMD that is on the receiving end of that SMTP transaction is that message's final destination. Transaction: Origin to destination RCPT TO: DATA DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=b@destination.example; b=PASS From: A Message! ==== ]]> In the initial transaction of a DKIM2 signed message, the signing domain must be aligned with the domain in 5322.From. Note that the mf= and 5321.MailFrom are equal, but they do not need to be equal to the 5322.From. In every DKIM2 transaction, it is required that the topmost (highest i=) DKIM2-Signature's signing domain be aligned with the domain in that signature's mf= tag, and that the mf= tag be equal to the 5321.MailFrom for that transaction. Alignment of these domains is a mitigation for backscatter, and it is left to the system operator to prevent local backscatter (ex. acct1@example.com misusing 5321.MailFrom of acct2@example.com). In every DKIM2 transaction, it is required that the topmost DKIM2-Signature's rt= be equal to the 5321.RcptTo for that transaction. This equality is a mitigation for message replay, by making delivery to any other mailbox (even at the same host) be not authenticated by DKIM2. Acceptance of messages that don't authenticate with DKIM2 is a matter of local policy.

Autoforwarding (no alteration) This is often called the "alumni forwarder" scenario, but many other forwarding services exist. An ADMD has a message to send, and the destination is an address at another ADMD acting as a forwarding service. The forwarding service resends the message to another ADMD, which is the final destination for the message. In this scenario, it is assumed that the forwarding service does not alter the message at all. Transaction: Origin to forwarder RCPT TO: DATA DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=b@alias.example; b=PASS From: A Message! ==== ]]> Transaction: Forwarder to destination RCPT TO: DATA DKIM2-Signature: i=2; d=alias.example; s=key4321; mf=b@alias.example; rt=c@destination.example; b=PASS DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=b@alias.example; b=PASS From: A Message! ==== ]]> In the forwarding transaction, the i=2 signing domain is aligned to the 5321.MailFrom and the domain in i=1 rt=. There is no requirement that i=2 signing be aligned with 5322.From. DMARC requirements can be satisfied in both transactions, because there is a passing signature aligned with the 5322.From.

Mailing list (no alteration) This operates like an autoforwarder. The only difference is that these systems are expected to re-deliver to multiple destinations instead of just one. Transaction: Origin to mailing list RCPT TO: DATA DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=m@list.example; b=PASS From: A Message! ==== ]]> Transaction: Mailing list to destination RCPT TO: DATA DKIM2-Signature: i=2; d=list.example; s=key50; mf=m@list.example; rt=b@subscriber.example; b=PASS DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=m@list.example; b=PASS From: A Message! ==== ]]>

Mailing list (with alteration) Similar to the non-modifying mailing list case, but with modifications of the message (body, 5322.Subject, etc.) that invalidate the signature in i=1. Transaction: Origin to mailing list RCPT TO: DATA DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=m@list.example; b=PASS From: A Message! ==== ]]> Transaction: Mailing list to destination RCPT TO: DATA DKIM2-Signature: i=2; d=list.example; s=key1; mf=m@list.example; rt=b@subscriber.example; b=PASS DKIM2-Modification: i=2; delta="Appended a line" DKIM2-Signature: i=1; d=origin.example; s=key50; mf=a@origin.example; rt=m@list.example; b=PASS_AFTER_UNDO_MODS From: A Message! Click https://list.example/unsubscribe to unsubscribe from this. ==== ]]> It is unclear whether the second transaction can be considered to satisfy origin.example's DMARC requirements, as origin.example's signature did not pass on the message as presented.

Mailing list (with alteration and From munging) Further modification, where the mailing list also changes the 5322.From header field to something else. This is done in today's ecosystem to allow for delivery of modified messages sent from domains with DMARC policies. Transaction: Origin to mailing list RCPT TO: DATA DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example; rt=m@list.example; b=PASS From: A Message! ==== ]]> Transaction: Mailing list to destination RCPT TO: DATA DKIM2-Signature: i=2; d=list.example; s=key1; mf=m@list.example; rt=b@subscriber.example; b=PASS DKIM2-Modification: i=2; delta="Appended a line; From used to be "a@origin.example"" DKIM2-Signature: i=1; d=origin.example; s=key50; mf=a@origin.example; rt=m@list.example; b=PASS_AFTER_UNDO_MODS From: "a via list" A Message! Click https://list.example/unsubscribe to unsubscribe from this. ==== ]]> DMARC is satisfied by this message. There is a signature from the domain of 5322.From that passes on the message being presented, and the original 5322.From isn't visible unless the receiving system decides that that's an appropriate thing to do. It should be required that any changes 5322.From be included in a signature where the signing domain aligns with the new 5322.From, similar to how i=1 must align with the message's original 5322.From.

Sending on behalf of another domain There are scenarios in which one ADMD is sending messages on behalf of another ADMD. A common example of this is Email Service Providers (ESPs) that send promotional mail on behalf of their customers. Transaction: Origin to destination RCPT TO: DATA DKIM2-Signature: i=2; d=esp.example; s=espkey; mf=something@esp.example; rt=abc@destination.example; b=PASS DKIM2-SIGNATURE: i=1; d=brand.example; s=brandkey; mf=something@brand.example; rt=something@esp.example; b=PASS From: "Brand coupons" Here are some coupons for our Brand products! ==== ]]> Despite being originated from the ESP directly, DKIM2's requirement that the i=1 d= tag have alignment with both the 5321.MailFrom and 5322.From means that scenarios like this will require two signatures at origination. The first satisfies the requirement that the signature be aligned with 5322.From, and the second satisfies the requirement that the topmost signature's mf= tag be equal to the 5321.MailFrom of the transaction. Generation of two signatures is only required when the ESP needs to use a 5321.MailFrom that is not aligned with 5322.From. If this is not required, the mail can be sent using a single signature that aligns with both.

IANA Considerations None.

Security Considerations Security considerations for DKIM2 will be included in the protocol document.