[ietf-dkim] "Best Before" vs. "expiration" date
mike at mtcc.com
Mon Apr 24 17:42:35 PDT 2006
Paul Hoffman wrote:
> At 5:04 PM -0700 4/24/06, Michael Thomas wrote:
>> Paul Hoffman wrote:
>>> At 3:32 PM -0700 4/24/06, Jim Fenton wrote:
>>> More good questions. "I, the sender, want this to not be able to be
>>> validated after this date" is all well and good, but the sender's
>>> wishes go directly against the recipient's wishes, which are to have
>>> as many validated messages as possible.
>> That's not correct. The receiver's motivation is to defend itself.
>> Validating messages
>> a priori does not do that.
> True, but does it hurt to do so? If a recipient validates a message
> that has "expired", what is the harm to the recipient? The advatage,
> of course, is that they are now sure where the message came from; this
> is the same as in the normal, unexpired case.
All I'm trying to point out here is that the sender and receiver's
not at odds with each other. In fact, they seem quite aligned to me. And
true even if the receiver goes ahead and does the key lookup anyway; in both
cases, it has pretty reliable information from the sender that
kosher, and that's always useful for receivers.
>> If a sender through its own policy says "don't trust/honor/blame me
>> this after this time", why should a receiver not honor that?
> If that policy makes no sense for the recipient (the sender was
> responsible at time X but not at time X+1), then the recipient would
> still want to know whether the message came from the putative source.
I don't see why it doesn't make sense, but if the only thing that we're
on is whether a receiver may or may not do the validation after the
time... I don't really have much feeling one way or the other about
that. I tend
to think they shouldn't, but I could live with it being a choice for the
and defer this argument until we actually have some wide deployment
More information about the ietf-dkim