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.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
