On Wed, Jun 05, 2002 at 12:52:21PM -0500, Mark Roach wrote:
| On Sat, 2002-06-01 at 00:06, dman wrote:
| > On Fri, May 31, 2002 at 02:06:25PM -0500, Roach, Mark R. wrote:
...
| > | I see that with authuserdb, I can specify /var/mail for the Maildir, but
| > | I would prefer to not have to keep a separate password database just for
| > | imap. (I am currently using pam to authenticate against my ldap
| > | directory).
| >
| > Hmm, is authuserdb a separate db or can it plug into LDAP? IIRC
| > courier can authenticate against LDAP.
|
| Yes, courier can authenticate against LDAP directly, but that requires a
| courier-specific schema which I don't feel like implementing for the
| same reason as the authuserdb, my solution turned out to be ldap via pam
| via the courier-authdaemon + the symlink you suggested above.
I think it's great when various components can all be directed through
PAM for authentication because that creates a single channel through
which the configuration (LDAP, NIS(+), passwd/shadow, SMB, whatever)
can be (re)directed. It's certainly better than having every daemon
perform the LDAP itself and require re-configuring every daemon if the
config changes.
| > | Does anyone have any suggestions on what "the one right way" to do
| > | things is? should all mail be accessed via imap, should the mail server
| > | mount the users' home directories, or some other, better option that I
| > | am too dense to think of :) ?
| >
| > The Right Way is for the imap server to be as flexible as the MTA is.
| > Unfortunately neither courier nor uw-imap are that flexible.
| > (Actually, I think uw is, but it's compile-time config).
|
| As I am using it, I am becoming more of the opinion that the imap server
| does just about everything I need. grep may not be an option, but mutt
| makes a fine imap client from the command line
That's good.
One issue to be aware of -- folders underneath INBOX (eg, imap path of
INBOX/foo) are stored as .<name> (namely ~/Maildir/.foo). This is
undersireable for me because I currently have "subfolders" like
~/Mail/lists/debian-user that mutt accesses directly. The two naming
schemes kinda clash. The other feature I like about using mutt with a
direct filesystem is the ability to use shell globbing to list folders
in the 'mailboxes' directive.
| > (I haven't actually solved the imap problem myself, and have postponed
| > it because I don't have any users using it)
|
| out of curiosity, do your users have mail delivered directly to their
| boxes or do they mount their home dirs from the mail server?
My user (me) has mail delivered directly to THE box in /var/mai/<me>
or ~/Mail/<whatever> according to my filters (currently exim but
testing out maildrop too). I think it's probable that my family will
start using my mail server soon as Juno rolls out their new seti@home
workalike requirements. In that case they'll have a choice of using
IMAPS-client-of-their-choice (from windo~1 box), squirrelmail (I met
the original developers in person this weekend), or learning how to
use ssh and either mutt or a GUI client with X-over-ssh. I think the
latter options are less likely than the former 2. ATM my dad has mail
from cybersitter delivered to him through my server, but an alias (or
is it a .forward? same difference) redirects it to his juno account.
Other than that, I'm the only user of my mail server.
-D
--
Microsoft DNS service terminates abnormally when it receives a response
to a dns query that was never made.
Fix information: run your DNS service on a different platform.
-- bugtraq
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
Attachment:
pgpJl2Ql6jCi9.pgp
Description: PGP signature