On 1/27/21 12:47, Murray S. Kucherawy wrote: > On Wed, Jan 27, 2021 at 12:37 PM John Levine <jo...@taugh.com > <mailto:jo...@taugh.com>> wrote: > > I still don't understand why failure reports about messages that > happen to be failure reports are in any way special. > > > Loop detection in RFC 5321 is a normative MUST because of the obvious > operational problems it creates. Maybe I'm being thick, but right now > I don't see how this is different, apart from the fact that each > message is distinct; you're still causing a problem by turning this on > without a care in the world about whether two verifiers start spamming > each other.
There's coverage in 7489 Section 7.2 that a domain owner can inadvertently DDoS themselves via failure reports. And that still surprised many implementers, even though it seemed obvious to them in retrospect. This case is even less obvious, and we still have questions coming in about it from new implementers. I don't think it's a security consideration because it doesn't scale up the way "ruf" can, so it deserves a brief mention here. But I would rephrase Ale's last sentence: 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 for authentication, as failure to authenticate failure reports may result in mail loops. These loops can be mitigated by sending reports from a domain or subdomain that doesn't request reports, or by performing rate limiting for report receiving mailboxes. --S.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
