From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Wednesday, March 24, 2010 1:46 PM
To: Murray S. Kucherawy
Subject: Re: [mail-vet-discuss] Proposed "header.b" tag for DKIM
Yeah, it seemed vaguely familiar. The reason I ask is because any IETF
effort is almost
by definition a big undertaking, so having a pressing and compelling
need and a largish
constituency are usually table stakes. I guess I wonder who that
constituency is here, and
whether it's really large enough to get over the ietf energy barrier.
This only requires registration of a new tag in the registries the base
auth-results draft created and not a full revision draft or other overhaul work
to make it work. This isn't imposing any mandatory new syntax either. It's
just creating an optional mechanism that can be used to disambiguate results.
I don't think this will be as big an undertaking as the base draft was, or the
other issue will be.
I just read through the draft and I still don't see the "why" that I'm
I understand the problem itself, but the why I'm asking about is more
of "why is
this an actual problem faced by implementations". Ie, is this something
trouble out in the field? Part of this is my own ignorance about how
people are actually
using auth-res, I admit.
I have seen at least one site that signs with a small key (in terms of bits
used) and one large key, so it's got two different selectors but all the other
signature input parameters are identical. This produces two results. There's
no "header.s" so right now you get two results that could be different and no
way to tell them apart. The verifier could distill that down to a single
result that is the union of the two, but that may not be palatable in all
situations (i.e. maybe the receiver cares, but now it can't apply its policy).
There's also at least one DKIM implementation that will not even accept a
"dkim=pass" if the signature didn't cover the Subject: header field. And
OpenDKIM has various policy features that allow things like "if 'l=' was in use
and not enough of the received message was covered, then the signature isn't
acceptable regardless of the outcome.
One sender that wants to satisfy multiple DKIM acceptance policies will
eventually need to affix multiple signatures with different properties. At the
moment there's no way to distinguish those results past the verifier. That's
the problem I'm trying to solve. The hints of this are operationally there,
but there's not an actual pain point I'm trying to resolve ... yet.
NOTE WELL: This list operates according to