Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Sep 2013 16:52:02 -0700

Folks,

Barry has agreed to sponsor the enclosed status change.

He would like to see discussion formal request.

(If you've already responded to my /in/formal query earlier today on the 
dmarc@ietf list, please now lodge any formal comments you wish to make 
on either of the two lists here.

d/

-------- Original Message --------
Subject: Request to move RFC 5617 (ADSP) to Historic
Date: Wed, 11 Sep 2013 16:09:14 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Barry Leiba <[email-masked]>,  Pete Resnick 
<[email-masked]>

Folks,

This is a formal request, to have DomainKeys Identified Mail (DKIM)
Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

It has garnered almost no deployment and use, in the 4 years since its
advancement to IETF Proposed Standard.

In addition, newer work, DMARC, covers the same general email functional
area and already has garnered quite a bit of deployment and use. Hence
it will clarify things for the marketplace to remove standards status
from the apparently-competing, but actually-useless ADSP specification.

Today I sent a query to the MAAWG Technical committee and the IETF DMARC
mailing lists, to assess support for the status change. Within only a
few hours, I've already seen quite a few +1s, and no -1s.

Thanks.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Terry Zink <[email-masked]>
Date: Thu, 12 Sep 2013 00:46:24 +0000

I agree with this proposal.

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, September 11, 2013 4:52 PM
To: DKIM IETF WG; Apps Discuss
Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

Folks,

(If you've already responded to my /in/formal query earlier today on the dmarc@ietf list, please now lodge any formal comments you wish to make on either of the two lists here.

d/

-------- Original Message --------
Subject: Request to move RFC 5617 (ADSP) to Historic
Date: Wed, 11 Sep 2013 16:09:14 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Barry Leiba <[email-masked]>,  Pete Resnick <[email-masked]>

Folks,

This is a formal request, to have DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

It has garnered almost no deployment and use, in the 4 years since its advancement to IETF Proposed Standard.

In addition, newer work, DMARC, covers the same general email functional area and already has garnered quite a bit of deployment and use. Hence it will clarify things for the marketplace to remove standards status from the apparently-competing, but actually-useless ADSP specification.

Today I sent a query to the MAAWG Technical committee and the IETF DMARC mailing lists, to assess support for the status change. Within only a few hours, I've already seen quite a few +1s, and no -1s.

Thanks.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 18:15:46 -0700

I also agree with this proposal.  I don't have much to add over the text in
the formal request; it lays out the case based on my experience
implementing DKIM and ADSP in open source.  I can also say that I have
never encountered an operation that actively uses it, including current and
previous employers.

-MSK

On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink <[email-masked]>wrote:

> dmarc@ietf list, please now lodge any formal comments you wish to make on
> either of the two lists here.
>
> d/
>
>
> This is a formal request, to have DomainKeys Identified Mail (DKIM) Author
> Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.
>
> area and already has garnered quite a bit of deployment and use. Hence it
> will clarify things for the marketplace to remove standards status from the
> apparently-competing, but actually-useless ADSP specification.
>
> mailing lists, to assess support for the status change. Within only a few
> hours, I've already seen quite a few +1s, and no -1s.
>
> Thanks.
>
>
> d/
>
> --
> Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2013 01:39:45 -0000

>Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

I'm one of the authors, and I think it's a dandy idea.

Other than a few experiments and one or two impressive misfires, such
as one that bounced innocent bystanders off an IETF mailing list,
nobody's ever used it.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Sep 2013 23:09:47 -0400

This seems like a reasonable step to take.

    Tony Hansen

On 9/11/2013 7:52 PM, Dave Crocker wrote:
> (If you've already responded to my /in/formal query earlier today on
> the dmarc@ietf list, please now lodge any formal comments you wish to
> make on either of the two lists here.
>
> d/
>
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Sep 2013 08:47:39 +0200

Dave,

> make on either of the two lists here.

I agree.  To my knowledge there has not been uptake and realistically
DMARC is meant to correct this.

Eliot

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 12 Sep 2013 09:01:12 +0200 (CEST)

> either of the two lists here.

that's fine for me.

> few hours, I've already seen quite a few +1s, and no -1s.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Sep 2013 08:34:14 -0400

-1

This will require a substantial review before any change of status is 
done and should be done as part of WG working on Domain Policies.

There is already substantial work with ADSP and APIs implemented and 
deployed. We continue to get world wide usage of our ADSP zone record 
generator wizard:

     http://www.winserver.com/public/wcadsp

Logs can provided upon request.  Commercial software exist that has it 
deployed -- Ours is one of them.

I would like a study done of all the entire scope of Domain Policy 
support whether its for DKIM, SPF or any other future message 
authentication/authorization protocol.

This will help to address and eliminate the huge redundancy and waste 
of at least 4-5 TXT record DNS calls for each mail transaction.  The 
IETF should review all the related mail protocols; SPF, DKIM, ADSP, 
extensions for ADSP such as ATPS and ASL, we have also VBR and now yet 
another one DMARC as one.

Yet, I don't think DMARC covers what was needed.  It fundamentally 
lacks addressing the #1 issue, #1 desire and #1 problem that plagued 
DKIM with SSP and ADSP -- 3rd party signer controls and policy support.

I am considering to re-introduce DSAP (DKIM Signature Authorization 
Protocol) I-D solution and proposed it to the IETF.

      http://tools.ietf.org/html/draft-santos-dkim-dsap-00

The DSAP protocol covers how to handle receiver actions and authorized 
3rd party signer concepts. It also expects any reputation layer to 
work together in integrated fashion.

--
HLS

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Sep 2013 08:18:54 -0400

> DMARC is meant to correct this.

There are ADSP implementations, deployments, APIs and wizards too!  It 
may not be within the exclusive club of an external trade, non-IETF 
group, but to suggest the investment has not be done, would not be 
correct.

The bottom line is that DMARC does not address 3rd party controls 
which was the central issue with DOMAIN POLICIES layers for DKIM.   It 
was for SSP, DSAP and made worst with ADSP when it intentionally and 
blindly removed 3rd party considerations from SSP and relabeled it 
ADSP.  It was added back in with ADSP 3rd party control extensions.

DMARC is mainly for reporting which does not solve the problem. It 
doesn't solve the main problem with protecting the copyright holding 
AUTHOR domain with DKIM signatures from 3rd party interference.

Until DMARC can prove to be a valued replacement, that truly resolves 
the 3rd party issue, ADSP should not be moved to historic. I am not 
going to invest money and time in DMARC research when we already have 
much effort done with ADSP. More importantly, DMARC is not a IETF 
network wide solution and the key authors are not going to allow 3rd 
party solutions to be augmented into it.   If that was the case, then 
we may have something to consider.  But until thing, we are in the 
same boat.

The IETF needs a thorough review of the entire concept of DOMAIN 
POLICIES via TXT records and the issue of 3rd party interference with 
security controls. Far too many TXT calls with little to no payoff 
value whatsoever and to add yet another DMARC TXT call exploration 
with absolutely NO payoff value, no added value, will be hard to take 
really serious.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Sep 2013 21:24:37 -0400

--
HLS

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 12 Sep 2013 07:59:57 -0700

> > make on either of the two lists here
>

+1

--Kurt Andersen

---

From: Steve Atkins <[email-masked]>
Date: Thu, 12 Sep 2013 08:50:47 -0700

+1

Cheers,
  Steve

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Sep 2013 12:20:17 -0700

This might be the right thing to do, but it seems like the more
appropriate time might be to do this when DMARC becomes standards-track.

I will note that vanilla, uncustomized SpamAssassin does implement ADSP,
so there might be more checking of ADSP records than some realize.  See,
for example:

 http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED

-Jim

P.S. I owe the DMARC folks a review of the DMARC spec, which I have
begun and already have quite a few questions.  I expect to complete this
within a week.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Sep 2013 12:28:34 -0700

> appropriate time might be to do this when DMARC becomes standards-track.

1. There is not going to be any change the adoption of ADSP between now 
and then.

2. I don't see any obvious reason for linking them.  The mere fact that 
they are playing in roughly the same sandbox does not provide any 
obvious requirement for fate-sharing that I can see.

3. IF DMARC is never standardized, it still makes sense to deprecate ADSP.

>   http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED

There seems to be a pattern that has developed, of demanding that 
failure mean literally no adoption.  It doesn't mean that.  It means 
that it has no community traction.  ADSP more than qualifies on the 
pragmatics of failure.

d/

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Sep 2013 13:02:44 -0700

> that it has no community traction.  ADSP more than qualifies on the

This was a response to your statement to Barry and Pete, "It has
garnered almost no deployment and use." If that comment was relevant, so
is a comment that there is, in fact, some deployment.

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Sep 2013 17:27:15 -0400

Addressing some technical issues here, and thanks for raising them.

On Thu, Sep 12, 2013 at 8:34 AM, Hector Santos <[email-masked]> wrote:
> -1
>
> This will require a substantial review before any change of status is done
> and should be done as part of WG working on Domain Policies.
>

There's no question that code is out there to process ADSP records.
I'm willing to have a conversation about this point, but: I don't
think that code in the field is what makes us decide that a standard
is now Historic, though RFC 2026 is vague on this point, saying only
this:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.

I think the points in this case are that (1) there's little or no
evidence that the standard is providing the benefit that it's meant to
provide, and (2) we have rough consensus that we no longer want to
recommend the specification as a current standard.  Part (2) is what I
assign to "for any other reason considered to be obsolete."

Therefore, discussion about whether (1) and (2) are true is fully
within scope here.

That said, I'd like to see arguments not that code to assess ADSP is
deployed, or even very widely deployed, but that the protocol is
providing benefits commensurate with keeping it as a current standard.
 Data that supports that view is welcome.

Barry, Applications AD

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Sep 2013 17:29:22 -0400

> that it has no community traction.  ADSP more than qualifies on the

The pragmatics of failure also can include implementations but see 
zero payoff in the field. Pure wasted redundant overhead in DNS calls 
and crypto processing is all that is highly measurable.

In our implementation, DKIM and VBR certainly fits in that category. 
Yet, we did it for its "marketing" value.  ADSP is also implemented 
and deployed.  The payoff measured is still another matter.

Even if ADSP domains have DKIM=DISCARDABLE, its been hard to add logic 
to reject or negatively classify failed DKIM messages.  Yet, you don't 
how sites local policies filters are done.  Sites and even users might 
just apply an ADSP DKIM=DISCARDABLE policy rejection to certain high 
value domains, like PAYPAL.COM but not others.

If Authentication-Results headers are used, what is done locally is a 
matter of local policy.  What is to say the same is not possible with 
DMARC with its p=reject action attribute?  I haven't seen any MUA show 
a different view yet, but I am sure there are some in the field.  Some 
have an icon or indicator but its not always profound.

We have the same issue with 3rd party signing problems with DMARC. 
ADSP has extensions such as TPA, ATPS and ASL that attempts to address 
authorized 3rd party signatures.  There is interest and deployments of 
these extensions.  DMARC will not attempt to address 3rd party 
signatures.  Whats to stop an DMARC extension to emerge which can 
piggy back off the _DMARC record?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Sep 2013 10:04:24 -0400

>   Data that supports that view is welcome.

Hi Barry, in all honesty I had difficulty trying to figure out why the 
burden should be on deployments to answer your question.

Are we asking if the proof of concept is still valid? Does it have a 
payoff, a useful utility?   We know all the answers was and still is 
yes. The issue has always been two folds:

First, how to leverage DKIM signatures in two layers:

   - Deterministic Domain Policy Layer to describe the practice
     of domain signing and the failure points for the operations.

   - For valid signatures, use a (futuristic) reputation
     (3rd Party Trust Service) concept to vouch for the
     signature and hence message.

Both, individually or integrated, has benefits commensurate with 
seeking a standard, so both were pursued.  DKIM has no reputation 
layer yet in wide practice but the modeling is being done. Thats still 
all in the air.  In the mean time, currently, DKIM only has a single 
protection layer and that is with ADSP (with also ATPS, ACL).

Second, the most critical issue was about how to apply and scale 3rd 
party DKIM signing controls for the larger systems.  ADSP stripped 
down SSP to remove 3rd party controls.  This was a unpopular move. The 
ADSP extensions ATPS, ASL and TPA helped correct this operational role 
by offering again 3rd party signature authorization policies for 
domains to use for help protect there DKIM signing investment.

Shouldn't the burden be on the proposer to provide an applicability 
and impact study how DKIM will be impacted by making ADSP obsolete and 
also replace it with an alternative?  This is about DKIM.

Why should all the IETF-MAN-YEARS be lost, require many of the DKIM 
related RFCs to be modified, updated also made obsolete where there is 
no apparent IETF alternative solution?

I guess I am not sure what you are looking for, if (significant) 
"running code" is not good enough any more.   This move will surely 
set a precedence to steer early adopters away from IETF proposals 
until it finally completed.  This will only allow the largest to 
dictate the direction of technology with lesser regard to the wider 
community of technology users.   It feels all wrong.

This feels nothing more to me as a competing solution being proposed 
with ADSP apparently in the way.  Thats not a better idea if it 
provided a better solution. It does not.  Same above two issues still 
apply; lack of DKIM protection and 3rd party controls.

Keep in mind that replacing ADSP with DMARC will be advocating a 
_DMARC migration path for ADSP.  If it does not, then this should mean 
to a greater extent an applicability and impact study should be done 
before pulling the rug from under ADSP publishers and receivers feet.

Thanks

-- 
HLS

---

From: SM <[email-masked]>
Date: Fri, 13 Sep 2013 10:55:08 -0700

>Date: Wed, 11 Sep 2013 16:09:14 -0700

[snip]

>Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

In my opinion RFC 5617 has not seen significant deployment.  There 
are instances where the signing practice is overridden by local 
considerations.  Based on that I don't think that it is worth pursing 
further standardization and move the RFC to Historic.

There is likely some clean-up work to do.  I haven't looked into the 
paperwork.  That may require a RFC.

Regards,
-sm

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2013 18:20:24 -0000

>paperwork.  That may require a RFC.

I don't think so.  We defined it as an entirely optional add-on to
DKIM, and there's no reference to it in RFC 6376.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Fri, 13 Sep 2013 22:27:05 -0400

> burden should be on deployments to answer your question.

That's a fair question.

There are a bunch of people saying that they are not seeing a benefit
from ADSP.  Those who are saying that include some large email
handlers and some high-profile phishing targets, so we have it from
both sides of the ADSP pond -- the ones trying to filter and the ones
trying to protect their domain identities.  They're all saying that
ADSP isn't doing it.

But when things aren't happening, it's difficult to come up with hard
numbers.  They could show us what ADSP isn't helping them block, but
we wouldn't know what else ADSP might be helping them block.

Given that, someone who says that ADSP *is* helping to block this
stuff... is the one who can provide evidence for that.  If we can see
some numbers showing what was blocked with the help of ADSP *that
would have gotten through without it*, we can consider that in
determining what benefit ADSP is providing.

That's the sort of thing I'm asking for: arguments, backed by whatever
evidence we have, that there *is* a benefit from having ADSP as a
standard, and that we should therefore not retire it.

In the rest of your note you talk about why ADSP is here: what it's
intended to accomplish.  We know that... but the discussion that's on
the table is that it's not accomplishing it.  Yes, you're right: ADSP
is what we have.  Where is the evidence that it's working?

As to IETF work lost, well, there are many IETF standards that have
not been successful, and that have withered and been, arguably, lost
work.  It happens.  We usually just leave them dead on the vine.  In
this case, we've seen real-Internet demonstrations that mis-applied
ADSP has caused real damage, in lost mail and screwed-up mailing
lists.  Officially making ADSP Historic will discourage domains from
publishing ADSP records, if there's no significant benefit from them,
but a demonstrated potential for damage.

Don't read from that that I'm supporting this move; I'm not supporting
either side of it.  It's my job to judge the result of the
conversation.  Provide some evidence of benefit, and it'll be
considered.  Who knows?: you might sway some who have already said
"+1" to making it Historic.

And I'll repeat: we're judging ADSP on its own here, not in comparison
with anything else that might have one more letter in its name.  If we
can see value in ADSP, that will matter, regardless of any
alternatives.  It's not a "competing solution" thing, so let's please
have no more of that.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Sep 2013 22:22:12 -0700

> trying to protect their domain identities.  They're all saying that

An important thing to consider, too, is the observation that ADSP actually
causes damage.  Consider its interaction with mailing lists, for example.
There hasn't been a workable solution provided to this problem, and the
damage also isn't theoretical.

If it has serious damage possibilities and no noteworthy uptake, it seems
unlikely to enjoy any sudden adoption even if there's ample code out there
that actually implements it.

OpenDKIM ships with ADSP support in both the library and the filter and has
since ADSP was in development.  I'm going to ask on our mailing lists
whether anyone's using it and seeing real benefit from it.  I'll report
back any useful replies.

-MSK

---

From: Martijn Grooten <[email-masked]>
Date: Sat, 14 Sep 2013 15:37:46 +0000 (UTC)

On Fri, 13 Sep 2013, Murray S. Kucherawy wrote:
> An important thing to consider, too, is the observation that ADSP 
> actually causes damage.  Consider its interaction with mailing lists, 
> for example.  There hasn't been a workable solution provided to this 
> problem, and the damage also isn't theoretical.

+1

And +1 therefore to the request to have RFC 5617 moved to history.

Martijn.

---

From: "John Levine" <[email-masked]>
Date: 14 Sep 2013 15:26:35 -0000

>whether anyone's using it and seeing real benefit from it.  I'll report

I see that there are still ADSP records for paypal.com and
paypal.co.uk, so you might start there.

On my own DNS server, I see a certain number of lookups for _adsp
records, but I also see some for _ssp and _policy, so I suspect
there's a lot of ancient software running on autopilot.

If anyone has contacts at the University of Pennsylvania, I see a few
_adsp lookups from DNS hosts at upenn.edu.

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Sep 2013 19:59:57 -0400

Hi Barry,

It is difficult to ignore the total picture, to separate the judgment 
and logistics of a DKIM investment with (ADSP) domain signing 
practices support, and the suggestion to either replace it or remove 
the general idea of protecting restrictive Domain Signing Practices 
from the DKIM framework.

However, I will try to outline a few key points for your consideration.

First, ADSP is not complete. This WG work item was intentionally 
pushed aside to allow DKIM to move forward.  DKIM was just recently 
made an IS and it is prudent for the IETF to determine if that 
endorsement included the basic premise and idea of Domain Signing 
Practice protocols along with other future considerations.  There are 
ADSP extensions which are getting interest and increase usage if only 
from a tracing standpoint -- which was a major goal.   This should 
indicate a WG review of the concepts to see if it can be completed 
now, as it was basically understood would eventually be done.  I was 
hoping the DKIM IS would be begin this process.

Second, ADSP or checking Domain Signing Practices (DSP) is a 
fundamental part of the DKIM Service Architecture as illustrated in 
RFC5585:

                     |
                     |- RFC5322 Message
                     V
      +--------------------------------+
      |  Message Signed?               |
      +-----+--------------------+-----+
            |yes                  |no
            |                     |
            |SDID/AUID            |AUID
            |                     |
            V                     |
      +-------------+ SDID/AUID   |
      |  Verify     +---------+   |
      |  Signature  |         |   |
      +------+------+         |   |
         pass|            fail|   |
             V                |   |
      +-------------+         |   |
      |    SDID     |         |   |
      | Assessments |         |   |
      |             |         V   V
      +-----+--+----+      +-------+
          |    |          / Check   \
          |    +--SDID-->/  Signing  \
          |             /   Practices \
          |            +-------+-------+
          |                    |
          V                    V

DKIM has one basic requirement for binding headers: the 5322.From 
header.  As much as it may be desired by Reputation framework 
advocates, we can not separate the question of how the Author Domain 
is strongly related to a signed messages or even the signer of the 
message.  We have no other anchor to work with. The signer id is still 
theoretical and only at the local white list level.

Third, ADSP is a major part of the RFC5863 DKIM Deployment Guide .  So 
overall, a consideration to end ADSP will need review of the entire 
DKIM process and usage in the market place.   What is it that didn't 
work?  What is the impact of relaxing the DKIM security threat entry 
points as highlighted in the threat analysis RFC4686?

Forth, the mailing list interop issue was reported by me. I proved it 
can happen once I saw the DKIM WG mailing list begin to "eat its own 
dog food" by (re)signing messages and I was exploring with these 
implementing and exploring these exclusive policy domains.  But the 
theory was well known and published in 2006. I wrote (in DSAP) about 
the need for MLS (Mail List Servers) or resigners in general who 
became DKIM compliant, the need to consider the security around 
restrictive ADSP domains:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DSAP operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DKIM signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

This MLS guideline was carried on in RFC6377 "DKIM and Mailing Lists" 
with the same insight. Our MLS package followed thru with this 
required MLS RESIGNER design considerations as you can see at this 
subscription site:

     http://www.winserver.com/public/code/html-subscribe?list=winserver

So another question is whether MLS made the required consideration to 
securing restrictive domains?  If no, why not?  I was aware back 
during the RFC6377 production that there were others MLS authors or 
developers who liked the idea.  It made sense.  As it was pointed out 
but unfortunately missed in the externally produced fast tracked 
RFC5863 deployment guide, this conflict had its genesis in RFC5863 
with its description of resigner operations and ADSP operations.  It 
didn't provide the insight regarding resigners needs to consider this 
policy signing controls.

In addition, DKIM+POLICY considerations also required that the more 
restrictive domains begin to clean up their usage of using private, 
corporate, high value domains in public.  Domains needed to understand 
of the DKIM "blind" resigners existence without controls to prevent 
interop issues.

There are three policies:

    DKIM=unknown
    DKIM=all
    DKIM=discardable

By far, unknown is found more than DKIM=all. DKIM=Discardable is being 
used only by exclusive private operations.  Its not designed for 
public usage which is obvious.

One confusion was with DKIM=ALL and whether it excluded 3rd party 
signers. It also had no actionable semantics. Only Discardable had 
actionable material.  DISCARD was the intent, but a REJECT was also 
possible and hence the MLS has to be consider of the REJECT as well.

Overall, one of the goals was to process and trace the results with 
Authentication-Results to hopefully gain better insight in writing MFA 
(Mail Filter Agents), if possible.

This was done and its still being done and this needs to be strongly 
considered.  MFAs will be developed at some point. We can not use the 
lack of actionable material as evidence of lack of usage or lack of 
utility.   Our package supports ADSP but out of the box it does not 
take action of failed DKIM messages.  However, it is documented of 
what an operator can do with their backend mail processing scripts.

It should be part of the research to see what we have learned from 
ADSP.  If we are going to pull the rug from under the feet of 
implementators and publishers, it can not be done blindly and 
inconsiderate of all the above and then some.  The suggestion that it 
can be replaced with DMARC does not eliminate all the above learned 
considerations.

Or are we in a more better position to also strongly and support 
inform MLS authors to follow DMARC policies now?

--
HLS

-- 
HLS