Hello Tomki, The schema for reports is:
first element is <feedback/>, it includes <policy_published/> . <policy_published/> contains <domain/>. Do you propose to include in the <domain/> the base domain, that declared implicitly or explicitly the sp= tag, and then cummulate all data for that domain and subdomains in the same xml.gz report, or do you propose to include several xml.gz files for each domain in a single email? Alternative approaches to reduce the amount of emails are: - include one or more xml reports in a single email, e.g. based on derived policy via the sp= mechanism - group reports for a single domain owner into one email with many xml files, provided that the recipient address of the reports is the same. Here sp= is irrelevant. This is tricky, when the recitient addresses for two domains overlap, but are not identical. - group xml.gz reports for many domain owners (or many distinct second level domains) into a single email, provided that the recipients of the different reports would be the same. Regards Дилян On Fri, 2019-06-21 at 18:04 -0700, Tomki wrote: > The spec appears to be unclear on how subdomains are to be reported - ie > most but not all implementations have performed this as intended, in the > same XML as the top level domain (when the subdomain does not have its > own DMARC TXT record) > > Cisco interpreted the current definition to mean that every subdomain > seen should get its own XML file. (not just the ones with their own > DMARC record) This results in every individual IronPort system [which > has DMARC reporting enabled] generating hundreds to thousands of extra > reports every day. > This can result in corporate reporters like Paypal or Rolls Royce > (IronPort users) sending as many reports in a given day as Google. > > The section which should be referred to in implementing a reporting > engine is 7.2 https://tools.ietf.org/html/rfc7489#section-7.2 > The only relevant bullet that I find here is > " The report SHOULD include the following data:" > .... > "Data for each Domain Owner's subdomain separately from mail from > the sender's Organizational Domain, even if there is no explicit > subdomain policy" > > In trying to find out why Cisco implemented their reporting in the way > that they did, I've actually had a hard time understanding how others > understood that bullet point well enough - I can only imagine that > everybody just implemented by following examples of existing > implementations. > > A suggested rewording for that bullet point: > " Data for each Domain Owner's subdomains as separate records in a > report titled for the Organizational Domain, unless there is an explicit > subdomain policy - in which case a standalone report is generated for > that subdomain" > > --Tomki > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
