On Tuesday, May 05, 2015 11:00:43 PM Hector Santos wrote: > On 5/5/2015 7:55 PM, Scott Kitterman wrote: > > On Tuesday, May 05, 2015 02:24:19 PM Hector Santos wrote: > >> You don't even have to say "universally useful." All that does is > >> keeps possible implementators away. It can be very useful to some > >> and to them, its universal. > > > > It depends on the type of mechanism we're discussing registration for. If > > it's something receivers can do on their own with no cooperation from > > originators or mediators, then I agree. A scheme that doesn't require > > cooperation with other actors in the architecture can be 'good enough' > > even if it's only useful to a segment of the user based. > > > > OTOH, if there is a scheme that requires multiple actors in the > > architecture to cooperate, then (as I described in my utility analysis), > > it has to be pretty universally usable or it won't get sufficient > > deployment to be operationally useful. > > We are talking about DNS publication of records and domains having to > roll up their sleeves and collect the data they need, if they want to, > making a registration process available to DKIM resigners. > > I see it as a separation problem. The same one, nearly all the > DNS-based protocols had/have -- Publishing DNS records requirement in > order to be useful. If we had used this high bar to have a > registration/publishing readiness or assurance first before you get > started, as you ideally suggest, most of these protocols would not > have been done. > > You need to have your methods in place first and the minimum code > changes among all actors is doing a simple DNS lookup as it was > originally conceived. That is not hard to compare with the > alternatives which has a higher implementation cost and requires much > greater code change. > > Just like SPF, once enough domains published records, it became > somewhat useful and only really more useful when rejection policies > were set. This is when a payoff was realized -- with a rejection > policy. That took a mighty long time and yet, it is still a highly > wasteful protocol. Neverteless, it didn't stop anyone from using it > and domains with larger network of senders are still trying to figure > them all out.
No. It's fundamentally different. For SPF, the managers of an ADMD need to determine their authorized outbound email architecture. That's in the hands of the administrators. For these email list registration proposals it's the mailing list proclivities of every single user. Mars and Jupiter are "the same" in that they are both planets. Trying to land on one is much more feasible than the other despite that sameness. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
