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. 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. 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. There may be other ways to solve this, but that is one.
Mike _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
