John Levine wrote: > I've been trying to find _adsp records, and there's precious few of > them. Of the 73 domains that have sent me DKIM signed mail recently, > three have dkim=unknown, two have dkim=all, and the other 68 have no > ADSP. The two with dkim=all are both tiny personal domains with only > a single user. I checked obvious candidates that do sign all their > mail and could be considered phishing targets such as paypal.com, > ebay.com, ag.com, and cisco.com, and found no ADSP.
There is no standard to adopt it. After SSP was killed, who would the waste time again to explore something that really didn't look like the authors believed in it? Many have indicated support once there is a draft standard. But you can't use only your assessment because the API that was out there did include have SSP support and there were SSP records out here. > So the implementation experience is, to put it generously, pretty > sparse. Between the lack of experience and the serious design > problems that a significant number of people in the DKIM group find in > ADSP, it seems like a very poor candidate for standardization in its > current form. You never had any attention to allow POLICY to be part of DKIM. Never, to be frank. From the very beginning, you were throwing stones at POLICY. > If it were up to me. It is up to you. You took SSP and wrote ADSP. > I'd forget about it for now, get more experience > with DKIM, and try dropping unsigned mail from places like paypal.com > and ag.com to see how much difference it makes and how many of their > signatures break. (Since Paypal and AG each send mail from a small > set of easy to identify servers, you can generally look at mail with > broken signatures and tell whether it's real anyway.) When we have a > better understanding of how people use DKIM, how the various > identities are used, and how signatures break, maybe then we can > consider whether there are self-assertions that would be useful to > receivers. > > Since there seems to be a faction that is nonetheless eager to publish > something about ADSP, an Experimental RFC would better reflect the > reality of the situation, since ADSP in its current form really is > just an experiment. And so is DKIM! This is all shameless nonsense. It is unfortunate both Eric and Jim Fenton allowed their specification to be mangled, crippled and swallowed by non believers of Policy. At least Eric has an excuse (health and there are better things in life to do deal with this), but Jim did not. All this time wasted. It was predicted when you came out with ADSP when it was on record you simply never believed in POLICY. So it was quite obvious there was not going to be much championing of this document. Now it finally came to fruition. You can't work on something you don't believe it. Maybe its time as Eric suggested to move forward with an non-IETF POLICY document. Maybe its time as others outside the WG to move forward with their suggestions with a POLICY document. Is there anyone out who believes in POLICY, can champion, can take over this ADSP document and help finish it? -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
