imapext-2007
view docs/FAQ.html @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
1 <!--
2 * ========================================================================
3 * Copyright 1988-2007 University of Washington
4 *
5 * Licensed under the Apache License, Version 2.0 (the "License");
6 * you may not use this file except in compliance with the License.
7 * You may obtain a copy of the License at
8 *
9 * http://www.apache.org/licenses/LICENSE-2.0
10 *
11 *
12 * ========================================================================
13 *
14 -->
16 <!--chtml set title="IMAP Toolkit Frequently Asked Questions"-->
17 <!--chtml include "//imap/incs/top.inc"-->
19 <h2>Table of Contents</h2>
21 <ul>
22 <li>
23 <a href="#general">1. General/Software Feature Questions</a>
25 <ul>
26 <li><a href="#1.1">1.1 Can I set up a POP or IMAP server on
27 UNIX/Linux/OSF/etc.?</a></li>
29 <li><a href="#1.2">1.2 I am currently using qpopper as my POP3 server
30 on UNIX. Do I need to replace it with ipop3d in order to run
31 imapd?</a></li>
33 <li><a href="#1.3">1.3 Can I set up a POP or IMAP server on Windows
34 XP, 2000, NT, Me, 98, or 95?</a></li>
36 <li><a href="#1.4">1.4 Can I set up a POP or IMAP server on Windows
37 3.1 or DOS?</a></li>
39 <li><a href="#1.5">1.5 Can I set up a POP or IMAP server on
40 Macintosh?</a></li>
42 <li><a href="#1.6">1.6 Can I set up a POP or IMAP server on
43 VAX/VMS?</a></li>
45 <li><a href="#1.7">1.7 Can I set up a POP or IMAP server on
46 TOPS-20?</a></li>
48 <li><a href="#1.8">1.8 Are hierarchical mailboxes supported?</a></li>
50 <li><a href="#1.9">1.9 Are "dual-use" mailboxes supported?</a></li>
52 <li><a href="#1.10">1.10 Can I have a mailbox that has both messages
53 and sub-mailboxes?</a></li>
55 <li><a href="#1.11">1.11 What is the difference between "mailbox" and
56 "folder"?</a></li>
58 <li><a href="#1.12">1.12 What is the status of
59 internationalization?</a></li>
61 <li><a href="#1.13">1.13 Can I use SSL?</a></li>
63 <li><a href="#1.14">1.14 Can I use TLS and the STARTTLS
64 facility?</a></li>
66 <li><a href="#1.15">1.15 Can I use CRAM-MD5 authentication?</a></li>
68 <li><a href="#1.16">1.16 Can I use APOP authentication?</a></li>
70 <li><a href="#1.17">1.17 Can I use Kerberos V5?</a></li>
72 <li><a href="#1.18">1.18 Can I use PAM for plaintext
73 passwords?</a></li>
75 <li><a href="#1.19">1.19 Can I use Kerberos 5 for plaintext
76 passwords?</a></li>
78 <li><a href="#1.20">1.20 Can I use AFS for plaintext
79 passwords?</a></li>
81 <li><a href="#1.21">1.21 Can I use DCE for plaintext
82 passwords?</a></li>
84 <li><a href="#1.22">1.22 Can I use the CRAM-MD5 database for
85 plaintext passwords?</a></li>
87 <li><a href="#1.23">1.23 Can I disable plaintext passwords?</a></li>
89 <li><a href="#1.24">1.24 Can I disable plaintext passwords on
90 unencrypted sessions, but allow them on encrypted sessions?</a></li>
92 <li><a href="#1.25">1.25 Can I use virtual hosts?</a></li>
94 <li><a href="#1.26">1.26 Can I use RPOP authentication?</a></li>
96 <li><a href="#1.27">1.27 Can I use Kerberos V4?</a></li>
98 <li><a href="#1.28">1.28 Is there support for S/Key or OTP?</a></li>
100 <li><a href="#1.29">1.29 Is there support for NTLM or SPA?</a></li>
102 <li><a href="#1.30">1.30 Is there support for mh?</a></li>
104 <li><a href="#1.31">1.31 Is there support for qmail and the maildir
105 format?</a></li>
107 <li><a href="#1.32">1.32 Is there support for the Cyrus mailbox
108 format?</a></li>
110 <li><a href="#1.33">1.33 Is this software Y2K compliant?</a></li>
111 </ul>
112 </li>
114 <li>
115 <a href="#requirements">2. What Do I Need to Build This Software?</a>
117 <ul>
118 <li><a href="#2.1">2.1 What do I need to build this software with SSL
119 on UNIX?</a></li>
121 <li><a href="#2.2">2.2 What do I need to build this software with
122 Kerberos V on UNIX?</a></li>
124 <li><a href="#2.3">2.3 What do I need to use a C++ compiler with this
125 software to build my own application?</a></li>
127 <li><a href="#2.4">2.4 What do I need to build this software on
128 Windows?</a></li>
130 <li><a href="#2.5">2.5 What do I need to build this software on
131 DOS?</a></li>
133 <li><a href="#2.6">2.6 Can't I use Borland C to build this software
134 on the PC?</a></li>
136 <li><a href="#2.7">2.7 What do I need to build this software on the
137 Mac?</a></li>
139 <li><a href="#2.8">2.8 What do I need to build this software on
140 VMS?</a></li>
142 <li><a href="#2.9">2.9 What do I need to build this software on
143 TOPS-20?</a></li>
145 <li><a href="#2.10">2.10 What do I need to build this software on
146 Amiga or OS/2?</a></li>
148 <li><a href="#2.11">2.11 What do I need to build this software on
149 Windows CE?</a></li>
150 </ul>
151 </li>
153 <li>
154 <a href="#build">3. Build and Configuration Questions</a>
156 <ul>
157 <li><a href="#3.1">3.1 How do I configure the IMAP and POP servers on
158 UNIX?</a></li>
160 <li><a href="#3.2">3.2 I built and installed the servers according to
161 the BUILD instructions. It can't be that easy. Don't I need to write
162 a config file?</a></li>
164 <li><a href="#3.3">3.3 How do I make the IMAP and POP servers look
165 for INBOX at some place other than the mail spool directory?</a></li>
167 <li><a href="#3.4">3.4 How do I make the IMAP server look for
168 secondary folders at some place other than the user's home
169 directory?</a></li>
171 <li><a href="#3.5">3.5 How do I configure SSL?</a></li>
173 <li><a href="#3.6">3.6 How do I configure TLS and the STARTTLS
174 facility?</a></li>
176 <li><a href="#3.7">3.7 How do I build/install OpenSSL and
177 obtain/create certificates for use with SSL?</a></li>
179 <li><a href="#3.8">3.8 How do I configure CRAM-MD5
180 authentication?</a></li>
182 <li><a href="#3.9">3.9 How do I configure APOP
183 authentication?</a></li>
185 <li><a href="#3.10">3.10 How do I configure Kerberos V5?</a></li>
187 <li><a href="#3.11">3.11 How do I configure PAM for plaintext
188 passwords?</a></li>
190 <li><a href="#3.12">3.12 It looks like all I have to do to make the
191 server use Kerberos is to build with PAM on my Linux system, and set
192 it up in PAM for Kerberos passwords. Right?</a></li>
194 <li><a href="#3.13">3.13 How do I configure Kerberos 5 for plaintext
195 passwords?</a></li>
197 <li><a href="#3.14">3.14 How do I configure AFS for plaintext
198 passwords?</a></li>
200 <li><a href="#3.15">3.15 How do I configure DCE for plaintext
201 passwords?</a></li>
203 <li><a href="#3.16">3.16 How do I configure the CRAM-MD5 database for
204 plaintext passwords?</a></li>
206 <li><a href="#3.17">3.17 How do I disable plaintext
207 passwords?</a></li>
209 <li><a href="#3.18">3.18 How do I disable plaintext passwords on
210 unencrypted sessions, but allow them in SSL or TLS sessions?</a></li>
212 <li><a href="#3.19">3.19 How do I configure virtual hosts?</a></li>
214 <li>
215 <a href="#3.20">3.20 Why do I get compiler warning messages such
216 as:
218 <ul>
219 <li>passing arg 3 of `scandir' from incompatible pointer
220 type</li>
222 <li>Pointers are not assignment-compatible.</li>
224 <li>Argument #4 is not the correct type.</li>
225 </ul>during the build?</a>
226 </li>
228 <li>
229 <a href="#3.21">3.21 Why do I get compiler warning messages such
230 as
232 <ul>
233 <li>Operation between types "void(*)(int)" and "void*" is not
234 allowed.</li>
236 <li>Function argument assignment between types "void*" and
237 "void(*)(int)" is not allowed.</li>
239 <li>Pointers are not assignment-compatible.</li>
241 <li>Argument #5 is not the correct type.</li>
242 </ul>during the build?</a>
243 </li>
245 <li>
246 <a href="#3.22">3.22 Why do I get linker warning messages such
247 as:
249 <ul>
250 <li>mtest.c:515: the `gets' function is dangerous and should not
251 be used.</li>
252 </ul>during the build? Isn't this a security bug?</a>
253 </li>
255 <li>
256 <a href="#3.23">3.23 Why do I get linker warning messages such
257 as:</a>
259 <ul>
260 <li>auth_ssl.c:92: the `tmpnam' function is dangerous and should
261 not be used.</li>
262 </ul>during the build? Isn't this a security bug?
263 </li>
265 <li><a href="#3.24">3.24 OK, suppose I see a warning message about a
266 function being "dangerous and should not be used" for something other
267 than this gets() or tmpnam() call?</a></li>
268 </ul>
269 </li>
271 <li>
272 <a href="#operation">4. Operational Questions</a>
274 <ul>
275 <li><a href="#4.1">4.1 How can I enable anonymous IMAP
276 logins?</a></li>
278 <li><a href="#4.2">4.2 How do I set up an alert message that each
279 IMAP user will see?</a></li>
281 <li><a href="#4.3">4.3 How does the c-client library choose which of
282 its several mechanisms to use to establish an IMAP connection to the
283 server? I noticed that it can connect on port 143, port 993, via rsh,
284 and via ssh.</a></li>
286 <li><a href="#4.4">4.4 I am using a TLS-capable IMAP server, so I
287 don't need to use /ssl to get encryption. However, I want to be
288 certain that my session is TLS encrypted before I send my password.
289 How to I do this?</a></li>
291 <li><a href="#4.5">4.5 How do I use one of the alternative formats
292 described in the formats.txt document? In particular, I hear that mbx
293 format will give me better performance and allow shared
294 access.</a></li>
296 <li><a href="#4.6">4.6 How do I set up shared mailboxes?</a></li>
298 <li><a href="#4.7">4.7 How can I make the server syslogs go to
299 someplace other than the mail syslog?</a></li>
300 </ul>
301 </li>
303 <li>
304 <a href="#security">5. Security Questions</a>
306 <ul>
307 <li><a href="#5.1">5.1 I see that the IMAP server allows access to
308 arbitary files on the system, including /etc/passwd! How do I disable
309 this?</a></li>
311 <li><a href="#5.2">5.2 I've heard that IMAP servers are insecure. Is
312 this true?</a></li>
314 <li><a href="#5.3">5.3 How do I know that I have the most secure
315 version of the server?</a></li>
317 <li><a href="#5.4">5.4 I see all these strcpy() and sprintf() calls,
318 those are unsafe, aren't they?</a></li>
320 <li><a href="#5.5">5.5 Those /tmp lock files are protected 666, is
321 that really right?</a></li>
322 </ul>
323 </li>
325 <li>
326 <a href="#strange">6. <i>Why Did You Do This Strange Thing?</i>
327 Questions</a>
329 <ul>
330 <li><a href="#6.1">6.1 Why don't you use GNU autoconfig / automake /
331 autoblurdybloop?</a></li>
333 <li><a href="#6.2">6.2 Why do you insist upon a build with -g?
334 Doesn't it waste disk and memory space?</a></li>
336 <li><a href="#6.3">6.3 Why don't you make c-client a shared
337 library?</a></li>
339 <li><a href="#6.4">6.4 Why don't you use iconv() for
340 internationalization support?</a></li>
342 <li><a href="#6.5">6.5 Why is the IMAP server connected to the home
343 directory by default?</a></li>
345 <li><a href="#6.6">6.6 I have a Windows system. Why isn't the server
346 plug and play for me?</a></li>
348 <li><a href="#6.7">6.7 I looked at the UNIX SSL code and saw that you
349 have the SSL data payload size set to 8192 bytes. SSL allows 16K; why
350 aren't you using the full size?</a></li>
352 <li><a href="#6.8">6.8 Why is an mh format INBOX called #mhinbox
353 instead of just INBOX?</a></li>
355 <li><a href="#6.9">6.9 Why don't you support the maildir
356 format?</a></li>
358 <li><a href="#6.10">6.10 Why don't you support the Cyrus
359 format?</a></li>
361 <li><a href="#6.11">6.11 Why is it creating extra forks on my SVR4
362 system?</a></li>
364 <li><a href="#6.12">6.12 Why are you so fussy about the date/time
365 format in the internal <code>"From "</code> line in traditional
366 UNIX mailbox files? My other mail program just considers every line
367 that starts with <code>"From "</code> to be the start of the
368 message.</a></li>
370 <li><a href="#6.13">6.13 Why is traditional UNIX format the default
371 format?</a></li>
373 <li><a href="#6.14">6.14 Why do you write this "DON'T DELETE THIS
374 MESSAGE -- FOLDER INTERNAL DATA" message at the start of traditional
375 UNIX and MMDF format mailboxes?</a></li>
377 <li><a href="#6.15">6.15 Why don't you stash the mailbox metadata in
378 the first real message of the mailbox instead of writing this fake
379 FOLDER INTERNAL DATA message?</a></li>
381 <li><a href="#6.16">6.16 Why aren't "dual-use" mailboxes the
382 default?</a></li>
384 <li><a href="#6.17">6.17 Why do you use ucbcc to build on
385 Solaris?</a></li>
387 <li><a href="#6.18">6.18 Why should I care about some old system with
388 BSD libraries? cc is the right thing on my Solaris system!</a></li>
390 <li><a href="#6.19">6.19 Why do you insist upon writing .lock files
391 in the spool directory?</a></li>
393 <li><a href="#6.20">6.20 Why should I care about compatibility with
394 the past?</a></li>
395 </ul>
396 </li>
398 <li>
399 <a href="#problems">7. Problems and Annoyances</a>
401 <ul>
402 <li><a href="#7.1">7.1 Help! My INBOX is empty! What happened to my
403 messages?</a></li>
405 <li><a href="#7.2">7.2 Help! All my messages in a non-INBOX mailbox
406 have been concatenated into one message which claims to be from me
407 and has a subject of the file name of the mailbox! What's going
408 on?</a></li>
410 <li>
411 <a href="#7.3">7.3 Why do I get the message:
413 <ul>
414 <li>CREATE failed: Can't create mailbox node xxxxxxxxx: File
415 exists</li>
416 </ul>and how do I fix it?</a>
417 </li>
419 <li><a href="#7.4">7.4 Why can't I log in to the server? The user
420 name and password are right!</a></li>
422 <li><a href="#7.5">7.5 Help! My load average is soaring and I see
423 hundreds of POP and IMAP servers, many logged in as the same
424 user!</a></li>
426 <li><a href="#7.6">7.6 Why does mail disappear even though I set
427 "keep mail on server"?</a></li>
429 <li>
430 <a href="#7.7">7.7 Why do I get the message
432 <ul>
433 <li>Moved ##### bytes of new mail to /home/user/mbox from
434 /var/spool/mail/user</li>
435 </ul>and why did this happen?</a>
436 </li>
438 <li><a href="#7.8">7.8 Why isn't it showing the local host name as a
439 fully-qualified domain name?</a></li>
441 <li><a href="#7.9">7.9 Why is the local host name in the
442 From/Sender/Message-ID headers of outgoing mail not coming out as a
443 fully-qualified domain name?</a></li>
445 <li>
446 <a href="#7.10">7.10 What does the message:
448 <ul>
449 <li>Mailbox vulnerable - directory /var/spool/mail must have 1777
450 protection</li>
451 </ul>mean? How can I fix this?</a>
452 </li>
454 <li>
455 <a href="#7.11">7.11 What does the message:
457 <ul>
458 <li>Mailbox is open by another process, access is readonly</li>
459 </ul>mean? How do I fix this?</a>
460 </li>
462 <li>
463 <a href="#7.12">7.12 What does the message:
465 <ul>
466 <li>Can't get write access to mailbox, access is readonly</li>
467 </ul>mean?</a>
468 </li>
470 <li><a href="#7.13">7.13 I set my POP3 client to "delete messages
471 from server" but they never get deleted. What is wrong?</a></li>
473 <li>
474 <a href="#7.14">7.14 What do messages such as:
476 <ul>
477 <li>Message ... UID ... already has UID ...</li>
479 <li>Message ... UID ... less than ...</li>
481 <li>Message ... UID ... greater than last ...</li>
483 <li>Invalid UID ... in message ..., rebuilding UIDs</li>
484 </ul>mean?</a>
485 </li>
487 <li>
488 <a href="#7.15">7.15 What do the error messages:
490 <ul>
491 <li>Unable to read internal header at ...</li>
493 <li>Unable to find CRLF at ...</li>
495 <li>Unable to parse internal header at ...</li>
497 <li>Unable to parse message date at ...</li>
499 <li>Unable to parse message flags at ...</li>
501 <li>Unable to parse message UID at ...</li>
503 <li>Unable to parse message size at ...</li>
505 <li>Last message (at ... ) runs past end of file ...</li>
506 </ul>mean? I am using mbx format.</a>
507 </li>
509 <li>
510 <a href="#7.16">7.16 What do the syslog messages:
512 <ul>
513 <li>imap/tcp server failing (looping)</li>
515 <li>pop3/tcp server failing (looping)</li>
516 </ul>mean? When it happens, the listed service shuts down. How can
517 I fix this?</a>
518 </li>
520 <li>
521 <a href="#7.17">7.17 What does the syslog message:
523 <ul>
524 <li>Mailbox lock file /tmp/.600.1df3 open failure: Permission
525 denied</li>
526 </ul>mean?</a>
527 </li>
529 <li>
530 <a href="#7.18">7.18 What do the syslog messages:
532 <ul>
533 <li>Command stream end of file, while reading line user=...
534 host=...</li>
536 <li>Command stream end of file, while reading char user=...
537 host=...</li>
539 <li>Command stream end of file, while writing text user=...
540 host=...</li>
541 </ul>mean?</a>
542 </li>
544 <li>
545 <a href="#7.19">7.19 Why did my POP or IMAP session suddenly
546 disconnect? The syslog has the message:
548 <ul>
549 <li>Killed (lost mailbox lock) user=... host=...</li>
550 </ul></a>
551 </li>
553 <li><a href="#7.20">7.20 Why does my IMAP client show all the files
554 on the system, recursively from the UNIX root directory?</a></li>
556 <li><a href="#7.21">7.21 Why does my IMAP client show all of my
557 files, recursively from my UNIX home directory?</a></li>
559 <li><a href="#7.22">7.22 Why does my IMAP client show that I have
560 mailboxes named "#mhinbox", "#mh", "#shared", "#ftp", "#news", and
561 "#public"?</a></li>
563 <li><a href="#7.23">7.23 Why does my IMAP client show all my files in
564 my home directory?</a></li>
566 <li><a href="#7.24">7.24 Why is there a long delay before I get
567 connected to the IMAP or POP server, no matter what client I
568 use?</a></li>
570 <li><a href="#7.25">7.25 Why is there a long delay in Pine or any
571 other c-client based application call before I get connected to the
572 IMAP server? The hang seems to be in the c-client mail_open() call. I
573 don't have this problem with any other IMAP client. There is no delay
574 connecting to a POP3 or NNTP server with mail_open().</a></li>
576 <li><a href="#7.26">7.26 Why does a message sometimes get split into
577 two or more messages on my SUN system?</a></li>
579 <li>
580 <a href="#7.27">7.27 Why did my POP or IMAP session suddenly
581 disconnect? The syslog has the message:
583 <ul>
584 <li>Autologout user=<...my user name...> host=<...my
585 imap server...></li>
586 </ul></a>
587 </li>
589 <li>
590 <a href="#7.28">7.28 What does the UNIX error message:
592 <ul>
593 <li>TLS/SSL failure: myserver: SSL negotiation failed</li>
594 </ul>mean?</a>
595 </li>
597 <li>
598 <a href="#7.29">7.29 What does the PC error message:
600 <ul>
601 <li>TLS/SSL failure: myserver: Unexpected TCP input
602 disconnect</li>
603 </ul>mean?</a>
604 </li>
606 <li>
607 <a href="#7.30">7.30 What does the error message:
609 <ul>
610 <li>TLS/SSL failure: myserver: Server name does not match
611 certificate</li>
612 </ul>mean?</a>
613 </li>
615 <li>
616 <a href="#7.31">7.31 What does the UNIX error message:
618 <ul>
619 <li>TLS/SSL failure: myserver: self-signed certificate</li>
620 </ul>mean?</a>
621 </li>
623 <li>
624 <a href="#7.32">7.32 What does the PC error message
626 <ul>
627 <li>TLS/SSL failure: myserver: Self-signed certificate or
628 untrusted authority</li>
629 </ul>mean?</a>
630 </li>
632 <li>
633 <a href="#7.33">7.33 What does the UNIX error message:
635 <ul>
636 <li>TLS/SSL failure: myserver: unable to get local issuer
637 certificate</li>
638 </ul>mean?</a>
639 </li>
641 <li><a href="#7.34">7.34 Why does reading certain messages hang when
642 using Netscape? It works fine with Pine!</a></li>
644 <li><a href="#7.35">7.35 Why does Netscape say that there's a problem
645 with the IMAP server and that I should "Contact your mail server
646 administrator."?</a></li>
648 <li><a href="#7.36">7.36 Why is one user creating huge numbers of
649 IMAP or POP server sessions?</a></li>
651 <li><a href="#7.37">7.37 Why don't I get any new mail notifications
652 from Outlook Express or Outlook after a while?</a></li>
654 <li><a href="#7.38">7.38 Why don't I get any new mail notifications
655 from Entourage?</a></li>
657 <li><a href="#7.39">7.39 Why doesn't Entourage work at all?</a></li>
659 <li><a href="#7.40">7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE)
660 work at all?</a></li>
662 <li><a href="#7.41">7.41 Why can't I connect via SSL to Eudora? It
663 says the connection has been broken, and in the server syslogs I see
664 "Command stream end of file".</a></li>
666 <li><a href="#7.42">7.42 Sheesh. Aren't there <i>any</i> good IMAP
667 clients out there?</a></li>
669 <li>
670 <a href="#7.43">7.43 But wait! PC Pine (or other PC program build
671 with c-client) crashes with the message
673 <ul>
674 <li>incomplete SecBuffer exceeds maximum buffer size</li>
675 </ul>when I use SSL connections. This is a bug in c-client, right?</a>
676 </li>
678 <li><a href="#7.44">7.44 My qpopper users keep on getting the DON'T
679 DELETE THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or
680 IMAP. How can I fix this?</a></li>
682 <li><a href="#7.45">7.45 Help! I installed the servers but I can't
683 connect to them from my client!</a></li>
685 <li>
686 <a href="#7.46">7.46 Why do I get the message
688 <ul>
689 <li>Can not authenticate to SMTP server: 421 SMTP connection went
690 away!</li>
691 </ul>and why did this happen? There was also something about
693 <ul>
694 <li>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</li>
695 </ul></a>
696 </li>
698 <li>
699 <a href="#7.47">7.47 Why do I get the message
701 <ul>
702 <li>SMTP Authentication cancelled</li>
703 </ul>and why did this happen? There was also something about
705 <ul>
706 <li>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</li>
707 </ul></a>
708 </li>
710 <li>
711 <a href="#7.48">7.48 Why do I get the message
713 <ul>
714 <li>Invalid base64 string</li>
715 </ul>when I try to authenticate to a Cyrus server?
716 </li></a>
717 </ul>
718 </li>
720 <li>
721 <a href="#additional">8. Where to Go For Additional Information</a>
723 <ul>
724 <li><a href="#8.1">8.1 Where can I go to ask questions?</a></li>
726 <li><a href="#8.2">8.2 I have some ideas for enhancements to IMAP.
727 Where should I go?</a></li>
729 <li><a href="#8.3">8.3 Where can I read more about IMAP and other
730 email protocols?</a></li>
732 <li><a href="#8.4">8.4 Where can I find out more about setting up and
733 administering an IMAP server?</a></li>
734 </ul>
735 </li>
736 </ul><!--=======START BODY-->
737 <hr>
739 <h2><a name="general">1. General/Software Feature Questions</a></h2>
740 <hr>
742 <p><a name="1.1"><strong>1.1 Can I set up a POP or IMAP server on
743 UNIX/Linux/OSF/etc.?</strong></a></p>
745 <dl>
746 <dd>Yes. Refer to the UNIX specific notes in files CONFIG and BUILD.</dd>
747 </dl>
749 <p><a href="#top">Back to top</a></p>
750 <hr>
752 <p><a name="1.2"><strong>1.2 I am currently using qpopper as my POP3 server on
753 UNIX. Do I need to replace it with ipop3d in order to run
754 imapd?</strong></a></p>
756 <dl>
757 <dd>
758 Not necessarily.
760 <p>Although ipop3d interoperates with imapd better than qpopper, imapd
761 and qpopper will work together. The few qpopper/imapd interoperability
762 issues mostly affect users who use both IMAP and POP3 clients; those
763 users would probably be better served if their POP3 server is
764 ipop3d.</p>
766 <p>If you are happy with qpopper and just want to add imapd, you should
767 do that, and defer a decision on changing qpopper to ipop3d. That way,
768 you can get comfortable with imapd's performance, without changing
769 anything for your qpopper users.</p>
771 <p>Many sites have subsequently decided to change from qpopper to
772 ipop3d in order to get better POP3/IMAP interoperability. If you need
773 to do this, you'll know. There also seems to be a way to make qpopper
774 work better with imapd; see the answer to the <a href="#7.44">My
775 qpopper users keep on getting the DON'T DELETE THIS MESSAGE -- FOLDER
776 INTERNAL DATA if they also use Pine or IMAP. How can I fix this?</a>
777 question.</p>
778 </dd>
779 </dl>
781 <p><a href="#top">Back to top</a></p>
782 <hr>
784 <p><a name="1.3"><strong>1.3 Can I set up a POP or IMAP server on Windows XP,
785 2000, NT, Me, 98, or 95?</strong></a></p>
787 <dl>
788 <dd>
789 Yes. Refer to the NT specific notes in files CONFIG and BUILD. Also,
790 for DOS-based versions of Windows (Windows Me, 98, and 95) you *must*
791 set up CRAM-MD5 authentication, as described in md5.txt.
793 <p>There is no file access control on Windows 9x or Me, so you probably
794 will have to do modifications to env_unix.c to prevent people from
795 hacking others' mail.</p>
797 <p>Note, however, that the server is not plug and play the way it is
798 for UNIX.</p>
799 </dd>
800 </dl>
802 <p><a href="#top">Back to top</a></p>
803 <hr>
805 <p><a name="1.4"><strong>1.4 Can I set up a POP or IMAP server on Windows 3.1 or
806 DOS?</strong></a><br>
807 <a name="1.5"><strong>1.5 Can I set up a POP or IMAP server on
808 Macintosh?</strong></a><br>
809 <a name="1.6"><strong>1.6 Can I set up a POP or IMAP server on
810 VAX/VMS?</strong></a></p>
812 <dl>
813 <dd>Yes, it's just a small matter of programming.</dd>
814 </dl>
816 <p><a href="#top">Back to top</a></p>
817 <hr>
819 <p><a name="1.7"><strong>1.7 Can I set up a POP or IMAP server on
820 TOPS-20?</strong></a></p>
822 <dl>
823 <dd>
824 You have a TOPS-20 system? Cool.
826 <p>If IMAP2 (RFC 1176) is good enough for you, you can use MAPSER which
827 is about the ultimate gonzo pure TOPS-20 extended addressing assembly
828 language program. Unfortunately, IMAP2 is barely good enough for Pine
829 these days, and most other IMAP clients won't work with IMAP2 at all.
830 Maybe someone will hack MAPSER to do IMAP4rev1 some day.</p>
832 <p>We don't know if anyone wrote a POP3 server for TOPS-20. There
833 definitely was a POP2 server once upon a time.</p>
835 <p>Or you can port the POP and IMAP server from this IMAP toolkit to
836 it. All that you need for a first stab is to port the MTX driver.
837 That'll probably be just a couple of hours of hacking.</p>
838 </dd>
839 </dl>
841 <p><a href="#top">Back to top</a></p>
842 <hr>
844 <p><a name="1.8"><strong>1.8 Are hierarchical mailboxes
845 supported?</strong></a><br>
846 <a name="1.9"><strong>1.9 Are "dual-use" mailboxes
847 supported?</strong></a><br>
848 <a name="1.10"><strong>1.10 Can I have a mailbox that has both messages and
849 sub-mailboxes?</strong></a></p>
851 <dl>
852 <dd>
853 Yes. However, there is one important caveat.
855 <p>Some mailbox formats, including the default which is the traditional
856 UNIX mailbox format, are stored as a single file containing all the
857 messages. UNIX does not permit a name in the filesystem to be both a
858 file and a directory; consequently you can not have a sub-mailbox
859 within a mailbox that is in one of these formats.</p>
861 <p>This is not a limitation of the software; this is a limitation of
862 UNIX. For example, there are mailbox formats in which the name is a
863 directory and each message is a file within that directory; these
864 formats support sub-mailboxes within such mailboxes. However, for
865 technical reasons, the "flat file" formats are generally preferred
866 since they perform better. Read imap-2007/docs/formats.txt for more
867 information on this topic.</p>
869 <p>It is always permissible to create a directory that is not a
870 mailbox, and have sub-mailboxes under it. The easiest way to create a
871 directory is to create a new mailbox inside a directory that doesn't
872 already exist. For example, if you create "Mail/testbox" on UNIX, the
873 directory "Mail/" will automatically be created and then the mailbox
874 "testbox" will be created as a sub-mailbox of "Mail/".</p>
876 <p>It is also possible to create the name "Mail/" directly. Check the
877 documentation for your client software to see how to do this with that
878 software.</p>
880 <p>Of course, on Windows systems you would use "\" instead of "/".</p>
881 </dd>
882 </dl>
884 <p><a href="#top">Back to top</a></p>
885 <hr>
887 <p><a name="1.11"><strong>1.11 What is the difference between "mailbox" and
888 "folder"?</strong></a></p>
890 <dl>
891 <dd>
892 The term "mailbox" is IMAP-speak for what a lot of software calls a
893 "folder" or a "mail folder". However, "folder" is often used in other
894 contexts to refer to a directory, for example, in the graphic user
895 interface on both Windows and Macintosh.
897 <p>A "mailbox" is specifically defined as a named object that contains
898 messages. It is not required to be capable of containing other types of
899 objects including other mailboxes; although some mailbox formats will
900 permit this.</p>
902 <p>In IMAP-speak, a mailbox which can not contain other mailboxes is
903 called a "no-inferiors mailbox". Similarly, a directory which can not
904 contain messages is not a mailbox and is called a "no-select name".</p>
905 </dd>
906 </dl>
908 <p><a href="#top">Back to top</a></p>
909 <hr>
911 <p><a name="1.12"><strong>1.12 What is the status of
912 internationalization?</strong></a></p>
914 <dl>
915 <dd>
916 The IMAP toolkit is partially internationalized and multilingualized.
918 <p>Searching is supported in the following charsets: US-ASCII, UTF-8,
919 ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6,
920 ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11,
921 ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U
922 (alias KOI8-RU), TIS-620, VISCII, ISO-2022-JP, ISO-2022-KR,
923 ISO-2022-CN, ISO-2022-JP-1, ISO-2022-JP-2, GB2312 (alias CN-GB),
924 CN-GB-12345, BIG5 (alias CN-BIG5), EUC-JP, EUC-KR, Shift_JIS,
925 Shift-JIS, KS_C_5601-1987, KS_C_5601-1992, WINDOWS_874, WINDOWS-1250,
926 WINDOWS-1251, WINDOWS-1252, WINDOWS-1253, WINDOWS-1254, WINDOWS-1255,
927 WINDOWS-1256, WINDOWS-1257, WINDOWS-1258.</p>
929 <p>All ISO-2022-?? charsets are treated identically, and support ASCII,
930 JIS Roman, hankaku katakana, ISO-8859-[1 - 10], TIS, GB 2312, JIS X
931 0208, JIS X 0212, KSC 5601, and planes 1 and 2 of CNS 11643.</p>
933 <p>EUC-JP includes support for JIS X 0212 and hankaku katakana.</p>
935 <p>c-client library support also exists to convert text in any of the
936 above charsets into Unicode, including headers with MIME
937 encoded-words.</p>
939 <p>There is no support for localization (e.g. non-English error
940 messages) at the present time, but such support is planned.</p>
941 </dd>
942 </dl>
944 <p><a href="#top">Back to top</a></p>
945 <hr>
947 <p><a name="1.13"><strong>1.13 Can I use SSL?</strong></a></p>
949 <dl>
950 <dd>Yes. See the answer to the <a href="#3.5">How do I configure SSL?</a>
951 question.</dd>
952 </dl>
954 <p><a href="#top">Back to top</a></p>
955 <hr>
957 <p><a name="1.14"><strong>1.14 Can I use TLS and the STARTTLS
958 facility?</strong></a></p>
960 <dl>
961 <dd>Yes. See the answer to the <a href="#3.6">How do I configure TLS and
962 the STARTTLS facility?</a> question.</dd>
963 </dl>
965 <p><a href="#top">Back to top</a></p>
966 <hr>
968 <p><a name="1.15"><strong>1.15 Can I use CRAM-MD5
969 authentication?</strong></a></p>
971 <dl>
972 <dd>Yes. See the answer to the <a href="#3.8">How do I configure CRAM-MD5
973 authentication?</a> question.</dd>
974 </dl>
976 <p><a href="#top">Back to top</a></p>
977 <hr>
979 <p><a name="1.16"><strong>1.16 Can I use APOP authentication?</strong></a></p>
981 <dl>
982 <dd>
983 Yes. See the <a href="#3.9">How do I configure APOP authentication?</a>
984 question.
986 <p>Note that there is no client support for APOP authentication.</p>
987 </dd>
988 </dl>
990 <p><a href="#top">Back to top</a></p>
991 <hr>
993 <p><a name="1.17"><strong>1.17 Can I use Kerberos V5?</strong></a></p>
995 <dl>
996 <dd>Yes. See the answer to the <a href="#3.10">How do I configure
997 Kerberos V5?</a> question.</dd>
998 </dl>
1000 <p><a href="#top">Back to top</a></p>
1001 <hr>
1003 <p><a name="1.18"><strong>1.18 Can I use PAM for plaintext
1004 passwords?</strong></a></p>
1006 <dl>
1007 <dd>Yes. See the answer to the <a href="#3.11">How do I configure PAM for
1008 plaintext passwords?</a> question.</dd>
1009 </dl>
1011 <p><a href="#top">Back to top</a></p>
1012 <hr>
1014 <p><a name="1.19"><strong>1.19 Can I use Kerberos 5 for plaintext
1015 passwords?</strong></a></p>
1017 <dl>
1018 <dd>Yes. See the answer to the <a href="#3.13">How do I configure
1019 Kerberos 5 for plaintext passwords?</a> question.</dd>
1020 </dl>
1022 <p><a href="#top">Back to top</a></p>
1023 <hr>
1025 <p><a name="1.20"><strong>1.20 Can I use AFS for plaintext
1026 passwords?</strong></a></p>
1028 <dl>
1029 <dd>Yes. See the answer to the <a href="#3.14">How do I configure AFS for
1030 plaintext passwords?</a> question.</dd>
1031 </dl>
1033 <p><a href="#top">Back to top</a></p>
1034 <hr>
1036 <p><a name="1.21"><strong>1.21 Can I use DCE for plaintext
1037 passwords?</strong></a></p>
1039 <dl>
1040 <dd>Yes. See the answer to the <a href="#3.15">How do I configure DCE for
1041 plaintext passwords?</a> question.</dd>
1042 </dl>
1044 <p><a href="#top">Back to top</a></p>
1045 <hr>
1047 <p><a name="1.22"><strong>1.22 Can I use the CRAM-MD5 database for plaintext
1048 passwords?</strong></a></p>
1050 <dl>
1051 <dd>Yes. See the answer to the <a href="#3.16">How do I configure the
1052 CRAM-MD5 database for plaintext passwords?</a> question.</dd>
1053 </dl>
1055 <p><a href="#top">Back to top</a></p>
1056 <hr>
1058 <p><a name="1.23"><strong>1.23 Can I disable plaintext
1059 passwords?</strong></a></p>
1061 <dl>
1062 <dd>Yes. See the answer to the <a href="#3.17">How do I disable plaintext
1063 passwords?</a> question.</dd>
1064 </dl>
1066 <p><a href="#top">Back to top</a></p>
1067 <hr>
1069 <p><a name="1.24"><strong>1.24 Can I disable plaintext passwords on unencrypted
1070 sessions, but allow them on encrypted sessions?</strong></a></p>
1072 <dl>
1073 <dd>Yes. See the answer to the <a href="#3.18">How do I disable plaintext
1074 passwords on unencrypted sessions, but allow them in SSL or TLS
1075 sessions?</a> question.</dd>
1076 </dl>
1078 <p><a href="#top">Back to top</a></p>
1079 <hr>
1081 <p><a name="1.25"><strong>1.25 Can I use virtual hosts?</strong></a></p>
1083 <dl>
1084 <dd>Yes. See the answer to the <a href="#3.19">How do I configure virtual
1085 hosts?</a> question.</dd>
1086 </dl>
1088 <p><a href="#top">Back to top</a></p>
1089 <hr>
1091 <p><a name="1.26"><strong>1.26 Can I use RPOP authentication?</strong></a></p>
1093 <dl>
1094 <dd>There is no support for RPOP authentication.</dd>
1095 </dl>
1097 <p><a href="#top">Back to top</a></p>
1098 <hr>
1100 <p><a name="1.27"><strong>1.27 Can I use Kerberos V4?</strong></a></p>
1102 <dl>
1103 <dd>
1104 Kerberos V4 is not supported. Kerberos V4 client-only contributed code
1105 is available in
1106 <pre>
1107 <a href=
1108 "ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z">ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z
1109 </a>
1110 </pre>This is a patchkit which must be applied to the IMAP toolkit according
1111 to the instructions in the patchkit's README. We can not promise that this
1112 code works.
1113 </dd>
1114 </dl>
1116 <p><a href="#top">Back to top</a></p>
1117 <hr>
1119 <p><a name="1.28"><strong>1.28 Is there support for S/Key or
1120 OTP?</strong></a></p>
1122 <dl>
1123 <dd>There is currently no support for S/Key or OTP. There may be an OTP
1124 SASL authenticator available from third parties.</dd>
1125 </dl>
1127 <p><a href="#top">Back to top</a></p>
1128 <hr>
1130 <p><a name="1.29"><strong>1.29 Is there support for NTLM or
1131 SPA?</strong></a></p>
1133 <dl>
1134 <dd>
1135 There is currently no support for NTLM or SPA, nor are there any plans
1136 to add such support. In general, I avoid vendor-specific mechanisms. I
1137 also believe that these mechanisms are being deprecated by their
1138 vendor.
1140 <p>There may be an NTLM SASL authenticator available from third
1141 parties.</p>
1142 </dd>
1143 </dl>
1145 <p><a href="#top">Back to top</a></p>
1146 <hr>
1148 <p><a name="1.30"><strong>1.30 Is there support for mh?</strong></a></p>
1150 <dl>
1151 <dd>
1152 Yes, but only as a legacy format. Your mh format INBOX is accessed by
1153 the name "#mhinbox", and all other mh format mailboxes are accessed by
1154 prefixing "#mh/" to the name, e.g. "#mh/foo". The mh support uses the
1155 "Path:" entry in your .mh_profile file to identify the root directory
1156 of your mh format mailboxes.
1158 <p>Non-legacy use of mh format is not encouraged. There is no support
1159 for permanent flags or unique identifiers; furthermore there are known
1160 severe performance problems with the mh format.</p>
1161 </dd>
1162 </dl>
1164 <p><a href="#top">Back to top</a></p>
1165 <hr>
1167 <p><a name="1.31"><strong>1.31 Is there support for qmail and the maildir
1168 format?</strong></a></p>
1170 <dl>
1171 <dd>There is no support for qmail or the maildir format in our
1172 distribution, nor are there any plans to add such support. Maildir
1173 support may be available from third parties.</dd>
1174 </dl>
1176 <p><a href="#top">Back to top</a></p>
1177 <hr>
1179 <p><a name="1.32"><strong>1.32 Is there support for the Cyrus mailbox
1180 format?</strong></a></p>
1182 <dl>
1183 <dd>No.</dd>
1184 </dl>
1186 <p><a href="#top">Back to top</a></p>
1187 <hr>
1189 <p><a name="1.33"><strong>1.33 Is this software Y2K compliant?</strong></a></p>
1191 <dl>
1192 <dd>Please read the files Y2K and calendar.txt.</dd>
1193 </dl>
1195 <p><a href="#top">Back to top</a></p>
1196 <hr>
1198 <p><br></p>
1200 <h2><a name="requirements">2. What Do I Need to Build This Software?</a></h2>
1201 <hr>
1203 <p><a name="2.1"><strong>2.1 What do I need to build this software with SSL on
1204 UNIX?</strong></a></p>
1206 <dl>
1207 <dd>You need to build and install OpenSSL first.</dd>
1208 </dl>
1210 <p><a href="#top">Back to top</a></p>
1211 <hr>
1213 <p><a name="2.2"><strong>2.2 What do I need to build this software with Kerberos
1214 V on UNIX?</strong></a></p>
1216 <dl>
1217 <dd>You need to build and install MIT Kerberos first.</dd>
1218 </dl>
1220 <p><a href="#top">Back to top</a></p>
1221 <hr>
1223 <p><a name="2.3"><strong>2.3 What do I need to use a C++ compiler with this
1224 software to build my own application?</strong></a></p>
1226 <dl>
1227 <dd>
1228 If you are building an application using the c-client library, use the
1229 new c-client.h file instead of including the other include files. It
1230 seems that c-client.h should define away all the troublesome names that
1231 conflict with C++.
1233 <p>If you use gcc, you may need to use -fno-operator-names as well.</p>
1234 </dd>
1235 </dl>
1237 <p><a href="#top">Back to top</a></p>
1238 <hr>
1240 <p><a name="2.4"><strong>2.4 What do I need to build this software on
1241 Windows?</strong></a></p>
1243 <dl>
1244 <dd>
1245 You need Microsoft Visual C++ 6.0, Visual C++ .NET, or Visual C# .NET
1246 (which you can buy from any computer store), along with the Microsoft
1247 Platform SDK (which you can download from Microsoft's web site).
1249 <p>You do not need to install the entire Platform SDK; it suffices to
1250 install just the Core SDK and the Internet Development SDK.</p>
1251 </dd>
1252 </dl>
1254 <p><a href="#top">Back to top</a></p>
1255 <hr>
1257 <p><a name="2.5"><strong>2.5 What do I need to build this software on
1258 DOS?</strong></a></p>
1260 <dl>
1261 <dd>It's been several years since we last attempted to do this. At the
1262 time, we used Microsoft C.</dd>
1263 </dl>
1265 <p><a href="#top">Back to top</a></p>
1266 <hr>
1268 <p><a name="2.6"><strong>2.6 Can't I use Borland C to build this software on the
1269 PC?</strong></a></p>
1271 <dl>
1272 <dd>Probably not. If you know otherwise, please let us know.</dd>
1273 </dl>
1275 <p><a href="#top">Back to top</a></p>
1276 <hr>
1278 <p><a name="2.7"><strong>2.7 What do I need to build this software on the
1279 Mac?</strong></a></p>
1281 <dl>
1282 <dd>It has been several years since we last attempted to do this. At the
1283 time, we used Symantec THINK C; but today you'll need a C compiler which
1284 allows segments to be more than 32K.</dd>
1285 </dl>
1287 <p><a href="#top">Back to top</a></p>
1288 <hr>
1290 <p><a name="2.8"><strong>2.8 What do I need to build this software on
1291 VMS?</strong></a></p>
1293 <dl>
1294 <dd>You need the VMS C compiler, and either the Multinet or Netlib
1295 TCP.</dd>
1296 </dl>
1298 <p><a href="#top">Back to top</a></p>
1299 <hr>
1301 <p><a name="2.9"><strong>2.9 What do I need to build this software on
1302 TOPS-20?</strong></a></p>
1304 <dl>
1305 <dd>You need the TOPS-20 KCC compiler.</dd>
1306 </dl>
1308 <p><a href="#top">Back to top</a></p>
1309 <hr>
1311 <p><a name="2.10"><strong>2.10 What do I need to build this software on Amiga or
1312 OS/2?</strong></a></p>
1314 <dl>
1315 <dd>We don't know.</dd>
1316 </dl>
1318 <p><a href="#top">Back to top</a></p>
1319 <hr>
1321 <p><a name="2.11"><strong>2.11 What do I need to build this software on Windows
1322 CE?</strong></a></p>
1324 <dl>
1325 <dd>This port is incomplete. Someone needs to finish it.</dd>
1326 </dl>
1328 <p><a href="#top">Back to top</a></p>
1329 <hr>
1331 <p><br></p>
1333 <h2><a name="build">3. Build and Configuration Questions</a></h2>
1334 <hr>
1336 <p><a name="3.1"><strong>3.1 How do I configure the IMAP and POP servers on
1337 UNIX?</strong></a><br>
1338 <a name="3.2"><strong>3.2 I built and installed the servers according to the
1339 BUILD instructions. It can't be that easy. Don't I need to write a
1340 config file?</strong></a></p>
1342 <dl>
1343 <dd>
1344 For ordinary "vanilla" UNIX systems, this software is plug and play;
1345 just build it, install it, and you're done. If you have a modified
1346 system, then you may want to do additional work; most of this is to a
1347 single source code file (env_unix.c on UNIX systems). Read the file
1348 CONFIG for more details.
1350 <p>Yes, it's that easy. There are some additional options, such as SSL
1351 or Kerberos, which require additional steps to build. See the relevant
1352 questions below.</p>
1353 </dd>
1354 </dl>
1356 <p><a href="#top">Back to top</a></p>
1357 <hr>
1359 <p><a name="3.3"><strong>3.3 How do I make the IMAP and POP servers look for
1360 INBOX at some place other than the mail spool
1361 directory?</strong></a><br>
1362 <a name="3.4"><strong>3.4 How do I make the IMAP server look for secondary
1363 folders at some place other than the user's home
1364 directory?</strong></a></p>
1366 <dl>
1367 <dd>Please read the file CONFIG for discussion of this and other
1368 issues.</dd>
1369 </dl>
1371 <p><a href="#top">Back to top</a></p>
1372 <hr>
1374 <p><a name="3.5"><strong>3.5 How do I configure SSL?</strong></a><br>
1375 <a name="3.6"><strong>3.6 How do I configure TLS and the STARTTLS
1376 facility?</strong></a></p>
1378 <dl>
1379 <dd>
1380 imap-2007 supports SSL and TLS client functionality on UNIX and 32-bit
1381 Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS server
1382 functionality on UNIX for IMAP and POP3.
1384 <p>UNIX SSL build requires that a third-party software package,
1385 OpenSSL, be installed on the system first. Read imap-2007/docs/SSLBUILD
1386 for more information.</p>
1388 <p>SSL is supported via undocumented Microsoft interfaces in Windows 9x
1389 and NT4; and via standard interfaces in Windows 2000, Windows
1390 Millenium, and Windows XP.</p>
1391 </dd>
1392 </dl>
1394 <p><a href="#top">Back to top</a></p>
1395 <hr>
1397 <p><a name="3.7"><strong>3.7 How do I build/install OpenSSL and obtain/create
1398 certificates for use with SSL?</strong></a></p>
1400 <dl>
1401 <dd>If you need help in doing this, try the contacts mentioned in the
1402 OpenSSL README. We do not offer support for OpenSSL or certificates.</dd>
1403 </dl>
1405 <p><a href="#top">Back to top</a></p>
1406 <hr>
1408 <p><a name="3.8"><strong>3.8 How do I configure CRAM-MD5
1409 authentication?</strong></a><br>
1410 <a name="3.9"><strong>3.9 How do I configure APOP
1411 authentication?</strong></a></p>
1413 <dl>
1414 <dd>
1415 CRAM-MD5 authentication is enabled in the IMAP and POP3 client code on
1416 all platforms. Read md5.txt to learn how to set up CRAM-MD5 and APOP
1417 authentication on UNIX and NT servers.
1419 <p>There is no support for APOP client authentication.</p>
1420 </dd>
1421 </dl>
1423 <p><a href="#top">Back to top</a></p>
1424 <hr>
1426 <p><a name="3.10"><strong>3.10 How do I configure Kerberos V5?</strong></a></p>
1428 <dl>
1429 <dd>
1430 imap-2007 supports client and server functionality on UNIX and 32-bit
1431 Windows.
1433 <p>Kerberos V5 is supported by default in Windows 2000 builds:</p>
1434 <pre>
1435 nmake -f makefile.w2k
1436 </pre>
1438 <p>Other builds require that a third-party Kerberos package, e.g. MIT
1439 Kerberos, be installed on the system first.</p>
1441 <p>To build with Kerberos V5 on UNIX, include EXTRAAUTHENTICATORS=gss
1442 in the make command line, e.g.</p>
1443 <pre>
1444 make lnp EXTRAAUTHENTICATORS=gss
1445 </pre>
1447 <p>To build with Kerberos V5 on Windows 9x, Windows Millenium, and NT4,
1448 use the "makefile.ntk" file instead of "makefile.nt":</p>
1449 <pre>
1451 nmake -f makefile.ntk
1452 </pre>
1453 </dd>
1454 </dl>
1456 <p><a href="#top">Back to top</a></p>
1457 <hr>
1459 <p><a name="3.11"><strong>3.11 How do I configure PAM for plaintext
1460 passwords?</strong></a></p>
1462 <dl>
1463 <dd>
1464 On Linux systems, use the lnp port, e.g.
1465 <pre>
1466 make lnp
1468 </pre>On Solaris systems and other systems with defective PAM
1469 implementations, build with PASSWDTYPE=pmb, e.g.
1470 <pre>
1471 make sol PASSWDTYPE=pmb
1472 </pre>On all other systems, build with PASSWDTYPE=pam, e.g
1473 <pre>
1474 make foo PASSWDTYPE=pam
1475 </pre>If you build with PASSWDTYPE=pam and authentication does not work, try
1476 rebuilding (after a "make clean") with PASSWDTYPE=pmb.
1477 </dd>
1478 </dl>
1480 <p><a href="#top">Back to top</a></p>
1481 <hr>
1483 <p><a name="3.12"><strong>3.12 It looks like all I have to do to make the server
1484 use Kerberos is to build with PAM on my Linux system, and set it up in
1485 PAM for Kerberos passwords. Right?</strong></a></p>
1487 <dl>
1488 <dd>
1489 Yes and no.
1491 <p>Doing this will make plaintext password authentication use the
1492 Kerberos password instead of the /etc/passwd password.</p>
1494 <p>However, this will NOT give you Kerberos-secure authentication. See
1495 the answer to the <a href="#3.10">How do I configure Kerberos V5?</a>
1496 question for how to build with Kerberos-secure authentication.</p>
1497 </dd>
1498 </dl>
1500 <p><a href="#top">Back to top</a></p>
1501 <hr>
1503 <p><a name="3.13"><strong>3.13 How do I configure Kerberos 5 for plaintext
1504 passwords?</strong></a></p>
1506 <dl>
1507 <dd>
1508 Build with PASSWDTYPE=gss, e.g.
1509 <pre>
1510 make sol PASSWDTYPE=gss
1511 </pre>However, this will NOT give you Kerberos-secure authentication. See the
1512 answer to the <a href="#3.10">How do I configure Kerberos V5?</a> question
1513 for how to build with Kerberos-secure authentication.
1514 </dd>
1515 </dl>
1517 <p><a href="#top">Back to top</a></p>
1518 <hr>
1520 <p><a name="3.14"><strong>3.14 How do I configure AFS for plaintext
1521 passwords?</strong></a></p>
1523 <dl>
1524 <dd>
1525 Build with PASSWDTYPE=afs, e.g
1526 <pre>
1527 make sol PASSWDTYPE=afs
1529 </pre>
1530 </dd>
1531 </dl>
1533 <p><a href="#top">Back to top</a></p>
1534 <hr>
1536 <p><a name="3.15"><strong>3.15 How do I configure DCE for plaintext
1537 passwords?</strong></a></p>
1539 <dl>
1540 <dd>
1541 Build with PASSWDTYPE=dce, e.g
1542 <pre>
1543 make sol PASSWDTYPE=dce
1544 </pre>
1545 </dd>
1546 </dl>
1548 <p><a href="#top">Back to top</a></p>
1549 <hr>
1551 <p><a name="3.16"><strong>3.16 How do I configure the CRAM-MD5 database for
1552 plaintext passwords?</strong></a></p>
1554 <dl>
1555 <dd>
1556 The CRAM-MD5 password database is automatically used for plaintext
1557 password if it exists.
1559 <p>Note that this is NOT CRAM-MD5-secure authentication. You probably
1560 want to consider disabling plaintext passwords for non-SSL/TLS
1561 sessions. See the next two questions.</p>
1562 </dd>
1563 </dl>
1565 <p><a href="#top">Back to top</a></p>
1566 <hr>
1568 <p><a name="3.17"><strong>3.17 How do I disable plaintext
1569 passwords?</strong></a></p>
1571 <dl>
1572 <dd>
1573 Server-level plaintext passwords can be disabled by setting
1574 PASSWDTYPE=nul, e.g.
1575 <pre>
1576 make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
1577 </pre>Note that you must have a CRAM-MD5 database installed or specify at
1578 least one EXTRAAUTHENTICATOR, otherwise it will not be possible to log in to
1579 the server.
1581 <p>When plaintext passwords are disabled, the IMAP server will
1582 advertise the LOGINDISABLED capability and the POP3 server will not
1583 advertise the USER capability.</p>
1584 </dd>
1585 </dl>
1587 <p><a href="#top">Back to top</a></p>
1589 <p><a name="3.18"><strong>3.18 How do I disable plaintext passwords on
1590 unencrypted sessions, but allow them in SSL or TLS
1591 sessions?</strong></a></p>
1593 <dl>
1594 <dd>
1595 <p>Do not set PASSWDTYPE=nul or SSLTYPE=unix. Set SSLTYPE=nopwd
1596 instead, e.g.</p>
1597 <pre>
1598 make lnx SSLTYPE=nopwd
1599 </pre>
1601 <p>When plaintext passwords are disabled, the IMAP server will
1602 advertise the LOGINDISABLED capability and the POP3 server will not
1603 advertise the USER capability.</p>
1605 <p>Plaintext passwords will always be enabled in SSL sessions; the IMAP
1606 server will not advertise the LOGINDISABLED capability and the POP3
1607 server will advertise the USER capability.</p>
1609 <p>If the client does a successful start-TLS in a non-SSL session,
1610 plaintext passwords will be enabled, and a new CAPABILITY or CAPA
1611 command (which is required after start-TLS) will show the effect as in
1612 SSL sessions.</p>
1613 </dd>
1614 </dl>
1616 <p><a href="#top">Back to top</a></p>
1617 <hr>
1619 <p><a name="3.19"><strong>3.19 How do I configure virtual
1620 hosts?</strong></a></p>
1622 <dl>
1623 <dd>
1624 This is automatic, but with certain restrictions.
1626 <p>The most important one is that each virtual host must have its own
1627 IP address; otherwise the server has no way of knowing which virtual
1628 host is desired.</p>
1630 <p>As distributed, the software uses a global password file; hence user
1631 "fred" on one virtual host is "fred" on all virtual hosts. You may want
1632 to modify the checkpw() routine to implement some other policy (e.g.
1633 separate password files).</p>
1635 <p>Note that the security model assumes that all users have their own
1636 unique UNIX UID number. So if you use separate password files you
1637 should make certain that the UID numbers do not overlap between
1638 different files.</p>
1640 <p>More advanced virtual host support may be available as patches from
1641 third parties.</p>
1642 </dd>
1643 </dl>
1645 <p><a href="#top">Back to top</a></p>
1646 <hr>
1648 <p><a name="3.20"><strong>3.20 Why do I get compiler warning messages such
1649 as:</strong></a></p>
1650 <pre>
1651 passing arg 3 of `scandir' from incompatible pointer type
1652 Pointers are not assignment-compatible.
1653 Argument #4 is not the correct type.
1655 </pre>
1657 <p><strong>during the build?</strong></p>
1659 <dl>
1660 <dd>
1661 You can safely ignore these messages.
1663 <p>Over the years, the prototype for scandir() has changed, and thus is
1664 variant across different UNIX platforms. In particular, the definitions
1665 of the third argument (type select_t) and fourth argument (type
1666 compar_t) have changed over the years, the issue being whether or not
1667 the arguments to the functions pointed to by these function pointers
1668 are of type const or not.</p>
1670 <p>The way that c-client calls scandir() will tend to generate these
1671 compiler warnings on newer systems such as Linux; however, it will
1672 still build. The problem with fixing the call is that then it won't
1673 build on older systems.</p>
1674 </dd>
1675 </dl>
1677 <p><a href="#top">Back to top</a></p>
1678 <hr>
1680 <p><a name="3.21"><strong>3.21 Why do I get compiler warning messages such
1681 as</strong></a></p>
1682 <pre>
1683 Operation between types "void(*)(int)" and "void*" is not allowed.
1684 Function argument assignment between types "void*" and "void(*)(int)" is not allowed.
1685 Pointers are not assignment-compatible.
1686 Argument #5 is not the correct type.
1687 </pre>
1689 <p><strong>during the build?</strong></p>
1691 <dl>
1692 <dd>
1693 You can safely ignore these messages.
1695 <p>All known systems have no problem with casting a function pointer
1696 to/from a void* pointer, certain C compilers issue a compiler
1697 diagnostic because this facility is listed as a "Common extension" by
1698 the C standard:</p>
1699 <pre>
1700 K.5.7 Function pointer casts
1701 [#1] A pointer to an object or to void may be cast to a pointer
1702 to a function, allowing data to be invoked as a function (6.3.4).
1703 [#2] A pointer to a function may be cast to a pointer to an
1704 object or to void, allowing a function to be inspected or
1705 modified (for example, by a debugger) (6.3.4).
1707 </pre>It may be just a "common extension", but this facility is relied upon
1708 heavily by c-client.
1709 </dd>
1710 </dl>
1712 <p><a href="#top">Back to top</a></p>
1713 <hr>
1715 <p><a name="3.22"><strong>3.22 Why do I get linker warning messages such
1716 as:</strong></a></p>
1717 <pre>
1718 mtest.c:515: the `gets' function is dangerous and should not be used.
1719 </pre>
1721 <p><strong>during the build? Isn't this a security bug?</strong></p>
1723 <dl>
1724 <dd>
1725 You can safely ignore this message.
1727 <p>Certain linkers, most notably on Linux, give this warning message.
1728 It is indeed true that the traditional gets() function is not a safe
1729 one.</p>
1731 <p>However, the mtest program is only a demonstration program, a model
1732 of a very basic application program using c-client. It is not something
1733 that you would install, much less run in any security-sensitive
1734 context.</p>
1736 <p>mtest has numerous other shortcuts that you wouldn't want to do in a
1737 real application program.</p>
1739 <p>The only "security bug" with mtest would be if it was run by some
1740 script in a security-sensitive context, but mtest isn't particularly
1741 useful for such purposes. If you wanted to write a script to automate
1742 some email task using c-client, you'd be better off using imapd instead
1743 of mtest.</p>
1745 <p>mtest only has two legitimate uses. It's a useful testbed for me
1746 when debugging new versions of c-client, and it's useful as a model for
1747 someone writing a simple c-client application to see how the various
1748 calls work.</p>
1750 <p>By the way, if you need a more advanced example of c-client
1751 programming than mtest (and you probably will), I recommend that you
1752 look at the source code for imapd and Pine.</p>
1753 </dd>
1754 </dl>
1756 <p><a href="#top">Back to top</a></p>
1757 <hr>
1759 <p><a name="3.23"><strong>3.23 Why do I get linker warning messages such
1760 as:</strong></a></p>
1761 <pre>
1762 auth_ssl.c:92: the `tmpnam' function is dangerous and should not be used.
1763 </pre>
1765 <p><strong>during the build? Isn't this a security bug?</strong></p>
1767 <dl>
1768 <dd>
1769 You can safely ignore this message.
1771 <p>Certain linkers, most notably on Linux, give this warning message,
1772 based upon two known issues with tmpnam():</p>
1774 <dl>
1775 <dd>there can be a buffer overflow if an inadequate buffer is
1776 allocated.</dd>
1778 <dd>there can be a timing race caused by certain incautious usage of
1779 the return value.</dd>
1780 </dl>
1782 <p>Neither of these issues applies in the particular use that is made
1783 of tmpnam(). More importantly, the tmpnam() call is never executed on
1784 Linux systems.</p>
1785 </dd>
1786 </dl>
1788 <p><a href="#top">Back to top</a></p>
1789 <hr>
1791 <p><a name="3.24"><strong>3.24 OK, suppose I see a warning message about a
1792 function being "dangerous and should not be used" for something other
1793 than this gets() or tmpnam() call?</strong></a></p>
1795 <dl>
1796 <dd>Please forward the details for investigation.</dd>
1797 </dl>
1799 <p><a href="#top">Back to top</a></p>
1800 <hr>
1802 <p><br></p>
1804 <h2><a name="operation">4. Operational Questions</a></h2>
1805 <hr>
1807 <p><a name="4.1"><strong>4.1 How can I enable anonymous IMAP
1808 logins?</strong></a></p>
1810 <dl>
1811 <dd>Create the file /etc/anonymous.newsgroups. At the present time, this
1812 file should be empty. This will permit IMAP logins as anonymous as well
1813 as the ANONYMOUS SASL authenticator. Anonymous users have access to
1814 mailboxes in the #news., #ftp/, and #public/ namespaces only.</dd>
1815 </dl>
1817 <p><a href="#top">Back to top</a></p>
1818 <hr>
1820 <p><a name="4.2"><strong>4.2 How do I set up an alert message that each IMAP
1821 user will see?</strong></a></p>
1823 <dl>
1824 <dd>Create the file /etc/imapd.alert with the text of the message. This
1825 text should be kept to one line if possible. Note that this will cause an
1826 alert to every IMAP user every time they initiate an IMAP session, so it
1827 should only be used for critical messages.</dd>
1828 </dl>
1830 <p><a href="#top">Back to top</a></p>
1831 <hr>
1833 <p><a name="4.3"><strong>4.3 How does the c-client library choose which of its
1834 several mechanisms to use to establish an IMAP connection to the server?
1835 I noticed that it can connect on port 143, port 993, via rsh, and via
1836 ssh.</strong></a></p>
1838 <dl>
1839 <dd>
1840 c-client chooses how to establish an IMAP connection via the following
1841 rules:
1843 <ul>
1844 <li>If /ssl is specified, use an SSL connection. Fail otherwise.</li>
1846 <li>Else if client is a UNIX system and "ssh server exec /etc/rimapd"
1847 works, use that</li>
1849 <li>Else if /tryssl is specified and an SSL connection works, use
1850 that.</li>
1852 <li>Else if client is a UNIX system and "rsh server exec /etc/rimapd"
1853 works, use that.</li>
1855 <li>Else use a non-SSL connection.</li>
1856 </ul>
1857 </dd>
1858 </dl>
1860 <p><a href="#top">Back to top</a></p>
1861 <hr>
1863 <p><a name="4.4"><strong>4.4 I am using a TLS-capable IMAP server, so I don't
1864 need to use /ssl to get encryption. However, I want to be certain that
1865 my session is TLS encrypted before I send my password. How to I do
1866 this?</strong></a></p>
1868 <dl>
1869 <dd>Use the /tls option in the mailbox name. This will cause an error
1870 message and the connection to fail if the server does not negotiate
1871 STARTTLS.</dd>
1872 </dl>
1874 <p><a href="#top">Back to top</a></p>
1875 <hr>
1877 <p><a name="4.5"><strong>4.5 How do I use one of the alternative formats
1878 described in the formats.txt document? In particular, I hear that mbx
1879 format will give me better performance and allow shared
1880 access.</strong></a></p>
1882 <dl>
1883 <dd>
1884 The rumors about mbx format being preferred are true. It is faster than
1885 the traditional UNIX mailbox format and permits shared access.
1887 <p>However, and this is <em>very important</em>, note that using an
1888 alternative mailbox format is an advanced facility, and only expert
1889 users should undertake it. If you don't understand any of the following
1890 notes, you may not be enough of an expert yet, and are probably better
1891 off not going this route until you are more comfortable with your
1892 understanding.</p>
1894 <p>Some of the formats, including mbx, are only supported by the
1895 software based on the c-client library, and are not recognized by other
1896 mailbox programs. The "vi" editor will corrupt any mbx format mailbox
1897 that it encounters.</p>
1899 <p>Another problem is that the certain formats, including mbx, use
1900 advanced file access and locking techniques that do <em>not</em> work
1901 reliably with NFS. NFS is not a real filesystem. Use IMAP instead of
1902 NFS for distributed access.</p>
1904 <p>Each of the following steps are in escalating order of involvement.
1905 The further you go down this list, the more deeply committed you
1906 become:</p>
1908 <ul>
1909 <li>The simplest way to create a mbx-format mailbox is to prefix the
1910 name with "#driver.mbx/" when creating a mailbox through c-client.
1911 For example, if you create "#driver.mbx/foo", the mailbox "foo" will
1912 be created in mbx format. Only use "#driver.mbx/" when creating the
1913 mailbox. At all other times, just use the name ("foo" in this
1914 example); the software will automatically select the driver for mbx
1915 whenever that mailbox is accessed without you doing anything
1916 else.</li>
1918 <li>You can use the "mailutil copy" command to copy an existing
1919 mailbox to a new mailbox in mbx format. Read the man page provided
1920 with the mailutil program for details.</li>
1922 <li>If you create an mbx-format INBOX, by creating
1923 "#driver.mbx/INBOX" (note that "INBOX" must be all uppercase), then
1924 subsequent access to INBOX by any c-client based application will use
1925 the mbx-format INBOX. Any mail delivered to the traditional format
1926 mailbox in the spool directory (e.g. /var/spool/mail/$USER) will
1927 automatically be copied into the mbx-format INBOX and the spool
1928 directory copy removed.</li>
1930 <li>You can cause any newly-created mailboxes to be in mbx-format by
1931 default by changing the definition of CREATEPROTO=unixproto to be
1932 CREATEPROTO=mbxproto in src/osdep/unix/Makefile, then rebuilding the
1933 IMAP toolkit (do a "make clean" first). Do not change EMPTYPROTO,
1934 since mbx format mailboxes are never a zero-byte file. If you use
1935 Pine or the imap-utils, you should probably also rebuild them with
1936 the new IMAP toolkit too.</li>
1938 <li>You can deliver directly to the mbx-format INBOX by use of the
1939 tmail or dmail programs. tmail is for direct invocation from sendmail
1940 (or whatever MTA program you use); dmail is for calls from procmail.
1941 Both of these programs have man pages which must be read carefully
1942 before making this change.</li>
1943 </ul>
1945 <p>Most other servers (e.g. Cyrus) require use of a non-standard
1946 format. A full-fledged format conversion is not significantly different
1947 from what you have to do with other servers. The difference, which
1948 makes format conversion procedures somewhat more complicated with this
1949 server, is that there is no "all or nothing" requirement with this
1950 server. There are many points in between. A format conversion can be
1951 anything from a single mailbox or single user, to systemwide.</p>
1953 <p>This is good in that you can decide how far to go, or do the steps
1954 incrementally as you become more comfortable with the result. On the
1955 other hand, there's no "One True Way" which can be boiled down to a
1956 simple set of pedagogical instructions.</p>
1958 <p>A number of sites have done full-fledged format conversions, and are
1959 reportedly quite happy with the results. Feel free to ask in the
1960 comp.mail.imap newsgroup or the imap-uw mailing list for advice or
1961 help.</p>
1962 </dd>
1963 </dl>
1965 <p><a href="#top">Back to top</a></p>
1966 <hr>
1968 <p><a name="4.6"><strong>4.6 How do I set up shared mailboxes?</strong></a></p>
1970 <dl>
1971 <dd>
1972 At the simplest level, a shared mailbox is one which has UNIX file and
1973 directory protections which permit multiple users to access it. What
1974 this means is that your existing skills and tools to create and manage
1975 shared files on your UNIX system apply to shared mailboxes; e.g.
1976 <pre>
1977 chmod 666 mailbox
1978 </pre>
1980 <p>You may want to consider the use of a mailbox format which permits
1981 multiple simultaneous read/write sessions, such as the mbx format. The
1982 traditional UNIX format only allows one read/write session to a
1983 mailbox at a time.</p>
1985 <p>An additional convenience item are three system directories, which
1986 can be set up for shared namespaces. These are: #ftp, #shared, and
1987 #public, and are defined by creating the associated UNIX users and home
1988 directories as described below.</p>
1990 <p>#ftp/ refers to the anonymous ftp filesystem exported by the ftp
1991 server, and is equivalent to the home directory for UNIX user "ftp".
1992 For example, #ftp/foo/bar refers to the file /foo/bar in the anonymous
1993 FTP filesystem, or ~ftp/foo/bar for normal users. Anonymous FTP files
1994 are available to anonymous IMAP logins. By default, newly-created files
1995 in #ftp/ are protected 644.</p>
1997 <p>#public/ refers to an IMAP toolkit convention called "public" files,
1998 and is equivalent to the home directory for UNIX user "imappublic". For
1999 example, #public/foo/bar refers to the file ~imappublic/foo/bar. Public
2000 files are available to anonymous IMAP logins. By default, newly-created
2001 files in #public are created with protection 0666.</p>
2003 <p>#shared/ refers to an IMAP toolkit convention called "shared" files,
2004 and is equivalent to the home directory for UNIX user "imapshared". For
2005 example, #shared/foo/bar refers to the file ~imapshared/foo/bar. Shared
2006 files are <em>not</em> available to anonymous IMAP logins. By default,
2007 newly-created files in #shared are created with protection 0660.</p>
2008 </dd>
2009 </dl>
2011 <p><a href="#top">Back to top</a></p>
2012 <hr>
2014 <p><a name="4.7"><strong>4.7 How can I make the server syslogs go to someplace
2015 other than the mail syslog?</strong></a></p>
2017 <dl>
2018 <dd>
2019 The openlog() call that sets the syslog facility is in
2020 <strong>src/osdep/unix/env_unix.c</strong> in routine
2021 <strong>server_init()</strong>. You need to edit this file to change
2022 the syslog facility from LOG_MAIL to the facility you want, then
2023 rebuild. You also need to set up your /etc/syslog.conf properly.
2025 <p>Refer to the man pages for syslog and syslogd for more information
2026 on what the available syslog facilities are and how to configure
2027 syslogs. If you still don't understand what to do, find a UNIX system
2028 expert.</p>
2029 </dd>
2030 </dl>
2032 <p><a href="#top">Back to top</a></p>
2033 <hr>
2035 <p><br></p>
2037 <h2><a name="security">5. Security Questions</a></h2>
2038 <hr>
2040 <p><a name="5.1"><strong>5.1 I see that the IMAP server allows access to
2041 arbitary files on the system, including /etc/passwd! How do I disable
2042 this?</strong></a></p>
2044 <dl>
2045 <dd>
2046 You should not worry about this if your IMAP users are allowed shell
2047 access. The IMAP server does not permit any access that the user can
2048 not have via the shell.
2050 <p>If, and only if, you deny your IMAP users shell access, you may want
2051 to consider one of three choices. Note that these choices reduce IMAP
2052 functionality, and may have undesirable side effects. Each of these
2053 choices involves an edit to file
2054 <strong>src/osdep/unix/env_unix.c</strong></p>
2056 <p>The first (and recommended) choice is to set
2057 <strong>restrictBox</strong> as described in file CONFIG. This will
2058 disable access to the filesystem root, to other users' home directory,
2059 and to superior directory.</p>
2061 <p>The second (and strongly NOT recommended) choice is to set
2062 <strong>closedBox</strong> as described in file CONFIG. This puts each
2063 IMAP session into a so-called "chroot jail", and thus setting this
2064 option is <em>extremely</em> dangerous; it can make your system much
2065 less secure and open to root compromise attacks. So do not use this
2066 option unless you are <em>absolutely certain</em> that you understand
2067 all the issues of a "chroot jail."</p>
2069 <p>The third choice is to rewrite routine
2070 <strong>mailboxfile()</strong> to implement whatever mapping from
2071 mailbox name to filesystem name (and restrictions) that you wish. This
2072 is the most general choice. As a guide, you can see at the start of
2073 routine <strong>mailboxfile()</strong> what the
2074 <strong>restrictBox</strong> choice does.</p>
2075 </dd>
2076 </dl>
2078 <p><a href="#top">Back to top</a></p>
2079 <hr>
2081 <p><a name="5.2"><strong>5.2 I've heard that IMAP servers are insecure. Is this
2082 true?</strong></a></p>
2084 <dl>
2085 <dd>
2086 There are no known security problems in this version of the IMAP
2087 toolkit, including the IMAP and POP servers. The IMAP and POP servers
2088 limit what can be done while not logged in, and as part of the login
2089 process discard all privileges except those of the user.
2091 <p>As with other software packages, there have been buffer overflow
2092 vulnerabilities in past versions. All known problems of this nature are
2093 fixed in this version.</p>
2095 <p>There is every reason to believe that the bad guys are engaged in an
2096 ongoing effort to find vulnerabilities in the IMAP toolkit. We look for
2097 such problems, and when one is found we fix it.</p>
2099 <p>It's unfortunate that any vulnerabilities existed in past versions,
2100 and we're doing my best to keep the IMAP toolkit free of
2101 vulnerabilities. No new vulnerabilities have been discovered in quite a
2102 while, but efforts will not be relaxed.</p>
2104 <p>Beware of vendors who claim that their implementations can not have
2105 vulnerabilities.</p>
2106 </dd>
2107 </dl>
2109 <p><a href="#top">Back to top</a></p>
2110 <hr>
2112 <p><a name="5.3"><strong>5.3 How do I know that I have the most secure version
2113 of the server?</strong></a></p>
2115 <dl>
2116 <dd>
2117 The best way is to keep your server software up to date. The bad guys
2118 are always looking for ways to crack software, and when they find one,
2119 let all their friends know.
2121 <p>Oldtimers used to refer to a concept of <em>software rot</em>: if
2122 your software hasn't been updated in a while, it would "rot" -- tend to
2123 acquire problems that it didn't have when it was new.</p>
2125 <p>The latest release version of the IMAP toolkit is always available
2126 at <a href=
2127 "ftp://ftp.cac.washington.edu/mail/imap.tar.Z">ftp://ftp.cac.washington.edu/mail/imap.tar.Z</a></p>
2128 </dd>
2129 </dl>
2131 <p><a href="#top">Back to top</a></p>
2132 <hr>
2134 <p><a name="5.4"><strong>5.4 I see all these strcpy() and sprintf() calls, those
2135 are unsafe, aren't they?</strong></a></p>
2137 <dl>
2138 <dd>
2139 Yes and no.
2141 <p>It can be unsafe to do these calls if you do not know that the
2142 string being written will fit in the buffer. However, they are
2143 perfectly safe if you do know that.</p>
2145 <p>Beware of programmers who advocate doing a brute-force change of all
2146 instances of</p>
2147 <pre>
2148 strcpy (s,t);
2149 </pre>to
2150 <pre>
2151 strncpy (s,t,n)[n] = '\0';
2152 </pre>and similar measures in the name of "fixing all possible buffer
2153 overflows."
2155 <p>There are examples in which a security bug was introduced because of
2156 this type of "fix", due to the programmer using the wrong value for n.
2157 In one case, the programmer thought that n was larger than it actually
2158 was, causing a NUL to be written out of the buffer; in another, n was
2159 too small, and a security credential was truncated.</p>
2161 <p>What is particularly ironic was that in both cases, the original
2162 strcpy() was safe, because the size of the source string was known to
2163 be safe.</p>
2165 <p>With all this in mind, the software has been inspected, and it is
2166 believed that all places where buffer overflows can happen have been
2167 fixed. The strcpy()s that are still are in the code occur after a size
2168 check was done in some other way.</p>
2170 <p>Note that the common C idiom of</p>
2171 <pre>
2172 *s++ = c;
2173 </pre>is just as vulnerable to buffer overflows. You can't cure buffer
2174 overflows by outlawing certain functions, nor is it desirable to do so;
2175 sometimes operations like strcpy() translate into fast machine instructions
2176 for better performance.
2178 <p>Nothing replaces careful study of code. That's how the bad guys find
2179 bugs. Security is not accomplished by means of brute-force
2180 shortcuts.</p>
2181 </dd>
2182 </dl>
2184 <p><a href="#top">Back to top</a></p>
2185 <hr>
2187 <p><a name="5.5"><strong>5.5 Those /tmp lock files are protected 666, is that
2188 really right?</strong></a></p>
2190 <dl>
2191 <dd>
2192 Yes. Shared mailboxes won't work otherwise. Also, you get into
2193 accidental denial of service problems with old lock files left lying
2194 around; this happens fairly frequently.
2196 <p>The deliberate mischief that can be caused by fiddling with the lock
2197 files is small-scale; harassment level at most. There are many -- and
2198 much more effective -- other ways of harassing another user on UNIX.
2199 It's usually not difficult to determine the culprit.</p>
2201 <p>Before worrying about deliberate mischief, worry first about things
2202 happening by accident!</p>
2203 </dd>
2204 </dl>
2206 <p><a href="#top">Back to top</a></p>
2207 <hr>
2209 <p><br></p>
2211 <h2><a name="strange">6. <em>Why Did You Do This Strange Thing?</em>
2212 Questions</a></h2>
2213 <hr>
2215 <p><a name="6.1"><strong>6.1 Why don't you use GNU autoconfig / automake /
2216 autoblurdybloop?</strong></a></p>
2218 <dl>
2219 <dd>
2220 Autoconfig et al are not available on all the platforms where the IMAP
2221 toolkit is supported; and do not work correctly on some of the
2222 platforms where they do exist. Furthermore, these programs add another
2223 layer of complexity to an already complex process.
2225 <p>Coaxing software that uses autoconfig to build properly on platforms
2226 which were not specifically considered by that software wastes an
2227 inordinate amount of time. When (not if) autoconfig fails to do the
2228 right thing, the result is an inpenetrable morass to untangle in order
2229 to find the problem and fix it.</p>
2231 <p>The concept behind autoconfig is good, but the execution is flawed.
2232 It rarely does the right thing on a platform that wasn't specifically
2233 considered. Human life is too short to debug autoconfig problems,
2234 especially since the current mechanism is so much easier.</p>
2235 </dd>
2236 </dl>
2238 <p><a href="#top">Back to top</a></p>
2239 <hr>
2241 <p><a name="6.2"><strong>6.2 Why do you insist upon a build with -g? Doesn't it
2242 waste disk and memory space?</strong></a></p>
2244 <dl>
2245 <dd>
2246 From time to time a submitted port has snuck in without -g. This has
2247 <em>always</em> ended up causing problems. There are only two valid
2248 excuses for not using -g in a port:
2250 <ul>
2251 <li>The compiler does not support -g</li>
2253 <li>An alternate form of -g is needed with optimization, e.g.
2254 -g3.</li>
2255 </ul>
2257 <p>There will be no new ports added without -g (or a suitable
2258 alternative) being set.</p>
2260 <p>-g has not been arbitrarily added to the ports which do not
2261 currently have it because we don't know if doing so would break the
2262 build. However, any support issues with one of those port <em>will</em>
2263 lead to the correct -g setting being determined and permanently
2264 added.</p>
2266 <p>Processors are fast enough (and disk space is cheap enough) that -g
2267 should be automatic in all compilers with no way of turning it off, and
2268 /bin/strip should be a symlink to /bin/true. Human life is too short to
2269 deal with binaries built without -g. Such binaries should be a bad
2270 memory of the days of KIPS processors and disks that costs several
2271 dollars per kilobyte.</p>
2272 </dd>
2273 </dl>
2275 <p><a href="#top">Back to top</a></p>
2276 <hr>
2278 <p><a name="6.3"><strong>6.3 Why don't you make c-client a shared
2279 library?</strong></a></p>
2281 <dl>
2282 <dd>
2283 All too often, shared libraries create far more problems than they
2284 solve.
2286 <p>Remember that you only gain the benefit of a shared library when
2287 there are multiple applications which use that shared library. Even
2288 without shared libraries, on most modern operating systems (and many
2289 ancient ones too!) applications will share their text segments between
2290 across multiple processes running the same application. This means that
2291 if your system only runs one application (e.g. imapd) that uses the
2292 c-client library, then you gain no benefit from making c-client a
2293 shared library even if it has 100 imapd processes. You will, however
2294 suffer added complexity.</p>
2296 <p>If you have a server system that just runs imapd and ipop3d, then
2297 making c-client a shared library will save just one copy of c-client no
2298 matter how many IMAP/POP3 processes are running.</p>
2300 <p>The problem with shared libraries is that you have to keep around a
2301 copy of the library every time something changes in the library that
2302 would affect the interface the library presents to the application. So,
2303 you end up having many copies of the same shared library.</p>
2305 <p>If you don't keep multiple copies of the shared library, then one of
2306 two things happens. If there was proper versioning, then you'll get a
2307 message such as "cannot open shared object file" or "minor versions
2308 don't match" and the application won't run. Otherwise, the application
2309 will run, but will fail in mysterious ways.</p>
2311 <p>Several sites and third-party distributors have modified the
2312 c-client makefile in order to make c-client be a shared library.
2313 <em>When</em> (not <em>if</em>) a c-client based application fails in
2314 mysterious ways because of a library compatibility problem, the result
2315 is a bug report. A lot of time and effort ends up getting wasted
2316 investigating such bug reports.</p>
2318 <p>Memory is so cheap these days that it's not worth it. Human life is
2319 too short to deal with shared library compatibility problems.</p>
2320 </dd>
2321 </dl>
2323 <p><a href="#top">Back to top</a></p>
2324 <hr>
2326 <p><a name="6.4"><strong>6.4 Why don't you use iconv() for internationalization
2327 support?</strong></a></p>
2329 <dl>
2330 <dd>iconv() is not ubiquitous enough.</dd>
2331 </dl>
2333 <p><a href="#top">Back to top</a></p>
2334 <hr>
2336 <p><a name="6.5"><strong>6.5 Why is the IMAP server connected to the home
2337 directory by default?</strong></a></p>
2339 <dl>
2340 <dd>
2341 The IMAP server has no way of knowing what you might call "mail" as
2342 opposed to "some other file"; in fact, you can use IMAP to access any
2343 file.
2345 <p>The IMAP server also doesn't know whether your preferred
2346 subdirectory for mailbox files is "mail/", ".mail/", "Mail/",
2347 "Mailboxes/", or any of a zillion other possibilities. If one such name
2348 were chosen, it would undoubtably anger the partisans of all the other
2349 names.</p>
2351 <p>It is possible to modify the software so that the default connected
2352 directory is someplace else. Please read the file CONFIG for discussion
2353 of this and other issues.</p>
2354 </dd>
2355 </dl>
2357 <p><a href="#top">Back to top</a></p>
2358 <hr>
2360 <p><a name="6.6"><strong>6.6 I have a Windows system. Why isn't the server plug
2361 and play for me?</strong></a></p>
2363 <dl>
2364 <dd>
2365 There is no standard for how mail is stored on Windows; nor a single
2366 standard SMTP server. The closest to either would be the SMTP server in
2367 Microsoft's IIS.
2369 <p>So there's no default by which to make assumptions. As the software
2370 is set up, it assumes that the each user has an Windows login account
2371 and private home directory, and that mail is stored on that home
2372 directory as files in one of the popular UNIX formats. It also assumes
2373 that there is some tool equivalent to inetd on UNIX that does the
2374 TCP/IP listening and server startup.</p>
2376 <p>Basically, unless you're an email software hacker, you probably want
2377 to look elsewhere if you want IMAP/POP servers for Windows.</p>
2378 </dd>
2379 </dl>
2381 <p><a href="#top">Back to top</a></p>
2382 <hr>
2384 <p><a name="6.7"><strong>6.7 I looked at the UNIX SSL code and saw that you have
2385 the SSL data payload size set to 8192 bytes. SSL allows 16K; why aren't
2386 you using the full size?</strong></a></p>
2388 <dl>
2389 <dd>
2390 This is to avoid an interoperability problem with:
2392 <ul>
2393 <li>PC IMAP clients that use Microsoft's SChannel.DLL (SSPI) for SSL
2394 support</li>
2396 <li>Microsoft Exchange server (which also uses SChannel).</li>
2397 </ul>
2399 <p>SChannel has a bug that makes it think that the maximum SSL data
2400 payload size is 16379 bytes -- 5 bytes too small. Thus, c-client has to
2401 make sure that it never transmits full sized SSL packets.</p>
2403 <p>The reason for using 8K (as opposed to, say, 16379 bytes, or 15K,
2404 or...) is that it corresponds with the TCP buffer size that the
2405 software uses elsewhere for input; there's a slight performance benefit
2406 to having the two sizes correspond or at least be a multiple of each
2407 other. Also, it keeps the size as a power of two, which might be
2408 significant on some platforms.</p>
2410 <p>There wasn't a significant difference that we could measure between
2411 8K and 15K.</p>
2413 <p>Microsoft has developed a hotfix for this bug. Look up MSKB article
2414 number 300562. Contrary to the article text which implies that this is
2415 a Pine issue, this bug also affects Microsoft Exchange server with
2416 <em>any</em> client that transmits full-sized SSL payloads.</p>
2417 </dd>
2418 </dl>
2420 <p><a href="#top">Back to top</a></p>
2421 <hr>
2423 <p><a name="6.8"><strong>6.8 Why is an mh format INBOX called #mhinbox instead
2424 of just INBOX?</strong></a></p>
2426 <dl>
2427 <dd>
2428 It's a long story. In brief, the mh format driver is less functional
2429 than any of the other drivers. It turned out that there were some users
2430 (including high-level administrators) who tried mh years ago and no
2431 longer use it, but still had an mh profile left behind.
2433 <p>When the mh driver used INBOX, it would see the mh profile, and
2434 proceed to move the user's INBOX into the mh format INBOX. This caused
2435 considerable confusion as some things stopped working.</p>
2436 </dd>
2437 </dl>
2439 <p><a href="#top">Back to top</a></p>
2440 <hr>
2442 <p><a name="6.9"><strong>6.9 Why don't you support the maildir
2443 format?</strong></a></p>
2445 <dl>
2446 <dd>
2447 It is technically difficult to support maildir in IMAP while
2448 maintaining acceptable performance, robustness, following the
2449 requirements of the IMAP protocol specification, and following the
2450 requirements of maildir.
2452 <p>No one has succeeded in accomplishing all four together. The various
2453 maildir drivers offered as patches all have these problems. The problem
2454 is exacerbated because this implementation supports multiple formats;
2455 consequently this implementation can't make any performance shortcuts
2456 by assuming that all the world is maildir.</p>
2458 <p>We can't do a better job than the maildir fan community has done
2459 with their maildir drivers. Similarly, if the maildir fan community
2460 provides the maildir driver, they take on the responsibility for
2461 answering maildir-specific support questions. This is as it should be,
2462 and that is why maildir support is left to the maildir fan
2463 community.</p>
2464 </dd>
2465 </dl>
2467 <p><a href="#top">Back to top</a></p>
2468 <hr>
2470 <p><a name="6.10"><strong>6.10 Why don't you support the Cyrus
2471 format?</strong></a></p>
2473 <dl>
2474 <dd>
2475 There's no point to doing so. An implementation which supports multiple
2476 formats will never do as well as one which is optimized to support one
2477 single format.
2479 <p>If you want to use Cyrus mailbox format, you should use the Cyrus
2480 server, which is the native implementation of that format and is
2481 specifically optimized for that format. That's also why Cyrus doesn't
2482 implement any other format.</p>
2483 </dd>
2484 </dl>
2486 <p><a href="#top">Back to top</a></p>
2487 <hr>
2489 <p><a name="6.11"><strong>6.11 Why is it creating extra forks on my SVR4
2490 system?</strong></a></p>
2492 <dl>
2493 <dd>
2494 This is because your system only has fcntl() style locking and not
2495 flock() style locking. fcntl() locking has a design flaw that causes a
2496 close() to release any locks made by that process on the file opened on
2497 that file descriptor, even if the lock was made on a different file
2498 descriptor.
2500 <p>This design flaw causes unexpected loss of lock, and consequent
2501 mailbox corruption. The workaround is to do certain "dangerous
2502 operations" in another fork, thus avoiding doing a close() in the
2503 vulnerable fork.</p>
2505 <p>The best way to solve this problem is to upgrade your SVR4 (Solaris,
2506 AIX, HP-UX, SGI) or OSF/1 system to a more advanced operating system,
2507 such as Linux or BSD. These more advanced operating systems have
2508 fcntl() locking for compatibility with SVR4, but also have flock()
2509 locking.</p>
2511 <p>Beware of certain SVR4 systems, such as AIX, which have an "flock()"
2512 function in their C library that is just a jacket that does an fcntl()
2513 lock. This is not a true flock(), and has the same design flaw as
2514 fcntl().</p>
2515 </dd>
2516 </dl>
2518 <p><a href="#top">Back to top</a></p>
2519 <hr>
2521 <p><a name="6.12"><strong>6.12 Why are you so fussy about the date/time format in
2522 the internal <code>"From "</code> line in traditional UNIX mailbox
2523 files? My other mail program just considers every line that starts with
2524 <code>"From "</code> to be the start of the message.</strong></a></p>
2526 <dl>
2527 <dd>
2528 You just answered your own question. If any line that starts with
2529 <code>"From "</code> is treated as the start of a message, then
2530 every message text line which starts with <code>"From "</code> has
2531 to be quoted (typically by prefixing a ">" character). People
2532 complain about this -- "why did a > get stuck in my message?"
2534 <p>So, good mail reading software only considers a line to be a
2535 <code>"From "</code> line if it follows the actual specification
2536 for a "From " line. This means, among other things, that the day of
2537 week is fixed-format: <code>"May 14"</code>, but
2538 <code>"May 7"</code> (note the extra space) as opposed to
2539 <code>"May 7"</code>. ctime() format for the date is the most
2540 common, although POSIX also allows a numeric timezone after the
2541 year. For compatibility with ancient software, the seconds are optional,
2542 the timezone may appear before the year, the old 3-letter timezones are
2543 also permitted, and "remote from xxx" may appear after the whole
2544 thing.</p>
2546 <p>Unfortunately, some software written by novices use other formats.
2547 The most common error is to have a variable-width day of month, perhaps
2548 in the erroneous belief that RFC 2822 (or RFC 822) defines the format of
2549 the date/time in the <code>"From "</code> line (it doesn't; no RFC
2550 describes internal formats). I've seen a few other goofs, such as a
2551 single-digit second, but these are less common.</p>
2553 <p>If you are writing your own software that writes mailbox files, and
2554 you really aren't all that savvy with all the ins and outs and ancient
2555 history, you should seriously consider using the c-client library (e.g.
2556 routine mail_append()) instead of doing the file writes yourself. If
2557 you must do it yourself, use ctime(), as in:</p>
2558 <pre>
2559 fprintf (mbx,"From %s@%h %s",user,host,ctime (time (0)));
2560 </pre>rather than try to figure out a good format yourself. ctime() is the
2561 most traditional format and nobody will flame you for using it.
2562 </dd>
2563 </dl>
2565 <p><a href="#top">Back to top</a></p>
2566 <hr>
2568 <p><a name="6.13"><strong>6.13 Why is traditional UNIX format the default
2569 format?</strong></a></p>
2571 <dl>
2572 <dd>Compatibility with the past 30 or so years of UNIX history. This
2573 server is the only one that completely interoperates with legacy UNIX
2574 mail tools.</dd>
2575 </dl>
2577 <p><a href="#top">Back to top</a></p>
2578 <hr>
2580 <p><a name="6.14"><strong>6.14 Why do you write this "DON'T DELETE THIS MESSAGE
2581 -- FOLDER INTERNAL DATA" message at the start of traditional UNIX and
2582 MMDF format mailboxes?</strong></a></p>
2584 <dl>
2585 <dd>
2586 This pseudo-message serves two purposes.
2588 <p>First, it establishes the mailbox format even when the mailbox has
2589 no messages. Otherwise, a mailbox with no messages is a zero-byte file,
2590 which could be one of several formats.</p>
2592 <p>Second, it holds mailbox metadata used by IMAP: the UID validity,
2593 the last assigned UID, and mailbox keywords. Without this metadata,
2594 which must be preserved even when the mailbox has no messages, the
2595 traditional UNIX format wouldn't be able to support the full
2596 capabilities of IMAP.</p>
2597 </dd>
2598 </dl>
2600 <p><a href="#top">Back to top</a></p>
2601 <hr>
2603 <p><a name="6.15"><strong>6.15 Why don't you stash the mailbox metadata in the
2604 first real message of the mailbox instead of writing this fake FOLDER
2605 INTERNAL DATA message?</strong></a></p>
2607 <dl>
2608 <dd>
2609 In fact, that is what is done if the mailbox is non-empty and does not
2610 already have a FOLDER INTERNAL DATA message.
2612 <p>One problem with doing that is that if some external program removes
2613 the first message, the metadata is lost and must be recreated, thus
2614 losing any prior UID or keyword list status that IMAP clients may
2615 depend upon.</p>
2617 <p>Another problem is that this doesn't help if the last message is
2618 deleted. This will result in an empty mailbox, and the necessity to
2619 create a FOLDER INTERNAL DATA message.</p>
2620 </dd>
2621 </dl>
2623 <p><a href="#top">Back to top</a></p>
2624 <hr>
2626 <p><a name="6.16"><strong>6.16 Why aren't "dual-use" mailboxes the
2627 default?</strong></a></p>
2629 <dl>
2630 <dd>Compatibility with the past 30 or so years of UNIX history, not to
2631 mention compatibility with user expectations when using shell tools.</dd>
2632 </dl>
2634 <p><a href="#top">Back to top</a></p>
2635 <hr>
2637 <p><a name="6.17"><strong>6.17 Why do you use ucbcc to build on
2638 Solaris?</strong></a></p>
2640 <dl>
2641 <dd>
2642 It is a long, long story about why cc is set to ucbcc. You need to
2643 invoke the C compiler so that it links with the SVR4 libraries and not
2644 the BSD libraries, otherwise readdir() will return the wrong
2645 information.
2647 <p>Of all the names in the most common path, ucbcc is the only name to
2648 be found (on /usr/ccs/bin) that points to a suitable compiler. cc is
2649 likely to be /usr/ucb/cc which is absolutely not the compiler that you
2650 want. The real SVR4 cc is probably something like /opt/SUNWspro/bin/cc
2651 which is rarely in anyone's path by default.</p>
2653 <p>ucbcc is probably a link to acc, e.g. /opt/SUNWspro/SC4.0/bin/acc,
2654 and is the UCB C compiler using the SVR4 libraries.</p>
2656 <p>If ucbcc isn't on your system, then punt on the SUN C compiler and
2657 use gcc instead (the gso port instead of the sol port).</p>
2659 <p>If, in spite of all the above warnings, you choose to change "ucbcc"
2660 to "cc", you will probably find that the -O2 needs to be changed to -O.
2661 If you don't get any error messages with -O2, that's a pretty good
2662 indicator that you goofed and are running the compiler that will link
2663 with the BSD libraries.</p>
2665 <p>To recap:</p>
2667 <ul>
2668 <li>The sol port is designed to be built using the UCB compiler using
2669 the SVR4 libraries. This compiler is "ucbcc", which is lunk to acc.
2670 You use -O2 as one of the CFLAGS.</li>
2672 <li>If you build the sol port with the UCB compiler using the BSD
2673 libraries, you will get no error messages but you will get bad
2674 binaries (the most obvious symptom is dropping the first two
2675 characters return filenames from the imapd LIST command. This
2676 compiler also uses -O2, and is very often what the user gets from
2677 "cc". <strong>BEWARE</strong></li>
2679 <li>If you build the sol port with the real SVR4 compiler, which is
2680 often hidden away or unavailable on many systems, then you will get
2681 errors from -O2 and you need to change that to -O. But you will get a
2682 good binary. However, you should try it with -O2 first, to make sure
2683 that you got this compiler and not the UCB compiler using BSD
2684 libraries.</li>
2685 </ul>
2686 </dd>
2687 </dl>
2689 <p><a href="#top">Back to top</a></p>
2690 <hr>
2692 <p><a name="6.18"><strong>6.18 Why should I care about some old system with BSD
2693 libraries? cc is the right thing on my Solaris system!</strong></a></p>
2695 <dl>
2696 <dd>
2697 Because there still are sites that use such systems. On those systems,
2698 the assumption that "cc" does the right thing will lead to corrupt
2699 binaries with no error message or other warning that anything is amiss.
2701 <p>Too many sites have fallen victim to this problem.</p>
2702 </dd>
2703 </dl>
2705 <p><a href="#top">Back to top</a></p>
2706 <hr>
2708 <p><a name="6.19"><strong>6.19 Why do you insist upon writing .lock files in the
2709 spool directory?</strong></a></p>
2711 <dl>
2712 <dd>Compatibility with the past 30 years of UNIX software which deals
2713 with the spool directory, especially software which delivers mail.
2714 Otherwise, it is possible to lose mail.</dd>
2715 </dl>
2717 <p><a href="#top">Back to top</a></p>
2718 <hr>
2720 <p><a name="6.20"><strong>6.20 Why should I care about compatibility with the
2721 past?</strong></a></p>
2723 <dl>
2724 <dd>This is one of those questions in which the answer never convinces
2725 those who ask it. Somehow, everybody who ever asks this question ends up
2726 answering it for themselves as they get older, with the very answer that
2727 they rejected years earlier.</dd>
2728 </dl>
2730 <p><a href="#top">Back to top</a></p>
2731 <hr>
2733 <p><br></p>
2735 <h2><a name="problems">7. Problems and Annoyances</a></h2>
2736 <hr>
2738 <p><a name="7.1"><strong>7.1 Help! My INBOX is empty! What happened to my
2739 messages?</strong></a></p>
2741 <dl>
2742 <dd>
2743 If you are seeing "0 messages" when you open INBOX and you know you
2744 have messages there (and perhaps have looked at your mail spool file
2745 and see that messages are there), then probably there is something
2746 wrong with the very first line of your mail spool file. Make sure that
2747 the first five bytes of the file are "From ", followed by an email
2748 address and a date/time in ctime() format, e.g.:
2749 <pre>
2750 From fred@foo.bar Mon May 7 20:54:30 2001
2751 </pre>
2752 </dd>
2753 </dl>
2755 <p><a href="#top">Back to top</a></p>
2756 <hr>
2758 <p><a name="7.2"><strong>7.2 Help! All my messages in a non-INBOX mailbox have
2759 been concatenated into one message which claims to be from me and has a
2760 subject of the file name of the mailbox! What's going
2761 on?</strong></a></p>
2763 <dl>
2764 <dd>
2765 Something wrong with the very first line of the mailbox. Make sure that
2766 the first five bytes of the file are "From ", followed by an email
2767 address and a date/time in ctime() format, e.g.:
2768 <pre>
2769 From fred@foo.bar Mon May 7 20:54:30 2001
2770 </pre>
2771 </dd>
2772 </dl>
2774 <p><a href="#top">Back to top</a></p>
2775 <hr>
2777 <p><a name="7.3"><strong>7.3 Why do I get the message:</strong> <tt>CREATE
2778 failed: Can't create mailbox node xxxxxxxxx: File exists</tt>
2779 <strong>and how do I fix it?</strong></a></p>
2781 <dl>
2782 <dd>See the answer to the <a href="#1.8">Are hierarchical mailboxes
2783 supported?</a> question.</dd>
2784 </dl>
2786 <p><a href="#top">Back to top</a></p>
2787 <hr>
2789 <p><a name="7.4"><strong>7.4 Why can't I log in to the server? The user name and
2790 password are right!</strong></a></p>
2792 <dl>
2793 <dd>
2794 There are a myriad number of possible answers to this question. The
2795 only way to say for sure what is wrong is run the server under a
2796 debugger such as gdb while root (yes, you must be root) with a
2797 breakpoint at routines checkpw() and loginpw(), then single-step until
2798 you see which test rejected you. The server isn't going to give any
2799 error messages other than "login failed" in the name of not giving out
2800 any unnecessary information to unauthorized individuals.
2802 <p>Here are some of the more common reasons why login may fail:</p>
2804 <ul>
2805 <li>You didn't really give the correct user name and/or
2806 password.</li>
2808 <li>Your client doesn't send the LOGIN command correctly; for
2809 example, IMAP2 clients won't send a password containing a "*"
2810 correctly to an IMAP4 server.</li>
2812 <li>If you have set up a CRAM-MD5 database, remember that the
2813 password used is the one in the CRAM-MD5 database, and furthermore
2814 that there must also be an entry in /etc/passwd (but the /etc/passwd
2815 password is not used).</li>
2817 <li>If you are using PAM, have you created a service file for the
2818 server in /etc/pam.d?</li>
2820 <li>If you are using shadow passwords, have you used an appropriate
2821 port when building? In particular, note that "lnx" is for Linux
2822 systems without shadow passwords; you probably want "slx" or "lnp"
2823 instead.</li>
2825 <li>If your system has account or password expirations, check to see
2826 that the expiration date hasn't passed.</li>
2828 <li>You can't log in as root or any other UID 0 user. This is for
2829 your own safety, not to mention the fact that the servers use UID 0
2830 as meaning "not logged in".</li>
2831 </ul>
2832 </dd>
2833 </dl>
2835 <p><a href="#top">Back to top</a></p>
2836 <hr>
2838 <p><a name="7.5"><strong>7.5 Help! My load average is soaring and I see hundreds
2839 of POP and IMAP servers, many logged in as the same
2840 user!</strong></a></p>
2842 <dl>
2843 <dd>
2844 Certain inferior losing GUI mail reading programs have a "synchronize
2845 all mailboxes at startup" (IMAP) or "check for new mail every second"
2846 (POP) feature which causes a rapid and unchecked spawning of servers.
2848 <p>This is not a problem in the server; the client is really asking for
2849 all those server sessions. Unfortunately, there isn't much that the POP
2850 and IMAP servers can do about it; they don't spawned themselves.</p>
2852 <p>Some sites have added code to record the number of server sessions
2853 spawned per user per hour, and disable login for a user who has
2854 exceeded a predetermined rate. This doesn't stop the servers from being
2855 spawned; it just means that a server session will commit suicide a bit
2856 faster.</p>
2858 <p>Another possibility is to detect excessive server spawning activity
2859 at the level where the server is spawned, which would be inetd or
2860 possibly tcpd. The problem here is that this is a hard time to
2861 quantify. 50 sessions in a minute from a multi-user timesharing system
2862 may be perfectly alright, whereas 10 sessions a minute from a PC may be
2863 too much.</p>
2865 <p>The real solution is to fix the client configuration, by disabling
2866 those evil features. Also tell the vendors of those clients how you
2867 feel about distributing denial-of-service attack tools in the guise of
2868 mail reading programs.</p>
2869 </dd>
2870 </dl>
2872 <p><a href="#top">Back to top</a></p>
2873 <hr>
2875 <p><a name="7.6"><strong>7.6 Why does mail disappear even though I set "keep
2876 mail on server"?</strong></a><br>
2877 <a name="7.7"><strong>7.7 Why do I get the message</strong> <tt>Moved #####
2878 bytes of new mail to /home/user/mbox from /var/spool/mail/user</tt>
2879 <strong>and why did this happen?</strong></a></p>
2881 <dl>
2882 <dd>
2883 This is probably caused by the mbox driver. If the file "mbox" exists
2884 on the user's home directory and is in UNIX mailbox format, then when
2885 INBOX is opened this file will be selected as INBOX instead of the mail
2886 spool file. Messages will be automatically transferred from the mail
2887 spool file into the mbox file.
2889 <p>To disable this behavior, delete "mbox" from the EXTRADRIVERS list
2890 in the top-level Makefile and rebuild. Note that if you do this, users
2891 won't be able to access the messages that have already been moved to
2892 mbox unless they open mbox instead of INBOX.</p>
2893 </dd>
2894 </dl>
2896 <p><a href="#top">Back to top</a></p>
2897 <hr>
2899 <p><a name="7.8"><strong>7.8 Why isn't it showing the local host name as a
2900 fully-qualified domain name?</strong></a><br>
2901 <a name="7.9"><strong>7.9 Why is the local host name in the
2902 From/Sender/Message-ID headers of outgoing mail not coming out as a
2903 fully-qualified domain name?</strong></a></p>
2905 <dl>
2906 <dd>
2907 Your UNIX system is misconfigured. The entry for your system in
2908 /etc/hosts must have the fully-qualified domain name first, e.g.
2909 <pre>
2910 105.69.1.234 myserver.example.com myserver
2911 </pre>
2913 <p>A common mistake of novice system administrators is to have the
2914 short name first, e.g.</p>
2915 <pre>
2916 105.69.1.234 myserver myserver.example.com
2918 </pre>
2920 <p>or to omit the fully qualified domain name entirely, e.g.</p>
2921 <pre>
2922 105.69.1.234 myserver
2923 </pre>
2925 <p>The result of this is that when the IMAP toolkit does a
2926 gethostbyname() call to get the fully-qualified domain name, it would
2927 get "myserver" instead of "myserver.example.com".</p>
2929 <p>On some systems, a configuration file (typically named
2930 /etc/svc.conf, /etc/netsvc.conf, or /etc/nsswitch.conf) can be used to
2931 configure the system to use the domain name system (DNS) instead of
2932 /etc/hosts, so it doesn't matter if /etc/hosts is misconfigured.</p>
2934 <p>Check the man pages for gethostbyname, hosts, svc, and/or netsvc for
2935 more information.</p>
2937 <p>Unfortunately, certain vendors, most notably SUN, have failed to
2938 make this clear in their documentation. Most of SUN's documentation
2939 assumes a corporate network that is not connected to the Internet.</p>
2941 <p>net.folklore once (late 1980s) held that the proper procedure was to
2942 append the results of getdomainname() to the name returned by
2943 gethostname(), and some versions of sendmail configuration files were
2944 distributed that did this. This was incorrect; the string returned from
2945 getdomainname() is the Yellow Pages (a.k.a NIS) domain name, which is a
2946 completely different (albeit unfortunately named) entity from an
2947 Internet domain. These were often fortuitously the same string, except
2948 when they weren't. Frequently, this would result in host names with
2949 spuriously doubled domain names, e.g.</p>
2950 <pre>
2951 myserver.example.com.example.com
2953 </pre>
2955 <p>This practice has been thoroughly discredited for many years, but
2956 folklore dies hard.</p>
2957 </dd>
2958 </dl>
2960 <p><a href="#top">Back to top</a></p>
2961 <hr>
2963 <p><a name="7.10"><strong>7.10 What does the message:</strong> <tt>Mailbox
2964 vulnerable - directory /var/spool/mail must have 1777 protection</tt>
2965 <strong>mean? How can I fix this?</strong></a></p>
2967 <dl>
2968 <dd>
2969 In order to update a mailbox in the default UNIX format, it is
2970 necessary to create a lock file to prevent the mailer from delivering
2971 mail while an update is in progress. Some systems use a directory
2972 protection of 775, requiring that all mail handling programs be setgid
2973 mail; or of 755, requiring that all mail handling programs be setuid
2974 root.
2976 <p>The IMAP toolkit does not run with any special privileges, and I
2977 plan to keep it that way. It is antithetical to the concept of a
2978 toolkit if users can't write their own programs to use it. Also, I've
2979 had enough bad experiences with security bugs while running privileged;
2980 the IMAP and POP servers have to be root when not logged in, in order
2981 to be able to log themselves in. I don't want to go any deeper down
2982 that slippery slope.</p>
2984 <p>Directory protection 1777 is secure enough on most well-managed
2985 systems. If you can't trust your users with a 1777 mail spool (petty
2986 harassment is about the limit of the abuse exposure), then you have
2987 much worse problems then that.</p>
2989 <p>If you absolutely insist upon requiring privileges to create a lock
2990 file, external file locking can be done via a setgid mail program named
2991 /etc/mlock (this is defined by LOCKPGM in the c-client Makefile). If
2992 the toolkit is unable to create a <...mailbox...>.lock file in
2993 the directory by itself, it will try to call mlock to do it. I do not
2994 recommend doing this for performance reasons.</p>
2996 <p>A sample mlock program is included as part of imap-2007. We have
2997 tried to make this sample program secure, but it has not been
2998 thoroughly audited.</p>
2999 </dd>
3000 </dl>
3002 <p><a href="#top">Back to top</a></p>
3003 <hr>
3005 <p><a name="7.11"><strong>7.11 What does the message:</strong> <tt>Mailbox is
3006 open by another process, access is readonly</tt> <strong>mean? How do I
3007 fix this?</strong></a></p>
3009 <dl>
3010 <dd>
3011 A problem occurred in applying a lock to a /tmp lock file. Either some
3012 other program has the mailbox open and won't relenquish it, or
3013 something is wrong with the protection of /tmp or the lock.
3015 <p>Make sure that the /tmp directory is protected 1777. Some security
3016 scripts incorrectly set the protection of the /tmp directory to 775,
3017 which disables /tmp for all non-privileged programs.</p>
3018 </dd>
3019 </dl>
3021 <p><a href="#top">Back to top</a></p>
3022 <hr>
3024 <p><a name="7.12"><strong>7.12 What does the message:</strong> <tt>Can't get
3025 write access to mailbox, access is readonly</tt>
3026 <strong>mean?</strong></a></p>
3028 <dl>
3029 <dd>The mailbox file is write-protected against you.</dd>
3030 </dl>
3032 <p><a href="#top">Back to top</a></p>
3033 <hr>
3035 <p><a name="7.13"><strong>7.13 I set my POP3 client to "delete messages from
3036 server" but they never get deleted. What is wrong?</strong></a></p>
3038 <dl>
3039 <dd>
3040 Make sure that your mailbox is not read-only: that the mailbox is owned
3041 by you and write enabled (protection 0600), and that the /tmp directory
3042 is longer world-writeable. /tmp must be world-writeable because lots of
3043 applications use it for scratch space. To fix this, do
3044 <pre>
3046 chmod 1777 /tmp
3047 </pre>as root.
3049 <p>Make sure that your POP3 client issues a QUIT command when it
3050 finishes. The POP3 protocol specifies that deletions are discarded
3051 unless a proper QUIT is done.</p>
3053 <p>Make sure that you are not opening multiple POP3 sessions to the
3054 same mailbox. It is a requirement of the POP3 protocol than only one
3055 POP3 session be in effect to a mailbox at a time, however some,
3056 poorly-written POP3 clients violate this. Also, some background "check
3057 for new mail" tasks also cause a violation. See the answer to the
3058 <a href="#7.19">What does the syslog message: Killed (lost mailbox
3059 lock) user=... host=... mean?</a> question for more details.</p>
3060 </dd>
3061 </dl>
3063 <p><a href="#top">Back to top</a></p>
3064 <hr>
3066 <p><a name="7.14"><strong>7.14 What do messages such as:</strong></a></p>
3067 <pre>
3068 Message ... UID ... already has UID ...
3069 Message ... UID ... less than ...
3070 Message ... UID ... greater than last ...
3071 Invalid UID ... in message ..., rebuilding UIDs
3072 </pre>
3074 <p><strong>mean?</strong></p>
3076 <dl>
3077 <dd>
3078 Something happened to corrupt the unique identifier regime in the
3079 mailbox. In traditional UNIX-format mailboxes, this can happen if the
3080 user deleted the "DO NOT DELETE" internal message.
3082 <p>This problem is relatively harmless; a new valid unique identifier
3083 regime will be created. The main effect is that any references to the
3084 old UIDs will no longer be useful.</p>
3086 <p>So, unless it is a chronic problem or you feel like debugging, you
3087 can safely ignore these messages.</p>
3088 </dd>
3089 </dl>
3091 <p><a href="#top">Back to top</a></p>
3092 <hr>
3094 <p><a name="7.15"><strong>7.15 What do the error messages:</strong></a></p>
3095 <pre>
3096 Unable to read internal header at ...
3097 Unable to find CRLF at ...
3098 Unable to parse internal header at ...
3099 Unable to parse message date at ...
3100 Unable to parse message flags at ...
3101 Unable to parse message UID at ...
3102 Unable to parse message size at ...
3103 Last message (at ... ) runs past end of file ...
3104 </pre>
3106 <p><strong>mean? I am using mbx format.</strong></p>
3108 <dl>
3109 <dd>
3110 The mbx-format mailbox is corrupted and needs to be repaired.
3112 <p>You should make an effort to find out why the corruption happened.
3113 Was there an obvious system problem (crash or disk failure)? Did the
3114 user accidentally access the file via NFS? Mailboxes don't get
3115 corrupted by themselves; something caused the problem.</p>
3117 <p>Some people have developed automated scripts, but if you're
3118 comfortable using emacs it's pretty easy to fix it manually. Do
3119 <em>not</em> use vi or any other editor unless you are certain that
3120 editor can handle binary!!!</p>
3122 <p>If you are not comfortable with emacs, or if the file is too large
3123 to read with emacs, see the "step-by-step" technique later on for
3124 another way of doing it.</p>
3126 <p>After the word "at" in the error message is the byte position it got
3127 to when it got unhappy with the file, e.g. if you see:</p>
3128 <pre>
3129 Unable to parse internal header at 43921: ne bombastic blurdybloop
3130 </pre>The problem occurs at the 43,931 byte in the file. That's the point you
3131 need to fix. c-client is expecting an internal header at that byte number,
3132 looking something like:
3133 <pre>
3134 6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
3135 </pre>The format of this internal line is:
3136 <pre>
3137 dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
3138 </pre>The only thing that is variable is the "ssss" field, it can be as many
3139 digits as needed. All other fields (inluding the "dd") are fixed width. So,
3140 the easiest thing to do is to look forward in the file for the next internal
3141 header, and delete everything from the error point to that internal header.
3143 <p>Here's what to do if you want to be smarter and do a little bit more
3144 work. Generally, you're in the middle of a message, and there's nothing
3145 wrong with that message. The problem happened in the *previous*
3146 message. So, search back to the previous internal header. Now, remember
3147 that "ssss" field? That's the size of that message.</p>
3149 <p>Mark where you are in the file, move the cursor to the line after
3150 the internal header, and skip that many bytes ("ssss") forward. If
3151 you're at the point of the error in the file, then that message is
3152 corrupt. If you're at a different point, then perhaps the previous
3153 message is corrupt and has a too long size count that "ate" into this
3154 message.</p>
3156 <p>Basically, what you need to do is make sure that all those size
3157 counts are right, and that moving "ssss" bytes from the line after the
3158 internal header will land you at another internal header.</p>
3160 <p>Usually, once you know what you're looking at, it's pretty easy to
3161 work out the corruption, and the best remedial action. Repair scripts
3162 will make the problem go away but may not always do the smartest/best
3163 salvage of the user's data. Manual repair is more flexible and usually
3164 preferable.</p>
3166 <p>Here is a step-by-step technique for fixing corrupt mbx files that's
3167 a bit cruder than the procedure outlined above, but works for any size
3168 file.</p>
3170 <p>In this example, suppose that the corrupt file is INBOX, the error
3171 message is</p>
3172 <pre>
3173 Unable to find CRLF at 132551754
3174 </pre>and the size of the INBOX file is 132867870 bytes.
3176 <p>The first step is to split the mailbox file at the point of the
3177 error:</p>
3179 <ul>
3180 <li>Rename the INBOX file to some other name, such as INBOX.bad.</li>
3182 <li>Copy the first 132,551,754 bytes of INBOX.bad to another file,
3183 such as INBOX.new.</li>
3185 <li>Extract the trailing 316,116 bytes (132867870-132551754) of
3186 INBOX.bad into another file, such as INBOX.tail.</li>
3188 <li>You no longer need INBOX.bad. Delete it.</li>
3189 </ul>In other words, use the number from the "Unable to find CRLF at"
3190 as the point to split INBOX into two new files, INBOX.new and
3191 INBOX.tail.
3193 <p>Now, remove the erroneous data:</p>
3195 <ul>
3196 <li>Verify that you can open INBOX.new in IMAP or Pine.</li>
3198 <li>The last message of INBOX.new is probably corrupted. Copy it to
3199 another file, such as badmsg.1, then delete and expunge that last
3200 message from INBOX.new</li>
3202 <li>Locate the first occurance of text in INBOX.tail which looks like
3203 an internal header, as described above.</li>
3205 <li>Remove all the text which occurs prior to that point, and place
3206 it into another file, such as badmsg.2. Note that in the case of a
3207 single digit date, there is a leading space which must not be removed
3208 (e.g. " 6-Nov-2001" not "6-Nov-2001").</li>
3209 </ul>
3211 <p>Reassemble the mailbox:</p>
3213 <ul>
3214 <li>Append INBOX.tail to INBOX.new.</li>
3216 <li>You no longer need INBOX.tail. Delete it.</li>
3218 <li>Verify that you can open INBOX.new in IMAP or Pine.</li>
3219 </ul>
3221 <p>Reinstall INBOX.new as INBOX:</p>
3223 <ul>
3224 <li>Check to see if you have received any new messages while
3225 repairing INBOX.</li>
3227 <li>If you haven't received any new messages while repairing INBOX,
3228 just rename INBOX.new to INBOX.</li>
3230 <li>If you have received new messages, be sure to copy the new
3231 messages from INBOX to INBOX.new before doing the rename.</li>
3232 </ul>
3234 <p>You now have a working INBOX, as well as two files with corrupted
3235 data (badmsg.1 and badmsg.2). There may be some useful data in the two
3236 badmsg files that you might want to try salvaging; otherwise you can
3237 delete the two badmsg files.</p>
3238 </dd>
3239 </dl>
3241 <p><a href="#top">Back to top</a></p>
3242 <hr>
3244 <p><a name="7.16"><strong>7.16 What do the syslog messages:</strong></a></p>
3245 <pre>
3247 imap/tcp server failing (looping)
3248 pop3/tcp server failing (looping)
3249 </pre>
3251 <p><strong>mean? When it happens, the listed service shuts down. How can I
3252 fix this?</strong></p>
3254 <dl>
3255 <dd>
3256 The error message "server failing (looping), service terminated" is not
3257 from either the IMAP or POP servers. Instead, it comes from inetd, the
3258 daemon which listens for TCP connections to a number of servers,
3259 including the IMAP and POP servers.
3261 <p>inetd has a limit of 40 new server sessions per minute for any
3262 particular service. If more than 40 sessions are initiated in a minute,
3263 inetd will issue the "failing (looping), service terminated" message
3264 and shut down the service for 10 minutes. inetd does this to prevent
3265 system resource consumption by a client which is spawning infinite
3266 numbers of servers. It should be noted that this is a denial of
3267 service; however for some systems the alternative is a crash which
3268 would be a worse denial of service!</p>
3270 <p>For larger server systems, the limit of 40 is much too low. The
3271 limit was established many years ago when a system typically only ran a
3272 few dozen servers.</p>
3274 <p>On some versions of inetd, such as the one distributed with most
3275 versions of Linux, you can modify the <strong>/etc/inetd.conf</strong>
3276 file to have a larger number of servers by appending a period followed
3277 by a number after the <strong>nowait</strong> word for the server
3278 entry. For example, if your existing /etc/inetd.conf line reads:</p>
3279 <pre>
3280 imap stream tcp nowait root /usr/etc/imapd imapd
3281 </pre>try changing it to be:
3282 <pre>
3283 imap stream tcp nowait.100 root /usr/etc/imapd imapd
3284 </pre>Another example (using TCP wrappers):
3285 <pre>
3286 imap stream tcp nowait root /usr/sbin/tcpd imapd
3287 </pre>try changing it to be:
3288 <pre>
3289 imap stream tcp nowait.100 root /usr/sbin/tcpd imapd
3291 </pre>to increase the limit to 100 sessions/minute.
3293 <p>Before making this change, please read the information in "man
3294 inetd" to determine whether or not your inetd has this feature. If it
3295 does not, and you make this change, the likely outcome is that you will
3296 disable IMAP service entirely.</p>
3298 <p>Another way to fix this problem is to edit the inetd.c source code
3299 (provided by your UNIX system vendor) to set higher limits, rebuild
3300 inetd, install the new binary, and reboot your system. This should only
3301 be done by a UNIX system expert. In the inetd.c source code, the limits
3302 <strong>TOOMANY</strong> (normally 40) is the maximum number of new
3303 server sessions permitted per minute, and <strong>RETRYTIME</strong>
3304 (normally 600) is the number of seconds inetd will shut down the server
3305 after it exceeds TOOMANY.</p>
3306 </dd>
3307 </dl>
3309 <p><a href="#top">Back to top</a></p>
3310 <hr>
3312 <p><a name="7.17"><strong>7.17 What does the syslog message:</strong>
3313 <tt>Mailbox lock file /tmp/.600.1df3 open failure: Permission
3314 denied</tt> <strong>mean?</strong></a></p>
3316 <dl>
3317 <dd>
3318 This usually means that some "helpful" security script person has
3319 protected /tmp so that it is no longer world-writeable. /tmp must be
3320 world-writeable because lots of applications use it for scratch space.
3321 To fix this, do
3322 <pre>
3323 chmod 1777 /tmp
3325 </pre>as root.
3327 <p>If that isn't the answer, check the protection of the named file. If
3328 it is something other than 666, then either someone is hacking or some
3329 "helpful" person modified the code to have a different default lock
3330 file protection.</p>
3331 </dd>
3332 </dl>
3334 <p><a href="#top">Back to top</a></p>
3335 <hr>
3337 <p><a name="7.18"><strong>7.18 What do the syslog messages:</strong></a></p>
3338 <pre>
3339 Command stream end of file, while reading line user=... host=...
3340 Command stream end of file, while reading char user=... host=...
3341 Command stream end of file, while writing text user=... host=...
3342 </pre>
3344 <p><strong>mean?</strong></p>
3346 <dl>
3347 <dd>
3348 This message occurs when the session is disconnected without a proper
3349 LOGOUT (IMAP) or QUIT (POP) command being received by the server first.
3351 <p>In many cases, this is perfectly normal; many client implementations
3352 are impolite and do this. Some programmers think this sort of rudeness
3353 is "more efficient".</p>
3355 <p>The condition could, however, indicate a client or network
3356 connectivity problem. The server has no way of knowing whether there's
3357 a problem or just a rude client, so it issues this message instead of a
3358 Logout.</p>
3360 <p>Certain inferior losing clients disconnect abruptly after a failed
3361 login, and instead of saying that the login failed, just say that they
3362 can't access the mailbox. They then complain to the system manager, who
3363 looks in the syslog and finds this message. Not very helpful, eh? See
3364 the answer to the <a href="#7.4">Why can't I log in to the server? The
3365 user name and password are right!</a> question.</p>
3367 <p>If the user isn't reporting a problem, you can probably ignore this
3368 message.</p>
3369 </dd>
3370 </dl>
3372 <p><a href="#top">Back to top</a></p>
3373 <hr>
3375 <p><a name="7.19"><strong>7.19 Why did my POP or IMAP session suddenly
3376 disconnect? The syslog has the message:</strong> <tt>Killed (lost
3377 mailbox lock) user=... host=...</tt></a></p>
3379 <dl>
3380 <dd>
3381 This message only happens when either the traditional UNIX mailbox
3382 format or MMDF format is in use. This format only allows one session to
3383 have the mailbox open read/write at a time.
3385 <p>The servers assume that if a second session attempts to open the
3386 mailbox, that means that the first session is probably owned by an
3387 abandoned client. The common scenario here is a user who leaves his
3388 client running at the office, and then tries to read his mail from
3389 home. Through an internal mechanism called <em>kiss of death</em>, the
3390 second session requests the first session to kill itself. When the
3391 first session receives the "kiss of death", it issues the "Killed (lost
3392 mailbox lock)" syslog message and terminates. The second session then
3393 seizes read/write access, and becomes the new "first" session.</p>
3395 <p>Certain poorly-designed clients routinely open multiple sessions to
3396 the same mailbox; the users of those clients tend to get this message a
3397 lot.</p>
3399 <p>Another cause of this message is a background "check for new mail"
3400 task which does its work by opening a POP session to server every few
3401 seconds. They do this because POP doesn't have a way to announce new
3402 mail.</p>
3404 <p>The solution to both situations is to replace the client with a good
3405 online IMAP client such as Pine. Life is too short to waste on POP
3406 clients and poorly-designed IMAP clients.</p>
3407 </dd>
3408 </dl>
3410 <p><a href="#top">Back to top</a></p>
3411 <hr>
3413 <p><a name="7.20"><strong>7.20 Why does my IMAP client show all the files on the
3414 system, recursively from the UNIX root directory?</strong></a><br>
3415 <a name="7.21"><strong>7.21 Why does my IMAP client show all of my files,
3416 recursively from my UNIX home directory?</strong></a></p>
3418 <dl>
3419 <dd>
3420 A well-written client should only show one level of hierarchy and then
3421 stop, awaiting explicit user action before going lower. However, some
3422 poorly-designed clients will recursively list all files, which may be a
3423 very long list (especially if you have symbolic links to directories
3424 that create a loop in the filesystem graph!).
3426 <p>This behavior has also been observed in some third-party c-client
3427 drivers, including maildir drivers. Consequently, this problem has even
3428 been observed in Pine. It is important to understand that this is not a
3429 problem in Pine or c-client; it is a problem in the third-party driver.
3430 A Pine built without that third-party driver will not have this
3431 problem.</p>
3433 <p>See also the answer to <a href="#7.73">Why does my IMAP client show
3434 all my files in my home directory?</a></p>
3435 </dd>
3436 </dl>
3438 <p><a href="#top">Back to top</a></p>
3439 <hr>
3441 <p><a name="7.22"><strong>7.22 Why does my IMAP client show that I have
3442 mailboxes named "#mhinbox", "#mh", "#shared", "#ftp", "#news", and
3443 "#public"?</strong></a></p>
3445 <dl>
3446 <dd>
3447 These are IMAP namespace names. They represent other hierarchies in
3448 which messages may exist. These hierarchies may not necessarily exist
3449 on a server, but the namespace name is still in the namespace list in
3450 order to mark it as reserved.
3452 <p>A few poorly-designed clients display all namespace names as if they
3453 were top-level mailboxes in a user's list of mailboxes, whether or not
3454 they actually exist. This is a flaw in those clients.</p>
3455 </dd>
3456 </dl>
3458 <p><a href="#top">Back to top</a></p>
3459 <hr>
3461 <p><a name="7.23"><strong>7.23 Why does my IMAP client show all my files in my
3462 home directory?</strong></a></p>
3464 <dl>
3465 <dd>
3466 As distributed, the IMAP server is connected to your home directory by
3467 default. It has no way of knowing what you might call "mail" as opposed
3468 to "some other file"; in fact, you can use IMAP to access any file.
3470 <p>Most clients have an option to configure your connected directory on
3471 the IMAP server. For example, in Pine you can specify this as the
3472 "Path" in your folder-collection, e.g.</p>
3473 <pre>
3474 Nickname : Secondary Folders
3475 Server : imap.example.com
3476 Path : mail/
3477 View :
3478 </pre>In this example, the user is connected to the "mail" subdirectory of
3479 his home directory.
3481 <p>Other servers call this the "folder prefix" or similar term.</p>
3483 <p>It is possible to modify the IMAP server so that all users are
3484 automatically connected to some other directory, e.g. a subdirectory of
3485 the user's home directory. Read the file CONFIG for more details.</p>
3486 </dd>
3487 </dl>
3489 <p><a href="#top">Back to top</a></p>
3490 <hr>
3492 <p><a name="7.24"><strong>7.24 Why is there a long delay before I get connected
3493 to the IMAP or POP server, no matter what client I use?</strong></a></p>
3495 <dl>
3496 <dd>
3497 There are two common occurances of this problem:
3499 <ul>
3500 <li>You are running a system (e.g. certain versions of Linux) which
3501 by default attempts to connect to an "IDENT" protocol (port 113)
3502 server on your client. However, a firewall or NAT box is blocking
3503 connections to that port, so the connection attempt times out.
3505 <p>The IDENT protocol is a well-known bad idea that does not
3506 deliver any real security but causes incredible problems. The idea
3507 is that this will give the server a record of the user name, or at
3508 least what some program listening on port 113 says is the user
3509 name. So, if somebody coming from port nnnnn on a system does
3510 something bad, IDENT may give you the userid of the bad guy.</p>
3512 <p>The problem is, IDENT is only meaningful on a timesharing system
3513 which has an administrator who is privileged and users who are not.
3514 It is of no value on a personal system which has no separate
3515 concept of "system administrator" vs. "unprivileged user".</p>
3517 <p>On either type of system, security-minded people either turn
3518 IDENT off or replace it with an IDENT server that lies. Among other
3519 things, IDENT gives spammers the ability to harvest email addresses
3520 from anyone who connects to a web page.</p>
3522 <p>This problem has been showing up quite frequently on systems
3523 which use xinetd instead of inetd. Look for files named
3524 /etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d, and
3525 /etc/xinetd.d/ipop3d. In those files, look for lines containing
3526 "USERID", e.g.</p>
3527 <pre>
3528 log_on_success += USERID
3529 </pre>Hunt down such lines, and delete them ruthlessly from all files in
3530 which they occur. Don't be shy about it.
3531 </li>
3533 <li>The DNS is taking a long time to do a reverse DNS (PTR record)
3534 lookup of the IP address of your client. This is a problem in your
3535 DNS, which either you or you ISP need to resolve. Ideally, the DNS
3536 should return the client's name; but if it can't it should at least
3537 return an error quickly.</li>
3538 </ul>
3540 <p>As you may have noticed, neither of these are actual problems in the
3541 IMAP or POP servers; they are configuration issues with either your
3542 system or your network infrastructure. If this is all new to you, run
3543 (don't walk) to the nearest technical bookstore and get yourself a good
3544 pedagogical text on system administration for the type of system you
3545 are running.</p>
3546 </dd>
3547 </dl>
3549 <p><a href="#top">Back to top</a></p>
3550 <hr>
3552 <p><a name="7.25"><strong>7.25 Why is there a long delay in Pine or any other
3553 c-client based application call before I get connected to the IMAP
3554 server? The hang seems to be in the c-client mail_open() call. I don't
3555 have this problem with any other IMAP client. There is no delay
3556 connecting to a POP3 or NNTP server with mail_open().</strong></a></p>
3558 <dl>
3559 <dd>
3560 By default, the c-client library attempts to make a connection through
3561 rsh (and ssh, if you enable that). If the command:
3562 <pre>
3563 rsh imapserver exec /etc/rimapd
3565 </pre>(or ssh if that is enabled) returns with a "* PREAUTH" response, it
3566 will use the resulting rsh session as the IMAP session and not require an
3567 authentication step on the server.
3569 <p>Unfortunately, rsh has a design error that treats "TCP connection
3570 refused" as "temporary failure, try again"; it expects the "rsh not
3571 allowed" case to be implemented as a successful connection followed by
3572 an error message and close the connection.</p>
3574 <p>It must be emphasized that this is a bug in rsh. It is <em>not</em>
3575 a bug in the IMAP toolkit.</p>
3577 <p>The use of rsh can be disabled in any the following ways:</p>
3579 <ul>
3580 <li>You can disable it for this particular session by either:
3582 <ul>
3583 <li>setting an explicit port number in the mailbox name, e.g.
3584 <pre>
3585 {imapserver.foo.com:143}INBOX
3586 </pre>
3587 </li>
3589 <li>using SSL (the /ssl switch)</li>
3590 </ul>
3591 </li>
3593 <li>You can disable rsh globally by setting the rsh timeout value to
3594 0 with the call:
3595 <pre>
3596 mail_parameters (NIL,SET_RSHTIMEOUT,0);
3597 </pre>
3598 </li>
3599 </ul>
3600 </dd>
3601 </dl>
3603 <p><a href="#top">Back to top</a></p>
3604 <hr>
3606 <p><a name="7.26"><strong>7.26 Why does a message sometimes get split into two
3607 or more messages on my SUN system?</strong></a></p>
3609 <dl>
3610 <dd>
3611 This is caused by an interaction of two independent design problems in
3612 SUN mail software. The first problem is that the "forward message"
3613 option in SUN's <em>mail tool</em> program includes the internal "From
3614 " header line in the text that it forwarded. This internal header line
3615 is specific to traditional UNIX mailbox files and is not suitable for
3616 use in forwarded messages.
3618 <p>The second problem is that the mail delivery agent assumes that mail
3619 reading programs will not use the traditional UNIX mailbox format but
3620 instead an incompatible variant that depends upon a
3621 <em>Content-Length:</em> message header. Content-Length is widely
3622 recognized to have been a terrible mistake, and is no longer
3623 recommended for use in mail (it is used in other facilities that use
3624 MIME).</p>
3626 <p>One symptom of the problem is that under certain circumstances, a
3627 message may get broken up into several messages. I'm also aware of
3628 security bugs caused by programs that foolishly trust "Content-Length:"
3629 headers with evil values.</p>
3631 <p>To fix the mailer on your system, edit your sendmail.cf to change
3632 the <strong>Mlocal</strong> line to have the <strong>-E</strong> flag.
3633 A typical entry will lool like:</p>
3634 <pre>
3635 Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20,
3636 A=mail.local -d $u
3637 </pre>This fix will also work around the problem with mail tool, because it
3638 will insert a ">" before the internal header line to prevent it from being
3639 interpreted by mail reading software as an internal header line.
3640 </dd>
3641 </dl>
3643 <p><a href="#top">Back to top</a></p>
3644 <hr>
3646 <p><a name="7.27"><strong>7.27 Why did my POP or IMAP session suddenly
3647 disconnect? The syslog has the message:</strong></a></p>
3648 <pre>
3649 Autologout user=<...my user name...> host=<...my client system...>
3651 </pre>
3653 <dl>
3654 <dd>
3655 This is a problem in your client.
3657 <p>In the case of IMAP, it failed to communicate with the IMAP server
3658 for over 30 minutes; in the case of POP, it failed to communicate with
3659 the POP server for over 10 minutes.</p>
3660 </dd>
3661 </dl>
3663 <p><a href="#top">Back to top</a></p>
3664 <hr>
3666 <p><a name="7.28"><strong>7.28 What does the UNIX error message:</strong>
3667 <tt>TLS/SSL failure: myserver: SSL negotiation failed</tt>
3668 <strong>mean?</strong></a><br>
3669 <a name="7.29"><strong>7.29 What does the PC error message:</strong>
3670 <tt>TLS/SSL failure: myserver: Unexpected TCP input disconnect</tt>
3671 <strong>mean?</strong></a></p>
3673 <dl>
3674 <dd>
3675 This usually means that an attempt to negotiate TLS encryption via the
3676 STARTTLS command failed, because the server advertises STARTTLS
3677 functionality, but doesn't actually have it (e.g. because no
3678 certificates are installed).
3680 <p>Use the /notls option in the mailbox name to disable TLS
3681 negotiation.</p>
3682 </dd>
3683 </dl>
3685 <p><a href="#top">Back to top</a></p>
3686 <hr>
3688 <p><a name="7.30"><strong>7.30 What does the error message:</strong> <tt>TLS/SSL
3689 failure: myserver: Server name does not match certificate</tt>
3690 <strong>mean?</strong></a></p>
3692 <dl>
3693 <dd>
3694 An SSL or TLS session encryption failed because the server name in the
3695 server's certificate does not match the name that you gave it. This
3696 could indicate that the server is not really the system you think that
3697 it is, but can be also be called if you gave a nickname for the server
3698 or name that was not fully-qualified. You must use the fully-qualified
3699 domain name for the server in order to validate its certificate
3701 <p>Use the /novalidate-cert option in the mailbox name to disable
3702 validation of the certificate.</p>
3703 </dd>
3704 </dl>
3706 <p><a href="#top">Back to top</a></p>
3707 <hr>
3709 <p><a name="7.31"><strong>7.31 What does the UNIX error message:</strong>
3710 <tt>TLS/SSL failure: myserver: self-signed certificate</tt>
3711 <strong>mean?</strong></a><br>
3712 <a name="7.32"><strong>7.32 What does the PC error message:</strong>
3713 <tt>TLS/SSL failure: myserver: Self-signed certificate or untrusted
3714 authority</tt> <strong>mean?</strong></a></p>
3716 <dl>
3717 <dd>
3718 An SSL or TLS session encryption failed because your server's
3719 certificate is "self-signed"; that is, it is not signed by any
3720 Certificate Authority (CA) and thus can not be validated. A CA-signed
3721 certificate costs money, and some smaller sites either don't want to
3722 pay for it or haven't gotten one yet. The bad part about this is that
3723 this means there is no guarantee that the server is really the system
3724 you think that it is.
3726 <p>Use the /novalidate-cert option in the mailbox name to disable
3727 validation of the certificate.</p>
3728 </dd>
3729 </dl>
3731 <p><a href="#top">Back to top</a></p>
3732 <hr>
3734 <p><a name="7.33"><strong>7.33 What does the UNIX error message:</strong>
3735 <tt>TLS/SSL failure: myserver: unable to get local issuer
3736 certificate</tt> <strong>mean?</strong></a></p>
3738 <dl>
3739 <dd>
3740 An SSL or TLS session encryption failed because your system does not
3741 have the Certificate Authority (CA) certificates installed on OpenSSL's
3742 certificates directory. On most systems, this directory is
3743 /usr/local/ssl/certs). As a result, it is not possible to validate the
3744 server's certificate.
3746 <p>If CA certificates are properly installed, you should see
3747 factory.pem and about a dozen other .pem names such as
3748 thawteCb.pem.</p>
3750 <p>As a workaround, you can use the /novalidate-cert option in the
3751 mailbox name to disable validation of the certificate; however, note
3752 that you are then vulnerable to various security attacks by bad
3753 guys.</p>
3755 <p>The correct fix is to copy all the files from the certs/ directory
3756 in the OpenSSL distribution to the /usr/local/ssl/certs (or whatever)
3757 directory. Note that you need to do this after building OpenSSL,
3758 because the OpenSSL build creates a number of needed symbolic links.
3759 For some bizarre reason, the OpenSSL "make install" doesn't do this for
3760 you, so you must do it manually.</p>
3761 </dd>
3762 </dl>
3764 <p><a href="#top">Back to top</a></p>
3765 <hr>
3767 <p><a name="7.34"><strong>7.34 Why does reading certain messages hang when using
3768 Netscape? It works fine with Pine!</strong></a></p>
3770 <dl>
3771 <dd>
3772 There are two possible causes.
3774 <p>Check the mail syslog. If you see the message "Killed (lost mailbox
3775 lock)" for the impacted user(s), read the FAQ entry regarding that
3776 message.</p>
3778 <p>Check the affected mailbox to see if there are embedded NUL
3779 characters in the message. NULs in message texts are a technical
3780 violation of both the message format and IMAP specifications. Most
3781 clients don't care, but apparently Netscape does.</p>
3783 <p>You can work around this by rebuilding imapd with the
3784 <strong>NETSCAPE_BRAIN_DAMAGE</strong> option set (see
3785 src/imapd/Makefile); this will cause imapd to convert all NULs to 0x80
3786 characters. A better solution is to enable the feature in your MTA to
3787 MIME-convert messages with binary content. See the documentation for
3788 your MTA for how to do this.</p>
3789 </dd>
3790 </dl>
3792 <p><a href="#top">Back to top</a></p>
3793 <hr>
3795 <p><a name="7.35"><strong>7.35 Why does Netscape say that there's a problem with
3796 the IMAP server and that I should "Contact your mail server
3797 administrator."?</strong></a></p>
3799 <dl>
3800 <dd>
3801 Certain versions of Netscape do this when you click the Manage Mail
3802 button, which uses an undocumented feature of Netscape's proprietary
3803 IMAP server.
3805 <p>You can work around this by rebuilding imapd with the
3806 <strong>NETSCAPE_BRAIN_DAMAGE</strong> option set (see
3807 src/imapd/Makefile) to a URL that points either to an alternative IMAP
3808 client (e.g. Pine) or perhaps to a homebrew mail account management
3809 page.</p>
3810 </dd>
3811 </dl>
3813 <p><a href="#top">Back to top</a></p>
3814 <hr>
3816 <p><a name="7.36"><strong>7.36 Why is one user creating huge numbers of IMAP or
3817 POP server sessions?</strong></a></p>
3819 <dl>
3820 <dd>The user is probably using Outlook Express, Eudora, or a similar
3821 program. See the answer to the <a href="#7.5">Help! My load average is
3822 soaring and I see hundreds of POP and IMAP servers, many logged in as the
3823 same user!</a> question.</dd>
3824 </dl>
3826 <p><a href="#top">Back to top</a></p>
3827 <hr>
3829 <p><a name="7.37"><strong>7.37 Why don't I get any new mail notifications from
3830 Outlook Express or Outlook after a while?</strong></a></p>
3832 <dl>
3833 <dd>
3834 This is a known bug in Outlook Express. Microsoft is aware of the
3835 problem and its cause. They have informed us that they do not have any
3836 plans to fix it at the present time.
3838 <p>The problem is also reported in Outlook 2000, but not verified.</p>
3840 <p>Outlook Express uses the IMAP IDLE command to avoid having to "ping"
3841 the server every few minutes for new mail. Unfortunately, Outlook
3842 Express overlooks the part in the IDLE specification which requires
3843 that a client terminate and restart the IDLE before the IMAP 30 minute
3844 inactivity autologout timer triggers.</p>
3846 <p>When this happens, Outlook Express displays "Not connected" at the
3847 bottom of the window. Since it's no longer connected to the IMAP
3848 server, it isn't going to notice any new mail.</p>
3850 <p>As soon as the user does anything that would cause an IMAP
3851 operation, Outlook Express will reconnect and new mail will flow again.
3852 If the user does something that causes an IMAP operation at least every
3853 29 minutes, the problem won't happen.</p>
3855 <p>Modern versions of imapd attempt to work around the problem by
3856 automatically reporting fake new mail after 29 minutes. This causes
3857 Outlook Express to exit the IDLE state; as soon as this happens imapd
3858 revokes the fake new mail. As long as this behavior isn't known to
3859 cause problems with other clients, this workaround will remain in
3860 imapd.</p>
3861 </dd>
3862 </dl>
3864 <p><a href="#top">Back to top</a></p>
3865 <hr>
3867 <p><a name="7.38"><strong>7.38 Why don't I get any new mail notifications from
3868 Entourage?</strong></a></p>
3870 <dl>
3871 <dd>
3872 This is a known bug in Entourage.
3874 <p>You built an older version of imapd with the
3875 <strong>MICROSOFT_BRAIN_DAMAGE</strong> option set, in order to disable
3876 support for the IDLE command. However, Entourage won't get new mail
3877 unless IDLE command support exists.</p>
3879 <p>Note: the MICROSOFT_BRAIN_DAMAGE option no longer exists in modern
3880 versions, as the Outlook Express problem which it attempted to solve
3881 has been worked around in another way.</p>
3882 </dd>
3883 </dl>
3885 <p><a href="#top">Back to top</a></p>
3886 <hr>
3888 <p><a name="7.39"><strong>7.39 Why doesn't Entourage work at
3889 all?</strong></a></p>
3891 <dl>
3892 <dd>
3893 It's hard to know. Entourage breaks almost every rule in the book for
3894 IMAP. It is highly instructive to do a packet trace on Entourage, as an
3895 example of how <em>not</em> to use IMAP. It does things like STATUS
3896 (MESSAGES) on the currently selected mailbox and re-fetching the same
3897 static data over and over again.
3899 <p>It seems that every time we understand what it is doing wrong in
3900 Entourage and come up with a workaround, we learn about something else
3901 that's broken.</p>
3903 <p>Try building imapd with the <strong>ENTOURAGE_BRAIN_DAMAGE</strong>
3904 option set, in order to disable the diagnostic that occurs when doing
3905 STATUS on the currently selected mailbox.</p>
3906 </dd>
3907 </dl>
3909 <p><a href="#top">Back to top</a></p>
3910 <hr>
3912 <p><a name="7.40"><strong>7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work
3913 at all?</strong></a></p>
3915 <dl>
3916 <dd>
3917 This is a bug in NSNOTIFY; it doesn't handle unsolicited data from the
3918 server correctly.
3920 <p>Fortunately, there is no reason to use this program with IMAP;
3921 NSNOTIFY is a polling program to let you know when new mail has
3922 appeared in your maildrop. This is necessary with POP; but since IMAP
3923 dynamically announces new mail in the session you're better off (and
3924 will actually cause less load on the server!) keeping your mail reading
3925 program's IMAP session open and let IMAP do the notifying for you.</p>
3927 <p>Consequently, the recommended fix for the NSNOTIFY problem is to
3928 delete the NSNOTIFY binary.</p>
3929 </dd>
3930 </dl>
3932 <p><a href="#top">Back to top</a></p>
3933 <hr>
3935 <p><a name="7.41"><strong>7.41 Why can't I connect via SSL to Eudora? It says
3936 the connection has been broken, and in the server syslogs I see "Command
3937 stream end of file".</strong></a></p>
3939 <dl>
3940 <dd>There is a report that you can fix the problem by going into Eudora's
3941 advanced network configuration menu and increasing the network buffer
3942 size to 8192.</dd>
3943 </dl>
3945 <p><a href="#top">Back to top</a></p>
3946 <hr>
3948 <p><a name="7.42"><strong>7.42 Sheesh. Aren't there <em>any</em> good IMAP
3949 clients out there?</strong></a></p>
3951 <dl>
3952 <dd>
3953 Yes!
3955 <p>Pine is a <em>wonderful</em> client. It's fast, it uses IMAP well,
3956 and it generates text mail (life is too short to waste on HTML mail).
3957 Also, there are some really wonderful things in progress in the Pine
3958 world.</p>
3960 <p>There are some good GUI clients out there, mostly from smaller
3961 vendors. Without naming names, look for the vendors who are active in
3962 the IMAP protocol development community, and their products.</p>
3964 <p>Netscape, Eudora, and Outlook <em>can</em> be configured with enough
3965 effort to be good citizens and work well for users, <em>but</em> they
3966 can also be badly misconfigured, and often the misconfiguration is the
3967 default.</p>
3968 </dd>
3969 </dl>
3971 <p><a href="#top">Back to top</a></p>
3972 <hr>
3974 <p><a name="7.43"><strong>7.43 But wait! PC Pine (or other PC program build with
3975 c-client) crashes with the message</strong> <tt>incomplete SecBuffer
3976 exceeds maximum buffer size</tt> <strong>when I use SSL connections.
3977 This is a bug in c-client, right?</strong></a></p>
3979 <dl>
3980 <dd>
3981 It's a bug in the Microsoft SChannel.DLL, which implements SSL.
3982 Microsoft admits it (albeit with an unstatement: "it's not fully RFC
3983 compliant"). The problem is that SChannel indicates that the maximum
3984 SSL packet data size is 5 bytes smaller than the actual maximum. Thus,
3985 any IMAP server which transmits a maximum sized SSL packet will not
3986 work with PC Pine or any other program which uses SChannel.
3988 <p>It can take a while for the problem to show up. The client has to do
3989 something that causes at least 16K of contiguous data. Many clients do
3990 partial fetching, which tends to reduce the number of cases where this
3991 can happen. However, <em>all</em> software which uses SChannel to
3992 support SSL is affected by this bug.</p>
3994 <p>This problem does not affect UNIX code, since OpenSSL is used on
3995 UNIX.</p>
3997 <p>This problem most recently showed up with the CommunigatePro IMAP
3998 server. They have an update which trims down their maximum contiguous
3999 data to less than 16K, in order to work around the problem.</p>
4001 <p>This problem has also shown up with the Exchange IMAP server with
4002 UNIX clients (including Pine built with an older version of c-client)
4003 which sends full-sized 16K SSL packets. Modern c-client works around
4004 the problem by trimming down its maximum outgoing SSL packet size to
4005 8K.</p>
4007 <p>Microsoft has developed a hotfix for this bug. Look up MSKB article
4008 number 300562. Contrary to the article text which implies that this is
4009 a Pine issue, this bug also affect Microsoft Exchange server with *any*
4010 UNIX based client that transmits full-sized SSL payloads.</p>
4011 </dd>
4012 </dl>
4014 <p><a href="#top">Back to top</a></p>
4015 <hr>
4017 <p><a name="7.44"><strong>7.44 My qpopper users keep on getting the DON'T DELETE
4018 THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or IMAP. How
4019 can I fix this?</strong></a></p>
4021 <dl>
4022 <dd>
4023 This is an incompatibility between qpopper and the c-client library
4024 used by Pine, imapd, and ipop[23]d.
4026 <p>Assuming that you want to continue using qpopper, look into
4027 qpopper's <strong>--enable-uw-kludge-flag</strong> configuration flag,
4028 which is documented as "check for and hide UW 'Folder Internal Data'
4029 messages".</p>
4031 <p>The other alternative is to switch from qpopper to ipop3d.</p>
4032 </dd>
4033 </dl>
4035 <p><a href="#top">Back to top</a></p>
4036 <hr>
4038 <p><a name="7.45"><strong>7.45 Help! I installed the servers but I can't connect
4039 to them from my client!</strong></a></p>
4041 <dl>
4042 <dd>
4043 Review the installation instructions carefully. Make sure that you have
4044 not skipped any of the steps. Make sure that you have made the correct
4045 entries in the configuration files; pay careful attention to the exact
4046 spelling of the service names and the path names. Make sure as well
4047 that you have properly restarted inetd.
4049 <p>If you have a system with Yellow Pages/NIS such as Solaris, have you
4050 updated the service names there as well as in /etc/services?</p>
4052 <p>If you have a system with TCP wrappers, have you properly updated
4053 the TCP wrapper files (e.g. /etc/hosts.allow and /etc/hosts.deny) for
4054 the servers?</p>
4056 <p>If you have a system which uses xinetd instead of inetd, have you
4057 made sure that you have made the correct corresponding xinetd changes
4058 for those services?</p>
4060 <p>Try telneting to the server port (143 for IMAP, 110 for POP3). If
4061 you get a "refused" error, that probably means that you don't have the
4062 service set up in inetd.conf. If the connection opens and then closes
4063 with no message, the service is set up, but either the path name of the
4064 server binary in inetd.conf is wrong or your TCP wrappers are
4065 configured to deny access.</p>
4067 <p>If you don't know how to make the corresponding changes to these
4068 files, seek the help of a local expert for your system.</p>
4069 </dd>
4070 </dl>
4072 <p><a href="#top">Back to top</a></p>
4073 <hr>
4075 <p><a name="7.46"><strong>7.46 Why do I get the message</strong> <tt>Can not
4076 authenticate to SMTP server: 421 SMTP connection went away!</tt>
4077 <strong>and why did this happen? There was also something about</strong>
4078 <tt>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</tt></a></p>
4080 <dl>
4081 <dd>
4082 Some versions of qmail, including that running on mail.smtp.yahoo.com,
4083 disconnect the SMTP session if you fail to authenticate prior to
4084 attempting to transmit mail. An attempt to authenticate was made, but
4085 it failed because the server had already disconnected.
4087 <p>To work around this, you need to specify /user=... in the host name
4088 specification.</p>
4090 <p>The SECURITY PROBLEM came about because the server advertised the
4091 AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
4092 session, in violation of RFC 4616. This message is just a warning, and
4093 in fact occurred after the server had disconnected.</p>
4094 </dd>
4095 </dl>
4097 <p><a href="#top">Back to top</a></p>
4098 <hr>
4100 <p><a name="7.47"><strong>7.47 Why do I get the message</strong> <tt>SMTP
4101 Authentication cancelled</tt> <strong>and why did this happen? There was
4102 also something about</strong> <tt>SECURITY PROBLEM: insecure server
4103 advertised AUTH=PLAIN</tt></a></p>
4105 <dl>
4106 <dd>
4107 This is a bug in the SMTP server.
4109 <p>Some versions of qmail, including that running on
4110 mail.smtp.yahoo.com, have a bug in their implementation of SASL in
4111 their SMTP server, which renders it non-compliant with the
4112 standard.</p>
4114 <p>If the client does not provide an initial response in the command
4115 line for an authentication mechanism whose profile does not have an
4116 initial challenge, qmail issues a bogus response:</p>
4117 <pre>
4118 334 ok, go on
4119 </pre>The problem is the "ok, go on". This violates RFC 4954's requirement
4120 that the text part in a 334 response be a BASE64 encoded string; in other
4121 words, it is a protocol syntax error.
4123 <p>In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the
4124 encoded string have no data. In other words, the appropropiate
4125 standards-compliant server response is "334" followed by a SPACE and a
4126 CRLF.</p>
4128 <p>The SECURITY PROBLEM came about because the server advertised the
4129 AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
4130 session, in violation of RFC 4616. This message is just a warning, and
4131 is not related the "Authentication cancelled" problem.</p>
4132 </dd>
4133 </dl>
4135 <p><a href="#top">Back to top</a></p>
4136 <hr>
4138 <p><a name="7.48"><strong>7.48 Why do I get the message</strong> <tt>Invalid
4139 base64 string</tt> <strong>when I try to authenticate to a Cyrus
4140 server?</strong></a></p>
4142 <dl>
4143 <dd>
4144 This slightly misleading message is the way that a Cyrus server
4145 indicates that an authentication exchange was cancelled. It is not
4146 indicative of a bug or protocol violation.
4148 <p>The most common reason that this happens is if the Cyrus server
4149 offers Kerberos authentication, c-client is built with Kerberos
4150 support, but your client system is not within the Kerberos realm. In
4151 this case, the client code will try to authenticate via Kerberos, fail
4152 to get the Kerberos credentials, cancel the authentication attempt, and
4153 try the next available authentication technology.</p>
4154 </dd>
4155 </dl>
4157 <p><a href="#top">Back to top</a></p>
4158 <hr>
4160 <p><br></p>
4162 <h2><a name="additional">8. Where to Go For Additional Information</a></h2>
4163 <hr>
4165 <p><a name="8.1"><strong>8.1 Where can I go to ask questions?</strong></a><br>
4166 <a name="8.2"><strong>8.2 I have some ideas for enhancements to IMAP. Where
4167 should I go?</strong></a></p>
4169 <dl>
4170 <dd>
4171 If you have questions about the IMAP protocol, or want to participate
4172 in discussions of future directions of the IMAP protocol, the
4173 appropriate mailing list is imap-protocol@u.washington.edu. You can
4174 subscribe to this list via <a href=
4175 "mailto:imap-protocol-request@u.washington.edu"><tt>imap-protocol-request@u.washington.edu</tt></a>
4177 <p>If you have questions about this software, you can send me email
4178 directly or use the imap-uw@u.washington.edu mailing list. You can
4179 subscribe to this list via <a href=
4180 "mailto:imap-uw-request@u.washington.edu"><tt>imap-uw-request@u.washington.edu</tt></a></p>
4182 <p>If you have general questions about the use of IMAP software
4183 (not specific to the UW IMAP toolkit) use the
4184 imap-use@u.washington.edu mailing list. You can subscribe to
4185 this list via <a href=
4186 "mailto:imap-use-request@u.washington.edu"><tt>imap-use-request@u.washington.edu</tt></a></p>
4188 <p>You must be a subscriber to post to these lists. As an
4189 alternative, you can use the
4190 <strong>comp.mail.imap</strong> newsgroup.</p>
4191 </dd>
4192 </dl>
4194 <p><a href="#top">Back to top</a></p>
4195 <hr>
4197 <p><a name="8.3"><strong>8.3 Where can I read more about IMAP and other email
4198 protocols?</strong></a></p>
4200 <dl>
4201 <dd>We recommend <em>Internet Email Protocols: A Developer's Guide</em>,
4202 by Kevin Johnson, published by Addison Wesley, ISBN 0-201-43288-9.</dd>
4203 </dl>
4205 <p><a href="#top">Back to top</a></p>
4206 <hr>
4208 <p><a name="8.4"><strong>8.4 Where can I find out more about setting up and
4209 administering an IMAP server?</strong></a></p>
4211 <dl>
4212 <dd>
4213 We recommend <em>Managing IMAP</em>, by Dianna Mullet & Kevin
4214 Mullet, published by O'Reilly, ISBN 0-596-00012-X.
4216 <p>This book also has an excellent comparison of the UW and Cyrus IMAP
4217 servers.<br></p>
4218 </dd>
4219 </dl>
4221 <p><a href="#top">Back to top</a></p>
4223 <p>Last Updated: 15 November 2007</p>
4225 <!--chtml include "//imap/incs/bottom.inc"-->