Would it be useful to add an 'ao' tag name for aggregate reporting options?
Something like:

 

ao:         Aggregate reporting options (plain-text; OPTIONAL; default is
"0"). 

Provides requested options for generation of aggregate reports. This tag's
content MUST be ignored if a "rua" tag is not specified. The value of this
tag is a colon-separated list of characters that indicate aggregate
reporting options as follows:

 

0: Generate a DMARC aggregate report for every message, regardless of its
alignment.

1: Generate a DMARC aggregate report if any underlying authentication
mechanism produced something other than an aligned "pass" result.

d: Generate a DMARC aggregate report if the message had a signature that
failed evaluation, regardless of its alignment. 

s: Generate a DMARC aggregate report if the message failed SPF evaluation,
regardless of its alignment.

 

This would allow domain owners to save on tons of reports to be handled and
processing that are useless in most scenarios. For instance, when I've
deployed my SPF/DKIM/DMARC policy and I'm pleased with my policie's results,
I would still want to use the reporting to detect and fix changes in my
email environment. If a million mails a day are nicely processed with DKIM
and SPF aligned, I do not need those entries in my aggregate reports. I'm
only interested in the reports where either DKIM or SPF fails. In most
scenario's this will cut data transfer and report processing with more than
99 percent. Whenever there is a bump in the number of reports received, I
can detect that something is wrong and I might need to add a host to my SPF
policy or need to fix my DKIM signing.

 

I was amazed that these options weren't in the current RFC, as these do
exist for failure reports. Am I missing something? Is there a reason why
this would be a bad idea?

 

Kind regards,

Freddie

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to