On Oct 3, 2013, at 4:53 AM, Hector Santos <hsantos(_at_)isdg(_dot_)net> 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(_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.
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