Hello all,
Being just an observer and follower of the DKIM2 spec discussion on this
ML, I was wondering what could be done to help make DKIM2 succeed in a
better way than when Ed25519 was introduced for DKIM, which never really
took off.
I don't know what is usually done in terms of "PR" to relevant parties
when it comes to standardising something on the IETF DKIM group, so
perhaps Standard Operating Procedures already exist. That would be great!
However, should that not be the case, then I have been wondering whether
it would be worth considering early outreach to developers of several
email related tools, e.g.:
- libraries and milter implementations (some are already here, or have
it implemented, like Fastmail and Stalwart)
* Rspamd
* OpenDKIM
* dkimpy
* any others that I am forgetting here
- widely used email-authentication diagnostic tools / websites, such
as:
* MXToolbox
* Mailhardener
* dmarcian
* EasyDMARC
* I am sure there are many others, and this is by no means an
authoritative or complete list, just what came to my mind now.
Mostly, I am wondering about that second group. My concern is that
deploying a new authentication mechanism involves more than support in
signing and receiving MTAs. Administrators also rely on familiar tools
such as MXToolbox and Mailhardener to diagnose DNS configuration,
signature verification and interoperability problems.
When Ed25519 for DKIM was standardised, it didn't take off as expected
(or should I say, hoped for). Perhaps publishing a Standard alone does
not guarantee that it will be taken up, even if it might have advantages
over what is current.
Would it be useful to encourage diagnostic-tool developers to evaluate
DKIM2 support as the specification stabilises, with a view to having
meaningful testing available when early deployments begin?
I am thinking particularly of DNS-record validation, signature
verification, clear reporting of unsupported algorithms or formats, and
interoperability test cases.
There is already a test website by Bron. Perhaps this can be made public
around that time as a resource for testing a DKIM2 setup as well?
I understand that the specification is still evolving, but I wanted to
mention this in time, so that it can perhaps mature if it is deemed a
good idea.
Perhaps early engagement with these tool developers might help reduce
friction when development of the DKIM2 standard nears completion?
I hope this is of any use!
Kind regards, and thank you so much for everything you do for email!
Edmund Lodewijks
--
Edmund Lodewijks <[email protected]>
TZ: UTC+2 / GMT+2
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
