[ietf-dkim] Fluffy DKIM questions

[Steve Atkins]

On May 15, 2007, at 1:16 PM, Dave Crocker wrote:

> Steve,
>
> Please take a look at <http://dkim.org/info/dkim-faq.html> and then  
> re-send your note with the questions that it doesn't answer. At the  
> least, this will give me some input about the faq's utility.
>

The FAQ is a generally good, brief, high level overview of
the positive aspects of the technical details of the protocol.
It leaves many of the implications of those details to
the imagination of the reader - and some of those implications
are subtle and easy to get wrong, so there's risk of people
coming away with quite different (and possibly wrong) ideas
of what DKIM deployment will actually mean to them.

Rephrased, then:

1. What are the drawbacks of deploying DKIM or DK+DKIM
     compared to not deploying it. What are the direct business
     benefits of signing with it? If I'm checking against it, what
     does a valid signature mean? An invalid signature? A
     missing signature? What should I consider doing in those
     cases? What *shouldn't* I do?

(Signing and validation cost. Widespread misunderstanding
of what mail whose signature does not validate means.)

2. What are the advantages of DKIM over DK to me as a
     sender or as a receiver of mail? Why did you change it
     all in an incompatible way, so I have to support both?
     Does the standardisation of DKIM mean that DK is dead?

(This also leads into senders questions along the lines of
  "You told me SPF was The Answer,so I deployed SPF and
I still need to support that because some recipients still check
it. Then you told me DK was The Answer, so I deployed that,
and I still need to support it because some recipients still
check it. Now you're telling me that DKIM is The Answer.
Why should we believe you this time? How many incompatible
sender authentication technologies are we going to have to
support for all time?" OK, maybe more of a whine than a
question, but they do have a point.)

3. Should I sign with DKIM? DK? Both? If I should sign with
     both is there any best practice as to how to do so? Should
     I expect a recipient to check DKIM or DK or both? Is there
     a flag day when I should stop signing with DK?

(I've seen reports of odd and broken behaviour from some
recipients for mail signed with both DK and DKIM, and I'm
getting questions as to which people should use.)

4. What does "Licensee hereby grants Yahoo! and its
     subsidiaries a license under all patent claims owned
     or licensable by Licensee without requirement of paying
     additional consideration to make, use, sell, offer for sale,
     import and/or license any Implementations." mean, and
     do I need to care?

(I know what I think it means, and I don't care, but some of
the people I'm talking to about deployment are concerned
by it, and even minor reasons not to consider DKIM deployment
right now would be good to avoid.)

All this is stuff that I can answer, I think, but it's something
that there should be a consistent message for, so I was
hoping someone else had already put together something
or at least thought about how to communicate it. Jim's
response was quite useful there, I think.

Cheers,
   Steve


> d/
>
> Steve Atkins wrote:
>> As a distraction from the deeply technical stuff, I have
>> some PR / deployment related questions. I'm looking
>> for answers that are suitable for a user intending to
>> deploy, rather than a developer intending to implement.
>> I'm also talking solely about dkim-base, not about any
>> of the bags on the side.
>> 1. Does anyone have an overview of the benefits and
>>     drawbacks to DK and DKIM in general?
>> 2. How about the differences between DK and DKIM?
>> 3. Is a valid DK signature a valid DKIM signature?
>> 3b. If the general answer to that is "no", are some subsets
>>     of DK signatures also valid DKIM signatures?
>> 4. What are the Intellectual Property implications of
>>     deploying DKIM? (The Yahoo DK license agreement
>>     has scared off a number of people from implementing
>>     or using it).
>> I think I know the answers to some of these, but I
>> thought I'd throw them out here anyway.
>> Cheers,
>>   Steve
>> _______________________________________________
>> NOTE WELL: This list operates according to http://mipassoc.org/ 
>> dkim/ietf-list-rules.html
>
> -- 
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net