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. > 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. Barry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
