On Fri, Dec 4, 2020 at 3:10 AM Alessandro Vesely <ves...@tana.it> wrote:
> 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. > Sure (though it's also fine where it is, IMHO). 2. In the first *-bullet above, the sense of multi-recipient is > ambiguous. An > explicit mention of ruf= might help. > I don't follow. 3. The 2nd and 3rd *-bullets may need expansion. Propose text in case. > Has anyone complained that they're too terse? 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. > The latter, which is consistent with SMTP never generating a bounce about a bounce. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
