You have good reason to be proud of what you accomplished with incomplete information and limited resources. But that does not address the question of whether we should provide more complete information in the future.
I am really quite mystified by the resistance on this issue. Is there a concern that report parsers will crash if they are presented with an unexpected XML data element? Is there a privacy concern with HELO? You have made it clear that you are opposed, but you have not really said why, and the silent majority apparently think my idea is too stupid to even deserve comment. What do we expect people to do with Aggregate Reports? Here is my understanding: Recipients use reports to separate message sources, as indicated by the Source IP, into these reputation groups: - Messages that originate within the domain - Messages which originate from vendors in a relationship to the domain - Messages forwarded by a non-modifying forwarder - Messages which cannot be authenticated but which are determined to be benevolent, such as a mailing list - Messages which cannot be authenticated because they are not benevolent. After assigning a server to the first two groups, we work to ensure that they are verifiable with SPF and DKIM. The third group is protected when the first two groups are properly configured with DKIM signatures. The fourth group is a possible incentive to stay at p=none. The fifth group is a significant incentive to move to p=reject. But assigning addresses to those groups is not always trivial. Source IP addresses don't have reputations by themselves; they inherit reputation from the organization that operates them. So everything hinges on server identity. I have put a lot of recent effort into server reputation assessment. I have found that it requires considering HELO name, Reverse DNS name, whether those names can be forward-confirmed to the Source IP, and whether those names are associated with same or different organizations. It is a small leap to see that server authentication principles used for filtering an incoming message will also be useful for categorizing a message sending server that appears on an Aggregate Report. The converse is also true, it is easy to see that the existing Aggregate Report is weakened by the lack of full server identification. So that's why I floated this stupid idea, Doug Foster On Sun, Jan 8, 2023 at 2:56 PM Dotzero <[email protected]> wrote: > > > On Sun, Jan 8, 2023 at 2:17 PM Douglas Foster < > [email protected]> wrote: > >> re: "These are not forensic reports" >> The purpose of aggregate reports is to define WHERE a problem occurs, >> while the purpose of a forensic report is to define WHY a problem occurs. >> (e.g. "Why do my DKIM signatures fail when sent to example.com on >> Thursdays?") The problem with Source IP alone is that it does not >> adequately answer the WHERE question. Perhaps you have never had to find >> a computer behind a many-to-one NAT, but it happens. >> > > Perhaps I did architect and run a system with many thousands of server > instance on-prem, colo, cloud and 3rd party vendors, including integration > of systems from acquisitions... and all without EHLO in aggregate > reports... and all without paying a 6-figure consulting fee to find all of > our mail sources and get them configured for DKIM signing. You make it > sound as if without EHLO, all is lost. As far as finding a server in a pool > behind NAT/PAT implementations, that isn't all that difficult - more like > drudge work. I've done it on implementations that involve both local load > balancing and wide area load balancing. I'm not exactly sure what point you > are trying to make. > >> >> Aggregate reports are most useful to organizations with a mail >> environment which is so complex that they can justify a 6-figure consulting >> engagement to find all of their mail sources and get them configured with >> DKIM signing. These are the ones that are likely to need HELO information >> to complete their rollout. I am also thinking of DMARC-participating >> PSOs, which will be interested in maximum available information about DMARC >> failures. >> > > Aggregate reports are useful to ANY organization interested in > implementing email authentication to protect their sending domains. > Organizations with large complex environments are in the best position to > find all their mail sources and get them configured properly for > SPF/DKIM/DMARC. Smaller organizations tend to lack the internal resources > and the knowledge to create and maintain proper implementations. > > Michael Hammer >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
