Subject: [ietf-dkim] ADSP stats

From: "John R. Levine" <[email-masked]>
Date: 16 Apr 2011 18:06:06 -0400

I crunched all the signed mail I've gotten since the beginning of 2010:

2010:
  135 adsp -> dkim=all
    5 adsp -> dkim=all;
    1 adsp -> dkim=all; t=s
   38 adsp -> dkim=discardable
  194 adsp -> dkim=unknown
    6 adsp -> dkim=unknown;
  223 adsp -> noerror
8020 adsp -> none

2011:
   59 adsp -> dkim=all
    5 adsp -> dkim=all; t=s
   11 adsp -> dkim=all;t=s
    5 adsp -> dkim=discardable
   22 adsp -> dkim=unknown
   21 adsp -> noerror
2649 adsp -> none

"noerror" is mostly Yahoo, which has CNAMEs but no ADSP record.  All 
of the dkim=discardable is Paypal.  Nearly all of the dkim=all was small 
personal domains; the only large one I saw was paypal-inc.com.

orbitz.com and cert.org publish dkim=unknown

I also got about a dozen SPF and Sender-ID records, likely from 
ill-advised wildcards.

So in my limited dataset, ADSP usage is if anything shrinking, with only 
Paypal publishing discardable.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 Apr 2011 00:52:29 -0400

> Paypal publishing discardable.

hmmmmmmmmmm

John, you do realize its only April? 1/4 of 2011?

According to your stats:

    2649*4 = 10,596

There will be an extrapolated increase of 2576 by the end of year.

The more valuable data point of interest is the total unique domains, 
not how many messages.

Nonetheless, you are exhibiting a personal community network 
statistics and everyone's personal community network patterns are 
different.

Microsoft hotmail.com has now started to check for ADSP senders. 
Their stats will show a significant increase of senders adding 
DKIM+ADSP support to better reach hotmail.com users.  Hopefully they 
will soon begin to do something you didn't do - Promote DKIM and ADSP. 
    If you want ADSP to increase, you need to support it, champion it. 
Something most creators do - be the #1 User and Champion of their own 
work.

Love/hate them, Microsoft is still a market leader.  Ignore ADSP at 
your own peril.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 Apr 2011 01:25:32 -0400

> John, you do realize its only April? 1/4 of 2011?

Sorry. Wrong data comparison.

Lets correct the extrapolation using your active ADSP domain recordings.

2011: 135+5+1+38+194+6    = 379 ADSP records for 365 days
2010: 59+5+11+5+22        = 102 ADSP records for 107 days

Linear extrapolation

   102/107 days  =  x/ 365 days

Solve for x:

  x = 102*365/107 = 347

So yes, for your personal community a slight decrease, but nothing to 
base anything on.  Promote ADSP more and we should see  increase adoption.

The real interest is the total unique domains and also the changes, 
i.e. how many of the 2010 ADSP = NONE  domains have adopted ADSP in 
2011. That will give you a better adoption rate.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 Apr 2011 02:08:31 -0400

> 2011. That will give you a better adoption rate.

Some other things to consider John.

DNS ADSP domain adoption rate is just one side. What is also important 
is the DKIM verifier Enabling ADSP checking Adoption Rate.

One fact is true:  Of the two popular open source DKIM API packages, 
both support ADSP and are ready to go.

How implementators of these APIs have enabled ADSP checking, we don't 
know.

I believe Murry indicated last year OpenDKIM has ADSP checking is OFF 
out of the box. Maybe it is enabled now for his statistics work. We 
use ALT-N's LIBDKIM API and we have ADSP checking enabled out of the box.

With RFC5016 (Requirements for a DKIM Signing Practices Protocol) and 
the work done in RFC4686 (Analysis of Threats Motivating DKIM), there 
was consensus ADSP checking make sense under two conditions:

       1st party failures
       3rd party signatures (valid or not)

There was a majority consensus (if not 100%), the valid 1st party 
signatures did not require ADSP checking because the only reasonable 
threat is an internal compromise (theft of private key).  ADSP can 
only help to deal with violations (faults) of policy declarations:

    What to do about 1st party failures
    What to do about unauthorized 3rd party signature

Maybe one interest data point would be to collect ADSP DNS queries. 
That will give a snapshot of how many DKIM verifiers are checking for 
ADSP.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Apr 2011 01:50:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Saturday, April 16, 2011 3:06 PM
> To: DKIM List
> Subject: [ietf-dkim] ADSP stats
> 
> [...]

I seem to recall sending this out, but maybe it wasn't to this list because I can't find it in my "ietf-dkim" mailbox.  Apologies if this is a duplicate.

Here's what OpenDKIM has for ADSP statistics.  To set context, OpenDKIM always checks ADSP when there's no valid author domain signature, but doesn't act on it by default.  That means if someone posts an ADSP policy and there was a valid author signature, it won't be included in the numbers marked [*] because we don't do the query in that case.

	Messages reported: 13.3M since August 30, 2010
	Distinct From: domains observed: 490276
	Domains for which an ADSP query returned anything at all [*]: 71460 (14.6%)
	Domains for which an ADSP of "unknown" was found [*]: 313 (0.06%)
	Domains for which an ADSP of "all" was found [*]: 272 (0.05%)
	Domains for which an ADSP of "discardable" was found [*]: 42 (0.009%)

Of those 42 discardable ones, 13 were PayPal variants.  Interestingly, SwissCom was another.

You can tell from this that the vast majority of what our ADSP queries hit is wildcard TXT records referencing something other than an ADSP record (probably SPF).

I can break it down by month if anyone's interested in trend data, but the numbers are so small in the first place that I doubt it'd be very interesting.

