> A possible senario we are now considering is leave our home > directories NFS mounted on the imap server (to handle the dotfiles) but repla > ce > each users ~/mail folder with a symlink to a directory on a locally mounted > filesystem on the imap server.
The only problem with this is that nothing (in what you've described) is forcing users to configure procmail so that it's actually delivering into the (local) ~/mail tree; your users are still able to shoot themselves in the foot by delivering asynchronously over NFS. You could always mount the home directory read-only, but this might break other things (like procmail logfiles). On the other hand, maybe you do want your users to be able to deliver "off" the IMAP server and onto the NFS server if they so choose, but then they might need to be aware of the locking issues I refer to below. > 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). AFAIK most c-client file formats (everything except unix and mmdf?) require flock() (or a simulated equivalent) to work. Since it doesn't work over NFS I'd say folder corruption is inevitable if pine (or anything else) is accessing these (better!) formats over NFS. More details at http://www.washington.edu/imap/documentation/locking.txt.html Have you just been lucky so far or are you still using unix format folders, I wonder? That would make procmail configuration easier, but it's worth going to other formats, in which case you might need to help your users in configuring procmail to call dmail when delivering to folders. Cheers, - Joel _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
