On Wed, Mar 14, 2018 at 2:37 PM Brandon Long <[email protected]> wrote:
> > > > On Tue, Mar 13, 2018 at 3:44 PM Hector Santos <[email protected]> wrote: > >> >> >> >> One would be a spec revision to deal with ARC. Does DMARC >> >> still 'fail'? Yet the whole point of ARC is to create the >> >> possibility of still getting delivered, in spite of this. >> > >> > My position on this is that the decision by a validator/mailbox >> > provider to use ARC and accept mail that would otherwise fail DMARC >> > falls under the heading of "local policy". There does not need to be a >> > spec revision to deal with ARC from this perspective. A sending domain >> > publishing a DMARC policy is expressing it's wishes, not making >> > demands (it cannot enforce). This is true with respect to any local >> > policy a validator/mailbox provider implements. >> > >> >> 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
