My experience is a bit old, but I had issues of interoperability with a well known vendor of large-scale email send. It was very hard to debug the issues, and they eventually decided to adopt opendkim, because many were using it already.
I’m not saying these nits should be explicitly in the charter as they are operational issues, but I did not feel they were captured in the higher-level objectives. From: Murray S. Kucherawy <superu...@gmail.com> Date: Thursday, November 7, 2024 at 08:51 To: Franck Martin <fmar...@linkedin.com> Cc: Bron Gondwana <brong=40fastmailteam....@dmarc.ietf.org>, ietf-dkim@ietf.org <ietf-dkim@ietf.org>, Wei Chuang <wei...@google.com>, Richard Clayton <rclay...@yahooinc.com> Subject: Re: [Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2 On Thu, Nov 7, 2024 at 4:26 PM Franck Martin <fmar...@linkedin.com<mailto:fmar...@linkedin.com>> wrote: A last nit, many standardized on opendkim, because of interoperability. There were too many weird things happening between different implementations of DKIM1. I don’t know if interoperability should be better addressed (better debugging, reporting), or the suggestion that everyone should use the same library. Do you have any examples of such problems? I thought the interoperability testing we did with DKIM was some of the most thorough I've seen in the IETF (at least in the applications areas) since I started, so I'm surprised that stuff got through. The only thing I've heard of is [in]consistency around how different implementations do [not] implement "x=". In any event, I agree that we should strive to meet or surpass the thoroughness of what we did for DKIM. On whether the charter has to say that expressly, I'm less certain. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
