I sometimes override DMARC p=quarantine failures with filters, does DMARC
require a filters extended tag and compliance by mail clients to not allow
overriding of the filters if the domain requests it?
My point is, fundamentally in the mail eco-system, whether something is
delivered or rejected or labeled as spam is at the discretion of the
receiver. Having increasing levels of "but I really mean it" for DMARC is
not useful.
Also, the sender doesn't implement ARC, so why should they care?
Also, I think some of this already happens today based on reports. We get
complaints about where we override DMARC from domains all the time, and
that goes into our work on making our overrides more correct. I don't see
how arc=n helps that at all. If you wanted to help that, you'd want some
mechanism or automation with which a domain owner could tell a particular
mailbox provider that they're doing a bad job, and that's a lot more
complicated than arc=n.
Brandon
On Wed, Jan 24, 2018 at 7:53 AM Hector Santos <hsan...@isdg.net> wrote:
> Quick review note:
>
> The draft introduction talks about the "False Positive" problem with
> restrictive DMARC policies -- the reason why we are here.
>
> We need to keep in mind, DMARC also comes with "True Positives" DMARC
> failures as well. DMARC Author Domains who will either be ignorant
> (unaware of ARC) and/or does not wish to implement it (yet) and expect
> all DMARC failed messages to be handled according (rejects/quarantine)
> by receivers. This is expected to be especially true during the
> experimentation and migration to support period. We are here because
> of the reject/quarantine problem. People are not going to just stop
> processing this filter until ARC proves itself.
>
> For easier plug and play logic, the compliant ARC Receivers will need
> a signal from the DMARC Author Domain that ARC can/should be applied
> when DMARC failures. I suggest a new ARC section for an DMARC
> extended tag, "arc=" and/or using the first Author Domain created ARC
> header to signal ARC compliance.
>
> For the DMARC Extended Tag (throwing it out there):
>
> arc=0 ARC not expected to preempt failures (default)
>
> arc=1 The Original Domain signs with ARC, not required
> if author domain is the first seal.
>
> arc=y The Original Domain MAY NOT sign with ARC but
> others can to forward failed messages.
>
> Something like the above to convey the various possibilities the
> DMARC/ARC will mostly be encountering which will basically be:
>
> if DMARC fails
> {
> //==========================
> // NEW! Added ARC Policy support
> //==========================
> if Mail.Headers["ARC-Seal"].domain == AuthorDomain
> or DMARC.Tags["arc"] != "0"
> {
> Add ARC seals/headers
> return SUCCESS;
> }
> //==========================
> Fail the message
> return FAILURE;
> }
>
> Thanks
>
>
> On 1/22/2018 5:47 PM, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
> >
> > Title : Authenticated Received Chain (ARC) Protocol
> > Authors : Kurt Andersen
> > Brandon Long
> > Steven Jones
> > Seth Blank
> > Murray Kucherawy
> > Filename : draft-ietf-dmarc-arc-protocol-11.txt
> > Pages : 54
> > Date : 2018-01-22
> >
> > Abstract:
> > The Authenticated Received Chain (ARC) protocol creates a mechanism
> > whereby a series of handlers of an email message can conduct
> > authentication of the email message as it passes among them on the
> > way to its destination, and record the status of that authentication
> > at each step along the handling path, for use by the final recipient
> > in making choices about the disposition of the message. Changes in
> > the message that might break DKIM or DMARC can be identified through
> > the ARC set of header fields.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11
> > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-11
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-11
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
> >
> >
>
> --
> HLS
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
