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.
Correct.
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
motivations are
not at odds with each other. In fact, they seem quite aligned to me. And
that's
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
something's not
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
differing
on is whether a receiver may or may not do the validation after the
expiration
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
receiver
and defer this argument until we actually have some wide deployment
experience.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html