[ietf-dkim] x= lets senders expire responsibility

Bill.Oxley at cox.com Bill.Oxley at cox.com
Fri Apr 14 10:53:57 PDT 2006


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.oxley at cox.com 


-----Original Message-----
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.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.org>
To: "Hector Santos" <hsantos at santronics.com>
Cc: "IETF-DKIM" <ietf-dkim at mipassoc.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



More information about the ietf-dkim mailing list