I was not trying to be harsh. I actually have no problem with the profit motive, and was only trying to acknowledge the answer to my question. However, you raise points that have also been on my mind. To the extent that non-participation is caused by cost or data leakage, our documents can do a lot to reduce those objections.
I have already observed that eliminating the request for every signature would be a good place to start simplifying. Multiple people in this group asserted that those signatures might be useful to someone sometime, but nobody was able to say, "I know that the extra signatures were helpful to this specific person in this specific situation." If we cannot point to specific use case, we must not have a very significant need. Early on, I suggested that we have a failures-only reporting option. A mail system domain manager needs only one successful test to prove that his system is configured properly. Thereafter, he only needs to know about failures. On the other hand, any alarm system needs an occasional test to prove that it is still working correctly, so we need an occasional way to generate success reports. Unfortunately, our present design sends thousands (millions?) of success-only reports, every day, so that the recipients will know that the system will work if and when a failure is detected. If we have any sympathy for the costs imposed on the organizations that are sending reports, we should rethink that balance. Data leakage is also a legitimate concern. Once a sender knows that his system is configured correctly, DMARC aggregate reports become a tool for mail-sending domain owners to do surveillance on mail-receiving domain owners. Despite my initial complaints, I have been able to accurately match my aggregate reports to my outgoing messages. For each report source, I know whether they report for all domains or only some domains, and for those who only report on some domains, I have been able to detect which domains are being reported and which are being omitted. This is a problem. DMARC is supposed to help evaluators make better disposition decisions by helping mail-sending domains ensure that their messages can be authenticated. It should not become a tool for attackers to better understand the security posture of the recipient. Placing a limit on success reporting cannot entirely eliminate this risk, but it would make systematic data collection more difficult. Doug On Sun, Nov 20, 2022 at 8:14 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Sun, Nov 20, 2022 at 11:33 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> That is helpful, thank you. It says to me that their non-participation >> does not have any direct implications for what we are trying to do. >> >> Specifically, it is not that DMARC has too many false positives, or that >> the processing effort is unacceptable. It is simply a reflection of their >> assessment that valuable information should be purchased from them, not >> given away for free. >> > > I think this is a bit of a cynical viewpoint. There are other simpler > reasons not to participate in reporting. Off the top of my head: > > 1) It is a non-trivial compute, storage, and maintenance cost a report > generator has to undertake, proportional to the amount of mail they handle, > and is done largely for the benefit of others. > > 2) The policy part of the protocol works just fine, and is a benefit, > without the reporting component. > > 3) There are risks of privacy leaks, either actual or perceived (or both). > > Many operators' business models would find any one of these hard to > swallow, much less all of them in combination. > > -MSK, participating >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
