On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: > On Sun, May 10, 2015 at 4:37 PM, Douglas Otis <[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. Unlike TPA-Label that required NO third-party authentication method change, ATPS imposed two significant changes onto third-parties:
1) A need for a new DKIM signature unique for _every_ Author domain seen by the mediator. 2) A need to determine an _unspecified_ hash unique for each Author domain seen by the mediator. Both of these unnecessary and difficult impositions do not align with those benefiting (the DMARC domain). This type of misaligned and overly difficult responsibility greatly impedes adoption where no conclusions can be derived from a lack of adoption. Calling these claims specious suggests: 1) Making onerous impositions on third-parties was not the cause ATPS not being adopted. How in the heck does one prove that? > 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. The TPA label effort was dropped when it looked like ADSP was not going anywhere. You picked up the idea and that was fine, but I warned about a variable hash causing unreasonable complexity. The basic concept of TPA-Label remains sound and still offers a simple way to establish informal federations. Once someone attempts to offer any sort of delegation based on DKIM signatures will quickly discover a need to retract errant authorizations which DKIM can not accommodate. TPA-Label can operate from a DNS server independent of other services used by a domain. TPA-Label places the burden on the DMARC domain (or their proxy) to indicate to their recipients which of the various third-party message sources do not abuse their domain. After all, only the DMARC domain receives feedback and can compare it against outbound logs. Only they represent a reliable authority. > 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. That is why there is an offer on the table to allow us to establish this type of feedback for any large ESP. It can be done effectively without becoming onerous. Really. Does any large ESP wish to defend public exchanges within their domain? Anything that defends open exchange is worth a few cycles. If not, DMARC should then offer a policy profile that includes Sender header field. Otherwise DMARC remains non-compatible and is disruptive of desired interchange as a result. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
