On 3/14/2018 5:37 PM, Brandon Long wrote:
On Tue, Mar 13, 2018 at 3:44 PM Hector Santos <hsan...@isdg.net
If a domain publishes a "p=reject/quarantine" (restrictive policy),
the published intent and expectation is to reject or quarantine
failures. If the receiver wishes to further relax how it handles
failures, that would be a specific local policy, not "general policy."
Overall, the protocol intent is to Reject/Quarantine.
The ARC question is how does ARC change this existing
"psuedo-standard" protocol logic?
I prefer an explicit DMARC extended tag (or a author domain ARC seal)
that publishes the domain intent to use ARC to relax "some"
p=reject/quarantine failure in some fashion which is not defined at
the moment. The preference is to remove/reduce receiver ambiguity of
what is to be expected when DKIM/DMARC is augmented with the ARC.
I still object to this concept on the same basis as the last two times
we had this discussion.
Brandon
Brandon,
Quite possible you haven't been clear in your DKIM Policy Modeling
engineering reasoning.
The concept has been written across multiple RFCs since DKIM Policy
Modeling architecture, including SPF.
If a domain publishes a DNS-based Public Record policy, you SHOULD
honor its wishes as defined by the protocol recommendations.
You can do what you please with Local policy, you can even prepare
your product in the market place (if any) to behave as you want.
Other implementations can do the same product designs that follow
closely with the specifications. That is what the system
cooperatively competitive. Both SPF and DKIM POLICY docs have been
very clear a,long these lines and its the #1 reason why we are still
here after 10+ years trying to resolve same original "indirect"
rejection issues, are we not? First it was SSP, then it was ASDP and
now its these issues with DMARC.
So if you backing off and are advocating that receivers should ignore
or add a "Don't really Mean it" rejection semantic regarding Hard Fail
Policies, with SPF or DMARC, then you need to change the
specifications and make it more clear in the new specs.
But I suspect a top marketing, security interest, the highest payoff,
will continue to be to seek and support hard deterministic protocols.
That doesn't stop us from working on new stuff that deal with the
fuzzy non-deterministic classification decisions. We add some learning
to it if you want. Just make it very clear in your DKIM ARC
augmentation what you want. If you want ARC to change how DMARC
words, then you have to say so in your specs. You just can't assume
people will blindly ignore what is already in place.
Thanks
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
