Subject: Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

From: "John Levine" <[email-masked]>
Date: 2 Oct 2013 14:52:38 -0000

>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'm one of the authors of this RFC and support the change.

ADSP was basically an experiment that failed.  It has no significant
deployment, and the problem it was supposed to solve is now being
addressed in other ways.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Oct 2013 12:28:57 -0400

--On Wednesday, October 02, 2013 07:41 -0700 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from an individual participant
> to make the following status changes:
> 

Hi.  Just to be sure that everyone has the same understanding of
what is being proposed here, the above says "to Historic" but
the writeup at
http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
says "to Internet Standard".   Can one or the other be corrected?

After reading the description at the link cited above and
assuming that "Historic" is actually intended, I wonder,
procedurally, whether a move to Historic without document other
than in the tracker is an appropriate substitute for the
publication of an Applicability Statement that says "not
recommended" and that explains, at least in the level of detail
of the tracker entry, why using ADSP is a bad idea.  

If there were no implementations and no evidence that anyone
cared about this, my inclination would be to just dispose of RFC
5617 as efficiently and with as little effort as possible.  But,
since the tracker entry says that there are implementations and
that misconfiguration has caused harm (strongly implying that
there has even been deployment), it seems to me that a clear and
affirmative "not recommended" applicability statement is in
order.

thanks,
   john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Oct 2013 12:32:05 -0400

> says "to Internet Standard".   Can one or the other be corrected?

Gakk.  I don't know how that happened.  I'll see if the Secretariat
can fix it.  I'm sure it's my fault......

Sigh.

Barry

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 2 Oct 2013 13:43:15 -0400

Hi,

The subject lines says the intention is to move to Internet Standard; the
text says the intention is to move to Historic.
This Last Call should probably be re-published with matching intent.

David Harrington
[email-masked]
+1-603-828-1401
> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of The IESG
> Sent: Wednesday, October 02, 2013 10:42 AM
> To: IETF-Announce
> Subject: Last Call: Change the status of ADSP (RFC 5617) to Internet
Standard
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-10-30. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The affected document can be obtained via
> http://datatracker.ietf.org/doc/rfc5617/
> 
> IESG discussion of this request can be tracked via
> http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-
> historic/ballot/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 02 Oct 2013 10:44:23 -0700

> of the tracker entry, why using ADSP is a bad idea.

This suggestion has the dual potential benefits of being inefficient and 
ineffective.

If a spec is Historic, it is redundant to say not recommended.  As in, 
duh...

Even better is that an applicability statement is merely another place 
for the potential implementer to fail to look and understand.

Anyone who fails to understand the implications of Historic (or fails to 
find the correct status) is not going to be better at finding and 
understanding an applicability statement.

ADSP is only worthy of a small effort, to correct its status, to reflect 
its current role in Internet Mail.  Namely, its universal non-use within 
email filtering.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Oct 2013 14:46:03 -0400

I assume we will need to agree to disagree about this, but...

--On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker
<[email-masked]> wrote:

> If a spec is Historic, it is redundant to say not recommended.
> As in, duh...

"Duh" notwithstanding, we move documents to Historic for many
reasons.  RFC 2026 lists "historic" as one of the reasons a
document may be "not recommended" (Section 3.3(e)) but says only
"superceded... or is for any other reason considered to be
obsolete" about Historic (Section 4.2.4).  That is entirely
consistent with Maturity Levels and Requirement Levels being
basically orthogonal to each other, even if "Not Recommended"
and "Internet Standard" are presumably mutually exclusive.

> Even better is that an applicability statement is merely
> another place for the potential implementer to fail to look
> and understand.

Interesting.   If a potential implementer or other potential
user of this capability fails to look for the status of the
document or protocol, then the reclassification to Historic
won't be found and this effort is a waste of the community's
time.  If, by contrast, that potential user checks far enough to
determine that the document has been reclassified to Historic,
why is it not desirable to point that user to a superceding
document that explains the problem and assigns as requirement
status of "not recommended"?  

The situation would be different if a huge amount of additional
work were involved but it seems to me that almost all of the
required explanation is already in the write-up and that the
amount of effort required to approve an action consisting of a
document and a status change is the same as that required to
approve the status change only.  If creating an I-D from the
write-up is considered too burdensome and it would help, I'd be
happy to do that rather than continuing to complain.

