Subject: [dmarc-ietf] Forensic report loops

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Jan 2021 20:29:51 -0800

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.

As I recall, email routing loops are broken by simply counting the Received
fields, but a given forensic report is a new message each time, so a
mechanism like that won't work.

Off the top of my head, a few options:

1) a new header field indicating "This is a forensic report, don't generate
a forensic report about it."

2) some kind of token that's always in the Subject field of a DMARC
forensic report.

3) always generate forensic reports as the null sender, and specify that
forensic reports should never be generated in response to the null sender

4) something else?

-MSK

---

From: Steven M Jones <[email-masked]>
Date: Thu, 14 Jan 2021 01:22:10 -0800

> How are implementers dealing with forensic report loops?

The question of whether such a thing is actually ever seen in the wild
should be asked, if only to document that it was asked and answered. See
prior "this is a vanishingly small number who cares" discussions.

Channeling Dave, is it fair to just say the objective is: To ensure that
forensic reports do not ever cause the recipient of a forensic report to
generate another forensic report in response? Is that overly broad? Are
there other goals or conditions?

> 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.

Is there a functional or operational difference between aggregate and
forensic reports I'm not thinking of that would cause the solution for
one case to be unsuitable for the other? Or can we hope for a mechanism
that applies to all DMARC reports?

> 1) a new header field indicating "This is a forensic report, don't
> generate a forensic report about it."

Is there a reason somebody might use this new header in an abusive way?
Or include it in a forged forensic report to avoid exposure? Cue a 0.1%
of 0.1% sidebar...

Jumping ahead of those questions, would the new header have to be DKIM
signed by the report generator, and the entity /doing final delivery of
that report/ required to validate the DKIM signature(s) from the report
generator, and only generate a forensic report in response if this new
header is not present? Or if the signature didn't cover the new header?
Or if the signature couldn't be validated?

"Doing final delivery of that report" -- is that sufficient? Or, "any
entity processing the report and potentially generating a report in
response?"

> 2) some kind of token that's always in the Subject field of a DMARC
DMARC forensic report Subject: lines aren't uniform, but the last time I
looked there was an awful lot of similarity. If that were tightened up a
little more, would an explicit token really be necessary?

> 3) always generate forensic reports as the null sender, and specify
> that forensic reports should never be generated in response to the
> null sender

I suppose that would meet the goal, but what would be lost along the
way? What keeps coming to mind is the advice I've seen to have your
bounce messages authenticate with DMARC - if a sender does that or is in
the process of implementing it, they might want whatever forensic
reports they could potentially get...

cf.
https://www.validity.com/how-to-authenticate-your-bounce-messages-with-dmarc/

--S.

---

From: Juri Haberland <[email-masked]>
Date: Thu, 14 Jan 2021 11:36:36 +0100

> prior "this is a vanishingly small number who cares" discussions.

I had this happening twice with different (small) report receivers, so I
stopped sending failure reports alltogether.

Regards,
  Juri

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 14 Jan 2021 13:12:21 +0200

Hello,

> prior "this is a vanishingly small number who cares" discussions.

Imagine a case, where two sites sending forensic reports on failures
exchange messages and the one site is misconfigured: on each received
forensic report it sends a bounce, which bounce does not DMARC-align. 
This the same problem as with a misconfigured site sending Aggregate
reports, but does happen once a second, not once a day.  By sending
reports with return-path:<> you prevent the misconfigured recipient of
the report to generate a bounce, which bounce must DMARC-align, but
does not DMARC-align.

I want to remind on real-world cases addressed on this mailing list
• On 25 May 2019 with Subject “Is there any recommendation to send
DMARC message-specific failure reports FROM:<>”?
• On 31 May 2019 with Subject “Endless Email Loops with Aggregate
Reports”
• On 4 JUne 2019 with Subject “Endless Loops with DKIM reports” which
addresses reporting per “RFC 6651  Extensions to DKIM for Failure
Reporting” - this is not much different than forensic reports

that lead to https://trac.ietf.org/trac/dmarc/ticket/30 “Endless Email
Loops with Aggregate Reports”.

I have not read the thread “Ticket #28 - Failure report mail loops”.

