I suspect in the real sysadmin world changing keys every week probably
isn't going to happen :-)
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Friday, April 14, 2006 1:32 PM
To: Douglas Otis
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, April 14, 2006 12:26 PM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility
One simple solution would be to change the recommendations and ensure
a reasonable period for accessing keys to enable protections over
IMAP and POP transit. A recommendation might be changed to weeks
rather than days.
...
A faster polling rate for an MUA is a not a solution. : (
Doug, the current recommendation is 7 days. That means that at a
minimum
the polling rate for your MUA needs to be 6.9 days or less if you don't
want
to experience problems. Right?
Even if the recommended key retention time is increased to 2 weeks, your
MUA
minimum polling rate is now 1.9 weeks or less, and so on.
So while the higher retention time is better for the MUA to not miss
revoked
keys, you will always have the same timing issue with the offline MUA.
Right?
---
Hector
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html