From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] imap4d operation (Was: ATA next) Message-ID: <20040123075534.H28365@cackle.proxima.alt.za> References: <20040122203626.F28365@cackle.proxima.alt.za> <9bc085a2c64521b6622e7f23ffcd5358@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <9bc085a2c64521b6622e7f23ffcd5358@plan9.bell-labs.com>; from David Presotto on Thu, Jan 22, 2004 at 02:53:15PM -0500 Date: Fri, 23 Jan 2004 07:55:35 +0200 Topicbox-Message-UUID: bf735cc8-eacc-11e9-9e20-41e7f4b1d025 On Thu, Jan 22, 2004 at 02:53:15PM -0500, David Presotto wrote: > > I'll fix sources. > Thank you. There doesn't seem to be a short circuit to figuring these things out other than study and questioning, unfortunately. > > (b) does imap4d not need to be able to "speak for" the new user, > > which is easiest achieved on an auth server? > > It's easiest achieved by the user login in which just goes via > factotum. Factotum talks to the auth server but it doesn't matter > whether the auth server is local or remote. Factotum has certainly made a huge difference. I'm going to have to think this one through, because the picture that's beginning to form in my head will no doubt need some touching up :-) Just as a data point, "cron" would not be able to do the same without at least some major adjustments, would it? I do note that one tends to think of factotum conversing with the authenticator, whereas the conversation in fact takes place _through_ the client or server. ++L