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

[Alessandro Vesely <[e-mail]>]

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