A possible approach is not to send failure reports for messages
received on the address for accepting aggregate/forensic reports. 
These messages shall just be excluded from all calculations.

Does anybody compare the number of messages sent from her host1 to the
host2 of somebody else, with the number of reported messages in the
aggregate report?  If the numbers do not match, does somebody apply
negative spam weights for host2?

Greetings
  Дилян

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Jan 2021 07:24:33 -0800

> prior "this is a vanishingly small number who cares" discussions.

I'm asking the question in response to an actual use case.  Granted it's an
isolated case so far, but it comes from a not-insignificant organization
that probably handles a substantial email load, so at least for their side
this is already happening, or could happen, at scale.

> there other goals or conditions?

I believe that's exactly what I was asking for.

> that applies to all DMARC reports?

I don't see a reason why we need a different method for each report type.
The case in hand is forensic reports, but that's just part of the specific
incident to which I'm responding.

> Or include it in a forged forensic report to avoid exposure? Cue a 0.1%

I can't imagine one, but I'm running on little sleep at the moment.

> Or if the signature couldn't be validated?

Sure, those are all things to consider.

> entity processing the report and potentially generating a report in

I think you could put the check in either place.  Also fodder for
discussion of a solution.

> little more, would an explicit token really be necessary?

I don't particularly care for the idea of standardizing a Subject header
field value, or part of one, as a way of doing loop detection anyway, but I
thought I'd throw it in there just to round out the list.

> reports they could potentially get...

I'm also not a fan of the idea of treating different bounce messages in
different ways.  That seems like avoidable complexity.  Do we want to ever
send back a forensic report for something from the null sender,
irrespective of what's in it?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Jan 2021 07:28:17 -0800

> I have not read the thread “Ticket #28 - Failure report mail loops”.

Thanks, and apologies to the group; I should've checked for an open ticket
on this topic first.

This one recommends rate limiting rather than simpler "don't" type
guidance.  I think we can table this until that ticket is open.

> These messages shall just be excluded from all calculations.

That seems plausible, though less bulletproof than simply using the address
already reserved by the email standard for administrative messages.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 14 Jan 2021 17:04:07 +0100

On Thu 14/Jan/2021 16:24:33 +0100 Murray S. Kucherawy wrote:
>>> forensic reports should never be generated in response to the null
>>> sender >>
>> I suppose that would meet the goal, but what would be lost along the way?
>> What keeps coming to mind is the advice I've seen to have your bounce
>> messages authenticate with DMARC - if a sender does that or is in the
>> process of implementing it, they might want whatever forensic reports they
>> could potentially get...

Another way is to set the From: domain to a subdomain having a DMARC record 
with neither rua= nor ruf=.  I use noloop.tana.it for aggregate reports.

> send back a forensic report for something from the null sender, irrespective
> of what's in it?

It might be interesting to know if regular NDNs are authenticated all right. 
As they have the null sender, rule (3) prevents that feedback.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2021 12:35:40 -0500

In article <CAL0qLwZVWRFnaK1iqMC800GCt651xwu=dEqhz=[email-masked]> you write:
>-=-=-=-=-=-

Why isn't the solution to fix the sender's configuration so the reports
are aligned?  They're just mail messages.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 14 Jan 2021 09:50:47 -0800

On Thu, Jan 14, 2021 at 7:28 AM Murray S. Kucherawy <[email-masked]>
wrote:

> That seems plausible, though less bulletproof than simply using the
> address already reserved by the email standard for administrative messages.
>

I thought that we discussed that ticket and decided that the incidence of
problems was low enough to warrant a "WONT FIX" determination.

https://mailarchive.ietf.org/arch/browse/dmarc/?gbt=1&index=W3uGPEpT3Yi5lqKntZXyL8jkNjk

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Jan 2021 08:24:57 -0800

> https://mailarchive.ietf.org/arch/browse/dmarc/?gbt=1&index=W3uGPEpT3Yi5lqKntZXyL8jkNjk

We did, and if it had only ever come up exactly once, I might think nothing
of it.  But here it is again.  Now I'm inclined to think where there's
smoke there's fire, and this might require more consideration.

-MSK, participating

---

From: Douglas Foster <[email-masked]>
Date: Fri, 15 Jan 2021 16:31:30 -0500

