From: Scott Kitterman <ietf-dkim@ki...> - 2007-08-15 11:00:31
On Wed, 15 Aug 2007 01:13:28 -0700 (PDT) "Murray S. Kucherawy"
>On Tue, 14 Aug 2007, Scott Kitterman wrote:
>> One thing to consider is that many signers are still using the pre-RFC
>> formats including such small obscure senders as Gmail. If you are just
>> signing, this won't matter, but if you can about verifying signatures,
>> you ought to think about if you are ready to stop recognizing pre-RFC
>> formats or not.
>Sarcasm aside, I did consider all of that before removing support for
>pre-RFC formats. I am quite aware of who is signing with DKIM and with
>which versions. Also setting aside the fact that anything "pre-RFC" means
>"experimental" and is thus by definition not standard, there was still a
>good reason for doing so.
>While the changes for 2.0.0 were in development last month, which mostly
>included comprehensive support for multiple signatures (which had been
>identified as a high priority), it became extremely difficult to maintain
>both the code for multiple signature support and continued code support
>for the older DKIM formats. The choice in such situations is clear: You
>invest effort into the one of the two which is expected to have the most
>longevity and impact.
>Code maintainability is critical right now, especially in this nascent but
>quickly-expanding arena. I'm willing to take the hit for discontinuing
>convoluted support for experimental formats in exchange for something
>that's clean, useful, and will remain useable for some time.
>There are already a number of people who have approached Gmail about
>updating their signing code to match the RFC. Although I doubt they need
>our help, we have offered it.
>Moreover, v1.2.0 is still available from SourceForge as the most recent
>released version that retained support for all versions of DKIM if that's
>more important to your installation that what's available in v2.1.1.
>And finally, dkim-milter is open source software and this is mostly a
>volunteer effort. I'm quite open to accepting patches to restore the lost
>functionality in a maintainable way if you wish to contribute such.
I'm sorry that came across as criticism of your development decision. It
wasn't intended that way. It was meant as an operational caution about
I'm sure Google and others will upgrade in time, but in the mean time, if
verification is important to an MTA operator, upgrading to the 2.0 series
has real operational risks that people should be aware of.
Get latest updates about Open Source Projects, Conferences and News.