On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote:
On Wed, Oct 2, 2013 at 7:41 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
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.
--
HLS