I would think this should prevent problems if at least one complies:

Reports should be sent from a no-reply account so that any auto-reply will
be rejected as invalid recipient.   DMARC reporting SHOULD NOT occur for
such messages, even if the DATA section is accepted before rejecting or
discarding the message.

Report reception accounts should be dedicated to this purpose.
 Unacceptable incoming messages to this account SHOULD be excluded from
DMARC reporting, regardless of reason.  Accepted messages MAY also be
excluded from DMARC reporting.

Doug Foster

On Fri, Jan 15, 2021, 11:25 AM Murray S. Kucherawy <[email-masked]>
wrote:

> We did, and if it had only ever come up exactly once, I might think
> nothing of it.  But here it is again.  Now I'm inclined to think where
> there's smoke there's fire, and this might require more consideration.
>
> -MSK, participating
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Дилян Палаузов <[email-masked]>
Date: Fri, 15 Jan 2021 23:40:13 +0200

Hello,

Am Freitag, dem 15.01.2021 um 16:31 -0500 schrieb Douglas Foster:
> Reports should be sent from a no-reply account so that any auto-reply
> will be rejected as invalid recipient.   DMARC reporting SHOULD NOT
> occur for such messages, even if the DATA section is accepted before
> rejecting or discarding the message.
> 
>  Unacceptable incoming messages to this account SHOULD be excluded
> from DMARC reporting, regardless of reason.  Accepted messages MAY
> also be excluded from DMARC reporting.
> 

this text suggests WHAT to do, but not WHY to do it.  In my opinion any
suggested workflow shall be accomplished by problem description, so
that the implementers can understand the  rationale of the proposed
solution (and thus higher the chances, that the endless loops are
prevented).  I put the problem description in my previous mail on this
mailing list.

Greetings
  Дилян

> Doug Foster
> 
> On Fri, Jan 15, 2021, 11:25 AM Murray S. Kucherawy
> <[email-masked]> wrote:
> > > I thought that we discussed that ticket and decided that the
> > > incidence of problems was low enough to warrant a "WONT FIX"
> > > determination.
> > > 
> > >
> >
> > nothing of it.  But here it is again.  Now I'm inclined to think
> > where there's smoke there's fire, and this might require more
> > consideration.
> > 
> > -MSK, participating

---

From: "John Levine" <[email-masked]>
Date: 15 Jan 2021 22:40:26 -0500

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?

---

From: Douglas Foster <[email-masked]>
Date: Sat, 16 Jan 2021 08:21:57 -0500

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 <[email-masked]> wrote:

> In article <CAL0qLwaZx97cztehz_o=
> [email-masked]> you write:
> >-=-=-=-=-=-
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 16 Jan 2021 13:30:56 -0800

> ruf= that asks for the reports. What am I missing here?

You might be right, so I'll go back and ask this use case what the
specifics are.

What I'm concerned about is that since this has come up before N times
(for, admittedly, some currently small value of N), we've seen enough
disparate cases of it that we may be missing something bigger, and if so,
doing something defensive in the specification would be prudent.  There's
smoke here, and there may be fire.

Will report back.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 16 Jan 2021 17:20:19 -0500

> smoke here, and there may be fire.

OK, thanks.

My guess is that if we can track it down it is likely to be "my software 
is buggy so I want everyone else to work around it."

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Juri Haberland <[email-masked]>
Date: Sun, 17 Jan 2021 18:19:17 +0100

> is buggy so I want everyone else to work around it."

The cases that I had to deal with were misconfigurations on the other
side. I had to put these senders on some kind of ignore list to not send
out failure reports for their failing messages. That stopped the loop.

Regards,
  Juri

---

From: "John Levine" <[email-masked]>
Date: 17 Jan 2021 16:26:53 -0500

>out failure reports for their failing messages. That stopped the loop.

I believe you, but did the fail loop cause a significant load on your
system, or were they just ugly?

As I've said before, if they're sending unaligned mail and have an
ruf= to ask for reports, I'd think it fair to assume they'd want the
reports.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2021 12:58:56 +0100

> smoke here, and there may be fire.

Examining my report folder, I note I'm sending one-liner aggregate reports to 
domains I never wrote to.  The pattern is their sending me feedback for one or 
more mailing list posts, followed by my one-liner acknowledging their report 
later on the same day or on the next day, depending on their sending time.

