On Mon 07/Dec/2020 08:15:57 +0100 Murray S. Kucherawy wrote:
On Fri, Dec 4, 2020 at 3:10 AM Alessandro Vesely <[email protected]> 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).
Thanks.
2. In the first *-bullet above, the sense of multi-recipient is
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.
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.
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
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
