As discussed briefly at IETF-124, I have created an I-D describing an
alternate method for signing DKIM2 recipients and the next domain. This
method makes use of the DKIM2 ESMTP extension to pass a recipient
signature through the SMTP session and places the next domain
information in a separate, independently signed header.
Name: draft-latimer-dkim2-rcpt-nd-signing
Revision: 00
Title: DKIM2 Recipient and Next Domain Signing
Date: 2025-11-13
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-latimer-dkim2-rcpt-nd-signing-00.txt
Status:
https://datatracker.ietf.org/doc/draft-latimer-dkim2-rcpt-nd-signing/
HTML:
https://www.ietf.org/archive/id/draft-latimer-dkim2-rcpt-nd-signing-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-latimer-dkim2-rcpt-nd-signing
The objectives are to improve compatibility with existing DKIM use cases
and ensure that DKIM2 can implemented to the maximum extent possible
within the scope of filters, while limiting the amount of DKIM2-specific
logic being added to SMTP itself. It also offers significant performance
benefits in terms of both routing and signing efficiency, while reducing
the number of DNS lookups required compared to alternative approaches.
This implementation requires filters to be able to edit the RCPT
parameters for recipients. Using existing Milter v8 protocol
functionality, this could be implemented by combining SMFIR_DELRCPT and
SMFIR_ADDRCPT_PAR.
There is one caveat, however. Currently, Postfix does not fully
implement SMFIR_ADDRCPT_PAR and does not add parameters to added
recipients. The notes from when this was implemented indicate the
functionality would "require ESMTP command-line parsing in the cleanup
server". As other approaches would require more extensive DKIM2-aware
header parsing to be added, I don't consider this alone to be a
significant barrier to implementation.
There is a valid concern around filter performance if the filter is run
during message delivery. While the decision of when to run the filter is
up to each implementation, the signing of individual recipients with a
signature derived from the DKIM2-Signature is significantly faster than
signing the same email multiple times and generating a new signature for
each recipient.
In my quick tests, signing an email with a 40MB attachment addressed to
100 recipients took 33% longer than signing for a single recipient, with
further optimisations possible. This is negligible overhead compared to
signing multiple instances of an email and as this approach would
typically only require each intended recipient to be signed once, this
additional overhead is eliminated from subsequent hops.
While the specifics weren't discussed during the meeting, I have since
refined my proposal to have the signer explicitly declare BCC
recipients. This allows SMTP implementations to make routing decisions
without having to implement their own header parsing logic.
Shortly before the meeting, Wei mentioned the potential for pp= to be
used to delegate signing to a platform and ease migration to Ed25519. I
had previously highlighted the benefits of explicitly delegating signing
authority, so since there is some support for that idea I have also
incorporated this into the DKIM2-NextDomain header.
An explicit signing approval allows an ESP which currently manages user
keys to sign the original approval using an RSA key, then re-sign the
email and recipients using their own Ed25519 keys.
Many users choose to route email through third parties out of necessity.
Surrendering control over keys that can sign on behalf of their domain
is a requirement for using many such services. Adding a delegated
signing authority allows users to retain control of their keys while
still permitting an ESP to make necessary changes.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