> ADSP is only worthy of a small effort, to correct its status,
> to reflect its current role in Internet Mail.  Namely, its
> universal non-use within email filtering.

If the specification had been universally ignored, I'd think
that a simple status change without further documentation was
completely reasonable.  However, the write-up discusses "harm
caused by incorrect configuration and by inappropriate use",
"real cases", and effects from posts from users.  That strongly
suggests that this is a [mis]feature that has been sufficiently
deployed to cause problems, not someone that is "universally
non-used".  And that, IMO, calls for a explanation --at least to
the extent of the explanation in the write-up-- as to why ADSP
was a bad idea, should be retired where it is used, and should
not be further deployed.  

best,
   john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Oct 2013 14:04:02 -0700

On Wed, Oct 2, 2013 at 7:41 AM, The IESG <[email-masked]> wrote:

> [...]

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

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2013 07:53:51 -0400

> operator intends to remove that capability once this status change goes

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 3 Oct 2013 10:14:18 -0400

> can fix it.  I'm sure it's my fault......

Noting that this has been fixed and that a revised Last Call note went
out.  Please, if you continue this discussion, change the subject line
to say "Historic" instead of "Internet Standard", so no one is
confused by the dissonance.

Thanks, all, and my apologies again for the error in the title.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 03 Oct 2013 16:51:22 +0200

> deployment, and the problem it was supposed to solve is now being

I oppose to the change as proposed, and support the explanation called
for by John Klensin instead.  Two arguments:

1)  The harm Barry exemplifies in the request --incompatibility with
    mailing list posting-- is going to be a feature of at least one
    of the other ways addressing that problem.  Indeed, "those who
    don't know history are destined to repeat it", and the explanation
    is needed to make history known.

2)  A possible fix for ADSP is explained by John Levine himself:
    http://www.mail-archive.com/[email-masked]/msg16969.html
    I'm not proposing to mention it along with the explanation, but
    fixing is not the same as moving to historic.  It seems that it
    is just a part of RFC 5617, DNS records, that we want to move.

Ale

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 03 Oct 2013 11:11:00 -0400

>    is just a part of RFC 5617, DNS records, that we want to move.

That's not a fix for ADSP. It's an alternative to it.

ADSP failed. It's time to move on.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2013 12:41:37 -0400

> ADSP failed. It's time to move on.

For DKIM/ADSP investors (folks who put the $$$ into it and got on 
board with the IETF for this DKIM support effort), thats really not an 
acceptable answer.  What are we moving on to, DMARC?  Its the same 
issue, or is the suggestion that Mailing List Services or middleware 
will support DMARC to help protect DKIM signatures from 3rd party abuses?

ADSP did not fail if the same proof of concepts is going to be 
repeated with DMARC. As Alessandro stated, we are merely switching 
_ADSP to _DMARC zone records with new but similar SOFT (relaxed) vs 
HARD (restrictive) rejection policies and handling rules.   The same 
ones that MLS (Mailing List Services) will have to support as well. 
Its no different than ADSP.

Now, what it does say is that DKIM itself is a weaker protocol.  There 
will no longer be any marketing value for protecting DKIM signatures, 
even if its only in IETF theory.  No value to compare what a DOMAIN 
wanted with its signatures and no protection from abuse whatsoever.

I would say this, if this ADSP historic request was done before the 
DKIM request to change to Internet Standard a few months ago, I would 
of not supported the IS change for DKIM.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Oct 2013 13:09:03 -0400

--On Thursday, October 03, 2013 16:51 +0200 Alessandro Vesely
<[email-masked]> wrote:

>> ADSP was basically an experiment that failed.  It has no
>> significant deployment, and the problem it was supposed to
>> solve is now being addressed in other ways.
> 
> I oppose to the change as proposed, and support the
> explanation called for by John Klensin instead.  Two arguments:
> 
> 1)  The harm Barry exemplifies in the request
> --incompatibility with     mailing list posting-- is going to
> be a feature of at least one     of the other ways addressing
> that problem.  Indeed, "those who     don't know history are
> destined to repeat it", and the explanation     is needed to
> make history known.
> 
> http://www.mail-archive.com/[email-masked]/msg16969.ht
> ml     I'm not proposing to mention it along with the
> explanation, but     fixing is not the same as moving to
> historic.  It seems that it     is just a part of RFC 5617,
> DNS records, that we want to move.

