On Mon, Aug 8, 2022 at 4:14 AM Alessandro Vesely <ves...@tana.it> wrote:
> On Sun 07/Aug/2022 19:20:12 +0200 John Levine wrote: > >>> By remembering failure reports issued in the past, new failures having > >>> already reported characteristics (e.g. same forwarder) can be silently > >>> ignored. That would greatly reduce noise. > >> > >> This is a horrible idea. It presupposes that failures from the same > origin > >> (e.g. same forwarder) at different points in time are the result of the > >> same underlying cause. This may be true in some cases but not true in > other > >> cases. Operational environments are not static. Even for short time > frames > >> this is a bad approach. > > > > It also misses the fact that "already reported characteristics" is > > undefined. > > > Right, that's to be defined. Clearly, the criteria differ between SPF and > DKIM. We could also define fuzzy criteria. > > > > We have plenty of work already without inventing more. Let's agree not > to > > do this and get back to work on what we've already agreed to do. > > > Does "not to do this" refer to failure reporting as a whole? > > As is, it is a noise generator that the majority of users decided not to > implement. > When "we" (dmarc.org team) originally came up with DMARC, the goal was to take what was in essence a private club to an open standard that anyone could benefit from. My personal take is that validators choose not to provide failure reporting for various reasons other than "it's a noise generator". It requires extra effort and resources that some validators choose not to undertake because it doesn't benefit them (from their perspective). Another reason some validators don't implement is fear of potential liability under GDPR or similar regimes. There are a number of validators that provide failure reports through private channels but only where a direct or indirect contractual relationship exists. This seems to primarily through intermediaries that provide email authentication services. Michael Hammer > > > Best > Ale > -- > > > > > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
