On Apr 19, 2006, at 12:30 PM, Stephen Farrell wrote:
I wish you'd stop with the spurious figures.
These figures strongly suggest the recommendation in section 5.2 is
inadequate to accommodate lapses in availability owing to vacations,
when that is important to the sender.
Section 5.2
...
,---
| A signer SHOULD NOT sign with a key that is expected to expire within
| seven days; that is, when rotating to a new key, signing should
| immediately commence with the new key and the old key SHOULD be
| retained for at least seven days before being removed from the key
| server.
'___
A safer recommendation would be:
: A signer SHOULD NOT sign with a key that is expected to expire within
: a transit period where protection is desired; that is, when rotating
: to a new key, signing should immediately commence with the new key
: and the old key SHOULD be retained for at least the period where
: transit protection is desired before being removed from the key
: server.
Again, all this is an aside for us. There's no required
correlation between x= and key life cycles. Please stop flogging
that dead horse.
The x= parameter is a totally separate issue. Where have I
conflated the two?
There: [1]. Took all of 5 seconds to find one. There are others.
[1] http://mipassoc.org/pipermail/ietf-dkim/2006q2/003248.html
Hector made the inference key availability and the x= parameter are
related.
My statement was simply:
"When the transport includes IMAP and POP, this 7 day advice is far
too short of a period to ensure verification."
This was referring to section 5.2 and was not commenting upon the
conclusion reached by Hector. My apologies for not changing the
subject line.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html