So we can't tell how widely ADSP has been deployed because we don't check in the positive case, but we can see how it looks in the negative case: It's successfully "protecting" 0.13% of the domains out there.

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Apr 2011 09:00:17 -0400

> I can break it down by month if anyone's interested in trend 
> data, but the numbers are so small in the first place that I 
> doubt it'd be very interesting.
> 
> So we can't tell how widely ADSP has been deployed because we 
> don't check in the positive case, but we can see how it looks 
> in the negative case: It's successfully "protecting" 0.13% of 
> the domains out there.

Which is still higher than how SPF started out, yet, SPF took off due 
to its high promotion. Since there is no promotion of ADSP, watered 
down, and it was made harder to deal with 3rd party scenarios, with 
the refusal to make the necessary corrections, IMV, the exploration 
has becomes questionable and limited.  We have to promote it if we 
want to properly measure its adoption.

Data collection is always useful, but it generally doesn't tell the 
real story across the board because everyone's personal/business 
community network are different. You have to show a statistic analysis 
because the majority non usage reasons are untold and does not 
necessarily takes away the benefits and the well established proof of 
concept and realistic payoff possible. It is very well proven to be 
useful for those who have these stronger signature needs.

Interestingly, what would be an adoption percentage before it is taken 
serious?

Adoption is really three parts:

  1 [X] Verifier ADSP Implementation Readiness
  2 [_] Verifier ADSP Deployment (checking) Readiness
  3 [_] Domain ADSP declarations

Looking at just current APIs, it is 100% adoption. The current APIs 
readiness is due to when policy was still a strong focus starting with 
SSP and they were updated to support ADSP.  The harm of removing 
policy semantics in RFC4871bis is that we will begin to lose this 
implementation readiness.  Not having any ADID Policy Identity 
Assessor insights dangers future implementations from having this 
readiness.

Deployment Readiness is whether the operators have ADSP checking 
enabled. Because of the short term DNS low efficacy factors, it is a 
high consideration to have it disabled by default. That could change 
as Domain ADSP declarations increased.  But we don't know how 
different implementators have made it available.  Of course, this will 
be an non-issue when implementators stop coding for it or never code 
for it and don't offer it at all - the danger of removing the 
semantics in RFC4871.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Apr 2011 12:33:05 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Monday, April 18, 2011 6:00 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] ADSP stats
> 

I don't get the feeling that there's enthusiasm promoting ADSP because of its problems.  I think a lot of the things we had in mind for ADSP and its antecedents came at too high a price in the end, which is why it was "watered down". 

This working group spent a huge amount of blood, sweat and tears working on attempts to create a viable policy layer, and after all that, ADSP is what we managed to get consensus to do.  Lots of other alternatives have been proposed, and none of them have stuck either, and their various authors (including me) haven't persisted.

If ADSP is too weak or dangerous a protocol, and there are no current viable alternatives, then failing to beat the streets to get the industry to deploy it is an act of responsibility, not one of omission or laziness.

We tried policy, and couldn't make it work.  It's time to spend all this energy looking at something else.

---

From: "John R. Levine" <[email-masked]>
Date: 18 Apr 2011 16:53:10 -0400

> We tried policy, and couldn't make it work.  It's time to spend all this energy looking at something else.

To be more specific, we tried self-assertions of policy, which don't work.

We haven't done anything with credible third party assertions other than 
DNSBLs ("their policy is to send spam") and some ad-hoc things (eg, in a 
Spamassassin config, "paypal.com signs everything").  Those seem to me to 
be a plausible area for work.  But they're definitely not ADSP.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Apr 2011 13:23:15 -0700

> If ADSP is too weak or dangerous a protocol, and there are no current viable alternatives, then failing to beat the streets to get the industry to deploy it is an act of responsibility, not one of…

My feeling is that it conflicts with too many (would-be) industry third parties' self interest in
selling reputation/policy, and hence why the FUD bullhorn was on full blast through the entire
exercise, and remains on to this day. If DKIM itself were given the same treatment, we'd be looking
at the same sorry stats for it. That vested interests don't like something isn't an indication of
absolute worth, it's just an indication of its worth with respect to their perceived bottom line.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Apr 2011 15:37:08 -0700

> We tried policy, and couldn't make it work.  It's time to spend all this energy looking at something else.
With upcoming changes in the Internet architecture, many protocols 
including SMTP that exist within the commons, will need to revisit a 
basis for acceptance that does not over burden receivers.  It seems 
elements related to DKIM and SMTP can be more closely bound.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Apr 2011 19:15:31 -0400

Murray S. Kucherawy wrote:

> We tried policy, and couldn't make it work.  It's time to 
> spend all this energy looking at something else.

Murray, I appreciate your assessment.

The writing was on the wall when you have an opponent of policy become 
the author of ADSP, broken by erroneous removing all 3rd party 
semantics believe that be enough the separate mail system DKIM 
integration - a flaw that drove WG conflicts. There was a conflict of 
interest and even then, everyone made suggestions to correct it. But 
there was no interest by the editor. No one wishes to say that but 
making it work was impossible. A simple change of character would of 
made all the difference.

As a vendor who has strategic interest in offering DKIM trust related 
eCommerce services and product features for other host to start their 
own services, I can accept the design to exclude policy because it 
marginalizes a 3rd party trust model. It will lower incentives to buy 
into the independent trust assessment service market. I can understand 
that, and if that where we want to go, fine. I accept that.  No need 
to hide the reality.

Bu there are engineering confusion, inconsistencies, marketing and PR 
issues.

First, people reading the Deployment Guide document includes ADSP in 
its introduction, discussed in 6.1 and has an entire 7.3 section 
devoted to it.  And when people read the security document, they will 
read how policy can help
secure against DKIM threats.

