Once you do that, how are you going to get courier-pop or courier-imap to
look there when a user logs in to check email?
Uh ... good question? :-)
Is the implication here that the IMAP and POP servers don't look anywhere
else besides $HOME/Maildir for the user's Maildir? Is that hard-coded?
(Unless something like the virtual domain stuff is being used) Yikes!
Are these virtual users, or actual system users?
These are actual system users.
What I'm trying to implement:
A subset of users ("users" == "people with entries in our NIS ``passwd'' map")
uses our mail server. I want them to be able to get their e-mail, but not to
log into the mail server (via SSH or any other means). Their home directory
will still be available (over NFS) to Courier on the mail server for dot file
access purposes, I suppose, but I'd like to keep them from logging in if at
all possible. (I'd even want to keep their home directory from being NFS
mounted if I could get the .courier et al. file functionality some other way.)
But I'd rather not have their mail saved to their own $HOME/Maildir over NFS,
so that's why I'm trying to get all the Maildirs under one roof/tree. Using
"userdb" and virtual domains sounds like it's closest to what I want to
do, but I have no use for virtual domains - I'm inside a bigger domain
(at work), and just want mail to [EMAIL PROTECTED] to
go to this Courier box and work right. Virtual Domains seem like they're
meant to be used in a different kind of setup than mine.
Surely I can't be the only person who's ever wanted to keep Maildirs all under one directory tree but had no use/need for Virtual Domains???
- Greg
Sounds like virtual domains are exactly what you want.
I don't have any real NIS users (or in my case, NetInfo) that I want to set up, because I just didn't want to create local users at all for most of my mail accounts... but since you don't really want them logging in, you really have a very similar setup it sounds like to me.
For my set up, I have all my users setup as virtual users (including myself actually, even though I do still log in to the mail server locally) with PostgreSQL as the authentication mechanism.
This allows me a great deal of flexibility in where home and maildir go and who can access their mail and so forth. And even though it would work just fine with Courier as an MTA, I find it also integrates well with Postfix (with a small patch to use PgSQL lookups) which I actually still use as my MTA.
There are accounts in the virtual user list which can have a simple name, like my account where I log in to the mail system with 'james' -- and accounts where they have to use their full email address as their login (for other hosted domains) like '[EMAIL PROTECTED]'. You might not ever need accounts with email addresses as logins, to support other hosted domains, but the system doesn't really care much, as long as you tell it which email addresses to look up which way. So all your users could be 'tom', 'bob', 'bkthompson', 'jim90287', etc.
I simply set up a record for each user (again, this includes even my own account) that I want in the mail system. And as a benefit of being virtual:
They can have their own homes, or a shared home... they can have the same uid/gid, or they can have one that matches a "real user" id from NIS/NetInfo/etc.... they can be enabled or disabled ...... and all of this is without affecting whether they can have (and use) a real system account.
I like it A LOT this way!
Sounds to me (from your described situation above) like you probably would too.
Obviously you don't have to use a full-fledged database like PgSQL or MySQL if you don't want to... userdb should be able to accomplish exactly the same thing. I just figured in my situation to use it in case a) I wanted to use it with other systems, I expected they might support "real" databases better than the userdb setup, b) my user base eventually grew large enough that the lookups would be improved by using a "real" database (not likely, but it might get there), or c) I ever felt like managing the users from something other than command line, it's probably easier to write something that accesses SQL than the userdb store -- since I already knew how to write to SQL. :-)
Virtual users may or may not be the right solution for you, but I think it sounds like it could be. Either way... maybe this info can help you decide. Good luck!
-jab
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
