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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html