DKIM2 Why DKIM needs replacing, and what a replacement would look like
draft-gondwana-dkim2-motivation-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bron Gondwana , Richard Clayton , Wei Chuang | ||
| Last updated | 2024-11-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gondwana-dkim2-motivation-01
Network Working Group B. Gondwana
Internet-Draft Fastmail Pty Ltd
Obsoletes: 4686 (if approved) R. Clayton
Intended status: Standards Track Yahoo
Expires: 7 May 2025 W. Chuang
Google
3 November 2024
DKIM2 Why DKIM needs replacing, and what a replacement would look like
draft-gondwana-dkim2-motivation-01
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 7 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gondwana, et al. Expires 7 May 2025 [Page 1]
Internet-Draft DKIM2 Motivation November 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. Value of rt= . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Maximum value for i= . . . . . . . . . . . . . . . . . . 11
5.3. Maximum age for t= . . . . . . . . . . . . . . . . . . . 12
5.4. Registry of values for m= . . . . . . . . . . . . . . . . 12
5.5. Value for the fb= header . . . . . . . . . . . . . . . . 12
6. Checking hashes . . . . . . . . . . . . . . . . . . . . . . . 12
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
A.1. draft-gondwana-dkim2-motivation-01: . . . . . . . . . . . 16
A.2. draft-gondwana-dkim2-motivation-00: . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Gondwana, et al. Expires 7 May 2025 [Page 2]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 3]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 4]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 5]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 6]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 7]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 8]
Internet-Draft DKIM2 Motivation November 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 7 May 2025 [Page 9]
Internet-Draft DKIM2 Motivation November 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 |
+------------+-------------------------------------------------+
| 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 m=
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.
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.
Gondwana, et al. Expires 7 May 2025 [Page 10]
Internet-Draft DKIM2 Motivation November 2024
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. Value of rt=
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.
5.2. 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.
Gondwana, et al. Expires 7 May 2025 [Page 11]
Internet-Draft DKIM2 Motivation November 2024
5.3. 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.
5.4. 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.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).
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.
Gondwana, et al. Expires 7 May 2025 [Page 12]
Internet-Draft DKIM2 Motivation November 2024
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.
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.
Gondwana, et al. Expires 7 May 2025 [Page 13]
Internet-Draft DKIM2 Motivation November 2024
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.
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.
Gondwana, et al. Expires 7 May 2025 [Page 14]
Internet-Draft DKIM2 Motivation November 2024
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, and so systems
that are not DKIM2 aware can and will operate as they do at present.
DKIM2 capable servers will announce the capability in their initial
banner in the usual manner for SMTP extensions.
When a DKIM2 signed email is delivered to a server that does not
understand DKIM2 and leaves the DKIM2 ecosystem the DKIM2 specific
events can no longer be expected to occur. In particular any
failures to be deliver will be reported to the address in the
relevant return path and not back along the DKIM2 chain.
A DKIM2 signed email may be delivered to a server that understands
DKIM2 but if that server needs to forward the email elsewhere it may
find that there is no signing key available for the relevant domain
(recalling that the incoming email recorded the destination domain
and it is necessary for the next "hop" to match with that. In such a
case, once more the email will leave the DKIM2 ecosystem.
Refusing to allow an email to leave the DKIM2 ecosystem may be an
appropriate choice in some circumstances. If so then an appropriate
DSN should be created and passed back along the chain in the normal
manner.
It is more likely that local policy will be to pass the email to the
next intermediary even though this means that it leaves the DKIM2
ecosystem. In such a case it would be possible to add a final DKIM2
header to record this event, but doing this adds considerable
complexity, and would provide limited information which was not
otherwise available, hence no such header will be added.
If, after having left the DKIM2 ecosystem, the email reaches a DKIM2
aware system then the email may have been altered in such a way that
the DKIM2 signatures now fail. The receiving system will apply its
local policy to determine whether or not to accept the email.
If the DKIM2 signatures on the mail are valid, except that the last
header does not specify the receiving system as the next hop, then
once again it will a matter for local policy as to whether to accept
the email. It might be thought that it was obvious that the email
Gondwana, et al. Expires 7 May 2025 [Page 15]
Internet-Draft DKIM2 Motivation November 2024
was acceptable, but the non-DKIM2-aware intermediaries that have
handled it may have duplicated the email and there will be no DKIM2
headers to record this.
In any event, systems that accept email which has been outside the
DKIM2 ecosystem MUST NOT add any further DKIM2 headers.
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,
<https://www.rfc-editor.org/rfc/rfc4871>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/rfc/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/rfc/rfc5322>.
[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,
<https://www.rfc-editor.org/rfc/rfc8617>.
Appendix A. Changes from Earlier Versions
[[This section to be removed by RFC Editor]]
A.1. draft-gondwana-dkim2-motivation-01:
* remove the z= parameter on the grounds that it adds too much
complexity
* document that messages MUST NOT re-enter the DKIM2 world once the
chain has been broken.
Gondwana, et al. Expires 7 May 2025 [Page 16]
Internet-Draft DKIM2 Motivation November 2024
A.2. draft-gondwana-dkim2-motivation-00:
* initial version
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 7 May 2025 [Page 17]