It is not a loop, because I send from noloop.tana.it, which has no rua=.  I'm 
not alone using this trick.  Two naive report generators would continue to send 
one-liners indefinitely.

While this is a minor problem for aggregate reports, it can be a real problem 
for naive failure reports generators.  Juri reported he had to target a 
specific address, attributing the loop to a remote misconfiguration.  However, 
if it is possible to screw up authentications, the probability to meet a loop 
is just its square, times the number of generators.

The only prevention in the spec is to apply rate limiting.

I'd add a couple of loop-specific provisions:

* send reports from a subdomain having a DMARC record without ruf=,

* configure the verifier to not generate failures of messages destined to one's 
own ruf= address.

I shouldn't hurt, should it?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 27 Jan 2021 11:17:38 -0500

> domains I never wrote to.  The pattern is their sending me feedback for one 
> or more mailing list posts, followed by my one-liner acknowledging their 
> report later on the same day or on the next day, depending on their sending 
> time.

That's not a "loop", it's the way that DMARC reports work.

> specific address, attributing the loop to a remote misconfiguration. 
> However, if it is possible to screw up authentications, the probability to 
> meet a loop is just its square, times the number of generators.

If the authentication is screwed up, sending a failure report is exactly 
the right thing to do.  That's what they're for.

I think we should close this.  DMARC is working the way it is supposed to, 
and people don't want to get reports about their reports, there are 
obvious ways to prevent them, like not sending unaligned reports, or 
sending reports from a domain that doesn't get reports back.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2021 19:08:46 +0100

On Wed 27/Jan/2021 17:17:38 +0100 John R Levine wrote:
> 
>> While [loops are] a minor problem for aggregate reports, it can be a real problem 
> If the authentication is screwed up, sending a failure report is exactly the 
> right thing to do.  That's what they're for.

Even if the screwed up message was a failure report itself?

> I think we should close this.  DMARC is working the way it is supposed to, and 
> people don't want to get reports about their reports, there are obvious ways to 
> prevent them, like not sending unaligned reports,

Oh, there is a sentence in the current spec:

    Email streams carrying DMARC feedback data MUST conform to the DMARC
    mechanism, thereby resulting in an aligned "pass" (see Section 3.1).

As it stands, it's valid for both aggregate and failure reports.  However, it 
happened to land on the aggregate-reporting I-D only.

> or sending reports from a domain that doesn't get reports back.

That was one of the hints I proposed.  Your wording is better.  Added this:

3.3.  Transport

    Email streams carrying DMARC failure reports MUST conform to the
    DMARC mechanism, thereby resulting in an aligned "pass".  Special
    care must be taken for authentication, as failure to authenticate
    failure reports may result in mail loops.  Besides rate limiting,
    such loops can also be avoided by sending reports from a domain that
    doesn't get reports back.

Is that all right?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 27 Jan 2021 13:38:08 -0500

> Even if the screwed up message was a failure report itself?

Of course.  The failure repoort is a new e-mail message.  If it's not 
aligned, your code needs to be fixed.

>   failure reports may result in mail loops.

Stop there.  If you don't want failure reports, don't send unaligned 
messages.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Jan 2021 12:13:02 -0800

> Stop there.  If you don't want failure reports, don't send unaligned

I could be sold on the idea that there's not a problem for us to fix in the
protocol here, but what about the notion that it's something that might
warrant a sentence or two of informative text (i.e., that this is a problem
that can occur and possibly cause operational pressure)?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 27 Jan 2021 15:37:13 -0500

I still don't understand why failure reports about messages that
happen to be failure reports are in any way special.

The report is after all a brand new message which I would hope is sent
the way tou send any other message, and should be aligned if the rest
of your mail is.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Jan 2021 12:47:13 -0800

> happen to be failure reports are in any way special.

Loop detection in RFC 5321 is a normative MUST because of the obvious
operational problems it creates.  Maybe I'm being thick, but right now I
don't see how this is different, apart from the fact that each message is
distinct; you're still causing a problem by turning this on without a care
in the world about whether two verifiers start spamming each other.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 27 Jan 2021 22:08:39 -0500

