Quantities -------------- I can see that FAIL quantities could be useful for motivating law enforcement. It has the advantage of installed code and relatively little processing cost. But to Murray's specific questions:
Yes, reporting quantity 1 is an inconsistency with the specification. This source also fails to provide the DKIM scope ID, which is another inconsistency. My point was that it caused me to wonder whether quantity was necessary. The source server is being scored, not the mail messages, so it seems that all that is needed for reporting is "all pass", "all fail", or "some pass and fail". I have the impression that DMARC is not intended to meet the delivery scoring needs of domain owners, so giving an accounting of all mail is not required. I don't see a problem with dual path, because all reporting includes the Source IP. Servers will fall into one of a very few categories, and even fewer response actions. The possible states and the domain owner responses are: - The Source IP server is an authorized message originator and produces DMARC PASS. No action required. - The Source IP server is an authorized message originator and produces DMARC FAIL. This needs to be fixed. - The Source IP server is a forwarder and produces DMARC PASS based on DKIM. The DKIM Scope tells me where the message originated. No action required. - The Source IP server is an unauthorized originator, or a content-modifying forwarder, which produces DMARC FAIL. A failed DKIM scope ID may tell me where the message originated. Nothing much can be done about the apparent impersonation unless law enforcement takes interest. Signature Counts ----------------------- I am less impressed by the argument for multiple DKIM signatures. As Mark said, they might be useful if (a) I send a message that is not signed by my own domain, (b) is signed by the hosting service, (c) the messages are forwarded so that the originating Source IP is not reported, and (d) the forwarder signs the message during the forwarder. If only one message is reported, the forwarder's signature may displace the hosting service signature, leaving me with no information about which source servers have a problem. This complicated case only matters if I have no reporting from direct-delivery destinations, which seems very unlikely. On the other hand, tracking and reporting of multiple signatures causes an increase in software complexity, data usage, and reporting effort. DF On Sun, Dec 11, 2022 at 10:34 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Sun, Dec 11, 2022 at 12:21 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> 2) What to include in reports >> I have one reporting source that always reports a message count of 1, >> without regard to the number of messages that I sent and he received. >> > > Perhaps I'm misunderstanding, but isn't that a bug? > > >> This helped me realize that there is no need to report quantity. A >> correctly configured server will apply a correct signature on every >> message. Whether the problem is uniform or random, all that the domain >> owner needs to know is that a particular server is not signing correctly. >> >> > > Doesn't this presuppose that not only will the server always apply > signatures correctly, but the path such messages take to that recipient > never varies, nor does the handling practices of all agents in between? > > For instance, this message will be delivered to you twice, once via direct > connection and once via the DMARC list. They may have very different > results. You only want one of them? Which one do you care about and why? > > >> And as I have said before, collecting every signature adds unnecessary >> complication to the reporting process, while adding no value to the domain >> owner. All that needs to be reported is one aligned signature, because >> the domain owner's server only needs to apply one aligned signature. >> >> These changes would reduce the overhead reporting, especially for smaller >> organizations where the effort is not noise level. They would also reduce >> the risk of unwanted data leakage. >> >> But I am willing to be convinced. Can someone explain how success >> reports, message counts, or unaligned signatures serve a domain owner >> purpose which is relevant to DMARC? >> > > If I am a domain owner and I know I sent N messages to M distinct domains, > I expect (assuming universal participation) to get M reports back that, > added up, account for N messages, irrespective of whether they passed. > Anything else is lossy, and I believe I'm not getting a clear picture of my > overall mail flow. > > If our reporting is going to reflect only a subset of this, we need to > explain what that subset is and why that's better than providing something > complete. > > -MSK >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
