On 7/15/2020 8:14 PM, Jim Fenton wrote:
Unburying this from a different thread.
I'm really struggling to understand what problem(s) DMARC is trying to
solve. The most common answer I have heard says 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.
Jim, if we review both RFC4686 and RC5016, I believe we might find
there is not much to be changed. However, imo, something will have to
be done regarding RFC5016 section 5.3 item:
https://tools.ietf.org/html/rfc5016#section-5.3
5.3. Practice and Expectation Requirements
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.
This provision with strict protocol language "MUST NOT" prohibits any
DKIM Policy protocol, formally called SSP "Sender Signing Practices"
and now today, DMARC, from impugning on 3rd party policies such as how
a MLM operator via local policy exceptions can ignorantly and blinding
destroy the integrity and resign the mail instead of just honoring it.
This language would have be updated or removed and just leave the
implicit idea that local policy always prevails in all SMTP situations.
Have a good weekend, be safe.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
