DMARC Failure reporting Interval tag

Domain Owners may have various reasons to permanently configure a "ruf" tag. For example in the case of reputation management, monitoring or research this can be seen as useful functionality. DMARC per-message failure reports ("ruf") are sent almost immediately and in a non-aggregated manner. Under certain circumstances this can potentially lead to an undesirable high volume of reports. Especially in the case where the Domain Owner's name is spoofed and abused in a large scale phishing or other impersonation attack. DMARC [RFC7489] Section 7.3 leaves it to the discretion of participating Mail Receivers and report generators to take measures against sending high volumes of failure reports. But their mileage may vary and the measures they take, if any, may not meet the criteria of the Domain Owner at the receiving end. The lack of a mechanism to influence the volume of reports from a Domain Owners' perspective, constitutes an obstacle for deployment of this feature. This document updates [RFC7489] by defining the "fi" tag, a mechanism that allows the Domain Owner to request a limitation of no more than one failure report per report generator per time interval.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. The following terms are also used, as defined in DMARC [RFC7489]. Domain Owner and Mail Receiver.

The following tag is introduced as an additional valid DMARC tag for use in conjunction with the Reporting URI for Failure ("ruf") tag: fi: Interval requested between message-specific failure reports (plain-text 32-bit unsigned integer; OPTIONAL; if not defined or 0, then there is no rate limiting requested). Indicates a request to report generators to send per-message failure reports with an interval of approximately the requested number in seconds. But no more than that. Any intermediate remaining reports SHOULD NOT be sent and MAY be disgarded if generated at all. But disregarding per-message failure reports as a consequence of this tag, SHALL NOT affect the statistical information in aggregated feedback repports. Report generators that choose to adhere to the "ruf" tag option, SHOULD also adhere to the requested "fi" tag setting defined here. This tag's content SHALL be ignored if a "ruf" tag is not also specified, or if the syntax of the integer is invalid. Report generators that implement this feature MUST be able to support the entire interval range from 0-86400 and MAY support longer intervals.

The formal definition of the "fi" tag format, using ABNF , is as follows: Introduced:

dmarc-finterval = "fi" \*WSP "=" \*WSP 1\*DIGIT Updated:

dmarc-record = dmarc-version dmarc-sep [dmarc-request] [dmarc-sep dmarc-srequest] [dmarc-sep dmarc-auri] [dmarc-sep dmarc-furi] [dmarc-sep dmarc-adkim] [dmarc-sep dmarc-aspf] [dmarc-sep dmarc-ainterval] [dmarc-sep dmarc-finterval] [dmarc-sep dmarc-fo] [dmarc-sep dmarc-rfmt] [dmarc-sep dmarc-percent] [dmarc-sep] ; components other than dmarc-version and ; dmarc-request may appear in any order

The DMARC policy record with the "fi" tag might look like this when retrieved using a common command-line tool:

% dig +short TXT _dmarc.example.com. "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@example.com; fi=300;" To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):

; DMARC record for the domain example.com _dmarc IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc-feedback@example.com; " "ruf=mailto:auth-reports@example.com; fi=300; " ) The request implicates that the Domain Owner is willing to accept no more than one per-message failure report every 5 minutes from any report generator.

As per [RFC7489 p.17] Section 6.3 last paragraph, a new version of DMARC is not required. Older implementations that consider the "fi" tag as unknown, will ignore it. However, this document requires an update of the IANA DMARC Tag Registry:

Tag Name | Description ---------+--------------------------- fi | Failure Reporting interval

The Domain Owner should be aware that defining a "fi" tag is a trade-off between too much reports and possibly missing out on some details. A large scale attack that triggers the rate limiting, might block the generation of reports for other events on the same domain to the same Mail Receiver. An attack could involve many different report generators. The Domain Owner should be aware that the "fi" tag is on a per report generator basis. Combined, multiple report generators might still generate a considerable amount of reports. An attack could also involve multiple domains of one particular Domain Owner. The "fi" tag is on a per domain basis, so a deliberate abuse of multiple spoofed domains of one Domain Owner, might still generate high volumes of per-message failure reports. Therefore it makes sense to define a relatively short TTL on DMARC-records, to allow for the possibility of increasing the "fi"-value on an ad hoc basis, or to remove the "ruf" (and "fi") tag altogether in case of a problem. The security of the DMARC TXT-record of which the "fi" tag is a part, rests on the security of the underlying DNS infrastructure. In that respect is is advisable to make use of DNSSEC.

The DMARC virtual verification draft [draft-akagiri-dmarc-virtual-verification] discusses possible values for the "ruf" tag. The authors of that draft are kindly requested to take this draft into consideration as part of their discussions.

TBD