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
