On 28/08/2025 2:46 am, Richard Clayton wrote:
This draft is modelled on RFC 6376 and is intended to set out a formal
specification of DKIM2-Signature fields. It doubtless contains many
errors and omissions.
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, 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.
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
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