Ale,

Just to be clear about what I proposed because I'm not sure that
you actually agree:  If the situation is as described in the
write-up (and/or as described by John Levine, Murray, and some
other documents), then I'm in favor of deprecating ADSP.  The
_only_ issue I'm raising in this case is that I believe that
deprecating a feature or protocol element by moving things to
Historic by IESG action and a note in the tracker is appropriate
only for things that have been completely ignored after an
extended period or that have long ago passed out of public
consciousness.   When something has been implemented and
deployed sufficiently that the reason for deprecating it
includes assertions that it has not worked out in practice, I
believe that should be documented in an RFC both to make the
historical record clear and to help persuade anyone who is still
trying to use it to cease doing so.

There may well be arguments for not deprecating the feature, for
improving it in various ways, or for contexts in which its use
would be appropriate, but someone else will have to make them or
propose other remedies.  I have not done so nor am I likely to
do so.

  best,
    john

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2013 13:42:12 -0400

I agree, the problem IMV is the illusion that DMARC will replace it 
has some domains has already done by switching their strong exclusive 
mail operations declaration from _ADSP TXT record policy to a _DMARC 
policy.  Like FACEBOOK.COM. The REJECTING/DISCARD concept is still the 
same and active, just a different TXT domain policy protocol 
describing the expected behavior.

The problem I have is the lack of confidence that DMARC will be 
supported by the main conflictive software in the entire DKIM 
deployment and service architectural picture -- the resigners (mailing 
list software).  Thats the problem ADSP had.  DMARC does not change it.

So is making ADSP historic, killing the investment done with DKIM/ADSP 
support, going to be replacing with a plug and play protocol switch 
with DMARC?

If so, I don't like that lost of investment but I can support the move 
but now, not as an early adopter and I will wait until other mailing 
list software vendors/developers add that necessary support for DMARC 
rejection policies.   Its the same proof of concept issue as it was 
with ADSP.

DMARC just add some reporting, logging and feedback concepts to the 
picture.

--
HLS

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Oct 2013 10:51:22 -0700

On Oct 3, 2013, at 4:53 AM, Hector Santos <[email-masked]> wrote:

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 3 Oct 2013 11:45:11 -0700

On Thu, Oct 3, 2013 at 4:53 AM, Hector Santos <[email-masked]> wrote:

>
> 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.
>

I would hope this is obvious, but I didn't claim my little survey was
representative of the entire industry.  It's at best a cross section of
OpenDKIM's user base (which does include at least three of the largest
operators, but by no means all of them).  I made it clear how many replies
I'd gotten.

> 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?
>

The ADSP impact reports that are part of RFC6377, the writeup for this
action, and elsewhere already exist and are not specific to one
implementation.

I don't think there's any particular DMARC-specific agenda here, but it is
indeed obvious that (a) they overlap in a few ways, and (b) DMARC has not
yet been accepted as IETF work but already has more deployment and support
momentum than ADSP ever enjoyed.

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.
>

I think it's rather premature to claim anyone's input has been ignored when
the solicitation for comment is still open.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2013 15:55:12 -0400

> 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).  Ma…

Whether its ADSP, DMARC or anything else, any DKIM resigner has to be 
aware of the consequences of blind signing.  It can not operate in a 
vacuum as if all of the following documents did not exist:

    RFC4686  Analysis of Threats Motivating DKIM
    RFC5016  Requirements for a DKIM Signing Practices Protocol
    RFC5585  DKIM Service Overview
    RFC5617  DKIM Author Domain Signing Practices (ADSP)
    RFC5863  DKIM Development, Deployment, and Operations
    RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists

All of them describe a basic integrated concept of protecting the 
domain signature which is still a problem to be resolved today 
otherwise the payoff of the new DKIM "Internet Standard" is still 
Zilch, Nada, Nil.

So if the movement is now towards DMARC, are mailing list software 
going to support the policies exposed by DMARC restrictive domains?

