Barry Leiba wrote: > ----------- 1532 > What Tony says is not consistent with the WG consensus, which was NOT > to REQUIRE the presence of "v=DKIM1", and the text (Tony's "N/A" > notwithstanding) makes it clear that the absence of v= is interpreted > as "v=DKIM1". > > He's correct, though, that the intent was for the DKIM key record to > be backward compatible with DK (RFC 4870, Historical), but that the g= > tag screws that up. Perhaps what would be correct to say is this, > added after the g= paragraph and before its ABNF: > > Exception: if "g=" is specified with an empty value AND there is NO "v=" > specified at all, implementations MAY interpret this in the context of > DomainKeys [RFC4870], treating it as DKIM's "g=*". >
I disagree with this proposed resolution. I don't interpret backward compatibility as meaning that every DK selector must be usable with DKIM, but rather that it should be possible for the same selector record to be used by both DK and DKIM. In any case, the change you're proposing introduces an ambiguity in the specification: Under the circumstances cited, the verification result from DKIM is undefined. That's a poor statement for a standard to make. It's true that key records with empty g= values do contribute to verification failures; see http://blogs.cisco.com/security/comments/common_errors_causing_dkim_verification_failures/ for a discussion of this. The error we're talking about here is "inapplicable key". As the discussion notes, there's an ESP out there that is giving their customers key records to publish that have empty g= values. Yesterday, this single ESP accounted for 72% of all the Inapplicable Key errors we saw at Cisco. I contacted this ESP last fall, and they have not corrected the problem. There are lots of other syntax errors we see as well. I don't think it's worth introducing an ambiguity in the specification to compensate for an easily correctable problem. Do we next introduce a change in the spec to compensate for those that are publishing key records with extraneous backslashes? -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