So any good implementator will take all the documents into account.

And yet, the energy continues with DKIM+ADSP feedbacks work and now we 
have a DKIM-BASE that intentionally neglects any promotion in any 
shape or form concepts and insights regarding policy with existing 
Deployment and Security guidelines or any flexibility to explore further.

 From the beginning, the single main issue has always been about 
controlling unrestricted 3rd  party signer.   No one disputed the need 
for value of trusted 3rd party signers, especially for the trust 
business model.  The problem is that its viewed as mutually exclusive 
from policy, when in fact, the two are necessary co-existing layers. 
Policy helps the trust model, and trust helps policy because policy 
can not deal with good looking bad guys.

DKIM needs both to be successful.  Again, I understand the reasons to 
exclude it, and its not about lack of technical merits.  I'm proposed 
a simple compromise with two words that will not marginalized the 
trust market, but help it, help the marketing, help the PR problems.

Also, remember, DKIM has a term tagged to it regarding 
"Responsibility" so by keeping ADSP in the Deployment Guide and 
Security Documents, there are product liability concerns.  While 
High-value targets may not add ADSP records themselves, but they might 
need to check for it because intentional neglect is a realistic risk. 
Having it is not a problem because it also serves as an disclaimer.

History tells us that ignorance is the root of all conflicts. So why 
try to ignore and hide it in RFC4871bis?

But if we really think it won't work, then we should at least try to 
be consistent and clean up all DKIM related ADSP deployment and 
security guidelines - the RFCs need to be updated and it wouldn't make 
sense to continue related work with ADSP reporting.  Or can be done 
right and add a few words regarding its presence.

Microsoft has announced support for ADSP checking.  This is an very 
significant event. This should not be ignored.

Anyway, sure, a lot of wasted energy is here. But it pretty much based 
on your key cogs conviction. If you believe "authorized signer" is an 
natural identity for DKIM, then you should propose it and see hows it 
goes.  Maybe the policy people can come out for wood works.

-- 
HLS

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 19 Apr 2011 13:08:26 -0700

On Apr 18, 2011, at 1:23 PM, Michael Thomas wrote:

> exercise, and remains on to this day.

Could you provide some evidence of reputation/policy vendors spreading FUD about ADSP?  Press releases, blog posts, even links to mailing list archives.

It's possible that it happened, but if so I'd really like to know who was doing it.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: <[email-masked]>
Date: Tue, 19 Apr 2011 16:56:13 -0400

In my mind the whole adsp degenerated into a use case only for well recognized narrowband senders such as banks. Had nothing to do with reputation sellers, and judging by a recent exit from the market a reputation is only as good as it is maintained
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of J.D. Falk [[email-masked]]
Sent: Tuesday, April 19, 2011 4:08 PM
To: DKIM List
Subject: Re: [ietf-dkim] ADSP stats

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Apr 2011 21:03:01 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, April 19, 2011 1:56 PM
> To: [email-masked]; [email-masked]
> In my mind the whole adsp degenerated into a use case only for well
> recognized narrowband senders such as banks. Had nothing to do with
> reputation sellers, and judging by a recent exit from the market a
> reputation is only as good as it is maintained.

That's my recollection as well.  I never saw any concerted or even accidental attempt to block, prevent, quash, overthrow or otherwise prevent policy work from being done.  I believe the original policy work was a victim of the fact that it's very hard to get such things right in this operational environment, and there was insufficient operational evidence to support some of the original proposals.  Ultimately, we simply couldn't reach consensus on the rich solutions people wanted.  That's very different from the conspiracy theories that have been alleged by a few ever since.

I also can't see the current language as endorsing any particular layer on top of DKIM.  Indeed, we've published an RFC that presents a (limited) policy solution, but have deliberately avoided doing any work on reputation at all.  That seems to counter to what's being alleged here.

Finally, I'm a little tired of the notion that if a particular pet solution isn't the one that reached rough consensus, then the only possibility is that there's malice afoot.  The occasional incivility didn't help, but that's not the same thing as impropriety.  There are other possibilities one might consider as the reason something didn't make it into the RFCs.

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Apr 2011 03:07:35 -0400

Murray S. Kucherawy wrote:

>> Bill Oxley:

> That's my recollection as well.  I never saw any concerted 
> or even accidental attempt to block, prevent, quash, 
> overthrow or otherwise prevent policy work from being done.

Its hard to not see the gradual removal of all semantics, insights, 
words related to policy and the refusal to consider the natural 
identity "authorized signer" as anything but a concerted efforts to 
marginalized it and reduce incentive to support it. Otherwise, what is 
the reasoning for for the genocide of the "authorized signer" concept 
in  DKIM?

When there is a desire to have a (reasonable) unrestricted 3rd party 
signer model to work, then you to need to technically eliminate author 
domain rights to restrict it.  ADSP represented that concerted effort. 
  It was not done in the blind.

Is that evil?  No, but it needs to be explained.

> I believe the original policy work was a victim of the fact 
> that it's very hard to get such things right in this 
> operational environment, and there was insufficient 
> operational evidence to support some of the original 
> proposals.  

The same can be said for a trust only model.  Where is the operational 
payoff evidence? It is very hard to make it work with a high 
dependency and risk for an yet to emerge wide trust market place.  It 
can also be said, like ADSP,  trust is a very narrow because it can 
only work today in isolated scenarios between sites with common trust 
information.  ADSP had a consistent result model for all verifiers. 
Trust does not.  Trust is a long term idealized model where 
centralization information is required in order to have consistency in 
results.

> Ultimately, we simply couldn't reach consensus 
> on the rich solutions people wanted.  