We are not resolving the basic debate that was always with us. 
Stripping Policy from DKIM framework as a separate SSP, then further 
relaxing it and changing it to ADSP and now DMARC does not resolve the 
basic fundamental problem with securing DKIM signatures if middleware 
are not going to support the concept and continue with blind 
resigning.

Make ADSP historic and DKIM itself is at risk of finally falling into 
that wasted protocol project as well.  Sure everyone is signing but 
also stripping and replacing everyone's signature, its value has been 
totally lost.

Go figure. I think the requester of this change ought to write a 
report explaining how making ADSP historic and adopting DMARC 
minimizes any impact and also helps keep DKIM as a viable mail 
signature concept to have.  How the payoff is finally realized with 
DMARC rather an ADSP.

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Thu, 3 Oct 2013 16:37:48 -0400

To both Doug and Hector, and others who want to drift in this direction:

As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we do or
don't do with DMARC.  Bringing DMARC into the discussion is a
distraction, and, worse, makes it look like there's a tie-in.  There
is not.

So, please, let's not discuss DMARC as part of the "ADSP to Historic"
conversation.  The issue is purely one of whether ADSP can be shown to
have enough value to maintain it as a Proposed Standard, whether we're
not getting enough value from it, and whether there's harm resulting
from our recommending its use and seeing it poorly used.

Please, everyone: discussions of DMARC in relation to this topic are
out of scope.

Barry, Applications AD

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2013 18:22:24 -0400

Please accept my apology as I do not mean to be disrespectful. I find 
it impossible to separate all design considerations that are involved 
in this decision you are requesting us to consider regarding a near 
7-8 years DKIM + POLICY investment.

DKIM originated with POLICY support built-in and it was a critical 
part of its marketing and selling point. It evolved from its 
predecessor Domainkeys with built-in policy support.  DKIM+POLICY was 
its technological advancement and attraction.  It made sense and it 
was elegant common sense design. It is why we supported DKIM.   It was 
then split as DKIM and SSP. SSP was relaxed and changed to ADSP.

Now you are asking us to just drop ADSP or in short, drop the basic 
idea of Domain Policy Layer support that sits on top of DKIM.

I don't think there was any question that the proof of concept is 
there. The implementators are there. The APIs have support.  The 
publishers are there.  Its value is high, so high Dave Crocker once 
stated "Its scary!" (check archives).  A strong deterministic protocol 
that allowed private domains to expose strong email policies and for 
receivers to honor and follow, immediately protecting domains from 
electronic mail spoofs.  A thing of beauty!

But the MAILING LIST SOFTWARE (MLS) needed to support it.

If this vote is a suggestion that MLS will not support ADSP, I am 
asking will it support DMARC because we will be repeating the same 7-8 
years integrated software design issue.

I will support a discussion of the entire AUTHOR DOMAIN POLICY 
protection layer for DKIM and finally determine if it will work or 
not, and if so, maybe some way that even the MLS developers will 
support -- the main barrier to this DKIM + POLICY problem.

If DMARC and MLS developers are expected to coexist without 
complaints, then the impact of deprecating ADSP will be less severe 
and the investment, time, energy and knowledge already learned will 
not be lost.

Why can't we just wait until at least DMARC is settled answering some 
of the same DKIM signature practice security questions surely to 
arise?   If its supported (which seems to far to be getting a higher 
mindset), then why can't ADSP be deprecated at that point, with DMARC 
making ADSP obsolete?

--
HLS

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Oct 2013 15:25:54 -0700

> distraction, and, worse, makes it look like there's a tie-in.  There

Dear Berry,

Even John Levine the author had opine along these same lines.  The response to Hector was agreeing a reason should be given, along with agreeing with his justifications.  The tie-in may be limited, but nevertheless DMARC has become the chosen alternative.  It seems if any reasons are given for moving ADSP to historic it also should conjecture why DMARC and not ADSP, unless your point is nothing has been learned?

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 3 Oct 2013 16:45:41 -0700

>     is needed to make history known.

Ample discussion of the problems exists in RFCs, most notably RFC 6377.  A
simple solution to your concern would be to modify the writeup to reference
what's written there.

John Klensin's proposal, however, is to write up and publish a short RFC
that makes the state change and possibly the "Historic" request, so that
the two things (status change and pointers to details) are in one, more
obvious, place.

