Christopher Seawood <cseawood@seawood.org> writes:
>
>Ok, I forgot to mention that the domains are completely virtual. There
>will be no accounts on the pop server for any of the users of any of the
>domains. We have virtual domains setup in such a way that each user has
>his own control file, but we have not come up with an easy way to retrieve
>mail via pop as joeuser@jrandom.domain .
>
Well, if these users don't have entries in /etc/passwd on the POP
server, you'll have to use an indirect method of authenticating them.
One possibility might be if qpop3d supported cdb for authentication
and mailbox location.
Another possibility would be extensions to a Radius-like authentication
system where the pop daemon prompts for a username/password (much as
it presently does), asks the auth daemon if the user should be allowed
in, and the auth daemon returns the mailbox location as well as the
'A-OK' indication.
Unfortunately, there are a couple of problems. I don't think any of
the currently available tools can do this kind of thing, and running
all the pop daemons (and therefore the delivery programs) under a
single, common uid opens certain types of security holes.
You might have to end up assigning unique pop login names and
let the pop daemons look them up in a cdb or /etc/passwd file.
-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET
>
>Ok, I forgot to mention that the domains are completely virtual. There
>will be no accounts on the pop server for any of the users of any of the
>domains. We have virtual domains setup in such a way that each user has
>his own control file, but we have not come up with an easy way to retrieve
>mail via pop as joeuser@jrandom.domain .
>
Well, if these users don't have entries in /etc/passwd on the POP
server, you'll have to use an indirect method of authenticating them.
One possibility might be if qpop3d supported cdb for authentication
and mailbox location.
Another possibility would be extensions to a Radius-like authentication
system where the pop daemon prompts for a username/password (much as
it presently does), asks the auth daemon if the user should be allowed
in, and the auth daemon returns the mailbox location as well as the
'A-OK' indication.
Unfortunately, there are a couple of problems. I don't think any of
the currently available tools can do this kind of thing, and running
all the pop daemons (and therefore the delivery programs) under a
single, common uid opens certain types of security holes.
You might have to end up assigning unique pop login names and
let the pop daemons look them up in a cdb or /etc/passwd file.
-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET