Opened 2 years ago
Closed 11 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 14 months ago by todd.herr@…
comment:3 Changed 14 months ago by todd.herr@…
- Owner set to todd.herr@…
- Status changed from assigned to started
comment:4 Changed 14 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 13 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 13 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 13 months ago by todd.herr@…
- Resolution fixed deleted
- Status changed from closed to new
comment:8 Changed 13 months ago by todd.herr@…
- Status changed from new to assigned
comment:9 Changed 13 months ago by todd.herr@…
- Status changed from assigned to infoneeded
comment:10 Changed 13 months ago by todd.herr@…
- Status changed from infoneeded to assigned
comment:11 Changed 13 months ago by todd.herr@…
- Status changed from assigned to infoneeded
comment:12 Changed 12 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 12 months ago by todd.herr@…
- Status changed from assigned to infoneeded
comment:14 Changed 11 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 11 months ago by todd.herr@…
- Resolution set to fixed-consensus
- Status changed from assigned to closed
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Real world data from Valimail: