Network Working Group B. Gondwana Internet-Draft Fastmail Pty Ltd Obsoletes: 4686 (if approved) R. Clayton Intended status: Standards Track Yahoo Expires: 24 April 2025 W. Chuang Google 21 October 2024 DKIM2 Why DKIM needs replacing, and what a replacement would look like draft-gondwana-dkim2-motivation-00 Abstract This memo provides a rationale and outline design for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. 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 24 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Gondwana, et al. Expires 24 April 2025 [Page 1] Internet-Draft DKIM2 Motivation October 2024 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. Table of Contents 1. Background and motivations . . . . . . . . . . . . . . . . . 3 2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Basic ideas . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. How the aims of DKIM2 are achieved . . . . . . . . . . . . . 5 4.1. Simplification & codification . . . . . . . . . . . . . . 5 4.2. Preventing backscatter . . . . . . . . . . . . . . . . . 5 4.3. Improved Privacy for forwarders . . . . . . . . . . . . . 6 4.4. Simplifying error handling for intermediaries . . . . . . 6 4.5. The "mailing list DMARC issue" . . . . . . . . . . . . . 7 4.6. Security gateways . . . . . . . . . . . . . . . . . . . . 7 4.7. Addressing DKIM-replay . . . . . . . . . . . . . . . . . 8 4.8. Algorithmic dexterity . . . . . . . . . . . . . . . . . . 9 4.9. Reducing crypto-calculations . . . . . . . . . . . . . . 9 5. DKIM2 header fields . . . . . . . . . . . . . . . . . . . . . 9 5.1. Maximum value for i= . . . . . . . . . . . . . . . . . . 11 5.2. Maximum age for t= . . . . . . . . . . . . . . . . . . . 11 5.3. Registry of values for m= . . . . . . . . . . . . . . . . 12 5.4. Registry of values for z= . . . . . . . . . . . . . . . . 12 5.5. Value for the fb= header . . . . . . . . . . . . . . . . 12 6. Checking hashes . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Dealing with modifications. . . . . . . . . . . . . . . . 13 6.4. Dealing with replays . . . . . . . . . . . . . . . . . . 14 7. Feedback loops . . . . . . . . . . . . . . . . . . . . . . . 14 8. DKIM1/DKIM2 Interworking . . . . . . . . . . . . . . . . . . 15 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Gondwana, et al. Expires 24 April 2025 [Page 2] Internet-Draft DKIM2 Motivation October 2024 1. Background and motivations In 2007, [RFC4871] (Domain Key Identified Mail / DKIM) was published, outlining a mechanism for a domain to sign email in a way that recipients could ensure that the email had come from an entity possessing the secret key matching a public key published in the DNS by the source domain. For clarity in this document we call this established scheme "DKIM1". This document has been obsoleted and updated many times since then, and a large amount of operational experience has been gained using it. However, it has some known weaknesses with some kinds of email flow. If an intermediary alters the email then the original DKIM1 signature will no longer be verifiable. In 2019, [RFC8617] (Authenticated Received Chain / ARC) attempted to solve this issue. However, it does not provide a mechanism for determining whether recipients will recognise the ARC signatures or trust the veracity of the systems that add them. A further issue is that bad actors may "replay" bad email that systems have DKIM signed and erode the reputation of the signer. Ad hoc systems have been developed so that systems that have placed a DKIM signature onto an email may be informed about the quality of the messages that they are relaying -- so called feedback loops. However, there are no formal specifications for such schemes and feedback may be sent where it is not actually required. Furthermore, where the origin of a message has been forged and the final intermediary in a chain finds that it is undeliverable, then the Delivery Status Notification (DSN) may be sent to an unsuspecting third-party -- a phenomenon called backscatter. This document solves these and related problems in a holistic way, by having every hop in a forwarding chain responsible for: 1. verifying the path that messages have taken to get to it, including by being able to reverse modifications or by asserting that it trusts the previous hop unconditionally, and that it is the declared next hop in the chain. 2. declaring (under protection of its own signature) where the message is being sent to next. Gondwana, et al. Expires 24 April 2025 [Page 3] Internet-Draft DKIM2 Motivation October 2024 3. asserting that it will pass control messages (including bounces, abuse reports and delivery notifications) back to the previous hop for a reasonable time. 2. Design Goals 1. It is intended that legacy mail systems constructed in the last century will be able to interoperate with this new specification. However, more recently developed systems will, after a period of parallel running, need to be upgraded in order to continue to be able to authenticate email. 2. We favor simplicity over obscure functionality. 3. We aim to keep the number of cryptographic operations required the same or less, for all the most common types of email flow. 4. We aim to make all parts of the specification mandatory to implement because experience shows that interworking is adversely affected by providing optional functionality. 3. Basic ideas An email is DKIM2 signed by the originator -- in pretty much the same way as is done in the existing DKIM1 standard. In practice the vast majority of mail is signed using relaxed/relaxed methods. DKIM2 will only allow relaxed/relaxed. Each "hop" that handles the email adds another, sequentially numbered, DKIM2 header field. A simple relay will only add a single header. Email service providers will often add two, one on behalf of the actual originator the other for themselves. A relay that rewrites email from one domain to another will add two headers to record the rewriting. If an email is accepted by a server but it is later found that it cannot be delivered onward, or further analysis of its contents leads to a determination that it should not be delivered after all, then the previous hop is informed by means of a Delivery Status Notification (DSN). If a DSN is received for an email that was previously relayed, then the DSN is passed back to the system that delivered the email. Hence, DSNs are returned back along the "outgoing path" until they reach a system that can take responsibility for handling the report. Gondwana, et al. Expires 24 April 2025 [Page 4] Internet-Draft DKIM2 Motivation October 2024 The DKIM2 headers contain the source and destination of the email. They may also request "feedback" from later entities as to the quality of the email. This feedback is sent directly from systems that choose to honor such requests to any all of the requestors that the sender deems appropriate. Intermediaries that alter emails record their actions (so that later hops can undo and check signatures). Intermediaries whose alterations are too complex to be described or reversed will either have to arrange to be treated as the originator of the message (if they are near the start of the message's journey) or they will need to implicitly trusted by any further intermediaries (if they are near the end of the message's) journey. Intermediaries that duplicate ("explode") emails, record their action so that any further systems that see multiple copies of the email will not reject or discard the email as a "replay". 4. How the aims of DKIM2 are achieved 4.1. Simplification & codification *Issue*: Every DKIM1 signature specifies an explicit list of which email header fields have been signed. This leads to inconsistent signing of headers, and allows a signature to be created in which security- critical headers are not covered. To prevent bad actors from adding headers which were not originally present it is common to oversign by signing null versions of headers that are not present. This oversigning may be extended to signing two, for example, Subject header fields because some recipients may not enforce the [RFC5322] requirement of uniqueness. *Mitigation:* DKIM2 will specify a fixed set of headers in accordance with now well-established best practice (and insist they are unique) so there will be no need to list what is signed. However, some exotic headers may need to be signed for unusual or future use-cases. DKIM2 will allow this with an h= field. 4.2. Preventing backscatter *Issue:* Gondwana, et al. Expires 24 April 2025 [Page 5] Internet-Draft DKIM2 Motivation October 2024 With DKIM1, you can send delayed bounces if the message has come directly to you and the DKIM signature is DMARC aligned, but otherwise you need to reject at SMTP transaction time to ensure you won't be creating backscatter. *Mitigation:* Provided that an email is correctly signed when received, it can be rejected at a later point in time. The DSN will be sent to the immediately preceding intermediary. Since the bounce travels back along the (fully authenticated) incoming path it cannot be sent to an uninvolved third party. 4.3. Improved Privacy for forwarders *Issue:* If you want to create a privacy preserving forwarding service, you need to SRS rewrite the email's bounce address so that bounces don't accidentally leak the real address of the recipient. *Mitigation:* Since the DSN messages always go back up the DKIM2 chain, any hop can strip off the higher number (i=) records; including the sender and recipient addresses for them, and create a bounce as if the forwarder itself was doing the rejection. As asynchronous bounces will be common in DKIM2, this is indistinguishable to the sender. 4.4. Simplifying error handling for intermediaries *Issue:* ESPs and other entities that send email on behalf of others have a need to know when delivery errors occur. At present this can only be done by changing the RFC5321 return path so that DSNs will be delivered to an intermediary rather than original sender. Non- standardised mechanisms such as VERP or SRS may be employed to be able to pin down the details of the failure. *Mitigation:* In DKIM2 DSNs are passed back along the outgoing path so the ESP will receive the DSN and, depending on contractual arrangements, may be able to avoid passing this message any further back along the chain. *Issue:* Gondwana, et al. Expires 24 April 2025 [Page 6] Internet-Draft DKIM2 Motivation October 2024 A mailing list wishes to learn when email it has handled cannot be delivered. At present DSNs (as opposed to next hop delivery rejections) are often passed to the originator of the email (the value in the [RFC5321] MAIL FROM) and are invisible to the mailing list. *Mitigation:* Passing bounces back along the outgoing path allows a mailing list to take responsibility for the event and not bother the person who sent a message to the list. 4.5. The "mailing list DMARC issue" *Issue:* Once an intermediate (for example, a mailing list or alumni forwarder) makes a change to the header or body of a message, the hashes covered by the sender's DKIM signature no longer match, and it's not possible to see whether the message is semantically similar, or has been completely replaced by a bad actor. *Mitigation:* DKIM2 will define an algebra for describing how to reverse any changes to create the prior binary data, by inspecting the diff between the two versions, recipients will be able to see who injected bad content. Mailing lists (or alumni forwarders etc.) that alter the Subject header field (or other [RFC5322] headers) will record the previous header field contents. This is easy to undo for checking purposes. Mailing lists that add text (either to a simple email body or one or more MIME parts within the body) will record details of the text they have added. This text can then be removed when checking earlier signatures. We expect the "algebra" describing changes to be in a stand-alone document that need not be finalised on the same timescale as DKIM2 itself. 4.6. Security gateways *Issue:* There are some types of alteration, for example by security gateways, that may be impractical to describe in a cost-effective manner. Gondwana, et al. Expires 24 April 2025 [Page 7] Internet-Draft DKIM2 Motivation October 2024 *Mitigation:* We would expect that outgoing gateways that may be adding disclaimers or rewriting internal identifiers would be provided with appropriate signing keys so that they could be the "first hop" as far as the rest of the email handling chain is concerned. Incoming security gateways may be making substantial changes. Typically they will remove problematic types of attachment and rewrite URLs to use "interstitials". Since this type of functionality is generally provided on a contracted basis further intermediaries will be fully aware of the presence of the security gateway and can be configured to implicitly trust that it has checked earlier signatures and found them to be correct. Hence there is not need to be able to "undo" these changes. 4.7. Addressing DKIM-replay *Issue:* Because an email can currently be sent as "Bcc" such that there's no evidence in the message data of who the recipient is expected to be, it's possible to take a message that is correctly signed and replay it millions of times to different destination addresses as if they had been BCC'd. This message can be resent at any time. *Migitation:* DKIM2 headers will always have timestamps so that "old" signatures have no value. DKIM2 headers specify both "from" and "to" so that most opportunities to alter a message, re-sign it and replay it at scale will no longer be possible. Since the "to" address is always encoded in the email, any email to multiple recipients must be exploded by the sender, and each copy signed separately with different headers. If the email is replayed (perhaps through a large system with many different customers) then if the email does not say that it has been duplicated then signatures can be assumed to be unique and hence simple caching (or Bloom filters) will identify replays. If the email has been duplicated then recipients can assign a reputation to the entity that did the duplication (along with the expected number of duplicates that will arrive from that entity) and assess duplicate signatures on that basis. Gondwana, et al. Expires 24 April 2025 [Page 8] Internet-Draft DKIM2 Motivation October 2024 If the email is altered before duplication then it is again the case that this will be apparent to the recipient who can develop a reputation system for the entity that did the modification and replay. 4.8. Algorithmic dexterity The specification will require both RSA and elliptic curve be implemented. If there is IETF consensus around a "post-quantum" scheme then that will also be included. Experience with DKIM1 is that everyone supports RSA keys and EC support is very patchy so we will emphasize this aspect in bake-offs etc. Dexterity will become essential if advances in cryptanalysis cause a particular type of algorithm to become deprecated. To allow a phased switch away from such an algorithm we will make provision for more than one signature to be present in a single DKIM2 header. Systems capable of checking both signatures will require both to be correct. If only one signature is correct then email will be rejected with a clear message -- allowing interworking issues to be easily debugged. 4.9. Reducing crypto-calculations Experience at large mailbox providers is that incoming messages can have large numbers of DKIM signatures all of which need to be checked. For DKIM2, in the common case where email has not been altered by earlier hops, it will only be necessary to check the first DKIM2 signature, the one applied by the previous hop and, if "feedback" is to be provided, the signatures of any entities that have requested feedback. If DKIM-replay is felt to be an issue (and some providers will detect this by identifying non-unique signatures) then more DKIM2 headers may need to be processed to establish the veracity of an alleged forwarding path. Additionally any attempt to do forensics or to assign reputation to intermediates will require more signatures to be checked. 5. DKIM2 header fields DKIM2 headers will have the following fields Gondwana, et al. Expires 24 April 2025 [Page 9] Internet-Draft DKIM2 Motivation October 2024 +============+=================================================+ | Field | Explanation | | identifier | | +============+=================================================+ | i= | Sequence Number (from 1 to N) | +------------+-------------------------------------------------+ | t= | Timestamp | +------------+-------------------------------------------------+ | ds= | Signing key identifier (domain & selector) | +------------+-------------------------------------------------+ | a= | Crypto algorithm(s) used (unless combined with | | | b= to allow for multiple signatures on the same | | | email, see discussion of crypto-agility above) | +------------+-------------------------------------------------+ | b= | Signature over hash value strings (DKIM uses | | | b=) | +------------+-------------------------------------------------+ | bh= | Body hash value (see discussion) | +------------+-------------------------------------------------+ | h= | Extra headers signed by this hop | +------------+-------------------------------------------------+ | m= | Indicates if mail has been modified or exploded | +------------+-------------------------------------------------+ | z= | Next hop does not support DKIM2 (see below) | +------------+-------------------------------------------------+ | mf= | RFC5321.mail-from | +------------+-------------------------------------------------+ | rt= | RFC5321.rcpt-to | +------------+-------------------------------------------------+ | fb= | feedback requested for this email | +------------+-------------------------------------------------+ | n= | a nonce value (could use for database lookup | | | for DSN handling) | +------------+-------------------------------------------------+ Table 1 At the first hop there cannot be any modification, so instead the z= field is used to indicate a request by the sender that the email never be modified and/or never be “exploded” to multiple recipients. This might be appropriate for some types of transactional email. Since it is only a request, intermediaries may, by local policy, not honor it, but they SHOULD NOT relay mail where the request has not been honored to third parties. Gondwana, et al. Expires 24 April 2025 [Page 10] Internet-Draft DKIM2 Motivation October 2024 We will always hash headers in a "relaxed" mode (to use the DKIM1 jargon). For the body we will always use "relaxed" because that is the usual scheme for DKIM1. Relaxed is more expensive than "simple" but there have been concerns about expressed about interworking. The vast majority of DKIM1 email (99%+) uses relaxed/relaxed. The hashes of the header and the body can be placed into the DKIM2 header field, and then a signature is applied. Alternatively we could define a signature over the hashes but not record their values. The second is neater but the former does allow an unchanged body hash to just be copied and may assist in diagnosing faults. Note also, that there is no technical reason for computing two hashes rather than one, but the presence of an obviously unchanged body hash may again be useful for fault diagnosis and may assist humans in reasoning about how and where changes were made to the body. The nonce value is available for any purpose, but may well be used as an index into a database to access meta-data about an email that has been handled in the past. DKIM2 signatures expire after a fixed period (a week would be appropriate) so that it is not necessary to hold information for indefinite periods or to handle DSNs for email that was delivered long ago. Note that we have not included a version number. Experience from MIME onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, we recommend using header fields labeled DKIM3 instead. For simplicity using single characters before the = would be good, but we quickly run out of obvious relevant letters. Where there is a match to DKIM1 fields these have been copied (though this is merely to assist humans, it's unlikely to affect any code). 5.1. Maximum value for i= There will be an absolutely maximum value of 255 for i=; though realistically we should be able to bring this value back down to about 50. 5.2. Maximum age for t= For a message in transit, the timestamp MUST be less than one week ago. For bounces, they MUST be returned to their source within 2 weeks of the timestamp on hop i=1. This requires that as the destination, you MUST create the bounce within 1 week of receipt. Gondwana, et al. Expires 24 April 2025 [Page 11] Internet-Draft DKIM2 Motivation October 2024 5.3. Registry of values for m= +==========+==============================================+ | Value | Purpose | +==========+==============================================+ | nomodify | Any hop that adds this requires no | | | modifications; anybody later hop must either | | | reject it or agree to pass it on unmodified | +----------+----------------------------------------------+ | header | This hop has modified the headers; a | | | separate header lists the algebra to revert | | | the changes | +----------+----------------------------------------------+ | body | This hop has modified the body; a separate | | | header lists the algebra to revert the | | | changes | +----------+----------------------------------------------+ | complex | This hop has done something complex and | | | there is no way to revert it | +----------+----------------------------------------------+ Table 2 If there is no "m" value then this hop asserts it has not modified either the body nor any header covered by a previous DKIM2 signature. 5.4. Registry of values for z= Not present - the message staying in the DKIM2 world; the next hop has stated it supports DKIM2 and will be able to sign the next hop with a key which is domain aligned to the to= address on this message. z=y - the next hop does not support DKIM2 or does not have a key for the destination domain. 5.5. Value for the fb= header Not present, do not send feedback for this email to the signing domain fb=y - this signing domain would like to receive feedback about the disposition of this email (e.g. percentage reported as spam). Gondwana, et al. Expires 24 April 2025 [Page 12] Internet-Draft DKIM2 Motivation October 2024 6. Checking hashes For clarity this is written as if there is only one hash and signature to check, whereas there may in fact be one for the header and one for the body. Issues with DNS will cause [RFC5321] 4xx responses to be sent. 6.1. Step 1 Find the latest DKIM2 signature and determine if the email as received matches that hash AND that you are named as the destination of the email AND that the mail is coming from the named source. If not then refuse to accept the email. The previous hop is responsible for the email (they have either forged it or mangled it -- either way it is their problem). If this check passes then other checks can either be done at delivery time or the mail can be accepted and if later rejected there is a valid path back to the sender over which a DSN can be sent. If it is decided, by local policy, to accept an email where the hash fails (or you are not the documented recipient) then DSN messages back along the chain MUST NOT be sent. 6.2. Step 2 Find the first DKIM2 header (numbered 1) and determine if the email as received has the same hash as recorded there. If so, you know the email has not been altered on its way to you. The path it has followed is most likely irrelevant for deciding what to do with it. 6.3. Dealing with modifications. Find the highest numbered DKIM2 header that reports a modification. Undo the modification and repeat. When all modifications have been done then there should be a match with the original signature (at hop1). If not then the email has been altered (in an undocumented manner) on its way to you and it SHOULD be rejected. Note that it is not necessary to check the signature on a DKIM2 header that reports a modification. Undoing the modification and discovering that the message can now be authenticated is sufficient. Over time a reputation can be developed for a intermediary which is making modifications and given sufficient trust then the "undo" step could be skipped. Note that the signature of the DKIM2 header that reports the modification would need to be checked to ensure reputation accrued to the correct entity. Gondwana, et al. Expires 24 April 2025 [Page 13] Internet-Draft DKIM2 Motivation October 2024 If the modification is substantial (eg URLs rewritten, MIME parts removed) and it cannot be undone then the receiver (who may not be the immediate next hop) MUST trust the system doing the modification. If it does not then the mail SHOULD be rejected. It will be noted that some modifications can totally change the meaning of an email. This specification does not try to limit modifications. We believe that being able to attribute modifications to a particular entity will allow reliable blocking of malicious intermediaries once they are identified. 6.4. Dealing with replays Checking source and destination as recorded by the previous hop makes many “DKIM replay” scenarios impossible. It is possible to exclude all replays by determining if any DKIM2 header reports an expansion event (one incoming email resulting in multiple further emails). If not then you would expect that the (original) hash of the email is unique and duplicates can be rejected. If a expansion event is recorded then receiving multiple copies would not be a surprise. It will be necessary to use local policy to assess whether the number of copies received is acceptable or not. Over time you may wish to develop a reputation for a DKIM2 identity which is doing expansions and conclude that a specific number of copies is to be expected. This can be used to refine local policy. 7. Feedback loops Some mailbox providers are prepared to report their, or their customers', opinions about incoming email -- for example: that a customer marked a particular email as "spam". These systems are generally called "feedback loops". There are usually bureaucratic systems to ensure reports are only sent to entities that wish to receive them and the mailbox provider may decide that some entities should not be sent any feedback. The senders of email, the originator and/or a commercial company (an ESP) hired to send the email generally favor feedback loops because it allows them to make their emails more acceptable, and the commercial companies can rapidly become aware of customers whose email is widely disliked. Gondwana, et al. Expires 24 April 2025 [Page 14] Internet-Draft DKIM2 Motivation October 2024 In DKIM2 any intermediary can request feedback, but it is still the decision of the mailbox provider as to whether any feedback will be sent. They may still require pre-registration on a per domain basis to receive feedback if only to ensure that any nominated email address is appropriate and is not an unsuspecting third party. Note that feedback can be sent to any requesting entity. There is nothing special about a requester being at hop1 or hop2 on a chain. In particular some forwarding systems late in the chain may wish to become aware if they are forwarding emails that are then reported to be spam. 8. DKIM1/DKIM2 Interworking Note that DKIM2 signed email can also be DKIM1 signed. DKIM2 capable servers will announce the capability in their initial banner in the usual manner for SMTP extensions. A DKIM2 capable client connecting to a DKIM2 capable server will append a "rcpt parameter" to the RCPT TO command to query whether or not the particular destination domain if DKIM2 capable -- viz: that it will be able to sign DKIM2 headers if email is relayed or sign a DSN if an email is rejected. A specific 5xx response will indicate that the domain is not DKIM2 capable. e.g. RCPT TO: DKIM2 If a DKIM2 capable server finds that it will have to pass an email to a non-DKIM2 server or that the relevant domain is not DKIM2 capable then a special DKIM2 header will be added to the email, as an extra hop, (using the z= parameter) to indicate that the message is leaving the DKIM2 world. The message can then be sent using a RCPT TO command without the DKIM2 rcpt parameter (perhaps immediately in the same SMTP connection). It may be inconvenient for a server to generate and sign a DKIM2 header whilst the SMTP conversation is occurring. If so, then it will be necessary to maintain a database of whether a particular destination is expected to support DKIM2 or not and pre-sign accordingly. In the event that expectations are not met then the SMTP conversation would be abandoned and the email re-queued after appropriate modification. If a DKIM2 capable server receives an email which has a z= field in the latest DKIM2 header then if the original signature is correct (perhaps after undoing documented modifications) then all is well and delivery can continue as normal. Otherwise the server can either, by Gondwana, et al. Expires 24 April 2025 [Page 15] Internet-Draft DKIM2 Motivation October 2024 local policy, accept a known-to-be-mutilated email OR it can generate a DSN and send it to the last DKIM2 server. It SHOULD NOT reject delivery because a non-DKIM2 aware system will generate a delivery failure message to the SMTP return path address which is not appropriate. Note that is inherent in the DKIM2 design that emails are only ever sent to one recipient at a time. At present some mail servers will batch deliveries together if they are going to the same destination and issue multiple RCPT TO commands in the SMTP protocol conversation. This is not possible with DKIM2 because each email must document a single RFC5321 destination in the rt= parameter. This may seem inefficient but only about 1% of email is currently delivered using multiple RCPT TO commands. 9. Security TBA 10. IANA Considerations TBA 11. Normative References [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, DOI 10.17487/RFC4871, May 2007, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, . Appendix A. Changes from Earlier Versions [[This section to be removed by RFC Editor]] Gondwana, et al. Expires 24 April 2025 [Page 16] Internet-Draft DKIM2 Motivation October 2024 Authors' Addresses Bron Gondwana Fastmail Pty Ltd Level 2, 114 William Street 3000 Australia Phone: +61 457 416 436 Email: brong@fastmailteam.com Richard Clayton Yahoo Email: rclayton@yahooinc.com Wei Chuang Google Email: weihaw@google.com Gondwana, et al. Expires 24 April 2025 [Page 17]