On Thu, Jan 28, 2021 at 1:42 PM John R Levine <jo...@taugh.com> wrote:
> > 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. > Yes, I realize the difference. I was making an analogy. 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. > OK, let's hop into your example. I care enough about DMARC to send reports about it, and I want to send all of my mail aligned. I send a test message that ends up unaligned somehow, perhaps through a broken relay I don't own, and I would ideally like to get one message back that tells me that. If I happen to send my test to a place that unintentionally sends an unaligned report back to me, perhaps because of the same relay, I'm going to get flooded, even though my local setup is verifiably correct. And, probably, so are they. You're saying the only real answer here is that the two end operators in this example need to fix their evidently-crappy setups, or change their DNS records to remove the "ruf" value until they can get the guy in the middle to fix whatever's broken? Maybe I'm the dim one, but I can't see why it's manifestly absurd to think we might somehow augment either the report or the message containing it by adding just enough metadata someplace to signal one end or the other, or both, to avert the flood. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
