On Mon, 19 Apr 2004, Mark Crispin wrote: > On Mon, 19 Apr 2004, David Lee wrote: > > A further question: if the INBOX is in the home directory, and an incoming > > message would take it over quota, what is _supposed_ to happen? > > If delivery fails due to over quota, it is supposed to revert the file to > its previous state by truncating the file to the pre-delivery size.
OK. Thanks. > > > (imap-2002e, by the way. And the home directories are on a NFS server, so > > have to be NFS mounted onto the c-client email machines.) > > Are you saying that the mailbox file is accessed via NFS? mbx format is > not guaranteed to work via NFS. Indeed, that would be NFS access. And our NFS settings for the homedir are historically weak, allowing all sorts of attribute caching. So I can well believe that our corruption on this test account is because of that: we're asking for trouble in such a context! Indeed, leading up to this test, we had anticpated that this might be a problem, but I forgot about it in yesterday's reporting. Sorry. So for the moment you may safely regard that corruption report as our local problem (nothing for you to worry about) almost certainly caused by our local inappropriate NFS settings. Just for interest, our "/var/mail" area (UNIX format inboxes) is also NFS-mounted from the central NetApp fileserver onto the cluster of front-end IMAP/POP/tmail/dmail servers (RH9; Solaris 8). But here we have very strong NFS arguments: rw,noac,actimeo=0 and see no problems. (I realise the IMAP distribution urges great caution with NFS in any email context, but these systems (RH9, Solaris8, NetApp) seem to have good NFS implementations, so with strong NFS arguments the combination seems OK.) (But, to return to our scheduled programming, it would be nice if there were the option of "/var/mail" accepting an "mbx" format!) -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham : : Phone: +44 191 334 2752 U.K. :
