Remove ri= tag

[ietf-svn-bot]

keyword_nit_tag-update owner:todd.herr@valimail.com resolution_fixed-consensus type_defect | by seth@sethblank.com

---

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.

---

Issue migrated from trac:50 at 2022-01-24 16:16:47 +0000

[ietf-svn-bot]

@seth@sethblank.com changed status from new to assigned

[ietf-svn-bot]

@seth@sethblank.com removed owner (was draft-ietf-dmarc-rfc7601bis@ietf.org)

[ietf-svn-bot]

@seth@sethblank.com changed component from rfc7601bis to dmarc-bis

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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

[ietf-svn-bot]

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

[ietf-svn-bot]

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

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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.

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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

[ietf-svn-bot]

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

[ietf-svn-bot]

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

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

Pushed to github and merged to main branch

[ietf-svn-bot]

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

[ietf-svn-bot]

@todd.herr@valimail.com removed resolution (was fixed)

[ietf-svn-bot]

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

[ietf-svn-bot]

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

[ietf-svn-bot]

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

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

Related to #53 and #71

[ietf-svn-bot]

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

[ietf-svn-bot]

@vesely@tana.it changed status from infoneeded to assigned

[ietf-svn-bot]

@vesely@tana.it commented

---

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.

[ietf-svn-bot]

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

[ietf-svn-bot]

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

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

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

[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