Subject: [dmarc-ietf] Ticket #28 - Failure report mail loops

From: Alessandro Vesely <[email-masked]>
Date: Fri, 4 Dec 2020 12:10:28 +0100

We would like to close this ticket by Dec 18, two weeks from now, so please get 
on it.

The ticket originated from John's comment, in May 2019:

     Apropos recent discussions, we could recommend that failure reports be
     rate limited per recipient both to break loops and to deter indirect
     mail bombing.

The current draft discusses the topic toward the end of the introduction of 
Section 3, before the first subsection:

    An obvious consideration is the denial-of-service attack that can be
    perpetrated by an attacker who sends numerous messages purporting to
    be from the intended victim Domain Owner but that fail both SPF and
    DKIM; this would cause participating Mail Receivers to send failure
    reports to the Domain Owner or its delegate in potentially huge
    volumes.  Accordingly, participating Mail Receivers are encouraged to
    aggregate these reports as much as is practical, using the Incidents
    field of the Abuse Reporting Format ([RFC5965]).  Various aggregation
    techniques are possible, including the following:

    *  only send a report to the first recipient of multi-recipient
       messages;

    *  store reports for a period of time before sending them, allowing
       detection, collection, and reporting of like incidents;

    *  apply rate limiting, such as a maximum number of reports per
       minute that will be generated (and the remainder discarded).

Some issues the WG may want to consider:

1.  That whole passage should be moved to its own subsection of Section 5, 
"Security Considerations".  Only a reference should be left in the intro.

2.  In the first *-bullet above, the sense of multi-recipient is ambiguous.  An 
explicit mention of ruf= might help.

3.  The 2nd and 3rd *-bullets may need expansion.  Propose text in case.

4.  Some explicit loop prevention specification may be added.  For example:
4.1.  send reports from a subdomain having a DMARC record without ruf=, or
4.2.  never send failure reports about failed reports.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 4 Dec 2020 14:58:33 -0500

>     rate limited per recipient both to break loops and to deter indirect

I have never gotten enough failure reports that handling them was even
slightly inconvenient, and my addresses are on every spam list in the world.

Has anyone else?  If don't have evidence that this is a real problem, I'd just close the ticket.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 23:15:57 -0800

> "Security Considerations".  Only a reference should be left in the intro.

Sure (though it's also fine where it is, IMHO).

2.  In the first *-bullet above, the sense of multi-recipient is
> ambiguous.  An

I don't follow.

Has anyone complained that they're too terse?

> 4.2.  never send failure reports about failed reports.

The latter, which is consistent with SMTP never generating a bounce about a
bounce.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 7 Dec 2020 12:13:02 +0100

On Mon 07/Dec/2020 08:15:57 +0100 Murray S. Kucherawy wrote:
>> The current draft discusses the topic toward the end of the introduction
>> of Section 3, before the first subsection:
>>

Thanks.

>> ambiguous.  An explicit mention of ruf= might help. >
> I don't follow.

The two paragraphs before the one I quoted are:

    The destination(s) and nature of the reports are defined by the "ruf"
    and "fo" tags as defined in Section 6.3.

    Where multiple URIs are selected to receive failure reports, the
    report generator MUST make an attempt to deliver to each of them.

They make it clear the sense of "multi-recipient".  However, diagonal readers 
may miss that point, especially if the quoted part is moved.  They would 
attribute the usual meaning to the phrase "multi-recipient messages", which 
makes no sense.

> The latter, which is consistent with SMTP never generating a bounce about a

However, SMTP has an operational definition of bounce, MAIL FROM:<>.  Should we 
take the same stance?  That is, send failure reports with an empty bounce 
address and never send failure reports to bounces or failure reports?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 19:51:12 -0000

In article <[email-masked]>,
>address and never send failure reports to bounces or failure reports?

We're talking about DMARC failures, not SMTP delivery failures. I
don't see what the latter has to do with the former.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 14:58:20 -0500

>4.2.  never send failure reports about failed reports.

4.0.  Make your failure reports DMARC aligned.

Looking at the failure reports in my file, all of the messages
actually are aligned, so this is a solved problem.

Other than the the possibility of indirect mail bombing via failure
reports, which I believe has never happened, I don't understand what
problem we are trying to solve here.

Since the original comment was mine, I would suggest closing this one
as nothing to fix.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 8 Dec 2020 13:32:11 +0100

> don't see what the latter has to do with the former.

When dmarc authentication method fails on a message, an MTA may decide to send 
a failure report.  If the message is itself a failure report, however, no 
failure report should be sent.  The question is, how does the MTA determine 
whether the message is a failure report, without resorting to lengthy content 
analysis?

One possibility is to never send failure reports when the bounce address is 
empty, and mandate that failure reports be sent with an empty bounce address. 
That way, also regular SMTP bounces won't be reported if dmarc authentication 
fails.

Overly simplistic?

Ale
--

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2020 19:04:46 -0500

>whether the message is a failure report, without resorting to lengthy content 

If the top level content-type is multipart/report, that would be a
pretty good signal.

Nonetheless I believe this is not a real problem and we should just
close the ticket.

Can anyone tell us about failure loops that caused an actual problem.  "We sent
one failure message per day every day" is not something I would call a problem.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 9 Dec 2020 15:55:04 +0100

> If the top level content-type is multipart/report, that would be a

Works for me.  It still implies no failure reports on bounces, but admins can 
have bounces on failure reports if they want.

The change amounts to a fourth 1-liner *-bullet, for example:

    *  never send reports for message of Content-Type: multipart/report;

It seems better than the other three bullets, so I'd prepend it.  Does the WG 
agree?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 9 Dec 2020 10:23:05 -0500

> It seems better than the other three bullets, so I'd prepend it.  Does the WG 

No.  This is not a problem.  There is nothing to fix.  Please close this 
ticket.

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Dec 2020 09:22:04 -0800

On 12/9/2020 7:23 AM, John R Levine wrote:
> No.  This is not a problem.  There is nothing to fix.  Please close 
> this ticket. 

+1

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 18 Dec 2020 09:58:20 +0100

On Wed 09/Dec/2020 18:22:04 +0100 Dave Crocker wrote:
>> No.  This is not a problem.  There is nothing to fix.  Please close this ticket. 
> 
> +1

Fair enough.  Ticket closed.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 30 Dec 2020 16:17:47 -0500

> Has anyone else?  If don't have evidence that this is a real problem, I'd just close the ticket.

The answer was apparently no, so I propose we close this with no change.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 13:13:24 +0100

> The answer was apparently no, so I propose we close this with no change.

Closed already on 18th, see:
https://mailarchive.ietf.org/arch/msg/dmarc/FDVvP_DNMxCtUtSdoqHYtHxZRxw

Best
Ale
--