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

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jan 28, 2021 at 1:42 PM John R Levine <[e-mail]> wrote:

> > This to me is almost exactly the same thing as saying "Don't generate a
> > bounce about a bounce",
>
> Because these are not bounces.  They are not even a little bit like
> bounces.  Bounces are about invalid recipient addresses, but these have no
> relation to anything about the recipient address.
>

Yes, I realize the difference.  I was making an analogy.

They are fresh new messages sent from a system that presumably cares
> enough about DMARC to send reports about it, and presumably wants to send
> all of its mail with DMARC alignment.  If they are unaligned, that is
> because the sending system is broken, and if that systems publishes an
> ruf= tag, it is specifically asking to be inforned about exactly that
> breakage.
>

OK, let's hop into your example.  I care enough about DMARC to send reports
about it, and I want to send all of my mail aligned.  I send a test message
that ends up unaligned somehow, perhaps through a broken relay I don't own,
and I would ideally like to get one message back that tells me that.  If I
happen to send my test to a place that unintentionally sends an unaligned
report back to me, perhaps because of the same relay, I'm going to get
flooded, even though my local setup is verifiably correct.  And, probably,
so are they.

You're saying the only real answer here is that the two end operators in
this example need to fix their evidently-crappy setups, or change their DNS
records to remove the "ruf" value until they can get the guy in the middle
to fix whatever's broken?

Maybe I'm the dim one, but I can't see why it's manifestly absurd to think
we might somehow augment either the report or the message containing it by
adding just enough metadata someplace to signal one end or the other, or
both, to avert the flood.

-MSK