Yes it is a "you have to be this tall to ride with us". For instance, many Wordpress sites are on URL blocking lists, because the managers cannot keep with basic security updates. So if you want to host a website, you have to be that tall to ride with us (or find a hosting company, that will give you a child seat)
The mail ecosystem is going this way too. The tools are opensource, available to all, but you need to deploy them and maintain them. The spat of serious data breaches because of email, is making all of us very nervous that kids can create so much havoc so easily... On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > Scott Kitterman wrote: > > > It would be nice if we didn't design standards that only worked at a > certain > > scale. "You must be this tall to ride" worries me. > > There's nothing about ARC that is scale-specific, except for the obvious > observation that there's a batteries-not-included problem, so the analysis > work required to make good use of it as a receiver is likely to be > infeasible for smaller receivers meaning that: > > - initially only larger receivers will do it, and > - if it works then, over time, vendors/developers will embed slow-moving > pieces in products and/or reputation data providers will add faster moving > pieces to their services. > > This is just a diffusion process, not an exclusion of smaller players. > Indeed, it would almost appear that you'd be happier if the big guys had > excluded smaller players from this initiative... > > I'd also point out that we spent most of a decade (2003 - 2011) wandering > in a highly-inclusive -all/o=-/discardable wilderness. It took the world's > most-heavily-phished organisation working directly with one of the big guys > in private to get any purchase on the problem, and their subsequent sharing > of it (DMARC) to bring about progress more broadly. It would appear that > ARC is on a similar path to improving the situation for largest unresolved > piece of the problem (supporting forwarding). This does suggest a general > difficulty in using a consensus-driven process to devise solutions, rather > than merely refine/standardise/evolve them, however this does not seem like > a reason for concern, it may simply indicate that we've gotten as far as we > can get at present with such processes. The important test when deciding > whether to cooperate would appear to be whether the particular solution > unduly benefits the big guys compared to other viable solutions that are > already known about. ! > If there are none, then cooperating on ARC would appear to be a > no-brainer. > > > Solving the mailing list 'problem' in a way that requires me to switch to > > gmail (or some other large scale provider) to get my list mail delivered > is > > worse than no solution at all for me. > > Obviously. This is not being proposed, see the comments about about > vendors/developers and reputation data providers. > > - Roland > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) >
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
