On Thu, Dec 8, 2022 at 1:59 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> > 1) DMARC was a successful 2-company experiment, which was turned into a > widely implemented informational RFP. We are now writing the > standards-track version of that concept. We hope that Standards Track will > provide the basis for significantly increased adoption. This seems the > appropriate time to ask whether the design can be optimized for > efficiency. If you were designing from scratch, would this reporting > design be the result? What alternatives have we considered and ruled out? > You clearly don't know what you are talking about. There were a number of organizations involved in the original DMARC effort. I represented one of the participating organizations. Participating organizations included Senders (Financials, Social Media companies, other Brands and Publishers), Mailbox Providers and Intermediaries. There was a predecessor effort, which included a number of organizations, and was organized by J.D. Falk (Yahoo!)called MOOCOW. Another predecessor effort was organized by Ironport (Pat Peterson) and also included a number of organizations. I am arguably the first person to publicly ask receivers to reject mail that did not pass either DKIM or aligned SPF. That was in 2007 (more than 5 years before DMARC was published and before the DMARC.ORG team was organized. My public posts (using my then corporate email account) can be found on the DKIM-OPS list and SPF related lists. At the time there were only a couple of large mailbox providers which could do anything with those assertions and they could only provide chunks of mail logs for us (under contractual relationship) for us to mutually discuss and evaluate what was going on. I'm not writing this to brag on what I was doing but to make it clear that your assertion that DMARC " was a successful 2-company experiment" is absolutely incorrect and inaccurate. Please provide the source of your incorrect assertion. > > 2) The burden of reporting is not experienced equally by all report > senders. If I send a batch of messages from 1 source domain to: > - 10 target domains at Google, I will get 1 report, because Google > consolidates across target domains. > - 10 target domains at Yahoo, I will get 10 reports, because Yahoo chooses > to disaggregate by target domain. > - 10 target domains to Ironport clients, I will get 20 or 30 reports. > These are client-specific appliances, many clients have multiple appliances > configured in parallel for load balancing, and each appliance produces its > own report. > > Google presumably can dedicate servers to the reporting function, while > the Ironport servers seem to generate reports in parallel with message > processing. Altogether, I conclude that Google can absorb an increase in > workload much more easily than an appliance > > 3) The burden of reporting is not shared equally at present. > Substantially all of my reporting comes from the three sources just > stated: Google, Yahoo, and Ironport appliances. Since these > organizations have not been actively participating, perhaps you are right > and they are happy with the present design. On the other hand, perhaps > someone with connections should ask them whether they want to see > optimizations. > > I'll fix this for you. Ironport appliances are sold by Cisco. I was one of the first customers of Ironport (before they were even called Ironport they used the codename "Godspeed") and helped them by giving feedback on development of their "A" series (optimized for outbound email) appliances. Cisco bought them (to fill a gap in their product offerings) and subsequently focused on development of their "S" (security) line of devices. Cisco also reduced Ironport support for standards development in this space. After that a number of key Ironport employees went on to found companies which have been very supportive of efforts in this space. Several of note are Pat Peterson (Founded Agari) and Tim Draegen (Founded DMARCIAN). > > 4) As DMARC participation grows, the growth curve is not really linear. > Currently, 40% of my mailstream is covered by DMARC reporting because more > than 30% of my outbound mail goes to Google servers. Altogether, the > number of reporting domains, from all sources, is somewhere around 40. To > move reporting from 40% of messages to 40% of domains, the volume of > reports will grow by orders of magnitude. > > 5) Which then raises the question of, "Who do we expect to do reporting?" > Several participants in this group have expressed the conviction that > everyone who benefits from DMARC should also contribute to DMARC by doing > reporting. This seems fair, but it is probably not necessary. > Reporting from Google alone is probably sufficient for domain owners to > know whether or not their servers are properly configured. But as long > as we want everyone to participate, we cannot assume that everyone will > have Google's resources to contribute to the reporting task. > > All of which says to me that we should be looking to optimize the > reporting function to minimize the cost of participation. > Email implementations - both outbound and inbound - are not standardized from an operational perspective. Different implementations have different architectures. Business and other considerations impact the choices of different organizations. A number of organizations participate in M3AAWG.ORG and discuss these sorts of email issues there. Granted that it is pay-to-play AND their (non-financial) membership criteria must be met. The DMARC-IETF working group is open to anyone that wants to participate. People express all sorts of wants in the group. That doesn't mean those wants will be fulfilled. There only needs to be a certain threshold of reporting for senders to know if their outbound implementations are properly configured. The real benefit of broader reporting is visibility into where and how wide abuse of a sender's domain(s) is targeted. Presumably a receiver/validator is for the most part (except for local policy choices), for domains for which they are providing reporting, are respecting sender policy requests. Domains which do not provide reporting leave a blind spot for senders (Is that receiver simply not providing reporting or are they not implementing DMARC at all?) Other than with regard to interoperability, this working group is not in a position to tell organizations what they will or will not do. (See King Canute). For a given organization, issues such as privacy, anti-abuse (Why would I send any information at all to a malicious sender, whether based on DMARC, bounce logs or through any other mechanism?) or other considerations impact their decisions. It may be that DMARC reporting is way down the priority list for their product/service roadmap. It may be that the juice is simply not worth the squeeze. While smaller implementations should be considered in an IETF working group, adding hundreds of reports from hundreds of domains that receive hundreds of emails a day from me isn't even a rounding error for my mail streams. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
