> 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.
In other words, if may be difficult but we can change it.
> 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?
First, the protocol is already extensible, just not in the right way for this
case.
Second, what do you think the "non-V1 signatures in new fields" are if
they aren't extensions?
> 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."
You're confusing the definition of an extensibility mechanism with its use. We
specify extensibility mechanisms all the time without there being any
implication that someone using them is creating any sort of standard. Indeed,
we could, as part of this mechanism, include additional tagging to make it
clear whether or not a given set of tags are standardized or not.
This is all old and well-tread ground in many protocols, and there's large
amounts of "running code" saying that the issues you imagine this will create
don't actually occur in practice. (I have described the issues that have
occurred, as well as why that won't happen here.)
> > 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.
I have previously explained why the contexts aren't remotely comparable, but
let's suppose for a moment that they are. "p=reject" was in no way dependent on
any kind of extension to DKIM. Indeed, the main motivation behind extending
DKIM is that DKIM gives us no way to specify what a signature is for, which
makes it impossible to sign something twice with different grades of signature
while making sure the weaker one isn't used for the wrong purpose.
Although I don't agree with it and think it's gone one layer of abstraction too
far, I accept the design decision that having a means to specify the intended
purpose of a given signature in the signature itself is the wrong approach.
Which means the only alternative is to extend the signature semantics one way
or the other. Given that that this need has arisen, it seems to me that solving
the general problem in a clean way makes a lot more sense than a one time hack,
especially since the implementation costs are, AFAICT, nearly identical.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
