Opened 2 years ago

Closed 14 months ago

#50 closed defect (fixed-consensus)

Remove ri= tag

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

Description

Almost no one uses it, and it is generally ignored by mail systems.

More frequent data is desirable, but real world usage and implementation considerations make this appear to be an easy tag to remove.

Change History (15)

comment:1 Changed 2 years ago by seth@…

  • Component changed from rfc7601bis to dmarc-bis
  • Owner draft-ietf-dmarc-rfc7601bis@… deleted
  • Status changed from new to assigned

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

Real world data from Valimail:

73917 DMARC records examined
71160 with no ri tag
 1383 with ri = 86400 (the default)
 1102 with ri = 3600
  107 with ri = 84600 (typo'd default)
  165 with ri = something other than 86400, 84600, or 3600

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

  • Owner set to todd.herr@…
  • Status changed from assigned to started

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

Wondering if best approach here is to give this option the same treatment that the 'ptr' mechanism received in RFC 7208? That is, leave the original text in the document, but bound it with "(do not use)" and some discussion about how no one used it anyway.

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

Updated text as follows:

-ri:
+ri (do not use):
 :   Interval requested between aggregate reports (plain-text 32-bit
-unsigned integer; OPTIONAL; default is 86400).  Indicates a
-request to Receivers to generate aggregate reports separated by no
-more than the requested number of seconds.  DMARC implementations
+unsigned integer; OPTIONAL; default is 86400).  This tag SHOULD NOT
+be used in a DMARC record. See the note at the end for more information.
+Indicates a request to Receivers to generate aggregate reports separated
+by no more than the requested number of seconds.  DMARC implementations
 MUST be able to provide daily reports and SHOULD be able to
 provide hourly reports when requested.  However, anything other
 than a daily report is understood to be accommodated on a best-
 effort basis.
 
+    Note: In March, 2021, a survey of nearly 74,000 DMARC policy records showed
+    that fewer than 2% were publishing an ri tag with a non-default value, with
+    most of those set to a value of 3600. There was no evidence that any of these
+    requests for something more frequent than once daily were being honored.
+

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

  • Resolution set to fixed
  • Status changed from started to closed

Pushed to github and merged to main branch

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

  • Resolution fixed deleted
  • Status changed from closed to new

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

  • Status changed from new to assigned

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

  • Status changed from assigned to infoneeded

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

  • Status changed from infoneeded to assigned

Related to #53 and #71

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

  • Status changed from assigned to infoneeded

comment:12 Changed 15 months ago by vesely@…

  • Status changed from infoneeded to assigned

Confirm Valimail data. Out of 119,920 domains, I found 20 different values of ri:

MariaDB [mail]> select count(*) as c, original_ri from domain group by original_ri order by c desc;

c original_ri
118495 none
1249 86400
124 3600
23 14400
6 604800
6 21600
3 300
2 84600
2 43200
2 6400
1 172800
1 8
1 600
1 7200
1 900
1 2592000
1 44200
1 1
1 342000
1 8200

20 rows in set (0.102 sec) —edited

In fact, the frequency should be determined by the report producer. There is a possible relationship between frequency of reporting and size of resulting reports. The frequency could be adjusted accordingly. See tickets #53, #71, and #77.

comment:13 Changed 15 months ago by todd.herr@…

  • Status changed from assigned to infoneeded

comment:14 Changed 14 months ago by todd.herr@…

  • Status changed from infoneeded to assigned

Tag was removed per consensus at the 27 May 2021 interim (https://datatracker.ietf.org/doc/minutes-interim-2021-dmarc-01-202105270900/) and confirmed through mailing list discussion (https://mailarchive.ietf.org/arch/msg/dmarc/K7BYScgSYdwDCVusqL9ILUTf3oo/)

comment:15 Changed 14 months ago by todd.herr@…

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