Definition of "fo" parameter

[ietf-svn-bot]

owner:todd.herr@valimail.com resolution_fixed-consensus type_defect | by superuser@gmail.com

---

Message-ID: 54AB056C.2090101@bluepopcorn.net Date: Mon, 05 Jan 2015 13:43:08 -0800 From: Jim Fenton fenton@bluepopcorn.net To: "dmarc@ietf.org" dmarc@ietf.org 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. [...]

---

Issue migrated from trac:4 at 2022-01-24 16:13:40 +0000

[ietf-svn-bot]

@kboth+ietf@drkurt.com set component to dmarc-future-notes

[ietf-svn-bot]

@todd.herr@valimail.com changed component from dmarc-future-notes to dmarc-bis

[ietf-svn-bot]

@todd.herr@valimail.com changed status from new to accepted

[ietf-svn-bot]

@todd.herr@valimail.com set owner to todd.herr@valimail.com

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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

[ietf-svn-bot]

@todd.herr@valimail.com changed _comment0 which not transferred by tractive

[ietf-svn-bot]

@todd.herr@valimail.com changed _comment1 which not transferred by tractive

[ietf-svn-bot]

@todd.herr@valimail.com changed _comment2 which not transferred by tractive

[ietf-svn-bot]

@todd.herr@valimail.com changed status from accepted to started

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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

[ietf-svn-bot]

@todd.herr@valimail.com changed _comment0 which not transferred by tractive

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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.

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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'

[ietf-svn-bot]

@todd.herr@valimail.com changed status from started to infoneeded

[ietf-svn-bot]

@mail@wander.science commented

---

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)

[ietf-svn-bot]

@mail@wander.science changed _comment0 which not transferred by tractive

[ietf-svn-bot]

@todd.herr@valimail.com changed status from infoneeded to assigned

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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/)

[ietf-svn-bot]

@todd.herr@valimail.com changed status from assigned to closed

[ietf-svn-bot]

@todd.herr@valimail.com set resolution to fixed-consensus