Joel,
Many thanks for the response ...
2. Turn the imap service into a black box. This would involve
provisioning each user with a separate home directory locally
on the imap server for their personal imap store and the various
.dot files sendmail would like to see, plus anything procmail
might like to see. Then we'd then have to come up with a way
for users to manage their .dot files inside the black box which
is getting complicated and not very transparent for users.
This is the right solution for the "personal imap store", IMHO, but the
dotfiles are a separate issue. You need to decide how you want to handle
inbound mail and perhaps consider that it doesn't need to be done on the
IMAP server, in which case all those files can be mounted on another
machine so long as you're able to transfer the mail after it's been
processed on that machine to the correct mail folder on the IMAP machine.
black box it is then - adding an extra layer to deal with the dotfiles
activity before delivery to the INBOX does however complicate things.
My personal preference is to have sendmail (postfix, actually) and procmail
running on the IMAP server for simplicity but maybe to NFS mount those
files used by sendmail and procmail, and to keep them in the user's
"normal" home directory.
I'm liking this already.
There are multiple ways to make them available
on the IMAP server; it depends on whether you accept the uw-imap default
of "home directory" being what it says in the password file, amongst other
things. You can symlink to the NFS mounted versions, or periodically copy
the contents of the files, etc.
Symlinking (or periodic copy) would obviously involve prior knowledge of
everything the dotfiles might indirectly reference ... so changing uw-imap's
fault personal store is probably more robust.
But there's no reason to think the dotfiles and the IMAP folders require
the same solution. That's the main point.
Understood. A possible senario we are now considering is leave our home
directories NFS mounted on the imap server (to handle the dotfiles) but replace
each users ~/mail folder with a symlink to a directory on a locally mounted
filesystem on the imap server. Thus users only have one 'home directory',
and existing tools for managing dotfiles don't break, and the imap daemons
are always talking to local filesystems. Ofcourse the syslinks won't resolve
elsewhere the home directories might be mounted (thus breaking local access
to folders by pine - but that could be a good thing). This also gives us an
incremental migration path since we can flip one user at a time to a new
non NFS user imap store.
You might also like to read
http://mailman1.u.washington.edu/pipermail/imap-uw/2006-November/000934.html
and the surrounding thread.
Very useful - thanks for the reference.
Thanks again,
Richard
________________________________________________________________________
Richard Miller
Computing Technical Services - ICS, Macquarie University - Syd, Aust
Email: [EMAIL PROTECTED], Ph: +61 2 98509587, Fax: +61 2 98509551
________________________________________________________________________
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