Murray, since day one, since SSP, hell, since MARID, the lack of 
consensus was how to deal with anonymous unknown 3rd party trust 
assertions.  For DKIM, we couldn't agree of a DNS solution because it 
had to COVER all scenarios, even for the largest.

But the conflict came with ADSP excluding the basic idea for the 
allowance of a 3rd party signer. So even if we didn't have a feasible 
solution to to explicitly authorized 3rd party signers, we lost the 
ability to make DKIM operationally consistent with 3rd parties with a 
basic author domain policy declaration:

            "MY MAIL IS ALWAYS SIGN BY ANYONE"

I don't think it is fair to use lack of consensus because ADSP threw 
out the WG consensus built RFC4686 security concerns and we didn't 
have an opportunity to properly vote to void the WG Consensus Built 
security concerns.  Instead, it was flipped.  We were force to prove 
again why 3rd party policies are necessary.   It was a guarantee 
scenario for failure.  Yet when the ADSP broken part solutions was 
proposed (can DKIM=ALL be used to allow the above policy), the 
document author had no interest to solve it nor remove it from its 
status broken mode, no consensus quo.

> I also can't see the current language as endorsing any 
> particular layer on top of DKIM.  Indeed, we've published an 
> RFC that presents a (limited) policy solution, but have 
> deliberately avoided doing any work on reputation at all.  
> That seems to counter to what's being alleged here.

Section 2.5 and section 2.7 specifically describes a layered model for 
an independent trust assessment service module using an mandatory SDID 
authenticated output.  Isn't that whats written and desired?

A fresh reader of DKIM-BASE would conclude there is only one layer 
model and not conclude there is an well considered security based 
policy assessment model possible.

Finally, please consider that whoever selects a SDID to sign a 
message, whether its a 1s party author domain, 3rd party delegated or 
not, or MLM list operator, there are all still an authorized signer 
selection concept.  A verifier using an SDID for trust assessment 
comes with an inherent operational presumption for an authorized 
signer selection and certainly not believed to be an unauthorized 
signer selection.  From a functional standpoint, by making it harder 
in ADSP to have the simple declaration "always signed by anyone"  we 
make it harder for the 3rd parties to fit well, even trusted ones. And 
in my view, from an IETF protocol standpoint by intentionally removing 
all ideas for a natural protocol identity concept in DKIM to exist, 
well, that doesn't seem IETF Kolser and doesn't play well with the 
IETF idea to lead the way for flexibility and not get locked into a 
controversial "batteries required" method.

-- 
HLS

---

From: <[email-masked]>
Date: Wed, 20 Apr 2011 07:36:34 -0400

Indeed lack of support for 3rd party signers was where I gave up any interest at all in adsp 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Wednesday, April 20, 2011 3:08 AM
To: [email-masked]
Subject: Re: [ietf-dkim] ADSP stats

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 20 Apr 2011 13:40:06 -0400

What we were able to get consensus on was too limited and too crude in
terms of policy assertions. I would not attribute this to ill intent.

This is one of the reasons I have been supportive of 3rd party
intermediaries even though my natural inclination would have been the
standards route. There will be other efforts involving policy surfacing
and I will be supportive to the extent I think they make sense.

Mike

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, April 20, 2011 7:37 AM
> To: [email-masked]; [email-masked]
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Hector Santos

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 20 Apr 2011 13:25:08 -0700

> Indeed lack of support for 3rd party signers was where I gave up any interest at all in adsp 

As I remember it, there was (or appeared to be) consensus to get ADSP out there for testing by the entities it might work for, AND simultaneously work on something for the 3rd party scenarios.

What ever happened to that work? I know there were a couple of drafts, and Murray added support for one to OpenDKIM...if the 3rd party stuff is really that important, why isn't anyone using it?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Apr 2011 13:29:08 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Wednesday, April 20, 2011 1:25 PM
> As I remember it, there was (or appeared to be) consensus to get ADSP
> out there for testing by the entities it might work for, AND
> simultaneously work on something for the 3rd party scenarios.
> 
> What ever happened to that work? I know there were a couple of drafts,
> and Murray added support for one to OpenDKIM...if the 3rd party stuff
> is really that important, why isn't anyone using it?

Indeed, I asked this question at a couple of industry trade groups I attend, MAAWG being one of them.  The answer I generally get is that the key delegation already supported by DKIM works just fine, so why do we need some other mechanism that hits the DNS yet again and employs some complex policy expression language?

There has been no uptake at all in OpenDKIM for ATPS, and almost none is apparent with ADSP, although in the latter case our data can only give a range for adoption because we don't query when an author signature passes.  I could tighten that down by running five figures worth of TXT queries if we really feel the need to be more accurate.

I don't know of any public implementations of the other schemes.

---

From: "John R. Levine" <[email-masked]>
Date: 20 Apr 2011 16:49:37 -0400

> I don't know of any public implementations of the other schemes.

Well, there's vouch-by-reference, third party assertions that a signing 
domain is good.  It has a few implementatons but it hasn't been a barn 
burner either.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Apr 2011 13:51:21 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2011 1:50 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

The industry is still awaiting its silver bullet, I suspect.

(OpenDKIM also implemented VBR.)

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 Apr 2011 13:59:06 -0700

> (OpenDKIM also implemented VBR.)

This almost makes one think that the need is for compelling data, not just a 
spiffy mechanism for accessing it...

The term "value proposition" is markedly irritating, in this regard...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Apr 2011 14:40:09 -0700

