ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

2010-10-01 11:48:01
Michael Thomas wrote:
MH Michael Hammer (5304) wrote:
This is of interest beyond ADSP. It helps the community understand who
is signing. There has been much discussion of the value of Author vs.
Third-Party signing outside of the ADSP discussion.

As Jeff points out, this may be related to implementations defaulting to
signing this way (or not easily allowing 3rd party signing).

I don't think it should come out.

I agree. If nothing else, it may be showing implementations which have bad
access control mechanisms. But it seems to me that stats on how people are
signing is generally interesting, and isn't linked to ADSP at all.

What I am increasing seeing is that with the early DKIM raw signing 
(since policy was pulled and still in the works),  people are now are 
starting to question what is the purpose, the payoff, the 
uncertainties - policy (in whatever form) is the common consideration.

For example, you have a dkim=all. Following a strict RFC 4871, you end 
up with and world (IETF-DKIM world) seeing:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
   adsp=fail policy=all author.d=mtcc.com;

So what does that mean?

Well, you have to tell the world that mipassoc.org is a "good guy." 
Sure, it can isolated to certain reputation engines receivers and also 
members (list receivers) can white list it as well thus always 
trusting mipassoc.org.

But you can help the world wide general verifier market by using some 
sort of self-asserting third party "allow" or "authorization" method.

-- 
HLS



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html