Hi Дилян,
Thanks for your input and feedback. Maybe a single tag, that allows the domain owner to avoid receiving aggregate reports for messages that align, would be enough? I personally have little experience with mailing lists which, I understand, can be a real pain when it comes to SPF/DKIM. So would a tag that instructs the receiving party to only send an aggregate report whenever the DMARC policies is applied be a better option? Kind regards, Freddie Van: Дилян Палаузов [mailto:dilyan.palau...@aegee.org] Verzonden: woensdag 31 juli 2019 17:29 Aan: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' Hello Freddie, if a message has 5 DKIM-Signatures, some of them fail DKIM validation and some of them do not align, irrespective of validation status, you want to receive a report for the failed DKIM signatures. The proposed option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a report for failed DKIM signature you put in the DKIM-Signature header r=y. After the mail passes over a mailing list, the signature is invalidated and you get a useless report. Your intension is to limit the amount of useless reports, but this particular option goes in the opposite direction. If you remove the SPF records and ensure that each leaving message is signed, you do not need the ao=1 option, as each report on failure will be about DKIM. With ao=s whenever a mail is sent to an alias and redirected to another server, you will get a useless report. I am not exactly sure, but I think SPF contained some reporting mechanisms, so this option might duplicate them. Perhaps you want to propose a mechanism, that hides the successful deliveries (useless report) and only reports problematic cases? Regards Дилян On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman <freddie=40leemankuiper...@dmarc.ietf.org <mailto:freddie=40leemankuiper...@dmarc.ietf.org> > wrote: 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