On 4/20/11 1:25 PM, J.D. Falk wrote:
> On Apr 20, 2011, at 4:36,<[email-masked]>  wrote:
There is still a need for this type of work to improve upon DKIM 
acceptance when signatures are damaged for various "innocent" reasons.  
It seems appropriate to first determine the output of DANE and how IPv6 
acceptance might be handled.  IMHO, IPv6 acceptance needs practical SMTP 
sender validation methods.  Once in place, providing a policy layer upon 
what has been embraced as a practical acceptance mechanism for SMTP 
senders could easily be extended to include third-party issues with 
DKIM.  For example, this policy layer may be needed to deal with variant 
IDN bundles.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Apr 2011 14:50:22 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, April 20, 2011 2:40 PM

I don't see how DKIM and DANE occupy related spaces.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Apr 2011 15:14:24 -0700

On 4/20/11 2:50 PM, Murray S. Kucherawy wrote:
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Douglas Otis
They don't.  However, making third-party exceptions is better done in 
conjunction with a scheme that lacks replay by undefined entities.  Such 
a mechanism is also necessary to support domain reputations and perhaps 
even IPv6 acceptance.

IMHO, DKIM represents an anti-phishing mechanism.  As such, it is 
important for DKIM to be earnest in ensuring valid signatures preclude 
obvious spoofing techniques.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Apr 2011 16:01:15 -0700

On 04/20/2011 01:29 PM, Murray S. Kucherawy wrote:
> There has been no uptake at all in OpenDKIM for ATPS, and almost none is apparent with ADSP, although in the latter case our data can only give a range for adoption because we don't query when an author signature passes.
>    

That isn't a helpful metric. The 99% most likely domains to
have a ADSP record are ones where you see DKIM signatures
and they pass. So if you're only checking domains without
DKIM signatures (broken or otherwise), you're going to get
a self fulfilling prophecy.

A much better test would be compile a list of DKIM signing
domains, and do the ADSP query on them.

Mike, not that i think it's going to be terribly high either
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Apr 2011 16:13:39 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2011 4:01 PM
> To: Murray S. Kucherawy

Yeah, that's what I meant when I referred to doing five figures worth of TXT queries.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Apr 2011 16:18:56 -0700

> Yeah, that's what I meant when I referred to doing five figures worth of TXT queries.

I think it would be worth it, since the numbers are almost
certainly going to be better, even if they're not great. There's
nothing worse than a stat-as-meme that originate from highly
flawed studies.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 20 Apr 2011 20:01:21 -0400

> domains, and do the ADSP query on them.

That's what I did.  The only ADSP I see this year is Paypal.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 20 Apr 2011 20:50:58 -0400

> That's what I did.  The only ADSP I see this year is Paypal.

That's a success story of a sort.  We know that ADSP is only potentially 
useful in a narrow set of circumstances.  Data that indicates the protocol 
isn't being widely deployed for domains for which is not suited is good news.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2011 03:26:44 -0000

>That's a success story of a sort.  We know that ADSP is only
>potentially useful in a narrow set of circumstances.  Data that
>indicates the protocol isn't being widely deployed for domains for
>which is not suited is good news.

Along those lines, I hope it enjoys the same robust success as GOSIP.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 Apr 2011 00:08:37 -0400

> I don't know of any public implementations of the other schemes.

Because of my continued skepticism to "flip the DKIM switch" on our 
general customer base, our wcDKIM add-on implementation has been 
isolated to selected testers and for those customers who had requested 
supported.

ADSP and the extensions ATPS v1 and ACL are supported out of the box 
and all testers and customers using it have ATPS records with ACL and 
ATPS extensions enabled, and its works.  It works VERY well to to 
declare more than one authorized signer.

A Web-based Wizard was completed to help with the generation of the 
ADSP records, and it comes with a SIMULATOR:

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

For my own records, I included mipassoc.org as an authorized signer of 
my list membership.

Do an ADSP look up for ISDG.NET and you see the atps and acl tags:

   nslookup -query=txt _adsp._domainkey.isdg.net

    "dkim=all; atps=y;
         asl=santronics.com,isdg.net,
             winserver.com,megabytecoffee.com,
             mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;"

and if you use the wizard for ISDG.NET using mipassoc.org as an 
authorized signer, to generate the ATPS record, you will see that 
exposure in DNS.

nslookup -query=txt N3LSEHML2WGBFXOV7HSAK2QZSUBSEFHB._atps.isdg.net

     "v=atps01; d=mipassoc.org;"

So the implementation is there and again it works really great. Here 
is the Authentication-Results header for my isdg.net submissions to 
the IETF-DKIM list when our receiver gets a list mipassoc.org signed copy:

  Authentication-Results: dkim.winserver.com;
    dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
    adsp=pass policy=all author.d=isdg.net asl.d=mipassoc.org;

And if OPENKIM was checking and recording it, it SHOULD produce the 
same result.

Once we officially release our new update, while I still on the fence 
to expose our customers to negative domain DKIM branding for a 
non-existent TRUST Database world,  odds are good I will let the beast 
go.

But I can change my mind as I still have no confidence DKIM by itself 
is good for our general customer base who will follow our lead, what 
we do as a good thing.  So its not just about ADSP, DKIM itself has a 
serious deployment dilemma with little to no payoff and a high risk of 
unsolicited 3rd party signers weighting down domain branding.

However, it is ADSP whether its an illusion or not, that currently 
provides marketing reasons to answer the question how DKIM signing can 
help.  I can't just say "Batteries are required" to find an 
independent Trust Assessment Service.  The last time we did that with 
an implementing of a new technology, serious PR problems developed 
when an intermediary 3rd party broker exited its new business model 
venture.

