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
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
