On 04/14/2006 12:26, Douglas Otis wrote:
> On Apr 14, 2006, at 5:56 AM, Hector Santos wrote:
> >>> Unless it has help from the backend server, offline mail systems
> >>> will not work very reliably when keys are being changed.
> >>
> >> Should DKIM require services beyond DNS for verification?
> >
> > Is this a trick question? :-)
> >
> > In contexts of the offline MUA, for it to work reliably, I would
> > think it will need from feedback from the work done in the backend
> > (ISP, ESP, Mail Host).
> >
> > Otherwise, how would get your Offline Mail Reader to work correctly
> > with DKIM when you have the problem of unknown key revocation?
>
> While not on-line in the sense of continuous connectivity, an
> intermittent POP or IMAP connection would likely also have concurrent
> access to DNS for resolving such Internet services.
>
> With what you are suggesting, it would seem these DNS records will
> not be retained for a period adequate for protecting IMAP or POP
> transit unless some alternate repository of keys is obtained.
>
> >>> The only way I see to reduced this is to increase the frequency
> >>> of your pickup times so that is closer to real time.  At pickup,
> >>> the DKIM plug-ins do their work.  So even if you are away on
> >>> vacation, your computer is still on and doing its mail pickup.
> >>
> >> Access to email can occur at fairly slow rates.  A delay due to a
> >> short vacation suggests typical transit times may easily span
> >> several weeks.  Not every MUA is continuously on-line.
> >
> > Agree. The point was, with today's software, the current DKIM
> > specs, fixing or at least reducing the problem, would be to make it
> > do higher frequency pickups.
>
> 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.
>
> > I don't see any other solution for the person who wants to use DKIM
> > with his offline mail reader and isn't getting any help from this
> > host.  Do you?  How will you pull this rabbit out of the hat
> > without having a higher frequency pickup?
>
> What problem is being solved by rapidly removing the availability of
> keys?
>
> > What would be the "recommended frequency" for the DKIM ready MUA?
>
> This is limited by human interaction and as such, is necessarily slow.
>
> > Is this information that should be added to DKIM-BASE?  Maybe. But
> > then I will have to stop telling some of some of my users to top
> > polling our pop server every freaking minute! <g>
>
> A faster polling rate for an MUA is a not a solution. : (
>
I think this whole sub-thread highlights the impossibility of designing DKIM 
as an completely reliable MUA level tool.  While it may be useable in the 
MUA, I think the target of the protocol design should remain squarely in the 
MSA-MTA-MDA relm.

In terms of other MUA level timing sources, IIRC, the original Microsoft 
Caller ID for E-mail specifications recommended keeping things published in 
their DNS record for 30 days beyond when they had last been used.  If you 
want to target MUAs, then that's probably about where you need to be.

>From a protocol design perspective, I think the right answer is to design for 
the case where the receiving MTA/MDA will check the signature and record a 
result that, if appropriate, an MUA can use.

Scott K

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to