Overall, this is all about promotion. What you promote in this Product 
R&D endeavor. Don't promote ADSP, it doesn't go anywhere as fast as 
one may wish.  Yet, there has been long time evidence by many 
companies who stated they were waiting the Proposed standard to be 
finished. These are companies who are sending sensitive vendor/user 
messages and they are not signed by DKIM.  It makes you wonder why 
not, ask them privately outside this WG and you may be surprise.

When you see the reputation push, when you have no leading champion 
supporting it, advocating not to use it, of course, you are not going 
to get wider acceptance.  Its as simple at that.

At this moment, you are the DKIM technology market leader. It is up to 
you as a PRODUCT R&D engineer if you want to see ADSP used, tested and 
explored among your OPENDKIM customer base.

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 Apr 2011 00:27:49 -0400

> potentially useful in a narrow set of circumstances.  Data 
> that indicates the protocol isn't being widely deployed for 
> domains for which is not suited is good news.

What is more significant is Microsoft Hotmail.com (and I take it 
live.com) supporting ADSP checking. I suspect more domains will add 
ADSP records to "better access" hotmail, live users.

Also, paypal.com knows what its doing.  Whether or not, ADSP is liked 
or not, their ADSP record is a LEGAL DISCLAIMER.  It can be used as 
evidence for defense or counter-suits against any harm claims.  Any 
host who *intentional neglects* to use ADSP, is putting the hosting 
company at risk.

Any product engineer DKIM rep here should do themselves (and company) 
a great favor to talk to their chief counsel about DKIM claims of 
"responsibility" product liabilities risk and specifically about ADSP 
and the decision to intentionally not support it, especially on 
intentionally deciding not to check for 3rd party signed author domain 
policy records.

Silly or not, those are the fact lawyers look for.

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 Apr 2011 05:55:28 -0400

Murray S. Kucherawy wrote:

> There has been no uptake at all in OpenDKIM for ATPS, and almost 
> none is apparent with ADSP, although in the latter case our data 
> can only give a range for adoption because we don't query when an 
> author signature passes.  I could tighten that down by running 
> five figures worth of TXT queries if we really feel the need to 
> be more accurate.

Why not run a series of test where every AUID is looked up?

But if you wish to be more selective, the measures need to show the 
value of the DKIM declarations or lack there of and how policy 
semantics can be used as an expectation failure. In other words, the 
proof of concept.  How you fold them depends on how you to break down 
the types of violations.

IMV, there are three types of security concerns:

      Legacy Domain Mail Abuse
      DKIM Adaptation: 1st party signer abuse (facsimiles)
      DKIM Adaptation: 3rd party signer abuse

The #1 benefit of DKIM is its potential to immediately impact the 
legacy domain mail abuse problem.  It addresses the non-DKIM aware 
abusers of domain existing today.  So measuring messages with no 
DKIM-Signature is very useful.

Then you have the adaptation of DKIM abusers and there are two 
potential related "Cry Wolf" exploits:

     Those trying use 1st party unhandled failure
     Those trying use valid 3rd party signers

The first one tries to leverage the uncertainty of DKIM and the second 
one tries to water down trust using unrecognized signers that are 
displayed to used even if it just says "Signed by: trustme.com"

The hard part of any measures is the exclusivity value of one method 
over another.  So its not just about measuring how many domains are 
using ADSP, but showing the proof of concept in how can DKIM can help 
domains by analyzing your statistics.

For example, DNSRBL rejections may be 30%.  What if we turned that 
off? Could we get the 30% back using DKIM/ADSP?  Greylisting does 66% 
on our system.  Can DKIM/ADSP cover that if Greylisting was disabled? 
  Same with SPF and so on.

For many system, it is hard to turn off the filters just to get a DKIM 
impact measurement and the odds are very good by the time the payload 
is accepted, its already good mail or indeterminate.

But if you just want to a grand total of all the domains collected, 
just do an initial ADSP for all of them up front.   That will allow 
you to break it down including asking NON-ADSP what if questions.  For 
example,

    30% are 3rd party signatures.
       How many of these are recognized good guy signers?
       How many of these are unrecognized signers?

That measurement can start with a text list file of industry trust 
vendors and other eye balled well known trusted 3rd party and/or list 
domains.

Another measurement might be how many of the AUID are signed by 
different SDIDs?  One AUID has messages always signed by one SDID 
versus another AUID with messages signed by many different SDID.  Is 
there any significant to that?  Could that show how as exploited AUID 
can use ADSP to protect against multiple SDID signing exploits?

---

From: Paul Midgen <[email-masked]>
Date: Wed, 27 Apr 2011 17:20:33 +0000

I wanted to address Hotmail's use of ADSP, clarify our position on the issue of authentication policy, and share a few bits of information the list may find interesting.

Hotmail's use of DKIM+ADSP should not be interpreted as a political statement; we implemented DKIM to offset the impact of well-known SPF false-failure scenarios. We viewed DKIM+ADSP as a package deal and a first step to fully integrating authentication policy controls into our delivery pipeline.

In fact, we're still experimenting with the two standards in a phased rollout. For purely operational reasons the initial phase restricted DKIM validation to messages failing SPF, and we further restricted signature selection to author domain signatures.

SPF fails for ~1.5% of our inbound traffic, so that's the percentage of mail for which we currently run DKIM. The next phase of our DKIM project begins soon and will expand DKIM's "scope" to all non-passing SPF results, or ~49% of total inbound volume.

We check ADSP every time we run DKIM and see the following policy distribution:

97.98% "unknown" (including domains not explicitly publishing policy)
2% "discardable"
0.02% "all"

We'll continue to evaluate ADSP's utility as we increase the DKIM validation rate, though our research suggests the current policy distribution won't profoundly change.

