[ietf-dkim] New Issue: Treatment of verification failure not really a goal
fenton at cisco.com
Mon Mar 24 22:35:00 PDT 2008
Dave Crocker wrote:
> Jim Fenton wrote:
>> Most of the sections under 3.2, "Operational Goals", are really goals
>> in the sense of "I want a mechanism that...". So "I want a mechanism
>> that permits incremental adoption for incremental benefit" makes
>> complete sense. As does "I want a mechanism that minimizes the
>> amount of required infrastructure."
>> But section 3.2.1, "Treat verification failure the same as no
>> signature present" doesn't strike me as a goal, but rather a
>> consequence of the way that the mechanism works. I would probably
>> rather have something that can treat verification failure more
>> harshly, but it doesn't work that way. This really ought to be
>> merged with section 5.4, "Unverified or unsigned mail" instead.
> Let's try to tackle your last point, first. Section 5.4 is a
> description of the architecture. It's certainly a reasonable place to
> observe that failures are treated the same as no signature, as indeed
> 5.4 does. However that is different from describing higher-level
> goal-like issues, which is what section 3 is intended to be. By
> 'higher-level' I mean the stuff of significant constructs that
> motivate the work.
> Now to your primary point: DKIM's treating failures the same as
> no-signature is an unusual characteristic that captures folk's
> interest. From a pedagogical point of view, it warrants highlighting
> as an distinctive construct.
> Whether it deserves its own, explicit listing or whether it should be
> folded into one of the other entries (such as the current 3.2.2) is
> another matter. It seems to get enough attention to warrant being
> cited on its own, but I do see your point that it feels different from
> the other 'operational' goals. I am not sure how to reconcile that.
> Do you see the current Overview document form as doing any particular
> damage to one's understanding of DKIM?
It's just that the other goals sections do a good job of stating the
value proposition of DKIM, and this is a different sort of thing that I
think waters down what is otherwise a very strong section of the
document. If you can't come up with another place to cite it on its
own, I'd suggest listing it as the last rather than the first
More information about the ietf-dkim