I thought I was adding precision to the vague generalities in the draft. I am all for anti-abuse. I agree that the primary benefit of failure reporting is anti-abuse. Others are correct in saying that there are other ways to solve most DKIM problems.
For smaller players, the hope is that the failure report recipient organization will be a bigger entity with better options for fighting abusers. If anti-abuse requires essentially every incident to trigger a report, then the document should be clear that such is the intended norm. In that case, any lesser volume is merely deference to the reality that mail senders will only do what they are willing. If we aggregate at all, including the local-part in the grouping rule will defeat the attempt to aggrehate. Too many addresses have encoding that creates uniqueness or near uniqueness, even when the nominal mailbox recurs. IP drives the investigation to a specific machine (or organization exit path) and SMTP domain drives the investigation to a specific administrative context on the source server or source organization. Overall, any higher level of aggregation loses context, and any lower level of aggregation becomes too granular. Leaving things for the developer to guess about aggregation strategies seems like a terrible idea. Being able to to assess whether aggregated reports from different sources are about similar or different problems seemed important to me. If every incident gets a report, then maybe the issue is less important because the full message parse will give the answer eventually. Doug On Thu, Jul 3, 2025, 8:45 AM Dotzero <[email protected]> wrote: > > > On Thu, Jul 3, 2025 at 7:50 AM Douglas Foster < > [email protected]> wrote: > >> I believe the reporting strategy needs to be defined in more detail than >> provided in section 2, because we need to ensure that report volumes are >> manageable for both sender and receiver, and to ensure that receivers can >> make sense of multiple reports from multiple sources. Leaving this issue >> to the imagination of each implementer will cause interoperability problems. >> >> . I propose the following: >> >> Reporting Frequency >> "The aim of failure reporting is not to count each and every failure, but >> rather to report different failure conditions." These design >> considerations apply to this goal: >> >> A failure condition is defined as a unique combination of RFC5322.From >> Domain, RFC5321.MailFrom domain, and source IP address. This corresponds >> to the three parameters of the SPF alignment test. It also provides enough >> granularity so that separate problems are likely to be reported >> separately. This approach also helps a report receiver classify whether >> reports from different receivers represent different conditions or multiple >> information sources about a single condition. >> >> Failure reports need to be repeated periodically, to ensure that the >> receiver has sufficient information to solve the problem, to ensure that >> failure conditions are not overlooked, and to provide clarity about whether >> a condition is resolved or not. However, excessive reporting will hinder >> efforts to solve known problems, and may cause report senders or report >> recipients to cease participation in failure reporting. >> >> Some failure conditions will represent crises that require a prompt >> response, some failure conditions will involve complexity that takes time >> to resolve, and some failure conditions will be unsolvable. The reporting >> frequency needs to correspond to these situations. >> >> Given these considerations, the following guidelines are provided: >> >> New failure conditions should be reported promptly. The initial report >> will generally represent a single message, but may represent multiple >> messages if a cluster of messages are received together. >> >> After the initial report is sent, no more reports are sent until the end >> of a time interval. The time interval is gradually increased so that the >> volume of reports on a single condition declines. >> >> The following reporting intervals are recommended: >> After the initial report, send additional reports at hourly intervals if >> additional failures occur. >> After the first day, send additional reports at daily intervals if >> additional failures occur. >> After two weeks, send additional reports at weekly intervals until the >> problem is resolved or the administrator concludes that further reporting >> is not useful. >> >> Doug Foster >> > > I'm going to have to think about this. What you propose limits the amount > of information to the report recipient. I'm a security/anti-abuse person. > The number of reports in an abuse situation gives me information about > scale and scope of an attack. Is it targeting one receiver domain or > multiple ones and at what scale? An attacker can also switch up the URLs > contained in the emails even though the failure "types" may look the same. > The useful information is in parsing the individual reports. > > My next concern is the additional burden you are placing on report > providers. At the moment there is absolutely no running code at all which > supports what you are proposing. Looking at the recharter I would take the > position that such changed (expanded) requirements are beyond the scope of > what we are charged with doing. > > I'm also not sure that your proposed changes are necessary. Your focus > appears to be on validation/delivery issues from a legitimate sender rather > than abuse. In that case, for each report received by a sending domain, > they have sent an outbound email to the reporting domain. If they have the > resources to send that outbound email they should have the resources to > receive the failure reports. Even in the case where they are overwhelmed > with failure reports resulting from abuse, they can always send those > reports straight to /dev/null as needed. I always recommend having a > separate host or pool of hosts for reports to avoid potentially impacting > regular inbound mail flows. > > As I wrote at the beginning of the post, I will have to think on this. > > Michael Hammer >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
