On Thu, 15 Apr 2004, Mark Crispin wrote:
> On Thu, 15 Apr 2004, David Lee wrote:
> > Is there any reason why "/var/mail/$user" (usually in trad. UNIX format)
> > cannot itself be in "mbx" format? (Trying it as such seems not to work,
> > and this seems to be confirmed by the "docs/drivers.txt" description.)
>
> That's a good question! Fortunately, there are good answers:
>
> The spool directory is perceived by a large body of software to be "owned"
> by the traditional UNIX mail facility. As such, there is all sorts of
> software which will happily append a traditional UNIX format message to a
> file in the spool directory without any check to see if, in fact, that
> file actually is a traditional UNIX format message. The result is a
> corrupted mbx format mailbox.
Fair enough, in those many environments where c-client is not the
exclusive access to the "/var/mail" area.
In our own case, with one local exception, only c-client things access the
"/var/mail/$user" area, and we already run with "env_unix.c"/"*sysinbox()"
adjusting to use a different, non-default path. (For the record this is
"/var/mail/MN/$user" location where MN is uid-mod-100).
> You would think "shouldn't programs invoke sendmail, or at least pipe to
> /bin/mail or /bin/mail.local or whatever?" Of course! But all too many
> programs write directly because "it is more efficient that way."
Agreed. Our aforementioned "local exception" took this short cut, and
we're happy to regard that as our own problem of own own making that we
would need to sort out (and ought to anyway!).
> As for philosophical questions:
>
> There are system management and privacy concerns for not having people's
> INBOX in a shared spool directory.
>
> It is easier to administer quotas when the INBOX is co-located with the
> non-INBOX mailboxes. It is perfectly reasonable to set the user's
> "mailbox directory" to be something other than the user's UNIX home
> directory, and many sites do this.
>
> Anyone can obtain information about the size, last write, and last read of
> anyone else's INBOX in a shared directory. This can be, in certain
> circumstances, extremely useful for bad guys.
But they are all independent of the format (UNIX v. mbx etc.) in that
"/var/mail" area, aren't they?
All we're really after is a way for the INBOX to continued to be in some
area that isn't the home directory, and the existing "/var/mail/.../$user"
seemed a reasonable thought. (The only necessary change is to be "mbx"
rather than UNIX format.)
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?
With a test account, I put an mbx format "INBOX" into the home directory
and arranged for that homedir to be almost up to quota. I then delivered
some messages:
1. They delivered until the quota was exceeed, then backed up in
"/var/spool/mqueue" with EX_TEMPFAIL: that seems reasonable.
2. At the point where quota is exceeded, the "INBOX", previously OK, went
corrupt. Pine showed:
Invalid UID 0000000b in message 11, rebuilding
then a few seconds later:
SELECT failed: Last message (at 274832) runs past end of file (291881 > 290816)
That seems unreasonable. The one that tips the quota-balance also
seems to corrupt the file.
(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.)
--
: 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. :
