rev |
line source |
yuuji@0
|
1 /* ========================================================================
|
yuuji@0
|
2 * Copyright 1988-2007 University of Washington
|
yuuji@0
|
3 *
|
yuuji@0
|
4 * Licensed under the Apache License, Version 2.0 (the "License");
|
yuuji@0
|
5 * you may not use this file except in compliance with the License.
|
yuuji@0
|
6 * You may obtain a copy of the License at
|
yuuji@0
|
7 *
|
yuuji@0
|
8 * http://www.apache.org/licenses/LICENSE-2.0
|
yuuji@0
|
9 *
|
yuuji@0
|
10 *
|
yuuji@0
|
11 * ========================================================================
|
yuuji@0
|
12 */
|
yuuji@0
|
13
|
yuuji@0
|
14 IMAP Toolkit Frequently Asked Questions
|
yuuji@0
|
15
|
yuuji@0
|
16 Table of Contents
|
yuuji@0
|
17
|
yuuji@0
|
18 * 1. General/Software Feature Questions
|
yuuji@0
|
19 + 1.1 Can I set up a POP or IMAP server on UNIX/Linux/OSF/etc.?
|
yuuji@0
|
20 + 1.2 I am currently using qpopper as my POP3 server on UNIX.
|
yuuji@0
|
21 Do I need to replace it with ipop3d in order to run imapd?
|
yuuji@0
|
22 + 1.3 Can I set up a POP or IMAP server on Windows XP, 2000,
|
yuuji@0
|
23 NT, Me, 98, or 95?
|
yuuji@0
|
24 + 1.4 Can I set up a POP or IMAP server on Windows 3.1 or DOS?
|
yuuji@0
|
25 + 1.5 Can I set up a POP or IMAP server on Macintosh?
|
yuuji@0
|
26 + 1.6 Can I set up a POP or IMAP server on VAX/VMS?
|
yuuji@0
|
27 + 1.7 Can I set up a POP or IMAP server on TOPS-20?
|
yuuji@0
|
28 + 1.8 Are hierarchical mailboxes supported?
|
yuuji@0
|
29 + 1.9 Are "dual-use" mailboxes supported?
|
yuuji@0
|
30 + 1.10 Can I have a mailbox that has both messages and
|
yuuji@0
|
31 sub-mailboxes?
|
yuuji@0
|
32 + 1.11 What is the difference between "mailbox" and "folder"?
|
yuuji@0
|
33 + 1.12 What is the status of internationalization?
|
yuuji@0
|
34 + 1.13 Can I use SSL?
|
yuuji@0
|
35 + 1.14 Can I use TLS and the STARTTLS facility?
|
yuuji@0
|
36 + 1.15 Can I use CRAM-MD5 authentication?
|
yuuji@0
|
37 + 1.16 Can I use APOP authentication?
|
yuuji@0
|
38 + 1.17 Can I use Kerberos V5?
|
yuuji@0
|
39 + 1.18 Can I use PAM for plaintext passwords?
|
yuuji@0
|
40 + 1.19 Can I use Kerberos 5 for plaintext passwords?
|
yuuji@0
|
41 + 1.20 Can I use AFS for plaintext passwords?
|
yuuji@0
|
42 + 1.21 Can I use DCE for plaintext passwords?
|
yuuji@0
|
43 + 1.22 Can I use the CRAM-MD5 database for plaintext passwords?
|
yuuji@0
|
44 + 1.23 Can I disable plaintext passwords?
|
yuuji@0
|
45 + 1.24 Can I disable plaintext passwords on unencrypted
|
yuuji@0
|
46 sessions, but allow them on encrypted sessions?
|
yuuji@0
|
47 + 1.25 Can I use virtual hosts?
|
yuuji@0
|
48 + 1.26 Can I use RPOP authentication?
|
yuuji@0
|
49 + 1.27 Can I use Kerberos V4?
|
yuuji@0
|
50 + 1.28 Is there support for S/Key or OTP?
|
yuuji@0
|
51 + 1.29 Is there support for NTLM or SPA?
|
yuuji@0
|
52 + 1.30 Is there support for mh?
|
yuuji@0
|
53 + 1.31 Is there support for qmail and the maildir format?
|
yuuji@0
|
54 + 1.32 Is there support for the Cyrus mailbox format?
|
yuuji@0
|
55 + 1.33 Is this software Y2K compliant?
|
yuuji@0
|
56 * 2. What Do I Need to Build This Software?
|
yuuji@0
|
57 + 2.1 What do I need to build this software with SSL on UNIX?
|
yuuji@0
|
58 + 2.2 What do I need to build this software with Kerberos V on
|
yuuji@0
|
59 UNIX?
|
yuuji@0
|
60 + 2.3 What do I need to use a C++ compiler with this software
|
yuuji@0
|
61 to build my own application?
|
yuuji@0
|
62 + 2.4 What do I need to build this software on Windows?
|
yuuji@0
|
63 + 2.5 What do I need to build this software on DOS?
|
yuuji@0
|
64 + 2.6 Can't I use Borland C to build this software on the PC?
|
yuuji@0
|
65 + 2.7 What do I need to build this software on the Mac?
|
yuuji@0
|
66 + 2.8 What do I need to build this software on VMS?
|
yuuji@0
|
67 + 2.9 What do I need to build this software on TOPS-20?
|
yuuji@0
|
68 + 2.10 What do I need to build this software on Amiga or OS/2?
|
yuuji@0
|
69 + 2.11 What do I need to build this software on Windows CE?
|
yuuji@0
|
70 * 3. Build and Configuration Questions
|
yuuji@0
|
71 + 3.1 How do I configure the IMAP and POP servers on UNIX?
|
yuuji@0
|
72 + 3.2 I built and installed the servers according to the BUILD
|
yuuji@0
|
73 instructions. It can't be that easy. Don't I need to write a
|
yuuji@0
|
74 config file?
|
yuuji@0
|
75 + 3.3 How do I make the IMAP and POP servers look for INBOX at
|
yuuji@0
|
76 some place other than the mail spool directory?
|
yuuji@0
|
77 + 3.4 How do I make the IMAP server look for secondary folders
|
yuuji@0
|
78 at some place other than the user's home directory?
|
yuuji@0
|
79 + 3.5 How do I configure SSL?
|
yuuji@0
|
80 + 3.6 How do I configure TLS and the STARTTLS facility?
|
yuuji@0
|
81 + 3.7 How do I build/install OpenSSL and obtain/create
|
yuuji@0
|
82 certificates for use with SSL?
|
yuuji@0
|
83 + 3.8 How do I configure CRAM-MD5 authentication?
|
yuuji@0
|
84 + 3.9 How do I configure APOP authentication?
|
yuuji@0
|
85 + 3.10 How do I configure Kerberos V5?
|
yuuji@0
|
86 + 3.11 How do I configure PAM for plaintext passwords?
|
yuuji@0
|
87 + 3.12 It looks like all I have to do to make the server use
|
yuuji@0
|
88 Kerberos is to build with PAM on my Linux system, and set it
|
yuuji@0
|
89 up in PAM for Kerberos passwords. Right?
|
yuuji@0
|
90 + 3.13 How do I configure Kerberos 5 for plaintext passwords?
|
yuuji@0
|
91 + 3.14 How do I configure AFS for plaintext passwords?
|
yuuji@0
|
92 + 3.15 How do I configure DCE for plaintext passwords?
|
yuuji@0
|
93 + 3.16 How do I configure the CRAM-MD5 database for plaintext
|
yuuji@0
|
94 passwords?
|
yuuji@0
|
95 + 3.17 How do I disable plaintext passwords?
|
yuuji@0
|
96 + 3.18 How do I disable plaintext passwords on unencrypted
|
yuuji@0
|
97 sessions, but allow them in SSL or TLS sessions?
|
yuuji@0
|
98 + 3.19 How do I configure virtual hosts?
|
yuuji@0
|
99 + 3.20 Why do I get compiler warning messages such as:
|
yuuji@0
|
100 o passing arg 3 of `scandir' from incompatible pointer
|
yuuji@0
|
101 type
|
yuuji@0
|
102 o Pointers are not assignment-compatible.
|
yuuji@0
|
103 o Argument #4 is not the correct type.
|
yuuji@0
|
104 during the build?
|
yuuji@0
|
105 + 3.21 Why do I get compiler warning messages such as
|
yuuji@0
|
106 o Operation between types "void(*)(int)" and "void*" is
|
yuuji@0
|
107 not allowed.
|
yuuji@0
|
108 o Function argument assignment between types "void*" and
|
yuuji@0
|
109 "void(*)(int)" is not allowed.
|
yuuji@0
|
110 o Pointers are not assignment-compatible.
|
yuuji@0
|
111 o Argument #5 is not the correct type.
|
yuuji@0
|
112 during the build?
|
yuuji@0
|
113 + 3.22 Why do I get linker warning messages such as:
|
yuuji@0
|
114 o mtest.c:515: the `gets' function is dangerous and should
|
yuuji@0
|
115 not be used.
|
yuuji@0
|
116 during the build? Isn't this a security bug?
|
yuuji@0
|
117 + 3.23 Why do I get linker warning messages such as:
|
yuuji@0
|
118 o auth_ssl.c:92: the `tmpnam' function is dangerous and
|
yuuji@0
|
119 should not be used.
|
yuuji@0
|
120 during the build? Isn't this a security bug?
|
yuuji@0
|
121 + 3.24 OK, suppose I see a warning message about a function
|
yuuji@0
|
122 being "dangerous and should not be used" for something other
|
yuuji@0
|
123 than this gets() or tmpnam() call?
|
yuuji@0
|
124 * 4. Operational Questions
|
yuuji@0
|
125 + 4.1 How can I enable anonymous IMAP logins?
|
yuuji@0
|
126 + 4.2 How do I set up an alert message that each IMAP user will
|
yuuji@0
|
127 see?
|
yuuji@0
|
128 + 4.3 How does the c-client library choose which of its several
|
yuuji@0
|
129 mechanisms to use to establish an IMAP connection to the
|
yuuji@0
|
130 server? I noticed that it can connect on port 143, port 993,
|
yuuji@0
|
131 via rsh, and via ssh.
|
yuuji@0
|
132 + 4.4 I am using a TLS-capable IMAP server, so I don't need to
|
yuuji@0
|
133 use /ssl to get encryption. However, I want to be certain
|
yuuji@0
|
134 that my session is TLS encrypted before I send my password.
|
yuuji@0
|
135 How to I do this?
|
yuuji@0
|
136 + 4.5 How do I use one of the alternative formats described in
|
yuuji@0
|
137 the formats.txt document? In particular, I hear that mbx
|
yuuji@0
|
138 format will give me better performance and allow shared
|
yuuji@0
|
139 access.
|
yuuji@0
|
140 + 4.6 How do I set up shared mailboxes?
|
yuuji@0
|
141 + 4.7 How can I make the server syslogs go to someplace other
|
yuuji@0
|
142 than the mail syslog?
|
yuuji@0
|
143 * 5. Security Questions
|
yuuji@0
|
144 + 5.1 I see that the IMAP server allows access to arbitary
|
yuuji@0
|
145 files on the system, including /etc/passwd! How do I disable
|
yuuji@0
|
146 this?
|
yuuji@0
|
147 + 5.2 I've heard that IMAP servers are insecure. Is this true?
|
yuuji@0
|
148 + 5.3 How do I know that I have the most secure version of the
|
yuuji@0
|
149 server?
|
yuuji@0
|
150 + 5.4 I see all these strcpy() and sprintf() calls, those are
|
yuuji@0
|
151 unsafe, aren't they?
|
yuuji@0
|
152 + 5.5 Those /tmp lock files are protected 666, is that really
|
yuuji@0
|
153 right?
|
yuuji@0
|
154 * 6. Why Did You Do This Strange Thing? Questions
|
yuuji@0
|
155 + 6.1 Why don't you use GNU autoconfig / automake /
|
yuuji@0
|
156 autoblurdybloop?
|
yuuji@0
|
157 + 6.2 Why do you insist upon a build with -g? Doesn't it waste
|
yuuji@0
|
158 disk and memory space?
|
yuuji@0
|
159 + 6.3 Why don't you make c-client a shared library?
|
yuuji@0
|
160 + 6.4 Why don't you use iconv() for internationalization
|
yuuji@0
|
161 support?
|
yuuji@0
|
162 + 6.5 Why is the IMAP server connected to the home directory by
|
yuuji@0
|
163 default?
|
yuuji@0
|
164 + 6.6 I have a Windows system. Why isn't the server plug and
|
yuuji@0
|
165 play for me?
|
yuuji@0
|
166 + 6.7 I looked at the UNIX SSL code and saw that you have the
|
yuuji@0
|
167 SSL data payload size set to 8192 bytes. SSL allows 16K; why
|
yuuji@0
|
168 aren't you using the full size?
|
yuuji@0
|
169 + 6.8 Why is an mh format INBOX called #mhinbox instead of just
|
yuuji@0
|
170 INBOX?
|
yuuji@0
|
171 + 6.9 Why don't you support the maildir format?
|
yuuji@0
|
172 + 6.10 Why don't you support the Cyrus format?
|
yuuji@0
|
173 + 6.11 Why is it creating extra forks on my SVR4 system?
|
yuuji@0
|
174 + 6.12 Why are you so fussy about the date/time format in the
|
yuuji@0
|
175 internal "From " line in traditional UNIX mailbox files? My
|
yuuji@0
|
176 other mail program just considers every line that starts with
|
yuuji@0
|
177 "From " to be the start of the message.
|
yuuji@0
|
178 + 6.13 Why is traditional UNIX format the default format?
|
yuuji@0
|
179 + 6.14 Why do you write this "DON'T DELETE THIS MESSAGE --
|
yuuji@0
|
180 FOLDER INTERNAL DATA" message at the start of traditional
|
yuuji@0
|
181 UNIX and MMDF format mailboxes?
|
yuuji@0
|
182 + 6.15 Why don't you stash the mailbox metadata in the first
|
yuuji@0
|
183 real message of the mailbox instead of writing this fake
|
yuuji@0
|
184 FOLDER INTERNAL DATA message?
|
yuuji@0
|
185 + 6.16 Why aren't "dual-use" mailboxes the default?
|
yuuji@0
|
186 + 6.17 Why do you use ucbcc to build on Solaris?
|
yuuji@0
|
187 + 6.18 Why should I care about some old system with BSD
|
yuuji@0
|
188 libraries? cc is the right thing on my Solaris system!
|
yuuji@0
|
189 + 6.19 Why do you insist upon writing .lock files in the spool
|
yuuji@0
|
190 directory?
|
yuuji@0
|
191 + 6.20 Why should I care about compatibility with the past?
|
yuuji@0
|
192 * 7. Problems and Annoyances
|
yuuji@0
|
193 + 7.1 Help! My INBOX is empty! What happened to my messages?
|
yuuji@0
|
194 + 7.2 Help! All my messages in a non-INBOX mailbox have been
|
yuuji@0
|
195 concatenated into one message which claims to be from me and
|
yuuji@0
|
196 has a subject of the file name of the mailbox! What's going
|
yuuji@0
|
197 on?
|
yuuji@0
|
198 + 7.3 Why do I get the message:
|
yuuji@0
|
199 o CREATE failed: Can't create mailbox node xxxxxxxxx: File
|
yuuji@0
|
200 exists
|
yuuji@0
|
201 and how do I fix it?
|
yuuji@0
|
202 + 7.4 Why can't I log in to the server? The user name and
|
yuuji@0
|
203 password are right!
|
yuuji@0
|
204 + 7.5 Help! My load average is soaring and I see hundreds of
|
yuuji@0
|
205 POP and IMAP servers, many logged in as the same user!
|
yuuji@0
|
206 + 7.6 Why does mail disappear even though I set "keep mail on
|
yuuji@0
|
207 server"?
|
yuuji@0
|
208 + 7.7 Why do I get the message
|
yuuji@0
|
209 o Moved ##### bytes of new mail to /home/user/mbox from
|
yuuji@0
|
210 /var/spool/mail/user
|
yuuji@0
|
211 and why did this happen?
|
yuuji@0
|
212 + 7.8 Why isn't it showing the local host name as a
|
yuuji@0
|
213 fully-qualified domain name?
|
yuuji@0
|
214 + 7.9 Why is the local host name in the From/Sender/Message-ID
|
yuuji@0
|
215 headers of outgoing mail not coming out as a fully-qualified
|
yuuji@0
|
216 domain name?
|
yuuji@0
|
217 + 7.10 What does the message:
|
yuuji@0
|
218 o Mailbox vulnerable - directory /var/spool/mail must have
|
yuuji@0
|
219 1777 protection
|
yuuji@0
|
220 mean? How can I fix this?
|
yuuji@0
|
221 + 7.11 What does the message:
|
yuuji@0
|
222 o Mailbox is open by another process, access is readonly
|
yuuji@0
|
223 mean? How do I fix this?
|
yuuji@0
|
224 + 7.12 What does the message:
|
yuuji@0
|
225 o Can't get write access to mailbox, access is readonly
|
yuuji@0
|
226 mean?
|
yuuji@0
|
227 + 7.13 I set my POP3 client to "delete messages from server"
|
yuuji@0
|
228 but they never get deleted. What is wrong?
|
yuuji@0
|
229 + 7.14 What do messages such as:
|
yuuji@0
|
230 o Message ... UID ... already has UID ...
|
yuuji@0
|
231 o Message ... UID ... less than ...
|
yuuji@0
|
232 o Message ... UID ... greater than last ...
|
yuuji@0
|
233 o Invalid UID ... in message ..., rebuilding UIDs
|
yuuji@0
|
234 mean?
|
yuuji@0
|
235 + 7.15 What do the error messages:
|
yuuji@0
|
236 o Unable to read internal header at ...
|
yuuji@0
|
237 o Unable to find CRLF at ...
|
yuuji@0
|
238 o Unable to parse internal header at ...
|
yuuji@0
|
239 o Unable to parse message date at ...
|
yuuji@0
|
240 o Unable to parse message flags at ...
|
yuuji@0
|
241 o Unable to parse message UID at ...
|
yuuji@0
|
242 o Unable to parse message size at ...
|
yuuji@0
|
243 o Last message (at ... ) runs past end of file ...
|
yuuji@0
|
244 mean? I am using mbx format.
|
yuuji@0
|
245 + 7.16 What do the syslog messages:
|
yuuji@0
|
246 o imap/tcp server failing (looping)
|
yuuji@0
|
247 o pop3/tcp server failing (looping)
|
yuuji@0
|
248 mean? When it happens, the listed service shuts down. How can
|
yuuji@0
|
249 I fix this?
|
yuuji@0
|
250 + 7.17 What does the syslog message:
|
yuuji@0
|
251 o Mailbox lock file /tmp/.600.1df3 open failure:
|
yuuji@0
|
252 Permission denied
|
yuuji@0
|
253 mean?
|
yuuji@0
|
254 + 7.18 What do the syslog messages:
|
yuuji@0
|
255 o Command stream end of file, while reading line user=...
|
yuuji@0
|
256 host=...
|
yuuji@0
|
257 o Command stream end of file, while reading char user=...
|
yuuji@0
|
258 host=...
|
yuuji@0
|
259 o Command stream end of file, while writing text user=...
|
yuuji@0
|
260 host=...
|
yuuji@0
|
261 mean?
|
yuuji@0
|
262 + 7.19 Why did my POP or IMAP session suddenly disconnect? The
|
yuuji@0
|
263 syslog has the message:
|
yuuji@0
|
264 o Killed (lost mailbox lock) user=... host=...
|
yuuji@0
|
265 + 7.20 Why does my IMAP client show all the files on the
|
yuuji@0
|
266 system, recursively from the UNIX root directory?
|
yuuji@0
|
267 + 7.21 Why does my IMAP client show all of my files,
|
yuuji@0
|
268 recursively from my UNIX home directory?
|
yuuji@0
|
269 + 7.22 Why does my IMAP client show that I have mailboxes named
|
yuuji@0
|
270 "#mhinbox", "#mh", "#shared", "#ftp", "#news", and "#public"?
|
yuuji@0
|
271 + 7.23 Why does my IMAP client show all my files in my home
|
yuuji@0
|
272 directory?
|
yuuji@0
|
273 + 7.24 Why is there a long delay before I get connected to the
|
yuuji@0
|
274 IMAP or POP server, no matter what client I use?
|
yuuji@0
|
275 + 7.25 Why is there a long delay in Pine or any other c-client
|
yuuji@0
|
276 based application call before I get connected to the IMAP
|
yuuji@0
|
277 server? The hang seems to be in the c-client mail_open()
|
yuuji@0
|
278 call. I don't have this problem with any other IMAP client.
|
yuuji@0
|
279 There is no delay connecting to a POP3 or NNTP server with
|
yuuji@0
|
280 mail_open().
|
yuuji@0
|
281 + 7.26 Why does a message sometimes get split into two or more
|
yuuji@0
|
282 messages on my SUN system?
|
yuuji@0
|
283 + 7.27 Why did my POP or IMAP session suddenly disconnect? The
|
yuuji@0
|
284 syslog has the message:
|
yuuji@0
|
285 o Autologout user=<...my user name...> host=<...my imap
|
yuuji@0
|
286 server...>
|
yuuji@0
|
287 + 7.28 What does the UNIX error message:
|
yuuji@0
|
288 o TLS/SSL failure: myserver: SSL negotiation failed
|
yuuji@0
|
289 mean?
|
yuuji@0
|
290 + 7.29 What does the PC error message:
|
yuuji@0
|
291 o TLS/SSL failure: myserver: Unexpected TCP input
|
yuuji@0
|
292 disconnect
|
yuuji@0
|
293 mean?
|
yuuji@0
|
294 + 7.30 What does the error message:
|
yuuji@0
|
295 o TLS/SSL failure: myserver: Server name does not match
|
yuuji@0
|
296 certificate
|
yuuji@0
|
297 mean?
|
yuuji@0
|
298 + 7.31 What does the UNIX error message:
|
yuuji@0
|
299 o TLS/SSL failure: myserver: self-signed certificate
|
yuuji@0
|
300 mean?
|
yuuji@0
|
301 + 7.32 What does the PC error message
|
yuuji@0
|
302 o TLS/SSL failure: myserver: Self-signed certificate or
|
yuuji@0
|
303 untrusted authority
|
yuuji@0
|
304 mean?
|
yuuji@0
|
305 + 7.33 What does the UNIX error message:
|
yuuji@0
|
306 o TLS/SSL failure: myserver: unable to get local issuer
|
yuuji@0
|
307 certificate
|
yuuji@0
|
308 mean?
|
yuuji@0
|
309 + 7.34 Why does reading certain messages hang when using
|
yuuji@0
|
310 Netscape? It works fine with Pine!
|
yuuji@0
|
311 + 7.35 Why does Netscape say that there's a problem with the
|
yuuji@0
|
312 IMAP server and that I should "Contact your mail server
|
yuuji@0
|
313 administrator."?
|
yuuji@0
|
314 + 7.36 Why is one user creating huge numbers of IMAP or POP
|
yuuji@0
|
315 server sessions?
|
yuuji@0
|
316 + 7.37 Why don't I get any new mail notifications from Outlook
|
yuuji@0
|
317 Express or Outlook after a while?
|
yuuji@0
|
318 + 7.38 Why don't I get any new mail notifications from
|
yuuji@0
|
319 Entourage?
|
yuuji@0
|
320 + 7.39 Why doesn't Entourage work at all?
|
yuuji@0
|
321 + 7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work at all?
|
yuuji@0
|
322 + 7.41 Why can't I connect via SSL to Eudora? It says the
|
yuuji@0
|
323 connection has been broken, and in the server syslogs I see
|
yuuji@0
|
324 "Command stream end of file".
|
yuuji@0
|
325 + 7.42 Sheesh. Aren't there any good IMAP clients out there?
|
yuuji@0
|
326 + 7.43 But wait! PC Pine (or other PC program build with
|
yuuji@0
|
327 c-client) crashes with the message
|
yuuji@0
|
328 o incomplete SecBuffer exceeds maximum buffer size
|
yuuji@0
|
329 when I use SSL connections. This is a bug in c-client, right?
|
yuuji@0
|
330 + 7.44 My qpopper users keep on getting the DON'T DELETE THIS
|
yuuji@0
|
331 MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or
|
yuuji@0
|
332 IMAP. How can I fix this?
|
yuuji@0
|
333 + 7.45 Help! I installed the servers but I can't connect to
|
yuuji@0
|
334 them from my client!
|
yuuji@0
|
335 + 7.46 Why do I get the message
|
yuuji@0
|
336 o Can not authenticate to SMTP server: 421 SMTP connection
|
yuuji@0
|
337 went away!
|
yuuji@0
|
338 and why did this happen? There was also something about
|
yuuji@0
|
339 o SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
|
yuuji@0
|
340 + 7.47 Why do I get the message
|
yuuji@0
|
341 o SMTP Authentication cancelled
|
yuuji@0
|
342 and why did this happen? There was also something about
|
yuuji@0
|
343 o SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
|
yuuji@0
|
344 + 7.48 Why do I get the message
|
yuuji@0
|
345 o Invalid base64 string
|
yuuji@0
|
346 when I try to authenticate to a Cyrus server?
|
yuuji@0
|
347 * 8. Where to Go For Additional Information
|
yuuji@0
|
348 + 8.1 Where can I go to ask questions?
|
yuuji@0
|
349 + 8.2 I have some ideas for enhancements to IMAP. Where should
|
yuuji@0
|
350 I go?
|
yuuji@0
|
351 + 8.3 Where can I read more about IMAP and other email
|
yuuji@0
|
352 protocols?
|
yuuji@0
|
353 + 8.4 Where can I find out more about setting up and
|
yuuji@0
|
354 administering an IMAP server?
|
yuuji@0
|
355 _________________________________________________________________
|
yuuji@0
|
356
|
yuuji@0
|
357 1. General/Software Feature Questions
|
yuuji@0
|
358 _________________________________________________________________
|
yuuji@0
|
359
|
yuuji@0
|
360 1.1 Can I set up a POP or IMAP server on UNIX/Linux/OSF/etc.?
|
yuuji@0
|
361
|
yuuji@0
|
362 Yes. Refer to the UNIX specific notes in files CONFIG and
|
yuuji@0
|
363 BUILD.
|
yuuji@0
|
364 _________________________________________________________________
|
yuuji@0
|
365
|
yuuji@0
|
366 1.2 I am currently using qpopper as my POP3 server on UNIX. Do I need
|
yuuji@0
|
367 to replace it with ipop3d in order to run imapd?
|
yuuji@0
|
368
|
yuuji@0
|
369 Not necessarily.
|
yuuji@0
|
370
|
yuuji@0
|
371 Although ipop3d interoperates with imapd better than qpopper,
|
yuuji@0
|
372 imapd and qpopper will work together. The few qpopper/imapd
|
yuuji@0
|
373 interoperability issues mostly affect users who use both IMAP
|
yuuji@0
|
374 and POP3 clients; those users would probably be better served
|
yuuji@0
|
375 if their POP3 server is ipop3d.
|
yuuji@0
|
376
|
yuuji@0
|
377 If you are happy with qpopper and just want to add imapd, you
|
yuuji@0
|
378 should do that, and defer a decision on changing qpopper to
|
yuuji@0
|
379 ipop3d. That way, you can get comfortable with imapd's
|
yuuji@0
|
380 performance, without changing anything for your qpopper users.
|
yuuji@0
|
381
|
yuuji@0
|
382 Many sites have subsequently decided to change from qpopper to
|
yuuji@0
|
383 ipop3d in order to get better POP3/IMAP interoperability. If
|
yuuji@0
|
384 you need to do this, you'll know. There also seems to be a way
|
yuuji@0
|
385 to make qpopper work better with imapd; see the answer to the
|
yuuji@0
|
386 My qpopper users keep on getting the DON'T DELETE THIS MESSAGE
|
yuuji@0
|
387 -- FOLDER INTERNAL DATA if they also use Pine or IMAP. How can
|
yuuji@0
|
388 I fix this? question.
|
yuuji@0
|
389 _________________________________________________________________
|
yuuji@0
|
390
|
yuuji@0
|
391 1.3 Can I set up a POP or IMAP server on Windows XP, 2000, NT, Me, 98,
|
yuuji@0
|
392 or 95?
|
yuuji@0
|
393
|
yuuji@0
|
394 Yes. Refer to the NT specific notes in files CONFIG and BUILD.
|
yuuji@0
|
395 Also, for DOS-based versions of Windows (Windows Me, 98, and
|
yuuji@0
|
396 95) you *must* set up CRAM-MD5 authentication, as described in
|
yuuji@0
|
397 md5.txt.
|
yuuji@0
|
398
|
yuuji@0
|
399 There is no file access control on Windows 9x or Me, so you
|
yuuji@0
|
400 probably will have to do modifications to env_unix.c to prevent
|
yuuji@0
|
401 people from hacking others' mail.
|
yuuji@0
|
402
|
yuuji@0
|
403 Note, however, that the server is not plug and play the way it
|
yuuji@0
|
404 is for UNIX.
|
yuuji@0
|
405 _________________________________________________________________
|
yuuji@0
|
406
|
yuuji@0
|
407 1.4 Can I set up a POP or IMAP server on Windows 3.1 or DOS?
|
yuuji@0
|
408 1.5 Can I set up a POP or IMAP server on Macintosh?
|
yuuji@0
|
409 1.6 Can I set up a POP or IMAP server on VAX/VMS?
|
yuuji@0
|
410
|
yuuji@0
|
411 Yes, it's just a small matter of programming.
|
yuuji@0
|
412 _________________________________________________________________
|
yuuji@0
|
413
|
yuuji@0
|
414 1.7 Can I set up a POP or IMAP server on TOPS-20?
|
yuuji@0
|
415
|
yuuji@0
|
416 You have a TOPS-20 system? Cool.
|
yuuji@0
|
417
|
yuuji@0
|
418 If IMAP2 (RFC 1176) is good enough for you, you can use MAPSER
|
yuuji@0
|
419 which is about the ultimate gonzo pure TOPS-20 extended
|
yuuji@0
|
420 addressing assembly language program. Unfortunately, IMAP2 is
|
yuuji@0
|
421 barely good enough for Pine these days, and most other IMAP
|
yuuji@0
|
422 clients won't work with IMAP2 at all. Maybe someone will hack
|
yuuji@0
|
423 MAPSER to do IMAP4rev1 some day.
|
yuuji@0
|
424
|
yuuji@0
|
425 We don't know if anyone wrote a POP3 server for TOPS-20. There
|
yuuji@0
|
426 definitely was a POP2 server once upon a time.
|
yuuji@0
|
427
|
yuuji@0
|
428 Or you can port the POP and IMAP server from this IMAP toolkit
|
yuuji@0
|
429 to it. All that you need for a first stab is to port the MTX
|
yuuji@0
|
430 driver. That'll probably be just a couple of hours of hacking.
|
yuuji@0
|
431 _________________________________________________________________
|
yuuji@0
|
432
|
yuuji@0
|
433 1.8 Are hierarchical mailboxes supported?
|
yuuji@0
|
434 1.9 Are "dual-use" mailboxes supported?
|
yuuji@0
|
435 1.10 Can I have a mailbox that has both messages and sub-mailboxes?
|
yuuji@0
|
436
|
yuuji@0
|
437 Yes. However, there is one important caveat.
|
yuuji@0
|
438
|
yuuji@0
|
439 Some mailbox formats, including the default which is the
|
yuuji@0
|
440 traditional UNIX mailbox format, are stored as a single file
|
yuuji@0
|
441 containing all the messages. UNIX does not permit a name in the
|
yuuji@0
|
442 filesystem to be both a file and a directory; consequently you
|
yuuji@0
|
443 can not have a sub-mailbox within a mailbox that is in one of
|
yuuji@0
|
444 these formats.
|
yuuji@0
|
445
|
yuuji@0
|
446 This is not a limitation of the software; this is a limitation
|
yuuji@0
|
447 of UNIX. For example, there are mailbox formats in which the
|
yuuji@0
|
448 name is a directory and each message is a file within that
|
yuuji@0
|
449 directory; these formats support sub-mailboxes within such
|
yuuji@0
|
450 mailboxes. However, for technical reasons, the "flat file"
|
yuuji@0
|
451 formats are generally preferred since they perform better. Read
|
yuuji@0
|
452 imap-2007/docs/formats.txt for more information on this topic.
|
yuuji@0
|
453
|
yuuji@0
|
454 It is always permissible to create a directory that is not a
|
yuuji@0
|
455 mailbox, and have sub-mailboxes under it. The easiest way to
|
yuuji@0
|
456 create a directory is to create a new mailbox inside a
|
yuuji@0
|
457 directory that doesn't already exist. For example, if you
|
yuuji@0
|
458 create "Mail/testbox" on UNIX, the directory "Mail/" will
|
yuuji@0
|
459 automatically be created and then the mailbox "testbox" will be
|
yuuji@0
|
460 created as a sub-mailbox of "Mail/".
|
yuuji@0
|
461
|
yuuji@0
|
462 It is also possible to create the name "Mail/" directly. Check
|
yuuji@0
|
463 the documentation for your client software to see how to do
|
yuuji@0
|
464 this with that software.
|
yuuji@0
|
465
|
yuuji@0
|
466 Of course, on Windows systems you would use "\" instead of "/".
|
yuuji@0
|
467 _________________________________________________________________
|
yuuji@0
|
468
|
yuuji@0
|
469 1.11 What is the difference between "mailbox" and "folder"?
|
yuuji@0
|
470
|
yuuji@0
|
471 The term "mailbox" is IMAP-speak for what a lot of software
|
yuuji@0
|
472 calls a "folder" or a "mail folder". However, "folder" is often
|
yuuji@0
|
473 used in other contexts to refer to a directory, for example, in
|
yuuji@0
|
474 the graphic user interface on both Windows and Macintosh.
|
yuuji@0
|
475
|
yuuji@0
|
476 A "mailbox" is specifically defined as a named object that
|
yuuji@0
|
477 contains messages. It is not required to be capable of
|
yuuji@0
|
478 containing other types of objects including other mailboxes;
|
yuuji@0
|
479 although some mailbox formats will permit this.
|
yuuji@0
|
480
|
yuuji@0
|
481 In IMAP-speak, a mailbox which can not contain other mailboxes
|
yuuji@0
|
482 is called a "no-inferiors mailbox". Similarly, a directory
|
yuuji@0
|
483 which can not contain messages is not a mailbox and is called a
|
yuuji@0
|
484 "no-select name".
|
yuuji@0
|
485 _________________________________________________________________
|
yuuji@0
|
486
|
yuuji@0
|
487 1.12 What is the status of internationalization?
|
yuuji@0
|
488
|
yuuji@0
|
489 The IMAP toolkit is partially internationalized and
|
yuuji@0
|
490 multilingualized.
|
yuuji@0
|
491
|
yuuji@0
|
492 Searching is supported in the following charsets: US-ASCII,
|
yuuji@0
|
493 UTF-8, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4,
|
yuuji@0
|
494 ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9,
|
yuuji@0
|
495 ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14,
|
yuuji@0
|
496 ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U (alias KOI8-RU),
|
yuuji@0
|
497 TIS-620, VISCII, ISO-2022-JP, ISO-2022-KR, ISO-2022-CN,
|
yuuji@0
|
498 ISO-2022-JP-1, ISO-2022-JP-2, GB2312 (alias CN-GB),
|
yuuji@0
|
499 CN-GB-12345, BIG5 (alias CN-BIG5), EUC-JP, EUC-KR, Shift_JIS,
|
yuuji@0
|
500 Shift-JIS, KS_C_5601-1987, KS_C_5601-1992, WINDOWS_874,
|
yuuji@0
|
501 WINDOWS-1250, WINDOWS-1251, WINDOWS-1252, WINDOWS-1253,
|
yuuji@0
|
502 WINDOWS-1254, WINDOWS-1255, WINDOWS-1256, WINDOWS-1257,
|
yuuji@0
|
503 WINDOWS-1258.
|
yuuji@0
|
504
|
yuuji@0
|
505 All ISO-2022-?? charsets are treated identically, and support
|
yuuji@0
|
506 ASCII, JIS Roman, hankaku katakana, ISO-8859-[1 - 10], TIS, GB
|
yuuji@0
|
507 2312, JIS X 0208, JIS X 0212, KSC 5601, and planes 1 and 2 of
|
yuuji@0
|
508 CNS 11643.
|
yuuji@0
|
509
|
yuuji@0
|
510 EUC-JP includes support for JIS X 0212 and hankaku katakana.
|
yuuji@0
|
511
|
yuuji@0
|
512 c-client library support also exists to convert text in any of
|
yuuji@0
|
513 the above charsets into Unicode, including headers with MIME
|
yuuji@0
|
514 encoded-words.
|
yuuji@0
|
515
|
yuuji@0
|
516 There is no support for localization (e.g. non-English error
|
yuuji@0
|
517 messages) at the present time, but such support is planned.
|
yuuji@0
|
518 _________________________________________________________________
|
yuuji@0
|
519
|
yuuji@0
|
520 1.13 Can I use SSL?
|
yuuji@0
|
521
|
yuuji@0
|
522 Yes. See the answer to the How do I configure SSL? question.
|
yuuji@0
|
523 _________________________________________________________________
|
yuuji@0
|
524
|
yuuji@0
|
525 1.14 Can I use TLS and the STARTTLS facility?
|
yuuji@0
|
526
|
yuuji@0
|
527 Yes. See the answer to the How do I configure TLS and the
|
yuuji@0
|
528 STARTTLS facility? question.
|
yuuji@0
|
529 _________________________________________________________________
|
yuuji@0
|
530
|
yuuji@0
|
531 1.15 Can I use CRAM-MD5 authentication?
|
yuuji@0
|
532
|
yuuji@0
|
533 Yes. See the answer to the How do I configure CRAM-MD5
|
yuuji@0
|
534 authentication? question.
|
yuuji@0
|
535 _________________________________________________________________
|
yuuji@0
|
536
|
yuuji@0
|
537 1.16 Can I use APOP authentication?
|
yuuji@0
|
538
|
yuuji@0
|
539 Yes. See the How do I configure APOP authentication? question.
|
yuuji@0
|
540
|
yuuji@0
|
541 Note that there is no client support for APOP authentication.
|
yuuji@0
|
542 _________________________________________________________________
|
yuuji@0
|
543
|
yuuji@0
|
544 1.17 Can I use Kerberos V5?
|
yuuji@0
|
545
|
yuuji@0
|
546 Yes. See the answer to the How do I configure Kerberos V5?
|
yuuji@0
|
547 question.
|
yuuji@0
|
548 _________________________________________________________________
|
yuuji@0
|
549
|
yuuji@0
|
550 1.18 Can I use PAM for plaintext passwords?
|
yuuji@0
|
551
|
yuuji@0
|
552 Yes. See the answer to the How do I configure PAM for plaintext
|
yuuji@0
|
553 passwords? question.
|
yuuji@0
|
554 _________________________________________________________________
|
yuuji@0
|
555
|
yuuji@0
|
556 1.19 Can I use Kerberos 5 for plaintext passwords?
|
yuuji@0
|
557
|
yuuji@0
|
558 Yes. See the answer to the How do I configure Kerberos 5 for
|
yuuji@0
|
559 plaintext passwords? question.
|
yuuji@0
|
560 _________________________________________________________________
|
yuuji@0
|
561
|
yuuji@0
|
562 1.20 Can I use AFS for plaintext passwords?
|
yuuji@0
|
563
|
yuuji@0
|
564 Yes. See the answer to the How do I configure AFS for plaintext
|
yuuji@0
|
565 passwords? question.
|
yuuji@0
|
566 _________________________________________________________________
|
yuuji@0
|
567
|
yuuji@0
|
568 1.21 Can I use DCE for plaintext passwords?
|
yuuji@0
|
569
|
yuuji@0
|
570 Yes. See the answer to the How do I configure DCE for plaintext
|
yuuji@0
|
571 passwords? question.
|
yuuji@0
|
572 _________________________________________________________________
|
yuuji@0
|
573
|
yuuji@0
|
574 1.22 Can I use the CRAM-MD5 database for plaintext passwords?
|
yuuji@0
|
575
|
yuuji@0
|
576 Yes. See the answer to the How do I configure the CRAM-MD5
|
yuuji@0
|
577 database for plaintext passwords? question.
|
yuuji@0
|
578 _________________________________________________________________
|
yuuji@0
|
579
|
yuuji@0
|
580 1.23 Can I disable plaintext passwords?
|
yuuji@0
|
581
|
yuuji@0
|
582 Yes. See the answer to the How do I disable plaintext
|
yuuji@0
|
583 passwords? question.
|
yuuji@0
|
584 _________________________________________________________________
|
yuuji@0
|
585
|
yuuji@0
|
586 1.24 Can I disable plaintext passwords on unencrypted sessions, but
|
yuuji@0
|
587 allow them on encrypted sessions?
|
yuuji@0
|
588
|
yuuji@0
|
589 Yes. See the answer to the How do I disable plaintext passwords
|
yuuji@0
|
590 on unencrypted sessions, but allow them in SSL or TLS sessions?
|
yuuji@0
|
591 question.
|
yuuji@0
|
592 _________________________________________________________________
|
yuuji@0
|
593
|
yuuji@0
|
594 1.25 Can I use virtual hosts?
|
yuuji@0
|
595
|
yuuji@0
|
596 Yes. See the answer to the How do I configure virtual hosts?
|
yuuji@0
|
597 question.
|
yuuji@0
|
598 _________________________________________________________________
|
yuuji@0
|
599
|
yuuji@0
|
600 1.26 Can I use RPOP authentication?
|
yuuji@0
|
601
|
yuuji@0
|
602 There is no support for RPOP authentication.
|
yuuji@0
|
603 _________________________________________________________________
|
yuuji@0
|
604
|
yuuji@0
|
605 1.27 Can I use Kerberos V4?
|
yuuji@0
|
606
|
yuuji@0
|
607 Kerberos V4 is not supported. Kerberos V4 client-only
|
yuuji@0
|
608 contributed code is available in
|
yuuji@0
|
609
|
yuuji@0
|
610 ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z
|
yuuji@0
|
611
|
yuuji@0
|
612 This is a patchkit which must be applied to the IMAP toolkit
|
yuuji@0
|
613 according to the instructions in the patchkit's README. We can
|
yuuji@0
|
614 not promise that this code works.
|
yuuji@0
|
615 _________________________________________________________________
|
yuuji@0
|
616
|
yuuji@0
|
617 1.28 Is there support for S/Key or OTP?
|
yuuji@0
|
618
|
yuuji@0
|
619 There is currently no support for S/Key or OTP. There may be an
|
yuuji@0
|
620 OTP SASL authenticator available from third parties.
|
yuuji@0
|
621 _________________________________________________________________
|
yuuji@0
|
622
|
yuuji@0
|
623 1.29 Is there support for NTLM or SPA?
|
yuuji@0
|
624
|
yuuji@0
|
625 There is currently no support for NTLM or SPA, nor are there
|
yuuji@0
|
626 any plans to add such support. In general, I avoid
|
yuuji@0
|
627 vendor-specific mechanisms. I also believe that these
|
yuuji@0
|
628 mechanisms are being deprecated by their vendor.
|
yuuji@0
|
629
|
yuuji@0
|
630 There may be an NTLM SASL authenticator available from third
|
yuuji@0
|
631 parties.
|
yuuji@0
|
632 _________________________________________________________________
|
yuuji@0
|
633
|
yuuji@0
|
634 1.30 Is there support for mh?
|
yuuji@0
|
635
|
yuuji@0
|
636 Yes, but only as a legacy format. Your mh format INBOX is
|
yuuji@0
|
637 accessed by the name "#mhinbox", and all other mh format
|
yuuji@0
|
638 mailboxes are accessed by prefixing "#mh/" to the name, e.g.
|
yuuji@0
|
639 "#mh/foo". The mh support uses the "Path:" entry in your
|
yuuji@0
|
640 .mh_profile file to identify the root directory of your mh
|
yuuji@0
|
641 format mailboxes.
|
yuuji@0
|
642
|
yuuji@0
|
643 Non-legacy use of mh format is not encouraged. There is no
|
yuuji@0
|
644 support for permanent flags or unique identifiers; furthermore
|
yuuji@0
|
645 there are known severe performance problems with the mh format.
|
yuuji@0
|
646 _________________________________________________________________
|
yuuji@0
|
647
|
yuuji@0
|
648 1.31 Is there support for qmail and the maildir format?
|
yuuji@0
|
649
|
yuuji@0
|
650 There is no support for qmail or the maildir format in our
|
yuuji@0
|
651 distribution, nor are there any plans to add such support.
|
yuuji@0
|
652 Maildir support may be available from third parties.
|
yuuji@0
|
653 _________________________________________________________________
|
yuuji@0
|
654
|
yuuji@0
|
655 1.32 Is there support for the Cyrus mailbox format?
|
yuuji@0
|
656
|
yuuji@0
|
657 No.
|
yuuji@0
|
658 _________________________________________________________________
|
yuuji@0
|
659
|
yuuji@0
|
660 1.33 Is this software Y2K compliant?
|
yuuji@0
|
661
|
yuuji@0
|
662 Please read the files Y2K and calendar.txt.
|
yuuji@0
|
663 _________________________________________________________________
|
yuuji@0
|
664
|
yuuji@0
|
665 2. What Do I Need to Build This Software?
|
yuuji@0
|
666 _________________________________________________________________
|
yuuji@0
|
667
|
yuuji@0
|
668 2.1 What do I need to build this software with SSL on UNIX?
|
yuuji@0
|
669
|
yuuji@0
|
670 You need to build and install OpenSSL first.
|
yuuji@0
|
671 _________________________________________________________________
|
yuuji@0
|
672
|
yuuji@0
|
673 2.2 What do I need to build this software with Kerberos V on UNIX?
|
yuuji@0
|
674
|
yuuji@0
|
675 You need to build and install MIT Kerberos first.
|
yuuji@0
|
676 _________________________________________________________________
|
yuuji@0
|
677
|
yuuji@0
|
678 2.3 What do I need to use a C++ compiler with this software to build
|
yuuji@0
|
679 my own application?
|
yuuji@0
|
680
|
yuuji@0
|
681 If you are building an application using the c-client library,
|
yuuji@0
|
682 use the new c-client.h file instead of including the other
|
yuuji@0
|
683 include files. It seems that c-client.h should define away all
|
yuuji@0
|
684 the troublesome names that conflict with C++.
|
yuuji@0
|
685
|
yuuji@0
|
686 If you use gcc, you may need to use -fno-operator-names as
|
yuuji@0
|
687 well.
|
yuuji@0
|
688 _________________________________________________________________
|
yuuji@0
|
689
|
yuuji@0
|
690 2.4 What do I need to build this software on Windows?
|
yuuji@0
|
691
|
yuuji@0
|
692 You need Microsoft Visual C++ 6.0, Visual C++ .NET, or Visual
|
yuuji@0
|
693 C# .NET (which you can buy from any computer store), along with
|
yuuji@0
|
694 the Microsoft Platform SDK (which you can download from
|
yuuji@0
|
695 Microsoft's web site).
|
yuuji@0
|
696
|
yuuji@0
|
697 You do not need to install the entire Platform SDK; it suffices
|
yuuji@0
|
698 to install just the Core SDK and the Internet Development SDK.
|
yuuji@0
|
699 _________________________________________________________________
|
yuuji@0
|
700
|
yuuji@0
|
701 2.5 What do I need to build this software on DOS?
|
yuuji@0
|
702
|
yuuji@0
|
703 It's been several years since we last attempted to do this. At
|
yuuji@0
|
704 the time, we used Microsoft C.
|
yuuji@0
|
705 _________________________________________________________________
|
yuuji@0
|
706
|
yuuji@0
|
707 2.6 Can't I use Borland C to build this software on the PC?
|
yuuji@0
|
708
|
yuuji@0
|
709 Probably not. If you know otherwise, please let us know.
|
yuuji@0
|
710 _________________________________________________________________
|
yuuji@0
|
711
|
yuuji@0
|
712 2.7 What do I need to build this software on the Mac?
|
yuuji@0
|
713
|
yuuji@0
|
714 It has been several years since we last attempted to do this.
|
yuuji@0
|
715 At the time, we used Symantec THINK C; but today you'll need a
|
yuuji@0
|
716 C compiler which allows segments to be more than 32K.
|
yuuji@0
|
717 _________________________________________________________________
|
yuuji@0
|
718
|
yuuji@0
|
719 2.8 What do I need to build this software on VMS?
|
yuuji@0
|
720
|
yuuji@0
|
721 You need the VMS C compiler, and either the Multinet or Netlib
|
yuuji@0
|
722 TCP.
|
yuuji@0
|
723 _________________________________________________________________
|
yuuji@0
|
724
|
yuuji@0
|
725 2.9 What do I need to build this software on TOPS-20?
|
yuuji@0
|
726
|
yuuji@0
|
727 You need the TOPS-20 KCC compiler.
|
yuuji@0
|
728 _________________________________________________________________
|
yuuji@0
|
729
|
yuuji@0
|
730 2.10 What do I need to build this software on Amiga or OS/2?
|
yuuji@0
|
731
|
yuuji@0
|
732 We don't know.
|
yuuji@0
|
733 _________________________________________________________________
|
yuuji@0
|
734
|
yuuji@0
|
735 2.11 What do I need to build this software on Windows CE?
|
yuuji@0
|
736
|
yuuji@0
|
737 This port is incomplete. Someone needs to finish it.
|
yuuji@0
|
738 _________________________________________________________________
|
yuuji@0
|
739
|
yuuji@0
|
740 3. Build and Configuration Questions
|
yuuji@0
|
741 _________________________________________________________________
|
yuuji@0
|
742
|
yuuji@0
|
743 3.1 How do I configure the IMAP and POP servers on UNIX?
|
yuuji@0
|
744 3.2 I built and installed the servers according to the BUILD
|
yuuji@0
|
745 instructions. It can't be that easy. Don't I need to write a config
|
yuuji@0
|
746 file?
|
yuuji@0
|
747
|
yuuji@0
|
748 For ordinary "vanilla" UNIX systems, this software is plug and
|
yuuji@0
|
749 play; just build it, install it, and you're done. If you have a
|
yuuji@0
|
750 modified system, then you may want to do additional work; most
|
yuuji@0
|
751 of this is to a single source code file (env_unix.c on UNIX
|
yuuji@0
|
752 systems). Read the file CONFIG for more details.
|
yuuji@0
|
753
|
yuuji@0
|
754 Yes, it's that easy. There are some additional options, such as
|
yuuji@0
|
755 SSL or Kerberos, which require additional steps to build. See
|
yuuji@0
|
756 the relevant questions below.
|
yuuji@0
|
757 _________________________________________________________________
|
yuuji@0
|
758
|
yuuji@0
|
759 3.3 How do I make the IMAP and POP servers look for INBOX at some
|
yuuji@0
|
760 place other than the mail spool directory?
|
yuuji@0
|
761 3.4 How do I make the IMAP server look for secondary folders at some
|
yuuji@0
|
762 place other than the user's home directory?
|
yuuji@0
|
763
|
yuuji@0
|
764 Please read the file CONFIG for discussion of this and other
|
yuuji@0
|
765 issues.
|
yuuji@0
|
766 _________________________________________________________________
|
yuuji@0
|
767
|
yuuji@0
|
768 3.5 How do I configure SSL?
|
yuuji@0
|
769 3.6 How do I configure TLS and the STARTTLS facility?
|
yuuji@0
|
770
|
yuuji@0
|
771 imap-2007 supports SSL and TLS client functionality on UNIX and
|
yuuji@0
|
772 32-bit Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS
|
yuuji@0
|
773 server functionality on UNIX for IMAP and POP3.
|
yuuji@0
|
774
|
yuuji@0
|
775 UNIX SSL build requires that a third-party software package,
|
yuuji@0
|
776 OpenSSL, be installed on the system first. Read
|
yuuji@0
|
777 imap-2007/docs/SSLBUILD for more information.
|
yuuji@0
|
778
|
yuuji@0
|
779 SSL is supported via undocumented Microsoft interfaces in
|
yuuji@0
|
780 Windows 9x and NT4; and via standard interfaces in Windows
|
yuuji@0
|
781 2000, Windows Millenium, and Windows XP.
|
yuuji@0
|
782 _________________________________________________________________
|
yuuji@0
|
783
|
yuuji@0
|
784 3.7 How do I build/install OpenSSL and obtain/create certificates for
|
yuuji@0
|
785 use with SSL?
|
yuuji@0
|
786
|
yuuji@0
|
787 If you need help in doing this, try the contacts mentioned in
|
yuuji@0
|
788 the OpenSSL README. We do not offer support for OpenSSL or
|
yuuji@0
|
789 certificates.
|
yuuji@0
|
790 _________________________________________________________________
|
yuuji@0
|
791
|
yuuji@0
|
792 3.8 How do I configure CRAM-MD5 authentication?
|
yuuji@0
|
793 3.9 How do I configure APOP authentication?
|
yuuji@0
|
794
|
yuuji@0
|
795 CRAM-MD5 authentication is enabled in the IMAP and POP3 client
|
yuuji@0
|
796 code on all platforms. Read md5.txt to learn how to set up
|
yuuji@0
|
797 CRAM-MD5 and APOP authentication on UNIX and NT servers.
|
yuuji@0
|
798
|
yuuji@0
|
799 There is no support for APOP client authentication.
|
yuuji@0
|
800 _________________________________________________________________
|
yuuji@0
|
801
|
yuuji@0
|
802 3.10 How do I configure Kerberos V5?
|
yuuji@0
|
803
|
yuuji@0
|
804 imap-2007 supports client and server functionality on UNIX and
|
yuuji@0
|
805 32-bit Windows.
|
yuuji@0
|
806
|
yuuji@0
|
807 Kerberos V5 is supported by default in Windows 2000 builds:
|
yuuji@0
|
808
|
yuuji@0
|
809 nmake -f makefile.w2k
|
yuuji@0
|
810
|
yuuji@0
|
811 Other builds require that a third-party Kerberos package, e.g.
|
yuuji@0
|
812 MIT Kerberos, be installed on the system first.
|
yuuji@0
|
813
|
yuuji@0
|
814 To build with Kerberos V5 on UNIX, include
|
yuuji@0
|
815 EXTRAAUTHENTICATORS=gss in the make command line, e.g.
|
yuuji@0
|
816
|
yuuji@0
|
817 make lnp EXTRAAUTHENTICATORS=gss
|
yuuji@0
|
818
|
yuuji@0
|
819 To build with Kerberos V5 on Windows 9x, Windows Millenium, and
|
yuuji@0
|
820 NT4, use the "makefile.ntk" file instead of "makefile.nt":
|
yuuji@0
|
821
|
yuuji@0
|
822
|
yuuji@0
|
823 nmake -f makefile.ntk
|
yuuji@0
|
824 _________________________________________________________________
|
yuuji@0
|
825
|
yuuji@0
|
826 3.11 How do I configure PAM for plaintext passwords?
|
yuuji@0
|
827
|
yuuji@0
|
828 On Linux systems, use the lnp port, e.g.
|
yuuji@0
|
829
|
yuuji@0
|
830 make lnp
|
yuuji@0
|
831
|
yuuji@0
|
832 On Solaris systems and other systems with defective PAM
|
yuuji@0
|
833 implementations, build with PASSWDTYPE=pmb, e.g.
|
yuuji@0
|
834
|
yuuji@0
|
835 make sol PASSWDTYPE=pmb
|
yuuji@0
|
836
|
yuuji@0
|
837 On all other systems, build with PASSWDTYPE=pam, e.g
|
yuuji@0
|
838
|
yuuji@0
|
839 make foo PASSWDTYPE=pam
|
yuuji@0
|
840
|
yuuji@0
|
841 If you build with PASSWDTYPE=pam and authentication does not
|
yuuji@0
|
842 work, try rebuilding (after a "make clean") with
|
yuuji@0
|
843 PASSWDTYPE=pmb.
|
yuuji@0
|
844 _________________________________________________________________
|
yuuji@0
|
845
|
yuuji@0
|
846 3.12 It looks like all I have to do to make the server use Kerberos is
|
yuuji@0
|
847 to build with PAM on my Linux system, and set it up in PAM for
|
yuuji@0
|
848 Kerberos passwords. Right?
|
yuuji@0
|
849
|
yuuji@0
|
850 Yes and no.
|
yuuji@0
|
851
|
yuuji@0
|
852 Doing this will make plaintext password authentication use the
|
yuuji@0
|
853 Kerberos password instead of the /etc/passwd password.
|
yuuji@0
|
854
|
yuuji@0
|
855 However, this will NOT give you Kerberos-secure authentication.
|
yuuji@0
|
856 See the answer to the How do I configure Kerberos V5? question
|
yuuji@0
|
857 for how to build with Kerberos-secure authentication.
|
yuuji@0
|
858 _________________________________________________________________
|
yuuji@0
|
859
|
yuuji@0
|
860 3.13 How do I configure Kerberos 5 for plaintext passwords?
|
yuuji@0
|
861
|
yuuji@0
|
862 Build with PASSWDTYPE=gss, e.g.
|
yuuji@0
|
863
|
yuuji@0
|
864 make sol PASSWDTYPE=gss
|
yuuji@0
|
865
|
yuuji@0
|
866 However, this will NOT give you Kerberos-secure authentication.
|
yuuji@0
|
867 See the answer to the How do I configure Kerberos V5? question
|
yuuji@0
|
868 for how to build with Kerberos-secure authentication.
|
yuuji@0
|
869 _________________________________________________________________
|
yuuji@0
|
870
|
yuuji@0
|
871 3.14 How do I configure AFS for plaintext passwords?
|
yuuji@0
|
872
|
yuuji@0
|
873 Build with PASSWDTYPE=afs, e.g
|
yuuji@0
|
874
|
yuuji@0
|
875 make sol PASSWDTYPE=afs
|
yuuji@0
|
876 _________________________________________________________________
|
yuuji@0
|
877
|
yuuji@0
|
878 3.15 How do I configure DCE for plaintext passwords?
|
yuuji@0
|
879
|
yuuji@0
|
880 Build with PASSWDTYPE=dce, e.g
|
yuuji@0
|
881
|
yuuji@0
|
882 make sol PASSWDTYPE=dce
|
yuuji@0
|
883 _________________________________________________________________
|
yuuji@0
|
884
|
yuuji@0
|
885 3.16 How do I configure the CRAM-MD5 database for plaintext passwords?
|
yuuji@0
|
886
|
yuuji@0
|
887 The CRAM-MD5 password database is automatically used for
|
yuuji@0
|
888 plaintext password if it exists.
|
yuuji@0
|
889
|
yuuji@0
|
890 Note that this is NOT CRAM-MD5-secure authentication. You
|
yuuji@0
|
891 probably want to consider disabling plaintext passwords for
|
yuuji@0
|
892 non-SSL/TLS sessions. See the next two questions.
|
yuuji@0
|
893 _________________________________________________________________
|
yuuji@0
|
894
|
yuuji@0
|
895 3.17 How do I disable plaintext passwords?
|
yuuji@0
|
896
|
yuuji@0
|
897 Server-level plaintext passwords can be disabled by setting
|
yuuji@0
|
898 PASSWDTYPE=nul, e.g.
|
yuuji@0
|
899
|
yuuji@0
|
900 make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
|
yuuji@0
|
901
|
yuuji@0
|
902 Note that you must have a CRAM-MD5 database installed or
|
yuuji@0
|
903 specify at least one EXTRAAUTHENTICATOR, otherwise it will not
|
yuuji@0
|
904 be possible to log in to the server.
|
yuuji@0
|
905
|
yuuji@0
|
906 When plaintext passwords are disabled, the IMAP server will
|
yuuji@0
|
907 advertise the LOGINDISABLED capability and the POP3 server will
|
yuuji@0
|
908 not advertise the USER capability.
|
yuuji@0
|
909
|
yuuji@0
|
910 3.18 How do I disable plaintext passwords on unencrypted sessions, but
|
yuuji@0
|
911 allow them in SSL or TLS sessions?
|
yuuji@0
|
912
|
yuuji@0
|
913 Do not set PASSWDTYPE=nul or SSLTYPE=unix. Set SSLTYPE=nopwd
|
yuuji@0
|
914 instead, e.g.
|
yuuji@0
|
915
|
yuuji@0
|
916 make lnx SSLTYPE=nopwd
|
yuuji@0
|
917
|
yuuji@0
|
918 When plaintext passwords are disabled, the IMAP server will
|
yuuji@0
|
919 advertise the LOGINDISABLED capability and the POP3 server will
|
yuuji@0
|
920 not advertise the USER capability.
|
yuuji@0
|
921
|
yuuji@0
|
922 Plaintext passwords will always be enabled in SSL sessions; the
|
yuuji@0
|
923 IMAP server will not advertise the LOGINDISABLED capability and
|
yuuji@0
|
924 the POP3 server will advertise the USER capability.
|
yuuji@0
|
925
|
yuuji@0
|
926 If the client does a successful start-TLS in a non-SSL session,
|
yuuji@0
|
927 plaintext passwords will be enabled, and a new CAPABILITY or
|
yuuji@0
|
928 CAPA command (which is required after start-TLS) will show the
|
yuuji@0
|
929 effect as in SSL sessions.
|
yuuji@0
|
930 _________________________________________________________________
|
yuuji@0
|
931
|
yuuji@0
|
932 3.19 How do I configure virtual hosts?
|
yuuji@0
|
933
|
yuuji@0
|
934 This is automatic, but with certain restrictions.
|
yuuji@0
|
935
|
yuuji@0
|
936 The most important one is that each virtual host must have its
|
yuuji@0
|
937 own IP address; otherwise the server has no way of knowing
|
yuuji@0
|
938 which virtual host is desired.
|
yuuji@0
|
939
|
yuuji@0
|
940 As distributed, the software uses a global password file; hence
|
yuuji@0
|
941 user "fred" on one virtual host is "fred" on all virtual hosts.
|
yuuji@0
|
942 You may want to modify the checkpw() routine to implement some
|
yuuji@0
|
943 other policy (e.g. separate password files).
|
yuuji@0
|
944
|
yuuji@0
|
945 Note that the security model assumes that all users have their
|
yuuji@0
|
946 own unique UNIX UID number. So if you use separate password
|
yuuji@0
|
947 files you should make certain that the UID numbers do not
|
yuuji@0
|
948 overlap between different files.
|
yuuji@0
|
949
|
yuuji@0
|
950 More advanced virtual host support may be available as patches
|
yuuji@0
|
951 from third parties.
|
yuuji@0
|
952 _________________________________________________________________
|
yuuji@0
|
953
|
yuuji@0
|
954 3.20 Why do I get compiler warning messages such as:
|
yuuji@0
|
955 passing arg 3 of `scandir' from incompatible pointer type
|
yuuji@0
|
956 Pointers are not assignment-compatible.
|
yuuji@0
|
957 Argument #4 is not the correct type.
|
yuuji@0
|
958
|
yuuji@0
|
959 during the build?
|
yuuji@0
|
960
|
yuuji@0
|
961 You can safely ignore these messages.
|
yuuji@0
|
962
|
yuuji@0
|
963 Over the years, the prototype for scandir() has changed, and
|
yuuji@0
|
964 thus is variant across different UNIX platforms. In particular,
|
yuuji@0
|
965 the definitions of the third argument (type select_t) and
|
yuuji@0
|
966 fourth argument (type compar_t) have changed over the years,
|
yuuji@0
|
967 the issue being whether or not the arguments to the functions
|
yuuji@0
|
968 pointed to by these function pointers are of type const or not.
|
yuuji@0
|
969
|
yuuji@0
|
970 The way that c-client calls scandir() will tend to generate
|
yuuji@0
|
971 these compiler warnings on newer systems such as Linux;
|
yuuji@0
|
972 however, it will still build. The problem with fixing the call
|
yuuji@0
|
973 is that then it won't build on older systems.
|
yuuji@0
|
974 _________________________________________________________________
|
yuuji@0
|
975
|
yuuji@0
|
976 3.21 Why do I get compiler warning messages such as
|
yuuji@0
|
977 Operation between types "void(*)(int)" and "void*" is not allowed.
|
yuuji@0
|
978 Function argument assignment between types "void*" and "void(*)(int)" is not a
|
yuuji@0
|
979 llowed.
|
yuuji@0
|
980 Pointers are not assignment-compatible.
|
yuuji@0
|
981 Argument #5 is not the correct type.
|
yuuji@0
|
982
|
yuuji@0
|
983 during the build?
|
yuuji@0
|
984
|
yuuji@0
|
985 You can safely ignore these messages.
|
yuuji@0
|
986
|
yuuji@0
|
987 All known systems have no problem with casting a function
|
yuuji@0
|
988 pointer to/from a void* pointer, certain C compilers issue a
|
yuuji@0
|
989 compiler diagnostic because this facility is listed as a
|
yuuji@0
|
990 "Common extension" by the C standard:
|
yuuji@0
|
991
|
yuuji@0
|
992 K.5.7 Function pointer casts
|
yuuji@0
|
993 [#1] A pointer to an object or to void may be cast to a pointer
|
yuuji@0
|
994 to a function, allowing data to be invoked as a function (6.3.4).
|
yuuji@0
|
995 [#2] A pointer to a function may be cast to a pointer to an
|
yuuji@0
|
996 object or to void, allowing a function to be inspected or
|
yuuji@0
|
997 modified (for example, by a debugger) (6.3.4).
|
yuuji@0
|
998
|
yuuji@0
|
999 It may be just a "common extension", but this facility is
|
yuuji@0
|
1000 relied upon heavily by c-client.
|
yuuji@0
|
1001 _________________________________________________________________
|
yuuji@0
|
1002
|
yuuji@0
|
1003 3.22 Why do I get linker warning messages such as:
|
yuuji@0
|
1004 mtest.c:515: the `gets' function is dangerous and should not be used.
|
yuuji@0
|
1005
|
yuuji@0
|
1006 during the build? Isn't this a security bug?
|
yuuji@0
|
1007
|
yuuji@0
|
1008 You can safely ignore this message.
|
yuuji@0
|
1009
|
yuuji@0
|
1010 Certain linkers, most notably on Linux, give this warning
|
yuuji@0
|
1011 message. It is indeed true that the traditional gets() function
|
yuuji@0
|
1012 is not a safe one.
|
yuuji@0
|
1013
|
yuuji@0
|
1014 However, the mtest program is only a demonstration program, a
|
yuuji@0
|
1015 model of a very basic application program using c-client. It is
|
yuuji@0
|
1016 not something that you would install, much less run in any
|
yuuji@0
|
1017 security-sensitive context.
|
yuuji@0
|
1018
|
yuuji@0
|
1019 mtest has numerous other shortcuts that you wouldn't want to do
|
yuuji@0
|
1020 in a real application program.
|
yuuji@0
|
1021
|
yuuji@0
|
1022 The only "security bug" with mtest would be if it was run by
|
yuuji@0
|
1023 some script in a security-sensitive context, but mtest isn't
|
yuuji@0
|
1024 particularly useful for such purposes. If you wanted to write a
|
yuuji@0
|
1025 script to automate some email task using c-client, you'd be
|
yuuji@0
|
1026 better off using imapd instead of mtest.
|
yuuji@0
|
1027
|
yuuji@0
|
1028 mtest only has two legitimate uses. It's a useful testbed for
|
yuuji@0
|
1029 me when debugging new versions of c-client, and it's useful as
|
yuuji@0
|
1030 a model for someone writing a simple c-client application to
|
yuuji@0
|
1031 see how the various calls work.
|
yuuji@0
|
1032
|
yuuji@0
|
1033 By the way, if you need a more advanced example of c-client
|
yuuji@0
|
1034 programming than mtest (and you probably will), I recommend
|
yuuji@0
|
1035 that you look at the source code for imapd and Pine.
|
yuuji@0
|
1036 _________________________________________________________________
|
yuuji@0
|
1037
|
yuuji@0
|
1038 3.23 Why do I get linker warning messages such as:
|
yuuji@0
|
1039 auth_ssl.c:92: the `tmpnam' function is dangerous and should not be used.
|
yuuji@0
|
1040
|
yuuji@0
|
1041 during the build? Isn't this a security bug?
|
yuuji@0
|
1042
|
yuuji@0
|
1043 You can safely ignore this message.
|
yuuji@0
|
1044
|
yuuji@0
|
1045 Certain linkers, most notably on Linux, give this warning
|
yuuji@0
|
1046 message, based upon two known issues with tmpnam():
|
yuuji@0
|
1047
|
yuuji@0
|
1048 there can be a buffer overflow if an inadequate buffer is
|
yuuji@0
|
1049 allocated.
|
yuuji@0
|
1050 there can be a timing race caused by certain incautious
|
yuuji@0
|
1051 usage of the return value.
|
yuuji@0
|
1052
|
yuuji@0
|
1053 Neither of these issues applies in the particular use that is
|
yuuji@0
|
1054 made of tmpnam(). More importantly, the tmpnam() call is never
|
yuuji@0
|
1055 executed on Linux systems.
|
yuuji@0
|
1056 _________________________________________________________________
|
yuuji@0
|
1057
|
yuuji@0
|
1058 3.24 OK, suppose I see a warning message about a function being
|
yuuji@0
|
1059 "dangerous and should not be used" for something other than this
|
yuuji@0
|
1060 gets() or tmpnam() call?
|
yuuji@0
|
1061
|
yuuji@0
|
1062 Please forward the details for investigation.
|
yuuji@0
|
1063 _________________________________________________________________
|
yuuji@0
|
1064
|
yuuji@0
|
1065 4. Operational Questions
|
yuuji@0
|
1066 _________________________________________________________________
|
yuuji@0
|
1067
|
yuuji@0
|
1068 4.1 How can I enable anonymous IMAP logins?
|
yuuji@0
|
1069
|
yuuji@0
|
1070 Create the file /etc/anonymous.newsgroups. At the present time,
|
yuuji@0
|
1071 this file should be empty. This will permit IMAP logins as
|
yuuji@0
|
1072 anonymous as well as the ANONYMOUS SASL authenticator.
|
yuuji@0
|
1073 Anonymous users have access to mailboxes in the #news., #ftp/,
|
yuuji@0
|
1074 and #public/ namespaces only.
|
yuuji@0
|
1075 _________________________________________________________________
|
yuuji@0
|
1076
|
yuuji@0
|
1077 4.2 How do I set up an alert message that each IMAP user will see?
|
yuuji@0
|
1078
|
yuuji@0
|
1079 Create the file /etc/imapd.alert with the text of the message.
|
yuuji@0
|
1080 This text should be kept to one line if possible. Note that
|
yuuji@0
|
1081 this will cause an alert to every IMAP user every time they
|
yuuji@0
|
1082 initiate an IMAP session, so it should only be used for
|
yuuji@0
|
1083 critical messages.
|
yuuji@0
|
1084 _________________________________________________________________
|
yuuji@0
|
1085
|
yuuji@0
|
1086 4.3 How does the c-client library choose which of its several
|
yuuji@0
|
1087 mechanisms to use to establish an IMAP connection to the server? I
|
yuuji@0
|
1088 noticed that it can connect on port 143, port 993, via rsh, and via
|
yuuji@0
|
1089 ssh.
|
yuuji@0
|
1090
|
yuuji@0
|
1091 c-client chooses how to establish an IMAP connection via the
|
yuuji@0
|
1092 following rules:
|
yuuji@0
|
1093
|
yuuji@0
|
1094 + If /ssl is specified, use an SSL connection. Fail otherwise.
|
yuuji@0
|
1095 + Else if client is a UNIX system and "ssh server exec
|
yuuji@0
|
1096 /etc/rimapd" works, use that
|
yuuji@0
|
1097 + Else if /tryssl is specified and an SSL connection works, use
|
yuuji@0
|
1098 that.
|
yuuji@0
|
1099 + Else if client is a UNIX system and "rsh server exec
|
yuuji@0
|
1100 /etc/rimapd" works, use that.
|
yuuji@0
|
1101 + Else use a non-SSL connection.
|
yuuji@0
|
1102 _________________________________________________________________
|
yuuji@0
|
1103
|
yuuji@0
|
1104 4.4 I am using a TLS-capable IMAP server, so I don't need to use /ssl
|
yuuji@0
|
1105 to get encryption. However, I want to be certain that my session is
|
yuuji@0
|
1106 TLS encrypted before I send my password. How to I do this?
|
yuuji@0
|
1107
|
yuuji@0
|
1108 Use the /tls option in the mailbox name. This will cause an
|
yuuji@0
|
1109 error message and the connection to fail if the server does not
|
yuuji@0
|
1110 negotiate STARTTLS.
|
yuuji@0
|
1111 _________________________________________________________________
|
yuuji@0
|
1112
|
yuuji@0
|
1113 4.5 How do I use one of the alternative formats described in the
|
yuuji@0
|
1114 formats.txt document? In particular, I hear that mbx format will give
|
yuuji@0
|
1115 me better performance and allow shared access.
|
yuuji@0
|
1116
|
yuuji@0
|
1117 The rumors about mbx format being preferred are true. It is
|
yuuji@0
|
1118 faster than the traditional UNIX mailbox format and permits
|
yuuji@0
|
1119 shared access.
|
yuuji@0
|
1120
|
yuuji@0
|
1121 However, and this is very important, note that using an
|
yuuji@0
|
1122 alternative mailbox format is an advanced facility, and only
|
yuuji@0
|
1123 expert users should undertake it. If you don't understand any
|
yuuji@0
|
1124 of the following notes, you may not be enough of an expert yet,
|
yuuji@0
|
1125 and are probably better off not going this route until you are
|
yuuji@0
|
1126 more comfortable with your understanding.
|
yuuji@0
|
1127
|
yuuji@0
|
1128 Some of the formats, including mbx, are only supported by the
|
yuuji@0
|
1129 software based on the c-client library, and are not recognized
|
yuuji@0
|
1130 by other mailbox programs. The "vi" editor will corrupt any mbx
|
yuuji@0
|
1131 format mailbox that it encounters.
|
yuuji@0
|
1132
|
yuuji@0
|
1133 Another problem is that the certain formats, including mbx, use
|
yuuji@0
|
1134 advanced file access and locking techniques that do not work
|
yuuji@0
|
1135 reliably with NFS. NFS is not a real filesystem. Use IMAP
|
yuuji@0
|
1136 instead of NFS for distributed access.
|
yuuji@0
|
1137
|
yuuji@0
|
1138 Each of the following steps are in escalating order of
|
yuuji@0
|
1139 involvement. The further you go down this list, the more deeply
|
yuuji@0
|
1140 committed you become:
|
yuuji@0
|
1141
|
yuuji@0
|
1142 + The simplest way to create a mbx-format mailbox is to prefix
|
yuuji@0
|
1143 the name with "#driver.mbx/" when creating a mailbox through
|
yuuji@0
|
1144 c-client. For example, if you create "#driver.mbx/foo", the
|
yuuji@0
|
1145 mailbox "foo" will be created in mbx format. Only use
|
yuuji@0
|
1146 "#driver.mbx/" when creating the mailbox. At all other times,
|
yuuji@0
|
1147 just use the name ("foo" in this example); the software will
|
yuuji@0
|
1148 automatically select the driver for mbx whenever that mailbox
|
yuuji@0
|
1149 is accessed without you doing anything else.
|
yuuji@0
|
1150 + You can use the "mailutil copy" command to copy an existing
|
yuuji@0
|
1151 mailbox to a new mailbox in mbx format. Read the man page
|
yuuji@0
|
1152 provided with the mailutil program for details.
|
yuuji@0
|
1153 + If you create an mbx-format INBOX, by creating
|
yuuji@0
|
1154 "#driver.mbx/INBOX" (note that "INBOX" must be all
|
yuuji@0
|
1155 uppercase), then subsequent access to INBOX by any c-client
|
yuuji@0
|
1156 based application will use the mbx-format INBOX. Any mail
|
yuuji@0
|
1157 delivered to the traditional format mailbox in the spool
|
yuuji@0
|
1158 directory (e.g. /var/spool/mail/$USER) will automatically be
|
yuuji@0
|
1159 copied into the mbx-format INBOX and the spool directory copy
|
yuuji@0
|
1160 removed.
|
yuuji@0
|
1161 + You can cause any newly-created mailboxes to be in mbx-format
|
yuuji@0
|
1162 by default by changing the definition of
|
yuuji@0
|
1163 CREATEPROTO=unixproto to be CREATEPROTO=mbxproto in
|
yuuji@0
|
1164 src/osdep/unix/Makefile, then rebuilding the IMAP toolkit (do
|
yuuji@0
|
1165 a "make clean" first). Do not change EMPTYPROTO, since mbx
|
yuuji@0
|
1166 format mailboxes are never a zero-byte file. If you use Pine
|
yuuji@0
|
1167 or the imap-utils, you should probably also rebuild them with
|
yuuji@0
|
1168 the new IMAP toolkit too.
|
yuuji@0
|
1169 + You can deliver directly to the mbx-format INBOX by use of
|
yuuji@0
|
1170 the tmail or dmail programs. tmail is for direct invocation
|
yuuji@0
|
1171 from sendmail (or whatever MTA program you use); dmail is for
|
yuuji@0
|
1172 calls from procmail. Both of these programs have man pages
|
yuuji@0
|
1173 which must be read carefully before making this change.
|
yuuji@0
|
1174
|
yuuji@0
|
1175 Most other servers (e.g. Cyrus) require use of a non-standard
|
yuuji@0
|
1176 format. A full-fledged format conversion is not significantly
|
yuuji@0
|
1177 different from what you have to do with other servers. The
|
yuuji@0
|
1178 difference, which makes format conversion procedures somewhat
|
yuuji@0
|
1179 more complicated with this server, is that there is no "all or
|
yuuji@0
|
1180 nothing" requirement with this server. There are many points in
|
yuuji@0
|
1181 between. A format conversion can be anything from a single
|
yuuji@0
|
1182 mailbox or single user, to systemwide.
|
yuuji@0
|
1183
|
yuuji@0
|
1184 This is good in that you can decide how far to go, or do the
|
yuuji@0
|
1185 steps incrementally as you become more comfortable with the
|
yuuji@0
|
1186 result. On the other hand, there's no "One True Way" which can
|
yuuji@0
|
1187 be boiled down to a simple set of pedagogical instructions.
|
yuuji@0
|
1188
|
yuuji@0
|
1189 A number of sites have done full-fledged format conversions,
|
yuuji@0
|
1190 and are reportedly quite happy with the results. Feel free to
|
yuuji@0
|
1191 ask in the comp.mail.imap newsgroup or the imap-uw mailing
|
yuuji@0
|
1192 list for advice or help.
|
yuuji@0
|
1193 _________________________________________________________________
|
yuuji@0
|
1194
|
yuuji@0
|
1195 4.6 How do I set up shared mailboxes?
|
yuuji@0
|
1196
|
yuuji@0
|
1197 At the simplest level, a shared mailbox is one which has UNIX
|
yuuji@0
|
1198 file and directory protections which permit multiple users to
|
yuuji@0
|
1199 access it. What this means is that your existing skills and
|
yuuji@0
|
1200 tools to create and manage shared files on your UNIX system
|
yuuji@0
|
1201 apply to shared mailboxes; e.g.
|
yuuji@0
|
1202
|
yuuji@0
|
1203 chmod 666 mailbox
|
yuuji@0
|
1204
|
yuuji@0
|
1205 You may want to consider the use of a mailbox format which
|
yuuji@0
|
1206 permits multiple simultaneous read/write sessions, such as the
|
yuuji@0
|
1207 mbx format. The traditional UNIX format only allows one
|
yuuji@0
|
1208 read/write session to a mailbox at a time.
|
yuuji@0
|
1209
|
yuuji@0
|
1210 An additional convenience item are three system directories,
|
yuuji@0
|
1211 which can be set up for shared namespaces. These are: #ftp,
|
yuuji@0
|
1212 #shared, and #public, and are defined by creating the
|
yuuji@0
|
1213 associated UNIX users and home directories as described below.
|
yuuji@0
|
1214
|
yuuji@0
|
1215 #ftp/ refers to the anonymous ftp filesystem exported by the
|
yuuji@0
|
1216 ftp server, and is equivalent to the home directory for UNIX
|
yuuji@0
|
1217 user "ftp". For example, #ftp/foo/bar refers to the file
|
yuuji@0
|
1218 /foo/bar in the anonymous FTP filesystem, or ~ftp/foo/bar for
|
yuuji@0
|
1219 normal users. Anonymous FTP files are available to anonymous
|
yuuji@0
|
1220 IMAP logins. By default, newly-created files in #ftp/ are
|
yuuji@0
|
1221 protected 644.
|
yuuji@0
|
1222
|
yuuji@0
|
1223 #public/ refers to an IMAP toolkit convention called "public"
|
yuuji@0
|
1224 files, and is equivalent to the home directory for UNIX user
|
yuuji@0
|
1225 "imappublic". For example, #public/foo/bar refers to the file
|
yuuji@0
|
1226 ~imappublic/foo/bar. Public files are available to anonymous
|
yuuji@0
|
1227 IMAP logins. By default, newly-created files in #public are
|
yuuji@0
|
1228 created with protection 0666.
|
yuuji@0
|
1229
|
yuuji@0
|
1230 #shared/ refers to an IMAP toolkit convention called "shared"
|
yuuji@0
|
1231 files, and is equivalent to the home directory for UNIX user
|
yuuji@0
|
1232 "imapshared". For example, #shared/foo/bar refers to the file
|
yuuji@0
|
1233 ~imapshared/foo/bar. Shared files are not available to
|
yuuji@0
|
1234 anonymous IMAP logins. By default, newly-created files in
|
yuuji@0
|
1235 #shared are created with protection 0660.
|
yuuji@0
|
1236 _________________________________________________________________
|
yuuji@0
|
1237
|
yuuji@0
|
1238 4.7 How can I make the server syslogs go to someplace other than the
|
yuuji@0
|
1239 mail syslog?
|
yuuji@0
|
1240
|
yuuji@0
|
1241 The openlog() call that sets the syslog facility is in
|
yuuji@0
|
1242 src/osdep/unix/env_unix.c in routine server_init(). You need to
|
yuuji@0
|
1243 edit this file to change the syslog facility from LOG_MAIL to
|
yuuji@0
|
1244 the facility you want, then rebuild. You also need to set up
|
yuuji@0
|
1245 your /etc/syslog.conf properly.
|
yuuji@0
|
1246
|
yuuji@0
|
1247 Refer to the man pages for syslog and syslogd for more
|
yuuji@0
|
1248 information on what the available syslog facilities are and how
|
yuuji@0
|
1249 to configure syslogs. If you still don't understand what to do,
|
yuuji@0
|
1250 find a UNIX system expert.
|
yuuji@0
|
1251 _________________________________________________________________
|
yuuji@0
|
1252
|
yuuji@0
|
1253 5. Security Questions
|
yuuji@0
|
1254 _________________________________________________________________
|
yuuji@0
|
1255
|
yuuji@0
|
1256 5.1 I see that the IMAP server allows access to arbitary files on the
|
yuuji@0
|
1257 system, including /etc/passwd! How do I disable this?
|
yuuji@0
|
1258
|
yuuji@0
|
1259 You should not worry about this if your IMAP users are allowed
|
yuuji@0
|
1260 shell access. The IMAP server does not permit any access that
|
yuuji@0
|
1261 the user can not have via the shell.
|
yuuji@0
|
1262
|
yuuji@0
|
1263 If, and only if, you deny your IMAP users shell access, you may
|
yuuji@0
|
1264 want to consider one of three choices. Note that these choices
|
yuuji@0
|
1265 reduce IMAP functionality, and may have undesirable side
|
yuuji@0
|
1266 effects. Each of these choices involves an edit to file
|
yuuji@0
|
1267 src/osdep/unix/env_unix.c
|
yuuji@0
|
1268
|
yuuji@0
|
1269 The first (and recommended) choice is to set restrictBox as
|
yuuji@0
|
1270 described in file CONFIG. This will disable access to the
|
yuuji@0
|
1271 filesystem root, to other users' home directory, and to
|
yuuji@0
|
1272 superior directory.
|
yuuji@0
|
1273
|
yuuji@0
|
1274 The second (and strongly NOT recommended) choice is to set
|
yuuji@0
|
1275 closedBox as described in file CONFIG. This puts each IMAP
|
yuuji@0
|
1276 session into a so-called "chroot jail", and thus setting this
|
yuuji@0
|
1277 option is extremely dangerous; it can make your system much
|
yuuji@0
|
1278 less secure and open to root compromise attacks. So do not use
|
yuuji@0
|
1279 this option unless you are absolutely certain that you
|
yuuji@0
|
1280 understand all the issues of a "chroot jail."
|
yuuji@0
|
1281
|
yuuji@0
|
1282 The third choice is to rewrite routine mailboxfile() to
|
yuuji@0
|
1283 implement whatever mapping from mailbox name to filesystem name
|
yuuji@0
|
1284 (and restrictions) that you wish. This is the most general
|
yuuji@0
|
1285 choice. As a guide, you can see at the start of routine
|
yuuji@0
|
1286 mailboxfile() what the restrictBox choice does.
|
yuuji@0
|
1287 _________________________________________________________________
|
yuuji@0
|
1288
|
yuuji@0
|
1289 5.2 I've heard that IMAP servers are insecure. Is this true?
|
yuuji@0
|
1290
|
yuuji@0
|
1291 There are no known security problems in this version of the
|
yuuji@0
|
1292 IMAP toolkit, including the IMAP and POP servers. The IMAP and
|
yuuji@0
|
1293 POP servers limit what can be done while not logged in, and as
|
yuuji@0
|
1294 part of the login process discard all privileges except those
|
yuuji@0
|
1295 of the user.
|
yuuji@0
|
1296
|
yuuji@0
|
1297 As with other software packages, there have been buffer
|
yuuji@0
|
1298 overflow vulnerabilities in past versions. All known problems
|
yuuji@0
|
1299 of this nature are fixed in this version.
|
yuuji@0
|
1300
|
yuuji@0
|
1301 There is every reason to believe that the bad guys are engaged
|
yuuji@0
|
1302 in an ongoing effort to find vulnerabilities in the IMAP
|
yuuji@0
|
1303 toolkit. We look for such problems, and when one is found we
|
yuuji@0
|
1304 fix it.
|
yuuji@0
|
1305
|
yuuji@0
|
1306 It's unfortunate that any vulnerabilities existed in past
|
yuuji@0
|
1307 versions, and we're doing my best to keep the IMAP toolkit free
|
yuuji@0
|
1308 of vulnerabilities. No new vulnerabilities have been discovered
|
yuuji@0
|
1309 in quite a while, but efforts will not be relaxed.
|
yuuji@0
|
1310
|
yuuji@0
|
1311 Beware of vendors who claim that their implementations can not
|
yuuji@0
|
1312 have vulnerabilities.
|
yuuji@0
|
1313 _________________________________________________________________
|
yuuji@0
|
1314
|
yuuji@0
|
1315 5.3 How do I know that I have the most secure version of the server?
|
yuuji@0
|
1316
|
yuuji@0
|
1317 The best way is to keep your server software up to date. The
|
yuuji@0
|
1318 bad guys are always looking for ways to crack software, and
|
yuuji@0
|
1319 when they find one, let all their friends know.
|
yuuji@0
|
1320
|
yuuji@0
|
1321 Oldtimers used to refer to a concept of software rot: if your
|
yuuji@0
|
1322 software hasn't been updated in a while, it would "rot" -- tend
|
yuuji@0
|
1323 to acquire problems that it didn't have when it was new.
|
yuuji@0
|
1324
|
yuuji@0
|
1325 The latest release version of the IMAP toolkit is always
|
yuuji@0
|
1326 available at ftp://ftp.cac.washington.edu/mail/imap.tar.Z
|
yuuji@0
|
1327 _________________________________________________________________
|
yuuji@0
|
1328
|
yuuji@0
|
1329 5.4 I see all these strcpy() and sprintf() calls, those are unsafe,
|
yuuji@0
|
1330 aren't they?
|
yuuji@0
|
1331
|
yuuji@0
|
1332 Yes and no.
|
yuuji@0
|
1333
|
yuuji@0
|
1334 It can be unsafe to do these calls if you do not know that the
|
yuuji@0
|
1335 string being written will fit in the buffer. However, they are
|
yuuji@0
|
1336 perfectly safe if you do know that.
|
yuuji@0
|
1337
|
yuuji@0
|
1338 Beware of programmers who advocate doing a brute-force change
|
yuuji@0
|
1339 of all instances of
|
yuuji@0
|
1340
|
yuuji@0
|
1341 strcpy (s,t);
|
yuuji@0
|
1342
|
yuuji@0
|
1343 to
|
yuuji@0
|
1344
|
yuuji@0
|
1345 strncpy (s,t,n)[n] = '\0';
|
yuuji@0
|
1346
|
yuuji@0
|
1347 and similar measures in the name of "fixing all possible buffer
|
yuuji@0
|
1348 overflows."
|
yuuji@0
|
1349
|
yuuji@0
|
1350 There are examples in which a security bug was introduced
|
yuuji@0
|
1351 because of this type of "fix", due to the programmer using the
|
yuuji@0
|
1352 wrong value for n. In one case, the programmer thought that n
|
yuuji@0
|
1353 was larger than it actually was, causing a NUL to be written
|
yuuji@0
|
1354 out of the buffer; in another, n was too small, and a security
|
yuuji@0
|
1355 credential was truncated.
|
yuuji@0
|
1356
|
yuuji@0
|
1357 What is particularly ironic was that in both cases, the
|
yuuji@0
|
1358 original strcpy() was safe, because the size of the source
|
yuuji@0
|
1359 string was known to be safe.
|
yuuji@0
|
1360
|
yuuji@0
|
1361 With all this in mind, the software has been inspected, and it
|
yuuji@0
|
1362 is believed that all places where buffer overflows can happen
|
yuuji@0
|
1363 have been fixed. The strcpy()s that are still are in the code
|
yuuji@0
|
1364 occur after a size check was done in some other way.
|
yuuji@0
|
1365
|
yuuji@0
|
1366 Note that the common C idiom of
|
yuuji@0
|
1367
|
yuuji@0
|
1368 *s++ = c;
|
yuuji@0
|
1369
|
yuuji@0
|
1370 is just as vulnerable to buffer overflows. You can't cure
|
yuuji@0
|
1371 buffer overflows by outlawing certain functions, nor is it
|
yuuji@0
|
1372 desirable to do so; sometimes operations like strcpy()
|
yuuji@0
|
1373 translate into fast machine instructions for better
|
yuuji@0
|
1374 performance.
|
yuuji@0
|
1375
|
yuuji@0
|
1376 Nothing replaces careful study of code. That's how the bad guys
|
yuuji@0
|
1377 find bugs. Security is not accomplished by means of brute-force
|
yuuji@0
|
1378 shortcuts.
|
yuuji@0
|
1379 _________________________________________________________________
|
yuuji@0
|
1380
|
yuuji@0
|
1381 5.5 Those /tmp lock files are protected 666, is that really right?
|
yuuji@0
|
1382
|
yuuji@0
|
1383 Yes. Shared mailboxes won't work otherwise. Also, you get into
|
yuuji@0
|
1384 accidental denial of service problems with old lock files left
|
yuuji@0
|
1385 lying around; this happens fairly frequently.
|
yuuji@0
|
1386
|
yuuji@0
|
1387 The deliberate mischief that can be caused by fiddling with the
|
yuuji@0
|
1388 lock files is small-scale; harassment level at most. There are
|
yuuji@0
|
1389 many -- and much more effective -- other ways of harassing
|
yuuji@0
|
1390 another user on UNIX. It's usually not difficult to determine
|
yuuji@0
|
1391 the culprit.
|
yuuji@0
|
1392
|
yuuji@0
|
1393 Before worrying about deliberate mischief, worry first about
|
yuuji@0
|
1394 things happening by accident!
|
yuuji@0
|
1395 _________________________________________________________________
|
yuuji@0
|
1396
|
yuuji@0
|
1397 6. Why Did You Do This Strange Thing? Questions
|
yuuji@0
|
1398 _________________________________________________________________
|
yuuji@0
|
1399
|
yuuji@0
|
1400 6.1 Why don't you use GNU autoconfig / automake / autoblurdybloop?
|
yuuji@0
|
1401
|
yuuji@0
|
1402 Autoconfig et al are not available on all the platforms where
|
yuuji@0
|
1403 the IMAP toolkit is supported; and do not work correctly on
|
yuuji@0
|
1404 some of the platforms where they do exist. Furthermore, these
|
yuuji@0
|
1405 programs add another layer of complexity to an already complex
|
yuuji@0
|
1406 process.
|
yuuji@0
|
1407
|
yuuji@0
|
1408 Coaxing software that uses autoconfig to build properly on
|
yuuji@0
|
1409 platforms which were not specifically considered by that
|
yuuji@0
|
1410 software wastes an inordinate amount of time. When (not if)
|
yuuji@0
|
1411 autoconfig fails to do the right thing, the result is an
|
yuuji@0
|
1412 inpenetrable morass to untangle in order to find the problem
|
yuuji@0
|
1413 and fix it.
|
yuuji@0
|
1414
|
yuuji@0
|
1415 The concept behind autoconfig is good, but the execution is
|
yuuji@0
|
1416 flawed. It rarely does the right thing on a platform that
|
yuuji@0
|
1417 wasn't specifically considered. Human life is too short to
|
yuuji@0
|
1418 debug autoconfig problems, especially since the current
|
yuuji@0
|
1419 mechanism is so much easier.
|
yuuji@0
|
1420 _________________________________________________________________
|
yuuji@0
|
1421
|
yuuji@0
|
1422 6.2 Why do you insist upon a build with -g? Doesn't it waste disk and
|
yuuji@0
|
1423 memory space?
|
yuuji@0
|
1424
|
yuuji@0
|
1425 From time to time a submitted port has snuck in without -g.
|
yuuji@0
|
1426 This has always ended up causing problems. There are only two
|
yuuji@0
|
1427 valid excuses for not using -g in a port:
|
yuuji@0
|
1428
|
yuuji@0
|
1429 + The compiler does not support -g
|
yuuji@0
|
1430 + An alternate form of -g is needed with optimization, e.g.
|
yuuji@0
|
1431 -g3.
|
yuuji@0
|
1432
|
yuuji@0
|
1433 There will be no new ports added without -g (or a suitable
|
yuuji@0
|
1434 alternative) being set.
|
yuuji@0
|
1435
|
yuuji@0
|
1436 -g has not been arbitrarily added to the ports which do not
|
yuuji@0
|
1437 currently have it because we don't know if doing so would break
|
yuuji@0
|
1438 the build. However, any support issues with one of those port
|
yuuji@0
|
1439 will lead to the correct -g setting being determined and
|
yuuji@0
|
1440 permanently added.
|
yuuji@0
|
1441
|
yuuji@0
|
1442 Processors are fast enough (and disk space is cheap enough)
|
yuuji@0
|
1443 that -g should be automatic in all compilers with no way of
|
yuuji@0
|
1444 turning it off, and /bin/strip should be a symlink to
|
yuuji@0
|
1445 /bin/true. Human life is too short to deal with binaries built
|
yuuji@0
|
1446 without -g. Such binaries should be a bad memory of the days of
|
yuuji@0
|
1447 KIPS processors and disks that costs several dollars per
|
yuuji@0
|
1448 kilobyte.
|
yuuji@0
|
1449 _________________________________________________________________
|
yuuji@0
|
1450
|
yuuji@0
|
1451 6.3 Why don't you make c-client a shared library?
|
yuuji@0
|
1452
|
yuuji@0
|
1453 All too often, shared libraries create far more problems than
|
yuuji@0
|
1454 they solve.
|
yuuji@0
|
1455
|
yuuji@0
|
1456 Remember that you only gain the benefit of a shared library
|
yuuji@0
|
1457 when there are multiple applications which use that shared
|
yuuji@0
|
1458 library. Even without shared libraries, on most modern
|
yuuji@0
|
1459 operating systems (and many ancient ones too!) applications
|
yuuji@0
|
1460 will share their text segments between across multiple
|
yuuji@0
|
1461 processes running the same application. This means that if your
|
yuuji@0
|
1462 system only runs one application (e.g. imapd) that uses the
|
yuuji@0
|
1463 c-client library, then you gain no benefit from making c-client
|
yuuji@0
|
1464 a shared library even if it has 100 imapd processes. You will,
|
yuuji@0
|
1465 however suffer added complexity.
|
yuuji@0
|
1466
|
yuuji@0
|
1467 If you have a server system that just runs imapd and ipop3d,
|
yuuji@0
|
1468 then making c-client a shared library will save just one copy
|
yuuji@0
|
1469 of c-client no matter how many IMAP/POP3 processes are running.
|
yuuji@0
|
1470
|
yuuji@0
|
1471 The problem with shared libraries is that you have to keep
|
yuuji@0
|
1472 around a copy of the library every time something changes in
|
yuuji@0
|
1473 the library that would affect the interface the library
|
yuuji@0
|
1474 presents to the application. So, you end up having many copies
|
yuuji@0
|
1475 of the same shared library.
|
yuuji@0
|
1476
|
yuuji@0
|
1477 If you don't keep multiple copies of the shared library, then
|
yuuji@0
|
1478 one of two things happens. If there was proper versioning, then
|
yuuji@0
|
1479 you'll get a message such as "cannot open shared object file"
|
yuuji@0
|
1480 or "minor versions don't match" and the application won't run.
|
yuuji@0
|
1481 Otherwise, the application will run, but will fail in
|
yuuji@0
|
1482 mysterious ways.
|
yuuji@0
|
1483
|
yuuji@0
|
1484 Several sites and third-party distributors have modified the
|
yuuji@0
|
1485 c-client makefile in order to make c-client be a shared
|
yuuji@0
|
1486 library. When (not if) a c-client based application fails in
|
yuuji@0
|
1487 mysterious ways because of a library compatibility problem, the
|
yuuji@0
|
1488 result is a bug report. A lot of time and effort ends up
|
yuuji@0
|
1489 getting wasted investigating such bug reports.
|
yuuji@0
|
1490
|
yuuji@0
|
1491 Memory is so cheap these days that it's not worth it. Human
|
yuuji@0
|
1492 life is too short to deal with shared library compatibility
|
yuuji@0
|
1493 problems.
|
yuuji@0
|
1494 _________________________________________________________________
|
yuuji@0
|
1495
|
yuuji@0
|
1496 6.4 Why don't you use iconv() for internationalization support?
|
yuuji@0
|
1497
|
yuuji@0
|
1498 iconv() is not ubiquitous enough.
|
yuuji@0
|
1499 _________________________________________________________________
|
yuuji@0
|
1500
|
yuuji@0
|
1501 6.5 Why is the IMAP server connected to the home directory by default?
|
yuuji@0
|
1502
|
yuuji@0
|
1503 The IMAP server has no way of knowing what you might call
|
yuuji@0
|
1504 "mail" as opposed to "some other file"; in fact, you can use
|
yuuji@0
|
1505 IMAP to access any file.
|
yuuji@0
|
1506
|
yuuji@0
|
1507 The IMAP server also doesn't know whether your preferred
|
yuuji@0
|
1508 subdirectory for mailbox files is "mail/", ".mail/", "Mail/",
|
yuuji@0
|
1509 "Mailboxes/", or any of a zillion other possibilities. If one
|
yuuji@0
|
1510 such name were chosen, it would undoubtably anger the partisans
|
yuuji@0
|
1511 of all the other names.
|
yuuji@0
|
1512
|
yuuji@0
|
1513 It is possible to modify the software so that the default
|
yuuji@0
|
1514 connected directory is someplace else. Please read the file
|
yuuji@0
|
1515 CONFIG for discussion of this and other issues.
|
yuuji@0
|
1516 _________________________________________________________________
|
yuuji@0
|
1517
|
yuuji@0
|
1518 6.6 I have a Windows system. Why isn't the server plug and play for
|
yuuji@0
|
1519 me?
|
yuuji@0
|
1520
|
yuuji@0
|
1521 There is no standard for how mail is stored on Windows; nor a
|
yuuji@0
|
1522 single standard SMTP server. The closest to either would be the
|
yuuji@0
|
1523 SMTP server in Microsoft's IIS.
|
yuuji@0
|
1524
|
yuuji@0
|
1525 So there's no default by which to make assumptions. As the
|
yuuji@0
|
1526 software is set up, it assumes that the each user has an
|
yuuji@0
|
1527 Windows login account and private home directory, and that mail
|
yuuji@0
|
1528 is stored on that home directory as files in one of the popular
|
yuuji@0
|
1529 UNIX formats. It also assumes that there is some tool
|
yuuji@0
|
1530 equivalent to inetd on UNIX that does the TCP/IP listening and
|
yuuji@0
|
1531 server startup.
|
yuuji@0
|
1532
|
yuuji@0
|
1533 Basically, unless you're an email software hacker, you probably
|
yuuji@0
|
1534 want to look elsewhere if you want IMAP/POP servers for
|
yuuji@0
|
1535 Windows.
|
yuuji@0
|
1536 _________________________________________________________________
|
yuuji@0
|
1537
|
yuuji@0
|
1538 6.7 I looked at the UNIX SSL code and saw that you have the SSL data
|
yuuji@0
|
1539 payload size set to 8192 bytes. SSL allows 16K; why aren't you using
|
yuuji@0
|
1540 the full size?
|
yuuji@0
|
1541
|
yuuji@0
|
1542 This is to avoid an interoperability problem with:
|
yuuji@0
|
1543
|
yuuji@0
|
1544 + PC IMAP clients that use Microsoft's SChannel.DLL (SSPI) for
|
yuuji@0
|
1545 SSL support
|
yuuji@0
|
1546 + Microsoft Exchange server (which also uses SChannel).
|
yuuji@0
|
1547
|
yuuji@0
|
1548 SChannel has a bug that makes it think that the maximum SSL
|
yuuji@0
|
1549 data payload size is 16379 bytes -- 5 bytes too small. Thus,
|
yuuji@0
|
1550 c-client has to make sure that it never transmits full sized
|
yuuji@0
|
1551 SSL packets.
|
yuuji@0
|
1552
|
yuuji@0
|
1553 The reason for using 8K (as opposed to, say, 16379 bytes, or
|
yuuji@0
|
1554 15K, or...) is that it corresponds with the TCP buffer size
|
yuuji@0
|
1555 that the software uses elsewhere for input; there's a slight
|
yuuji@0
|
1556 performance benefit to having the two sizes correspond or at
|
yuuji@0
|
1557 least be a multiple of each other. Also, it keeps the size as a
|
yuuji@0
|
1558 power of two, which might be significant on some platforms.
|
yuuji@0
|
1559
|
yuuji@0
|
1560 There wasn't a significant difference that we could measure
|
yuuji@0
|
1561 between 8K and 15K.
|
yuuji@0
|
1562
|
yuuji@0
|
1563 Microsoft has developed a hotfix for this bug. Look up MSKB
|
yuuji@0
|
1564 article number 300562. Contrary to the article text which
|
yuuji@0
|
1565 implies that this is a Pine issue, this bug also affects
|
yuuji@0
|
1566 Microsoft Exchange server with any client that transmits
|
yuuji@0
|
1567 full-sized SSL payloads.
|
yuuji@0
|
1568 _________________________________________________________________
|
yuuji@0
|
1569
|
yuuji@0
|
1570 6.8 Why is an mh format INBOX called #mhinbox instead of just INBOX?
|
yuuji@0
|
1571
|
yuuji@0
|
1572 It's a long story. In brief, the mh format driver is less
|
yuuji@0
|
1573 functional than any of the other drivers. It turned out that
|
yuuji@0
|
1574 there were some users (including high-level administrators) who
|
yuuji@0
|
1575 tried mh years ago and no longer use it, but still had an mh
|
yuuji@0
|
1576 profile left behind.
|
yuuji@0
|
1577
|
yuuji@0
|
1578 When the mh driver used INBOX, it would see the mh profile, and
|
yuuji@0
|
1579 proceed to move the user's INBOX into the mh format INBOX. This
|
yuuji@0
|
1580 caused considerable confusion as some things stopped working.
|
yuuji@0
|
1581 _________________________________________________________________
|
yuuji@0
|
1582
|
yuuji@0
|
1583 6.9 Why don't you support the maildir format?
|
yuuji@0
|
1584
|
yuuji@0
|
1585 It is technically difficult to support maildir in IMAP while
|
yuuji@0
|
1586 maintaining acceptable performance, robustness, following the
|
yuuji@0
|
1587 requirements of the IMAP protocol specification, and following
|
yuuji@0
|
1588 the requirements of maildir.
|
yuuji@0
|
1589
|
yuuji@0
|
1590 No one has succeeded in accomplishing all four together. The
|
yuuji@0
|
1591 various maildir drivers offered as patches all have these
|
yuuji@0
|
1592 problems. The problem is exacerbated because this
|
yuuji@0
|
1593 implementation supports multiple formats; consequently this
|
yuuji@0
|
1594 implementation can't make any performance shortcuts by assuming
|
yuuji@0
|
1595 that all the world is maildir.
|
yuuji@0
|
1596
|
yuuji@0
|
1597 We can't do a better job than the maildir fan community has
|
yuuji@0
|
1598 done with their maildir drivers. Similarly, if the maildir fan
|
yuuji@0
|
1599 community provides the maildir driver, they take on the
|
yuuji@0
|
1600 responsibility for answering maildir-specific support
|
yuuji@0
|
1601 questions. This is as it should be, and that is why maildir
|
yuuji@0
|
1602 support is left to the maildir fan community.
|
yuuji@0
|
1603 _________________________________________________________________
|
yuuji@0
|
1604
|
yuuji@0
|
1605 6.10 Why don't you support the Cyrus format?
|
yuuji@0
|
1606
|
yuuji@0
|
1607 There's no point to doing so. An implementation which supports
|
yuuji@0
|
1608 multiple formats will never do as well as one which is
|
yuuji@0
|
1609 optimized to support one single format.
|
yuuji@0
|
1610
|
yuuji@0
|
1611 If you want to use Cyrus mailbox format, you should use the
|
yuuji@0
|
1612 Cyrus server, which is the native implementation of that format
|
yuuji@0
|
1613 and is specifically optimized for that format. That's also why
|
yuuji@0
|
1614 Cyrus doesn't implement any other format.
|
yuuji@0
|
1615 _________________________________________________________________
|
yuuji@0
|
1616
|
yuuji@0
|
1617 6.11 Why is it creating extra forks on my SVR4 system?
|
yuuji@0
|
1618
|
yuuji@0
|
1619 This is because your system only has fcntl() style locking and
|
yuuji@0
|
1620 not flock() style locking. fcntl() locking has a design flaw
|
yuuji@0
|
1621 that causes a close() to release any locks made by that process
|
yuuji@0
|
1622 on the file opened on that file descriptor, even if the lock
|
yuuji@0
|
1623 was made on a different file descriptor.
|
yuuji@0
|
1624
|
yuuji@0
|
1625 This design flaw causes unexpected loss of lock, and consequent
|
yuuji@0
|
1626 mailbox corruption. The workaround is to do certain "dangerous
|
yuuji@0
|
1627 operations" in another fork, thus avoiding doing a close() in
|
yuuji@0
|
1628 the vulnerable fork.
|
yuuji@0
|
1629
|
yuuji@0
|
1630 The best way to solve this problem is to upgrade your SVR4
|
yuuji@0
|
1631 (Solaris, AIX, HP-UX, SGI) or OSF/1 system to a more advanced
|
yuuji@0
|
1632 operating system, such as Linux or BSD. These more advanced
|
yuuji@0
|
1633 operating systems have fcntl() locking for compatibility with
|
yuuji@0
|
1634 SVR4, but also have flock() locking.
|
yuuji@0
|
1635
|
yuuji@0
|
1636 Beware of certain SVR4 systems, such as AIX, which have an
|
yuuji@0
|
1637 "flock()" function in their C library that is just a jacket
|
yuuji@0
|
1638 that does an fcntl() lock. This is not a true flock(), and has
|
yuuji@0
|
1639 the same design flaw as fcntl().
|
yuuji@0
|
1640 _________________________________________________________________
|
yuuji@0
|
1641
|
yuuji@0
|
1642 6.12 Why are you so fussy about the date/time format in the internal
|
yuuji@0
|
1643 "From " line in traditional UNIX mailbox files? My other mail program
|
yuuji@0
|
1644 just considers every line that starts with "From " to be the start of
|
yuuji@0
|
1645 the message.
|
yuuji@0
|
1646
|
yuuji@0
|
1647 You just answered your own question. If any line that starts
|
yuuji@0
|
1648 with "From " is treated as the start of a message, then every
|
yuuji@0
|
1649 message text line which starts with "From " has to be quoted
|
yuuji@0
|
1650 (typically by prefixing a ">" character). People complain about
|
yuuji@0
|
1651 this -- "why did a > get stuck in my message?"
|
yuuji@0
|
1652
|
yuuji@0
|
1653 So, good mail reading software only considers a line to be a
|
yuuji@0
|
1654 "From " line if it follows the actual specification for a
|
yuuji@0
|
1655 "From " line. This means, among other things, that the day of
|
yuuji@0
|
1656 week is fixed-format: "May 14", but "May 7" (note the extra
|
yuuji@0
|
1657 space) as opposed to "May 7". ctime() format for the date is
|
yuuji@0
|
1658 the most common, although POSIX also allows a numeric timezone
|
yuuji@0
|
1659 after the year. For compatibility with ancient software, the
|
yuuji@0
|
1660 seconds are optional, the timezone may appear before the year,
|
yuuji@0
|
1661 the old 3-letter timezones are also permitted, and "remote from
|
yuuji@0
|
1662 xxx" may appear after the whole thing.
|
yuuji@0
|
1663
|
yuuji@0
|
1664 Unfortunately, some software written by novices use other
|
yuuji@0
|
1665 formats. The most common error is to have a variable-width day
|
yuuji@0
|
1666 of month, perhaps in the erroneous belief that RFC 2822 (or RFC
|
yuuji@0
|
1667 822) defines the format of the date/time in the "From " line
|
yuuji@0
|
1668 (it doesn't; no RFC describes internal formats). I've seen a
|
yuuji@0
|
1669 few other goofs, such as a single-digit second, but these are
|
yuuji@0
|
1670 less common.
|
yuuji@0
|
1671
|
yuuji@0
|
1672 If you are writing your own software that writes mailbox files,
|
yuuji@0
|
1673 and you really aren't all that savvy with all the ins and outs
|
yuuji@0
|
1674 and ancient history, you should seriously consider using the
|
yuuji@0
|
1675 c-client library (e.g. routine mail_append()) instead of doing
|
yuuji@0
|
1676 the file writes yourself. If you must do it yourself, use
|
yuuji@0
|
1677 ctime(), as in:
|
yuuji@0
|
1678
|
yuuji@0
|
1679 fprintf (mbx,"From %s@%h %s",user,host,ctime (time (0)));
|
yuuji@0
|
1680
|
yuuji@0
|
1681 rather than try to figure out a good format yourself. ctime()
|
yuuji@0
|
1682 is the most traditional format and nobody will flame you for
|
yuuji@0
|
1683 using it.
|
yuuji@0
|
1684 _________________________________________________________________
|
yuuji@0
|
1685
|
yuuji@0
|
1686 6.13 Why is traditional UNIX format the default format?
|
yuuji@0
|
1687
|
yuuji@0
|
1688 Compatibility with the past 30 or so years of UNIX history.
|
yuuji@0
|
1689 This server is the only one that completely interoperates with
|
yuuji@0
|
1690 legacy UNIX mail tools.
|
yuuji@0
|
1691 _________________________________________________________________
|
yuuji@0
|
1692
|
yuuji@0
|
1693 6.14 Why do you write this "DON'T DELETE THIS MESSAGE -- FOLDER
|
yuuji@0
|
1694 INTERNAL DATA" message at the start of traditional UNIX and MMDF
|
yuuji@0
|
1695 format mailboxes?
|
yuuji@0
|
1696
|
yuuji@0
|
1697 This pseudo-message serves two purposes.
|
yuuji@0
|
1698
|
yuuji@0
|
1699 First, it establishes the mailbox format even when the mailbox
|
yuuji@0
|
1700 has no messages. Otherwise, a mailbox with no messages is a
|
yuuji@0
|
1701 zero-byte file, which could be one of several formats.
|
yuuji@0
|
1702
|
yuuji@0
|
1703 Second, it holds mailbox metadata used by IMAP: the UID
|
yuuji@0
|
1704 validity, the last assigned UID, and mailbox keywords. Without
|
yuuji@0
|
1705 this metadata, which must be preserved even when the mailbox
|
yuuji@0
|
1706 has no messages, the traditional UNIX format wouldn't be able
|
yuuji@0
|
1707 to support the full capabilities of IMAP.
|
yuuji@0
|
1708 _________________________________________________________________
|
yuuji@0
|
1709
|
yuuji@0
|
1710 6.15 Why don't you stash the mailbox metadata in the first real
|
yuuji@0
|
1711 message of the mailbox instead of writing this fake FOLDER INTERNAL
|
yuuji@0
|
1712 DATA message?
|
yuuji@0
|
1713
|
yuuji@0
|
1714 In fact, that is what is done if the mailbox is non-empty and
|
yuuji@0
|
1715 does not already have a FOLDER INTERNAL DATA message.
|
yuuji@0
|
1716
|
yuuji@0
|
1717 One problem with doing that is that if some external program
|
yuuji@0
|
1718 removes the first message, the metadata is lost and must be
|
yuuji@0
|
1719 recreated, thus losing any prior UID or keyword list status
|
yuuji@0
|
1720 that IMAP clients may depend upon.
|
yuuji@0
|
1721
|
yuuji@0
|
1722 Another problem is that this doesn't help if the last message
|
yuuji@0
|
1723 is deleted. This will result in an empty mailbox, and the
|
yuuji@0
|
1724 necessity to create a FOLDER INTERNAL DATA message.
|
yuuji@0
|
1725 _________________________________________________________________
|
yuuji@0
|
1726
|
yuuji@0
|
1727 6.16 Why aren't "dual-use" mailboxes the default?
|
yuuji@0
|
1728
|
yuuji@0
|
1729 Compatibility with the past 30 or so years of UNIX history, not
|
yuuji@0
|
1730 to mention compatibility with user expectations when using
|
yuuji@0
|
1731 shell tools.
|
yuuji@0
|
1732 _________________________________________________________________
|
yuuji@0
|
1733
|
yuuji@0
|
1734 6.17 Why do you use ucbcc to build on Solaris?
|
yuuji@0
|
1735
|
yuuji@0
|
1736 It is a long, long story about why cc is set to ucbcc. You need
|
yuuji@0
|
1737 to invoke the C compiler so that it links with the SVR4
|
yuuji@0
|
1738 libraries and not the BSD libraries, otherwise readdir() will
|
yuuji@0
|
1739 return the wrong information.
|
yuuji@0
|
1740
|
yuuji@0
|
1741 Of all the names in the most common path, ucbcc is the only
|
yuuji@0
|
1742 name to be found (on /usr/ccs/bin) that points to a suitable
|
yuuji@0
|
1743 compiler. cc is likely to be /usr/ucb/cc which is absolutely
|
yuuji@0
|
1744 not the compiler that you want. The real SVR4 cc is probably
|
yuuji@0
|
1745 something like /opt/SUNWspro/bin/cc which is rarely in anyone's
|
yuuji@0
|
1746 path by default.
|
yuuji@0
|
1747
|
yuuji@0
|
1748 ucbcc is probably a link to acc, e.g.
|
yuuji@0
|
1749 /opt/SUNWspro/SC4.0/bin/acc, and is the UCB C compiler using
|
yuuji@0
|
1750 the SVR4 libraries.
|
yuuji@0
|
1751
|
yuuji@0
|
1752 If ucbcc isn't on your system, then punt on the SUN C compiler
|
yuuji@0
|
1753 and use gcc instead (the gso port instead of the sol port).
|
yuuji@0
|
1754
|
yuuji@0
|
1755 If, in spite of all the above warnings, you choose to change
|
yuuji@0
|
1756 "ucbcc" to "cc", you will probably find that the -O2 needs to
|
yuuji@0
|
1757 be changed to -O. If you don't get any error messages with -O2,
|
yuuji@0
|
1758 that's a pretty good indicator that you goofed and are running
|
yuuji@0
|
1759 the compiler that will link with the BSD libraries.
|
yuuji@0
|
1760
|
yuuji@0
|
1761 To recap:
|
yuuji@0
|
1762
|
yuuji@0
|
1763 + The sol port is designed to be built using the UCB compiler
|
yuuji@0
|
1764 using the SVR4 libraries. This compiler is "ucbcc", which is
|
yuuji@0
|
1765 lunk to acc. You use -O2 as one of the CFLAGS.
|
yuuji@0
|
1766 + If you build the sol port with the UCB compiler using the BSD
|
yuuji@0
|
1767 libraries, you will get no error messages but you will get
|
yuuji@0
|
1768 bad binaries (the most obvious symptom is dropping the first
|
yuuji@0
|
1769 two characters return filenames from the imapd LIST command.
|
yuuji@0
|
1770 This compiler also uses -O2, and is very often what the user
|
yuuji@0
|
1771 gets from "cc". BEWARE
|
yuuji@0
|
1772 + If you build the sol port with the real SVR4 compiler, which
|
yuuji@0
|
1773 is often hidden away or unavailable on many systems, then you
|
yuuji@0
|
1774 will get errors from -O2 and you need to change that to -O.
|
yuuji@0
|
1775 But you will get a good binary. However, you should try it
|
yuuji@0
|
1776 with -O2 first, to make sure that you got this compiler and
|
yuuji@0
|
1777 not the UCB compiler using BSD libraries.
|
yuuji@0
|
1778 _________________________________________________________________
|
yuuji@0
|
1779
|
yuuji@0
|
1780 6.18 Why should I care about some old system with BSD libraries? cc is
|
yuuji@0
|
1781 the right thing on my Solaris system!
|
yuuji@0
|
1782
|
yuuji@0
|
1783 Because there still are sites that use such systems. On those
|
yuuji@0
|
1784 systems, the assumption that "cc" does the right thing will
|
yuuji@0
|
1785 lead to corrupt binaries with no error message or other warning
|
yuuji@0
|
1786 that anything is amiss.
|
yuuji@0
|
1787
|
yuuji@0
|
1788 Too many sites have fallen victim to this problem.
|
yuuji@0
|
1789 _________________________________________________________________
|
yuuji@0
|
1790
|
yuuji@0
|
1791 6.19 Why do you insist upon writing .lock files in the spool
|
yuuji@0
|
1792 directory?
|
yuuji@0
|
1793
|
yuuji@0
|
1794 Compatibility with the past 30 years of UNIX software which
|
yuuji@0
|
1795 deals with the spool directory, especially software which
|
yuuji@0
|
1796 delivers mail. Otherwise, it is possible to lose mail.
|
yuuji@0
|
1797 _________________________________________________________________
|
yuuji@0
|
1798
|
yuuji@0
|
1799 6.20 Why should I care about compatibility with the past?
|
yuuji@0
|
1800
|
yuuji@0
|
1801 This is one of those questions in which the answer never
|
yuuji@0
|
1802 convinces those who ask it. Somehow, everybody who ever asks
|
yuuji@0
|
1803 this question ends up answering it for themselves as they get
|
yuuji@0
|
1804 older, with the very answer that they rejected years earlier.
|
yuuji@0
|
1805 _________________________________________________________________
|
yuuji@0
|
1806
|
yuuji@0
|
1807 7. Problems and Annoyances
|
yuuji@0
|
1808 _________________________________________________________________
|
yuuji@0
|
1809
|
yuuji@0
|
1810 7.1 Help! My INBOX is empty! What happened to my messages?
|
yuuji@0
|
1811
|
yuuji@0
|
1812 If you are seeing "0 messages" when you open INBOX and you know
|
yuuji@0
|
1813 you have messages there (and perhaps have looked at your mail
|
yuuji@0
|
1814 spool file and see that messages are there), then probably
|
yuuji@0
|
1815 there is something wrong with the very first line of your mail
|
yuuji@0
|
1816 spool file. Make sure that the first five bytes of the file are
|
yuuji@0
|
1817 "From ", followed by an email address and a date/time in
|
yuuji@0
|
1818 ctime() format, e.g.:
|
yuuji@0
|
1819
|
yuuji@0
|
1820 From fred@foo.bar Mon May 7 20:54:30 2001
|
yuuji@0
|
1821 _________________________________________________________________
|
yuuji@0
|
1822
|
yuuji@0
|
1823 7.2 Help! All my messages in a non-INBOX mailbox have been
|
yuuji@0
|
1824 concatenated into one message which claims to be from me and has a
|
yuuji@0
|
1825 subject of the file name of the mailbox! What's going on?
|
yuuji@0
|
1826
|
yuuji@0
|
1827 Something wrong with the very first line of the mailbox. Make
|
yuuji@0
|
1828 sure that the first five bytes of the file are "From ",
|
yuuji@0
|
1829 followed by an email address and a date/time in ctime() format,
|
yuuji@0
|
1830 e.g.:
|
yuuji@0
|
1831
|
yuuji@0
|
1832 From fred@foo.bar Mon May 7 20:54:30 2001
|
yuuji@0
|
1833 _________________________________________________________________
|
yuuji@0
|
1834
|
yuuji@0
|
1835 7.3 Why do I get the message: CREATE failed: Can't create mailbox node
|
yuuji@0
|
1836 xxxxxxxxx: File exists and how do I fix it?
|
yuuji@0
|
1837
|
yuuji@0
|
1838 See the answer to the Are hierarchical mailboxes supported?
|
yuuji@0
|
1839 question.
|
yuuji@0
|
1840 _________________________________________________________________
|
yuuji@0
|
1841
|
yuuji@0
|
1842 7.4 Why can't I log in to the server? The user name and password are
|
yuuji@0
|
1843 right!
|
yuuji@0
|
1844
|
yuuji@0
|
1845 There are a myriad number of possible answers to this question.
|
yuuji@0
|
1846 The only way to say for sure what is wrong is run the server
|
yuuji@0
|
1847 under a debugger such as gdb while root (yes, you must be root)
|
yuuji@0
|
1848 with a breakpoint at routines checkpw() and loginpw(), then
|
yuuji@0
|
1849 single-step until you see which test rejected you. The server
|
yuuji@0
|
1850 isn't going to give any error messages other than "login
|
yuuji@0
|
1851 failed" in the name of not giving out any unnecessary
|
yuuji@0
|
1852 information to unauthorized individuals.
|
yuuji@0
|
1853
|
yuuji@0
|
1854 Here are some of the more common reasons why login may fail:
|
yuuji@0
|
1855
|
yuuji@0
|
1856 + You didn't really give the correct user name and/or password.
|
yuuji@0
|
1857 + Your client doesn't send the LOGIN command correctly; for
|
yuuji@0
|
1858 example, IMAP2 clients won't send a password containing a "*"
|
yuuji@0
|
1859 correctly to an IMAP4 server.
|
yuuji@0
|
1860 + If you have set up a CRAM-MD5 database, remember that the
|
yuuji@0
|
1861 password used is the one in the CRAM-MD5 database, and
|
yuuji@0
|
1862 furthermore that there must also be an entry in /etc/passwd
|
yuuji@0
|
1863 (but the /etc/passwd password is not used).
|
yuuji@0
|
1864 + If you are using PAM, have you created a service file for the
|
yuuji@0
|
1865 server in /etc/pam.d?
|
yuuji@0
|
1866 + If you are using shadow passwords, have you used an
|
yuuji@0
|
1867 appropriate port when building? In particular, note that
|
yuuji@0
|
1868 "lnx" is for Linux systems without shadow passwords; you
|
yuuji@0
|
1869 probably want "slx" or "lnp" instead.
|
yuuji@0
|
1870 + If your system has account or password expirations, check to
|
yuuji@0
|
1871 see that the expiration date hasn't passed.
|
yuuji@0
|
1872 + You can't log in as root or any other UID 0 user. This is for
|
yuuji@0
|
1873 your own safety, not to mention the fact that the servers use
|
yuuji@0
|
1874 UID 0 as meaning "not logged in".
|
yuuji@0
|
1875 _________________________________________________________________
|
yuuji@0
|
1876
|
yuuji@0
|
1877 7.5 Help! My load average is soaring and I see hundreds of POP and
|
yuuji@0
|
1878 IMAP servers, many logged in as the same user!
|
yuuji@0
|
1879
|
yuuji@0
|
1880 Certain inferior losing GUI mail reading programs have a
|
yuuji@0
|
1881 "synchronize all mailboxes at startup" (IMAP) or "check for new
|
yuuji@0
|
1882 mail every second" (POP) feature which causes a rapid and
|
yuuji@0
|
1883 unchecked spawning of servers.
|
yuuji@0
|
1884
|
yuuji@0
|
1885 This is not a problem in the server; the client is really
|
yuuji@0
|
1886 asking for all those server sessions. Unfortunately, there
|
yuuji@0
|
1887 isn't much that the POP and IMAP servers can do about it; they
|
yuuji@0
|
1888 don't spawned themselves.
|
yuuji@0
|
1889
|
yuuji@0
|
1890 Some sites have added code to record the number of server
|
yuuji@0
|
1891 sessions spawned per user per hour, and disable login for a
|
yuuji@0
|
1892 user who has exceeded a predetermined rate. This doesn't stop
|
yuuji@0
|
1893 the servers from being spawned; it just means that a server
|
yuuji@0
|
1894 session will commit suicide a bit faster.
|
yuuji@0
|
1895
|
yuuji@0
|
1896 Another possibility is to detect excessive server spawning
|
yuuji@0
|
1897 activity at the level where the server is spawned, which would
|
yuuji@0
|
1898 be inetd or possibly tcpd. The problem here is that this is a
|
yuuji@0
|
1899 hard time to quantify. 50 sessions in a minute from a
|
yuuji@0
|
1900 multi-user timesharing system may be perfectly alright, whereas
|
yuuji@0
|
1901 10 sessions a minute from a PC may be too much.
|
yuuji@0
|
1902
|
yuuji@0
|
1903 The real solution is to fix the client configuration, by
|
yuuji@0
|
1904 disabling those evil features. Also tell the vendors of those
|
yuuji@0
|
1905 clients how you feel about distributing denial-of-service
|
yuuji@0
|
1906 attack tools in the guise of mail reading programs.
|
yuuji@0
|
1907 _________________________________________________________________
|
yuuji@0
|
1908
|
yuuji@0
|
1909 7.6 Why does mail disappear even though I set "keep mail on server"?
|
yuuji@0
|
1910 7.7 Why do I get the message Moved ##### bytes of new mail to
|
yuuji@0
|
1911 /home/user/mbox from /var/spool/mail/user and why did this happen?
|
yuuji@0
|
1912
|
yuuji@0
|
1913 This is probably caused by the mbox driver. If the file "mbox"
|
yuuji@0
|
1914 exists on the user's home directory and is in UNIX mailbox
|
yuuji@0
|
1915 format, then when INBOX is opened this file will be selected as
|
yuuji@0
|
1916 INBOX instead of the mail spool file. Messages will be
|
yuuji@0
|
1917 automatically transferred from the mail spool file into the
|
yuuji@0
|
1918 mbox file.
|
yuuji@0
|
1919
|
yuuji@0
|
1920 To disable this behavior, delete "mbox" from the EXTRADRIVERS
|
yuuji@0
|
1921 list in the top-level Makefile and rebuild. Note that if you do
|
yuuji@0
|
1922 this, users won't be able to access the messages that have
|
yuuji@0
|
1923 already been moved to mbox unless they open mbox instead of
|
yuuji@0
|
1924 INBOX.
|
yuuji@0
|
1925 _________________________________________________________________
|
yuuji@0
|
1926
|
yuuji@0
|
1927 7.8 Why isn't it showing the local host name as a fully-qualified
|
yuuji@0
|
1928 domain name?
|
yuuji@0
|
1929 7.9 Why is the local host name in the From/Sender/Message-ID headers
|
yuuji@0
|
1930 of outgoing mail not coming out as a fully-qualified domain name?
|
yuuji@0
|
1931
|
yuuji@0
|
1932 Your UNIX system is misconfigured. The entry for your system in
|
yuuji@0
|
1933 /etc/hosts must have the fully-qualified domain name first,
|
yuuji@0
|
1934 e.g.
|
yuuji@0
|
1935
|
yuuji@0
|
1936 105.69.1.234 myserver.example.com myserver
|
yuuji@0
|
1937
|
yuuji@0
|
1938 A common mistake of novice system administrators is to have the
|
yuuji@0
|
1939 short name first, e.g.
|
yuuji@0
|
1940
|
yuuji@0
|
1941 105.69.1.234 myserver myserver.example.com
|
yuuji@0
|
1942
|
yuuji@0
|
1943 or to omit the fully qualified domain name entirely, e.g.
|
yuuji@0
|
1944
|
yuuji@0
|
1945 105.69.1.234 myserver
|
yuuji@0
|
1946
|
yuuji@0
|
1947 The result of this is that when the IMAP toolkit does a
|
yuuji@0
|
1948 gethostbyname() call to get the fully-qualified domain name, it
|
yuuji@0
|
1949 would get "myserver" instead of "myserver.example.com".
|
yuuji@0
|
1950
|
yuuji@0
|
1951 On some systems, a configuration file (typically named
|
yuuji@0
|
1952 /etc/svc.conf, /etc/netsvc.conf, or /etc/nsswitch.conf) can be
|
yuuji@0
|
1953 used to configure the system to use the domain name system
|
yuuji@0
|
1954 (DNS) instead of /etc/hosts, so it doesn't matter if /etc/hosts
|
yuuji@0
|
1955 is misconfigured.
|
yuuji@0
|
1956
|
yuuji@0
|
1957 Check the man pages for gethostbyname, hosts, svc, and/or
|
yuuji@0
|
1958 netsvc for more information.
|
yuuji@0
|
1959
|
yuuji@0
|
1960 Unfortunately, certain vendors, most notably SUN, have failed
|
yuuji@0
|
1961 to make this clear in their documentation. Most of SUN's
|
yuuji@0
|
1962 documentation assumes a corporate network that is not connected
|
yuuji@0
|
1963 to the Internet.
|
yuuji@0
|
1964
|
yuuji@0
|
1965 net.folklore once (late 1980s) held that the proper procedure
|
yuuji@0
|
1966 was to append the results of getdomainname() to the name
|
yuuji@0
|
1967 returned by gethostname(), and some versions of sendmail
|
yuuji@0
|
1968 configuration files were distributed that did this. This was
|
yuuji@0
|
1969 incorrect; the string returned from getdomainname() is the
|
yuuji@0
|
1970 Yellow Pages (a.k.a NIS) domain name, which is a completely
|
yuuji@0
|
1971 different (albeit unfortunately named) entity from an Internet
|
yuuji@0
|
1972 domain. These were often fortuitously the same string, except
|
yuuji@0
|
1973 when they weren't. Frequently, this would result in host names
|
yuuji@0
|
1974 with spuriously doubled domain names, e.g.
|
yuuji@0
|
1975
|
yuuji@0
|
1976 myserver.example.com.example.com
|
yuuji@0
|
1977
|
yuuji@0
|
1978 This practice has been thoroughly discredited for many years,
|
yuuji@0
|
1979 but folklore dies hard.
|
yuuji@0
|
1980 _________________________________________________________________
|
yuuji@0
|
1981
|
yuuji@0
|
1982 7.10 What does the message: Mailbox vulnerable - directory
|
yuuji@0
|
1983 /var/spool/mail must have 1777 protection mean? How can I fix this?
|
yuuji@0
|
1984
|
yuuji@0
|
1985 In order to update a mailbox in the default UNIX format, it is
|
yuuji@0
|
1986 necessary to create a lock file to prevent the mailer from
|
yuuji@0
|
1987 delivering mail while an update is in progress. Some systems
|
yuuji@0
|
1988 use a directory protection of 775, requiring that all mail
|
yuuji@0
|
1989 handling programs be setgid mail; or of 755, requiring that all
|
yuuji@0
|
1990 mail handling programs be setuid root.
|
yuuji@0
|
1991
|
yuuji@0
|
1992 The IMAP toolkit does not run with any special privileges, and
|
yuuji@0
|
1993 I plan to keep it that way. It is antithetical to the concept
|
yuuji@0
|
1994 of a toolkit if users can't write their own programs to use it.
|
yuuji@0
|
1995 Also, I've had enough bad experiences with security bugs while
|
yuuji@0
|
1996 running privileged; the IMAP and POP servers have to be root
|
yuuji@0
|
1997 when not logged in, in order to be able to log themselves in. I
|
yuuji@0
|
1998 don't want to go any deeper down that slippery slope.
|
yuuji@0
|
1999
|
yuuji@0
|
2000 Directory protection 1777 is secure enough on most well-managed
|
yuuji@0
|
2001 systems. If you can't trust your users with a 1777 mail spool
|
yuuji@0
|
2002 (petty harassment is about the limit of the abuse exposure),
|
yuuji@0
|
2003 then you have much worse problems then that.
|
yuuji@0
|
2004
|
yuuji@0
|
2005 If you absolutely insist upon requiring privileges to create a
|
yuuji@0
|
2006 lock file, external file locking can be done via a setgid mail
|
yuuji@0
|
2007 program named /etc/mlock (this is defined by LOCKPGM in the
|
yuuji@0
|
2008 c-client Makefile). If the toolkit is unable to create a
|
yuuji@0
|
2009 <...mailbox...>.lock file in the directory by itself, it will
|
yuuji@0
|
2010 try to call mlock to do it. I do not recommend doing this for
|
yuuji@0
|
2011 performance reasons.
|
yuuji@0
|
2012
|
yuuji@0
|
2013 A sample mlock program is included as part of imap-2007. We
|
yuuji@0
|
2014 have tried to make this sample program secure, but it has not
|
yuuji@0
|
2015 been thoroughly audited.
|
yuuji@0
|
2016 _________________________________________________________________
|
yuuji@0
|
2017
|
yuuji@0
|
2018 7.11 What does the message: Mailbox is open by another process, access
|
yuuji@0
|
2019 is readonly mean? How do I fix this?
|
yuuji@0
|
2020
|
yuuji@0
|
2021 A problem occurred in applying a lock to a /tmp lock file.
|
yuuji@0
|
2022 Either some other program has the mailbox open and won't
|
yuuji@0
|
2023 relenquish it, or something is wrong with the protection of
|
yuuji@0
|
2024 /tmp or the lock.
|
yuuji@0
|
2025
|
yuuji@0
|
2026 Make sure that the /tmp directory is protected 1777. Some
|
yuuji@0
|
2027 security scripts incorrectly set the protection of the /tmp
|
yuuji@0
|
2028 directory to 775, which disables /tmp for all non-privileged
|
yuuji@0
|
2029 programs.
|
yuuji@0
|
2030 _________________________________________________________________
|
yuuji@0
|
2031
|
yuuji@0
|
2032 7.12 What does the message: Can't get write access to mailbox, access
|
yuuji@0
|
2033 is readonly mean?
|
yuuji@0
|
2034
|
yuuji@0
|
2035 The mailbox file is write-protected against you.
|
yuuji@0
|
2036 _________________________________________________________________
|
yuuji@0
|
2037
|
yuuji@0
|
2038 7.13 I set my POP3 client to "delete messages from server" but they
|
yuuji@0
|
2039 never get deleted. What is wrong?
|
yuuji@0
|
2040
|
yuuji@0
|
2041 Make sure that your mailbox is not read-only: that the mailbox
|
yuuji@0
|
2042 is owned by you and write enabled (protection 0600), and that
|
yuuji@0
|
2043 the /tmp directory is longer world-writeable. /tmp must be
|
yuuji@0
|
2044 world-writeable because lots of applications use it for scratch
|
yuuji@0
|
2045 space. To fix this, do
|
yuuji@0
|
2046
|
yuuji@0
|
2047
|
yuuji@0
|
2048 chmod 1777 /tmp
|
yuuji@0
|
2049
|
yuuji@0
|
2050 as root.
|
yuuji@0
|
2051
|
yuuji@0
|
2052 Make sure that your POP3 client issues a QUIT command when it
|
yuuji@0
|
2053 finishes. The POP3 protocol specifies that deletions are
|
yuuji@0
|
2054 discarded unless a proper QUIT is done.
|
yuuji@0
|
2055
|
yuuji@0
|
2056 Make sure that you are not opening multiple POP3 sessions to
|
yuuji@0
|
2057 the same mailbox. It is a requirement of the POP3 protocol than
|
yuuji@0
|
2058 only one POP3 session be in effect to a mailbox at a time,
|
yuuji@0
|
2059 however some, poorly-written POP3 clients violate this. Also,
|
yuuji@0
|
2060 some background "check for new mail" tasks also cause a
|
yuuji@0
|
2061 violation. See the answer to the What does the syslog message:
|
yuuji@0
|
2062 Killed (lost mailbox lock) user=... host=... mean? question for
|
yuuji@0
|
2063 more details.
|
yuuji@0
|
2064 _________________________________________________________________
|
yuuji@0
|
2065
|
yuuji@0
|
2066 7.14 What do messages such as:
|
yuuji@0
|
2067 Message ... UID ... already has UID ...
|
yuuji@0
|
2068 Message ... UID ... less than ...
|
yuuji@0
|
2069 Message ... UID ... greater than last ...
|
yuuji@0
|
2070 Invalid UID ... in message ..., rebuilding UIDs
|
yuuji@0
|
2071
|
yuuji@0
|
2072 mean?
|
yuuji@0
|
2073
|
yuuji@0
|
2074 Something happened to corrupt the unique identifier regime in
|
yuuji@0
|
2075 the mailbox. In traditional UNIX-format mailboxes, this can
|
yuuji@0
|
2076 happen if the user deleted the "DO NOT DELETE" internal
|
yuuji@0
|
2077 message.
|
yuuji@0
|
2078
|
yuuji@0
|
2079 This problem is relatively harmless; a new valid unique
|
yuuji@0
|
2080 identifier regime will be created. The main effect is that any
|
yuuji@0
|
2081 references to the old UIDs will no longer be useful.
|
yuuji@0
|
2082
|
yuuji@0
|
2083 So, unless it is a chronic problem or you feel like debugging,
|
yuuji@0
|
2084 you can safely ignore these messages.
|
yuuji@0
|
2085 _________________________________________________________________
|
yuuji@0
|
2086
|
yuuji@0
|
2087 7.15 What do the error messages:
|
yuuji@0
|
2088 Unable to read internal header at ...
|
yuuji@0
|
2089 Unable to find CRLF at ...
|
yuuji@0
|
2090 Unable to parse internal header at ...
|
yuuji@0
|
2091 Unable to parse message date at ...
|
yuuji@0
|
2092 Unable to parse message flags at ...
|
yuuji@0
|
2093 Unable to parse message UID at ...
|
yuuji@0
|
2094 Unable to parse message size at ...
|
yuuji@0
|
2095 Last message (at ... ) runs past end of file ...
|
yuuji@0
|
2096
|
yuuji@0
|
2097 mean? I am using mbx format.
|
yuuji@0
|
2098
|
yuuji@0
|
2099 The mbx-format mailbox is corrupted and needs to be repaired.
|
yuuji@0
|
2100
|
yuuji@0
|
2101 You should make an effort to find out why the corruption
|
yuuji@0
|
2102 happened. Was there an obvious system problem (crash or disk
|
yuuji@0
|
2103 failure)? Did the user accidentally access the file via NFS?
|
yuuji@0
|
2104 Mailboxes don't get corrupted by themselves; something caused
|
yuuji@0
|
2105 the problem.
|
yuuji@0
|
2106
|
yuuji@0
|
2107 Some people have developed automated scripts, but if you're
|
yuuji@0
|
2108 comfortable using emacs it's pretty easy to fix it manually. Do
|
yuuji@0
|
2109 not use vi or any other editor unless you are certain that
|
yuuji@0
|
2110 editor can handle binary!!!
|
yuuji@0
|
2111
|
yuuji@0
|
2112 If you are not comfortable with emacs, or if the file is too
|
yuuji@0
|
2113 large to read with emacs, see the "step-by-step" technique
|
yuuji@0
|
2114 later on for another way of doing it.
|
yuuji@0
|
2115
|
yuuji@0
|
2116 After the word "at" in the error message is the byte position
|
yuuji@0
|
2117 it got to when it got unhappy with the file, e.g. if you see:
|
yuuji@0
|
2118
|
yuuji@0
|
2119 Unable to parse internal header at 43921: ne bombastic blurdybloop
|
yuuji@0
|
2120
|
yuuji@0
|
2121 The problem occurs at the 43,931 byte in the file. That's the
|
yuuji@0
|
2122 point you need to fix. c-client is expecting an internal header
|
yuuji@0
|
2123 at that byte number, looking something like:
|
yuuji@0
|
2124
|
yuuji@0
|
2125 6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
|
yuuji@0
|
2126
|
yuuji@0
|
2127 The format of this internal line is:
|
yuuji@0
|
2128
|
yuuji@0
|
2129 dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
|
yuuji@0
|
2130
|
yuuji@0
|
2131 The only thing that is variable is the "ssss" field, it can be
|
yuuji@0
|
2132 as many digits as needed. All other fields (inluding the "dd")
|
yuuji@0
|
2133 are fixed width. So, the easiest thing to do is to look forward
|
yuuji@0
|
2134 in the file for the next internal header, and delete everything
|
yuuji@0
|
2135 from the error point to that internal header.
|
yuuji@0
|
2136
|
yuuji@0
|
2137 Here's what to do if you want to be smarter and do a little bit
|
yuuji@0
|
2138 more work. Generally, you're in the middle of a message, and
|
yuuji@0
|
2139 there's nothing wrong with that message. The problem happened
|
yuuji@0
|
2140 in the *previous* message. So, search back to the previous
|
yuuji@0
|
2141 internal header. Now, remember that "ssss" field? That's the
|
yuuji@0
|
2142 size of that message.
|
yuuji@0
|
2143
|
yuuji@0
|
2144 Mark where you are in the file, move the cursor to the line
|
yuuji@0
|
2145 after the internal header, and skip that many bytes ("ssss")
|
yuuji@0
|
2146 forward. If you're at the point of the error in the file, then
|
yuuji@0
|
2147 that message is corrupt. If you're at a different point, then
|
yuuji@0
|
2148 perhaps the previous message is corrupt and has a too long size
|
yuuji@0
|
2149 count that "ate" into this message.
|
yuuji@0
|
2150
|
yuuji@0
|
2151 Basically, what you need to do is make sure that all those size
|
yuuji@0
|
2152 counts are right, and that moving "ssss" bytes from the line
|
yuuji@0
|
2153 after the internal header will land you at another internal
|
yuuji@0
|
2154 header.
|
yuuji@0
|
2155
|
yuuji@0
|
2156 Usually, once you know what you're looking at, it's pretty easy
|
yuuji@0
|
2157 to work out the corruption, and the best remedial action.
|
yuuji@0
|
2158 Repair scripts will make the problem go away but may not always
|
yuuji@0
|
2159 do the smartest/best salvage of the user's data. Manual repair
|
yuuji@0
|
2160 is more flexible and usually preferable.
|
yuuji@0
|
2161
|
yuuji@0
|
2162 Here is a step-by-step technique for fixing corrupt mbx files
|
yuuji@0
|
2163 that's a bit cruder than the procedure outlined above, but
|
yuuji@0
|
2164 works for any size file.
|
yuuji@0
|
2165
|
yuuji@0
|
2166 In this example, suppose that the corrupt file is INBOX, the
|
yuuji@0
|
2167 error message is
|
yuuji@0
|
2168
|
yuuji@0
|
2169 Unable to find CRLF at 132551754
|
yuuji@0
|
2170
|
yuuji@0
|
2171 and the size of the INBOX file is 132867870 bytes.
|
yuuji@0
|
2172
|
yuuji@0
|
2173 The first step is to split the mailbox file at the point of the
|
yuuji@0
|
2174 error:
|
yuuji@0
|
2175
|
yuuji@0
|
2176 + Rename the INBOX file to some other name, such as INBOX.bad.
|
yuuji@0
|
2177 + Copy the first 132,551,754 bytes of INBOX.bad to another
|
yuuji@0
|
2178 file, such as INBOX.new.
|
yuuji@0
|
2179 + Extract the trailing 316,116 bytes (132867870-132551754) of
|
yuuji@0
|
2180 INBOX.bad into another file, such as INBOX.tail.
|
yuuji@0
|
2181 + You no longer need INBOX.bad. Delete it.
|
yuuji@0
|
2182
|
yuuji@0
|
2183 In other words, use the number from the "Unable to find CRLF
|
yuuji@0
|
2184 at" as the point to split INBOX into two new files, INBOX.new
|
yuuji@0
|
2185 and INBOX.tail.
|
yuuji@0
|
2186
|
yuuji@0
|
2187 Now, remove the erroneous data:
|
yuuji@0
|
2188
|
yuuji@0
|
2189 + Verify that you can open INBOX.new in IMAP or Pine.
|
yuuji@0
|
2190 + The last message of INBOX.new is probably corrupted. Copy it
|
yuuji@0
|
2191 to another file, such as badmsg.1, then delete and expunge
|
yuuji@0
|
2192 that last message from INBOX.new
|
yuuji@0
|
2193 + Locate the first occurance of text in INBOX.tail which looks
|
yuuji@0
|
2194 like an internal header, as described above.
|
yuuji@0
|
2195 + Remove all the text which occurs prior to that point, and
|
yuuji@0
|
2196 place it into another file, such as badmsg.2. Note that in
|
yuuji@0
|
2197 the case of a single digit date, there is a leading space
|
yuuji@0
|
2198 which must not be removed (e.g. " 6-Nov-2001" not
|
yuuji@0
|
2199 "6-Nov-2001").
|
yuuji@0
|
2200
|
yuuji@0
|
2201 Reassemble the mailbox:
|
yuuji@0
|
2202
|
yuuji@0
|
2203 + Append INBOX.tail to INBOX.new.
|
yuuji@0
|
2204 + You no longer need INBOX.tail. Delete it.
|
yuuji@0
|
2205 + Verify that you can open INBOX.new in IMAP or Pine.
|
yuuji@0
|
2206
|
yuuji@0
|
2207 Reinstall INBOX.new as INBOX:
|
yuuji@0
|
2208
|
yuuji@0
|
2209 + Check to see if you have received any new messages while
|
yuuji@0
|
2210 repairing INBOX.
|
yuuji@0
|
2211 + If you haven't received any new messages while repairing
|
yuuji@0
|
2212 INBOX, just rename INBOX.new to INBOX.
|
yuuji@0
|
2213 + If you have received new messages, be sure to copy the new
|
yuuji@0
|
2214 messages from INBOX to INBOX.new before doing the rename.
|
yuuji@0
|
2215
|
yuuji@0
|
2216 You now have a working INBOX, as well as two files with
|
yuuji@0
|
2217 corrupted data (badmsg.1 and badmsg.2). There may be some
|
yuuji@0
|
2218 useful data in the two badmsg files that you might want to try
|
yuuji@0
|
2219 salvaging; otherwise you can delete the two badmsg files.
|
yuuji@0
|
2220 _________________________________________________________________
|
yuuji@0
|
2221
|
yuuji@0
|
2222 7.16 What do the syslog messages:
|
yuuji@0
|
2223
|
yuuji@0
|
2224 imap/tcp server failing (looping)
|
yuuji@0
|
2225 pop3/tcp server failing (looping)
|
yuuji@0
|
2226
|
yuuji@0
|
2227 mean? When it happens, the listed service shuts down. How can I fix
|
yuuji@0
|
2228 this?
|
yuuji@0
|
2229
|
yuuji@0
|
2230 The error message "server failing (looping), service
|
yuuji@0
|
2231 terminated" is not from either the IMAP or POP servers.
|
yuuji@0
|
2232 Instead, it comes from inetd, the daemon which listens for TCP
|
yuuji@0
|
2233 connections to a number of servers, including the IMAP and POP
|
yuuji@0
|
2234 servers.
|
yuuji@0
|
2235
|
yuuji@0
|
2236 inetd has a limit of 40 new server sessions per minute for any
|
yuuji@0
|
2237 particular service. If more than 40 sessions are initiated in a
|
yuuji@0
|
2238 minute, inetd will issue the "failing (looping), service
|
yuuji@0
|
2239 terminated" message and shut down the service for 10 minutes.
|
yuuji@0
|
2240 inetd does this to prevent system resource consumption by a
|
yuuji@0
|
2241 client which is spawning infinite numbers of servers. It should
|
yuuji@0
|
2242 be noted that this is a denial of service; however for some
|
yuuji@0
|
2243 systems the alternative is a crash which would be a worse
|
yuuji@0
|
2244 denial of service!
|
yuuji@0
|
2245
|
yuuji@0
|
2246 For larger server systems, the limit of 40 is much too low. The
|
yuuji@0
|
2247 limit was established many years ago when a system typically
|
yuuji@0
|
2248 only ran a few dozen servers.
|
yuuji@0
|
2249
|
yuuji@0
|
2250 On some versions of inetd, such as the one distributed with
|
yuuji@0
|
2251 most versions of Linux, you can modify the /etc/inetd.conf file
|
yuuji@0
|
2252 to have a larger number of servers by appending a period
|
yuuji@0
|
2253 followed by a number after the nowait word for the server
|
yuuji@0
|
2254 entry. For example, if your existing /etc/inetd.conf line
|
yuuji@0
|
2255 reads:
|
yuuji@0
|
2256
|
yuuji@0
|
2257 imap stream tcp nowait root /usr/etc/imapd imapd
|
yuuji@0
|
2258
|
yuuji@0
|
2259 try changing it to be:
|
yuuji@0
|
2260
|
yuuji@0
|
2261 imap stream tcp nowait.100 root /usr/etc/imapd imapd
|
yuuji@0
|
2262
|
yuuji@0
|
2263 Another example (using TCP wrappers):
|
yuuji@0
|
2264
|
yuuji@0
|
2265 imap stream tcp nowait root /usr/sbin/tcpd imapd
|
yuuji@0
|
2266
|
yuuji@0
|
2267 try changing it to be:
|
yuuji@0
|
2268
|
yuuji@0
|
2269 imap stream tcp nowait.100 root /usr/sbin/tcpd imapd
|
yuuji@0
|
2270
|
yuuji@0
|
2271 to increase the limit to 100 sessions/minute.
|
yuuji@0
|
2272
|
yuuji@0
|
2273 Before making this change, please read the information in "man
|
yuuji@0
|
2274 inetd" to determine whether or not your inetd has this feature.
|
yuuji@0
|
2275 If it does not, and you make this change, the likely outcome is
|
yuuji@0
|
2276 that you will disable IMAP service entirely.
|
yuuji@0
|
2277
|
yuuji@0
|
2278 Another way to fix this problem is to edit the inetd.c source
|
yuuji@0
|
2279 code (provided by your UNIX system vendor) to set higher
|
yuuji@0
|
2280 limits, rebuild inetd, install the new binary, and reboot your
|
yuuji@0
|
2281 system. This should only be done by a UNIX system expert. In
|
yuuji@0
|
2282 the inetd.c source code, the limits TOOMANY (normally 40) is
|
yuuji@0
|
2283 the maximum number of new server sessions permitted per minute,
|
yuuji@0
|
2284 and RETRYTIME (normally 600) is the number of seconds inetd
|
yuuji@0
|
2285 will shut down the server after it exceeds TOOMANY.
|
yuuji@0
|
2286 _________________________________________________________________
|
yuuji@0
|
2287
|
yuuji@0
|
2288 7.17 What does the syslog message: Mailbox lock file /tmp/.600.1df3
|
yuuji@0
|
2289 open failure: Permission denied mean?
|
yuuji@0
|
2290
|
yuuji@0
|
2291 This usually means that some "helpful" security script person
|
yuuji@0
|
2292 has protected /tmp so that it is no longer world-writeable.
|
yuuji@0
|
2293 /tmp must be world-writeable because lots of applications use
|
yuuji@0
|
2294 it for scratch space. To fix this, do
|
yuuji@0
|
2295
|
yuuji@0
|
2296 chmod 1777 /tmp
|
yuuji@0
|
2297
|
yuuji@0
|
2298 as root.
|
yuuji@0
|
2299
|
yuuji@0
|
2300 If that isn't the answer, check the protection of the named
|
yuuji@0
|
2301 file. If it is something other than 666, then either someone is
|
yuuji@0
|
2302 hacking or some "helpful" person modified the code to have a
|
yuuji@0
|
2303 different default lock file protection.
|
yuuji@0
|
2304 _________________________________________________________________
|
yuuji@0
|
2305
|
yuuji@0
|
2306 7.18 What do the syslog messages:
|
yuuji@0
|
2307 Command stream end of file, while reading line user=... host=...
|
yuuji@0
|
2308 Command stream end of file, while reading char user=... host=...
|
yuuji@0
|
2309 Command stream end of file, while writing text user=... host=...
|
yuuji@0
|
2310
|
yuuji@0
|
2311 mean?
|
yuuji@0
|
2312
|
yuuji@0
|
2313 This message occurs when the session is disconnected without a
|
yuuji@0
|
2314 proper LOGOUT (IMAP) or QUIT (POP) command being received by
|
yuuji@0
|
2315 the server first.
|
yuuji@0
|
2316
|
yuuji@0
|
2317 In many cases, this is perfectly normal; many client
|
yuuji@0
|
2318 implementations are impolite and do this. Some programmers
|
yuuji@0
|
2319 think this sort of rudeness is "more efficient".
|
yuuji@0
|
2320
|
yuuji@0
|
2321 The condition could, however, indicate a client or network
|
yuuji@0
|
2322 connectivity problem. The server has no way of knowing whether
|
yuuji@0
|
2323 there's a problem or just a rude client, so it issues this
|
yuuji@0
|
2324 message instead of a Logout.
|
yuuji@0
|
2325
|
yuuji@0
|
2326 Certain inferior losing clients disconnect abruptly after a
|
yuuji@0
|
2327 failed login, and instead of saying that the login failed, just
|
yuuji@0
|
2328 say that they can't access the mailbox. They then complain to
|
yuuji@0
|
2329 the system manager, who looks in the syslog and finds this
|
yuuji@0
|
2330 message. Not very helpful, eh? See the answer to the Why can't
|
yuuji@0
|
2331 I log in to the server? The user name and password are right!
|
yuuji@0
|
2332 question.
|
yuuji@0
|
2333
|
yuuji@0
|
2334 If the user isn't reporting a problem, you can probably ignore
|
yuuji@0
|
2335 this message.
|
yuuji@0
|
2336 _________________________________________________________________
|
yuuji@0
|
2337
|
yuuji@0
|
2338 7.19 Why did my POP or IMAP session suddenly disconnect? The syslog
|
yuuji@0
|
2339 has the message: Killed (lost mailbox lock) user=... host=...
|
yuuji@0
|
2340
|
yuuji@0
|
2341 This message only happens when either the traditional UNIX
|
yuuji@0
|
2342 mailbox format or MMDF format is in use. This format only
|
yuuji@0
|
2343 allows one session to have the mailbox open read/write at a
|
yuuji@0
|
2344 time.
|
yuuji@0
|
2345
|
yuuji@0
|
2346 The servers assume that if a second session attempts to open
|
yuuji@0
|
2347 the mailbox, that means that the first session is probably
|
yuuji@0
|
2348 owned by an abandoned client. The common scenario here is a
|
yuuji@0
|
2349 user who leaves his client running at the office, and then
|
yuuji@0
|
2350 tries to read his mail from home. Through an internal mechanism
|
yuuji@0
|
2351 called kiss of death, the second session requests the first
|
yuuji@0
|
2352 session to kill itself. When the first session receives the
|
yuuji@0
|
2353 "kiss of death", it issues the "Killed (lost mailbox lock)"
|
yuuji@0
|
2354 syslog message and terminates. The second session then seizes
|
yuuji@0
|
2355 read/write access, and becomes the new "first" session.
|
yuuji@0
|
2356
|
yuuji@0
|
2357 Certain poorly-designed clients routinely open multiple
|
yuuji@0
|
2358 sessions to the same mailbox; the users of those clients tend
|
yuuji@0
|
2359 to get this message a lot.
|
yuuji@0
|
2360
|
yuuji@0
|
2361 Another cause of this message is a background "check for new
|
yuuji@0
|
2362 mail" task which does its work by opening a POP session to
|
yuuji@0
|
2363 server every few seconds. They do this because POP doesn't have
|
yuuji@0
|
2364 a way to announce new mail.
|
yuuji@0
|
2365
|
yuuji@0
|
2366 The solution to both situations is to replace the client with a
|
yuuji@0
|
2367 good online IMAP client such as Pine. Life is too short to
|
yuuji@0
|
2368 waste on POP clients and poorly-designed IMAP clients.
|
yuuji@0
|
2369 _________________________________________________________________
|
yuuji@0
|
2370
|
yuuji@0
|
2371 7.20 Why does my IMAP client show all the files on the system,
|
yuuji@0
|
2372 recursively from the UNIX root directory?
|
yuuji@0
|
2373 7.21 Why does my IMAP client show all of my files, recursively from my
|
yuuji@0
|
2374 UNIX home directory?
|
yuuji@0
|
2375
|
yuuji@0
|
2376 A well-written client should only show one level of hierarchy
|
yuuji@0
|
2377 and then stop, awaiting explicit user action before going
|
yuuji@0
|
2378 lower. However, some poorly-designed clients will recursively
|
yuuji@0
|
2379 list all files, which may be a very long list (especially if
|
yuuji@0
|
2380 you have symbolic links to directories that create a loop in
|
yuuji@0
|
2381 the filesystem graph!).
|
yuuji@0
|
2382
|
yuuji@0
|
2383 This behavior has also been observed in some third-party
|
yuuji@0
|
2384 c-client drivers, including maildir drivers. Consequently, this
|
yuuji@0
|
2385 problem has even been observed in Pine. It is important to
|
yuuji@0
|
2386 understand that this is not a problem in Pine or c-client; it
|
yuuji@0
|
2387 is a problem in the third-party driver. A Pine built without
|
yuuji@0
|
2388 that third-party driver will not have this problem.
|
yuuji@0
|
2389
|
yuuji@0
|
2390 See also the answer to Why does my IMAP client show all my
|
yuuji@0
|
2391 files in my home directory?
|
yuuji@0
|
2392 _________________________________________________________________
|
yuuji@0
|
2393
|
yuuji@0
|
2394 7.22 Why does my IMAP client show that I have mailboxes named
|
yuuji@0
|
2395 "#mhinbox", "#mh", "#shared", "#ftp", "#news", and "#public"?
|
yuuji@0
|
2396
|
yuuji@0
|
2397 These are IMAP namespace names. They represent other
|
yuuji@0
|
2398 hierarchies in which messages may exist. These hierarchies may
|
yuuji@0
|
2399 not necessarily exist on a server, but the namespace name is
|
yuuji@0
|
2400 still in the namespace list in order to mark it as reserved.
|
yuuji@0
|
2401
|
yuuji@0
|
2402 A few poorly-designed clients display all namespace names as if
|
yuuji@0
|
2403 they were top-level mailboxes in a user's list of mailboxes,
|
yuuji@0
|
2404 whether or not they actually exist. This is a flaw in those
|
yuuji@0
|
2405 clients.
|
yuuji@0
|
2406 _________________________________________________________________
|
yuuji@0
|
2407
|
yuuji@0
|
2408 7.23 Why does my IMAP client show all my files in my home directory?
|
yuuji@0
|
2409
|
yuuji@0
|
2410 As distributed, the IMAP server is connected to your home
|
yuuji@0
|
2411 directory by default. It has no way of knowing what you might
|
yuuji@0
|
2412 call "mail" as opposed to "some other file"; in fact, you can
|
yuuji@0
|
2413 use IMAP to access any file.
|
yuuji@0
|
2414
|
yuuji@0
|
2415 Most clients have an option to configure your connected
|
yuuji@0
|
2416 directory on the IMAP server. For example, in Pine you can
|
yuuji@0
|
2417 specify this as the "Path" in your folder-collection, e.g.
|
yuuji@0
|
2418
|
yuuji@0
|
2419 Nickname : Secondary Folders
|
yuuji@0
|
2420 Server : imap.example.com
|
yuuji@0
|
2421 Path : mail/
|
yuuji@0
|
2422 View :
|
yuuji@0
|
2423
|
yuuji@0
|
2424 In this example, the user is connected to the "mail"
|
yuuji@0
|
2425 subdirectory of his home directory.
|
yuuji@0
|
2426
|
yuuji@0
|
2427 Other servers call this the "folder prefix" or similar term.
|
yuuji@0
|
2428
|
yuuji@0
|
2429 It is possible to modify the IMAP server so that all users are
|
yuuji@0
|
2430 automatically connected to some other directory, e.g. a
|
yuuji@0
|
2431 subdirectory of the user's home directory. Read the file CONFIG
|
yuuji@0
|
2432 for more details.
|
yuuji@0
|
2433 _________________________________________________________________
|
yuuji@0
|
2434
|
yuuji@0
|
2435 7.24 Why is there a long delay before I get connected to the IMAP or
|
yuuji@0
|
2436 POP server, no matter what client I use?
|
yuuji@0
|
2437
|
yuuji@0
|
2438 There are two common occurances of this problem:
|
yuuji@0
|
2439
|
yuuji@0
|
2440 + You are running a system (e.g. certain versions of Linux)
|
yuuji@0
|
2441 which by default attempts to connect to an "IDENT" protocol
|
yuuji@0
|
2442 (port 113) server on your client. However, a firewall or NAT
|
yuuji@0
|
2443 box is blocking connections to that port, so the connection
|
yuuji@0
|
2444 attempt times out.
|
yuuji@0
|
2445 The IDENT protocol is a well-known bad idea that does not
|
yuuji@0
|
2446 deliver any real security but causes incredible problems. The
|
yuuji@0
|
2447 idea is that this will give the server a record of the user
|
yuuji@0
|
2448 name, or at least what some program listening on port 113
|
yuuji@0
|
2449 says is the user name. So, if somebody coming from port nnnnn
|
yuuji@0
|
2450 on a system does something bad, IDENT may give you the userid
|
yuuji@0
|
2451 of the bad guy.
|
yuuji@0
|
2452 The problem is, IDENT is only meaningful on a timesharing
|
yuuji@0
|
2453 system which has an administrator who is privileged and users
|
yuuji@0
|
2454 who are not. It is of no value on a personal system which has
|
yuuji@0
|
2455 no separate concept of "system administrator" vs.
|
yuuji@0
|
2456 "unprivileged user".
|
yuuji@0
|
2457 On either type of system, security-minded people either turn
|
yuuji@0
|
2458 IDENT off or replace it with an IDENT server that lies. Among
|
yuuji@0
|
2459 other things, IDENT gives spammers the ability to harvest
|
yuuji@0
|
2460 email addresses from anyone who connects to a web page.
|
yuuji@0
|
2461 This problem has been showing up quite frequently on systems
|
yuuji@0
|
2462 which use xinetd instead of inetd. Look for files named
|
yuuji@0
|
2463 /etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d,
|
yuuji@0
|
2464 and /etc/xinetd.d/ipop3d. In those files, look for lines
|
yuuji@0
|
2465 containing "USERID", e.g.
|
yuuji@0
|
2466 log_on_success += USERID
|
yuuji@0
|
2467 Hunt down such lines, and delete them ruthlessly from all
|
yuuji@0
|
2468 files in which they occur. Don't be shy about it.
|
yuuji@0
|
2469 + The DNS is taking a long time to do a reverse DNS (PTR
|
yuuji@0
|
2470 record) lookup of the IP address of your client. This is a
|
yuuji@0
|
2471 problem in your DNS, which either you or you ISP need to
|
yuuji@0
|
2472 resolve. Ideally, the DNS should return the client's name;
|
yuuji@0
|
2473 but if it can't it should at least return an error quickly.
|
yuuji@0
|
2474
|
yuuji@0
|
2475 As you may have noticed, neither of these are actual problems
|
yuuji@0
|
2476 in the IMAP or POP servers; they are configuration issues with
|
yuuji@0
|
2477 either your system or your network infrastructure. If this is
|
yuuji@0
|
2478 all new to you, run (don't walk) to the nearest technical
|
yuuji@0
|
2479 bookstore and get yourself a good pedagogical text on system
|
yuuji@0
|
2480 administration for the type of system you are running.
|
yuuji@0
|
2481 _________________________________________________________________
|
yuuji@0
|
2482
|
yuuji@0
|
2483 7.25 Why is there a long delay in Pine or any other c-client based
|
yuuji@0
|
2484 application call before I get connected to the IMAP server? The hang
|
yuuji@0
|
2485 seems to be in the c-client mail_open() call. I don't have this
|
yuuji@0
|
2486 problem with any other IMAP client. There is no delay connecting to a
|
yuuji@0
|
2487 POP3 or NNTP server with mail_open().
|
yuuji@0
|
2488
|
yuuji@0
|
2489 By default, the c-client library attempts to make a connection
|
yuuji@0
|
2490 through rsh (and ssh, if you enable that). If the command:
|
yuuji@0
|
2491
|
yuuji@0
|
2492 rsh imapserver exec /etc/rimapd
|
yuuji@0
|
2493
|
yuuji@0
|
2494 (or ssh if that is enabled) returns with a "* PREAUTH"
|
yuuji@0
|
2495 response, it will use the resulting rsh session as the IMAP
|
yuuji@0
|
2496 session and not require an authentication step on the server.
|
yuuji@0
|
2497
|
yuuji@0
|
2498 Unfortunately, rsh has a design error that treats "TCP
|
yuuji@0
|
2499 connection refused" as "temporary failure, try again"; it
|
yuuji@0
|
2500 expects the "rsh not allowed" case to be implemented as a
|
yuuji@0
|
2501 successful connection followed by an error message and close
|
yuuji@0
|
2502 the connection.
|
yuuji@0
|
2503
|
yuuji@0
|
2504 It must be emphasized that this is a bug in rsh. It is not a
|
yuuji@0
|
2505 bug in the IMAP toolkit.
|
yuuji@0
|
2506
|
yuuji@0
|
2507 The use of rsh can be disabled in any the following ways:
|
yuuji@0
|
2508
|
yuuji@0
|
2509 + You can disable it for this particular session by either:
|
yuuji@0
|
2510 o setting an explicit port number in the mailbox name,
|
yuuji@0
|
2511 e.g.
|
yuuji@0
|
2512 {imapserver.foo.com:143}INBOX
|
yuuji@0
|
2513 o using SSL (the /ssl switch)
|
yuuji@0
|
2514 + You can disable rsh globally by setting the rsh timeout value
|
yuuji@0
|
2515 to 0 with the call:
|
yuuji@0
|
2516 mail_parameters (NIL,SET_RSHTIMEOUT,0);
|
yuuji@0
|
2517 _________________________________________________________________
|
yuuji@0
|
2518
|
yuuji@0
|
2519 7.26 Why does a message sometimes get split into two or more messages
|
yuuji@0
|
2520 on my SUN system?
|
yuuji@0
|
2521
|
yuuji@0
|
2522 This is caused by an interaction of two independent design
|
yuuji@0
|
2523 problems in SUN mail software. The first problem is that the
|
yuuji@0
|
2524 "forward message" option in SUN's mail tool program includes
|
yuuji@0
|
2525 the internal "From " header line in the text that it forwarded.
|
yuuji@0
|
2526 This internal header line is specific to traditional UNIX
|
yuuji@0
|
2527 mailbox files and is not suitable for use in forwarded
|
yuuji@0
|
2528 messages.
|
yuuji@0
|
2529
|
yuuji@0
|
2530 The second problem is that the mail delivery agent assumes that
|
yuuji@0
|
2531 mail reading programs will not use the traditional UNIX mailbox
|
yuuji@0
|
2532 format but instead an incompatible variant that depends upon a
|
yuuji@0
|
2533 Content-Length: message header. Content-Length is widely
|
yuuji@0
|
2534 recognized to have been a terrible mistake, and is no longer
|
yuuji@0
|
2535 recommended for use in mail (it is used in other facilities
|
yuuji@0
|
2536 that use MIME).
|
yuuji@0
|
2537
|
yuuji@0
|
2538 One symptom of the problem is that under certain circumstances,
|
yuuji@0
|
2539 a message may get broken up into several messages. I'm also
|
yuuji@0
|
2540 aware of security bugs caused by programs that foolishly trust
|
yuuji@0
|
2541 "Content-Length:" headers with evil values.
|
yuuji@0
|
2542
|
yuuji@0
|
2543 To fix the mailer on your system, edit your sendmail.cf to
|
yuuji@0
|
2544 change the Mlocal line to have the -E flag. A typical entry
|
yuuji@0
|
2545 will lool like:
|
yuuji@0
|
2546
|
yuuji@0
|
2547 Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20,
|
yuuji@0
|
2548 A=mail.local -d $u
|
yuuji@0
|
2549
|
yuuji@0
|
2550 This fix will also work around the problem with mail tool,
|
yuuji@0
|
2551 because it will insert a ">" before the internal header line to
|
yuuji@0
|
2552 prevent it from being interpreted by mail reading software as
|
yuuji@0
|
2553 an internal header line.
|
yuuji@0
|
2554 _________________________________________________________________
|
yuuji@0
|
2555
|
yuuji@0
|
2556 7.27 Why did my POP or IMAP session suddenly disconnect? The syslog
|
yuuji@0
|
2557 has the message:
|
yuuji@0
|
2558 Autologout user=<...my user name...> host=<...my client system...>
|
yuuji@0
|
2559
|
yuuji@0
|
2560 This is a problem in your client.
|
yuuji@0
|
2561
|
yuuji@0
|
2562 In the case of IMAP, it failed to communicate with the IMAP
|
yuuji@0
|
2563 server for over 30 minutes; in the case of POP, it failed to
|
yuuji@0
|
2564 communicate with the POP server for over 10 minutes.
|
yuuji@0
|
2565 _________________________________________________________________
|
yuuji@0
|
2566
|
yuuji@0
|
2567 7.28 What does the UNIX error message: TLS/SSL failure: myserver: SSL
|
yuuji@0
|
2568 negotiation failed mean?
|
yuuji@0
|
2569 7.29 What does the PC error message: TLS/SSL failure: myserver:
|
yuuji@0
|
2570 Unexpected TCP input disconnect mean?
|
yuuji@0
|
2571
|
yuuji@0
|
2572 This usually means that an attempt to negotiate TLS encryption
|
yuuji@0
|
2573 via the STARTTLS command failed, because the server advertises
|
yuuji@0
|
2574 STARTTLS functionality, but doesn't actually have it (e.g.
|
yuuji@0
|
2575 because no certificates are installed).
|
yuuji@0
|
2576
|
yuuji@0
|
2577 Use the /notls option in the mailbox name to disable TLS
|
yuuji@0
|
2578 negotiation.
|
yuuji@0
|
2579 _________________________________________________________________
|
yuuji@0
|
2580
|
yuuji@0
|
2581 7.30 What does the error message: TLS/SSL failure: myserver: Server
|
yuuji@0
|
2582 name does not match certificate mean?
|
yuuji@0
|
2583
|
yuuji@0
|
2584 An SSL or TLS session encryption failed because the server name
|
yuuji@0
|
2585 in the server's certificate does not match the name that you
|
yuuji@0
|
2586 gave it. This could indicate that the server is not really the
|
yuuji@0
|
2587 system you think that it is, but can be also be called if you
|
yuuji@0
|
2588 gave a nickname for the server or name that was not
|
yuuji@0
|
2589 fully-qualified. You must use the fully-qualified domain name
|
yuuji@0
|
2590 for the server in order to validate its certificate
|
yuuji@0
|
2591
|
yuuji@0
|
2592 Use the /novalidate-cert option in the mailbox name to disable
|
yuuji@0
|
2593 validation of the certificate.
|
yuuji@0
|
2594 _________________________________________________________________
|
yuuji@0
|
2595
|
yuuji@0
|
2596 7.31 What does the UNIX error message: TLS/SSL failure: myserver:
|
yuuji@0
|
2597 self-signed certificate mean?
|
yuuji@0
|
2598 7.32 What does the PC error message: TLS/SSL failure: myserver:
|
yuuji@0
|
2599 Self-signed certificate or untrusted authority mean?
|
yuuji@0
|
2600
|
yuuji@0
|
2601 An SSL or TLS session encryption failed because your server's
|
yuuji@0
|
2602 certificate is "self-signed"; that is, it is not signed by any
|
yuuji@0
|
2603 Certificate Authority (CA) and thus can not be validated. A
|
yuuji@0
|
2604 CA-signed certificate costs money, and some smaller sites
|
yuuji@0
|
2605 either don't want to pay for it or haven't gotten one yet. The
|
yuuji@0
|
2606 bad part about this is that this means there is no guarantee
|
yuuji@0
|
2607 that the server is really the system you think that it is.
|
yuuji@0
|
2608
|
yuuji@0
|
2609 Use the /novalidate-cert option in the mailbox name to disable
|
yuuji@0
|
2610 validation of the certificate.
|
yuuji@0
|
2611 _________________________________________________________________
|
yuuji@0
|
2612
|
yuuji@0
|
2613 7.33 What does the UNIX error message: TLS/SSL failure: myserver:
|
yuuji@0
|
2614 unable to get local issuer certificate mean?
|
yuuji@0
|
2615
|
yuuji@0
|
2616 An SSL or TLS session encryption failed because your system
|
yuuji@0
|
2617 does not have the Certificate Authority (CA) certificates
|
yuuji@0
|
2618 installed on OpenSSL's certificates directory. On most systems,
|
yuuji@0
|
2619 this directory is /usr/local/ssl/certs). As a result, it is not
|
yuuji@0
|
2620 possible to validate the server's certificate.
|
yuuji@0
|
2621
|
yuuji@0
|
2622 If CA certificates are properly installed, you should see
|
yuuji@0
|
2623 factory.pem and about a dozen other .pem names such as
|
yuuji@0
|
2624 thawteCb.pem.
|
yuuji@0
|
2625
|
yuuji@0
|
2626 As a workaround, you can use the /novalidate-cert option in the
|
yuuji@0
|
2627 mailbox name to disable validation of the certificate; however,
|
yuuji@0
|
2628 note that you are then vulnerable to various security attacks
|
yuuji@0
|
2629 by bad guys.
|
yuuji@0
|
2630
|
yuuji@0
|
2631 The correct fix is to copy all the files from the certs/
|
yuuji@0
|
2632 directory in the OpenSSL distribution to the
|
yuuji@0
|
2633 /usr/local/ssl/certs (or whatever) directory. Note that you
|
yuuji@0
|
2634 need to do this after building OpenSSL, because the OpenSSL
|
yuuji@0
|
2635 build creates a number of needed symbolic links. For some
|
yuuji@0
|
2636 bizarre reason, the OpenSSL "make install" doesn't do this for
|
yuuji@0
|
2637 you, so you must do it manually.
|
yuuji@0
|
2638 _________________________________________________________________
|
yuuji@0
|
2639
|
yuuji@0
|
2640 7.34 Why does reading certain messages hang when using Netscape? It
|
yuuji@0
|
2641 works fine with Pine!
|
yuuji@0
|
2642
|
yuuji@0
|
2643 There are two possible causes.
|
yuuji@0
|
2644
|
yuuji@0
|
2645 Check the mail syslog. If you see the message "Killed (lost
|
yuuji@0
|
2646 mailbox lock)" for the impacted user(s), read the FAQ entry
|
yuuji@0
|
2647 regarding that message.
|
yuuji@0
|
2648
|
yuuji@0
|
2649 Check the affected mailbox to see if there are embedded NUL
|
yuuji@0
|
2650 characters in the message. NULs in message texts are a
|
yuuji@0
|
2651 technical violation of both the message format and IMAP
|
yuuji@0
|
2652 specifications. Most clients don't care, but apparently
|
yuuji@0
|
2653 Netscape does.
|
yuuji@0
|
2654
|
yuuji@0
|
2655 You can work around this by rebuilding imapd with the
|
yuuji@0
|
2656 NETSCAPE_BRAIN_DAMAGE option set (see src/imapd/Makefile); this
|
yuuji@0
|
2657 will cause imapd to convert all NULs to 0x80 characters. A
|
yuuji@0
|
2658 better solution is to enable the feature in your MTA to
|
yuuji@0
|
2659 MIME-convert messages with binary content. See the
|
yuuji@0
|
2660 documentation for your MTA for how to do this.
|
yuuji@0
|
2661 _________________________________________________________________
|
yuuji@0
|
2662
|
yuuji@0
|
2663 7.35 Why does Netscape say that there's a problem with the IMAP server
|
yuuji@0
|
2664 and that I should "Contact your mail server administrator."?
|
yuuji@0
|
2665
|
yuuji@0
|
2666 Certain versions of Netscape do this when you click the Manage
|
yuuji@0
|
2667 Mail button, which uses an undocumented feature of Netscape's
|
yuuji@0
|
2668 proprietary IMAP server.
|
yuuji@0
|
2669
|
yuuji@0
|
2670 You can work around this by rebuilding imapd with the
|
yuuji@0
|
2671 NETSCAPE_BRAIN_DAMAGE option set (see src/imapd/Makefile) to a
|
yuuji@0
|
2672 URL that points either to an alternative IMAP client (e.g.
|
yuuji@0
|
2673 Pine) or perhaps to a homebrew mail account management page.
|
yuuji@0
|
2674 _________________________________________________________________
|
yuuji@0
|
2675
|
yuuji@0
|
2676 7.36 Why is one user creating huge numbers of IMAP or POP server
|
yuuji@0
|
2677 sessions?
|
yuuji@0
|
2678
|
yuuji@0
|
2679 The user is probably using Outlook Express, Eudora, or a
|
yuuji@0
|
2680 similar program. See the answer to the Help! My load average is
|
yuuji@0
|
2681 soaring and I see hundreds of POP and IMAP servers, many logged
|
yuuji@0
|
2682 in as the same user! question.
|
yuuji@0
|
2683 _________________________________________________________________
|
yuuji@0
|
2684
|
yuuji@0
|
2685 7.37 Why don't I get any new mail notifications from Outlook Express
|
yuuji@0
|
2686 or Outlook after a while?
|
yuuji@0
|
2687
|
yuuji@0
|
2688 This is a known bug in Outlook Express. Microsoft is aware of
|
yuuji@0
|
2689 the problem and its cause. They have informed us that they do
|
yuuji@0
|
2690 not have any plans to fix it at the present time.
|
yuuji@0
|
2691
|
yuuji@0
|
2692 The problem is also reported in Outlook 2000, but not verified.
|
yuuji@0
|
2693
|
yuuji@0
|
2694 Outlook Express uses the IMAP IDLE command to avoid having to
|
yuuji@0
|
2695 "ping" the server every few minutes for new mail.
|
yuuji@0
|
2696 Unfortunately, Outlook Express overlooks the part in the IDLE
|
yuuji@0
|
2697 specification which requires that a client terminate and
|
yuuji@0
|
2698 restart the IDLE before the IMAP 30 minute inactivity
|
yuuji@0
|
2699 autologout timer triggers.
|
yuuji@0
|
2700
|
yuuji@0
|
2701 When this happens, Outlook Express displays "Not connected" at
|
yuuji@0
|
2702 the bottom of the window. Since it's no longer connected to the
|
yuuji@0
|
2703 IMAP server, it isn't going to notice any new mail.
|
yuuji@0
|
2704
|
yuuji@0
|
2705 As soon as the user does anything that would cause an IMAP
|
yuuji@0
|
2706 operation, Outlook Express will reconnect and new mail will
|
yuuji@0
|
2707 flow again. If the user does something that causes an IMAP
|
yuuji@0
|
2708 operation at least every 29 minutes, the problem won't happen.
|
yuuji@0
|
2709
|
yuuji@0
|
2710 Modern versions of imapd attempt to work around the problem by
|
yuuji@0
|
2711 automatically reporting fake new mail after 29 minutes. This
|
yuuji@0
|
2712 causes Outlook Express to exit the IDLE state; as soon as this
|
yuuji@0
|
2713 happens imapd revokes the fake new mail. As long as this
|
yuuji@0
|
2714 behavior isn't known to cause problems with other clients, this
|
yuuji@0
|
2715 workaround will remain in imapd.
|
yuuji@0
|
2716 _________________________________________________________________
|
yuuji@0
|
2717
|
yuuji@0
|
2718 7.38 Why don't I get any new mail notifications from Entourage?
|
yuuji@0
|
2719
|
yuuji@0
|
2720 This is a known bug in Entourage.
|
yuuji@0
|
2721
|
yuuji@0
|
2722 You built an older version of imapd with the
|
yuuji@0
|
2723 MICROSOFT_BRAIN_DAMAGE option set, in order to disable support
|
yuuji@0
|
2724 for the IDLE command. However, Entourage won't get new mail
|
yuuji@0
|
2725 unless IDLE command support exists.
|
yuuji@0
|
2726
|
yuuji@0
|
2727 Note: the MICROSOFT_BRAIN_DAMAGE option no longer exists in
|
yuuji@0
|
2728 modern versions, as the Outlook Express problem which it
|
yuuji@0
|
2729 attempted to solve has been worked around in another way.
|
yuuji@0
|
2730 _________________________________________________________________
|
yuuji@0
|
2731
|
yuuji@0
|
2732 7.39 Why doesn't Entourage work at all?
|
yuuji@0
|
2733
|
yuuji@0
|
2734 It's hard to know. Entourage breaks almost every rule in the
|
yuuji@0
|
2735 book for IMAP. It is highly instructive to do a packet trace on
|
yuuji@0
|
2736 Entourage, as an example of how not to use IMAP. It does things
|
yuuji@0
|
2737 like STATUS (MESSAGES) on the currently selected mailbox and
|
yuuji@0
|
2738 re-fetching the same static data over and over again.
|
yuuji@0
|
2739
|
yuuji@0
|
2740 It seems that every time we understand what it is doing wrong
|
yuuji@0
|
2741 in Entourage and come up with a workaround, we learn about
|
yuuji@0
|
2742 something else that's broken.
|
yuuji@0
|
2743
|
yuuji@0
|
2744 Try building imapd with the ENTOURAGE_BRAIN_DAMAGE option set,
|
yuuji@0
|
2745 in order to disable the diagnostic that occurs when doing
|
yuuji@0
|
2746 STATUS on the currently selected mailbox.
|
yuuji@0
|
2747 _________________________________________________________________
|
yuuji@0
|
2748
|
yuuji@0
|
2749 7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work at all?
|
yuuji@0
|
2750
|
yuuji@0
|
2751 This is a bug in NSNOTIFY; it doesn't handle unsolicited data
|
yuuji@0
|
2752 from the server correctly.
|
yuuji@0
|
2753
|
yuuji@0
|
2754 Fortunately, there is no reason to use this program with IMAP;
|
yuuji@0
|
2755 NSNOTIFY is a polling program to let you know when new mail has
|
yuuji@0
|
2756 appeared in your maildrop. This is necessary with POP; but
|
yuuji@0
|
2757 since IMAP dynamically announces new mail in the session you're
|
yuuji@0
|
2758 better off (and will actually cause less load on the server!)
|
yuuji@0
|
2759 keeping your mail reading program's IMAP session open and let
|
yuuji@0
|
2760 IMAP do the notifying for you.
|
yuuji@0
|
2761
|
yuuji@0
|
2762 Consequently, the recommended fix for the NSNOTIFY problem is
|
yuuji@0
|
2763 to delete the NSNOTIFY binary.
|
yuuji@0
|
2764 _________________________________________________________________
|
yuuji@0
|
2765
|
yuuji@0
|
2766 7.41 Why can't I connect via SSL to Eudora? It says the connection has
|
yuuji@0
|
2767 been broken, and in the server syslogs I see "Command stream end of
|
yuuji@0
|
2768 file".
|
yuuji@0
|
2769
|
yuuji@0
|
2770 There is a report that you can fix the problem by going into
|
yuuji@0
|
2771 Eudora's advanced network configuration menu and increasing the
|
yuuji@0
|
2772 network buffer size to 8192.
|
yuuji@0
|
2773 _________________________________________________________________
|
yuuji@0
|
2774
|
yuuji@0
|
2775 7.42 Sheesh. Aren't there any good IMAP clients out there?
|
yuuji@0
|
2776
|
yuuji@0
|
2777 Yes!
|
yuuji@0
|
2778
|
yuuji@0
|
2779 Pine is a wonderful client. It's fast, it uses IMAP well, and
|
yuuji@0
|
2780 it generates text mail (life is too short to waste on HTML
|
yuuji@0
|
2781 mail). Also, there are some really wonderful things in progress
|
yuuji@0
|
2782 in the Pine world.
|
yuuji@0
|
2783
|
yuuji@0
|
2784 There are some good GUI clients out there, mostly from smaller
|
yuuji@0
|
2785 vendors. Without naming names, look for the vendors who are
|
yuuji@0
|
2786 active in the IMAP protocol development community, and their
|
yuuji@0
|
2787 products.
|
yuuji@0
|
2788
|
yuuji@0
|
2789 Netscape, Eudora, and Outlook can be configured with enough
|
yuuji@0
|
2790 effort to be good citizens and work well for users, but they
|
yuuji@0
|
2791 can also be badly misconfigured, and often the misconfiguration
|
yuuji@0
|
2792 is the default.
|
yuuji@0
|
2793 _________________________________________________________________
|
yuuji@0
|
2794
|
yuuji@0
|
2795 7.43 But wait! PC Pine (or other PC program build with c-client)
|
yuuji@0
|
2796 crashes with the message incomplete SecBuffer exceeds maximum buffer
|
yuuji@0
|
2797 size when I use SSL connections. This is a bug in c-client, right?
|
yuuji@0
|
2798
|
yuuji@0
|
2799 It's a bug in the Microsoft SChannel.DLL, which implements SSL.
|
yuuji@0
|
2800 Microsoft admits it (albeit with an unstatement: "it's not
|
yuuji@0
|
2801 fully RFC compliant"). The problem is that SChannel indicates
|
yuuji@0
|
2802 that the maximum SSL packet data size is 5 bytes smaller than
|
yuuji@0
|
2803 the actual maximum. Thus, any IMAP server which transmits a
|
yuuji@0
|
2804 maximum sized SSL packet will not work with PC Pine or any
|
yuuji@0
|
2805 other program which uses SChannel.
|
yuuji@0
|
2806
|
yuuji@0
|
2807 It can take a while for the problem to show up. The client has
|
yuuji@0
|
2808 to do something that causes at least 16K of contiguous data.
|
yuuji@0
|
2809 Many clients do partial fetching, which tends to reduce the
|
yuuji@0
|
2810 number of cases where this can happen. However, all software
|
yuuji@0
|
2811 which uses SChannel to support SSL is affected by this bug.
|
yuuji@0
|
2812
|
yuuji@0
|
2813 This problem does not affect UNIX code, since OpenSSL is used
|
yuuji@0
|
2814 on UNIX.
|
yuuji@0
|
2815
|
yuuji@0
|
2816 This problem most recently showed up with the CommunigatePro
|
yuuji@0
|
2817 IMAP server. They have an update which trims down their maximum
|
yuuji@0
|
2818 contiguous data to less than 16K, in order to work around the
|
yuuji@0
|
2819 problem.
|
yuuji@0
|
2820
|
yuuji@0
|
2821 This problem has also shown up with the Exchange IMAP server
|
yuuji@0
|
2822 with UNIX clients (including Pine built with an older version
|
yuuji@0
|
2823 of c-client) which sends full-sized 16K SSL packets. Modern
|
yuuji@0
|
2824 c-client works around the problem by trimming down its maximum
|
yuuji@0
|
2825 outgoing SSL packet size to 8K.
|
yuuji@0
|
2826
|
yuuji@0
|
2827 Microsoft has developed a hotfix for this bug. Look up MSKB
|
yuuji@0
|
2828 article number 300562. Contrary to the article text which
|
yuuji@0
|
2829 implies that this is a Pine issue, this bug also affect
|
yuuji@0
|
2830 Microsoft Exchange server with *any* UNIX based client that
|
yuuji@0
|
2831 transmits full-sized SSL payloads.
|
yuuji@0
|
2832 _________________________________________________________________
|
yuuji@0
|
2833
|
yuuji@0
|
2834 7.44 My qpopper users keep on getting the DON'T DELETE THIS MESSAGE --
|
yuuji@0
|
2835 FOLDER INTERNAL DATA if they also use Pine or IMAP. How can I fix
|
yuuji@0
|
2836 this?
|
yuuji@0
|
2837
|
yuuji@0
|
2838 This is an incompatibility between qpopper and the c-client
|
yuuji@0
|
2839 library used by Pine, imapd, and ipop[23]d.
|
yuuji@0
|
2840
|
yuuji@0
|
2841 Assuming that you want to continue using qpopper, look into
|
yuuji@0
|
2842 qpopper's --enable-uw-kludge-flag configuration flag, which is
|
yuuji@0
|
2843 documented as "check for and hide UW 'Folder Internal Data'
|
yuuji@0
|
2844 messages".
|
yuuji@0
|
2845
|
yuuji@0
|
2846 The other alternative is to switch from qpopper to ipop3d.
|
yuuji@0
|
2847 _________________________________________________________________
|
yuuji@0
|
2848
|
yuuji@0
|
2849 7.45 Help! I installed the servers but I can't connect to them from my
|
yuuji@0
|
2850 client!
|
yuuji@0
|
2851
|
yuuji@0
|
2852 Review the installation instructions carefully. Make sure that
|
yuuji@0
|
2853 you have not skipped any of the steps. Make sure that you have
|
yuuji@0
|
2854 made the correct entries in the configuration files; pay
|
yuuji@0
|
2855 careful attention to the exact spelling of the service names
|
yuuji@0
|
2856 and the path names. Make sure as well that you have properly
|
yuuji@0
|
2857 restarted inetd.
|
yuuji@0
|
2858
|
yuuji@0
|
2859 If you have a system with Yellow Pages/NIS such as Solaris,
|
yuuji@0
|
2860 have you updated the service names there as well as in
|
yuuji@0
|
2861 /etc/services?
|
yuuji@0
|
2862
|
yuuji@0
|
2863 If you have a system with TCP wrappers, have you properly
|
yuuji@0
|
2864 updated the TCP wrapper files (e.g. /etc/hosts.allow and
|
yuuji@0
|
2865 /etc/hosts.deny) for the servers?
|
yuuji@0
|
2866
|
yuuji@0
|
2867 If you have a system which uses xinetd instead of inetd, have
|
yuuji@0
|
2868 you made sure that you have made the correct corresponding
|
yuuji@0
|
2869 xinetd changes for those services?
|
yuuji@0
|
2870
|
yuuji@0
|
2871 Try telneting to the server port (143 for IMAP, 110 for POP3).
|
yuuji@0
|
2872 If you get a "refused" error, that probably means that you
|
yuuji@0
|
2873 don't have the service set up in inetd.conf. If the connection
|
yuuji@0
|
2874 opens and then closes with no message, the service is set up,
|
yuuji@0
|
2875 but either the path name of the server binary in inetd.conf is
|
yuuji@0
|
2876 wrong or your TCP wrappers are configured to deny access.
|
yuuji@0
|
2877
|
yuuji@0
|
2878 If you don't know how to make the corresponding changes to
|
yuuji@0
|
2879 these files, seek the help of a local expert for your system.
|
yuuji@0
|
2880 _________________________________________________________________
|
yuuji@0
|
2881
|
yuuji@0
|
2882 7.46 Why do I get the message Can not authenticate to SMTP server: 421
|
yuuji@0
|
2883 SMTP connection went away! and why did this happen? There was also
|
yuuji@0
|
2884 something about SECURITY PROBLEM: insecure server advertised
|
yuuji@0
|
2885 AUTH=PLAIN
|
yuuji@0
|
2886
|
yuuji@0
|
2887 Some versions of qmail, including that running on
|
yuuji@0
|
2888 mail.smtp.yahoo.com, disconnect the SMTP session if you fail to
|
yuuji@0
|
2889 authenticate prior to attempting to transmit mail. An attempt
|
yuuji@0
|
2890 to authenticate was made, but it failed because the server had
|
yuuji@0
|
2891 already disconnected.
|
yuuji@0
|
2892
|
yuuji@0
|
2893 To work around this, you need to specify /user=... in the host
|
yuuji@0
|
2894 name specification.
|
yuuji@0
|
2895
|
yuuji@0
|
2896 The SECURITY PROBLEM came about because the server advertised
|
yuuji@0
|
2897 the AUTH=PLAIN SASL authentication mechanism outside of a
|
yuuji@0
|
2898 TLS-encrypted session, in violation of RFC 4616. This message
|
yuuji@0
|
2899 is just a warning, and in fact occurred after the server had
|
yuuji@0
|
2900 disconnected.
|
yuuji@0
|
2901 _________________________________________________________________
|
yuuji@0
|
2902
|
yuuji@0
|
2903 7.47 Why do I get the message SMTP Authentication cancelled and why
|
yuuji@0
|
2904 did this happen? There was also something about SECURITY PROBLEM:
|
yuuji@0
|
2905 insecure server advertised AUTH=PLAIN
|
yuuji@0
|
2906
|
yuuji@0
|
2907 This is a bug in the SMTP server.
|
yuuji@0
|
2908
|
yuuji@0
|
2909 Some versions of qmail, including that running on
|
yuuji@0
|
2910 mail.smtp.yahoo.com, have a bug in their implementation of SASL
|
yuuji@0
|
2911 in their SMTP server, which renders it non-compliant with the
|
yuuji@0
|
2912 standard.
|
yuuji@0
|
2913
|
yuuji@0
|
2914 If the client does not provide an initial response in the
|
yuuji@0
|
2915 command line for an authentication mechanism whose profile does
|
yuuji@0
|
2916 not have an initial challenge, qmail issues a bogus response:
|
yuuji@0
|
2917
|
yuuji@0
|
2918 334 ok, go on
|
yuuji@0
|
2919
|
yuuji@0
|
2920 The problem is the "ok, go on". This violates RFC 4954's
|
yuuji@0
|
2921 requirement that the text part in a 334 response be a BASE64
|
yuuji@0
|
2922 encoded string; in other words, it is a protocol syntax error.
|
yuuji@0
|
2923
|
yuuji@0
|
2924 In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the
|
yuuji@0
|
2925 encoded string have no data. In other words, the appropropiate
|
yuuji@0
|
2926 standards-compliant server response is "334" followed by a
|
yuuji@0
|
2927 SPACE and a CRLF.
|
yuuji@0
|
2928
|
yuuji@0
|
2929 The SECURITY PROBLEM came about because the server advertised
|
yuuji@0
|
2930 the AUTH=PLAIN SASL authentication mechanism outside of a
|
yuuji@0
|
2931 TLS-encrypted session, in violation of RFC 4616. This message
|
yuuji@0
|
2932 is just a warning, and is not related the "Authentication
|
yuuji@0
|
2933 cancelled" problem.
|
yuuji@0
|
2934 _________________________________________________________________
|
yuuji@0
|
2935
|
yuuji@0
|
2936 7.48 Why do I get the message Invalid base64 string when I try to
|
yuuji@0
|
2937 authenticate to a Cyrus server?
|
yuuji@0
|
2938
|
yuuji@0
|
2939 This slightly misleading message is the way that a Cyrus server
|
yuuji@0
|
2940 indicates that an authentication exchange was cancelled. It is
|
yuuji@0
|
2941 not indicative of a bug or protocol violation.
|
yuuji@0
|
2942
|
yuuji@0
|
2943 The most common reason that this happens is if the Cyrus server
|
yuuji@0
|
2944 offers Kerberos authentication, c-client is built with Kerberos
|
yuuji@0
|
2945 support, but your client system is not within the Kerberos
|
yuuji@0
|
2946 realm. In this case, the client code will try to authenticate
|
yuuji@0
|
2947 via Kerberos, fail to get the Kerberos credentials, cancel the
|
yuuji@0
|
2948 authentication attempt, and try the next available
|
yuuji@0
|
2949 authentication technology.
|
yuuji@0
|
2950 _________________________________________________________________
|
yuuji@0
|
2951
|
yuuji@0
|
2952 8. Where to Go For Additional Information
|
yuuji@0
|
2953 _________________________________________________________________
|
yuuji@0
|
2954
|
yuuji@0
|
2955 8.1 Where can I go to ask questions?
|
yuuji@0
|
2956 8.2 I have some ideas for enhancements to IMAP. Where should I go?
|
yuuji@0
|
2957
|
yuuji@0
|
2958 If you have questions about the IMAP protocol, or want to
|
yuuji@0
|
2959 participate in discussions of future directions of the IMAP
|
yuuji@0
|
2960 protocol, the appropriate mailing list is
|
yuuji@0
|
2961 imap-protocol@u.washington.edu. You can subscribe to this
|
yuuji@0
|
2962 list via imap-protocol-request@u.washington.edu
|
yuuji@0
|
2963
|
yuuji@0
|
2964 If you have questions about this software, you can send me
|
yuuji@0
|
2965 email directly or use the imap-uw@u.washington.edu mailing
|
yuuji@0
|
2966 list. You can subscribe to this list via
|
yuuji@0
|
2967 imap-uw-request@u.washington.edu
|
yuuji@0
|
2968
|
yuuji@0
|
2969 If you have general questions about the use of IMAP software
|
yuuji@0
|
2970 (not specific to the UW IMAP toolkit) use the
|
yuuji@0
|
2971 imap-use@u.washington.edu mailing list. You can subscribe to
|
yuuji@0
|
2972 this list via imap-use-request@u.washington.edu
|
yuuji@0
|
2973
|
yuuji@0
|
2974 You must be a subscriber to post to these lists. As an
|
yuuji@0
|
2975 alternative, you can use the comp.mail.imap newsgroup.
|
yuuji@0
|
2976 _________________________________________________________________
|
yuuji@0
|
2977
|
yuuji@0
|
2978 8.3 Where can I read more about IMAP and other email protocols?
|
yuuji@0
|
2979
|
yuuji@0
|
2980 We recommend Internet Email Protocols: A Developer's Guide, by
|
yuuji@0
|
2981 Kevin Johnson, published by Addison Wesley, ISBN 0-201-43288-9.
|
yuuji@0
|
2982 _________________________________________________________________
|
yuuji@0
|
2983
|
yuuji@0
|
2984 8.4 Where can I find out more about setting up and administering an
|
yuuji@0
|
2985 IMAP server?
|
yuuji@0
|
2986
|
yuuji@0
|
2987 We recommend Managing IMAP, by Dianna Mullet & Kevin Mullet,
|
yuuji@0
|
2988 published by O'Reilly, ISBN 0-596-00012-X.
|
yuuji@0
|
2989
|
yuuji@0
|
2990 This book also has an excellent comparison of the UW and Cyrus
|
yuuji@0
|
2991 IMAP servers.
|
yuuji@0
|
2992
|
yuuji@0
|
2993 Last Updated: 15 November 2007
|