C) Stipulate somehow that generated reports should not contain data about received reports. (If you do that, then you likely obviate the need to generate a new report back to that operator in the first place.)
I can't even tell what might be a failure report without deep parsing and heuristics. And, of course, I am not inclined to add extra code to program around other people's bugs.
This to me is almost exactly the same thing as saying "Don't generate a bounce about a bounce",
Because these are not bounces. They are not even a little bit like bounces. Bounces are about invalid recipient addresses, but these have no relation to anything about the recipient address.
They are fresh new messages sent from a system that presumably cares enough about DMARC to send reports about it, and presumably wants to send all of its mail with DMARC alignment. If they are unaligned, that is because the sending system is broken, and if that systems publishes an ruf= tag, it is specifically asking to be inforned about exactly that breakage.
Maybe I'm dim, but I am having no success understanding the apparent interpretion of ruf as "tell me about the unaligned messages I'm sending, except for some that should be really easy for me to fix."
Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
