Subject: Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

From: Alessandro Vesely <[email-masked]>
Date: Mon, 1 Feb 2021 13:32:10 +0100

On Sun 31/Jan/2021 21:02:38 +0100 John Levine wrote:
> In article <[email-masked]> you write:
>>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.
> 
> 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.

True, it's not worth suggesting a super duper rate limiting.

Committed text:

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.

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

Not MUST?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 1 Feb 2021 11:29:23 -0500

>   recipient to avoid overloading recipient systems.

You might have other ways to prevent mailbombing, e.g., only sending 
failure reports to people who you know have bigger mail systems than you 
do.

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

---

From: Dotzero <[email-masked]>
Date: Mon, 1 Feb 2021 16:58:17 -0500

> Keep in mind that very few people send failure reports at all.

My experience is that most failure reports are provided through private
channels where there are contractual agreements in place to deal with
potential privacy and legal issues. This may be through intermediaries or
direct between the parties (sending organization and receiving
organization).

Understand that the DMARC effort came about because the original
participants felt it was useful in the private exchange of information
between senders and receivers. We felt it was better as an open standard
rather than as a private club.

>From my perspective it is unfortunate that we can't seem to find a way to
implement a system where failure reports are available other than through
private channels.

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

I disagree with John about failure reports not being useful.  I have found
failure reports to be extremely useful in anti-abuse efforts. The value can
range from takedowns of images and links to maliciousness to shutting down
sources of maliciousness.In some cases it has proven useful to law
enforcement as documentation of activities.

Unfortunately, I think addressing some of this has to be beyond the scope
of the current effort.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Feb 2021 12:40:07 +0100

On Mon 01/Feb/2021 17:29:23 +0100 John R Levine wrote:
> You might have other ways to prevent mailbombing, e.g., only sending failure 
> reports to people who you know have bigger mail systems than you do.

Right.  However, Murray recalled Section 6.3 of SMTP:

                           Whatever mechanisms are used, servers MUST
    contain provisions for detecting and stopping trivial loops.

Mailbombing in general is not a loop.  Two report generators reporting each 
other's failure to authenticate a failure report /is/ a loop.  So it deserves a 
MUST.  Perhaps:

    Reporters SHOULD rate limit the number of failure reports sent to any
    recipient to avoid overloading recipient systems.  In addition,
    reporters MUST ensure that such rate limiting or any other means
    can effectively stop possible mail loops.

?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 3 Feb 2021 11:55:45 -0500

>   contain provisions for detecting and stopping trivial loops.

I can tell you from bitter experience that rate limiting is the *ONLY* 
reliable way to stop trivial loops.  Whatever else you try, something will 
eventually change or delete the thing you try to use to recognize loops.

As a concrete example, I get a lot of failure reports from 
antispamcloud.com which are not multipart/report and which software would 
not recognize as a failure report.  Nonetheless, if they got into a 
reporting loop, it would be annoying, and rate limiting would stop them.

> other's failure to authenticate a failure report /is/ a loop.

Sometimes mailbombing is a loop, sometimes it isn't.  If the loop is so 
slow that it doesn't trigger rate limits, it's not likely to be a 
practical problem.

Regards,