> To me, that post says ADSP is best implemented as a locally-configured
list of domains for which ADSP should be enforced.  That may be the better
solution, but then there's no protocol for the IETF to document, because
nothing is interoperating.  I don't believe this is an argument for
prolonging ADSP itself.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2013 19:54:35 -0400

> Even John Levine the author had opine along these same lines.  The response to Hector was agreeing a reason should be given, along with agreeing with his justifications.  The tie-in may be limited,…

Doug, the whole problem was the middleware, the mailing list software 
or the 3rd party resigners who were either not supporting DKIM, 
ignorant of policy protocols and/or that did wish to have any 1st 
party domain controls dictating what mail can be resigned or not.

If DMARC is the "chosen alternative" we are still repeating the same 
related issues with this Author Domain Domain Policy Protocol as well. 
   The mailing list software needs to support this otherwise we still 
have the same problems as with ADSP.  In short, a subscriber to a list 
using a DOMAIN that is DMARC restrictive will also have a potential to 
cause automated unsubscribe events to members with DMARC compliant 
receivers supporting the DMARC restrictive policies.   Same thing as 
with ADSP, just change the protocol name.

Keep in mind that DMARC promises to offer better ADSP or as it 
documents "Super ADSP," in fact it outlines what seems to be the short 
comings of ADSP:

    http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#appendix-A.5

    A.5.  Issues With ADSP In Operation

    DMARC has been characterized as a "super-ADSP" of sorts.

    Contributors to DMARC have compiled a list of issues associated with
    ADSP, gained from operational experience, that have influenced the
    direction of DMARC:

    1.  ADSP has no support for subdomains, i.e., the ADSP record for
        example.com does not explicitly or implicitly apply to
        subdomain.example.com.  If wildcarding is not applied, then
        spammers can trivially bypass ADSP by sending from a subdomain
        with no ADSP record.

    2.  Non-existent subdomains are explicitly out of scope in ADSP.
        There is nothing in ADSP that states receivers should simply
        reject mail from NXDOMAINs regardless of ADSP policy (which of
        course allows spammers to trivially bypass ADSP by sending email
        from non-existent subdomains).

    3.  ADSP has no operational advice on when to look up the ADSP
        record.

    4.  ADSP has no support for using SPF as an auxiliary mechanism to
        DKIM.

    5.  ADSP has no support for a slow roll-out, i.e., no way to
        configure a percentage of email on which the receiver should
        apply the policy.  This is important for large-volume senders.

    6.  ADSP has no explicit support for an intermediate phase where the
        receiver quarantines (e.g., sends to the recipient's "spam"
        folder) rather than rejects the email.

    7.  The binding between the "From" header domain and DKIM is too
        tight for ADSP; they must match exactly.

We must consider that the requestor for the ADSP status change has 
also authored a DMARC "BCP:"

    Using DMARC
    http://tools.ietf.org/html/draft-crocker-dmarc-bcp-01

This draft only mentions ADSP once, and very briefly:

    10.  Interaction Issues

    Some issues come into play when DMARC is used in conjunction with one
    or more other services.

    o  Sender using both DMARC and ADSP

Ok, like what?

Lets try to get the issues straight. We are talking about dropping 
work that is already active in replace of some "super-ADSP" protocol.

Can we get it right please?

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Oct 2013 16:59:06 -0700

On 10/2/2013 11:46 AM, John C Klensin wrote:
> reasons.

Sure.  And you seem to think that it's important to publish an RFC that 
documents the reasons.  You seem to think that it will somehow affect 
later handling of the historic document.

While an entirely reasonable theoretical premise, I'm not aware of its 
having any empirical basis.  Quite the opposite.

Further since your proposal constitutes additional work for someone, the 
benefit of doing it should be clear and compelling.  So far, what you've 
offered is neither.

In fact, the general view around the IETF is that the rest of the world 
deals with RFCs in a very coarse and inclusive manner, so that your 
proposal for fine-grained, formal documentation of rationales and the 
like constitutes mere noise to the rest of the world.

> approve the status change only.

While it's laudable that you are volunteering to do this negligible 
extra work that will cause negligible amounts of additional delay, it 
still suffers the problem of producing negligible additional benefit.

If someone is all that interested in the reason the spec was moved to 
Historic, they can consult the IETF archives.

d/