Definition of "fo" parameter

[superuser@…]

Message-ID: <54AB056C.2090101@…>
Date: Mon, 05 Jan 2015 13:43:08 -0800
From: Jim Fenton <fenton@…>
To: "dmarc@…" <dmarc@…>
Subject: [dmarc-ietf] Comments on dmarc-base-09

[...]
Section 5.3, definition of fo: parameter: I had reported that there
isn't any prohibition on specifying both 0 and 1, and I thought someone
said that was fixed but I can't find it. More generally, I struggle to
find any real utility for a colon-separated list of options here.
[...]

[todd.herr@…]

Current text reads as follows:

fo:
:   Failure reporting options (plain-text; OPTIONAL; default is "0")
Provides requested options for generation of failure reports.
Report generators MAY choose to adhere to the requested options.
This tag's content MUST be ignored if a "ruf" tag (below) is not
also specified.  The value of this tag is a colon-separated list
of characters that indicate failure reporting options as follows:

    0:
    :   Generate a DMARC failure report if all underlying
       authentication mechanisms fail to produce an aligned "pass"
       result.

    1:
    :   Generate a DMARC failure report if any underlying
        authentication mechanism produced something other than an
        aligned "pass" result.

    d:
    :   Generate a DKIM failure report if the message had a signature
       that failed evaluation, regardless of its alignment.  DKIM-
       specific reporting is described in [@!RFC6651].

    s:
    :   Generate an SPF failure report if the message failed SPF
       evaluation, regardless of its alignment.  SPF-specific
       reporting is described in [@!RFC6652].

Jim's comment about there being no utility for the colon-separated list resonates with me, because each value either conflicts with another or is redundant.

0 - conflicts with 1, s and d, because you either want all or you don't
1 - redundant with s and d; overlaps with 0
s - redundant with 1
d - redundant with 1

If and only if there's ever a time when there are three or more authentication protocols underpinning DMARC, then it might make sense to support a colon-separated list of the letter values, so that the domain owner can request reports about failures of, say, DKIM and X, but not SPF (d:x).

Text to cover that eventual case might read:

Failure reporting options are shown below. The value of this tag is either
"0", "1", or a colon-separated list of the alphabetic characters shown in the list.

but even that would be borderline silly for the current condition of just two alphabetic options, where d:s would be the same as "1".

[todd.herr@…]

Changing relevant text to this:

fo:
:   Failure reporting options (plain-text; OPTIONAL; default is "0")
Provides requested options for generation of failure reports.
Report generators MAY choose to adhere to the requested options.
This tag's content MUST be ignored if a "ruf" tag (below) is not
also specified. Failure reporting options are shown below. The value
of this tag is either "0", "1", or a colon-separated list of the 
alphabetic characters shown in the list.

Above merged to main branch in github

[todd.herr@…]

Still wondering if we need some kind of disclaimer that we are aware that "d:s" is the same as "1", and that the colon-separated list only makes sense if there are at least three authentication options.

[todd.herr@…]

Might be safe to just delete the bits about a colon-separated list.

A survey of nearly 74,000 DMARC records that Valimail has scanned found that just 316 (0.42%) were using the colon-separated list as a value to their 'fo' tag.

Other interesting numbers from the 73,917 domains...

5,906 with a value of '1'
  517 with a value of '0'
   74 with a value of 's'
   11 with a value of 'd'

128 with a value of '1:d:s'
115 with a value of '0:1:d:s'

[mail@…]

152,348 v=dmarc1 records in tranco toplist:

grep -i "v=dmarc1" 2021-05-09_tranco_dmarc.txt | grep -i -E "fo( *)=( )*[^;\"]+" -o | cut -d "=" -f 2-|sort |uniq -c | sort -r

  40515 1
   3985 0
    825 0:1:d:s
    634 s
    575 1:d:s
    281 0:d:s
    108 0:1
    106 d
     59 1:s
     52 0:s
     50 d:s
     35 0:1:s
     22 1:d
     21 1:s:d
     11 0:d
      7 0:1:s:d
      5 0:1:d
      3 s:1
      1 1:1:d:s

(33 omitted with leading/trailing whitespace)
(50 omitted with syntax errors)

[todd.herr@…]

Text is updated for rev -02, as per discussion during 27 May 2021 interim session (​https://datatracker.ietf.org/doc/minutes-interim-2021-dmarc-01-202105270900/) and per consensus from working group mailing list (​https://mailarchive.ietf.org/arch/msg/dmarc/kSi0PL0fksyBGnZPIFzUL3cmJl4/)