On Apr 14, 2006, at 10:31 AM, Hector Santos wrote:
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?
Many people will not be able to access their email at this rate.
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.
This is better, but it would be still too little time to assure
messages within the IMAP/POP transport.
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?
Timing email is problematic. The Date header provides roughly the
same information as the t= parameter. The Date header could be
encompassed by the signature to offer an approximate date of when the
message was prepared and signed. The same variation in timing might
occur when signing, as with delays in the recipient's initial access
via IMAP/POP. DKIM does not indicate whether the email was signed
prior to being submitted by the MUA, or whether the message was
signed by the MSA. A very large disparity in the message date could
be an indication a stale message. A stale message might happen by
accident, or due to equipment failures, and would seem to require
either acceptance or rejection which might lead to the message being
bounced.
What happens to the message when the key is revoked?
A retired key flag, rather than blanking the public key, can extend
protections within the IMAP/POP transport while also permitting a
change in the acceptance criteria at the MDA, which seems to be the
goal.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html