On Wed, 27 Jan 2021, Murray S. Kucherawy wrote:
>> I still don't understand why failure reports about messages that happen 
>> to be failure reports are in any way special.
>
> distinct; ...

Here's perhaps another way to look at it.

Imagine that I am a semi-competent mail server operator.  I hear that 
DMARC is great stuff and I set up DMARC software on my server including 
sending and processing reports.

Unfortunately, my l33t coding skillz aren't quite up to it, and my failure 
reports are all unaligned.  Also, I'm not very good at reading specs and 
my reports aren't in the right format either.  (Not making this up, I have 
lots of failure reports that are not multipart/report.)

Oh, no!  People are sending me failure reports about my failure reports! 
Make it stop!

Which of these should we do:

A) Everyone in the world who produces failure reports adds special cases 
to look for incoming failure reports, and heuristics to try and recognize 
failure reports in the wrong format, and when it finds one of them, it 
makes a note not to send a failure report about it.

B) Someone slaps me upside the head and I fix my SPF record so my reports 
are sent correctly.

This does not strike me as a hard problem.

Regards,

---

From: Steven M Jones <[email-masked]>
Date: Wed, 27 Jan 2021 19:17:06 -0800

On 1/27/21 12:47, Murray S. Kucherawy wrote:
> On Wed, Jan 27, 2021 at 12:37 PM John Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> operational problems it creates.  Maybe I'm being thick, but right now
> I don't see how this is different, apart from the fact that each
> message is distinct; you're still causing a problem by turning this on
> without a care in the world about whether two verifiers start spamming
> each other.

There's coverage in 7489 Section 7.2 that a domain owner can
inadvertently DDoS themselves via failure reports. And that still
surprised many implementers, even though it seemed obvious to them in
retrospect.

This case is even less obvious, and we still have questions coming in
about it from new implementers.

I don't think it's a security consideration because it doesn't scale up
the way "ruf" can, so it deserves a brief mention here. But I would
rephrase Ale's last sentence:

3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken for authentication, as failure to authenticate
   failure reports may result in mail loops.  These loops can be mitigated
   by sending reports from a domain or subdomain that doesn't request
   reports, or by performing rate limiting for report receiving mailboxes.

--S.

---

From: Steven M Jones <[email-masked]>
Date: Wed, 27 Jan 2021 19:20:07 -0800

On 1/27/21 19:08, John R Levine wrote:
> ...
> B) Someone slaps me upside the head and I fix my SPF record so my
> reports are sent correctly.
>

It's not a hard problem. I see the last sentence in Section 3.3 as
reserving the right to deliver that slap...

--S.

---

From: Douglas Foster <[email-masked]>
Date: Wed, 27 Jan 2021 22:57:03 -0500

Loops require two parties.  Any one party can protect both parties by
choosing to not perpetuate the loop.

Saying that "the other guy" should be smarter seems wishful thinking.  Of
course some other people will act stupidly.  Fixing that problem is not in
my scope.   Having their mistakes interfere with my system's normal
operation is not an option that I am willing to permit.

DF

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Jan 2021 13:41:55 +0100

On Thu 28/Jan/2021 04:17:06 +0100 Steven M Jones wrote:
>> On Wed, Jan 27, 2021 at 12:37 PM John Levine wrote:
>>
>>> to be failure reports are in any way special. >>
>> in the world about whether two verifiers start spamming each other. >
> There's coverage in 7489 Section 7.2 that a domain owner can inadvertently
> DDoS themselves via failure reports. And that still surprised many
> implementers, even though it seemed obvious to them in retrospect. >
> This case is even less obvious, and we still have questions coming in about
> it from new implementers. >

I rephrased it further:

3.3.  Transport

    Email streams carrying DMARC failure reports MUST conform to the
    DMARC mechanism, thereby resulting in an aligned "pass".  Special
    care must be taken of authentication, as failure to authenticate
    failure reports may result in mail loops.  These loops can be
    mitigated by sending reports from a domain or subdomain that doesn't
    request reports, or by performing rate limiting especially for
    failures related to messages received at addresses published in a
    ruf= tag.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jan 2021 12:59:36 -0800

> B) Someone slaps me upside the head and I fix my SPF record so my reports

I'm suggesting:

C) Stipulate somehow that generated reports should not contain data about
received reports.  (If you do that, then you likely obviate the need to
generate a new report back to that operator in the first place.)

This to me is almost exactly the same thing as saying "Don't generate a
bounce about a bounce", which has been part of SMTP for decades (it's a
SHOULD NOT in 2821).  I don't understand why you're saying it's appropriate
in one but a non-issue in the other.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 28 Jan 2021 16:42:09 -0500

> generate a new report back to that operator in the first place.)

I can't even tell what might be a failure report without deep parsing and 
heuristics.  And, of course, I am not inclined to add extra code to 
program around other people's bugs.

> 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.

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.

Maybe I'm dim, but I am having no success understanding the apparent 
interpretion of ruf as "tell me about the unaligned messages I'm sending, 
except for some that should be really easy for me to fix."

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jan 2021 17:15:01 -0800

> relation to anything about the recipient address.

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

> ruf= tag, it is specifically asking to be inforned about exactly that

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

---

From: "John R Levine" <[email-masked]>
Date: 28 Jan 2021 20:30:04 -0500

> flooded, even though my local setup is verifiably correct.  And, probably,

Report floods could be a problem, but they're a general problem that don't 
have a lot to do with failure loops.  I used to get buckets of failure 
reports about random chinese spam that forged my domains on the From line.

It's reasonable to say that reporters should rate limit failure reports to 
avoid flooding recipients, but that's true no matter who sent the mail 
being reported.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 29 Jan 2021 16:00:05 -0500

In article <[email-masked]> you write:
>    failure reports may provoke further reports.

    Reporters SHOULD rate limit the number of failure reports sent
    to any recipient to avoid overloading recipient systems.

Why would reports due to a mail loop be more of a problem than due to
some random spammer sending a lot of fake mail, or (real life) your
users send mail to mailing lists with thousands of subscribers? Rate
limit your reports, don't worry about where they came from.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sat, 30 Jan 2021 07:51:56 -0500

Interesting point.

In your experience, how often does reporting produce any change in sender
behavior?

I have made attempts both to help senders correct their own SPF or DMARC
policy, or to get them to stop violating my DMARC policy.   As best I can
recall, my success rate has been zero.

For a responsive organization, finding a problem and getting the change
approved is likely to be a time-consuming a quick process.   A week
turnaround would seem timely, unless they go into emergency mode because
lots of mail is being blocked.

The spec is confusing because it says (a) failure reports should be sent
immediately, (b) failure reports should be aggregated, and (c) failure
reports should be throttled but without specifying a limit.

Of course, if the cause is a spammer, there is nothing that the domain
owner can do at all.

I wonder if the rule should be one message per week per source, since any
large volume sender will be getting reports from multiple sources.   The
main problem with this is that law enforcement actions may want to be
bombed.

DF

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Jan 2021 12:30:56 +0100

On Sat 30/Jan/2021 13:51:56 +0100 Douglas Foster wrote:
> [...]

This point deserves its own ticket.  While we have a ri= tag (to be revised, 
see Tickets #50 and #71) and !size limits for aggregate reports, failure report 
consumers don't have a way to express the amount or frequency of feedback they 
want.

>>     to any recipient to avoid overloading recipient systems.

I haven't yet modified this, but I mostly agree.

>> limit your reports, don't worry about where they came from.

Rate limiting usually implies a number of buckets.  They are managed by 
imposing limits per time periods, which can be either server-global or per 
bucket.  Normally, for MSA usage, one has one bucket per user.  I have never 
implemented failure reporting, but I'd guess buckets may vary.  Besides the 
signing domain (which determines the report consumer), the receiving address, 
the sender and the spam flag may deserve their own buckets.

Thoughts?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 31 Jan 2021 15:02:38 -0500

>the sender and the spam flag may deserve their own buckets.

The only one that matters for DMARC reporting is the recipient
address, since the purpose of rate limiting is to avoid overloading
the recipient mail system. I wouldn't worry about trying to send a
"representative" set of reports.

Keep in mind that very few people send failure reports at all. In my
experience few of them are useful. Most of mine are ordinary mailing
list messages where the failure is not surprising and does not mean
that anything needs to be fixed.

R's,
John