ietf-wg-dmarc / dmarc-draftissues

1 stars 0 forks source link

Add options to throttle aggregate reporting volumes #77

Closed ietf-svn-bot closed 3 years ago

ietf-svn-bot commented 4 years ago

owner:todd.herr@valimail.com resolution_wontfix type_enhancement | by fosterd@bayviewphysicians.com


The volume of aggregate report traffic is difficult to anticipate, and could be highly sensitive to the success of DMARC deployment. For organizations that are primarily interested in using aggregate reports to verify internal configuration controls, daily reports of non-problems will be unnecessary noise, and a potential obstacle to noticing the actual problems when they appear. Suggest adding tokens of the form:
minMessages=<value, default=1>; minProblems=<number, default=0>

Which means that the organization requests that reports only be sent if they recipient organization sees at least MinMessages emails of any kind and at least minProblems messages with status other than PASS.

Fully upward compatible with existing implementations, but reduces unwanted bandwidth and data storage for those that do not want reporting from minor domains or from domains with no problems.


Issue migrated from trac:77 at 2022-01-24 16:51:44 +0000

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com changed status from new to accepted

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com set owner to todd.herr@valimail.com

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com changed status from accepted to assigned

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com changed status from assigned to closed

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com set resolution to wontfix

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com commented


Aggregate report traffic is not highly sensitive to the success of DMARC deployment. Rather, aggregate report traffic is wholly a function of the volume of mail using domain owner's domain in the RFC5322.From header that is sent to DMARC validating and reporting domains. A domain owner that publishes a policy record with a rua tag but sends no mail could still receive DMARC aggregate reports from every domain sending such reports if the domain owner's domain is widely spoofed.

Mail receivers have honed in on this text in the description of the 'ri' tag as the effective standard for aggregate reporting:

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.

Anything other than a daily report (showing all data) is not something likely to happen. I don't expect that adding these new options will change that, so closing ticket.