On Wed 27/Jan/2021 17:17:38 +0100 John R Levine wrote:
While [loops are] a minor problem for aggregate reports, it can be a real problem
for naive failure reports generators. Juri reported he had to target a
specific address, attributing the loop to a remote misconfiguration. However,
if it is possible to screw up authentications, the probability to meet a loop
is just its square, times the number of generators.
If the authentication is screwed up, sending a failure report is exactly the
right thing to do. That's what they're for.
Even if the screwed up message was a failure report itself?
I think we should close this. DMARC is working the way it is supposed to, and
people don't want to get reports about their reports, there are obvious ways to
prevent them, like not sending unaligned reports,
Oh, there is a sentence in the current spec:
Email streams carrying DMARC feedback data MUST conform to the DMARC
mechanism, thereby resulting in an aligned "pass" (see Section 3.1).
As it stands, it's valid for both aggregate and failure reports. However, it
happened to land on the aggregate-reporting I-D only.
or sending reports from a domain that doesn't get reports back.
That was one of the hints I proposed. Your wording is better. Added this:
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. Besides rate limiting,
such loops can also be avoided by sending reports from a domain that
doesn't get reports back.
Is that all right?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
