Ned Freed writes: > Again, you're talking about a different strategy now.
Well, one way to look at this is that if the strategy you *thought* I was talking about involves self-inflicted injury to some participant, maybe neither that participant nor I are that stupid, and I was talking about something else. Not specifying the full scenario was my bad. We can stop there, at "my bad", if you like, but it would be more productive if we could meet halfway, on some bridge between "your good" and "my bad". > > > You're missing the point. We're *changing* the design here so > > > things no longer work this way by associating this with a > > > version bump. And we've already confirmed that a significant > > > number of implementations ignore v=2 signatures. > > > Changing the design of what? > > DKIM and subsequently DMARC. That's not *the* design, that's *two* designs you're changing. DKIM is "owned" by the IETF, and "we" can change it. DMARC is not; DMARC is a successful private protocol, and "we" can't change it. We can make suggestions that provide sufficient benefits to the current DMARC participants so that they prefer our proposal to the one that works for them already. That's a tall order though. "Don't fix what ain't broke." > Then this entire effort is pointless I'm afraid it's going to be unsuccessful, indeed. That doesn't make it pointless. OTOH I'd rather not waste your effort and mine if it is pointlees. > and we might as well leave it all to the MLMs to deal with as best > they can. Well, we MLM devs will deal. But it's not just us. There are a bunch of third parties for whom the workarounds so far are suboptimal. > None of the present proposals make any sense if DMARC agents continue > to only see only V1 signatures. True. But some of the non-V1 signatures proposed are in new fields. Why is it a good idea to do an extensible protocol that we don't have any proposed extensions for? I grant that if we're going to do that, a version bump to DKIM-Signature (rather than a new field) is very plausible. > > it's possible, maybe even quite probable, that the big players > > will use the possibility of registering values and imposing > > criticality to serve their own purposes. > > Why would they bother? If they want to do things along those lines, > they can already do them by generating and then requiring a > different header field and there's nothing we can do about > it. Because if the IETF publishes it, it's a "standard", and the onus is on them to conform. If they can conform without conforming, they can blame everyone else (as Yahoo! and AOL are already doing, albeit implicitly). And they can do it explicitly, because they "conform." > This [X.400] mechanism caused problems because some vendors added > critical extensions which would then cause other implementations to > bounce those messages. Sounds like "p=reject" to me. More precisely, in the "p=reject" environment, ignoring things is no longer "fail-safe", it's "fail-mail-lost". A critical extension must be handled properly, or the signature doesn't validate ... and the message bounces. Steve _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
