On May 5, 2015 1:25:43 PM EDT, Hector Santos <[email protected]> wrote: > >On 5/5/2015 12:50 PM, Scott Kitterman wrote: > >> On May 5, 2015 12:16:16 PM EDT, "Stephen J. Turnbull" ><[email protected]> wrote: >>> But the main point that everybody is missing is that we *do not* >need >>> to deal with the "registration problem" in this WG because the >>> information to register a substantial fraction of mailing lists is >>> distributed in the related mailflows already, and the mailbox >>> providers know where to find the users for confirmation of their >>> intent. There's no need for new protocols. >>> >>> I would prefer to focus on getting a signature delegation protocol >>> specified and hopefully put into practice, discussing mailing list >>> verification practices when potential users bring them up. >> >> No. I believe that entirely assumes away the hard part of the work. >The hard part isn't figuring out candidate data. That can trivially be >done as you suggest. The hard part is figuring out the subset of the >data that's worthy of special treatment. >> >> Approximately as soon as list-id enables DMARC bypass, the bad guys >will start adding it to everything. List-id is useless in this context. >> >> Scott K > >The main point would be that DSAP protocols can still be completed >making the registration part out of scope. It would be part of the >publishing and adoption, migration section as a short or long prospect. > >The same was true with SPF -- you had to wait until domains were >published and registered. Btw, What is your SPF payoff? Your average >daily SPF rejection? > >It is up to yahoo and others if they want to put an effort of >registering domains in order to white list them. That shouldn't stop >an issue for most domains and it should not be a barrier to having a >3rd party authorization protocol. > >As a receiver, I am willing to do a DNS call to the ADID/SDID pair >(when it differs) to see if there is an authorization. I don't really >wish to be changing code to read/write double signatures. This will >raise the adoption barrier.
Wrapping a 'somebody else's problem field' around the registration piece of this doesn't make it any more feasible. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
