On Sat 16/Jan/2021 22:30:56 +0100 Murray S. Kucherawy wrote:
On Fri, Jan 15, 2021 at 7:40 PM John Levine <[email protected]> wrote:
I still don't understand why anyone thinks there is a problem to be
fixed. If you don't want reports, don't ask for them. If you think the
mail you send shouldn't be provoking DMARC failure reports, adjust
whatever is sending the mail the mail is aligned, or get rid of the
ruf= that asks for the reports. What am I missing here?
You might be right, so I'll go back and ask this use case what the
specifics are.
What I'm concerned about is that since this has come up before N times
(for, admittedly, some currently small value of N), we've seen enough
disparate cases of it that we may be missing something bigger, and if so,
doing something defensive in the specification would be prudent. There's
smoke here, and there may be fire.
Will report back.
Examining my report folder, I note I'm sending one-liner aggregate reports to
domains I never wrote to. The pattern is their sending me feedback for one or
more mailing list posts, followed by my one-liner acknowledging their report
later on the same day or on the next day, depending on their sending time.
It is not a loop, because I send from noloop.tana.it, which has no rua=. I'm
not alone using this trick. Two naive report generators would continue to send
one-liners indefinitely.
While this is 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.
The only prevention in the spec is to apply rate limiting.
I'd add a couple of loop-specific provisions:
* send reports from a subdomain having a DMARC record without ruf=,
* configure the verifier to not generate failures of messages destined to one's
own ruf= address.
I shouldn't hurt, should it?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
