On 1/25/21 12:18 PM, Michael Thomas wrote:
On 1/25/21 12:08 PM, Todd Herr wrote:
On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas <[email protected]
<mailto:[email protected]>> wrote:
Sounds like a bug to me and an issue should be opened. Just
because it's
a 10 year old bug doesn't mean it's not a bug.
I disagree.
Authentication results should not differ at a given provider based
solely on the destination domain, so there is no reason to report
results separately for each destination domain. Further, there's no
value to the report generators, especially at large sites like
Google, to expend the resources necessary to generate and send X
reports when one will do.
So you're saying I should be free to spoof any domain I want because
Google might be inconvenienced?
If the language in 7.2.1.1 that Seth cited is "working," then report
generators are sending reports that pass DMARC and the report receivers
are validating that before ingesting the attached reports. However this
only provides some degree of attribution for the report itself...
We can certainly check with report receivers to confirm that they are
doing that validation, and perhaps get some measure of how often they
see reports that don't pass. What does that leave us with?
Assuming 7.2.1.1 "works," reports that don't pass DMARC won't be
processed, and won't cause the confusion and/or delayed implementation
you cited as the potential harm.
That leaves reports that pass DMARC, sent from domains that haven't
actually handled the sending domain's email. This sounds to me like
reports that contain false data. Reports containing false data are
identified as a security consideration in RFC7489 Section 12.2, without
a reference to 7.2.1.1 as the suggested mitigation.
I don't see where additional authentication of the report itself can
address this concern, given the availability of disposable domains. That
leaves report receivers with the need to track report senders'
reputation, which might warrant a mention in the revised spec.
What did I miss?
--S.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
