Subject: Re: New /etc/imapd.conf option? (Please support .imaprc)

From: "Peter Derr" <[email-masked]>
Date: Tue, 29 Jul 97 11:13:43 -0400

>	Do NOT use /etc/imapd.conf. this file is for UW-internal use
>	only.  Its semantics have changed in the past and will change
>	in the future.
>
>	If you want to export something other than the default UNIX
>	filesystem view, the correct thing to do is to write your
>	own environment policy routines in file
>		.../src/osdep/unix/env_unix.c
>	which is specially designed to contain all the environment
>	routines which user sites are likely to want to modify.
>
>	In particular, you should look at routines myhomedir() and
>	mailboxfile().

Really, the server ought to be customizable by means other than
modifying the source code.  It ought to be customizable system-wide by
using a file like /etc/imapd.conf or on a per-user basis with the
~/.imaprc file.

We have started using IMAP in our environment and have run into a
number of problems that could be solved by use of the ~/.imaprc file.

The per-user customization that the ~/.imaprc can offer would be
extremely useful.  Users that have been using various UNIX mail readers
and mail delivery mechanisms have evolved many personal styles and
configurations that many of the new IMAP clients aren't flexible enough
to adapt to, especially the location of the mail folders and the inbox,
and any prefix that might be required (like #mh/).

When considering whether to use the .imaprc, I waded though the
'information' in the sample imaprc file which declared that there was
no valid use for the imaprc file except for debugging purposes and its
use was basically unsupported. I of course put in the mandatory "I
accept the risk ..."  I was able to specify an alternate inbox this
way.

I feel that there is a valid use for a ~/.imaprc file that should be
supported. The variable system-inbox is a variable that I found a need
for. For a wide variety of reasons, many users here use slocal to parse
incomming mail and put the remainder into a different inbox.  This
obviously cannot be set on a system wide basis and if the mail client
isn't flexible enough to configure this, no other way that I can see
that it can be done.

Another variable that I would like to see supported is the location of
the mail folder hierachy.  As it stands, I need to tell my client (at
least the ones not too stupid to allow this) a subdirectory that
contains my mail. Frankly, giving a mail client access to ALL of my
files is rather scary. I can just see one of my users doing something
stupid (like opening their .profile) and getting the FOLDER INTERNAL
DATA message tacked onto the top. :-( This mail folder location could
be specified relative to $HOME either on a per user or a per system
basis.  Then, the server would not make any other files visible to any
client.

May I suggest that the .imaprc file contents be split into two
different files, one supported and limited to variables that users can
reasonably tinker with, and another file for all of the other
'debugging' or UW-specific options Mark does not want us mortals
tampering with.

This customization capability would really make the UW IMAP server more
useful.  This type of flexibility is what makes UNIX successfull.

Thanks,
Peter

---

From: "Steve \"Stevers!\" Coile" <[email-masked]>
Date: Tue, 29 Jul 1997 11:57:55 -0500 (EST)

[...]
>Really, the server ought to be customizable by means other than modifying
>the source code.  It ought to be customizable system-wide by using a
>file like /etc/imapd.conf or on a per-user basis with the ~/.imaprc file.

I concur.

-- 
    Steve Coile           P a t r i o t  N e t      Systems Engineering
 [email-masked]      Patriot Computer Group        (703) 277-7737

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Jul 1997 09:15:48 -0700 (PDT)

These are my final words on the subject:

1) imapd.conf and ~/.imaprc are NOT supported for any use outside of very
   limited UW internal use.

2) There is not at the present time any field-settable IMAP configuration.
   There may be in the future, but it will NOT be the imapd.conf file.

3) There have been multiple incidents in which sites have disregarded the
   warnings about imapd.conf and have had problems.  Nearly all of those
   incidents were completely unnecessary; the plug-and-play default was the
   correct configuration.

4) There are many other tasks which need to be done to c-client which are
   considerably more important that creating a field-settable IMAP
   configuration.  It will not increase the priority of a field-settable IMAP
   configuration to flame me on the c-client or other mailing lists.

5) c-client is free software.  It is worth at least as much as what you paid
   for it.  There are other, commercial, vendors of IMAP software.

6) DEC has many similar internal mechanisms in its software and hardware which
   are for company-internal purposes and are not for field modification.  DEC
   does this for good reasons.

I would appreciate that you accept my judgement that there are good reasons
for not supporting the imapd.conf functionality outside of UW.

Once again; there may be a future, supported, configuration functionality.
That functionality is not imapd.conf.  imapd.conf is a temporary function
which may be removed without replacement in future versions.  It is not wise
to depend upon it in any way.