Hi R,
I mostly wanted to answer one item below as chair. I'll give you a
non-expert view on the rest and hopefully others will fill in details.
On 2 Sep 2025, at 20:44, Inveigle.net wrote:
This is my first message on this mailing list, so forgive me if I am
missing some of the context discussed previously. I am aware of the
'Consensus review from IETF 123' thread which seems to indicate
DKIM2 won't be so named...
This bit is not quite right: There was no discussion at the last IETF
meeting on what the name of the protocol or the header field ought to
be. What we (the chairs) did hear in the room was that the information
in this protocol should not be carried in a "DKIM-Signature: v=2" header
field, but instead should use a new header field name. (And of course
that's what we heard in the room; the purpose of this thread is to
confirm that we got that right and that anyone who did not attend had a
chance to raise any new concerns on the list.) The current proposal on
the table is that header field name will start with "DKIM2-", though the
group can decide to change that in the future if they wish.
...but assuming it is based heavily on DKIM1 and intended to replace
it, I believe my comments are still relevant.
I was looking at this draft from the point of view of implementing it
in code, however, I am left a little bewildered by the route DKIM2
seems to be taking.
I am particularly concerned with DKIM2 appearing to fundamentally
change delivery logic, necessitated by the rt= tag, which is listed as
required, including for BCC recipients. Requiring special handing of
BCC recipients means 'dumb' systems that simply sign and forward will
need to be replaced with a full DKIM2-capable MTA, or be extensively
rewritten to implement retry logic for one to many deliveries.
Do note that there is also discussion about how to take a DKIM message
and add DKIM2 information to it (i.e., the "transition" discussion). So
it might not be necessary to replace the 'dumb' systems.
The rest I will leave to others to address.
pr
The same applies to e-mail clients, which are designed to send one
e-mail, not one per recipient. While there appears to be some
disagreement on this list regarding the practicality of client-side
signing and verification, this is something I use extensively (both
sending and receiving) and I know of other users doing the same. It is
particularly desirable to send pre-signed e-mail from remote
servers/clients as it simplifies key management, keeping DKIM keys
completely separate between high(er) risk systems and business e-mail,
while avoiding the need for SMTP credentials to be stored on remote
hosts or allowing unauthenticated relay from those systems.
I'm also unconvinced that relaxed canonicalisation should be used
exclusively, especially given simple/simple is the DKIM1 default and
trivial to implement. I've only had one issue with an upstream service
invalidating a DKIM-Signature as a result of using that
canonicalisation and that issue was fixed immediately after I brought
it to their attention.
Regards,
R. Latimer
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
