On Thu 05/Nov/2020 17:46:19 +0100 Todd Herr wrote:
On Wed, Nov 4, 2020 at 8:38 PM Jim Fenton <fen...@bluepopcorn.net> wrote:
I would suggest instead that the base specification describe the common
pieces: lookup of the DMARC record from the From: header field (or perhaps
some combination of header fields recently discussed), format of the DMARC
record making provision for extensibility by other DMARC specifications,
and anything else that is common to both policy and reporting.
A second specification would be policy, including much of what is in
Section 6 of Murray’s draft except for things like policy discovery that
would be in the base specification.
I’m neutral on whether the aggregate and failure reporting specifications
are separate or combined.
Respectfully, I disagree with the suggestion made here to move policy to a
separate document. DMARC at its core is the requested mail receiver policy
that's expressed in the p= tag; in the draft specification, p= and v= are
the only two required tags, and I can't envision a world where policy isn't
implemented as a requirement to implement DMARC.
That's the old spec. The consensus of the working group is to remove the
normative constraint about p= (ticket #49). So now only v= is required.
Moving discussion of policy to a second specification would render any base
specification to be no more than effectively a table of contents pointing
to other documents, which seems to me to be a pointless document to produce.
Operators who don't need policy, for example external report receivers who just
want to publish verification records, would find the relevant info in the base
spec.
A good point of Jim's proposal is that having policy in a separate spec, in the
same manner as reports, avoids the unintended effect of classifying reports as
a 2nd class, generally-not-used feature.
jm2p
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
