On 11/7/20 4:50 PM, Jim Fenton wrote:
On 5 Nov 2020, at 9:45, Seth Blank wrote:
[...]
To Todd's point, DMARC is a means of communicating policy between domain
owner and mail receiver regarding how to handle unauthenticated mail.
DMARC
does not function without policy.
[...] But I consider the reporting aspect to be useful even in the
absence of policy assertion or enforcement, allow a domain owner to
obtain information about recipients’ receipt of unauthenticated email
from that domain. I realize that RFC 7489 treats policy as the primary
function and reporting as secondary, but this WG is about improving
that specification, and I consider this to be an improvement.
I agree there is a great deal of value in reporting without
"enforcement" -- that's why the policy option of "p=none" exists.
Perhaps the use of the string "none," meaning "no change in handling,"
is too readily confused with "none" meaning "no policy?" Which is indeed
an odd duck, a policy saying there is no policy...
Is there a problem with using the "p=" tag to signal the desire for
reports without requesting a change in the processing of messages that
don't get a DMARC "pass?"
[ Quoting Seth again: ]
If someone believes policy can be spun out into a separate draft, please
upload your suggestion as an I-D and we will discuss it.
That’s quite a bit of work for something that might very well be dead
on arrival. I have outlined the portions of the specification that
would go in the base specification and the portions that go into the
policy document, and that should be sufficient to make this decision.
Okay, but what is the expected payoff from splitting it out? Does it
make it easier to process and approve updates of the policy content
separately from, say, the description of record discovery or Alignment
concepts? Easier to pass muster for Standards Track? Are implementers
currently confused and dissuaded by having policy details mixed with the
other content?
If the benefits seem worthwhile, I could get behind the split - but
there ought to be a clear benefit.
--S.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
