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

Reply via email to