Moving forward, we fully support the creation of a mechanism for deterministic authentication-based sender-published message disposition policy as well as the feedback loop(s) necessary to help senders overcome their reluctance to deploy aggressive policies.

While we believe our authentication policy controls will initially consume policy from intermediaries, we've designed them to use DNS-based policy should a broadly-acceptable standard emerge. We're taking the long view and betting that such a standard is possible, and are looking forward to being part of creating it.

-p

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Wednesday, April 20, 2011 5:51 PM
To: [email-masked]
Subject: Re: [ietf-dkim] ADSP stats

On Wednesday, April 20, 2011 08:01:21 PM John R. Levine wrote:
> > A much better test would be compile a list of DKIM signing domains, 
> > and do the ADSP query on them.
> 

That's a success story of a sort.  We know that ADSP is only potentially useful in a narrow set of circumstances.  Data that indicates the protocol isn't being widely deployed for domains for which is not suited is good news.

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 11:01:00 -0700

On 4/27/2011 10:20 AM, Paul Midgen wrote:\
> 97.98% "unknown" (including domains not explicitly publishing policy)

Paul,

Cool.  Thanks for sending that detailed note.

Are the percentages for total message traffic or are they for distinct From: 
domain names?  I assume the former, but the latter might be significant too.

The distinction could be useful because of how skewed the distribution of volume 
is, given the smaller number of very large senders.

d/
-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 27 Apr 2011 14:56:53 -0400

Paul, 

Thank you for sharing what you have. Comments/questions inline.

Mike

> [email-masked]] On Behalf Of Paul Midgen
> Sent: Wednesday, April 27, 2011 1:21 PM
> To: Scott Kitterman; [email-masked]
> I wanted to address Hotmail's use of ADSP, clarify our position on the
> issue of authentication policy, and share a few bits of information
the
> list may find interesting.
> 
> Hotmail's use of DKIM+ADSP should not be interpreted as a political
> statement; we implemented DKIM to offset the impact of well-known SPF
> false-failure scenarios. We viewed DKIM+ADSP as a package deal and a
> first step to fully integrating authentication policy controls into
our
> delivery pipeline.
> 
> In fact, we're still experimenting with the two standards in a phased
> rollout. For purely operational reasons the initial phase restricted
> DKIM validation to messages failing SPF, and we further restricted
> signature selection to author domain signatures.
> 
> SPF fails for ~1.5% of our inbound traffic, so that's the percentage
of
> mail for which we currently run DKIM. The next phase of our DKIM
> project begins soon and will expand DKIM's "scope" to all non-passing
> SPF results, or ~49% of total inbound volume.
> 

The 2% "discardable" is interesting. Is that percentage of volume or
percentage of domains evaluated? Also, is there anything noticeable
about the domains publishing such as a heavy preponderance of domains
belonging to financial organizations?

> We'll continue to evaluate ADSP's utility as we increase the DKIM
> validation rate, though our research suggests the current policy
> distribution won't profoundly change.
> 
> Moving forward, we fully support the creation of a mechanism for
> deterministic authentication-based sender-published message
disposition
> policy as well as the feedback loop(s) necessary to help senders
> overcome their reluctance to deploy aggressive policies.
> 

We (AGI) have been waiting for the ability to deploy aggressive policy
statements in a meaningful way and are supportive of efforts to move
this forward. Unfortunately ADSP as it stands is too limited from our
perspective.

> While we believe our authentication policy controls will initially
> consume policy from intermediaries, we've designed them to use DNS-
> based policy should a broadly-acceptable standard emerge. We're taking
> the long view and betting that such a standard is possible, and are
> looking forward to being part of creating it.
> 

+1

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 16:02:09 -0400

Good Show! Some inline comments:

Paul Midgen wrote:

> I wanted to address Hotmail's use of ADSP, clarify our position 
> on the issue of authentication policy, and share a few bits 
> of information the list may find interesting.
> 
> Hotmail's use of DKIM+ADSP should not be interpreted as 
> a political statement; 

And it should not need to be.  Is Live.com included?

> we implemented DKIM to offset the impact of well-known SPF 
> false-failure scenarios. We viewed DKIM+ADSP as a package deal 
> and a first step to fully integrating authentication policy 
> controls into our delivery pipeline.

Fantastic! It was Microsoft's entry into SPF that started MARID and 
hopefully some IETF eyes will see restarting IETF policy standard 
development efforts again.

> SPF fails for ~1.5% of our inbound traffic, so that's the 
> percentage of mail for which we currently run DKIM. The next 
> phase of our DKIM project begins soon and will expand 
> DKIM's "scope" to all non-passing SPF results, or ~49% of 
> total inbound volume.

We have eight years worth of statistics at:

    http://www.winserver.com/public/spamstats.wct

The LMAP column includes SPF, and the early DMP and Microsoft's XML 
version of SPF "Caller Id Email Policy" (CEP) which by the way is 
still alive for hotmail.com. :)

      nslookup -query=txt _ep.hotmail.com

   Non-authoritative answer:
   _ep.hotmail.com text =

     "<ep xmlns='http://ms.net/1' testing='true'>
     <out><m>
      <indirect>list1._ep.hotmail.com</indirect>
      <indirect>list2._ep.hotmail.com</indirect>
      <indirect>list3._ep.hotmail.com</indirect>
     </m></out>
     </ep>"

For many years, SPF was low percentage, probably like your 1.5 if you 
average it out since 2003.  But it began to climb as more SPF domains 
switched to hard fails. This month, you can see its 6.2%

