On Friday, June 9, 2023 4:33:54 AM EDT Barry Leiba wrote: > I think, Scott, that you and I have a fundamental disagreement that's > not resolvable, and I won't just repeat what I've already said. But a > couple of the things you said are ones I can't make sense of, so I'll > > talk about those: > > Software engineering isn't a perfect science. In general, a more > > complex protocol will suffer more defects. If you want to design > > things that only work when software is perfect, I'm not interested. > > It seems that you're saying you're "not interested" in any protocol > that won't work if there's a software bug, and that makes no sense to > me. Crypto is hard to get right and there are often bugs; TLS won't > work if you don't get the crypto right: does that mean you're not > interested in TLS? Or VPNs (IPsec)? Are you not interested in TCP > because it will fail if there's a bug in the network stack? For that > matter, a router with a bug in its MPLS implementation won't work: > should we not use MPLS? And, well, if there's a bug in your > SPF-record parser, SPF won't work either, n'est-ce pas? > > Of course, the level of failure in any of this depends upon just what > the bug is.
Thanks for pushing back on this. It was poorly worded. Let me try again, see below. > > One could make the opposite argument too, and I think it would be > > equally valid: > > > > The only value DKIM brings for DMARC is for indirect mail flows. For > > any direct connections, SPF is sufficient. All the proposed DKIM > > changes to solve the DKIM replay problem are likely to break indirect > > mail flows anyway, so there's no longer a point to keep DKIM. It's > > much more complicated and it looks like the benefit of it is going > > away, let's just simplify the protocol and get rid of it. > > This also makes no sense, as it completely misrepresents the situation > I'm raising. It *doesn't* work both ways, because DKIM works in all > situations that SPF does, but it *also* works in some situations where > SPF fails. The opposite is not true. DKIM adds value beyond what SPF > does. SPF does not add value, ever. > > You and Mike seem to be holding on to SPF because you want to, with > some vague "I've seen network errors and software errors" statements > but without real arguments. The only real argument I've seen is > Seth's about broader deployment of SPF without DKIM. I've already > said why I think that's not a reason we should keep SPF, but at least > that is a reason I can make sense of. It's not a case of I've seen a few failures, it's consistent (all I can say for certain is that it was as I no longer have access to this data). It was consistent across time and providers. At scale, DKIM would always have a fraction of a percent failure rate, while SPF would not (for direct connections - I have no disagreement with your statement that SPF doesn't help with indirect mail flows). This probably exculpates DNS as a source of the DKIM failures, since I think it's not likely that SPF records could be retrieved when DKIM key records could not, but I don't know for sure. The leads to a situation where the DMARC pass rate for direct connections would vary depending on if SPF was included: DKIM only: ~99.5% DKIM + SPF: ~100% SPF only: ~100% You may not think that last half of a percent is important (my recollection is that it varied a bit between 0.2% and 0.8%), but I think it exists and is important. The point I was attempting (badly) to make is that I have seen data that's contrary to your claim that there is no case where SPF will enable a DMARC pass that DKIM would not also yield a DMARC pass, so we don't need it. My judgement is that you are assuming too much perfection out of DKIM and the data doesn't support it. Does that make more sense? Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
