On Oct 3, 2013, at 4:53 AM, Hector Santos <hsantos@xxxxxxxx> wrote: > > On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote: >> On Wed, Oct 2, 2013 at 7:41 AM, The IESG <iesg-secretary@xxxxxxxx> wrote: >> >>> The IESG has received a request from an individual participant to make >>> the following status changes: >>> >>> - RFC5617 from Proposed Standard to Historic >>> >>> The supporting document for this request can be found here: >>> >>> http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ >>> [...] >>> >> >> I support this change, for the reasons articulated in the request and in >> this thread. >> >> I am the lead developer and maintainer of OpenDKIM, an open source >> implementation of DKIM and related standards, including VBR, ADSP, the >> recent REPUTE work, and some others. It is widely deployed, including use >> at a few of the largest operators. An informal survey was done on one of >> the mailing lists where this package is supported, asking which operators >> do ADSP queries and which act upon the results. I have so far only >> received a half dozen answers to this, but the consensus among them is >> clear: All of the respondents either do not check ADSP, or check it but do >> nothing with the results. One operator puts disposition of messages based >> on ADSP results into the hands of its users, but no statistics were offered >> about how many of these users have ADSP-based filtering enabled. That same >> operator intends to remove that capability once this status change goes >> into effect. >> >> -MSK > > I don't believe this would be a fair assessment of industry wide support -- using only one API to measure. There are other APIs and proprietary systems who most likely are not part of the OpenDKIM group. There are commercial operations using DKIM and ADSP is part of it. > > The interop problem is clearly due intentional neglect by specific MLS (Mailing List Software) of the DKIM security protocol, not because of the protocol itself. Support of the protocol does not cause an interop problem -- it helps support the DKIM security protocol. The ADSP (RFC5617) protocol is part of the DKIM security threat mitigation model (RFC4686), the DKIM Service Architecture (RFC5585), the DKIM Deployment Guide (RFC5863) and also the Mailing List for DKIM guideline (rfc6377). That is FOUR documents. > > Applicability and Impact reports *should* to be done before pulling the rug from under the non-OpenDKIM market feet. In addition, it appears part of the request is to help move an alternative DMARC protocol forward. Why would the DMARC replacement do better? Why should commercial development for ADSP be stopped and removed from products, and now a new investment for DMARC be done? Would this resolve the apparent interop problem with the specific Mailing List Software who refuse to support a DKIM security protocol? > > More importantly, why should any small operator and participant of the IETF continue to support IETF projects if their support is ignored and projects will be ended without their input or even explaining why it should be ended? That doesn't play well for the IETF Diversity Improvement Program. Dear Hector, Indeed, more should be said about underlying reasons. The reason for abandoning ADSP is for the same reason few providers reject messages not authorized by SPF records ending in "-all" (FAIL). Mailing-List software existed long before either of these strategies and domains using mailing lists need to be excluded from having DMARC policies (until a revised ATPS specification able to use normal signatures is published.) The reason for moving toward DMARC is, although aligned policy is only suitable for domains limited to messages of a transactional nature, places where one authorization scheme fails can be mostly recovered by the other which greatly increases the chances of a domain's policy being applied in the desired fashion. Regards, Douglas Otis