Hi!
A few comments:
- "To ensure maximum interoperability, Signers SHOULD sign messages with
multiple DKIM2 signatures, with each such signature using a different
cryptographic algorithm."
I'm not sure if this is needed. The main draft specifies that verifiers
MUST support both rsa (>= 1024 bit, <= 2048 bit) and ed25519. So
"signatures SHOULD include at least one of RSA (key size >= 1024, <=
2048) or ED25519" would be enough to "ensure maximum interoperability"?
- "Test-mode selectors (the "t=y" flag defined in {{DKIMKEYS}}) SHOULD
be used when a new key is first deployed"
I thought we're deprecating t= in the current DNS draft?
- "Verifiers are permitted to treat a DKIM2-Signature header field whose
t= timestamp is more than 14 days old, or that lies in the future, with
suspicion"
I thought, verifiers SHOULD (e.g. "are strongly encouraged") to treat
those as invalid? (We'll probably PERMERROR them, with just a little
slack for time skew for the "in the future" case.)
- "{{DKIM2}} does not impose a protocol-level limit on the number of
Message-Instance or DKIM2-Signature header fields a message may
accumulate; each is added, at most, once per hop"
The BCP does say that an ADMD should sign only once at exit. However,
there's deliberatly no "at most one new M-I between one D2-S and the
next one" to allow simpler revising steps without being obligated to
merge recipes generated by those steps. So there can be more than one
M-I per hop, even if the hop complies with the BCP in adding only one D2-S.
- "{{DKIM2}} does, however, bound the number of hash and signature
*entries* that may appear within a single such header field"
I don't see a limit for overall number of signatures in one s=. There
_is_ a limit to at most one per selector and at most two per algorithm
type, but with extension algorithm types, there are theoretically no
upper bounds. For a verifier there's still a limit as long as it
supports only a bounded number of algorithm types.
I also don't see a limit for hashes, with extension hash algorithm
names, but again a de facto limit in verifiers supporting only a bounded
number of those.
- "Data Loss Prevention"
A DLP system close to the sender can apply body null recipes but that
would limit trust downstream, because the DLP system only has a
(presumed) trust relationship with the sender but not with downstream
hops/receivers.
Basically a DLP system would rather need to act more fully on behalf of
the sender (like an email sending service provider).
In addition, the sensitive-data usecase of body null recipes isn't
applicable for headers (e.g. if I accidentaly send a mail with subject
"more talk about the customers credit card no ...").
So a DLP would best either need to bounce/reject such mails (possibly
scrubbing data in the DSN) or act on behalf of the sender (creating the
i=1 m=1 signature only at the DLP point, perhaps with artificial nd hops).
Kind regards,
Hannah.
On 9/9/26 17:23, [email protected] wrote:
Internet-Draft draft-ietf-dkim-dkim2-bcp-01.txt is now available. It is a work
item of the Domain Keys Identified Mail (DKIM) WG of the IETF.
Title: DKIM2 Best Practices
Author: Todd Herr
Name: draft-ietf-dkim-dkim2-bcp-01.txt
Pages: 25
Dates: 2026-09-09
Abstract:
[DKIM2] and its associated documents describe the DomainKeys
Identified Mail v2 (DKIM2) email authentication protocol. DKIM2 is
designed to address shortcomings in email authentication protocols
and mechanisms released prior to DKIM2, specifically SPF [RFC7208],
DKIM [RFC6376], DMARC [RFC9989], and ARC [RFC8617]. This document
discusses best practices for signing, handling, and validating
messages that carry DKIM2 signatures, and for interoperating with the
authentication protocols and mechanisms that preceded DKIM2.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-bcp/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-bcp-01
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dkim-dkim2-bcp-01
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr.
Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt,
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
