imapext-2007
view docs/CONFIG @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
1 /* ========================================================================
2 * Copyright 1988-2006 University of Washington
3 *
4 * Licensed under the Apache License, Version 2.0 (the "License");
5 * you may not use this file except in compliance with the License.
6 * You may obtain a copy of the License at
7 *
8 * http://www.apache.org/licenses/LICENSE-2.0
9 *
10 *
11 * ========================================================================
12 */
14 UNIX Configuration Notes
16 The IMAP and POP3 servers are plug-and-play on standard UNIX
17 systems. There is no special configuration needed. Please ignore all
18 rumors to the effect that you need to create an IMAP configuration
19 file.
21 If your system is non-standard, virtually everything that you are
22 likely to want to modify can be found in the source file
23 .../src/osdep/unix/env_unix.c
24 In particular, special attention should be given to the routines:
25 env_init() initialize c-client environment variables,
26 especially the user name and home directory
27 sysinbox() return the UNIX path of the INBOX in which
28 mail delivery will place mail
29 mailboxdir() translate a mailbox name into the associated
30 UNIX directory for listing
31 mailboxfile() translate a mailbox name into the associated
32 UNIX file for opening
34 There are also build options in the top-level makefile which you
35 can give on the command line when building the software. The most
36 common build options are "SSLTYPE=unix", to build the software with SSL,
37 and "SSLTYPE=nopwd", to build the software with SSL and disable plaintext
38 authentication unless the session is encrypted.
40 You should modify these routines as necessary for local policy.
41 The most common modifications are to env_init(), to modify the
42 software's idea of the home directory (which is used everywhere as the
43 default directory), and to sysinbox(), to modify where the software
44 looks for newly-delivered mail.
46 Example 1: suppose your mailer delivers mail to file ".mailbox"
47 in the user's home directory instead of the default UNIX mail spool
48 directory. You will want to change routine sysinbox(), changing the
49 line that reads:
51 sprintf (tmp,"%s/%s",MAILSPOOL,myusername ());
52 to be:
53 sprintf (tmp,"%s/.mailbox",myhomedir ());
55 Example 2: suppose you want to change c-client's idea of the
56 user's mailbox directory to be the "mail" subdirectory of the user's
57 home directory instead of the user's home directory. You will want to
58 change variable mailsubdir, changing the line that reads:
60 static char *mailsubdir = NIL; /* mail subdirectory name */
61 to be:
62 static char *mailsubdir = "mail";/* mail subdirectory name */
64 Example 3: suppose you want to disable plaintext authentication in
65 the IMAP and POP servers. If you want to disable plaintext authentication
66 in unencrypted sessions but permit it in encrypted sessions, you should use
67 "SSLTYPE=nopwd" in the make command line when building the software. For
68 example, to do this on a Linux system with PAM authentication, do:
69 make lnp SSLTYPE=nopwd
70 If you want to disable plaintext authentication under all circumstances
71 (including SSL or TLS encrypted sessions), use "PASSWDTYPE=nul", e.g.:
72 make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
73 which will make it impossible to log in except via Kerberos.
75 Example 4: suppose you want the IMAP and POP servers to do a chroot()
76 to the user's home directory. This is not recommended; there are known
77 ways of attacking chroot() based security mechanisms. Furthermore, if you
78 do this you can not use a traditional UNIX format INBOX in the mail spool
79 directory, since chroot() will prevent access to that directory. If you
80 really want to do this, you need to change variable closedBox, changing
81 the line which reads:
83 static short closedBox = NIL; /* is a closed box */
84 to be:
85 static short closedBox = T; /* is a closed box */
87 Example 5: suppose you want to disable non-namespace access to the
88 filesystem root and other users' names, but do not want to go to the
89 extreme of chroot() and you want to allow access to a traditional UNIX
90 format INBOX in the mail spool directory. You need to change variable
91 restrictBox, changing the line which reads:
93 static short restrictBox = NIL; /* is a restricted box */
94 to be:
95 static short restrictBox = -1; /* is a restricted box */
97 Other values to set in restrictBox can be found in env_unix.h.
99 Ignore all references in env_unix.c to a configuration file; that
100 code is for UW-internal use only. It is extremely unlikely that that
101 facility will work usefully for you; it is extremely likely that you
102 will shoot yourself in the foot by using; and it frequently changes in
103 an incompatible manner.
105 There are two other build-time configuration issues which you may
106 need to consider: drivers and authenticators. Both of these are set
107 up in the top-level Makefile -- in particular, by the EXTRADRIVERS and
108 EXTRAAUTHENTICATORS variables.
110 Drivers are code modules that support different mailbox storage
111 technologies. By default, all drivers are enabled. There is little
112 benefit to be gained by disabling a driver, with one exception. The
113 mbox driver implements the behavior of automatically moving new mail
114 from the spool directory to the "mbox" file on the user's home
115 directory, if and *only* if the "mbox" exists and is in mailbox
116 format. The mbox driver is listed under EXTRADRIVERS; if you wish to
117 disable it just remove it from that list and rebuild.
119 Authenticators are code modules that support authentication
120 technology for the server (password file lookup, Kerberos, S/Key,
121 etc.). EXTRAAUTHENTICATORS is used to add an authenticator. This
122 subject can be complex; find a wizard if you can't figure it out.
124 It is also possible to add your own drivers and authenticators.
125 This is a topic for wizards, and is beyond the scope of this text.
127 NT Configuration Notes
129 This software is not plug-and-play on NT. If you're not a hacker
130 and/or are unwilling to invest the time to do some programming, you
131 probably want to buy a commercial server for NT.
133 The primary issue that you need to deal with is the format of
134 mail, where the INBOX is located, and where secondary folders are
135 located. As distributed, the software supports mail in the default
136 format used on UNIX (unix format) as well as mbx, mtx, and tenex
137 formats. mbx format is encouraged if at all possible; mtx and tenex
138 format are for compatibility with the past. However, it all depends
139 upon how and where your SMTP server delivers mail.
141 To change the default mailbox format, edit the symbol
142 DEFAULTDRIVER in:
143 ../src/osdep/nt/makefile.nt
144 or
145 ../src/osdep/nt/makefile.ntk
146 To change the default location of INBOX, edit the file:
147 ../src/osdep/nt/mailfile.h
148 Virtually everything else having to do with environment that you are
149 likely to want to modify can be found in the source file:
150 .../src/osdep/nt/env_nt.c
151 In particular, special attention should be given to the routines:
152 env_init() initialize c-client environment variables,
153 especially the user name and home directory
154 sysinbox() return the NT path of the INBOX in which
155 mail delivery will place mail
156 mailboxdir() translate a mailbox name into the associated
157 NT directory for listing
158 mailboxfile() translate a mailbox name into the associated
159 NT file for opening
161 You should modify these routines as necessary. The most common
162 modifications are to env_init(), to modify the software's idea of the
163 home directory (which is used everywhere as the default directory),
164 and to sysinbox(), to modify where the software looks for
165 newly-delivered mail.
167 There are two other build-time configuration issues which you may
168 need to consider: drivers and authenticators. Both of these are set
169 up in the top-level Makefile -- in particular, by the EXTRADRIVERS and
170 EXTRAAUTHENTICATORS variables.
172 Drivers are code modules that support different mailbox storage
173 technologies. By default, all drivers are enabled. There is little
174 benefit to be gained by disabling a driver.
176 Authenticators are code modules that support authentication
177 technology for the server (password file lookup, Kerberos, S/Key,
178 etc.). EXTRAAUTHENTICATORS is used to add an authenticator. This
179 subject can be complex; find a wizard if you can't figure it out.
181 It is also possible to add your own drivers and authenticators.