I don't think it correct to be implying "we gave it an old college
try" when in fact, everything was being done to kill policy ideas.
Murray, Crocker and Levine where the key IETF cogs working on the DKIM
project and all three were pushing a Trust Model, removing the author
domain from the picture and in fact, militantly refused to even define
the author identity in the DKIM-BIS work which became a STD. Levine
was advocating the receiver do not support ADSP and therefore
alleviating the MLM problem. Levine refused to update ADSP. At this
point, proposing ATPS, well, anything related to POLICY, it was pretty
much too late at this point. ADSP was dead. ADSP was abandoned in the
DKIM-WG.
But as I said, the different now that DMARC replaced ADSP. You got a
whole different set of application users here that desperately need a
wide policy solution. You made that happen but you didn't complete
the job of making ATPS work off DMARC. So you left the holes there.
Instead, you made ATPS work off DKIM and that was yet another instant
barrier to adoption. It was like, "lets do this, but lets make it hard
to do." It was pretty a given that it wasn't going to work.
Now you have an opportunity to finally see if this going to work
because the focus is with DMARC. You didn't have that POLICY focus
before. It wasn't there. Until you do, you are going to continue to
have this powerful proof of concept hanging over DKIM.
If you updated ATPS to make it work off DMARC, and it doesn't get
traction now, I will retire from the DKIM project. I put a huge
investment into a commercial DKIM/ADSP/ATPS project and the rug was
pulled from under me when you pushed to abandoned ADSP. I am trying
to replaced ADSP with DMARC as you want and that includes having the
ATPSrev4 piece. It works. Thats a given.
You got to do it right.
--
HLS
On 5/11/2015 1:08 AM, Murray S. Kucherawy wrote:
On Sun, May 10, 2015 at 4:37 PM, Douglas Otis <[email protected]
<mailto:[email protected]>> wrote:
ATPS included an onerous task for any third-party service
likely used on a gratis basis. Each third-party was expected
to learn specific hash algorithms of each From domain. A
difficult process on top of changing their structure of DKIM
signatures repeated tens of thousands of times for each
different first party domain. In addition, reputations based
on the third-party relationship could not be leveraged
because of the optional hashing.
I continue to find this repeated claim specious at best.
Section 7 of ATPS describes the structure of the experiment and
invites feedback from anyone who tries it. Apart from Hector's recent
declaration and one hobby user of my open source implementation that
enabled it, there has been no feedback from the community at large
that anyone has tried it or any variant of it.
Given the pain point that a widely adopted authorized third-party
signatures scheme (in general, not just RFC6541) would solve, one
would think we'd have heard something in this regard in the last three
years. Nothing beyond what I just mentioned has materialized.
If you intend to claim that this is because of specific aspects in
RFC6541 of how the DNS records are generated, I suggest you consider
that even small operators don't have a problem computing hashes or
populating DNS zones, because computers are good at automating
things. Even if they did see those things as burdens, such operators
tend to be the sort to provide that kind of feedback even about a
protocol they ultimately can't use. Seriously, what person in the
email space that you've met in the last N years would not take an
opportunity to provide feedback, constructive or otherwise? We are a
rather opinionated bunch and love the sounds of our own voices.
Someone would've said something by now. But it hasn't happened.
TPA has existed even longer than ATPS has, and it has enjoyed
similarly goose-egg-shaped amounts of adoption. DSAP was around even
before that, and the story is the same. What they all have in common
is that they are not even close to something that serious operators
would be willing to try. They are plagued by -- you guessed it -- the
registration problem.
Absent a change in that posture by the community at large, this is
manifestly a dead end, and we really, seriously, need to stop burning
any more of our precious cycles on it.
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
