As to possible actions based on the previous list: Fix originator issues.
Weaken policy back to p=nine. Open tickets with outbound gateway vendor or change vendors. Direct employees to cease participation in personal mailing lists using work accounts. Work with intended recipient to submit a request to his admin for a change in their filtering policy. Contact legitimate impersonators with complaint asking them to cease and fdesist. Both this list and previous list may be incomplete, but you get the idea. Doug On Sat, Jun 14, 2025, 10:00 AM Douglas Foster < [email protected]> wrote: > Possible causes of failure result in an aggregate report: > Originator error > Outbound gateway changes, particularly ARC failures that become > significant because of downstream forwarding > Forwarding without changes and with DKIM signature. (Lack of signature is > really an originator error) > Forwarding with changes without forwarder ARC Set > Forwarding with changes with ARC that evaluator ignores > Reporting that is based on message state after inbound gateway makes > changes, even though the message was delivered. ( A problem unique to > outlook.com) > Acceptable ( non-malicoous) impersonation > Unacceptable or malicious impersonation > > Failure reports with message headers will help to distinguish these > possibilities from each other. > > The challenge is replication problem. The domain owner does not need the > same information thousands of times, especially if the replication comes > from the same source. > > Doug > > > On Sat, Jun 14, 2025, 4:19 AM Alessandro Vesely <[email protected]> wrote: > >> On Sat 14/Jun/2025 04:58:13 +0200 John R Levine wrote: >> > On Fri, 13 Jun 2025, Alessandro Vesely wrote: >> >> On Wed 11/Jun/2025 13:56:50 +0200 John R Levine wrote: >> >>> >> >>> I really do not understand what point you are making here. People >> find >> >>> aggregate reports useful enough to build businesses around them. But >> >>> failure reports are useless. >> >> >> >> I can hardly believe it. Unless you're getting a reward for receiving >> >> useless messages, why on earth do you have this record? [ with ruf= ] >> > >> > I set up my DMARC records in 2012 and have been collecting reports for >> the past >> > 13 years. I have gotten 597,000 aggregate reports and 93,000 failure >> reports. >> > All of the failure reports take up less than 800MB, an insignificant >> amount of >> > disk space these days. A little script puts summary into info a >> database which >> > is another 32MB. >> > >> > The reason I know that failure reports are useless is that I have a >> collection >> > from over a decade and the most interesting thing they've ever told me >> is who >> > at LinkedIn subscribes to the same mailing lists I do. >> >> >> That's the mailing list problem in action. It could be tackled by asking >> the >> report generators to omit reporting failures due to mailing lists, e.g. >> through >> subscriptions tracking. Had we solved this problem, you would not have >> received any reports, which wouldn't be sufficient to conclude that they >> are >> useless. >> >> >> Best >> Ale >> -- >> >> >> >> >> _______________________________________________ >> dmarc mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
