Suggestions for eliminating loops: Best (sender controlled) The report-sending account should be from a non-reportable domain or subdomain. Authority to report on behalf of another domain/sub-domain can be established with a DKIM signature of the reporting domain. Of course, if the report-sending domain is a subdomain of a reportable domain, the sub-domain needs its own DMARC policy to disable inheritance and to disable reporting. The report-sending account could be placed in a domain/sub-domain which is send-only (SPF policy but no MX records). This prevents out-of-office messages, NDRs, or spam from being sent to the report-sending account. A null sender would be one way of producing this result, but it may be difficult to implement in some configurations. Additionally, messages from the null sender are more likely to be rejected by BATV filtering. Alternate (sender controlled) If the report-sending account is in a domain/sub-domain that collects feedback, messages sent to the report-sending account must be excluded from feedback data collection.
Backup (recipient controlled) Option 1: The recipient account should be in a domain/subdomain that does not collect DMARC feedback. Option 2: If the recipient account domain does collect feedback data, the recipient account must be excluded from feedback data collection. Since the sender cannot know whether the recipient domain collects DMARC feedback, he should not rely on the sender being able to prevent looping. I think these methods will eliminate the need for rate limiting. Doug Foster ---------------------------------------- From: "Dave Crocker" <[email protected]> Sent: Thursday, June 6, 2019 4:28 AM To: "John R Levine" <[email protected]>, [email protected] Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports On 6/6/2019 10:08 AM, John R Levine wrote: > If people follow the spec there will be fewer loops, but it won't reduce > the number to zero. Forgive me, but I believe there is currently no spec to follow. Yet. I took this thread as raising the issue that there needs to be an effort that specifies how to avoid dmarc report loops. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
