[dmarc-ietf] Failure Reports, section 2, reporting frequency

[Douglas Foster <[e-mail]>]

I believe the reporting strategy needs to be defined in more detail than
provided in section 2, because we need to ensure that report volumes are
manageable for both sender and receiver, and to ensure that receivers can
make sense of multiple reports from multiple sources.   Leaving this issue
to the imagination of each implementer will cause interoperability problems.

.   I propose the following:

Reporting Frequency
"The aim of failure reporting is not to count each and every failure, but
rather to report different failure conditions."  These design
considerations apply to this goal:

A failure condition is defined as a unique combination of RFC5322.From
Domain, RFC5321.MailFrom domain, and source IP address.   This corresponds
to the three parameters of the SPF alignment test.  It also provides enough
granularity so that separate problems are likely to be reported
separately.  This approach also helps a report receiver classify whether
reports from different receivers represent different conditions or multiple
information sources about a single condition.

Failure reports need to be repeated periodically, to ensure that the
receiver has sufficient information to solve the problem, to ensure that
failure conditions are not overlooked, and to provide clarity about whether
a condition is resolved or not.   However, excessive reporting will hinder
efforts to solve known problems, and may cause report senders or report
recipients to cease participation in failure reporting.

Some failure conditions will represent crises that require a prompt
response, some failure conditions will involve complexity that takes time
to resolve, and some failure conditions will be unsolvable.  The reporting
frequency needs to correspond to these situations.

Given these considerations, the following guidelines are provided:

New failure conditions should be reported promptly.  The initial report
will generally represent a single message, but may represent multiple
messages if a cluster of messages are received together.

After the initial report is sent, no more reports are sent until the end of
a time interval.   The time  interval is gradually increased so that the
volume of reports on a single condition declines.

The following reporting intervals are recommended:
After the initial report, send additional reports at hourly intervals if
additional failures occur.
After the first day, send additional reports at daily intervals if
additional failures occur.
After two weeks, send additional reports at weekly intervals until the
problem is resolved or the administrator concludes that further reporting
is not useful.

Doug Foster