Opened 8 years ago

Closed 16 months ago

#4 closed defect (fixed-consensus)

Definition of "fo" parameter

Reported by: superuser@… Owned by: todd.herr@…
Priority: major Milestone: Deliverable #3 (changes to DMARC base spec + DMARC Usage Guide
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

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

Change History (10)

comment:1 Changed 5 years ago by kboth+ietf@…

  • Component set to dmarc-future-notes

comment:2 Changed 19 months ago by todd.herr@…

  • Component changed from dmarc-future-notes to dmarc-bis

comment:3 Changed 19 months ago by todd.herr@…

  • Owner set to todd.herr@…
  • Status changed from new to accepted

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

Last edited 19 months ago by todd.herr@… (previous) (diff)

comment:4 Changed 19 months ago by todd.herr@…

  • Status changed from accepted to started

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

Last edited 19 months ago by todd.herr@… (previous) (diff)

comment:5 Changed 19 months ago by 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.

comment:6 Changed 19 months ago by 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'

comment:7 Changed 18 months ago by todd.herr@…

  • Status changed from started to infoneeded

comment:8 Changed 17 months ago by 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)

Last edited 17 months ago by mail@… (previous) (diff)

comment:9 Changed 16 months ago by todd.herr@…

  • Status changed from infoneeded to assigned

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

comment:10 Changed 16 months ago by todd.herr@…

  • Resolution set to fixed-consensus
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.