[ietf-dkim] ADSP stats
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, jo...@iecc.com, 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
Re: [ietf-dkim] ADSP stats
John R. Levine wrote: > 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. hmm 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Hector Santos wrote: > John R. Levine wrote: > >> So in my limited dataset, ADSP usage is if anything shrinking, with only >> Paypal publishing discardable. > > hmm > > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Saturday, April 16, 2011 3:06 PM > To: DKIM List > Subject: [ietf-dkim] ADSP stats > > I crunched all the signed mail I've gotten since the beginning of 2010: > [...] 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Murray S. Kucherawy wrote: >> -Original Message- > 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Hector Santos > Sent: Monday, April 18, 2011 6:00 AM > To: DKIM List > Subject: Re: [ietf-dkim] ADSP stats > > 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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> 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,
John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ADSP stats
Murray S. Kucherawy wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 4/18/11 12:33 PM, Murray S. Kucherawy wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On Apr 18, 2011, at 1:23 PM, Michael Thomas wrote: > Murray S. Kucherawy wrote: >> 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. > > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of J.D. Falk [jdfalk-li...@cybernothing.org] Sent: Tuesday, April 19, 2011 4:08 PM To: DKIM List Subject: Re: [ietf-dkim] ADSP stats On Apr 18, 2011, at 1:23 PM, Michael Thomas wrote: > Murray S. Kucherawy wrote: >> 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. > > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of bill.ox...@cox.com > Sent: Tuesday, April 19, 2011 1:56 PM > To: jdfalk-li...@cybernothing.org; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Murray S. Kucherawy wrote: >> Bill Oxley: >> 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Indeed lack of support for 3rd party signers was where I gave up any interest at all in adsp -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, April 20, 2011 3:08 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ADSP stats Murray S. Kucherawy wrote: >> Bill Oxley: >> 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. 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
Re: [ietf-dkim] ADSP stats
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 > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com > Sent: Wednesday, April 20, 2011 7:37 AM > To: hsan...@isdg.net; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > Indeed lack of support for 3rd party signers was where I gave up any > interest at all in adsp > > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Hector Santos > Sent: Wednesday, April 20, 2011 3:08 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > Murray S. Kucherawy wrote: > > >> Bill Oxley: > >> 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. > > 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
Re: [ietf-dkim] ADSP stats
On Apr 20, 2011, at 4:36, wrote: > 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? > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of J.D. Falk > Sent: Wednesday, April 20, 2011 1:25 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > On Apr 20, 2011, at 4:36, wrote: > > > 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? 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> 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, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Wednesday, April 20, 2011 1:50 PM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > > 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. The industry is still awaiting its silver bullet, I suspect. (OpenDKIM also implemented VBR.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 4/20/2011 1:51 PM, Murray S. Kucherawy wrote: >> 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. > > The industry is still awaiting its silver bullet, I suspect. > > (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
Re: [ietf-dkim] ADSP stats
On 4/20/11 1:25 PM, J.D. Falk wrote: > On Apr 20, 2011, at 4:36, wrote: >> 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? 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Douglas Otis > Sent: Wednesday, April 20, 2011 2:40 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > 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. I don't see how DKIM and DANE occupy related spaces. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 4/20/11 2:50 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org >> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis >> Sent: Wednesday, April 20, 2011 2:40 PM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] ADSP stats >> >> 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. > > I don't see how DKIM and DANE occupy related spaces. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: Michael Thomas [mailto:m...@mtcc.com] > Sent: Wednesday, April 20, 2011 4:01 PM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > 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. Yeah, that's what I meant when I referred to doing five figures worth of TXT queries. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 04/20/2011 04:13 PM, Murray S. Kucherawy wrote: >> 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. >> > 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> A much better test would be compile a list of DKIM signing > domains, and do the ADSP query on them. That's what I did. The only ADSP I see this year is Paypal. Regards, John Levine, jo...@iecc.com, 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
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 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
>> 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. Along those lines, I hope it enjoys the same robust success as GOSIP. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Murray S. Kucherawy wrote: >> 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. > 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=k1; 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. -- Hector Santos, CTO http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Scott Kitterman wrote: > On Wednesday, April 20, 2011 08:01:21 PM John R. Levine wrote: >> 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. 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. -- Hector Santos, CTO http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Wednesday, April 20, 2011 5:51 PM To: ietf-dkim@mipassoc.org 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 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 4/27/2011 10:20 AM, Paul Midgen wrote:\ > 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" 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 Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
Paul, Thank you for sharing what you have. Comments/questions inline. Mike > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Paul Midgen > Sent: Wednesday, April 27, 2011 1:21 PM > To: Scott Kitterman; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > 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" > 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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 = " list1._ep.hotmail.com list2._ep.hotmail.com list3._ep.hotmail.com " 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. > 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" 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. -- Hector Santos, CTO http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
>> 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" 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, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ADSP stats
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:d...@dcrocker.net] Sent: Wednesday, April 27, 2011 11:01 AM To: Paul Midgen Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ADSP stats On 4/27/2011 10:20 AM, Paul Midgen wrote:\ > 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" 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 Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: MH Michael Hammer (5304) [mailto:mham...@ag.com] > Sent: Wednesday, April 27, 2011 11:57 AM > To: Paul Midgen; Scott Kitterman; ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] ADSP stats > > 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? 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: Hector Santos [mailto:hsan...@isdg.net] > Sent: Wednesday, April 27, 2011 1:02 PM > To: Paul Midgen > Cc: Scott Kitterman; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > And it should not need to be. Is Live.com included? > For the purposes of email, live.com & hotmail.com addresses are functionally identical. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> 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 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On 27/Apr/11 22:18, John R. Levine wrote: >>> 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" > > 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
Re: [ietf-dkim] ADSP stats
On Wed, Apr 20, 2011 at 8:29 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of J.D. Falk >> Sent: Wednesday, April 20, 2011 1:25 PM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] ADSP stats >> >> On Apr 20, 2011, at 4:36, wrote: >> >> > 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? > > 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? Sorry I'm late to the party. Perhaps it it just me, but I think when talking third-party, folks could be talking about two different things. 1) Key delegation, as Murray mentions. I believe this means when the party that authors the message uses a third party to send the message. The first party delegates the signing domain to the third party*. I agree that there doesn't need to be another mechanism to do such things. 2) The RFC5322FromDomain doesn't match DKIM's d= parameter. This means that a RFC5322From of example.com and a d= of transactional.example.com is considered third party. > There has been no uptake at all in OpenDKIM for ATPS, and almost none is > apparent with ADSP I can see ATPS gaining momentum in two ways: a) ADSP adopts it to allow third party signing (using the definition from #2 above) b) an author wants to assert a relationship with a DKIM signer. I see b being useless for receivers. I believe the RFC5322FromDomain should never match the d= parameter. * many ESPs do not do DNS delegation, but instead simply generate key pairs for their clients and have clients put the public key in DNS. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jeff Macdonald > Sent: Monday, May 02, 2011 8:07 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ADSP stats > > I can see ATPS gaining momentum in two ways: > > a) ADSP adopts it to allow third party signing (using the definition > from #2 above) > b) an author wants to assert a relationship with a DKIM signer. > > I see b being useless for receivers. I believe the RFC5322FromDomain > should never match the d= parameter. I think (b) might be useful if the receiver does something like VBR or a reputation query about the third-party. But if there's no apparent need for a third-party mechanism, then we're pretty much done. > * many ESPs do not do DNS delegation, but instead simply generate key > pairs for their clients and have clients put the public key in DNS. I include that mechanism when I say "key delegation" as a mechanism for authorizing a third party, so maybe we need a better general term. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On May 2, 2011, at 9:33 AM, Murray S. Kucherawy wrote: >> * many ESPs do not do DNS delegation, but instead simply generate key >> pairs for their clients and have clients put the public key in DNS. > > I include that mechanism when I say "key delegation" as a mechanism for > authorizing a third party, so maybe we need a better general term. Perhaps "key exchange" would fit? In any case, it sure sounds like we need a dedicated BCP about this so we can stop having to re-explain it every other week. (This is not a call for rechartering the DKIM WG.) -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
