[Dovecot] RC7: its issues or mine?

[David Lee]

Background:  I'm new to dovecot (although with many years Washington IMAP
behind me).  We're considering migrating from Washington IMAP to dovecot
on the main service here, and have just started trying dovecot, using RC7.

Washington, IMAP has the usual(-ish) "/var/spool/mail" shared area for the
INBOX (trad. UNIX "From " format); a user's folders default to being in
their home directory (same format).  We are looking towards a "minimal
effort" migration to dovecot, so wish to keep this layout.  (In an ideal
world, we would re-think, including "maildir" etc.  But that's not an
option at the moment.)




I have encountered three issues (so far); I'm not sure whether their mine
or something in dovecot (if the latter, whether bugs or features;
whether RC7-specific issues; etc.).

1. The overall description of "default_mail_env" seems inadequate (in the
conf file, "doc/variables.txt" and "doc/mail-storages.txt").  I'm trying:
   default_mail_env = mbox:~:INBOX=/var/spool/mail/%-2.02i/%u:INDEX=/tmp/indexes/%d/%n

and that seems OK-ish.  (The extra "%-2.02i" is because we subdivide the
otherwise huge "/var/spool/mail/" directory using the user's uid-mod-100.)
But the mere act of an IMAP "login" commands creates a directory (empty)
with the liternal name of ~ (tilde).  (An IMAP 'list "Mail" "*"' command
successfully finds the usr folders in the 'Mail' subdirectory of the
user's home directory.)

It's almost as if the 'default_mail_env' is telling it to create (literal)
'~' before realising that this is shorthand (as in C-shell) for home
directory.


2. We have some Pine usage in our UNIX cluster.  Historically this has
taken advantage of the Pine "rsh mailmachine /etc/rimapd" ability to avoid
the need for the password: pre-authentication etc.  (Yes, we realise that
'rsh' has security issues.)  But when I try making symlink "/etc/rimapd"
point to "/usr/dovecot/sbin/dovecot" this fails:
   Error: Can't use SSL key file /etc/ssl/private/dovecot.pem: Permission denied

We have:
   /etc/ssl/certs/dovecot.pem    (mode 444)
   /etc/ssl/private/dovecot.pem  (mode 400)
for the sake of secure-IMAP (port 993).  But why does this come into the
equation at all for this (none-SSL) "rsh ... /etc/rimapd" usage?


3. I was developing and testing this here at work using an account that I
mostly use from home using Outlook Express.  I was very careful (I think!)
only to use the read-only "examine INBOX" command (not "select INBOX").
When I went home and tried it as usual (connecting to our production
Washington IMAP service reading that INBOX).  But OE showed all the email
(including previously read) as "unread" (closed envelope icon).  It seems
that dovecot has done something to the message headers (even under
"examine") that has worried OE.  Any thoughts?




Finally any hints for NFS-based working?  We have a farm of a few Fedora
machines running the IMAP processes and the sendmail locally-delivery.
Our current "/etc/fstab" NFS spec. for the INBOX area (on a NetApp) is:
   rw,noac,actimeo=0,vers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr,fg,nosuid

Any changes?  Issues?  Thinks to consider?  Etc.

Many thanks.


-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :