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