[Dovecot] support for UW-style mbox

[Rich West]

> UW-IMAP will automatically append the contents of /var/spool/mail/user to
> ~user/mbox (and then clear /var/spool/mail/user) if ~user/mbox exists.
> I'd like to mimic that action with Dovecot. (I'm probably going to be unlucky,
> as an earlier respondent pointed out).
>   

> Sorry to show my ignorance, but I thought delivery was a function
> of the MTA (Exim in my case), which would require a change to my exim
> config file, and would probably not then be a per-user thing.
> (i.e. with UW-IMAP, if ~user/mbox doesnt exist, mail gets left in
> /var/spool/mail/user).
> I need to read about dovecot.conf

No, you are correct.  Delivery is handled by the MTA.  Dovecot just
needs to know where to access it.  By default, for example, with
Sendmail, it will place the email in /var/spool/mail (unless you change
some back-end code somewhere along the line), and then you can use
procmail (with a global procmailrc file in /etc) to place the mail where
you want it to go..

I haven't used UW-IMAP in a while now (well over a year and a half).  I
stopped using it at all of my supported sites because, even though it
was simple to manage, it was just way too slow.  From what I remember,
the UW implementation is such that UW-IMAP will read from the user's
mbox file if it exists, and if it doesn't, it will read from
<spooldir>/<username> (in this case, /var/spool/mail/user).  UW-IMAP (or
any IMAP) wouldn't actually do the delivery, so writing to the spool
directory temporarily and then moving it to the home directory shouldn't
actually happen.  However, I don't truly remember how it worked under
the hood, but that just doesn't seem right to me (too much chance for
conflict).  I do remember (back in the day) the headaches we would get
when trying to debug a "lost mail" problems (with a centralized
/var/spool/mail directory) and it turned out the user in question had
created an mbox file which had next to nothing in it. :)

-Rich