Subject: Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

From: Seth Blank <[email-masked]>
Date: Wed, 23 Sep 2020 14:51:27 -0700

Are there any other comments on ticket 51?

The report contains a disposition field where the result "none" has two
different semantic meanings. Should this be clarified?

Seth, as Chair

On Mon, Jun 8, 2020 at 1:24 AM Alessandro Vesely <[email-masked]> wrote:

> On Sun 07/Jun/2020 23:23:16 +0200 Seth Blank wrote:
> > https://trac.ietf.org/trac/dmarc/ticket/51
> >
> > In a DMARC aggregate report, a record with a disposition of "none" is
> > ambiguous, as a disposition of "none" at p=none means a different thing
> (that
> > no action was taken on the message) than a disposition of "none" if the
> DMARC
> > policy is reject or quarantine (the message passed an aligned
> authentication
> > check of either SPF or DKIM, and was therefore not subject to policy).
> >
> > It is desirable to have logically distinct disposition responses, and if
> so,
> > what should be reported in the latter case? As a straw man, "pass"
> instead of
> > "none"?
>
>
> The current spec, RFC 7489, does not dwell too much upon message
> disposition,
> but it is clear enough.
>
> IIRC, some ambiguity was intentional, letting "none" mean that delivery
> was not
> altered, which is not the same as telling the sender whether the
> corresponding
> messages did it to respective mailboxes or not.  The report producer may be
> reluctant to disclose that detail, and/or further filtering decisions can
> be
> made downstream —even by the MUA— without informing DMARC agents.
>
> All in all, the current enumeration DispositionType looks fine to me,
> although
> the comment in Appendix C should clarify that it is used both for
> published and
> for evaluated policies.
>
> Personally, I do write dmarc=pass in the Authentication-Results header
> fields
> only when the "pass" comes after a strict policy.  This is a per-message
> datum
> which may be worth highlighting in the UI.  However, I don't think
> aggregate
> reports would be clearer by distinguishing such cases.  They are not
> usually
> read by human eyes, and software can easily deduce that value by comparing
> with
> policy_published.
>
> The margin of error is limited to the case of single reports generated for
> periods during which the published DMARC policy changed.  Yet, such events
> seem
> to be less likely than the possibility of reports erroneously reporting
> "pass"
> even when the policy published was steadily "none".
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Sep 2020 01:39:25 -0700

On Sun, Jun 7, 2020 at 2:23 PM Seth Blank <seth=
[email-masked]> wrote:

> (that no action was taken on the message) than a disposition of "none" if
> the DMARC policy is reject or quarantine (the message passed an aligned
> authentication check of either SPF or DKIM, and was therefore not subject
> to policy).
>
> so, what should be reported in the latter case? As a straw man, "pass"
> instead of "none"?
>

Given the choices, I like "pass".

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Sep 2020 12:53:11 -0400

>Given the choices, I like "pass".

Agreed.  That's what my code did until I realized it was supposed to be none.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 25 Sep 2020 10:16:40 -0700

> Given the choices, I like "pass".

+1 to pass - but I'd go further than Ale and use pass whenever the DMARC
evaluation passes regardless of the policy setting in the DMARC record.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Mon, 28 Sep 2020 20:40:13 -0700

I'm hearing consensus that an aggregate report should retain a disposition
of "none" when the dmarc policy is "none", but when the policy is
quarantine or reject, "pass" should be used to disambiguate the use cases.
Further, there's been one suggestion that even in the case of a policy of
none, if the mail passes an aligned authentication check, the status
should be "pass".

Are there any objections to the overall consensus, or further commentary on
the case of an aligned pass with a policy of none? +1s are also welcome.

In 24 hours I'll record consensus; if there's no clear consensus on the
aligned pass case, then I'll open a separate ticket for it.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Sep 2020 12:14:50 +0200

> the case of an aligned pass with a policy of none? +1s are also welcome.

+1.  The rationale, AIUI, is that if the receiver successfully evaluated 
alignment, then "pass" is fine.  If the receiver didn't evaluate anything after 
it saw p=none, then "none" is fine.  <dkim> and <spf> should agree.

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Tue, 29 Sep 2020 08:38:59 -0400

> it saw p=none, then "none" is fine.  <dkim> and <spf> should agree.

Another +1

Michael Hammer

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 29 Sep 2020 14:55:06 -0700

> it saw p=none, then "none" is fine.  <dkim> and <spf> should agree.

If a receiver does not check alignment, then "none" would be the right
report, regardless of DMARC policy in the DNS record. (One could argue for "
¯\_(ツ)_/¯" instead of none, but I don't know how interoperable that would
be)

If DMARC is fully evaluated, including alignment, then "pass" would be
better.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Tue, 29 Sep 2020 15:08:35 -0700

> ¯\_(ツ)_/¯" instead of none, but I don't know how interoperable that would

As an individual, I don't know of any receiver that checks DMARC, but then
doesn't check alignment if the policy is none. Is that above actually a
real world use case that is understood? Perhaps this isn't clear because of
the use of "none" as a status in the first place...

--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Sep 2020 15:50:09 -0700

On 9/29/2020 3:08 PM, Seth Blank wrote:
> I don't know of any receiver that checks DMARC, but then doesn't check 
> alignment

It's not a matter of field statistics:

      Since checking alignment is an obvious part of the DMARC 
procedure, if someone does not follow the specification, they are not 
doing DMARC.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Tue, 29 Sep 2020 15:54:58 -0700

> procedure, if someone does not follow the specification, they are not

That's a much better point than mine. +1

--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 30 Sep 2020 08:01:27 -0700

> procedure, if someone does not follow the specification, they are not

Does that mean that "none" is not an appropriate verdict?

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Sep 2020 08:12:08 -0700

> Does that mean that "none" is not an appropriate verdict?

No, per https://tools.ietf.org/html/rfc7489#appendix-C "none" is the only
option for when a policy action is not undertaken:

   <!-- The policy actions specified by p and sp in the
        DMARC record. -->
   <xs:simpleType name="DispositionType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="quarantine"/>
       <xs:enumeration value="reject"/>
     </xs:restriction>
   </xs:simpleType>

The point of this thread, and where consensus appears to lie, is adding
another value to disambiguate the use cases.

--

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Sep 2020 08:39:16 -0700

> another value to disambiguate the use cases.

Hit send too fast, that's only part of the relevant schema, the rest (which
uses the above) is:

   <!-- Taking into account everything else in the record,
        the results of applying DMARC. -->
   <xs:complexType name="PolicyEvaluatedType">
     <xs:sequence>

*       <xs:element name="disposition" type="DispositionType"/>*
 <xs:element name="dkim" type="DMARCResultType"/>
       <xs:element name="spf" type="DMARCResultType"/>
       <xs:element name="reason" type="PolicyOverrideReason"
                   minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

--

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Sep 2020 08:42:41 -0700

> *       <xs:element name="disposition" type="DispositionType"/>*

Since quibbling is always more fun than dealing with substance...

Given the recent exchange about 'dispose', perhaps "handling" is a safer 
vocabulary choice?

d/

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Sep 2020 08:51:12 -0700

> Given the recent exchange about 'dispose', perhaps "handling" is a safer

Dave, please open a ticket about vocabulary within DMARC that you think
requires modification to be clearer and/or safer (like "dispose", which has
now been raised in two separate threads), and we'll tackle those
language changes separately with respect to the entire body of documents
instead of within the scope of singular issues.

--