On 7/14/2020 1:56 PM, Jim Fenton wrote:
Not specific to Dave's comment above, I'm really struggling to
understand what problem(s) we're trying to solve. The answers I get back
say something about "defending brand identity", which is a marketing,
not a technical consideration.
IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the
technical requirements. I am NOT volunteering to do this.
We will reach the same conclusions. But if we simply remove RFC5016,
Section 5.3 Item 10, then things will become very interesting:
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
I was totally flabbergasted when this last item #10 was added. This
was the "DKIM Policy Killer" and we have not recovered. The irony now
is the third party signer impugning on the 1st party policies.
1st Party Policies Matters! <g>
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
