John R Levine wrote:
I have a lot more trouble understanding why t= needs to be kept than why
x= needs to be kept.
Without t= we have no idea when a message was signed, since there's no
particular reason that the Date: header has to contain the current date,
or even that there be one.
Sure; I haven't been clear on why we care when the message was signed,
except as it affects the expiration of the signature (which x= expresses
more directly).
As a signer, I would much rather specify an expiration time for the
signature than to specify the time at which it was signed than to
have the verifier add a fudge factor to the signing time and use
that as the expiration. On this list, I have already heard numbers
between 1 and 2 weeks for the fudge factor, so the signer would
really have no idea how long the signatures are valid.
But the signer is likely to have little idea of what the transit time
to the recipient will be. The basic justification for x= is that the
sender knows the transit time and the recipient doesn't. I've never
seen any justification for that, and it's easy to think of scenarios
where it's just wrong.
I don't see why the recipient would have any better idea than the sender
on whether the transit time is acceptable.
I prefer x= over extrapolation of t= because it gives the verifier a
simple, objective test to see whether the signature is "stale".
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html