BTW, we reduced the DNS overhead by 60% by checking SPF after RCPT is 
determined to be locally valid.  This follows the tip in SMTP RCF5321 
section 3.3:

    3.3 Mail Transactions

    .....

    Despite the apparent scope of this requirement, there are
    circumstances in which the acceptability of the reverse-path may
    not be determined until one or more forward-paths (in RCPT
    commands) can be examined.  In those cases, the server MAY
    reasonably accept the reverse-path (with a 250 reply) and then
    report problems after the forward-paths are received and
    examined.  Normally, failures produce 550 or 553 replies.

> 97.98% "unknown" (including domains not explicitly publishing policy)

Which is expected. SPF showed similar, if not lower startup percentages.

> We'll continue to evaluate ADSP's utility as we increase the 
> DKIM validation rate, though our research suggests the current 
> policy distribution won't profoundly change.

You might be surprise!  Microsoft makes it know and there will be more 
motivations for domains to add ADSP support to reach your users.  It 
will help increase the branding for business service operations. 
Positive marketing will steer corporate customer mailings in your 
direction.  At the personal level, I will have more trust now to use 
my alias hotmail.com account currently use for MSDN.  Seriously, I 
have lesser reasons to use my GMAIL.COM account now.

> Moving forward, we fully support the creation of a mechanism 
> for deterministic authentication-based sender-published message 
> disposition policy as well as the feedback loop(s) necessary to 
> help senders overcome their reluctance to deploy aggressive policies.

Wonderful!

> While we believe our authentication policy controls will 
> initially consume policy from intermediaries, we've designed 
> them to use DNS-based policy should a broadly-acceptable 
> standard emerge. We're taking the long view and betting that 
> such a standard is possible, and are looking forward to 
> being part of creating it.

+1. I have strong convictions Policy with be DKIM's White Horse.

Thanks for your input.

---

From: "John R. Levine" <[email-masked]>
Date: 27 Apr 2011 16:18:46 -0400

>> 97.98% "unknown" (including domains not explicitly publishing policy)

That's not surprising.  Keep in mind that the design of ADSP means that 
you're supposed to check mail that's not signed (or at least, without a 
signature that matches the From: line.)  In my much smaller sample, I see 
discardable on mail from Paypal, and I could believe that Paypal is 2% of 
the signed mail they check.

Regards,

---

From: Paul Midgen <[email-masked]>
Date: Wed, 27 Apr 2011 22:33:02 +0000

Hi Dave,

Yes - percentages of the total "Failed SPF" traffic, which is good and bad. A larger number like 50% of total traffic would be more comforting, but in that 1.5% we don't see the same magnitude of high-volume sender dominance as we otherwise would. Distinct domain breakdown is among the other analyses in progress that I'll share once complete.

As a side note, for the very reason that a few senders dominate, we always try to look at the numbers with them and without them.

-p

-----Original Message-----
From: Dave CROCKER [mailto:[email-masked]] 
Sent: Wednesday, April 27, 2011 11:01 AM
To: Paul Midgen
Cc: [email-masked]
Subject: Re: [ietf-dkim] ADSP stats

Paul,

The distinction could be useful because of how skewed the distribution of volume is, given the smaller number of very large senders.

d/
-- 

   Dave Crocker

---

From: Paul Midgen <[email-masked]>
Date: Wed, 27 Apr 2011 22:40:44 +0000

> From: MH Michael Hammer (5304) [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 11:57 AM
> To: Paul Midgen; Scott Kitterman; [email-masked]
> Subject: RE: [ietf-dkim] ADSP stats
> 
 
> percentage of domains evaluated? Also, is there anything noticeable about
> the domains publishing such as a heavy preponderance of domains belonging
> to financial organizations?

Volume of messages on which we run DKIM (this is important because we don't do it 100% yet); I'll hold off on the second question until we've completed some more analysis.

---

From: Paul Midgen <[email-masked]>
Date: Wed, 27 Apr 2011 22:48:41 +0000

> From: Hector Santos [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 1:02 PM
> To: Paul Midgen
> Cc: Scott Kitterman; [email-masked]
 
> And it should not need to be.  Is Live.com included?

For the purposes of email, live.com & hotmail.com addresses are functionally identical.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Apr 2011 17:03:41 -0700

Barry,

Ticket #17 was listed as a duplicate of Ticket #4
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17

This is not correct!

The result of Ticket #4 was a change that simply said:
,---
Internationalized domain names MUST be converted as described in Section 
2.3 of [RFC5890] to "A-Labels"
'---

This failed to specify Fake A-Labels should not be permitted.  The point 
made by Ticket #17.  RFC5980 introduces restrictions against 3,329 
confusable unicode points not excluded by RFC3490.  Unless A-label 
validity checks are made by DKIM, it is not reasonable to assume 
RFC5980's added protection are afforded or that it is proper to validate 
this very critical input.  This issue becomes extremely important once 
 From domains are displayed using UTF-8.  DKIM should be prepared for 
this imminent change and anticipate the likely "confusable" exploitation 
techniques.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Wed, 27 Apr 2011 22:14:30 -0400

> RFC5980's added protection are afforded

The consensus of the working group, and the guidance from the IESG,
was to allow RFC 5890 and its co-documents to specify the
internationalization aspects.  It is well out of scope for DKIM to try
to do it.  I have seen no support for expanding the statement beyond
what's covered by ticket #4.

I'm happy to re-open ticket #17, and leave it open until WGLC ends,
but unless there's clear support for it, it will then be closed again.

Barry, as chair

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Apr 2011 17:48:45 +0200

On 27/Apr/11 22:18, John R. Levine wrote:
> In my much smaller sample, I see discardable on mail from Paypal,
> and I could believe that Paypal is 2% of the signed mail they
> check.

But they don't check Paypal messages that pass SPF, which IME is all
of them for mailfrom, none for helo.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html