The data I have seen (and it sounds like Mike is saying the same thing) shows DKIM verification results are less than 100%, consistently, for direct connections. It was always lower than the SPF pass rate for hosts listed in a domain's SPF record. I understand that in theory, it shouldn't matter, but in practice it is.
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. In terms of utility for direct connections, I think having both helps and I don't find claims the SPF can never pass when DKIM fails to be credible. If someone has data that shows that's true now, I'd be interested to see it (my experience is a few years ago, so things may have changed). Ultimately, I think SPF and DKIM both suffer from what I'll genetically call data hygiene problems. SPF is mostly adding third party providers who are insufficiently careful (might not even care, I don't know) generating SPF pass results for "bad" mail. DKIM is mostly about replay attacks. Neither of these are protocol problems and I don't think support dumping one or the other out of DMARC. 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. Now, I think that's a bad argument, but I don't think it's any worse than the argument being presented to get rid of SPF. Scott K On June 8, 2023 10:26:59 PM UTC, Barry Leiba <barryle...@computer.org> wrote: >> There are DKIM verification failures for reasons unrelated to DNS failures. >> As an example, I >> recently fixed a DKIM validation bug in the library I maintain which was >> causing a small fraction >> of valid signatures to fail verification since at least 2011. SPF + DKIM >> reduces DMARC failures. > >Oh, well, I don't buy this one at all: My software might have bugs, so >I have to use multiple mechanisms? No, you have to fix the software. >"Software might have bugs" is not a reason to put extra complexity >into a protocol. > >Would you suggest including two DKIM signatures using different crypto >suites in order to work around possible software bugs? Would you >suggest putting that into the protocol definition? > >> It's true that SPF is not particularly helpful for indirect mail flows, but >> I read your message as claiming >> using SPF with DKIM causes DMARC verification to be worse for indirect mail >> flows than when using >> DKIM alone. Is that right? > >What I said was that there is no case where DKIM will fail and SPF >will succeed. I stand by that statement. Can you describe a scenario >that breaks DKIM but has SPF still work? > >That's assuming the software is working right and one hasn't >configured it wrong, both of which should be fixed. And if you can't >retrieve a needed DNS record, you need to wait and retry, not try to >put unnecessary redundancy into the protocol. Unless, of course, you >can show that DKIM is significantly more likely to fail for that >reason than SPF is. > >The other thing I said about SPF is that there are cases now where the >SPF records required by the use of major service providers are so >bloated and contain so many IP addresses that they allow spammers who >use those same services to spoof any other customer of the service. >That makes SPF validation weak. As there's no benefit to it over >DKIM, I don't understand why we'd want to keep it. > >We needed SPF when DKIM was less widely deployed. We thought it was >more useful when we hadn't seen how often it breaks compared with >DKIM. And one advantage that SPF had -- that it allowed you to reject >a message during the SMTP negotiation, before the DATA command was >accepted -- can't be used if you need to check DKIM as well. > >Barry > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
