DMARC Failure reporting Interval tagSIDNMeander 501Arnhem6825 MDNL+31 26 352 5500marco.davids@sidn.nl
Internet
DMARC Working GroupDMARCThis document extends the DMARC (RFC7489) record format by defining
an additional tag. This new tag, the "fi" tag, is to be used in
conjunction with the "ruf" tag used for message-specific failure
reporting. It provides a Domain Owner with a simple way of
requesting limitation of the rate at which such reports are sent.
DMARC enables Domain Owners to request for detailed failure
reports for individual messages by means of the "ruf" tag.
There may be various reasons to permanently configure such a "ruf" tag. For example to
facilitate reputation management, monitoring or simply for research or operational purposes.
Failure reports are normally generated and sent almost immediately
after the Mail Receiver detects a DMARC failure. These reports
are useful for quickly notifying the Domain Owners of an
authentication failure, without waiting for an aggregate report.
However, under certain circumstances this property can potentially lead
to an undesirably high volume of reports. Especially when a 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 if and how they
take measures against sending high volumes of failure reports.
However, what a Mail Receiver or report generator considers acceptable
may exceed the capacity of the receiving Domain Owner.
The lack of a mechanism for a Domain Owner to influence the volume
of reports sent by any particular report generator constitutes an
obstacle to deployment of the "ruf" tag feature.
This document updates [RFC7489] by defining the "fi" tag, a mechanism
that allows the Domain Owner to request the limitation of failure reports
of no more than one failure report per report generator per time interval
and discard the remainder.
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 used, as defined in DMARC [RFC7489].
Domain Owner and Mail Receiver.
Also the term "report generator" is applied here the same way as in DMARC [RFC7489].
The following tag is introduced as an additional valid DMARC tag for use in conjunction with the Reporting URI for Failure ("ruf") tag:
Interval requested between message-specific failure reports (plain-text 32-bit unsigned integer;
OPTIONAL; default is "60"; if defined as "0", then there is no rate limitation requested, thereby
mimicking report generators that do not support this tag). Indicates a request to
report generators to send message-specific failure reports at an interval of approximately the
requested number of seconds.Any intermediate remaining reports SHOULD NOT be sent and MAY be
discarded, if generated at all. But discarding message-specific
failure reports as a consequence of this tag, SHALL NOT affect
the incident counts in the aggregated feedback reports.
A report generator MAY include in the message-specific failure
report an indication of the number of reports being discarded since the last issued report.
Where AFRF is used, the Abuse Reporting Format
optional "Incidents"-field may be used for this purpose.
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 "fi" 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. However, anything longer dan 86400 is understood to be accommodated on a best-effort basis.
The formal definition of the "fi" tag format, using ABNF , is as follows:
Introduced:
Which changes the dmarc-record definition to:
The DMARC policy record with the "fi" tag might look like this when retrieved using a common command-line tool:
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):
The request implies that the Domain Owner is willing to accept no
more than one message-specific failure report every 5 minutes from any
report generator. Any optionally defined indications for the maximum
report size in the URI will continue to work as defined in [RFC7489].
A report generator in this example would typically
honour the "fi" tag by sending out a report, storing a 'last report
sent' timestamp for example.com in memory and maintaining it as a
'do not sent' flag for a minimum of 300 seconds during which period
no consecutive reports are to be sent. After the flag has cleared,
a report may again be sent. The cycle then repeats.
Intermediate, unsent reports are discarded. But they do add to statistical counters
as if they were sent. So their details are part of any corresponding aggregated reports.
In AFRF, a message-specific report to the Domain Owner may contain this output (some parts left out for readability):
As a result of the DMARC record above, when a spammer sends two messages per
second and fi=300, a report generator would produce only one message-specific
failure report per 5 minutes, instead of 600. The "Incidents" field in the
report shows that this report represents 599 other incidents as well.
These will count in the daily aggregated feedback report, but where disregarded
and not sent out as individual message-specific failure reports.
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 to the IANA DMARC Tag Registry:
The Domain Owner should be aware that defining a "fi" tag involves a
trade-off between the benefit of preventing unmanageable incoming
report flows and the risk of not receiving potentially useful data.
A large scale attack that triggers reporting rate limitation,
might result in the non-dispatch of reports regarding other events
involving the same domain and the same Mail Receiver occuring at the same.
An attack can involve many different report generators. The Domain
Owner should be aware that the "fi" tag limits reporting by each
individual report generator. Multiple report generators might
still collectively generate a large volume of reports.
Mail Receivers with a farm or cluster of several report
generators might choose to synchronise the 'last sent'
timestamp value accross their machines in order to better comply
with the wishes of Domain Owners and to reduce the risk described above.
An attack can also involve multiple domains belonging to a single
Domain Owner. The "fi" tag applies to an individual domain, so the
deliberate abuse of multiple spoofed domains belonging to Domain Owner,
might still generate a high volumes of message-specific failure reports.
It therefore makes sense to define a relatively short TTL for 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 the event of a problem. This aspect
is also mentiond in [RFC7489 p.40] Section 10.2, second paragraph.
The security of the DMARC TXT-record, which the "fi" tag part of,
depends on the security of the underlying DNS infrastructure.
In that respect it 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.
The author would like to thank Elizabeth Zwicky, Moritz Müller, Maarten Wullink,
Cristian Hesselman, Bart Knubben, Rolf Sonneveld and Murray Kucherawy for
their valuable feedback.