Re: [dmarc-ietf] Forensic report loops are not a problem

[Douglas Foster <[e-mail]>]

1) Because loop prevention is easily defined.
2) Because loop prevention is easier and simpler and less stressful to
implement than loop correction.
3) Because changing DNS to fix a loop is too slow.
4) Because a loop could be triggered by a malicious spammer, and the
feedback becomes backscatter.
5) Because DMARC reports are courtesy messages for the benefit of the
sender.   The sender has no significant interest in whether the message is
accepted or not.
6) Because loops cause congestion that affect other traffic
7) Because we have reports from the wild which indicate that loops have
actually occurred

Is that enough?

On Fri, Jan 15, 2021 at 10:40 PM John Levine <[e-mail]> wrote:

> In article <CAL0qLwaZx97cztehz_o=
> [e-mail]> you write:
> >-=-=-=-=-=-
> >
> >How are implementers dealing with forensic report loops?
> >
> >Say I send a message from X to Y, whose DKIM signature fails.  Y sends me
> >back a forensic report, whose DKIM signature also fails.  X sends a
> >forensic report to Y, whose report fails, etc.  We need a way to break the
> >loop.
>
> If the reports are unaligned and their domain is requesting failure
> reports, sending reports about the failure is exactly the right thing
> to do.
>
> I still don't understand why anyone thinks there is a problem to be
> fixed. If you don't want reports, don't ask for them. If you think the
> mail you send shouldn't be provoking DMARC failure reports, adjust
> whatever is sending the mail the mail is aligned, or get rid of the
> ruf= that asks for the reports. What am I missing here?
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>