On Tue 26/Jan/2021 18:24:53 +0100 Michael Thomas wrote:
This is different than yesterday. From what I can tell there is no identifying
information of the original message like message-id in the report xml. If i'm
wrong, please point me to it.
With a record for each message it wouldn't be an *aggregate* report.
In addition, if I recover that message from the log, I might find no
relationship with the reporting domain or the reported source IP. That is to
say, I won't be able to deduce if the report is fake or real.
Since the object of the reports is to have confidence so that I can set a
p=reject policy, all an attacker needs to do is bombard $LARGEPROVIDER with
bogus messages purportedly from my domain to make me not want to change over
to reject for fear of large providers dumping legitimate email from my
domain. This could be somewhat mitigated if you know all of the IP addresses
that send for you domain, but that could be difficult with the use of
outsourced email, etc and shouldn't be a requirement.
$LARGEPROVIDER must use a reputation system to evaluate both the report
generator domain and the reported IP numbers.
Addition of the message-id would allow me to cross check from my logs, say,
that it was a legitimate message from my domain or not.
Not if you take forwarding into account.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
