Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt

From: [email-masked]
Date: Mon, 22 Jan 2018 14:47:28 -0800

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/

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Jan 2018 10:53:16 -0500

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, [email-masked] wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

-- 
HLS

---

From: Brandon Long <[email-masked]>
Date: Fri, 26 Jan 2018 20:23:45 +0000

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Jan 2018 10:51:15 -0500

Hi,

On 1/26/2018 3:23 PM, Brandon Long wrote:
> 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?

Local Policy always prevails. But we all work towards developing a 
common protocol and hopefully, and ideally, do so on a cooperative 
competitive basis where all nodes are treated the same at the protocol 
level.   The add-on value may be what the implementation may offer at 
the local level to customers, i.e. features, options, etc.

I believe the intent of the domain is his published policy record.  If 
a restrictive policy is published, the receiver should not presume it 
did not mean it.  When failure is detected, the author domain with a 
restrictive policy is given the world permission to treated it harshly.

     See RFC5016, "Requirements for a DomainKeys Identified Mail (DKIM)
     Signing Practices Protocol."  Also note section 5.3 Item 10
     which basically reminds us about Local Policy expectations.

But to me, thats just a protocol option:

     How should DMARC failures be handled?

     (o) Reject with _55x_ SMTP rejection code
     (_) Quarantine to user's spam box.
     [X] NEW! Check for the DMARC arc= tag.

etc.

I will have something like that in my implementation and even more 
options as we learn more how ARC is suppose to operate and fit in with 
the rest of the DKIM/POLICY/TRUST architectural model and system. 
Others may automatically presumed everything is accepted (250 reply 
code) and put into the user's spam box where it can be eyeballed by 
them (or completely forgotten by them).  Some here strongly believe 
that is the only to operate (never reject).  I believe in options.

> 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.

yes, thats a given, always, Local Policy always prevails.

But that is exactly why the extended policy signal would offer a more 
explicit indication of the the domain's intent. With no tag, there is 
an element of "fuzziness" for the receiver on whether it is doing the 
right thing.

If the domain has arc=0, then the compliant ARC/DMARC receiver SHOULD 
honor the intent of the protocol when the policy is restrictive.  If 
the domain has arc != 0, then the compliant ARC/DMARC receiver CAN|MAY 
use ARC to preempt a restrictive policy DMARC failure.

There is no ambiguity now, both technically and legally, if I may add, 
presuming that there may be DMARC domains who do not want any ARC 
processing of failed mail, using ARC to bypass a True Positive failure 
may have some level of liability concerns. i.e. you can't ignore this 
consideration.

> Also, the sender doesn't implement ARC, so why should they care?

Because of the point above.  Its always better to be protocol specific.

Also consider the ARC-ignorant receiver (who just doesn't know 
anything about it) but it supports DMARC, it may honor restrictive 
policies.  That would be the DMARC protocol expectation.  It would 
behave with an default 'arc=0" policy when it reads a DMARC record 
because it knows nothing about it.

> 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.

There will be domains who will not want to participate in a concept 
that can bypass true positive DMARC failures -- it can be viewed as 
security loophole.

Having an indicator will definitely help receivers with their 
processing logic, including development and usage of APIs.  Without 
it, ARC will add a new element of DMARC processing fuzziness unless 
you are presuming that any receiver even contemplating ARC implies 
that the receiver is automatically going to ignore author domain 
wishes.  Be careful with that because that would be enough for some 
implementators and domains to nix the whole ARC idea.

> 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.

Yes I would think that would be more complex, but also a different 
idea.  Receivers are already doing a DMARC lookup.  Adding an extended 
tag like "arc=" will assist receivers in how to process failures 
without ambiguity.

To me, the only real protocol design question would be what ARC would 
recommend as the default "arc=" value.   Using "arc=1" as the default 
would presume ARC can bypass any DMARC failure without explicit 
permission from the Author Domain.  The burden would be on the current 
DMARC p=reject/quarantine policies domains to add an "arc=0" to tell 
receivers "Please don't skip failures by using ARC."

Thanks

-- 
HLS