imapext-2007
diff docs/FAQ.html @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/docs/FAQ.html Mon Sep 14 15:17:45 2009 +0900 1.3 @@ -0,0 +1,4226 @@ 1.4 +<!-- 1.5 + * ======================================================================== 1.6 + * Copyright 1988-2007 University of Washington 1.7 + * 1.8 + * Licensed under the Apache License, Version 2.0 (the "License"); 1.9 + * you may not use this file except in compliance with the License. 1.10 + * You may obtain a copy of the License at 1.11 + * 1.12 + * http://www.apache.org/licenses/LICENSE-2.0 1.13 + * 1.14 + * 1.15 + * ======================================================================== 1.16 + * 1.17 +--> 1.18 + 1.19 +<!--chtml set title="IMAP Toolkit Frequently Asked Questions"--> 1.20 +<!--chtml include "//imap/incs/top.inc"--> 1.21 + 1.22 + <h2>Table of Contents</h2> 1.23 + 1.24 + <ul> 1.25 + <li> 1.26 + <a href="#general">1. General/Software Feature Questions</a> 1.27 + 1.28 + <ul> 1.29 + <li><a href="#1.1">1.1 Can I set up a POP or IMAP server on 1.30 + UNIX/Linux/OSF/etc.?</a></li> 1.31 + 1.32 + <li><a href="#1.2">1.2 I am currently using qpopper as my POP3 server 1.33 + on UNIX. Do I need to replace it with ipop3d in order to run 1.34 + imapd?</a></li> 1.35 + 1.36 + <li><a href="#1.3">1.3 Can I set up a POP or IMAP server on Windows 1.37 + XP, 2000, NT, Me, 98, or 95?</a></li> 1.38 + 1.39 + <li><a href="#1.4">1.4 Can I set up a POP or IMAP server on Windows 1.40 + 3.1 or DOS?</a></li> 1.41 + 1.42 + <li><a href="#1.5">1.5 Can I set up a POP or IMAP server on 1.43 + Macintosh?</a></li> 1.44 + 1.45 + <li><a href="#1.6">1.6 Can I set up a POP or IMAP server on 1.46 + VAX/VMS?</a></li> 1.47 + 1.48 + <li><a href="#1.7">1.7 Can I set up a POP or IMAP server on 1.49 + TOPS-20?</a></li> 1.50 + 1.51 + <li><a href="#1.8">1.8 Are hierarchical mailboxes supported?</a></li> 1.52 + 1.53 + <li><a href="#1.9">1.9 Are "dual-use" mailboxes supported?</a></li> 1.54 + 1.55 + <li><a href="#1.10">1.10 Can I have a mailbox that has both messages 1.56 + and sub-mailboxes?</a></li> 1.57 + 1.58 + <li><a href="#1.11">1.11 What is the difference between "mailbox" and 1.59 + "folder"?</a></li> 1.60 + 1.61 + <li><a href="#1.12">1.12 What is the status of 1.62 + internationalization?</a></li> 1.63 + 1.64 + <li><a href="#1.13">1.13 Can I use SSL?</a></li> 1.65 + 1.66 + <li><a href="#1.14">1.14 Can I use TLS and the STARTTLS 1.67 + facility?</a></li> 1.68 + 1.69 + <li><a href="#1.15">1.15 Can I use CRAM-MD5 authentication?</a></li> 1.70 + 1.71 + <li><a href="#1.16">1.16 Can I use APOP authentication?</a></li> 1.72 + 1.73 + <li><a href="#1.17">1.17 Can I use Kerberos V5?</a></li> 1.74 + 1.75 + <li><a href="#1.18">1.18 Can I use PAM for plaintext 1.76 + passwords?</a></li> 1.77 + 1.78 + <li><a href="#1.19">1.19 Can I use Kerberos 5 for plaintext 1.79 + passwords?</a></li> 1.80 + 1.81 + <li><a href="#1.20">1.20 Can I use AFS for plaintext 1.82 + passwords?</a></li> 1.83 + 1.84 + <li><a href="#1.21">1.21 Can I use DCE for plaintext 1.85 + passwords?</a></li> 1.86 + 1.87 + <li><a href="#1.22">1.22 Can I use the CRAM-MD5 database for 1.88 + plaintext passwords?</a></li> 1.89 + 1.90 + <li><a href="#1.23">1.23 Can I disable plaintext passwords?</a></li> 1.91 + 1.92 + <li><a href="#1.24">1.24 Can I disable plaintext passwords on 1.93 + unencrypted sessions, but allow them on encrypted sessions?</a></li> 1.94 + 1.95 + <li><a href="#1.25">1.25 Can I use virtual hosts?</a></li> 1.96 + 1.97 + <li><a href="#1.26">1.26 Can I use RPOP authentication?</a></li> 1.98 + 1.99 + <li><a href="#1.27">1.27 Can I use Kerberos V4?</a></li> 1.100 + 1.101 + <li><a href="#1.28">1.28 Is there support for S/Key or OTP?</a></li> 1.102 + 1.103 + <li><a href="#1.29">1.29 Is there support for NTLM or SPA?</a></li> 1.104 + 1.105 + <li><a href="#1.30">1.30 Is there support for mh?</a></li> 1.106 + 1.107 + <li><a href="#1.31">1.31 Is there support for qmail and the maildir 1.108 + format?</a></li> 1.109 + 1.110 + <li><a href="#1.32">1.32 Is there support for the Cyrus mailbox 1.111 + format?</a></li> 1.112 + 1.113 + <li><a href="#1.33">1.33 Is this software Y2K compliant?</a></li> 1.114 + </ul> 1.115 + </li> 1.116 + 1.117 + <li> 1.118 + <a href="#requirements">2. What Do I Need to Build This Software?</a> 1.119 + 1.120 + <ul> 1.121 + <li><a href="#2.1">2.1 What do I need to build this software with SSL 1.122 + on UNIX?</a></li> 1.123 + 1.124 + <li><a href="#2.2">2.2 What do I need to build this software with 1.125 + Kerberos V on UNIX?</a></li> 1.126 + 1.127 + <li><a href="#2.3">2.3 What do I need to use a C++ compiler with this 1.128 + software to build my own application?</a></li> 1.129 + 1.130 + <li><a href="#2.4">2.4 What do I need to build this software on 1.131 + Windows?</a></li> 1.132 + 1.133 + <li><a href="#2.5">2.5 What do I need to build this software on 1.134 + DOS?</a></li> 1.135 + 1.136 + <li><a href="#2.6">2.6 Can't I use Borland C to build this software 1.137 + on the PC?</a></li> 1.138 + 1.139 + <li><a href="#2.7">2.7 What do I need to build this software on the 1.140 + Mac?</a></li> 1.141 + 1.142 + <li><a href="#2.8">2.8 What do I need to build this software on 1.143 + VMS?</a></li> 1.144 + 1.145 + <li><a href="#2.9">2.9 What do I need to build this software on 1.146 + TOPS-20?</a></li> 1.147 + 1.148 + <li><a href="#2.10">2.10 What do I need to build this software on 1.149 + Amiga or OS/2?</a></li> 1.150 + 1.151 + <li><a href="#2.11">2.11 What do I need to build this software on 1.152 + Windows CE?</a></li> 1.153 + </ul> 1.154 + </li> 1.155 + 1.156 + <li> 1.157 + <a href="#build">3. Build and Configuration Questions</a> 1.158 + 1.159 + <ul> 1.160 + <li><a href="#3.1">3.1 How do I configure the IMAP and POP servers on 1.161 + UNIX?</a></li> 1.162 + 1.163 + <li><a href="#3.2">3.2 I built and installed the servers according to 1.164 + the BUILD instructions. It can't be that easy. Don't I need to write 1.165 + a config file?</a></li> 1.166 + 1.167 + <li><a href="#3.3">3.3 How do I make the IMAP and POP servers look 1.168 + for INBOX at some place other than the mail spool directory?</a></li> 1.169 + 1.170 + <li><a href="#3.4">3.4 How do I make the IMAP server look for 1.171 + secondary folders at some place other than the user's home 1.172 + directory?</a></li> 1.173 + 1.174 + <li><a href="#3.5">3.5 How do I configure SSL?</a></li> 1.175 + 1.176 + <li><a href="#3.6">3.6 How do I configure TLS and the STARTTLS 1.177 + facility?</a></li> 1.178 + 1.179 + <li><a href="#3.7">3.7 How do I build/install OpenSSL and 1.180 + obtain/create certificates for use with SSL?</a></li> 1.181 + 1.182 + <li><a href="#3.8">3.8 How do I configure CRAM-MD5 1.183 + authentication?</a></li> 1.184 + 1.185 + <li><a href="#3.9">3.9 How do I configure APOP 1.186 + authentication?</a></li> 1.187 + 1.188 + <li><a href="#3.10">3.10 How do I configure Kerberos V5?</a></li> 1.189 + 1.190 + <li><a href="#3.11">3.11 How do I configure PAM for plaintext 1.191 + passwords?</a></li> 1.192 + 1.193 + <li><a href="#3.12">3.12 It looks like all I have to do to make the 1.194 + server use Kerberos is to build with PAM on my Linux system, and set 1.195 + it up in PAM for Kerberos passwords. Right?</a></li> 1.196 + 1.197 + <li><a href="#3.13">3.13 How do I configure Kerberos 5 for plaintext 1.198 + passwords?</a></li> 1.199 + 1.200 + <li><a href="#3.14">3.14 How do I configure AFS for plaintext 1.201 + passwords?</a></li> 1.202 + 1.203 + <li><a href="#3.15">3.15 How do I configure DCE for plaintext 1.204 + passwords?</a></li> 1.205 + 1.206 + <li><a href="#3.16">3.16 How do I configure the CRAM-MD5 database for 1.207 + plaintext passwords?</a></li> 1.208 + 1.209 + <li><a href="#3.17">3.17 How do I disable plaintext 1.210 + passwords?</a></li> 1.211 + 1.212 + <li><a href="#3.18">3.18 How do I disable plaintext passwords on 1.213 + unencrypted sessions, but allow them in SSL or TLS sessions?</a></li> 1.214 + 1.215 + <li><a href="#3.19">3.19 How do I configure virtual hosts?</a></li> 1.216 + 1.217 + <li> 1.218 + <a href="#3.20">3.20 Why do I get compiler warning messages such 1.219 + as: 1.220 + 1.221 + <ul> 1.222 + <li>passing arg 3 of `scandir' from incompatible pointer 1.223 + type</li> 1.224 + 1.225 + <li>Pointers are not assignment-compatible.</li> 1.226 + 1.227 + <li>Argument #4 is not the correct type.</li> 1.228 + </ul>during the build?</a> 1.229 + </li> 1.230 + 1.231 + <li> 1.232 + <a href="#3.21">3.21 Why do I get compiler warning messages such 1.233 + as 1.234 + 1.235 + <ul> 1.236 + <li>Operation between types "void(*)(int)" and "void*" is not 1.237 + allowed.</li> 1.238 + 1.239 + <li>Function argument assignment between types "void*" and 1.240 + "void(*)(int)" is not allowed.</li> 1.241 + 1.242 + <li>Pointers are not assignment-compatible.</li> 1.243 + 1.244 + <li>Argument #5 is not the correct type.</li> 1.245 + </ul>during the build?</a> 1.246 + </li> 1.247 + 1.248 + <li> 1.249 + <a href="#3.22">3.22 Why do I get linker warning messages such 1.250 + as: 1.251 + 1.252 + <ul> 1.253 + <li>mtest.c:515: the `gets' function is dangerous and should not 1.254 + be used.</li> 1.255 + </ul>during the build? Isn't this a security bug?</a> 1.256 + </li> 1.257 + 1.258 + <li> 1.259 + <a href="#3.23">3.23 Why do I get linker warning messages such 1.260 + as:</a> 1.261 + 1.262 + <ul> 1.263 + <li>auth_ssl.c:92: the `tmpnam' function is dangerous and should 1.264 + not be used.</li> 1.265 + </ul>during the build? Isn't this a security bug? 1.266 + </li> 1.267 + 1.268 + <li><a href="#3.24">3.24 OK, suppose I see a warning message about a 1.269 + function being "dangerous and should not be used" for something other 1.270 + than this gets() or tmpnam() call?</a></li> 1.271 + </ul> 1.272 + </li> 1.273 + 1.274 + <li> 1.275 + <a href="#operation">4. Operational Questions</a> 1.276 + 1.277 + <ul> 1.278 + <li><a href="#4.1">4.1 How can I enable anonymous IMAP 1.279 + logins?</a></li> 1.280 + 1.281 + <li><a href="#4.2">4.2 How do I set up an alert message that each 1.282 + IMAP user will see?</a></li> 1.283 + 1.284 + <li><a href="#4.3">4.3 How does the c-client library choose which of 1.285 + its several mechanisms to use to establish an IMAP connection to the 1.286 + server? I noticed that it can connect on port 143, port 993, via rsh, 1.287 + and via ssh.</a></li> 1.288 + 1.289 + <li><a href="#4.4">4.4 I am using a TLS-capable IMAP server, so I 1.290 + don't need to use /ssl to get encryption. However, I want to be 1.291 + certain that my session is TLS encrypted before I send my password. 1.292 + How to I do this?</a></li> 1.293 + 1.294 + <li><a href="#4.5">4.5 How do I use one of the alternative formats 1.295 + described in the formats.txt document? In particular, I hear that mbx 1.296 + format will give me better performance and allow shared 1.297 + access.</a></li> 1.298 + 1.299 + <li><a href="#4.6">4.6 How do I set up shared mailboxes?</a></li> 1.300 + 1.301 + <li><a href="#4.7">4.7 How can I make the server syslogs go to 1.302 + someplace other than the mail syslog?</a></li> 1.303 + </ul> 1.304 + </li> 1.305 + 1.306 + <li> 1.307 + <a href="#security">5. Security Questions</a> 1.308 + 1.309 + <ul> 1.310 + <li><a href="#5.1">5.1 I see that the IMAP server allows access to 1.311 + arbitary files on the system, including /etc/passwd! How do I disable 1.312 + this?</a></li> 1.313 + 1.314 + <li><a href="#5.2">5.2 I've heard that IMAP servers are insecure. Is 1.315 + this true?</a></li> 1.316 + 1.317 + <li><a href="#5.3">5.3 How do I know that I have the most secure 1.318 + version of the server?</a></li> 1.319 + 1.320 + <li><a href="#5.4">5.4 I see all these strcpy() and sprintf() calls, 1.321 + those are unsafe, aren't they?</a></li> 1.322 + 1.323 + <li><a href="#5.5">5.5 Those /tmp lock files are protected 666, is 1.324 + that really right?</a></li> 1.325 + </ul> 1.326 + </li> 1.327 + 1.328 + <li> 1.329 + <a href="#strange">6. <i>Why Did You Do This Strange Thing?</i> 1.330 + Questions</a> 1.331 + 1.332 + <ul> 1.333 + <li><a href="#6.1">6.1 Why don't you use GNU autoconfig / automake / 1.334 + autoblurdybloop?</a></li> 1.335 + 1.336 + <li><a href="#6.2">6.2 Why do you insist upon a build with -g? 1.337 + Doesn't it waste disk and memory space?</a></li> 1.338 + 1.339 + <li><a href="#6.3">6.3 Why don't you make c-client a shared 1.340 + library?</a></li> 1.341 + 1.342 + <li><a href="#6.4">6.4 Why don't you use iconv() for 1.343 + internationalization support?</a></li> 1.344 + 1.345 + <li><a href="#6.5">6.5 Why is the IMAP server connected to the home 1.346 + directory by default?</a></li> 1.347 + 1.348 + <li><a href="#6.6">6.6 I have a Windows system. Why isn't the server 1.349 + plug and play for me?</a></li> 1.350 + 1.351 + <li><a href="#6.7">6.7 I looked at the UNIX SSL code and saw that you 1.352 + have the SSL data payload size set to 8192 bytes. SSL allows 16K; why 1.353 + aren't you using the full size?</a></li> 1.354 + 1.355 + <li><a href="#6.8">6.8 Why is an mh format INBOX called #mhinbox 1.356 + instead of just INBOX?</a></li> 1.357 + 1.358 + <li><a href="#6.9">6.9 Why don't you support the maildir 1.359 + format?</a></li> 1.360 + 1.361 + <li><a href="#6.10">6.10 Why don't you support the Cyrus 1.362 + format?</a></li> 1.363 + 1.364 + <li><a href="#6.11">6.11 Why is it creating extra forks on my SVR4 1.365 + system?</a></li> 1.366 + 1.367 + <li><a href="#6.12">6.12 Why are you so fussy about the date/time 1.368 + format in the internal <code>"From "</code> line in traditional 1.369 + UNIX mailbox files? My other mail program just considers every line 1.370 + that starts with <code>"From "</code> to be the start of the 1.371 + message.</a></li> 1.372 + 1.373 + <li><a href="#6.13">6.13 Why is traditional UNIX format the default 1.374 + format?</a></li> 1.375 + 1.376 + <li><a href="#6.14">6.14 Why do you write this "DON'T DELETE THIS 1.377 + MESSAGE -- FOLDER INTERNAL DATA" message at the start of traditional 1.378 + UNIX and MMDF format mailboxes?</a></li> 1.379 + 1.380 + <li><a href="#6.15">6.15 Why don't you stash the mailbox metadata in 1.381 + the first real message of the mailbox instead of writing this fake 1.382 + FOLDER INTERNAL DATA message?</a></li> 1.383 + 1.384 + <li><a href="#6.16">6.16 Why aren't "dual-use" mailboxes the 1.385 + default?</a></li> 1.386 + 1.387 + <li><a href="#6.17">6.17 Why do you use ucbcc to build on 1.388 + Solaris?</a></li> 1.389 + 1.390 + <li><a href="#6.18">6.18 Why should I care about some old system with 1.391 + BSD libraries? cc is the right thing on my Solaris system!</a></li> 1.392 + 1.393 + <li><a href="#6.19">6.19 Why do you insist upon writing .lock files 1.394 + in the spool directory?</a></li> 1.395 + 1.396 + <li><a href="#6.20">6.20 Why should I care about compatibility with 1.397 + the past?</a></li> 1.398 + </ul> 1.399 + </li> 1.400 + 1.401 + <li> 1.402 + <a href="#problems">7. Problems and Annoyances</a> 1.403 + 1.404 + <ul> 1.405 + <li><a href="#7.1">7.1 Help! My INBOX is empty! What happened to my 1.406 + messages?</a></li> 1.407 + 1.408 + <li><a href="#7.2">7.2 Help! All my messages in a non-INBOX mailbox 1.409 + have been concatenated into one message which claims to be from me 1.410 + and has a subject of the file name of the mailbox! What's going 1.411 + on?</a></li> 1.412 + 1.413 + <li> 1.414 + <a href="#7.3">7.3 Why do I get the message: 1.415 + 1.416 + <ul> 1.417 + <li>CREATE failed: Can't create mailbox node xxxxxxxxx: File 1.418 + exists</li> 1.419 + </ul>and how do I fix it?</a> 1.420 + </li> 1.421 + 1.422 + <li><a href="#7.4">7.4 Why can't I log in to the server? The user 1.423 + name and password are right!</a></li> 1.424 + 1.425 + <li><a href="#7.5">7.5 Help! My load average is soaring and I see 1.426 + hundreds of POP and IMAP servers, many logged in as the same 1.427 + user!</a></li> 1.428 + 1.429 + <li><a href="#7.6">7.6 Why does mail disappear even though I set 1.430 + "keep mail on server"?</a></li> 1.431 + 1.432 + <li> 1.433 + <a href="#7.7">7.7 Why do I get the message 1.434 + 1.435 + <ul> 1.436 + <li>Moved ##### bytes of new mail to /home/user/mbox from 1.437 + /var/spool/mail/user</li> 1.438 + </ul>and why did this happen?</a> 1.439 + </li> 1.440 + 1.441 + <li><a href="#7.8">7.8 Why isn't it showing the local host name as a 1.442 + fully-qualified domain name?</a></li> 1.443 + 1.444 + <li><a href="#7.9">7.9 Why is the local host name in the 1.445 + From/Sender/Message-ID headers of outgoing mail not coming out as a 1.446 + fully-qualified domain name?</a></li> 1.447 + 1.448 + <li> 1.449 + <a href="#7.10">7.10 What does the message: 1.450 + 1.451 + <ul> 1.452 + <li>Mailbox vulnerable - directory /var/spool/mail must have 1777 1.453 + protection</li> 1.454 + </ul>mean? How can I fix this?</a> 1.455 + </li> 1.456 + 1.457 + <li> 1.458 + <a href="#7.11">7.11 What does the message: 1.459 + 1.460 + <ul> 1.461 + <li>Mailbox is open by another process, access is readonly</li> 1.462 + </ul>mean? How do I fix this?</a> 1.463 + </li> 1.464 + 1.465 + <li> 1.466 + <a href="#7.12">7.12 What does the message: 1.467 + 1.468 + <ul> 1.469 + <li>Can't get write access to mailbox, access is readonly</li> 1.470 + </ul>mean?</a> 1.471 + </li> 1.472 + 1.473 + <li><a href="#7.13">7.13 I set my POP3 client to "delete messages 1.474 + from server" but they never get deleted. What is wrong?</a></li> 1.475 + 1.476 + <li> 1.477 + <a href="#7.14">7.14 What do messages such as: 1.478 + 1.479 + <ul> 1.480 + <li>Message ... UID ... already has UID ...</li> 1.481 + 1.482 + <li>Message ... UID ... less than ...</li> 1.483 + 1.484 + <li>Message ... UID ... greater than last ...</li> 1.485 + 1.486 + <li>Invalid UID ... in message ..., rebuilding UIDs</li> 1.487 + </ul>mean?</a> 1.488 + </li> 1.489 + 1.490 + <li> 1.491 + <a href="#7.15">7.15 What do the error messages: 1.492 + 1.493 + <ul> 1.494 + <li>Unable to read internal header at ...</li> 1.495 + 1.496 + <li>Unable to find CRLF at ...</li> 1.497 + 1.498 + <li>Unable to parse internal header at ...</li> 1.499 + 1.500 + <li>Unable to parse message date at ...</li> 1.501 + 1.502 + <li>Unable to parse message flags at ...</li> 1.503 + 1.504 + <li>Unable to parse message UID at ...</li> 1.505 + 1.506 + <li>Unable to parse message size at ...</li> 1.507 + 1.508 + <li>Last message (at ... ) runs past end of file ...</li> 1.509 + </ul>mean? I am using mbx format.</a> 1.510 + </li> 1.511 + 1.512 + <li> 1.513 + <a href="#7.16">7.16 What do the syslog messages: 1.514 + 1.515 + <ul> 1.516 + <li>imap/tcp server failing (looping)</li> 1.517 + 1.518 + <li>pop3/tcp server failing (looping)</li> 1.519 + </ul>mean? When it happens, the listed service shuts down. How can 1.520 + I fix this?</a> 1.521 + </li> 1.522 + 1.523 + <li> 1.524 + <a href="#7.17">7.17 What does the syslog message: 1.525 + 1.526 + <ul> 1.527 + <li>Mailbox lock file /tmp/.600.1df3 open failure: Permission 1.528 + denied</li> 1.529 + </ul>mean?</a> 1.530 + </li> 1.531 + 1.532 + <li> 1.533 + <a href="#7.18">7.18 What do the syslog messages: 1.534 + 1.535 + <ul> 1.536 + <li>Command stream end of file, while reading line user=... 1.537 + host=...</li> 1.538 + 1.539 + <li>Command stream end of file, while reading char user=... 1.540 + host=...</li> 1.541 + 1.542 + <li>Command stream end of file, while writing text user=... 1.543 + host=...</li> 1.544 + </ul>mean?</a> 1.545 + </li> 1.546 + 1.547 + <li> 1.548 + <a href="#7.19">7.19 Why did my POP or IMAP session suddenly 1.549 + disconnect? The syslog has the message: 1.550 + 1.551 + <ul> 1.552 + <li>Killed (lost mailbox lock) user=... host=...</li> 1.553 + </ul></a> 1.554 + </li> 1.555 + 1.556 + <li><a href="#7.20">7.20 Why does my IMAP client show all the files 1.557 + on the system, recursively from the UNIX root directory?</a></li> 1.558 + 1.559 + <li><a href="#7.21">7.21 Why does my IMAP client show all of my 1.560 + files, recursively from my UNIX home directory?</a></li> 1.561 + 1.562 + <li><a href="#7.22">7.22 Why does my IMAP client show that I have 1.563 + mailboxes named "#mhinbox", "#mh", "#shared", "#ftp", "#news", and 1.564 + "#public"?</a></li> 1.565 + 1.566 + <li><a href="#7.23">7.23 Why does my IMAP client show all my files in 1.567 + my home directory?</a></li> 1.568 + 1.569 + <li><a href="#7.24">7.24 Why is there a long delay before I get 1.570 + connected to the IMAP or POP server, no matter what client I 1.571 + use?</a></li> 1.572 + 1.573 + <li><a href="#7.25">7.25 Why is there a long delay in Pine or any 1.574 + other c-client based application call before I get connected to the 1.575 + IMAP server? The hang seems to be in the c-client mail_open() call. I 1.576 + don't have this problem with any other IMAP client. There is no delay 1.577 + connecting to a POP3 or NNTP server with mail_open().</a></li> 1.578 + 1.579 + <li><a href="#7.26">7.26 Why does a message sometimes get split into 1.580 + two or more messages on my SUN system?</a></li> 1.581 + 1.582 + <li> 1.583 + <a href="#7.27">7.27 Why did my POP or IMAP session suddenly 1.584 + disconnect? The syslog has the message: 1.585 + 1.586 + <ul> 1.587 + <li>Autologout user=<...my user name...> host=<...my 1.588 + imap server...></li> 1.589 + </ul></a> 1.590 + </li> 1.591 + 1.592 + <li> 1.593 + <a href="#7.28">7.28 What does the UNIX error message: 1.594 + 1.595 + <ul> 1.596 + <li>TLS/SSL failure: myserver: SSL negotiation failed</li> 1.597 + </ul>mean?</a> 1.598 + </li> 1.599 + 1.600 + <li> 1.601 + <a href="#7.29">7.29 What does the PC error message: 1.602 + 1.603 + <ul> 1.604 + <li>TLS/SSL failure: myserver: Unexpected TCP input 1.605 + disconnect</li> 1.606 + </ul>mean?</a> 1.607 + </li> 1.608 + 1.609 + <li> 1.610 + <a href="#7.30">7.30 What does the error message: 1.611 + 1.612 + <ul> 1.613 + <li>TLS/SSL failure: myserver: Server name does not match 1.614 + certificate</li> 1.615 + </ul>mean?</a> 1.616 + </li> 1.617 + 1.618 + <li> 1.619 + <a href="#7.31">7.31 What does the UNIX error message: 1.620 + 1.621 + <ul> 1.622 + <li>TLS/SSL failure: myserver: self-signed certificate</li> 1.623 + </ul>mean?</a> 1.624 + </li> 1.625 + 1.626 + <li> 1.627 + <a href="#7.32">7.32 What does the PC error message 1.628 + 1.629 + <ul> 1.630 + <li>TLS/SSL failure: myserver: Self-signed certificate or 1.631 + untrusted authority</li> 1.632 + </ul>mean?</a> 1.633 + </li> 1.634 + 1.635 + <li> 1.636 + <a href="#7.33">7.33 What does the UNIX error message: 1.637 + 1.638 + <ul> 1.639 + <li>TLS/SSL failure: myserver: unable to get local issuer 1.640 + certificate</li> 1.641 + </ul>mean?</a> 1.642 + </li> 1.643 + 1.644 + <li><a href="#7.34">7.34 Why does reading certain messages hang when 1.645 + using Netscape? It works fine with Pine!</a></li> 1.646 + 1.647 + <li><a href="#7.35">7.35 Why does Netscape say that there's a problem 1.648 + with the IMAP server and that I should "Contact your mail server 1.649 + administrator."?</a></li> 1.650 + 1.651 + <li><a href="#7.36">7.36 Why is one user creating huge numbers of 1.652 + IMAP or POP server sessions?</a></li> 1.653 + 1.654 + <li><a href="#7.37">7.37 Why don't I get any new mail notifications 1.655 + from Outlook Express or Outlook after a while?</a></li> 1.656 + 1.657 + <li><a href="#7.38">7.38 Why don't I get any new mail notifications 1.658 + from Entourage?</a></li> 1.659 + 1.660 + <li><a href="#7.39">7.39 Why doesn't Entourage work at all?</a></li> 1.661 + 1.662 + <li><a href="#7.40">7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) 1.663 + work at all?</a></li> 1.664 + 1.665 + <li><a href="#7.41">7.41 Why can't I connect via SSL to Eudora? It 1.666 + says the connection has been broken, and in the server syslogs I see 1.667 + "Command stream end of file".</a></li> 1.668 + 1.669 + <li><a href="#7.42">7.42 Sheesh. Aren't there <i>any</i> good IMAP 1.670 + clients out there?</a></li> 1.671 + 1.672 + <li> 1.673 + <a href="#7.43">7.43 But wait! PC Pine (or other PC program build 1.674 + with c-client) crashes with the message 1.675 + 1.676 + <ul> 1.677 + <li>incomplete SecBuffer exceeds maximum buffer size</li> 1.678 + </ul>when I use SSL connections. This is a bug in c-client, right?</a> 1.679 + </li> 1.680 + 1.681 + <li><a href="#7.44">7.44 My qpopper users keep on getting the DON'T 1.682 + DELETE THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or 1.683 + IMAP. How can I fix this?</a></li> 1.684 + 1.685 + <li><a href="#7.45">7.45 Help! I installed the servers but I can't 1.686 + connect to them from my client!</a></li> 1.687 + 1.688 + <li> 1.689 + <a href="#7.46">7.46 Why do I get the message 1.690 + 1.691 + <ul> 1.692 + <li>Can not authenticate to SMTP server: 421 SMTP connection went 1.693 + away!</li> 1.694 + </ul>and why did this happen? There was also something about 1.695 + 1.696 + <ul> 1.697 + <li>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</li> 1.698 + </ul></a> 1.699 + </li> 1.700 + 1.701 + <li> 1.702 + <a href="#7.47">7.47 Why do I get the message 1.703 + 1.704 + <ul> 1.705 + <li>SMTP Authentication cancelled</li> 1.706 + </ul>and why did this happen? There was also something about 1.707 + 1.708 + <ul> 1.709 + <li>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</li> 1.710 + </ul></a> 1.711 + </li> 1.712 + 1.713 + <li> 1.714 + <a href="#7.48">7.48 Why do I get the message 1.715 + 1.716 + <ul> 1.717 + <li>Invalid base64 string</li> 1.718 + </ul>when I try to authenticate to a Cyrus server? 1.719 + </li></a> 1.720 + </ul> 1.721 + </li> 1.722 + 1.723 + <li> 1.724 + <a href="#additional">8. Where to Go For Additional Information</a> 1.725 + 1.726 + <ul> 1.727 + <li><a href="#8.1">8.1 Where can I go to ask questions?</a></li> 1.728 + 1.729 + <li><a href="#8.2">8.2 I have some ideas for enhancements to IMAP. 1.730 + Where should I go?</a></li> 1.731 + 1.732 + <li><a href="#8.3">8.3 Where can I read more about IMAP and other 1.733 + email protocols?</a></li> 1.734 + 1.735 + <li><a href="#8.4">8.4 Where can I find out more about setting up and 1.736 + administering an IMAP server?</a></li> 1.737 + </ul> 1.738 + </li> 1.739 + </ul><!--=======START BODY--> 1.740 + <hr> 1.741 + 1.742 + <h2><a name="general">1. General/Software Feature Questions</a></h2> 1.743 + <hr> 1.744 + 1.745 + <p><a name="1.1"><strong>1.1 Can I set up a POP or IMAP server on 1.746 + UNIX/Linux/OSF/etc.?</strong></a></p> 1.747 + 1.748 + <dl> 1.749 + <dd>Yes. Refer to the UNIX specific notes in files CONFIG and BUILD.</dd> 1.750 + </dl> 1.751 + 1.752 + <p><a href="#top">Back to top</a></p> 1.753 + <hr> 1.754 + 1.755 + <p><a name="1.2"><strong>1.2 I am currently using qpopper as my POP3 server on 1.756 + UNIX. Do I need to replace it with ipop3d in order to run 1.757 + imapd?</strong></a></p> 1.758 + 1.759 + <dl> 1.760 + <dd> 1.761 + Not necessarily. 1.762 + 1.763 + <p>Although ipop3d interoperates with imapd better than qpopper, imapd 1.764 + and qpopper will work together. The few qpopper/imapd interoperability 1.765 + issues mostly affect users who use both IMAP and POP3 clients; those 1.766 + users would probably be better served if their POP3 server is 1.767 + ipop3d.</p> 1.768 + 1.769 + <p>If you are happy with qpopper and just want to add imapd, you should 1.770 + do that, and defer a decision on changing qpopper to ipop3d. That way, 1.771 + you can get comfortable with imapd's performance, without changing 1.772 + anything for your qpopper users.</p> 1.773 + 1.774 + <p>Many sites have subsequently decided to change from qpopper to 1.775 + ipop3d in order to get better POP3/IMAP interoperability. If you need 1.776 + to do this, you'll know. There also seems to be a way to make qpopper 1.777 + work better with imapd; see the answer to the <a href="#7.44">My 1.778 + qpopper users keep on getting the DON'T DELETE THIS MESSAGE -- FOLDER 1.779 + INTERNAL DATA if they also use Pine or IMAP. How can I fix this?</a> 1.780 + question.</p> 1.781 + </dd> 1.782 + </dl> 1.783 + 1.784 + <p><a href="#top">Back to top</a></p> 1.785 + <hr> 1.786 + 1.787 + <p><a name="1.3"><strong>1.3 Can I set up a POP or IMAP server on Windows XP, 1.788 + 2000, NT, Me, 98, or 95?</strong></a></p> 1.789 + 1.790 + <dl> 1.791 + <dd> 1.792 + Yes. Refer to the NT specific notes in files CONFIG and BUILD. Also, 1.793 + for DOS-based versions of Windows (Windows Me, 98, and 95) you *must* 1.794 + set up CRAM-MD5 authentication, as described in md5.txt. 1.795 + 1.796 + <p>There is no file access control on Windows 9x or Me, so you probably 1.797 + will have to do modifications to env_unix.c to prevent people from 1.798 + hacking others' mail.</p> 1.799 + 1.800 + <p>Note, however, that the server is not plug and play the way it is 1.801 + for UNIX.</p> 1.802 + </dd> 1.803 + </dl> 1.804 + 1.805 + <p><a href="#top">Back to top</a></p> 1.806 + <hr> 1.807 + 1.808 + <p><a name="1.4"><strong>1.4 Can I set up a POP or IMAP server on Windows 3.1 or 1.809 + DOS?</strong></a><br> 1.810 + <a name="1.5"><strong>1.5 Can I set up a POP or IMAP server on 1.811 + Macintosh?</strong></a><br> 1.812 + <a name="1.6"><strong>1.6 Can I set up a POP or IMAP server on 1.813 + VAX/VMS?</strong></a></p> 1.814 + 1.815 + <dl> 1.816 + <dd>Yes, it's just a small matter of programming.</dd> 1.817 + </dl> 1.818 + 1.819 + <p><a href="#top">Back to top</a></p> 1.820 + <hr> 1.821 + 1.822 + <p><a name="1.7"><strong>1.7 Can I set up a POP or IMAP server on 1.823 + TOPS-20?</strong></a></p> 1.824 + 1.825 + <dl> 1.826 + <dd> 1.827 + You have a TOPS-20 system? Cool. 1.828 + 1.829 + <p>If IMAP2 (RFC 1176) is good enough for you, you can use MAPSER which 1.830 + is about the ultimate gonzo pure TOPS-20 extended addressing assembly 1.831 + language program. Unfortunately, IMAP2 is barely good enough for Pine 1.832 + these days, and most other IMAP clients won't work with IMAP2 at all. 1.833 + Maybe someone will hack MAPSER to do IMAP4rev1 some day.</p> 1.834 + 1.835 + <p>We don't know if anyone wrote a POP3 server for TOPS-20. There 1.836 + definitely was a POP2 server once upon a time.</p> 1.837 + 1.838 + <p>Or you can port the POP and IMAP server from this IMAP toolkit to 1.839 + it. All that you need for a first stab is to port the MTX driver. 1.840 + That'll probably be just a couple of hours of hacking.</p> 1.841 + </dd> 1.842 + </dl> 1.843 + 1.844 + <p><a href="#top">Back to top</a></p> 1.845 + <hr> 1.846 + 1.847 + <p><a name="1.8"><strong>1.8 Are hierarchical mailboxes 1.848 + supported?</strong></a><br> 1.849 + <a name="1.9"><strong>1.9 Are "dual-use" mailboxes 1.850 + supported?</strong></a><br> 1.851 + <a name="1.10"><strong>1.10 Can I have a mailbox that has both messages and 1.852 + sub-mailboxes?</strong></a></p> 1.853 + 1.854 + <dl> 1.855 + <dd> 1.856 + Yes. However, there is one important caveat. 1.857 + 1.858 + <p>Some mailbox formats, including the default which is the traditional 1.859 + UNIX mailbox format, are stored as a single file containing all the 1.860 + messages. UNIX does not permit a name in the filesystem to be both a 1.861 + file and a directory; consequently you can not have a sub-mailbox 1.862 + within a mailbox that is in one of these formats.</p> 1.863 + 1.864 + <p>This is not a limitation of the software; this is a limitation of 1.865 + UNIX. For example, there are mailbox formats in which the name is a 1.866 + directory and each message is a file within that directory; these 1.867 + formats support sub-mailboxes within such mailboxes. However, for 1.868 + technical reasons, the "flat file" formats are generally preferred 1.869 + since they perform better. Read imap-2007/docs/formats.txt for more 1.870 + information on this topic.</p> 1.871 + 1.872 + <p>It is always permissible to create a directory that is not a 1.873 + mailbox, and have sub-mailboxes under it. The easiest way to create a 1.874 + directory is to create a new mailbox inside a directory that doesn't 1.875 + already exist. For example, if you create "Mail/testbox" on UNIX, the 1.876 + directory "Mail/" will automatically be created and then the mailbox 1.877 + "testbox" will be created as a sub-mailbox of "Mail/".</p> 1.878 + 1.879 + <p>It is also possible to create the name "Mail/" directly. Check the 1.880 + documentation for your client software to see how to do this with that 1.881 + software.</p> 1.882 + 1.883 + <p>Of course, on Windows systems you would use "\" instead of "/".</p> 1.884 + </dd> 1.885 + </dl> 1.886 + 1.887 + <p><a href="#top">Back to top</a></p> 1.888 + <hr> 1.889 + 1.890 + <p><a name="1.11"><strong>1.11 What is the difference between "mailbox" and 1.891 + "folder"?</strong></a></p> 1.892 + 1.893 + <dl> 1.894 + <dd> 1.895 + The term "mailbox" is IMAP-speak for what a lot of software calls a 1.896 + "folder" or a "mail folder". However, "folder" is often used in other 1.897 + contexts to refer to a directory, for example, in the graphic user 1.898 + interface on both Windows and Macintosh. 1.899 + 1.900 + <p>A "mailbox" is specifically defined as a named object that contains 1.901 + messages. It is not required to be capable of containing other types of 1.902 + objects including other mailboxes; although some mailbox formats will 1.903 + permit this.</p> 1.904 + 1.905 + <p>In IMAP-speak, a mailbox which can not contain other mailboxes is 1.906 + called a "no-inferiors mailbox". Similarly, a directory which can not 1.907 + contain messages is not a mailbox and is called a "no-select name".</p> 1.908 + </dd> 1.909 + </dl> 1.910 + 1.911 + <p><a href="#top">Back to top</a></p> 1.912 + <hr> 1.913 + 1.914 + <p><a name="1.12"><strong>1.12 What is the status of 1.915 + internationalization?</strong></a></p> 1.916 + 1.917 + <dl> 1.918 + <dd> 1.919 + The IMAP toolkit is partially internationalized and multilingualized. 1.920 + 1.921 + <p>Searching is supported in the following charsets: US-ASCII, UTF-8, 1.922 + ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, 1.923 + ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, 1.924 + ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U 1.925 + (alias KOI8-RU), TIS-620, VISCII, ISO-2022-JP, ISO-2022-KR, 1.926 + ISO-2022-CN, ISO-2022-JP-1, ISO-2022-JP-2, GB2312 (alias CN-GB), 1.927 + CN-GB-12345, BIG5 (alias CN-BIG5), EUC-JP, EUC-KR, Shift_JIS, 1.928 + Shift-JIS, KS_C_5601-1987, KS_C_5601-1992, WINDOWS_874, WINDOWS-1250, 1.929 + WINDOWS-1251, WINDOWS-1252, WINDOWS-1253, WINDOWS-1254, WINDOWS-1255, 1.930 + WINDOWS-1256, WINDOWS-1257, WINDOWS-1258.</p> 1.931 + 1.932 + <p>All ISO-2022-?? charsets are treated identically, and support ASCII, 1.933 + JIS Roman, hankaku katakana, ISO-8859-[1 - 10], TIS, GB 2312, JIS X 1.934 + 0208, JIS X 0212, KSC 5601, and planes 1 and 2 of CNS 11643.</p> 1.935 + 1.936 + <p>EUC-JP includes support for JIS X 0212 and hankaku katakana.</p> 1.937 + 1.938 + <p>c-client library support also exists to convert text in any of the 1.939 + above charsets into Unicode, including headers with MIME 1.940 + encoded-words.</p> 1.941 + 1.942 + <p>There is no support for localization (e.g. non-English error 1.943 + messages) at the present time, but such support is planned.</p> 1.944 + </dd> 1.945 + </dl> 1.946 + 1.947 + <p><a href="#top">Back to top</a></p> 1.948 + <hr> 1.949 + 1.950 + <p><a name="1.13"><strong>1.13 Can I use SSL?</strong></a></p> 1.951 + 1.952 + <dl> 1.953 + <dd>Yes. See the answer to the <a href="#3.5">How do I configure SSL?</a> 1.954 + question.</dd> 1.955 + </dl> 1.956 + 1.957 + <p><a href="#top">Back to top</a></p> 1.958 + <hr> 1.959 + 1.960 + <p><a name="1.14"><strong>1.14 Can I use TLS and the STARTTLS 1.961 + facility?</strong></a></p> 1.962 + 1.963 + <dl> 1.964 + <dd>Yes. See the answer to the <a href="#3.6">How do I configure TLS and 1.965 + the STARTTLS facility?</a> question.</dd> 1.966 + </dl> 1.967 + 1.968 + <p><a href="#top">Back to top</a></p> 1.969 + <hr> 1.970 + 1.971 + <p><a name="1.15"><strong>1.15 Can I use CRAM-MD5 1.972 + authentication?</strong></a></p> 1.973 + 1.974 + <dl> 1.975 + <dd>Yes. See the answer to the <a href="#3.8">How do I configure CRAM-MD5 1.976 + authentication?</a> question.</dd> 1.977 + </dl> 1.978 + 1.979 + <p><a href="#top">Back to top</a></p> 1.980 + <hr> 1.981 + 1.982 + <p><a name="1.16"><strong>1.16 Can I use APOP authentication?</strong></a></p> 1.983 + 1.984 + <dl> 1.985 + <dd> 1.986 + Yes. See the <a href="#3.9">How do I configure APOP authentication?</a> 1.987 + question. 1.988 + 1.989 + <p>Note that there is no client support for APOP authentication.</p> 1.990 + </dd> 1.991 + </dl> 1.992 + 1.993 + <p><a href="#top">Back to top</a></p> 1.994 + <hr> 1.995 + 1.996 + <p><a name="1.17"><strong>1.17 Can I use Kerberos V5?</strong></a></p> 1.997 + 1.998 + <dl> 1.999 + <dd>Yes. See the answer to the <a href="#3.10">How do I configure 1.1000 + Kerberos V5?</a> question.</dd> 1.1001 + </dl> 1.1002 + 1.1003 + <p><a href="#top">Back to top</a></p> 1.1004 + <hr> 1.1005 + 1.1006 + <p><a name="1.18"><strong>1.18 Can I use PAM for plaintext 1.1007 + passwords?</strong></a></p> 1.1008 + 1.1009 + <dl> 1.1010 + <dd>Yes. See the answer to the <a href="#3.11">How do I configure PAM for 1.1011 + plaintext passwords?</a> question.</dd> 1.1012 + </dl> 1.1013 + 1.1014 + <p><a href="#top">Back to top</a></p> 1.1015 + <hr> 1.1016 + 1.1017 + <p><a name="1.19"><strong>1.19 Can I use Kerberos 5 for plaintext 1.1018 + passwords?</strong></a></p> 1.1019 + 1.1020 + <dl> 1.1021 + <dd>Yes. See the answer to the <a href="#3.13">How do I configure 1.1022 + Kerberos 5 for plaintext passwords?</a> question.</dd> 1.1023 + </dl> 1.1024 + 1.1025 + <p><a href="#top">Back to top</a></p> 1.1026 + <hr> 1.1027 + 1.1028 + <p><a name="1.20"><strong>1.20 Can I use AFS for plaintext 1.1029 + passwords?</strong></a></p> 1.1030 + 1.1031 + <dl> 1.1032 + <dd>Yes. See the answer to the <a href="#3.14">How do I configure AFS for 1.1033 + plaintext passwords?</a> question.</dd> 1.1034 + </dl> 1.1035 + 1.1036 + <p><a href="#top">Back to top</a></p> 1.1037 + <hr> 1.1038 + 1.1039 + <p><a name="1.21"><strong>1.21 Can I use DCE for plaintext 1.1040 + passwords?</strong></a></p> 1.1041 + 1.1042 + <dl> 1.1043 + <dd>Yes. See the answer to the <a href="#3.15">How do I configure DCE for 1.1044 + plaintext passwords?</a> question.</dd> 1.1045 + </dl> 1.1046 + 1.1047 + <p><a href="#top">Back to top</a></p> 1.1048 + <hr> 1.1049 + 1.1050 + <p><a name="1.22"><strong>1.22 Can I use the CRAM-MD5 database for plaintext 1.1051 + passwords?</strong></a></p> 1.1052 + 1.1053 + <dl> 1.1054 + <dd>Yes. See the answer to the <a href="#3.16">How do I configure the 1.1055 + CRAM-MD5 database for plaintext passwords?</a> question.</dd> 1.1056 + </dl> 1.1057 + 1.1058 + <p><a href="#top">Back to top</a></p> 1.1059 + <hr> 1.1060 + 1.1061 + <p><a name="1.23"><strong>1.23 Can I disable plaintext 1.1062 + passwords?</strong></a></p> 1.1063 + 1.1064 + <dl> 1.1065 + <dd>Yes. See the answer to the <a href="#3.17">How do I disable plaintext 1.1066 + passwords?</a> question.</dd> 1.1067 + </dl> 1.1068 + 1.1069 + <p><a href="#top">Back to top</a></p> 1.1070 + <hr> 1.1071 + 1.1072 + <p><a name="1.24"><strong>1.24 Can I disable plaintext passwords on unencrypted 1.1073 + sessions, but allow them on encrypted sessions?</strong></a></p> 1.1074 + 1.1075 + <dl> 1.1076 + <dd>Yes. See the answer to the <a href="#3.18">How do I disable plaintext 1.1077 + passwords on unencrypted sessions, but allow them in SSL or TLS 1.1078 + sessions?</a> question.</dd> 1.1079 + </dl> 1.1080 + 1.1081 + <p><a href="#top">Back to top</a></p> 1.1082 + <hr> 1.1083 + 1.1084 + <p><a name="1.25"><strong>1.25 Can I use virtual hosts?</strong></a></p> 1.1085 + 1.1086 + <dl> 1.1087 + <dd>Yes. See the answer to the <a href="#3.19">How do I configure virtual 1.1088 + hosts?</a> question.</dd> 1.1089 + </dl> 1.1090 + 1.1091 + <p><a href="#top">Back to top</a></p> 1.1092 + <hr> 1.1093 + 1.1094 + <p><a name="1.26"><strong>1.26 Can I use RPOP authentication?</strong></a></p> 1.1095 + 1.1096 + <dl> 1.1097 + <dd>There is no support for RPOP authentication.</dd> 1.1098 + </dl> 1.1099 + 1.1100 + <p><a href="#top">Back to top</a></p> 1.1101 + <hr> 1.1102 + 1.1103 + <p><a name="1.27"><strong>1.27 Can I use Kerberos V4?</strong></a></p> 1.1104 + 1.1105 + <dl> 1.1106 + <dd> 1.1107 + Kerberos V4 is not supported. Kerberos V4 client-only contributed code 1.1108 + is available in 1.1109 + <pre> 1.1110 +<a href= 1.1111 +"ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z">ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z 1.1112 +</a> 1.1113 +</pre>This is a patchkit which must be applied to the IMAP toolkit according 1.1114 +to the instructions in the patchkit's README. We can not promise that this 1.1115 +code works. 1.1116 + </dd> 1.1117 + </dl> 1.1118 + 1.1119 + <p><a href="#top">Back to top</a></p> 1.1120 + <hr> 1.1121 + 1.1122 + <p><a name="1.28"><strong>1.28 Is there support for S/Key or 1.1123 + OTP?</strong></a></p> 1.1124 + 1.1125 + <dl> 1.1126 + <dd>There is currently no support for S/Key or OTP. There may be an OTP 1.1127 + SASL authenticator available from third parties.</dd> 1.1128 + </dl> 1.1129 + 1.1130 + <p><a href="#top">Back to top</a></p> 1.1131 + <hr> 1.1132 + 1.1133 + <p><a name="1.29"><strong>1.29 Is there support for NTLM or 1.1134 + SPA?</strong></a></p> 1.1135 + 1.1136 + <dl> 1.1137 + <dd> 1.1138 + There is currently no support for NTLM or SPA, nor are there any plans 1.1139 + to add such support. In general, I avoid vendor-specific mechanisms. I 1.1140 + also believe that these mechanisms are being deprecated by their 1.1141 + vendor. 1.1142 + 1.1143 + <p>There may be an NTLM SASL authenticator available from third 1.1144 + parties.</p> 1.1145 + </dd> 1.1146 + </dl> 1.1147 + 1.1148 + <p><a href="#top">Back to top</a></p> 1.1149 + <hr> 1.1150 + 1.1151 + <p><a name="1.30"><strong>1.30 Is there support for mh?</strong></a></p> 1.1152 + 1.1153 + <dl> 1.1154 + <dd> 1.1155 + Yes, but only as a legacy format. Your mh format INBOX is accessed by 1.1156 + the name "#mhinbox", and all other mh format mailboxes are accessed by 1.1157 + prefixing "#mh/" to the name, e.g. "#mh/foo". The mh support uses the 1.1158 + "Path:" entry in your .mh_profile file to identify the root directory 1.1159 + of your mh format mailboxes. 1.1160 + 1.1161 + <p>Non-legacy use of mh format is not encouraged. There is no support 1.1162 + for permanent flags or unique identifiers; furthermore there are known 1.1163 + severe performance problems with the mh format.</p> 1.1164 + </dd> 1.1165 + </dl> 1.1166 + 1.1167 + <p><a href="#top">Back to top</a></p> 1.1168 + <hr> 1.1169 + 1.1170 + <p><a name="1.31"><strong>1.31 Is there support for qmail and the maildir 1.1171 + format?</strong></a></p> 1.1172 + 1.1173 + <dl> 1.1174 + <dd>There is no support for qmail or the maildir format in our 1.1175 + distribution, nor are there any plans to add such support. Maildir 1.1176 + support may be available from third parties.</dd> 1.1177 + </dl> 1.1178 + 1.1179 + <p><a href="#top">Back to top</a></p> 1.1180 + <hr> 1.1181 + 1.1182 + <p><a name="1.32"><strong>1.32 Is there support for the Cyrus mailbox 1.1183 + format?</strong></a></p> 1.1184 + 1.1185 + <dl> 1.1186 + <dd>No.</dd> 1.1187 + </dl> 1.1188 + 1.1189 + <p><a href="#top">Back to top</a></p> 1.1190 + <hr> 1.1191 + 1.1192 + <p><a name="1.33"><strong>1.33 Is this software Y2K compliant?</strong></a></p> 1.1193 + 1.1194 + <dl> 1.1195 + <dd>Please read the files Y2K and calendar.txt.</dd> 1.1196 + </dl> 1.1197 + 1.1198 + <p><a href="#top">Back to top</a></p> 1.1199 + <hr> 1.1200 + 1.1201 + <p><br></p> 1.1202 + 1.1203 + <h2><a name="requirements">2. What Do I Need to Build This Software?</a></h2> 1.1204 + <hr> 1.1205 + 1.1206 + <p><a name="2.1"><strong>2.1 What do I need to build this software with SSL on 1.1207 + UNIX?</strong></a></p> 1.1208 + 1.1209 + <dl> 1.1210 + <dd>You need to build and install OpenSSL first.</dd> 1.1211 + </dl> 1.1212 + 1.1213 + <p><a href="#top">Back to top</a></p> 1.1214 + <hr> 1.1215 + 1.1216 + <p><a name="2.2"><strong>2.2 What do I need to build this software with Kerberos 1.1217 + V on UNIX?</strong></a></p> 1.1218 + 1.1219 + <dl> 1.1220 + <dd>You need to build and install MIT Kerberos first.</dd> 1.1221 + </dl> 1.1222 + 1.1223 + <p><a href="#top">Back to top</a></p> 1.1224 + <hr> 1.1225 + 1.1226 + <p><a name="2.3"><strong>2.3 What do I need to use a C++ compiler with this 1.1227 + software to build my own application?</strong></a></p> 1.1228 + 1.1229 + <dl> 1.1230 + <dd> 1.1231 + If you are building an application using the c-client library, use the 1.1232 + new c-client.h file instead of including the other include files. It 1.1233 + seems that c-client.h should define away all the troublesome names that 1.1234 + conflict with C++. 1.1235 + 1.1236 + <p>If you use gcc, you may need to use -fno-operator-names as well.</p> 1.1237 + </dd> 1.1238 + </dl> 1.1239 + 1.1240 + <p><a href="#top">Back to top</a></p> 1.1241 + <hr> 1.1242 + 1.1243 + <p><a name="2.4"><strong>2.4 What do I need to build this software on 1.1244 + Windows?</strong></a></p> 1.1245 + 1.1246 + <dl> 1.1247 + <dd> 1.1248 + You need Microsoft Visual C++ 6.0, Visual C++ .NET, or Visual C# .NET 1.1249 + (which you can buy from any computer store), along with the Microsoft 1.1250 + Platform SDK (which you can download from Microsoft's web site). 1.1251 + 1.1252 + <p>You do not need to install the entire Platform SDK; it suffices to 1.1253 + install just the Core SDK and the Internet Development SDK.</p> 1.1254 + </dd> 1.1255 + </dl> 1.1256 + 1.1257 + <p><a href="#top">Back to top</a></p> 1.1258 + <hr> 1.1259 + 1.1260 + <p><a name="2.5"><strong>2.5 What do I need to build this software on 1.1261 + DOS?</strong></a></p> 1.1262 + 1.1263 + <dl> 1.1264 + <dd>It's been several years since we last attempted to do this. At the 1.1265 + time, we used Microsoft C.</dd> 1.1266 + </dl> 1.1267 + 1.1268 + <p><a href="#top">Back to top</a></p> 1.1269 + <hr> 1.1270 + 1.1271 + <p><a name="2.6"><strong>2.6 Can't I use Borland C to build this software on the 1.1272 + PC?</strong></a></p> 1.1273 + 1.1274 + <dl> 1.1275 + <dd>Probably not. If you know otherwise, please let us know.</dd> 1.1276 + </dl> 1.1277 + 1.1278 + <p><a href="#top">Back to top</a></p> 1.1279 + <hr> 1.1280 + 1.1281 + <p><a name="2.7"><strong>2.7 What do I need to build this software on the 1.1282 + Mac?</strong></a></p> 1.1283 + 1.1284 + <dl> 1.1285 + <dd>It has been several years since we last attempted to do this. At the 1.1286 + time, we used Symantec THINK C; but today you'll need a C compiler which 1.1287 + allows segments to be more than 32K.</dd> 1.1288 + </dl> 1.1289 + 1.1290 + <p><a href="#top">Back to top</a></p> 1.1291 + <hr> 1.1292 + 1.1293 + <p><a name="2.8"><strong>2.8 What do I need to build this software on 1.1294 + VMS?</strong></a></p> 1.1295 + 1.1296 + <dl> 1.1297 + <dd>You need the VMS C compiler, and either the Multinet or Netlib 1.1298 + TCP.</dd> 1.1299 + </dl> 1.1300 + 1.1301 + <p><a href="#top">Back to top</a></p> 1.1302 + <hr> 1.1303 + 1.1304 + <p><a name="2.9"><strong>2.9 What do I need to build this software on 1.1305 + TOPS-20?</strong></a></p> 1.1306 + 1.1307 + <dl> 1.1308 + <dd>You need the TOPS-20 KCC compiler.</dd> 1.1309 + </dl> 1.1310 + 1.1311 + <p><a href="#top">Back to top</a></p> 1.1312 + <hr> 1.1313 + 1.1314 + <p><a name="2.10"><strong>2.10 What do I need to build this software on Amiga or 1.1315 + OS/2?</strong></a></p> 1.1316 + 1.1317 + <dl> 1.1318 + <dd>We don't know.</dd> 1.1319 + </dl> 1.1320 + 1.1321 + <p><a href="#top">Back to top</a></p> 1.1322 + <hr> 1.1323 + 1.1324 + <p><a name="2.11"><strong>2.11 What do I need to build this software on Windows 1.1325 + CE?</strong></a></p> 1.1326 + 1.1327 + <dl> 1.1328 + <dd>This port is incomplete. Someone needs to finish it.</dd> 1.1329 + </dl> 1.1330 + 1.1331 + <p><a href="#top">Back to top</a></p> 1.1332 + <hr> 1.1333 + 1.1334 + <p><br></p> 1.1335 + 1.1336 + <h2><a name="build">3. Build and Configuration Questions</a></h2> 1.1337 + <hr> 1.1338 + 1.1339 + <p><a name="3.1"><strong>3.1 How do I configure the IMAP and POP servers on 1.1340 + UNIX?</strong></a><br> 1.1341 + <a name="3.2"><strong>3.2 I built and installed the servers according to the 1.1342 + BUILD instructions. It can't be that easy. Don't I need to write a 1.1343 + config file?</strong></a></p> 1.1344 + 1.1345 + <dl> 1.1346 + <dd> 1.1347 + For ordinary "vanilla" UNIX systems, this software is plug and play; 1.1348 + just build it, install it, and you're done. If you have a modified 1.1349 + system, then you may want to do additional work; most of this is to a 1.1350 + single source code file (env_unix.c on UNIX systems). Read the file 1.1351 + CONFIG for more details. 1.1352 + 1.1353 + <p>Yes, it's that easy. There are some additional options, such as SSL 1.1354 + or Kerberos, which require additional steps to build. See the relevant 1.1355 + questions below.</p> 1.1356 + </dd> 1.1357 + </dl> 1.1358 + 1.1359 + <p><a href="#top">Back to top</a></p> 1.1360 + <hr> 1.1361 + 1.1362 + <p><a name="3.3"><strong>3.3 How do I make the IMAP and POP servers look for 1.1363 + INBOX at some place other than the mail spool 1.1364 + directory?</strong></a><br> 1.1365 + <a name="3.4"><strong>3.4 How do I make the IMAP server look for secondary 1.1366 + folders at some place other than the user's home 1.1367 + directory?</strong></a></p> 1.1368 + 1.1369 + <dl> 1.1370 + <dd>Please read the file CONFIG for discussion of this and other 1.1371 + issues.</dd> 1.1372 + </dl> 1.1373 + 1.1374 + <p><a href="#top">Back to top</a></p> 1.1375 + <hr> 1.1376 + 1.1377 + <p><a name="3.5"><strong>3.5 How do I configure SSL?</strong></a><br> 1.1378 + <a name="3.6"><strong>3.6 How do I configure TLS and the STARTTLS 1.1379 + facility?</strong></a></p> 1.1380 + 1.1381 + <dl> 1.1382 + <dd> 1.1383 + imap-2007 supports SSL and TLS client functionality on UNIX and 32-bit 1.1384 + Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS server 1.1385 + functionality on UNIX for IMAP and POP3. 1.1386 + 1.1387 + <p>UNIX SSL build requires that a third-party software package, 1.1388 + OpenSSL, be installed on the system first. Read imap-2007/docs/SSLBUILD 1.1389 + for more information.</p> 1.1390 + 1.1391 + <p>SSL is supported via undocumented Microsoft interfaces in Windows 9x 1.1392 + and NT4; and via standard interfaces in Windows 2000, Windows 1.1393 + Millenium, and Windows XP.</p> 1.1394 + </dd> 1.1395 + </dl> 1.1396 + 1.1397 + <p><a href="#top">Back to top</a></p> 1.1398 + <hr> 1.1399 + 1.1400 + <p><a name="3.7"><strong>3.7 How do I build/install OpenSSL and obtain/create 1.1401 + certificates for use with SSL?</strong></a></p> 1.1402 + 1.1403 + <dl> 1.1404 + <dd>If you need help in doing this, try the contacts mentioned in the 1.1405 + OpenSSL README. We do not offer support for OpenSSL or certificates.</dd> 1.1406 + </dl> 1.1407 + 1.1408 + <p><a href="#top">Back to top</a></p> 1.1409 + <hr> 1.1410 + 1.1411 + <p><a name="3.8"><strong>3.8 How do I configure CRAM-MD5 1.1412 + authentication?</strong></a><br> 1.1413 + <a name="3.9"><strong>3.9 How do I configure APOP 1.1414 + authentication?</strong></a></p> 1.1415 + 1.1416 + <dl> 1.1417 + <dd> 1.1418 + CRAM-MD5 authentication is enabled in the IMAP and POP3 client code on 1.1419 + all platforms. Read md5.txt to learn how to set up CRAM-MD5 and APOP 1.1420 + authentication on UNIX and NT servers. 1.1421 + 1.1422 + <p>There is no support for APOP client authentication.</p> 1.1423 + </dd> 1.1424 + </dl> 1.1425 + 1.1426 + <p><a href="#top">Back to top</a></p> 1.1427 + <hr> 1.1428 + 1.1429 + <p><a name="3.10"><strong>3.10 How do I configure Kerberos V5?</strong></a></p> 1.1430 + 1.1431 + <dl> 1.1432 + <dd> 1.1433 + imap-2007 supports client and server functionality on UNIX and 32-bit 1.1434 + Windows. 1.1435 + 1.1436 + <p>Kerberos V5 is supported by default in Windows 2000 builds:</p> 1.1437 + <pre> 1.1438 + nmake -f makefile.w2k 1.1439 +</pre> 1.1440 + 1.1441 + <p>Other builds require that a third-party Kerberos package, e.g. MIT 1.1442 + Kerberos, be installed on the system first.</p> 1.1443 + 1.1444 + <p>To build with Kerberos V5 on UNIX, include EXTRAAUTHENTICATORS=gss 1.1445 + in the make command line, e.g.</p> 1.1446 + <pre> 1.1447 + make lnp EXTRAAUTHENTICATORS=gss 1.1448 +</pre> 1.1449 + 1.1450 + <p>To build with Kerberos V5 on Windows 9x, Windows Millenium, and NT4, 1.1451 + use the "makefile.ntk" file instead of "makefile.nt":</p> 1.1452 + <pre> 1.1453 + 1.1454 + nmake -f makefile.ntk 1.1455 +</pre> 1.1456 + </dd> 1.1457 + </dl> 1.1458 + 1.1459 + <p><a href="#top">Back to top</a></p> 1.1460 + <hr> 1.1461 + 1.1462 + <p><a name="3.11"><strong>3.11 How do I configure PAM for plaintext 1.1463 + passwords?</strong></a></p> 1.1464 + 1.1465 + <dl> 1.1466 + <dd> 1.1467 + On Linux systems, use the lnp port, e.g. 1.1468 + <pre> 1.1469 + make lnp 1.1470 + 1.1471 +</pre>On Solaris systems and other systems with defective PAM 1.1472 +implementations, build with PASSWDTYPE=pmb, e.g. 1.1473 + <pre> 1.1474 + make sol PASSWDTYPE=pmb 1.1475 +</pre>On all other systems, build with PASSWDTYPE=pam, e.g 1.1476 + <pre> 1.1477 + make foo PASSWDTYPE=pam 1.1478 +</pre>If you build with PASSWDTYPE=pam and authentication does not work, try 1.1479 +rebuilding (after a "make clean") with PASSWDTYPE=pmb. 1.1480 + </dd> 1.1481 + </dl> 1.1482 + 1.1483 + <p><a href="#top">Back to top</a></p> 1.1484 + <hr> 1.1485 + 1.1486 + <p><a name="3.12"><strong>3.12 It looks like all I have to do to make the server 1.1487 + use Kerberos is to build with PAM on my Linux system, and set it up in 1.1488 + PAM for Kerberos passwords. Right?</strong></a></p> 1.1489 + 1.1490 + <dl> 1.1491 + <dd> 1.1492 + Yes and no. 1.1493 + 1.1494 + <p>Doing this will make plaintext password authentication use the 1.1495 + Kerberos password instead of the /etc/passwd password.</p> 1.1496 + 1.1497 + <p>However, this will NOT give you Kerberos-secure authentication. See 1.1498 + the answer to the <a href="#3.10">How do I configure Kerberos V5?</a> 1.1499 + question for how to build with Kerberos-secure authentication.</p> 1.1500 + </dd> 1.1501 + </dl> 1.1502 + 1.1503 + <p><a href="#top">Back to top</a></p> 1.1504 + <hr> 1.1505 + 1.1506 + <p><a name="3.13"><strong>3.13 How do I configure Kerberos 5 for plaintext 1.1507 + passwords?</strong></a></p> 1.1508 + 1.1509 + <dl> 1.1510 + <dd> 1.1511 + Build with PASSWDTYPE=gss, e.g. 1.1512 + <pre> 1.1513 + make sol PASSWDTYPE=gss 1.1514 +</pre>However, this will NOT give you Kerberos-secure authentication. See the 1.1515 +answer to the <a href="#3.10">How do I configure Kerberos V5?</a> question 1.1516 +for how to build with Kerberos-secure authentication. 1.1517 + </dd> 1.1518 + </dl> 1.1519 + 1.1520 + <p><a href="#top">Back to top</a></p> 1.1521 + <hr> 1.1522 + 1.1523 + <p><a name="3.14"><strong>3.14 How do I configure AFS for plaintext 1.1524 + passwords?</strong></a></p> 1.1525 + 1.1526 + <dl> 1.1527 + <dd> 1.1528 + Build with PASSWDTYPE=afs, e.g 1.1529 + <pre> 1.1530 + make sol PASSWDTYPE=afs 1.1531 + 1.1532 +</pre> 1.1533 + </dd> 1.1534 + </dl> 1.1535 + 1.1536 + <p><a href="#top">Back to top</a></p> 1.1537 + <hr> 1.1538 + 1.1539 + <p><a name="3.15"><strong>3.15 How do I configure DCE for plaintext 1.1540 + passwords?</strong></a></p> 1.1541 + 1.1542 + <dl> 1.1543 + <dd> 1.1544 + Build with PASSWDTYPE=dce, e.g 1.1545 + <pre> 1.1546 + make sol PASSWDTYPE=dce 1.1547 +</pre> 1.1548 + </dd> 1.1549 + </dl> 1.1550 + 1.1551 + <p><a href="#top">Back to top</a></p> 1.1552 + <hr> 1.1553 + 1.1554 + <p><a name="3.16"><strong>3.16 How do I configure the CRAM-MD5 database for 1.1555 + plaintext passwords?</strong></a></p> 1.1556 + 1.1557 + <dl> 1.1558 + <dd> 1.1559 + The CRAM-MD5 password database is automatically used for plaintext 1.1560 + password if it exists. 1.1561 + 1.1562 + <p>Note that this is NOT CRAM-MD5-secure authentication. You probably 1.1563 + want to consider disabling plaintext passwords for non-SSL/TLS 1.1564 + sessions. See the next two questions.</p> 1.1565 + </dd> 1.1566 + </dl> 1.1567 + 1.1568 + <p><a href="#top">Back to top</a></p> 1.1569 + <hr> 1.1570 + 1.1571 + <p><a name="3.17"><strong>3.17 How do I disable plaintext 1.1572 + passwords?</strong></a></p> 1.1573 + 1.1574 + <dl> 1.1575 + <dd> 1.1576 + Server-level plaintext passwords can be disabled by setting 1.1577 + PASSWDTYPE=nul, e.g. 1.1578 + <pre> 1.1579 + make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul 1.1580 +</pre>Note that you must have a CRAM-MD5 database installed or specify at 1.1581 +least one EXTRAAUTHENTICATOR, otherwise it will not be possible to log in to 1.1582 +the server. 1.1583 + 1.1584 + <p>When plaintext passwords are disabled, the IMAP server will 1.1585 + advertise the LOGINDISABLED capability and the POP3 server will not 1.1586 + advertise the USER capability.</p> 1.1587 + </dd> 1.1588 + </dl> 1.1589 + 1.1590 + <p><a href="#top">Back to top</a></p> 1.1591 + 1.1592 + <p><a name="3.18"><strong>3.18 How do I disable plaintext passwords on 1.1593 + unencrypted sessions, but allow them in SSL or TLS 1.1594 + sessions?</strong></a></p> 1.1595 + 1.1596 + <dl> 1.1597 + <dd> 1.1598 + <p>Do not set PASSWDTYPE=nul or SSLTYPE=unix. Set SSLTYPE=nopwd 1.1599 + instead, e.g.</p> 1.1600 + <pre> 1.1601 + make lnx SSLTYPE=nopwd 1.1602 +</pre> 1.1603 + 1.1604 + <p>When plaintext passwords are disabled, the IMAP server will 1.1605 + advertise the LOGINDISABLED capability and the POP3 server will not 1.1606 + advertise the USER capability.</p> 1.1607 + 1.1608 + <p>Plaintext passwords will always be enabled in SSL sessions; the IMAP 1.1609 + server will not advertise the LOGINDISABLED capability and the POP3 1.1610 + server will advertise the USER capability.</p> 1.1611 + 1.1612 + <p>If the client does a successful start-TLS in a non-SSL session, 1.1613 + plaintext passwords will be enabled, and a new CAPABILITY or CAPA 1.1614 + command (which is required after start-TLS) will show the effect as in 1.1615 + SSL sessions.</p> 1.1616 + </dd> 1.1617 + </dl> 1.1618 + 1.1619 + <p><a href="#top">Back to top</a></p> 1.1620 + <hr> 1.1621 + 1.1622 + <p><a name="3.19"><strong>3.19 How do I configure virtual 1.1623 + hosts?</strong></a></p> 1.1624 + 1.1625 + <dl> 1.1626 + <dd> 1.1627 + This is automatic, but with certain restrictions. 1.1628 + 1.1629 + <p>The most important one is that each virtual host must have its own 1.1630 + IP address; otherwise the server has no way of knowing which virtual 1.1631 + host is desired.</p> 1.1632 + 1.1633 + <p>As distributed, the software uses a global password file; hence user 1.1634 + "fred" on one virtual host is "fred" on all virtual hosts. You may want 1.1635 + to modify the checkpw() routine to implement some other policy (e.g. 1.1636 + separate password files).</p> 1.1637 + 1.1638 + <p>Note that the security model assumes that all users have their own 1.1639 + unique UNIX UID number. So if you use separate password files you 1.1640 + should make certain that the UID numbers do not overlap between 1.1641 + different files.</p> 1.1642 + 1.1643 + <p>More advanced virtual host support may be available as patches from 1.1644 + third parties.</p> 1.1645 + </dd> 1.1646 + </dl> 1.1647 + 1.1648 + <p><a href="#top">Back to top</a></p> 1.1649 + <hr> 1.1650 + 1.1651 + <p><a name="3.20"><strong>3.20 Why do I get compiler warning messages such 1.1652 + as:</strong></a></p> 1.1653 + <pre> 1.1654 + passing arg 3 of `scandir' from incompatible pointer type 1.1655 + Pointers are not assignment-compatible. 1.1656 + Argument #4 is not the correct type. 1.1657 + 1.1658 +</pre> 1.1659 + 1.1660 + <p><strong>during the build?</strong></p> 1.1661 + 1.1662 + <dl> 1.1663 + <dd> 1.1664 + You can safely ignore these messages. 1.1665 + 1.1666 + <p>Over the years, the prototype for scandir() has changed, and thus is 1.1667 + variant across different UNIX platforms. In particular, the definitions 1.1668 + of the third argument (type select_t) and fourth argument (type 1.1669 + compar_t) have changed over the years, the issue being whether or not 1.1670 + the arguments to the functions pointed to by these function pointers 1.1671 + are of type const or not.</p> 1.1672 + 1.1673 + <p>The way that c-client calls scandir() will tend to generate these 1.1674 + compiler warnings on newer systems such as Linux; however, it will 1.1675 + still build. The problem with fixing the call is that then it won't 1.1676 + build on older systems.</p> 1.1677 + </dd> 1.1678 + </dl> 1.1679 + 1.1680 + <p><a href="#top">Back to top</a></p> 1.1681 + <hr> 1.1682 + 1.1683 + <p><a name="3.21"><strong>3.21 Why do I get compiler warning messages such 1.1684 + as</strong></a></p> 1.1685 + <pre> 1.1686 + Operation between types "void(*)(int)" and "void*" is not allowed. 1.1687 + Function argument assignment between types "void*" and "void(*)(int)" is not allowed. 1.1688 + Pointers are not assignment-compatible. 1.1689 + Argument #5 is not the correct type. 1.1690 +</pre> 1.1691 + 1.1692 + <p><strong>during the build?</strong></p> 1.1693 + 1.1694 + <dl> 1.1695 + <dd> 1.1696 + You can safely ignore these messages. 1.1697 + 1.1698 + <p>All known systems have no problem with casting a function pointer 1.1699 + to/from a void* pointer, certain C compilers issue a compiler 1.1700 + diagnostic because this facility is listed as a "Common extension" by 1.1701 + the C standard:</p> 1.1702 + <pre> 1.1703 + K.5.7 Function pointer casts 1.1704 + [#1] A pointer to an object or to void may be cast to a pointer 1.1705 + to a function, allowing data to be invoked as a function (6.3.4). 1.1706 + [#2] A pointer to a function may be cast to a pointer to an 1.1707 + object or to void, allowing a function to be inspected or 1.1708 + modified (for example, by a debugger) (6.3.4). 1.1709 + 1.1710 +</pre>It may be just a "common extension", but this facility is relied upon 1.1711 +heavily by c-client. 1.1712 + </dd> 1.1713 + </dl> 1.1714 + 1.1715 + <p><a href="#top">Back to top</a></p> 1.1716 + <hr> 1.1717 + 1.1718 + <p><a name="3.22"><strong>3.22 Why do I get linker warning messages such 1.1719 + as:</strong></a></p> 1.1720 + <pre> 1.1721 +mtest.c:515: the `gets' function is dangerous and should not be used. 1.1722 +</pre> 1.1723 + 1.1724 + <p><strong>during the build? Isn't this a security bug?</strong></p> 1.1725 + 1.1726 + <dl> 1.1727 + <dd> 1.1728 + You can safely ignore this message. 1.1729 + 1.1730 + <p>Certain linkers, most notably on Linux, give this warning message. 1.1731 + It is indeed true that the traditional gets() function is not a safe 1.1732 + one.</p> 1.1733 + 1.1734 + <p>However, the mtest program is only a demonstration program, a model 1.1735 + of a very basic application program using c-client. It is not something 1.1736 + that you would install, much less run in any security-sensitive 1.1737 + context.</p> 1.1738 + 1.1739 + <p>mtest has numerous other shortcuts that you wouldn't want to do in a 1.1740 + real application program.</p> 1.1741 + 1.1742 + <p>The only "security bug" with mtest would be if it was run by some 1.1743 + script in a security-sensitive context, but mtest isn't particularly 1.1744 + useful for such purposes. If you wanted to write a script to automate 1.1745 + some email task using c-client, you'd be better off using imapd instead 1.1746 + of mtest.</p> 1.1747 + 1.1748 + <p>mtest only has two legitimate uses. It's a useful testbed for me 1.1749 + when debugging new versions of c-client, and it's useful as a model for 1.1750 + someone writing a simple c-client application to see how the various 1.1751 + calls work.</p> 1.1752 + 1.1753 + <p>By the way, if you need a more advanced example of c-client 1.1754 + programming than mtest (and you probably will), I recommend that you 1.1755 + look at the source code for imapd and Pine.</p> 1.1756 + </dd> 1.1757 + </dl> 1.1758 + 1.1759 + <p><a href="#top">Back to top</a></p> 1.1760 + <hr> 1.1761 + 1.1762 + <p><a name="3.23"><strong>3.23 Why do I get linker warning messages such 1.1763 + as:</strong></a></p> 1.1764 + <pre> 1.1765 + auth_ssl.c:92: the `tmpnam' function is dangerous and should not be used. 1.1766 +</pre> 1.1767 + 1.1768 + <p><strong>during the build? Isn't this a security bug?</strong></p> 1.1769 + 1.1770 + <dl> 1.1771 + <dd> 1.1772 + You can safely ignore this message. 1.1773 + 1.1774 + <p>Certain linkers, most notably on Linux, give this warning message, 1.1775 + based upon two known issues with tmpnam():</p> 1.1776 + 1.1777 + <dl> 1.1778 + <dd>there can be a buffer overflow if an inadequate buffer is 1.1779 + allocated.</dd> 1.1780 + 1.1781 + <dd>there can be a timing race caused by certain incautious usage of 1.1782 + the return value.</dd> 1.1783 + </dl> 1.1784 + 1.1785 + <p>Neither of these issues applies in the particular use that is made 1.1786 + of tmpnam(). More importantly, the tmpnam() call is never executed on 1.1787 + Linux systems.</p> 1.1788 + </dd> 1.1789 + </dl> 1.1790 + 1.1791 + <p><a href="#top">Back to top</a></p> 1.1792 + <hr> 1.1793 + 1.1794 + <p><a name="3.24"><strong>3.24 OK, suppose I see a warning message about a 1.1795 + function being "dangerous and should not be used" for something other 1.1796 + than this gets() or tmpnam() call?</strong></a></p> 1.1797 + 1.1798 + <dl> 1.1799 + <dd>Please forward the details for investigation.</dd> 1.1800 + </dl> 1.1801 + 1.1802 + <p><a href="#top">Back to top</a></p> 1.1803 + <hr> 1.1804 + 1.1805 + <p><br></p> 1.1806 + 1.1807 + <h2><a name="operation">4. Operational Questions</a></h2> 1.1808 + <hr> 1.1809 + 1.1810 + <p><a name="4.1"><strong>4.1 How can I enable anonymous IMAP 1.1811 + logins?</strong></a></p> 1.1812 + 1.1813 + <dl> 1.1814 + <dd>Create the file /etc/anonymous.newsgroups. At the present time, this 1.1815 + file should be empty. This will permit IMAP logins as anonymous as well 1.1816 + as the ANONYMOUS SASL authenticator. Anonymous users have access to 1.1817 + mailboxes in the #news., #ftp/, and #public/ namespaces only.</dd> 1.1818 + </dl> 1.1819 + 1.1820 + <p><a href="#top">Back to top</a></p> 1.1821 + <hr> 1.1822 + 1.1823 + <p><a name="4.2"><strong>4.2 How do I set up an alert message that each IMAP 1.1824 + user will see?</strong></a></p> 1.1825 + 1.1826 + <dl> 1.1827 + <dd>Create the file /etc/imapd.alert with the text of the message. This 1.1828 + text should be kept to one line if possible. Note that this will cause an 1.1829 + alert to every IMAP user every time they initiate an IMAP session, so it 1.1830 + should only be used for critical messages.</dd> 1.1831 + </dl> 1.1832 + 1.1833 + <p><a href="#top">Back to top</a></p> 1.1834 + <hr> 1.1835 + 1.1836 + <p><a name="4.3"><strong>4.3 How does the c-client library choose which of its 1.1837 + several mechanisms to use to establish an IMAP connection to the server? 1.1838 + I noticed that it can connect on port 143, port 993, via rsh, and via 1.1839 + ssh.</strong></a></p> 1.1840 + 1.1841 + <dl> 1.1842 + <dd> 1.1843 + c-client chooses how to establish an IMAP connection via the following 1.1844 + rules: 1.1845 + 1.1846 + <ul> 1.1847 + <li>If /ssl is specified, use an SSL connection. Fail otherwise.</li> 1.1848 + 1.1849 + <li>Else if client is a UNIX system and "ssh server exec /etc/rimapd" 1.1850 + works, use that</li> 1.1851 + 1.1852 + <li>Else if /tryssl is specified and an SSL connection works, use 1.1853 + that.</li> 1.1854 + 1.1855 + <li>Else if client is a UNIX system and "rsh server exec /etc/rimapd" 1.1856 + works, use that.</li> 1.1857 + 1.1858 + <li>Else use a non-SSL connection.</li> 1.1859 + </ul> 1.1860 + </dd> 1.1861 + </dl> 1.1862 + 1.1863 + <p><a href="#top">Back to top</a></p> 1.1864 + <hr> 1.1865 + 1.1866 + <p><a name="4.4"><strong>4.4 I am using a TLS-capable IMAP server, so I don't 1.1867 + need to use /ssl to get encryption. However, I want to be certain that 1.1868 + my session is TLS encrypted before I send my password. How to I do 1.1869 + this?</strong></a></p> 1.1870 + 1.1871 + <dl> 1.1872 + <dd>Use the /tls option in the mailbox name. This will cause an error 1.1873 + message and the connection to fail if the server does not negotiate 1.1874 + STARTTLS.</dd> 1.1875 + </dl> 1.1876 + 1.1877 + <p><a href="#top">Back to top</a></p> 1.1878 + <hr> 1.1879 + 1.1880 + <p><a name="4.5"><strong>4.5 How do I use one of the alternative formats 1.1881 + described in the formats.txt document? In particular, I hear that mbx 1.1882 + format will give me better performance and allow shared 1.1883 + access.</strong></a></p> 1.1884 + 1.1885 + <dl> 1.1886 + <dd> 1.1887 + The rumors about mbx format being preferred are true. It is faster than 1.1888 + the traditional UNIX mailbox format and permits shared access. 1.1889 + 1.1890 + <p>However, and this is <em>very important</em>, note that using an 1.1891 + alternative mailbox format is an advanced facility, and only expert 1.1892 + users should undertake it. If you don't understand any of the following 1.1893 + notes, you may not be enough of an expert yet, and are probably better 1.1894 + off not going this route until you are more comfortable with your 1.1895 + understanding.</p> 1.1896 + 1.1897 + <p>Some of the formats, including mbx, are only supported by the 1.1898 + software based on the c-client library, and are not recognized by other 1.1899 + mailbox programs. The "vi" editor will corrupt any mbx format mailbox 1.1900 + that it encounters.</p> 1.1901 + 1.1902 + <p>Another problem is that the certain formats, including mbx, use 1.1903 + advanced file access and locking techniques that do <em>not</em> work 1.1904 + reliably with NFS. NFS is not a real filesystem. Use IMAP instead of 1.1905 + NFS for distributed access.</p> 1.1906 + 1.1907 + <p>Each of the following steps are in escalating order of involvement. 1.1908 + The further you go down this list, the more deeply committed you 1.1909 + become:</p> 1.1910 + 1.1911 + <ul> 1.1912 + <li>The simplest way to create a mbx-format mailbox is to prefix the 1.1913 + name with "#driver.mbx/" when creating a mailbox through c-client. 1.1914 + For example, if you create "#driver.mbx/foo", the mailbox "foo" will 1.1915 + be created in mbx format. Only use "#driver.mbx/" when creating the 1.1916 + mailbox. At all other times, just use the name ("foo" in this 1.1917 + example); the software will automatically select the driver for mbx 1.1918 + whenever that mailbox is accessed without you doing anything 1.1919 + else.</li> 1.1920 + 1.1921 + <li>You can use the "mailutil copy" command to copy an existing 1.1922 + mailbox to a new mailbox in mbx format. Read the man page provided 1.1923 + with the mailutil program for details.</li> 1.1924 + 1.1925 + <li>If you create an mbx-format INBOX, by creating 1.1926 + "#driver.mbx/INBOX" (note that "INBOX" must be all uppercase), then 1.1927 + subsequent access to INBOX by any c-client based application will use 1.1928 + the mbx-format INBOX. Any mail delivered to the traditional format 1.1929 + mailbox in the spool directory (e.g. /var/spool/mail/$USER) will 1.1930 + automatically be copied into the mbx-format INBOX and the spool 1.1931 + directory copy removed.</li> 1.1932 + 1.1933 + <li>You can cause any newly-created mailboxes to be in mbx-format by 1.1934 + default by changing the definition of CREATEPROTO=unixproto to be 1.1935 + CREATEPROTO=mbxproto in src/osdep/unix/Makefile, then rebuilding the 1.1936 + IMAP toolkit (do a "make clean" first). Do not change EMPTYPROTO, 1.1937 + since mbx format mailboxes are never a zero-byte file. If you use 1.1938 + Pine or the imap-utils, you should probably also rebuild them with 1.1939 + the new IMAP toolkit too.</li> 1.1940 + 1.1941 + <li>You can deliver directly to the mbx-format INBOX by use of the 1.1942 + tmail or dmail programs. tmail is for direct invocation from sendmail 1.1943 + (or whatever MTA program you use); dmail is for calls from procmail. 1.1944 + Both of these programs have man pages which must be read carefully 1.1945 + before making this change.</li> 1.1946 + </ul> 1.1947 + 1.1948 + <p>Most other servers (e.g. Cyrus) require use of a non-standard 1.1949 + format. A full-fledged format conversion is not significantly different 1.1950 + from what you have to do with other servers. The difference, which 1.1951 + makes format conversion procedures somewhat more complicated with this 1.1952 + server, is that there is no "all or nothing" requirement with this 1.1953 + server. There are many points in between. A format conversion can be 1.1954 + anything from a single mailbox or single user, to systemwide.</p> 1.1955 + 1.1956 + <p>This is good in that you can decide how far to go, or do the steps 1.1957 + incrementally as you become more comfortable with the result. On the 1.1958 + other hand, there's no "One True Way" which can be boiled down to a 1.1959 + simple set of pedagogical instructions.</p> 1.1960 + 1.1961 + <p>A number of sites have done full-fledged format conversions, and are 1.1962 + reportedly quite happy with the results. Feel free to ask in the 1.1963 + comp.mail.imap newsgroup or the imap-uw mailing list for advice or 1.1964 + help.</p> 1.1965 + </dd> 1.1966 + </dl> 1.1967 + 1.1968 + <p><a href="#top">Back to top</a></p> 1.1969 + <hr> 1.1970 + 1.1971 + <p><a name="4.6"><strong>4.6 How do I set up shared mailboxes?</strong></a></p> 1.1972 + 1.1973 + <dl> 1.1974 + <dd> 1.1975 + At the simplest level, a shared mailbox is one which has UNIX file and 1.1976 + directory protections which permit multiple users to access it. What 1.1977 + this means is that your existing skills and tools to create and manage 1.1978 + shared files on your UNIX system apply to shared mailboxes; e.g. 1.1979 + <pre> 1.1980 + chmod 666 mailbox 1.1981 +</pre> 1.1982 + 1.1983 + <p>You may want to consider the use of a mailbox format which permits 1.1984 + multiple simultaneous read/write sessions, such as the mbx format. The 1.1985 + traditional UNIX format only allows one read/write session to a 1.1986 + mailbox at a time.</p> 1.1987 + 1.1988 + <p>An additional convenience item are three system directories, which 1.1989 + can be set up for shared namespaces. These are: #ftp, #shared, and 1.1990 + #public, and are defined by creating the associated UNIX users and home 1.1991 + directories as described below.</p> 1.1992 + 1.1993 + <p>#ftp/ refers to the anonymous ftp filesystem exported by the ftp 1.1994 + server, and is equivalent to the home directory for UNIX user "ftp". 1.1995 + For example, #ftp/foo/bar refers to the file /foo/bar in the anonymous 1.1996 + FTP filesystem, or ~ftp/foo/bar for normal users. Anonymous FTP files 1.1997 + are available to anonymous IMAP logins. By default, newly-created files 1.1998 + in #ftp/ are protected 644.</p> 1.1999 + 1.2000 + <p>#public/ refers to an IMAP toolkit convention called "public" files, 1.2001 + and is equivalent to the home directory for UNIX user "imappublic". For 1.2002 + example, #public/foo/bar refers to the file ~imappublic/foo/bar. Public 1.2003 + files are available to anonymous IMAP logins. By default, newly-created 1.2004 + files in #public are created with protection 0666.</p> 1.2005 + 1.2006 + <p>#shared/ refers to an IMAP toolkit convention called "shared" files, 1.2007 + and is equivalent to the home directory for UNIX user "imapshared". For 1.2008 + example, #shared/foo/bar refers to the file ~imapshared/foo/bar. Shared 1.2009 + files are <em>not</em> available to anonymous IMAP logins. By default, 1.2010 + newly-created files in #shared are created with protection 0660.</p> 1.2011 + </dd> 1.2012 + </dl> 1.2013 + 1.2014 + <p><a href="#top">Back to top</a></p> 1.2015 + <hr> 1.2016 + 1.2017 + <p><a name="4.7"><strong>4.7 How can I make the server syslogs go to someplace 1.2018 + other than the mail syslog?</strong></a></p> 1.2019 + 1.2020 + <dl> 1.2021 + <dd> 1.2022 + The openlog() call that sets the syslog facility is in 1.2023 + <strong>src/osdep/unix/env_unix.c</strong> in routine 1.2024 + <strong>server_init()</strong>. You need to edit this file to change 1.2025 + the syslog facility from LOG_MAIL to the facility you want, then 1.2026 + rebuild. You also need to set up your /etc/syslog.conf properly. 1.2027 + 1.2028 + <p>Refer to the man pages for syslog and syslogd for more information 1.2029 + on what the available syslog facilities are and how to configure 1.2030 + syslogs. If you still don't understand what to do, find a UNIX system 1.2031 + expert.</p> 1.2032 + </dd> 1.2033 + </dl> 1.2034 + 1.2035 + <p><a href="#top">Back to top</a></p> 1.2036 + <hr> 1.2037 + 1.2038 + <p><br></p> 1.2039 + 1.2040 + <h2><a name="security">5. Security Questions</a></h2> 1.2041 + <hr> 1.2042 + 1.2043 + <p><a name="5.1"><strong>5.1 I see that the IMAP server allows access to 1.2044 + arbitary files on the system, including /etc/passwd! How do I disable 1.2045 + this?</strong></a></p> 1.2046 + 1.2047 + <dl> 1.2048 + <dd> 1.2049 + You should not worry about this if your IMAP users are allowed shell 1.2050 + access. The IMAP server does not permit any access that the user can 1.2051 + not have via the shell. 1.2052 + 1.2053 + <p>If, and only if, you deny your IMAP users shell access, you may want 1.2054 + to consider one of three choices. Note that these choices reduce IMAP 1.2055 + functionality, and may have undesirable side effects. Each of these 1.2056 + choices involves an edit to file 1.2057 + <strong>src/osdep/unix/env_unix.c</strong></p> 1.2058 + 1.2059 + <p>The first (and recommended) choice is to set 1.2060 + <strong>restrictBox</strong> as described in file CONFIG. This will 1.2061 + disable access to the filesystem root, to other users' home directory, 1.2062 + and to superior directory.</p> 1.2063 + 1.2064 + <p>The second (and strongly NOT recommended) choice is to set 1.2065 + <strong>closedBox</strong> as described in file CONFIG. This puts each 1.2066 + IMAP session into a so-called "chroot jail", and thus setting this 1.2067 + option is <em>extremely</em> dangerous; it can make your system much 1.2068 + less secure and open to root compromise attacks. So do not use this 1.2069 + option unless you are <em>absolutely certain</em> that you understand 1.2070 + all the issues of a "chroot jail."</p> 1.2071 + 1.2072 + <p>The third choice is to rewrite routine 1.2073 + <strong>mailboxfile()</strong> to implement whatever mapping from 1.2074 + mailbox name to filesystem name (and restrictions) that you wish. This 1.2075 + is the most general choice. As a guide, you can see at the start of 1.2076 + routine <strong>mailboxfile()</strong> what the 1.2077 + <strong>restrictBox</strong> choice does.</p> 1.2078 + </dd> 1.2079 + </dl> 1.2080 + 1.2081 + <p><a href="#top">Back to top</a></p> 1.2082 + <hr> 1.2083 + 1.2084 + <p><a name="5.2"><strong>5.2 I've heard that IMAP servers are insecure. Is this 1.2085 + true?</strong></a></p> 1.2086 + 1.2087 + <dl> 1.2088 + <dd> 1.2089 + There are no known security problems in this version of the IMAP 1.2090 + toolkit, including the IMAP and POP servers. The IMAP and POP servers 1.2091 + limit what can be done while not logged in, and as part of the login 1.2092 + process discard all privileges except those of the user. 1.2093 + 1.2094 + <p>As with other software packages, there have been buffer overflow 1.2095 + vulnerabilities in past versions. All known problems of this nature are 1.2096 + fixed in this version.</p> 1.2097 + 1.2098 + <p>There is every reason to believe that the bad guys are engaged in an 1.2099 + ongoing effort to find vulnerabilities in the IMAP toolkit. We look for 1.2100 + such problems, and when one is found we fix it.</p> 1.2101 + 1.2102 + <p>It's unfortunate that any vulnerabilities existed in past versions, 1.2103 + and we're doing my best to keep the IMAP toolkit free of 1.2104 + vulnerabilities. No new vulnerabilities have been discovered in quite a 1.2105 + while, but efforts will not be relaxed.</p> 1.2106 + 1.2107 + <p>Beware of vendors who claim that their implementations can not have 1.2108 + vulnerabilities.</p> 1.2109 + </dd> 1.2110 + </dl> 1.2111 + 1.2112 + <p><a href="#top">Back to top</a></p> 1.2113 + <hr> 1.2114 + 1.2115 + <p><a name="5.3"><strong>5.3 How do I know that I have the most secure version 1.2116 + of the server?</strong></a></p> 1.2117 + 1.2118 + <dl> 1.2119 + <dd> 1.2120 + The best way is to keep your server software up to date. The bad guys 1.2121 + are always looking for ways to crack software, and when they find one, 1.2122 + let all their friends know. 1.2123 + 1.2124 + <p>Oldtimers used to refer to a concept of <em>software rot</em>: if 1.2125 + your software hasn't been updated in a while, it would "rot" -- tend to 1.2126 + acquire problems that it didn't have when it was new.</p> 1.2127 + 1.2128 + <p>The latest release version of the IMAP toolkit is always available 1.2129 + at <a href= 1.2130 + "ftp://ftp.cac.washington.edu/mail/imap.tar.Z">ftp://ftp.cac.washington.edu/mail/imap.tar.Z</a></p> 1.2131 + </dd> 1.2132 + </dl> 1.2133 + 1.2134 + <p><a href="#top">Back to top</a></p> 1.2135 + <hr> 1.2136 + 1.2137 + <p><a name="5.4"><strong>5.4 I see all these strcpy() and sprintf() calls, those 1.2138 + are unsafe, aren't they?</strong></a></p> 1.2139 + 1.2140 + <dl> 1.2141 + <dd> 1.2142 + Yes and no. 1.2143 + 1.2144 + <p>It can be unsafe to do these calls if you do not know that the 1.2145 + string being written will fit in the buffer. However, they are 1.2146 + perfectly safe if you do know that.</p> 1.2147 + 1.2148 + <p>Beware of programmers who advocate doing a brute-force change of all 1.2149 + instances of</p> 1.2150 + <pre> 1.2151 + strcpy (s,t); 1.2152 +</pre>to 1.2153 + <pre> 1.2154 + strncpy (s,t,n)[n] = '\0'; 1.2155 +</pre>and similar measures in the name of "fixing all possible buffer 1.2156 +overflows." 1.2157 + 1.2158 + <p>There are examples in which a security bug was introduced because of 1.2159 + this type of "fix", due to the programmer using the wrong value for n. 1.2160 + In one case, the programmer thought that n was larger than it actually 1.2161 + was, causing a NUL to be written out of the buffer; in another, n was 1.2162 + too small, and a security credential was truncated.</p> 1.2163 + 1.2164 + <p>What is particularly ironic was that in both cases, the original 1.2165 + strcpy() was safe, because the size of the source string was known to 1.2166 + be safe.</p> 1.2167 + 1.2168 + <p>With all this in mind, the software has been inspected, and it is 1.2169 + believed that all places where buffer overflows can happen have been 1.2170 + fixed. The strcpy()s that are still are in the code occur after a size 1.2171 + check was done in some other way.</p> 1.2172 + 1.2173 + <p>Note that the common C idiom of</p> 1.2174 + <pre> 1.2175 + *s++ = c; 1.2176 +</pre>is just as vulnerable to buffer overflows. You can't cure buffer 1.2177 +overflows by outlawing certain functions, nor is it desirable to do so; 1.2178 +sometimes operations like strcpy() translate into fast machine instructions 1.2179 +for better performance. 1.2180 + 1.2181 + <p>Nothing replaces careful study of code. That's how the bad guys find 1.2182 + bugs. Security is not accomplished by means of brute-force 1.2183 + shortcuts.</p> 1.2184 + </dd> 1.2185 + </dl> 1.2186 + 1.2187 + <p><a href="#top">Back to top</a></p> 1.2188 + <hr> 1.2189 + 1.2190 + <p><a name="5.5"><strong>5.5 Those /tmp lock files are protected 666, is that 1.2191 + really right?</strong></a></p> 1.2192 + 1.2193 + <dl> 1.2194 + <dd> 1.2195 + Yes. Shared mailboxes won't work otherwise. Also, you get into 1.2196 + accidental denial of service problems with old lock files left lying 1.2197 + around; this happens fairly frequently. 1.2198 + 1.2199 + <p>The deliberate mischief that can be caused by fiddling with the lock 1.2200 + files is small-scale; harassment level at most. There are many -- and 1.2201 + much more effective -- other ways of harassing another user on UNIX. 1.2202 + It's usually not difficult to determine the culprit.</p> 1.2203 + 1.2204 + <p>Before worrying about deliberate mischief, worry first about things 1.2205 + happening by accident!</p> 1.2206 + </dd> 1.2207 + </dl> 1.2208 + 1.2209 + <p><a href="#top">Back to top</a></p> 1.2210 + <hr> 1.2211 + 1.2212 + <p><br></p> 1.2213 + 1.2214 + <h2><a name="strange">6. <em>Why Did You Do This Strange Thing?</em> 1.2215 + Questions</a></h2> 1.2216 + <hr> 1.2217 + 1.2218 + <p><a name="6.1"><strong>6.1 Why don't you use GNU autoconfig / automake / 1.2219 + autoblurdybloop?</strong></a></p> 1.2220 + 1.2221 + <dl> 1.2222 + <dd> 1.2223 + Autoconfig et al are not available on all the platforms where the IMAP 1.2224 + toolkit is supported; and do not work correctly on some of the 1.2225 + platforms where they do exist. Furthermore, these programs add another 1.2226 + layer of complexity to an already complex process. 1.2227 + 1.2228 + <p>Coaxing software that uses autoconfig to build properly on platforms 1.2229 + which were not specifically considered by that software wastes an 1.2230 + inordinate amount of time. When (not if) autoconfig fails to do the 1.2231 + right thing, the result is an inpenetrable morass to untangle in order 1.2232 + to find the problem and fix it.</p> 1.2233 + 1.2234 + <p>The concept behind autoconfig is good, but the execution is flawed. 1.2235 + It rarely does the right thing on a platform that wasn't specifically 1.2236 + considered. Human life is too short to debug autoconfig problems, 1.2237 + especially since the current mechanism is so much easier.</p> 1.2238 + </dd> 1.2239 + </dl> 1.2240 + 1.2241 + <p><a href="#top">Back to top</a></p> 1.2242 + <hr> 1.2243 + 1.2244 + <p><a name="6.2"><strong>6.2 Why do you insist upon a build with -g? Doesn't it 1.2245 + waste disk and memory space?</strong></a></p> 1.2246 + 1.2247 + <dl> 1.2248 + <dd> 1.2249 + From time to time a submitted port has snuck in without -g. This has 1.2250 + <em>always</em> ended up causing problems. There are only two valid 1.2251 + excuses for not using -g in a port: 1.2252 + 1.2253 + <ul> 1.2254 + <li>The compiler does not support -g</li> 1.2255 + 1.2256 + <li>An alternate form of -g is needed with optimization, e.g. 1.2257 + -g3.</li> 1.2258 + </ul> 1.2259 + 1.2260 + <p>There will be no new ports added without -g (or a suitable 1.2261 + alternative) being set.</p> 1.2262 + 1.2263 + <p>-g has not been arbitrarily added to the ports which do not 1.2264 + currently have it because we don't know if doing so would break the 1.2265 + build. However, any support issues with one of those port <em>will</em> 1.2266 + lead to the correct -g setting being determined and permanently 1.2267 + added.</p> 1.2268 + 1.2269 + <p>Processors are fast enough (and disk space is cheap enough) that -g 1.2270 + should be automatic in all compilers with no way of turning it off, and 1.2271 + /bin/strip should be a symlink to /bin/true. Human life is too short to 1.2272 + deal with binaries built without -g. Such binaries should be a bad 1.2273 + memory of the days of KIPS processors and disks that costs several 1.2274 + dollars per kilobyte.</p> 1.2275 + </dd> 1.2276 + </dl> 1.2277 + 1.2278 + <p><a href="#top">Back to top</a></p> 1.2279 + <hr> 1.2280 + 1.2281 + <p><a name="6.3"><strong>6.3 Why don't you make c-client a shared 1.2282 + library?</strong></a></p> 1.2283 + 1.2284 + <dl> 1.2285 + <dd> 1.2286 + All too often, shared libraries create far more problems than they 1.2287 + solve. 1.2288 + 1.2289 + <p>Remember that you only gain the benefit of a shared library when 1.2290 + there are multiple applications which use that shared library. Even 1.2291 + without shared libraries, on most modern operating systems (and many 1.2292 + ancient ones too!) applications will share their text segments between 1.2293 + across multiple processes running the same application. This means that 1.2294 + if your system only runs one application (e.g. imapd) that uses the 1.2295 + c-client library, then you gain no benefit from making c-client a 1.2296 + shared library even if it has 100 imapd processes. You will, however 1.2297 + suffer added complexity.</p> 1.2298 + 1.2299 + <p>If you have a server system that just runs imapd and ipop3d, then 1.2300 + making c-client a shared library will save just one copy of c-client no 1.2301 + matter how many IMAP/POP3 processes are running.</p> 1.2302 + 1.2303 + <p>The problem with shared libraries is that you have to keep around a 1.2304 + copy of the library every time something changes in the library that 1.2305 + would affect the interface the library presents to the application. So, 1.2306 + you end up having many copies of the same shared library.</p> 1.2307 + 1.2308 + <p>If you don't keep multiple copies of the shared library, then one of 1.2309 + two things happens. If there was proper versioning, then you'll get a 1.2310 + message such as "cannot open shared object file" or "minor versions 1.2311 + don't match" and the application won't run. Otherwise, the application 1.2312 + will run, but will fail in mysterious ways.</p> 1.2313 + 1.2314 + <p>Several sites and third-party distributors have modified the 1.2315 + c-client makefile in order to make c-client be a shared library. 1.2316 + <em>When</em> (not <em>if</em>) a c-client based application fails in 1.2317 + mysterious ways because of a library compatibility problem, the result 1.2318 + is a bug report. A lot of time and effort ends up getting wasted 1.2319 + investigating such bug reports.</p> 1.2320 + 1.2321 + <p>Memory is so cheap these days that it's not worth it. Human life is 1.2322 + too short to deal with shared library compatibility problems.</p> 1.2323 + </dd> 1.2324 + </dl> 1.2325 + 1.2326 + <p><a href="#top">Back to top</a></p> 1.2327 + <hr> 1.2328 + 1.2329 + <p><a name="6.4"><strong>6.4 Why don't you use iconv() for internationalization 1.2330 + support?</strong></a></p> 1.2331 + 1.2332 + <dl> 1.2333 + <dd>iconv() is not ubiquitous enough.</dd> 1.2334 + </dl> 1.2335 + 1.2336 + <p><a href="#top">Back to top</a></p> 1.2337 + <hr> 1.2338 + 1.2339 + <p><a name="6.5"><strong>6.5 Why is the IMAP server connected to the home 1.2340 + directory by default?</strong></a></p> 1.2341 + 1.2342 + <dl> 1.2343 + <dd> 1.2344 + The IMAP server has no way of knowing what you might call "mail" as 1.2345 + opposed to "some other file"; in fact, you can use IMAP to access any 1.2346 + file. 1.2347 + 1.2348 + <p>The IMAP server also doesn't know whether your preferred 1.2349 + subdirectory for mailbox files is "mail/", ".mail/", "Mail/", 1.2350 + "Mailboxes/", or any of a zillion other possibilities. If one such name 1.2351 + were chosen, it would undoubtably anger the partisans of all the other 1.2352 + names.</p> 1.2353 + 1.2354 + <p>It is possible to modify the software so that the default connected 1.2355 + directory is someplace else. Please read the file CONFIG for discussion 1.2356 + of this and other issues.</p> 1.2357 + </dd> 1.2358 + </dl> 1.2359 + 1.2360 + <p><a href="#top">Back to top</a></p> 1.2361 + <hr> 1.2362 + 1.2363 + <p><a name="6.6"><strong>6.6 I have a Windows system. Why isn't the server plug 1.2364 + and play for me?</strong></a></p> 1.2365 + 1.2366 + <dl> 1.2367 + <dd> 1.2368 + There is no standard for how mail is stored on Windows; nor a single 1.2369 + standard SMTP server. The closest to either would be the SMTP server in 1.2370 + Microsoft's IIS. 1.2371 + 1.2372 + <p>So there's no default by which to make assumptions. As the software 1.2373 + is set up, it assumes that the each user has an Windows login account 1.2374 + and private home directory, and that mail is stored on that home 1.2375 + directory as files in one of the popular UNIX formats. It also assumes 1.2376 + that there is some tool equivalent to inetd on UNIX that does the 1.2377 + TCP/IP listening and server startup.</p> 1.2378 + 1.2379 + <p>Basically, unless you're an email software hacker, you probably want 1.2380 + to look elsewhere if you want IMAP/POP servers for Windows.</p> 1.2381 + </dd> 1.2382 + </dl> 1.2383 + 1.2384 + <p><a href="#top">Back to top</a></p> 1.2385 + <hr> 1.2386 + 1.2387 + <p><a name="6.7"><strong>6.7 I looked at the UNIX SSL code and saw that you have 1.2388 + the SSL data payload size set to 8192 bytes. SSL allows 16K; why aren't 1.2389 + you using the full size?</strong></a></p> 1.2390 + 1.2391 + <dl> 1.2392 + <dd> 1.2393 + This is to avoid an interoperability problem with: 1.2394 + 1.2395 + <ul> 1.2396 + <li>PC IMAP clients that use Microsoft's SChannel.DLL (SSPI) for SSL 1.2397 + support</li> 1.2398 + 1.2399 + <li>Microsoft Exchange server (which also uses SChannel).</li> 1.2400 + </ul> 1.2401 + 1.2402 + <p>SChannel has a bug that makes it think that the maximum SSL data 1.2403 + payload size is 16379 bytes -- 5 bytes too small. Thus, c-client has to 1.2404 + make sure that it never transmits full sized SSL packets.</p> 1.2405 + 1.2406 + <p>The reason for using 8K (as opposed to, say, 16379 bytes, or 15K, 1.2407 + or...) is that it corresponds with the TCP buffer size that the 1.2408 + software uses elsewhere for input; there's a slight performance benefit 1.2409 + to having the two sizes correspond or at least be a multiple of each 1.2410 + other. Also, it keeps the size as a power of two, which might be 1.2411 + significant on some platforms.</p> 1.2412 + 1.2413 + <p>There wasn't a significant difference that we could measure between 1.2414 + 8K and 15K.</p> 1.2415 + 1.2416 + <p>Microsoft has developed a hotfix for this bug. Look up MSKB article 1.2417 + number 300562. Contrary to the article text which implies that this is 1.2418 + a Pine issue, this bug also affects Microsoft Exchange server with 1.2419 + <em>any</em> client that transmits full-sized SSL payloads.</p> 1.2420 + </dd> 1.2421 + </dl> 1.2422 + 1.2423 + <p><a href="#top">Back to top</a></p> 1.2424 + <hr> 1.2425 + 1.2426 + <p><a name="6.8"><strong>6.8 Why is an mh format INBOX called #mhinbox instead 1.2427 + of just INBOX?</strong></a></p> 1.2428 + 1.2429 + <dl> 1.2430 + <dd> 1.2431 + It's a long story. In brief, the mh format driver is less functional 1.2432 + than any of the other drivers. It turned out that there were some users 1.2433 + (including high-level administrators) who tried mh years ago and no 1.2434 + longer use it, but still had an mh profile left behind. 1.2435 + 1.2436 + <p>When the mh driver used INBOX, it would see the mh profile, and 1.2437 + proceed to move the user's INBOX into the mh format INBOX. This caused 1.2438 + considerable confusion as some things stopped working.</p> 1.2439 + </dd> 1.2440 + </dl> 1.2441 + 1.2442 + <p><a href="#top">Back to top</a></p> 1.2443 + <hr> 1.2444 + 1.2445 + <p><a name="6.9"><strong>6.9 Why don't you support the maildir 1.2446 + format?</strong></a></p> 1.2447 + 1.2448 + <dl> 1.2449 + <dd> 1.2450 + It is technically difficult to support maildir in IMAP while 1.2451 + maintaining acceptable performance, robustness, following the 1.2452 + requirements of the IMAP protocol specification, and following the 1.2453 + requirements of maildir. 1.2454 + 1.2455 + <p>No one has succeeded in accomplishing all four together. The various 1.2456 + maildir drivers offered as patches all have these problems. The problem 1.2457 + is exacerbated because this implementation supports multiple formats; 1.2458 + consequently this implementation can't make any performance shortcuts 1.2459 + by assuming that all the world is maildir.</p> 1.2460 + 1.2461 + <p>We can't do a better job than the maildir fan community has done 1.2462 + with their maildir drivers. Similarly, if the maildir fan community 1.2463 + provides the maildir driver, they take on the responsibility for 1.2464 + answering maildir-specific support questions. This is as it should be, 1.2465 + and that is why maildir support is left to the maildir fan 1.2466 + community.</p> 1.2467 + </dd> 1.2468 + </dl> 1.2469 + 1.2470 + <p><a href="#top">Back to top</a></p> 1.2471 + <hr> 1.2472 + 1.2473 + <p><a name="6.10"><strong>6.10 Why don't you support the Cyrus 1.2474 + format?</strong></a></p> 1.2475 + 1.2476 + <dl> 1.2477 + <dd> 1.2478 + There's no point to doing so. An implementation which supports multiple 1.2479 + formats will never do as well as one which is optimized to support one 1.2480 + single format. 1.2481 + 1.2482 + <p>If you want to use Cyrus mailbox format, you should use the Cyrus 1.2483 + server, which is the native implementation of that format and is 1.2484 + specifically optimized for that format. That's also why Cyrus doesn't 1.2485 + implement any other format.</p> 1.2486 + </dd> 1.2487 + </dl> 1.2488 + 1.2489 + <p><a href="#top">Back to top</a></p> 1.2490 + <hr> 1.2491 + 1.2492 + <p><a name="6.11"><strong>6.11 Why is it creating extra forks on my SVR4 1.2493 + system?</strong></a></p> 1.2494 + 1.2495 + <dl> 1.2496 + <dd> 1.2497 + This is because your system only has fcntl() style locking and not 1.2498 + flock() style locking. fcntl() locking has a design flaw that causes a 1.2499 + close() to release any locks made by that process on the file opened on 1.2500 + that file descriptor, even if the lock was made on a different file 1.2501 + descriptor. 1.2502 + 1.2503 + <p>This design flaw causes unexpected loss of lock, and consequent 1.2504 + mailbox corruption. The workaround is to do certain "dangerous 1.2505 + operations" in another fork, thus avoiding doing a close() in the 1.2506 + vulnerable fork.</p> 1.2507 + 1.2508 + <p>The best way to solve this problem is to upgrade your SVR4 (Solaris, 1.2509 + AIX, HP-UX, SGI) or OSF/1 system to a more advanced operating system, 1.2510 + such as Linux or BSD. These more advanced operating systems have 1.2511 + fcntl() locking for compatibility with SVR4, but also have flock() 1.2512 + locking.</p> 1.2513 + 1.2514 + <p>Beware of certain SVR4 systems, such as AIX, which have an "flock()" 1.2515 + function in their C library that is just a jacket that does an fcntl() 1.2516 + lock. This is not a true flock(), and has the same design flaw as 1.2517 + fcntl().</p> 1.2518 + </dd> 1.2519 + </dl> 1.2520 + 1.2521 + <p><a href="#top">Back to top</a></p> 1.2522 + <hr> 1.2523 + 1.2524 + <p><a name="6.12"><strong>6.12 Why are you so fussy about the date/time format in 1.2525 + the internal <code>"From "</code> line in traditional UNIX mailbox 1.2526 + files? My other mail program just considers every line that starts with 1.2527 + <code>"From "</code> to be the start of the message.</strong></a></p> 1.2528 + 1.2529 + <dl> 1.2530 + <dd> 1.2531 + You just answered your own question. If any line that starts with 1.2532 + <code>"From "</code> is treated as the start of a message, then 1.2533 + every message text line which starts with <code>"From "</code> has 1.2534 + to be quoted (typically by prefixing a ">" character). People 1.2535 + complain about this -- "why did a > get stuck in my message?" 1.2536 + 1.2537 + <p>So, good mail reading software only considers a line to be a 1.2538 + <code>"From "</code> line if it follows the actual specification 1.2539 + for a "From " line. This means, among other things, that the day of 1.2540 + week is fixed-format: <code>"May 14"</code>, but 1.2541 + <code>"May 7"</code> (note the extra space) as opposed to 1.2542 + <code>"May 7"</code>. ctime() format for the date is the most 1.2543 + common, although POSIX also allows a numeric timezone after the 1.2544 + year. For compatibility with ancient software, the seconds are optional, 1.2545 + the timezone may appear before the year, the old 3-letter timezones are 1.2546 + also permitted, and "remote from xxx" may appear after the whole 1.2547 + thing.</p> 1.2548 + 1.2549 + <p>Unfortunately, some software written by novices use other formats. 1.2550 + The most common error is to have a variable-width day of month, perhaps 1.2551 + in the erroneous belief that RFC 2822 (or RFC 822) defines the format of 1.2552 + the date/time in the <code>"From "</code> line (it doesn't; no RFC 1.2553 + describes internal formats). I've seen a few other goofs, such as a 1.2554 + single-digit second, but these are less common.</p> 1.2555 + 1.2556 + <p>If you are writing your own software that writes mailbox files, and 1.2557 + you really aren't all that savvy with all the ins and outs and ancient 1.2558 + history, you should seriously consider using the c-client library (e.g. 1.2559 + routine mail_append()) instead of doing the file writes yourself. If 1.2560 + you must do it yourself, use ctime(), as in:</p> 1.2561 + <pre> 1.2562 + fprintf (mbx,"From %s@%h %s",user,host,ctime (time (0))); 1.2563 +</pre>rather than try to figure out a good format yourself. ctime() is the 1.2564 +most traditional format and nobody will flame you for using it. 1.2565 + </dd> 1.2566 + </dl> 1.2567 + 1.2568 + <p><a href="#top">Back to top</a></p> 1.2569 + <hr> 1.2570 + 1.2571 + <p><a name="6.13"><strong>6.13 Why is traditional UNIX format the default 1.2572 + format?</strong></a></p> 1.2573 + 1.2574 + <dl> 1.2575 + <dd>Compatibility with the past 30 or so years of UNIX history. This 1.2576 + server is the only one that completely interoperates with legacy UNIX 1.2577 + mail tools.</dd> 1.2578 + </dl> 1.2579 + 1.2580 + <p><a href="#top">Back to top</a></p> 1.2581 + <hr> 1.2582 + 1.2583 + <p><a name="6.14"><strong>6.14 Why do you write this "DON'T DELETE THIS MESSAGE 1.2584 + -- FOLDER INTERNAL DATA" message at the start of traditional UNIX and 1.2585 + MMDF format mailboxes?</strong></a></p> 1.2586 + 1.2587 + <dl> 1.2588 + <dd> 1.2589 + This pseudo-message serves two purposes. 1.2590 + 1.2591 + <p>First, it establishes the mailbox format even when the mailbox has 1.2592 + no messages. Otherwise, a mailbox with no messages is a zero-byte file, 1.2593 + which could be one of several formats.</p> 1.2594 + 1.2595 + <p>Second, it holds mailbox metadata used by IMAP: the UID validity, 1.2596 + the last assigned UID, and mailbox keywords. Without this metadata, 1.2597 + which must be preserved even when the mailbox has no messages, the 1.2598 + traditional UNIX format wouldn't be able to support the full 1.2599 + capabilities of IMAP.</p> 1.2600 + </dd> 1.2601 + </dl> 1.2602 + 1.2603 + <p><a href="#top">Back to top</a></p> 1.2604 + <hr> 1.2605 + 1.2606 + <p><a name="6.15"><strong>6.15 Why don't you stash the mailbox metadata in the 1.2607 + first real message of the mailbox instead of writing this fake FOLDER 1.2608 + INTERNAL DATA message?</strong></a></p> 1.2609 + 1.2610 + <dl> 1.2611 + <dd> 1.2612 + In fact, that is what is done if the mailbox is non-empty and does not 1.2613 + already have a FOLDER INTERNAL DATA message. 1.2614 + 1.2615 + <p>One problem with doing that is that if some external program removes 1.2616 + the first message, the metadata is lost and must be recreated, thus 1.2617 + losing any prior UID or keyword list status that IMAP clients may 1.2618 + depend upon.</p> 1.2619 + 1.2620 + <p>Another problem is that this doesn't help if the last message is 1.2621 + deleted. This will result in an empty mailbox, and the necessity to 1.2622 + create a FOLDER INTERNAL DATA message.</p> 1.2623 + </dd> 1.2624 + </dl> 1.2625 + 1.2626 + <p><a href="#top">Back to top</a></p> 1.2627 + <hr> 1.2628 + 1.2629 + <p><a name="6.16"><strong>6.16 Why aren't "dual-use" mailboxes the 1.2630 + default?</strong></a></p> 1.2631 + 1.2632 + <dl> 1.2633 + <dd>Compatibility with the past 30 or so years of UNIX history, not to 1.2634 + mention compatibility with user expectations when using shell tools.</dd> 1.2635 + </dl> 1.2636 + 1.2637 + <p><a href="#top">Back to top</a></p> 1.2638 + <hr> 1.2639 + 1.2640 + <p><a name="6.17"><strong>6.17 Why do you use ucbcc to build on 1.2641 + Solaris?</strong></a></p> 1.2642 + 1.2643 + <dl> 1.2644 + <dd> 1.2645 + It is a long, long story about why cc is set to ucbcc. You need to 1.2646 + invoke the C compiler so that it links with the SVR4 libraries and not 1.2647 + the BSD libraries, otherwise readdir() will return the wrong 1.2648 + information. 1.2649 + 1.2650 + <p>Of all the names in the most common path, ucbcc is the only name to 1.2651 + be found (on /usr/ccs/bin) that points to a suitable compiler. cc is 1.2652 + likely to be /usr/ucb/cc which is absolutely not the compiler that you 1.2653 + want. The real SVR4 cc is probably something like /opt/SUNWspro/bin/cc 1.2654 + which is rarely in anyone's path by default.</p> 1.2655 + 1.2656 + <p>ucbcc is probably a link to acc, e.g. /opt/SUNWspro/SC4.0/bin/acc, 1.2657 + and is the UCB C compiler using the SVR4 libraries.</p> 1.2658 + 1.2659 + <p>If ucbcc isn't on your system, then punt on the SUN C compiler and 1.2660 + use gcc instead (the gso port instead of the sol port).</p> 1.2661 + 1.2662 + <p>If, in spite of all the above warnings, you choose to change "ucbcc" 1.2663 + to "cc", you will probably find that the -O2 needs to be changed to -O. 1.2664 + If you don't get any error messages with -O2, that's a pretty good 1.2665 + indicator that you goofed and are running the compiler that will link 1.2666 + with the BSD libraries.</p> 1.2667 + 1.2668 + <p>To recap:</p> 1.2669 + 1.2670 + <ul> 1.2671 + <li>The sol port is designed to be built using the UCB compiler using 1.2672 + the SVR4 libraries. This compiler is "ucbcc", which is lunk to acc. 1.2673 + You use -O2 as one of the CFLAGS.</li> 1.2674 + 1.2675 + <li>If you build the sol port with the UCB compiler using the BSD 1.2676 + libraries, you will get no error messages but you will get bad 1.2677 + binaries (the most obvious symptom is dropping the first two 1.2678 + characters return filenames from the imapd LIST command. This 1.2679 + compiler also uses -O2, and is very often what the user gets from 1.2680 + "cc". <strong>BEWARE</strong></li> 1.2681 + 1.2682 + <li>If you build the sol port with the real SVR4 compiler, which is 1.2683 + often hidden away or unavailable on many systems, then you will get 1.2684 + errors from -O2 and you need to change that to -O. But you will get a 1.2685 + good binary. However, you should try it with -O2 first, to make sure 1.2686 + that you got this compiler and not the UCB compiler using BSD 1.2687 + libraries.</li> 1.2688 + </ul> 1.2689 + </dd> 1.2690 + </dl> 1.2691 + 1.2692 + <p><a href="#top">Back to top</a></p> 1.2693 + <hr> 1.2694 + 1.2695 + <p><a name="6.18"><strong>6.18 Why should I care about some old system with BSD 1.2696 + libraries? cc is the right thing on my Solaris system!</strong></a></p> 1.2697 + 1.2698 + <dl> 1.2699 + <dd> 1.2700 + Because there still are sites that use such systems. On those systems, 1.2701 + the assumption that "cc" does the right thing will lead to corrupt 1.2702 + binaries with no error message or other warning that anything is amiss. 1.2703 + 1.2704 + <p>Too many sites have fallen victim to this problem.</p> 1.2705 + </dd> 1.2706 + </dl> 1.2707 + 1.2708 + <p><a href="#top">Back to top</a></p> 1.2709 + <hr> 1.2710 + 1.2711 + <p><a name="6.19"><strong>6.19 Why do you insist upon writing .lock files in the 1.2712 + spool directory?</strong></a></p> 1.2713 + 1.2714 + <dl> 1.2715 + <dd>Compatibility with the past 30 years of UNIX software which deals 1.2716 + with the spool directory, especially software which delivers mail. 1.2717 + Otherwise, it is possible to lose mail.</dd> 1.2718 + </dl> 1.2719 + 1.2720 + <p><a href="#top">Back to top</a></p> 1.2721 + <hr> 1.2722 + 1.2723 + <p><a name="6.20"><strong>6.20 Why should I care about compatibility with the 1.2724 + past?</strong></a></p> 1.2725 + 1.2726 + <dl> 1.2727 + <dd>This is one of those questions in which the answer never convinces 1.2728 + those who ask it. Somehow, everybody who ever asks this question ends up 1.2729 + answering it for themselves as they get older, with the very answer that 1.2730 + they rejected years earlier.</dd> 1.2731 + </dl> 1.2732 + 1.2733 + <p><a href="#top">Back to top</a></p> 1.2734 + <hr> 1.2735 + 1.2736 + <p><br></p> 1.2737 + 1.2738 + <h2><a name="problems">7. Problems and Annoyances</a></h2> 1.2739 + <hr> 1.2740 + 1.2741 + <p><a name="7.1"><strong>7.1 Help! My INBOX is empty! What happened to my 1.2742 + messages?</strong></a></p> 1.2743 + 1.2744 + <dl> 1.2745 + <dd> 1.2746 + If you are seeing "0 messages" when you open INBOX and you know you 1.2747 + have messages there (and perhaps have looked at your mail spool file 1.2748 + and see that messages are there), then probably there is something 1.2749 + wrong with the very first line of your mail spool file. Make sure that 1.2750 + the first five bytes of the file are "From ", followed by an email 1.2751 + address and a date/time in ctime() format, e.g.: 1.2752 + <pre> 1.2753 + From fred@foo.bar Mon May 7 20:54:30 2001 1.2754 +</pre> 1.2755 + </dd> 1.2756 + </dl> 1.2757 + 1.2758 + <p><a href="#top">Back to top</a></p> 1.2759 + <hr> 1.2760 + 1.2761 + <p><a name="7.2"><strong>7.2 Help! All my messages in a non-INBOX mailbox have 1.2762 + been concatenated into one message which claims to be from me and has a 1.2763 + subject of the file name of the mailbox! What's going 1.2764 + on?</strong></a></p> 1.2765 + 1.2766 + <dl> 1.2767 + <dd> 1.2768 + Something wrong with the very first line of the mailbox. Make sure that 1.2769 + the first five bytes of the file are "From ", followed by an email 1.2770 + address and a date/time in ctime() format, e.g.: 1.2771 + <pre> 1.2772 + From fred@foo.bar Mon May 7 20:54:30 2001 1.2773 +</pre> 1.2774 + </dd> 1.2775 + </dl> 1.2776 + 1.2777 + <p><a href="#top">Back to top</a></p> 1.2778 + <hr> 1.2779 + 1.2780 + <p><a name="7.3"><strong>7.3 Why do I get the message:</strong> <tt>CREATE 1.2781 + failed: Can't create mailbox node xxxxxxxxx: File exists</tt> 1.2782 + <strong>and how do I fix it?</strong></a></p> 1.2783 + 1.2784 + <dl> 1.2785 + <dd>See the answer to the <a href="#1.8">Are hierarchical mailboxes 1.2786 + supported?</a> question.</dd> 1.2787 + </dl> 1.2788 + 1.2789 + <p><a href="#top">Back to top</a></p> 1.2790 + <hr> 1.2791 + 1.2792 + <p><a name="7.4"><strong>7.4 Why can't I log in to the server? The user name and 1.2793 + password are right!</strong></a></p> 1.2794 + 1.2795 + <dl> 1.2796 + <dd> 1.2797 + There are a myriad number of possible answers to this question. The 1.2798 + only way to say for sure what is wrong is run the server under a 1.2799 + debugger such as gdb while root (yes, you must be root) with a 1.2800 + breakpoint at routines checkpw() and loginpw(), then single-step until 1.2801 + you see which test rejected you. The server isn't going to give any 1.2802 + error messages other than "login failed" in the name of not giving out 1.2803 + any unnecessary information to unauthorized individuals. 1.2804 + 1.2805 + <p>Here are some of the more common reasons why login may fail:</p> 1.2806 + 1.2807 + <ul> 1.2808 + <li>You didn't really give the correct user name and/or 1.2809 + password.</li> 1.2810 + 1.2811 + <li>Your client doesn't send the LOGIN command correctly; for 1.2812 + example, IMAP2 clients won't send a password containing a "*" 1.2813 + correctly to an IMAP4 server.</li> 1.2814 + 1.2815 + <li>If you have set up a CRAM-MD5 database, remember that the 1.2816 + password used is the one in the CRAM-MD5 database, and furthermore 1.2817 + that there must also be an entry in /etc/passwd (but the /etc/passwd 1.2818 + password is not used).</li> 1.2819 + 1.2820 + <li>If you are using PAM, have you created a service file for the 1.2821 + server in /etc/pam.d?</li> 1.2822 + 1.2823 + <li>If you are using shadow passwords, have you used an appropriate 1.2824 + port when building? In particular, note that "lnx" is for Linux 1.2825 + systems without shadow passwords; you probably want "slx" or "lnp" 1.2826 + instead.</li> 1.2827 + 1.2828 + <li>If your system has account or password expirations, check to see 1.2829 + that the expiration date hasn't passed.</li> 1.2830 + 1.2831 + <li>You can't log in as root or any other UID 0 user. This is for 1.2832 + your own safety, not to mention the fact that the servers use UID 0 1.2833 + as meaning "not logged in".</li> 1.2834 + </ul> 1.2835 + </dd> 1.2836 + </dl> 1.2837 + 1.2838 + <p><a href="#top">Back to top</a></p> 1.2839 + <hr> 1.2840 + 1.2841 + <p><a name="7.5"><strong>7.5 Help! My load average is soaring and I see hundreds 1.2842 + of POP and IMAP servers, many logged in as the same 1.2843 + user!</strong></a></p> 1.2844 + 1.2845 + <dl> 1.2846 + <dd> 1.2847 + Certain inferior losing GUI mail reading programs have a "synchronize 1.2848 + all mailboxes at startup" (IMAP) or "check for new mail every second" 1.2849 + (POP) feature which causes a rapid and unchecked spawning of servers. 1.2850 + 1.2851 + <p>This is not a problem in the server; the client is really asking for 1.2852 + all those server sessions. Unfortunately, there isn't much that the POP 1.2853 + and IMAP servers can do about it; they don't spawned themselves.</p> 1.2854 + 1.2855 + <p>Some sites have added code to record the number of server sessions 1.2856 + spawned per user per hour, and disable login for a user who has 1.2857 + exceeded a predetermined rate. This doesn't stop the servers from being 1.2858 + spawned; it just means that a server session will commit suicide a bit 1.2859 + faster.</p> 1.2860 + 1.2861 + <p>Another possibility is to detect excessive server spawning activity 1.2862 + at the level where the server is spawned, which would be inetd or 1.2863 + possibly tcpd. The problem here is that this is a hard time to 1.2864 + quantify. 50 sessions in a minute from a multi-user timesharing system 1.2865 + may be perfectly alright, whereas 10 sessions a minute from a PC may be 1.2866 + too much.</p> 1.2867 + 1.2868 + <p>The real solution is to fix the client configuration, by disabling 1.2869 + those evil features. Also tell the vendors of those clients how you 1.2870 + feel about distributing denial-of-service attack tools in the guise of 1.2871 + mail reading programs.</p> 1.2872 + </dd> 1.2873 + </dl> 1.2874 + 1.2875 + <p><a href="#top">Back to top</a></p> 1.2876 + <hr> 1.2877 + 1.2878 + <p><a name="7.6"><strong>7.6 Why does mail disappear even though I set "keep 1.2879 + mail on server"?</strong></a><br> 1.2880 + <a name="7.7"><strong>7.7 Why do I get the message</strong> <tt>Moved ##### 1.2881 + bytes of new mail to /home/user/mbox from /var/spool/mail/user</tt> 1.2882 + <strong>and why did this happen?</strong></a></p> 1.2883 + 1.2884 + <dl> 1.2885 + <dd> 1.2886 + This is probably caused by the mbox driver. If the file "mbox" exists 1.2887 + on the user's home directory and is in UNIX mailbox format, then when 1.2888 + INBOX is opened this file will be selected as INBOX instead of the mail 1.2889 + spool file. Messages will be automatically transferred from the mail 1.2890 + spool file into the mbox file. 1.2891 + 1.2892 + <p>To disable this behavior, delete "mbox" from the EXTRADRIVERS list 1.2893 + in the top-level Makefile and rebuild. Note that if you do this, users 1.2894 + won't be able to access the messages that have already been moved to 1.2895 + mbox unless they open mbox instead of INBOX.</p> 1.2896 + </dd> 1.2897 + </dl> 1.2898 + 1.2899 + <p><a href="#top">Back to top</a></p> 1.2900 + <hr> 1.2901 + 1.2902 + <p><a name="7.8"><strong>7.8 Why isn't it showing the local host name as a 1.2903 + fully-qualified domain name?</strong></a><br> 1.2904 + <a name="7.9"><strong>7.9 Why is the local host name in the 1.2905 + From/Sender/Message-ID headers of outgoing mail not coming out as a 1.2906 + fully-qualified domain name?</strong></a></p> 1.2907 + 1.2908 + <dl> 1.2909 + <dd> 1.2910 + Your UNIX system is misconfigured. The entry for your system in 1.2911 + /etc/hosts must have the fully-qualified domain name first, e.g. 1.2912 + <pre> 1.2913 + 105.69.1.234 myserver.example.com myserver 1.2914 +</pre> 1.2915 + 1.2916 + <p>A common mistake of novice system administrators is to have the 1.2917 + short name first, e.g.</p> 1.2918 + <pre> 1.2919 + 105.69.1.234 myserver myserver.example.com 1.2920 + 1.2921 +</pre> 1.2922 + 1.2923 + <p>or to omit the fully qualified domain name entirely, e.g.</p> 1.2924 + <pre> 1.2925 + 105.69.1.234 myserver 1.2926 +</pre> 1.2927 + 1.2928 + <p>The result of this is that when the IMAP toolkit does a 1.2929 + gethostbyname() call to get the fully-qualified domain name, it would 1.2930 + get "myserver" instead of "myserver.example.com".</p> 1.2931 + 1.2932 + <p>On some systems, a configuration file (typically named 1.2933 + /etc/svc.conf, /etc/netsvc.conf, or /etc/nsswitch.conf) can be used to 1.2934 + configure the system to use the domain name system (DNS) instead of 1.2935 + /etc/hosts, so it doesn't matter if /etc/hosts is misconfigured.</p> 1.2936 + 1.2937 + <p>Check the man pages for gethostbyname, hosts, svc, and/or netsvc for 1.2938 + more information.</p> 1.2939 + 1.2940 + <p>Unfortunately, certain vendors, most notably SUN, have failed to 1.2941 + make this clear in their documentation. Most of SUN's documentation 1.2942 + assumes a corporate network that is not connected to the Internet.</p> 1.2943 + 1.2944 + <p>net.folklore once (late 1980s) held that the proper procedure was to 1.2945 + append the results of getdomainname() to the name returned by 1.2946 + gethostname(), and some versions of sendmail configuration files were 1.2947 + distributed that did this. This was incorrect; the string returned from 1.2948 + getdomainname() is the Yellow Pages (a.k.a NIS) domain name, which is a 1.2949 + completely different (albeit unfortunately named) entity from an 1.2950 + Internet domain. These were often fortuitously the same string, except 1.2951 + when they weren't. Frequently, this would result in host names with 1.2952 + spuriously doubled domain names, e.g.</p> 1.2953 + <pre> 1.2954 + myserver.example.com.example.com 1.2955 + 1.2956 +</pre> 1.2957 + 1.2958 + <p>This practice has been thoroughly discredited for many years, but 1.2959 + folklore dies hard.</p> 1.2960 + </dd> 1.2961 + </dl> 1.2962 + 1.2963 + <p><a href="#top">Back to top</a></p> 1.2964 + <hr> 1.2965 + 1.2966 + <p><a name="7.10"><strong>7.10 What does the message:</strong> <tt>Mailbox 1.2967 + vulnerable - directory /var/spool/mail must have 1777 protection</tt> 1.2968 + <strong>mean? How can I fix this?</strong></a></p> 1.2969 + 1.2970 + <dl> 1.2971 + <dd> 1.2972 + In order to update a mailbox in the default UNIX format, it is 1.2973 + necessary to create a lock file to prevent the mailer from delivering 1.2974 + mail while an update is in progress. Some systems use a directory 1.2975 + protection of 775, requiring that all mail handling programs be setgid 1.2976 + mail; or of 755, requiring that all mail handling programs be setuid 1.2977 + root. 1.2978 + 1.2979 + <p>The IMAP toolkit does not run with any special privileges, and I 1.2980 + plan to keep it that way. It is antithetical to the concept of a 1.2981 + toolkit if users can't write their own programs to use it. Also, I've 1.2982 + had enough bad experiences with security bugs while running privileged; 1.2983 + the IMAP and POP servers have to be root when not logged in, in order 1.2984 + to be able to log themselves in. I don't want to go any deeper down 1.2985 + that slippery slope.</p> 1.2986 + 1.2987 + <p>Directory protection 1777 is secure enough on most well-managed 1.2988 + systems. If you can't trust your users with a 1777 mail spool (petty 1.2989 + harassment is about the limit of the abuse exposure), then you have 1.2990 + much worse problems then that.</p> 1.2991 + 1.2992 + <p>If you absolutely insist upon requiring privileges to create a lock 1.2993 + file, external file locking can be done via a setgid mail program named 1.2994 + /etc/mlock (this is defined by LOCKPGM in the c-client Makefile). If 1.2995 + the toolkit is unable to create a <...mailbox...>.lock file in 1.2996 + the directory by itself, it will try to call mlock to do it. I do not 1.2997 + recommend doing this for performance reasons.</p> 1.2998 + 1.2999 + <p>A sample mlock program is included as part of imap-2007. We have 1.3000 + tried to make this sample program secure, but it has not been 1.3001 + thoroughly audited.</p> 1.3002 + </dd> 1.3003 + </dl> 1.3004 + 1.3005 + <p><a href="#top">Back to top</a></p> 1.3006 + <hr> 1.3007 + 1.3008 + <p><a name="7.11"><strong>7.11 What does the message:</strong> <tt>Mailbox is 1.3009 + open by another process, access is readonly</tt> <strong>mean? How do I 1.3010 + fix this?</strong></a></p> 1.3011 + 1.3012 + <dl> 1.3013 + <dd> 1.3014 + A problem occurred in applying a lock to a /tmp lock file. Either some 1.3015 + other program has the mailbox open and won't relenquish it, or 1.3016 + something is wrong with the protection of /tmp or the lock. 1.3017 + 1.3018 + <p>Make sure that the /tmp directory is protected 1777. Some security 1.3019 + scripts incorrectly set the protection of the /tmp directory to 775, 1.3020 + which disables /tmp for all non-privileged programs.</p> 1.3021 + </dd> 1.3022 + </dl> 1.3023 + 1.3024 + <p><a href="#top">Back to top</a></p> 1.3025 + <hr> 1.3026 + 1.3027 + <p><a name="7.12"><strong>7.12 What does the message:</strong> <tt>Can't get 1.3028 + write access to mailbox, access is readonly</tt> 1.3029 + <strong>mean?</strong></a></p> 1.3030 + 1.3031 + <dl> 1.3032 + <dd>The mailbox file is write-protected against you.</dd> 1.3033 + </dl> 1.3034 + 1.3035 + <p><a href="#top">Back to top</a></p> 1.3036 + <hr> 1.3037 + 1.3038 + <p><a name="7.13"><strong>7.13 I set my POP3 client to "delete messages from 1.3039 + server" but they never get deleted. What is wrong?</strong></a></p> 1.3040 + 1.3041 + <dl> 1.3042 + <dd> 1.3043 + Make sure that your mailbox is not read-only: that the mailbox is owned 1.3044 + by you and write enabled (protection 0600), and that the /tmp directory 1.3045 + is longer world-writeable. /tmp must be world-writeable because lots of 1.3046 + applications use it for scratch space. To fix this, do 1.3047 + <pre> 1.3048 + 1.3049 + chmod 1777 /tmp 1.3050 +</pre>as root. 1.3051 + 1.3052 + <p>Make sure that your POP3 client issues a QUIT command when it 1.3053 + finishes. The POP3 protocol specifies that deletions are discarded 1.3054 + unless a proper QUIT is done.</p> 1.3055 + 1.3056 + <p>Make sure that you are not opening multiple POP3 sessions to the 1.3057 + same mailbox. It is a requirement of the POP3 protocol than only one 1.3058 + POP3 session be in effect to a mailbox at a time, however some, 1.3059 + poorly-written POP3 clients violate this. Also, some background "check 1.3060 + for new mail" tasks also cause a violation. See the answer to the 1.3061 + <a href="#7.19">What does the syslog message: Killed (lost mailbox 1.3062 + lock) user=... host=... mean?</a> question for more details.</p> 1.3063 + </dd> 1.3064 + </dl> 1.3065 + 1.3066 + <p><a href="#top">Back to top</a></p> 1.3067 + <hr> 1.3068 + 1.3069 + <p><a name="7.14"><strong>7.14 What do messages such as:</strong></a></p> 1.3070 + <pre> 1.3071 + Message ... UID ... already has UID ... 1.3072 + Message ... UID ... less than ... 1.3073 + Message ... UID ... greater than last ... 1.3074 + Invalid UID ... in message ..., rebuilding UIDs 1.3075 +</pre> 1.3076 + 1.3077 + <p><strong>mean?</strong></p> 1.3078 + 1.3079 + <dl> 1.3080 + <dd> 1.3081 + Something happened to corrupt the unique identifier regime in the 1.3082 + mailbox. In traditional UNIX-format mailboxes, this can happen if the 1.3083 + user deleted the "DO NOT DELETE" internal message. 1.3084 + 1.3085 + <p>This problem is relatively harmless; a new valid unique identifier 1.3086 + regime will be created. The main effect is that any references to the 1.3087 + old UIDs will no longer be useful.</p> 1.3088 + 1.3089 + <p>So, unless it is a chronic problem or you feel like debugging, you 1.3090 + can safely ignore these messages.</p> 1.3091 + </dd> 1.3092 + </dl> 1.3093 + 1.3094 + <p><a href="#top">Back to top</a></p> 1.3095 + <hr> 1.3096 + 1.3097 + <p><a name="7.15"><strong>7.15 What do the error messages:</strong></a></p> 1.3098 + <pre> 1.3099 + Unable to read internal header at ... 1.3100 + Unable to find CRLF at ... 1.3101 + Unable to parse internal header at ... 1.3102 + Unable to parse message date at ... 1.3103 + Unable to parse message flags at ... 1.3104 + Unable to parse message UID at ... 1.3105 + Unable to parse message size at ... 1.3106 + Last message (at ... ) runs past end of file ... 1.3107 +</pre> 1.3108 + 1.3109 + <p><strong>mean? I am using mbx format.</strong></p> 1.3110 + 1.3111 + <dl> 1.3112 + <dd> 1.3113 + The mbx-format mailbox is corrupted and needs to be repaired. 1.3114 + 1.3115 + <p>You should make an effort to find out why the corruption happened. 1.3116 + Was there an obvious system problem (crash or disk failure)? Did the 1.3117 + user accidentally access the file via NFS? Mailboxes don't get 1.3118 + corrupted by themselves; something caused the problem.</p> 1.3119 + 1.3120 + <p>Some people have developed automated scripts, but if you're 1.3121 + comfortable using emacs it's pretty easy to fix it manually. Do 1.3122 + <em>not</em> use vi or any other editor unless you are certain that 1.3123 + editor can handle binary!!!</p> 1.3124 + 1.3125 + <p>If you are not comfortable with emacs, or if the file is too large 1.3126 + to read with emacs, see the "step-by-step" technique later on for 1.3127 + another way of doing it.</p> 1.3128 + 1.3129 + <p>After the word "at" in the error message is the byte position it got 1.3130 + to when it got unhappy with the file, e.g. if you see:</p> 1.3131 + <pre> 1.3132 + Unable to parse internal header at 43921: ne bombastic blurdybloop 1.3133 +</pre>The problem occurs at the 43,931 byte in the file. That's the point you 1.3134 +need to fix. c-client is expecting an internal header at that byte number, 1.3135 +looking something like: 1.3136 + <pre> 1.3137 + 6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001 1.3138 +</pre>The format of this internal line is: 1.3139 + <pre> 1.3140 + dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU 1.3141 +</pre>The only thing that is variable is the "ssss" field, it can be as many 1.3142 +digits as needed. All other fields (inluding the "dd") are fixed width. So, 1.3143 +the easiest thing to do is to look forward in the file for the next internal 1.3144 +header, and delete everything from the error point to that internal header. 1.3145 + 1.3146 + <p>Here's what to do if you want to be smarter and do a little bit more 1.3147 + work. Generally, you're in the middle of a message, and there's nothing 1.3148 + wrong with that message. The problem happened in the *previous* 1.3149 + message. So, search back to the previous internal header. Now, remember 1.3150 + that "ssss" field? That's the size of that message.</p> 1.3151 + 1.3152 + <p>Mark where you are in the file, move the cursor to the line after 1.3153 + the internal header, and skip that many bytes ("ssss") forward. If 1.3154 + you're at the point of the error in the file, then that message is 1.3155 + corrupt. If you're at a different point, then perhaps the previous 1.3156 + message is corrupt and has a too long size count that "ate" into this 1.3157 + message.</p> 1.3158 + 1.3159 + <p>Basically, what you need to do is make sure that all those size 1.3160 + counts are right, and that moving "ssss" bytes from the line after the 1.3161 + internal header will land you at another internal header.</p> 1.3162 + 1.3163 + <p>Usually, once you know what you're looking at, it's pretty easy to 1.3164 + work out the corruption, and the best remedial action. Repair scripts 1.3165 + will make the problem go away but may not always do the smartest/best 1.3166 + salvage of the user's data. Manual repair is more flexible and usually 1.3167 + preferable.</p> 1.3168 + 1.3169 + <p>Here is a step-by-step technique for fixing corrupt mbx files that's 1.3170 + a bit cruder than the procedure outlined above, but works for any size 1.3171 + file.</p> 1.3172 + 1.3173 + <p>In this example, suppose that the corrupt file is INBOX, the error 1.3174 + message is</p> 1.3175 + <pre> 1.3176 + Unable to find CRLF at 132551754 1.3177 +</pre>and the size of the INBOX file is 132867870 bytes. 1.3178 + 1.3179 + <p>The first step is to split the mailbox file at the point of the 1.3180 + error:</p> 1.3181 + 1.3182 + <ul> 1.3183 + <li>Rename the INBOX file to some other name, such as INBOX.bad.</li> 1.3184 + 1.3185 + <li>Copy the first 132,551,754 bytes of INBOX.bad to another file, 1.3186 + such as INBOX.new.</li> 1.3187 + 1.3188 + <li>Extract the trailing 316,116 bytes (132867870-132551754) of 1.3189 + INBOX.bad into another file, such as INBOX.tail.</li> 1.3190 + 1.3191 + <li>You no longer need INBOX.bad. Delete it.</li> 1.3192 + </ul>In other words, use the number from the "Unable to find CRLF at" 1.3193 + as the point to split INBOX into two new files, INBOX.new and 1.3194 + INBOX.tail. 1.3195 + 1.3196 + <p>Now, remove the erroneous data:</p> 1.3197 + 1.3198 + <ul> 1.3199 + <li>Verify that you can open INBOX.new in IMAP or Pine.</li> 1.3200 + 1.3201 + <li>The last message of INBOX.new is probably corrupted. Copy it to 1.3202 + another file, such as badmsg.1, then delete and expunge that last 1.3203 + message from INBOX.new</li> 1.3204 + 1.3205 + <li>Locate the first occurance of text in INBOX.tail which looks like 1.3206 + an internal header, as described above.</li> 1.3207 + 1.3208 + <li>Remove all the text which occurs prior to that point, and place 1.3209 + it into another file, such as badmsg.2. Note that in the case of a 1.3210 + single digit date, there is a leading space which must not be removed 1.3211 + (e.g. " 6-Nov-2001" not "6-Nov-2001").</li> 1.3212 + </ul> 1.3213 + 1.3214 + <p>Reassemble the mailbox:</p> 1.3215 + 1.3216 + <ul> 1.3217 + <li>Append INBOX.tail to INBOX.new.</li> 1.3218 + 1.3219 + <li>You no longer need INBOX.tail. Delete it.</li> 1.3220 + 1.3221 + <li>Verify that you can open INBOX.new in IMAP or Pine.</li> 1.3222 + </ul> 1.3223 + 1.3224 + <p>Reinstall INBOX.new as INBOX:</p> 1.3225 + 1.3226 + <ul> 1.3227 + <li>Check to see if you have received any new messages while 1.3228 + repairing INBOX.</li> 1.3229 + 1.3230 + <li>If you haven't received any new messages while repairing INBOX, 1.3231 + just rename INBOX.new to INBOX.</li> 1.3232 + 1.3233 + <li>If you have received new messages, be sure to copy the new 1.3234 + messages from INBOX to INBOX.new before doing the rename.</li> 1.3235 + </ul> 1.3236 + 1.3237 + <p>You now have a working INBOX, as well as two files with corrupted 1.3238 + data (badmsg.1 and badmsg.2). There may be some useful data in the two 1.3239 + badmsg files that you might want to try salvaging; otherwise you can 1.3240 + delete the two badmsg files.</p> 1.3241 + </dd> 1.3242 + </dl> 1.3243 + 1.3244 + <p><a href="#top">Back to top</a></p> 1.3245 + <hr> 1.3246 + 1.3247 + <p><a name="7.16"><strong>7.16 What do the syslog messages:</strong></a></p> 1.3248 + <pre> 1.3249 + 1.3250 + imap/tcp server failing (looping) 1.3251 + pop3/tcp server failing (looping) 1.3252 +</pre> 1.3253 + 1.3254 + <p><strong>mean? When it happens, the listed service shuts down. How can I 1.3255 + fix this?</strong></p> 1.3256 + 1.3257 + <dl> 1.3258 + <dd> 1.3259 + The error message "server failing (looping), service terminated" is not 1.3260 + from either the IMAP or POP servers. Instead, it comes from inetd, the 1.3261 + daemon which listens for TCP connections to a number of servers, 1.3262 + including the IMAP and POP servers. 1.3263 + 1.3264 + <p>inetd has a limit of 40 new server sessions per minute for any 1.3265 + particular service. If more than 40 sessions are initiated in a minute, 1.3266 + inetd will issue the "failing (looping), service terminated" message 1.3267 + and shut down the service for 10 minutes. inetd does this to prevent 1.3268 + system resource consumption by a client which is spawning infinite 1.3269 + numbers of servers. It should be noted that this is a denial of 1.3270 + service; however for some systems the alternative is a crash which 1.3271 + would be a worse denial of service!</p> 1.3272 + 1.3273 + <p>For larger server systems, the limit of 40 is much too low. The 1.3274 + limit was established many years ago when a system typically only ran a 1.3275 + few dozen servers.</p> 1.3276 + 1.3277 + <p>On some versions of inetd, such as the one distributed with most 1.3278 + versions of Linux, you can modify the <strong>/etc/inetd.conf</strong> 1.3279 + file to have a larger number of servers by appending a period followed 1.3280 + by a number after the <strong>nowait</strong> word for the server 1.3281 + entry. For example, if your existing /etc/inetd.conf line reads:</p> 1.3282 + <pre> 1.3283 + imap stream tcp nowait root /usr/etc/imapd imapd 1.3284 +</pre>try changing it to be: 1.3285 + <pre> 1.3286 + imap stream tcp nowait.100 root /usr/etc/imapd imapd 1.3287 +</pre>Another example (using TCP wrappers): 1.3288 + <pre> 1.3289 + imap stream tcp nowait root /usr/sbin/tcpd imapd 1.3290 +</pre>try changing it to be: 1.3291 + <pre> 1.3292 + imap stream tcp nowait.100 root /usr/sbin/tcpd imapd 1.3293 + 1.3294 +</pre>to increase the limit to 100 sessions/minute. 1.3295 + 1.3296 + <p>Before making this change, please read the information in "man 1.3297 + inetd" to determine whether or not your inetd has this feature. If it 1.3298 + does not, and you make this change, the likely outcome is that you will 1.3299 + disable IMAP service entirely.</p> 1.3300 + 1.3301 + <p>Another way to fix this problem is to edit the inetd.c source code 1.3302 + (provided by your UNIX system vendor) to set higher limits, rebuild 1.3303 + inetd, install the new binary, and reboot your system. This should only 1.3304 + be done by a UNIX system expert. In the inetd.c source code, the limits 1.3305 + <strong>TOOMANY</strong> (normally 40) is the maximum number of new 1.3306 + server sessions permitted per minute, and <strong>RETRYTIME</strong> 1.3307 + (normally 600) is the number of seconds inetd will shut down the server 1.3308 + after it exceeds TOOMANY.</p> 1.3309 + </dd> 1.3310 + </dl> 1.3311 + 1.3312 + <p><a href="#top">Back to top</a></p> 1.3313 + <hr> 1.3314 + 1.3315 + <p><a name="7.17"><strong>7.17 What does the syslog message:</strong> 1.3316 + <tt>Mailbox lock file /tmp/.600.1df3 open failure: Permission 1.3317 + denied</tt> <strong>mean?</strong></a></p> 1.3318 + 1.3319 + <dl> 1.3320 + <dd> 1.3321 + This usually means that some "helpful" security script person has 1.3322 + protected /tmp so that it is no longer world-writeable. /tmp must be 1.3323 + world-writeable because lots of applications use it for scratch space. 1.3324 + To fix this, do 1.3325 + <pre> 1.3326 + chmod 1777 /tmp 1.3327 + 1.3328 +</pre>as root. 1.3329 + 1.3330 + <p>If that isn't the answer, check the protection of the named file. If 1.3331 + it is something other than 666, then either someone is hacking or some 1.3332 + "helpful" person modified the code to have a different default lock 1.3333 + file protection.</p> 1.3334 + </dd> 1.3335 + </dl> 1.3336 + 1.3337 + <p><a href="#top">Back to top</a></p> 1.3338 + <hr> 1.3339 + 1.3340 + <p><a name="7.18"><strong>7.18 What do the syslog messages:</strong></a></p> 1.3341 + <pre> 1.3342 + Command stream end of file, while reading line user=... host=... 1.3343 + Command stream end of file, while reading char user=... host=... 1.3344 + Command stream end of file, while writing text user=... host=... 1.3345 +</pre> 1.3346 + 1.3347 + <p><strong>mean?</strong></p> 1.3348 + 1.3349 + <dl> 1.3350 + <dd> 1.3351 + This message occurs when the session is disconnected without a proper 1.3352 + LOGOUT (IMAP) or QUIT (POP) command being received by the server first. 1.3353 + 1.3354 + <p>In many cases, this is perfectly normal; many client implementations 1.3355 + are impolite and do this. Some programmers think this sort of rudeness 1.3356 + is "more efficient".</p> 1.3357 + 1.3358 + <p>The condition could, however, indicate a client or network 1.3359 + connectivity problem. The server has no way of knowing whether there's 1.3360 + a problem or just a rude client, so it issues this message instead of a 1.3361 + Logout.</p> 1.3362 + 1.3363 + <p>Certain inferior losing clients disconnect abruptly after a failed 1.3364 + login, and instead of saying that the login failed, just say that they 1.3365 + can't access the mailbox. They then complain to the system manager, who 1.3366 + looks in the syslog and finds this message. Not very helpful, eh? See 1.3367 + the answer to the <a href="#7.4">Why can't I log in to the server? The 1.3368 + user name and password are right!</a> question.</p> 1.3369 + 1.3370 + <p>If the user isn't reporting a problem, you can probably ignore this 1.3371 + message.</p> 1.3372 + </dd> 1.3373 + </dl> 1.3374 + 1.3375 + <p><a href="#top">Back to top</a></p> 1.3376 + <hr> 1.3377 + 1.3378 + <p><a name="7.19"><strong>7.19 Why did my POP or IMAP session suddenly 1.3379 + disconnect? The syslog has the message:</strong> <tt>Killed (lost 1.3380 + mailbox lock) user=... host=...</tt></a></p> 1.3381 + 1.3382 + <dl> 1.3383 + <dd> 1.3384 + This message only happens when either the traditional UNIX mailbox 1.3385 + format or MMDF format is in use. This format only allows one session to 1.3386 + have the mailbox open read/write at a time. 1.3387 + 1.3388 + <p>The servers assume that if a second session attempts to open the 1.3389 + mailbox, that means that the first session is probably owned by an 1.3390 + abandoned client. The common scenario here is a user who leaves his 1.3391 + client running at the office, and then tries to read his mail from 1.3392 + home. Through an internal mechanism called <em>kiss of death</em>, the 1.3393 + second session requests the first session to kill itself. When the 1.3394 + first session receives the "kiss of death", it issues the "Killed (lost 1.3395 + mailbox lock)" syslog message and terminates. The second session then 1.3396 + seizes read/write access, and becomes the new "first" session.</p> 1.3397 + 1.3398 + <p>Certain poorly-designed clients routinely open multiple sessions to 1.3399 + the same mailbox; the users of those clients tend to get this message a 1.3400 + lot.</p> 1.3401 + 1.3402 + <p>Another cause of this message is a background "check for new mail" 1.3403 + task which does its work by opening a POP session to server every few 1.3404 + seconds. They do this because POP doesn't have a way to announce new 1.3405 + mail.</p> 1.3406 + 1.3407 + <p>The solution to both situations is to replace the client with a good 1.3408 + online IMAP client such as Pine. Life is too short to waste on POP 1.3409 + clients and poorly-designed IMAP clients.</p> 1.3410 + </dd> 1.3411 + </dl> 1.3412 + 1.3413 + <p><a href="#top">Back to top</a></p> 1.3414 + <hr> 1.3415 + 1.3416 + <p><a name="7.20"><strong>7.20 Why does my IMAP client show all the files on the 1.3417 + system, recursively from the UNIX root directory?</strong></a><br> 1.3418 + <a name="7.21"><strong>7.21 Why does my IMAP client show all of my files, 1.3419 + recursively from my UNIX home directory?</strong></a></p> 1.3420 + 1.3421 + <dl> 1.3422 + <dd> 1.3423 + A well-written client should only show one level of hierarchy and then 1.3424 + stop, awaiting explicit user action before going lower. However, some 1.3425 + poorly-designed clients will recursively list all files, which may be a 1.3426 + very long list (especially if you have symbolic links to directories 1.3427 + that create a loop in the filesystem graph!). 1.3428 + 1.3429 + <p>This behavior has also been observed in some third-party c-client 1.3430 + drivers, including maildir drivers. Consequently, this problem has even 1.3431 + been observed in Pine. It is important to understand that this is not a 1.3432 + problem in Pine or c-client; it is a problem in the third-party driver. 1.3433 + A Pine built without that third-party driver will not have this 1.3434 + problem.</p> 1.3435 + 1.3436 + <p>See also the answer to <a href="#7.73">Why does my IMAP client show 1.3437 + all my files in my home directory?</a></p> 1.3438 + </dd> 1.3439 + </dl> 1.3440 + 1.3441 + <p><a href="#top">Back to top</a></p> 1.3442 + <hr> 1.3443 + 1.3444 + <p><a name="7.22"><strong>7.22 Why does my IMAP client show that I have 1.3445 + mailboxes named "#mhinbox", "#mh", "#shared", "#ftp", "#news", and 1.3446 + "#public"?</strong></a></p> 1.3447 + 1.3448 + <dl> 1.3449 + <dd> 1.3450 + These are IMAP namespace names. They represent other hierarchies in 1.3451 + which messages may exist. These hierarchies may not necessarily exist 1.3452 + on a server, but the namespace name is still in the namespace list in 1.3453 + order to mark it as reserved. 1.3454 + 1.3455 + <p>A few poorly-designed clients display all namespace names as if they 1.3456 + were top-level mailboxes in a user's list of mailboxes, whether or not 1.3457 + they actually exist. This is a flaw in those clients.</p> 1.3458 + </dd> 1.3459 + </dl> 1.3460 + 1.3461 + <p><a href="#top">Back to top</a></p> 1.3462 + <hr> 1.3463 + 1.3464 + <p><a name="7.23"><strong>7.23 Why does my IMAP client show all my files in my 1.3465 + home directory?</strong></a></p> 1.3466 + 1.3467 + <dl> 1.3468 + <dd> 1.3469 + As distributed, the IMAP server is connected to your home directory by 1.3470 + default. It has no way of knowing what you might call "mail" as opposed 1.3471 + to "some other file"; in fact, you can use IMAP to access any file. 1.3472 + 1.3473 + <p>Most clients have an option to configure your connected directory on 1.3474 + the IMAP server. For example, in Pine you can specify this as the 1.3475 + "Path" in your folder-collection, e.g.</p> 1.3476 + <pre> 1.3477 + Nickname : Secondary Folders 1.3478 + Server : imap.example.com 1.3479 + Path : mail/ 1.3480 + View : 1.3481 +</pre>In this example, the user is connected to the "mail" subdirectory of 1.3482 +his home directory. 1.3483 + 1.3484 + <p>Other servers call this the "folder prefix" or similar term.</p> 1.3485 + 1.3486 + <p>It is possible to modify the IMAP server so that all users are 1.3487 + automatically connected to some other directory, e.g. a subdirectory of 1.3488 + the user's home directory. Read the file CONFIG for more details.</p> 1.3489 + </dd> 1.3490 + </dl> 1.3491 + 1.3492 + <p><a href="#top">Back to top</a></p> 1.3493 + <hr> 1.3494 + 1.3495 + <p><a name="7.24"><strong>7.24 Why is there a long delay before I get connected 1.3496 + to the IMAP or POP server, no matter what client I use?</strong></a></p> 1.3497 + 1.3498 + <dl> 1.3499 + <dd> 1.3500 + There are two common occurances of this problem: 1.3501 + 1.3502 + <ul> 1.3503 + <li>You are running a system (e.g. certain versions of Linux) which 1.3504 + by default attempts to connect to an "IDENT" protocol (port 113) 1.3505 + server on your client. However, a firewall or NAT box is blocking 1.3506 + connections to that port, so the connection attempt times out. 1.3507 + 1.3508 + <p>The IDENT protocol is a well-known bad idea that does not 1.3509 + deliver any real security but causes incredible problems. The idea 1.3510 + is that this will give the server a record of the user name, or at 1.3511 + least what some program listening on port 113 says is the user 1.3512 + name. So, if somebody coming from port nnnnn on a system does 1.3513 + something bad, IDENT may give you the userid of the bad guy.</p> 1.3514 + 1.3515 + <p>The problem is, IDENT is only meaningful on a timesharing system 1.3516 + which has an administrator who is privileged and users who are not. 1.3517 + It is of no value on a personal system which has no separate 1.3518 + concept of "system administrator" vs. "unprivileged user".</p> 1.3519 + 1.3520 + <p>On either type of system, security-minded people either turn 1.3521 + IDENT off or replace it with an IDENT server that lies. Among other 1.3522 + things, IDENT gives spammers the ability to harvest email addresses 1.3523 + from anyone who connects to a web page.</p> 1.3524 + 1.3525 + <p>This problem has been showing up quite frequently on systems 1.3526 + which use xinetd instead of inetd. Look for files named 1.3527 + /etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d, and 1.3528 + /etc/xinetd.d/ipop3d. In those files, look for lines containing 1.3529 + "USERID", e.g.</p> 1.3530 + <pre> 1.3531 + log_on_success += USERID 1.3532 +</pre>Hunt down such lines, and delete them ruthlessly from all files in 1.3533 +which they occur. Don't be shy about it. 1.3534 + </li> 1.3535 + 1.3536 + <li>The DNS is taking a long time to do a reverse DNS (PTR record) 1.3537 + lookup of the IP address of your client. This is a problem in your 1.3538 + DNS, which either you or you ISP need to resolve. Ideally, the DNS 1.3539 + should return the client's name; but if it can't it should at least 1.3540 + return an error quickly.</li> 1.3541 + </ul> 1.3542 + 1.3543 + <p>As you may have noticed, neither of these are actual problems in the 1.3544 + IMAP or POP servers; they are configuration issues with either your 1.3545 + system or your network infrastructure. If this is all new to you, run 1.3546 + (don't walk) to the nearest technical bookstore and get yourself a good 1.3547 + pedagogical text on system administration for the type of system you 1.3548 + are running.</p> 1.3549 + </dd> 1.3550 + </dl> 1.3551 + 1.3552 + <p><a href="#top">Back to top</a></p> 1.3553 + <hr> 1.3554 + 1.3555 + <p><a name="7.25"><strong>7.25 Why is there a long delay in Pine or any other 1.3556 + c-client based application call before I get connected to the IMAP 1.3557 + server? The hang seems to be in the c-client mail_open() call. I don't 1.3558 + have this problem with any other IMAP client. There is no delay 1.3559 + connecting to a POP3 or NNTP server with mail_open().</strong></a></p> 1.3560 + 1.3561 + <dl> 1.3562 + <dd> 1.3563 + By default, the c-client library attempts to make a connection through 1.3564 + rsh (and ssh, if you enable that). If the command: 1.3565 + <pre> 1.3566 + rsh imapserver exec /etc/rimapd 1.3567 + 1.3568 +</pre>(or ssh if that is enabled) returns with a "* PREAUTH" response, it 1.3569 +will use the resulting rsh session as the IMAP session and not require an 1.3570 +authentication step on the server. 1.3571 + 1.3572 + <p>Unfortunately, rsh has a design error that treats "TCP connection 1.3573 + refused" as "temporary failure, try again"; it expects the "rsh not 1.3574 + allowed" case to be implemented as a successful connection followed by 1.3575 + an error message and close the connection.</p> 1.3576 + 1.3577 + <p>It must be emphasized that this is a bug in rsh. It is <em>not</em> 1.3578 + a bug in the IMAP toolkit.</p> 1.3579 + 1.3580 + <p>The use of rsh can be disabled in any the following ways:</p> 1.3581 + 1.3582 + <ul> 1.3583 + <li>You can disable it for this particular session by either: 1.3584 + 1.3585 + <ul> 1.3586 + <li>setting an explicit port number in the mailbox name, e.g. 1.3587 + <pre> 1.3588 + {imapserver.foo.com:143}INBOX 1.3589 +</pre> 1.3590 + </li> 1.3591 + 1.3592 + <li>using SSL (the /ssl switch)</li> 1.3593 + </ul> 1.3594 + </li> 1.3595 + 1.3596 + <li>You can disable rsh globally by setting the rsh timeout value to 1.3597 + 0 with the call: 1.3598 + <pre> 1.3599 + mail_parameters (NIL,SET_RSHTIMEOUT,0); 1.3600 +</pre> 1.3601 + </li> 1.3602 + </ul> 1.3603 + </dd> 1.3604 + </dl> 1.3605 + 1.3606 + <p><a href="#top">Back to top</a></p> 1.3607 + <hr> 1.3608 + 1.3609 + <p><a name="7.26"><strong>7.26 Why does a message sometimes get split into two 1.3610 + or more messages on my SUN system?</strong></a></p> 1.3611 + 1.3612 + <dl> 1.3613 + <dd> 1.3614 + This is caused by an interaction of two independent design problems in 1.3615 + SUN mail software. The first problem is that the "forward message" 1.3616 + option in SUN's <em>mail tool</em> program includes the internal "From 1.3617 + " header line in the text that it forwarded. This internal header line 1.3618 + is specific to traditional UNIX mailbox files and is not suitable for 1.3619 + use in forwarded messages. 1.3620 + 1.3621 + <p>The second problem is that the mail delivery agent assumes that mail 1.3622 + reading programs will not use the traditional UNIX mailbox format but 1.3623 + instead an incompatible variant that depends upon a 1.3624 + <em>Content-Length:</em> message header. Content-Length is widely 1.3625 + recognized to have been a terrible mistake, and is no longer 1.3626 + recommended for use in mail (it is used in other facilities that use 1.3627 + MIME).</p> 1.3628 + 1.3629 + <p>One symptom of the problem is that under certain circumstances, a 1.3630 + message may get broken up into several messages. I'm also aware of 1.3631 + security bugs caused by programs that foolishly trust "Content-Length:" 1.3632 + headers with evil values.</p> 1.3633 + 1.3634 + <p>To fix the mailer on your system, edit your sendmail.cf to change 1.3635 + the <strong>Mlocal</strong> line to have the <strong>-E</strong> flag. 1.3636 + A typical entry will lool like:</p> 1.3637 + <pre> 1.3638 + Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20, 1.3639 + A=mail.local -d $u 1.3640 +</pre>This fix will also work around the problem with mail tool, because it 1.3641 +will insert a ">" before the internal header line to prevent it from being 1.3642 +interpreted by mail reading software as an internal header line. 1.3643 + </dd> 1.3644 + </dl> 1.3645 + 1.3646 + <p><a href="#top">Back to top</a></p> 1.3647 + <hr> 1.3648 + 1.3649 + <p><a name="7.27"><strong>7.27 Why did my POP or IMAP session suddenly 1.3650 + disconnect? The syslog has the message:</strong></a></p> 1.3651 + <pre> 1.3652 + Autologout user=<...my user name...> host=<...my client system...> 1.3653 + 1.3654 +</pre> 1.3655 + 1.3656 + <dl> 1.3657 + <dd> 1.3658 + This is a problem in your client. 1.3659 + 1.3660 + <p>In the case of IMAP, it failed to communicate with the IMAP server 1.3661 + for over 30 minutes; in the case of POP, it failed to communicate with 1.3662 + the POP server for over 10 minutes.</p> 1.3663 + </dd> 1.3664 + </dl> 1.3665 + 1.3666 + <p><a href="#top">Back to top</a></p> 1.3667 + <hr> 1.3668 + 1.3669 + <p><a name="7.28"><strong>7.28 What does the UNIX error message:</strong> 1.3670 + <tt>TLS/SSL failure: myserver: SSL negotiation failed</tt> 1.3671 + <strong>mean?</strong></a><br> 1.3672 + <a name="7.29"><strong>7.29 What does the PC error message:</strong> 1.3673 + <tt>TLS/SSL failure: myserver: Unexpected TCP input disconnect</tt> 1.3674 + <strong>mean?</strong></a></p> 1.3675 + 1.3676 + <dl> 1.3677 + <dd> 1.3678 + This usually means that an attempt to negotiate TLS encryption via the 1.3679 + STARTTLS command failed, because the server advertises STARTTLS 1.3680 + functionality, but doesn't actually have it (e.g. because no 1.3681 + certificates are installed). 1.3682 + 1.3683 + <p>Use the /notls option in the mailbox name to disable TLS 1.3684 + negotiation.</p> 1.3685 + </dd> 1.3686 + </dl> 1.3687 + 1.3688 + <p><a href="#top">Back to top</a></p> 1.3689 + <hr> 1.3690 + 1.3691 + <p><a name="7.30"><strong>7.30 What does the error message:</strong> <tt>TLS/SSL 1.3692 + failure: myserver: Server name does not match certificate</tt> 1.3693 + <strong>mean?</strong></a></p> 1.3694 + 1.3695 + <dl> 1.3696 + <dd> 1.3697 + An SSL or TLS session encryption failed because the server name in the 1.3698 + server's certificate does not match the name that you gave it. This 1.3699 + could indicate that the server is not really the system you think that 1.3700 + it is, but can be also be called if you gave a nickname for the server 1.3701 + or name that was not fully-qualified. You must use the fully-qualified 1.3702 + domain name for the server in order to validate its certificate 1.3703 + 1.3704 + <p>Use the /novalidate-cert option in the mailbox name to disable 1.3705 + validation of the certificate.</p> 1.3706 + </dd> 1.3707 + </dl> 1.3708 + 1.3709 + <p><a href="#top">Back to top</a></p> 1.3710 + <hr> 1.3711 + 1.3712 + <p><a name="7.31"><strong>7.31 What does the UNIX error message:</strong> 1.3713 + <tt>TLS/SSL failure: myserver: self-signed certificate</tt> 1.3714 + <strong>mean?</strong></a><br> 1.3715 + <a name="7.32"><strong>7.32 What does the PC error message:</strong> 1.3716 + <tt>TLS/SSL failure: myserver: Self-signed certificate or untrusted 1.3717 + authority</tt> <strong>mean?</strong></a></p> 1.3718 + 1.3719 + <dl> 1.3720 + <dd> 1.3721 + An SSL or TLS session encryption failed because your server's 1.3722 + certificate is "self-signed"; that is, it is not signed by any 1.3723 + Certificate Authority (CA) and thus can not be validated. A CA-signed 1.3724 + certificate costs money, and some smaller sites either don't want to 1.3725 + pay for it or haven't gotten one yet. The bad part about this is that 1.3726 + this means there is no guarantee that the server is really the system 1.3727 + you think that it is. 1.3728 + 1.3729 + <p>Use the /novalidate-cert option in the mailbox name to disable 1.3730 + validation of the certificate.</p> 1.3731 + </dd> 1.3732 + </dl> 1.3733 + 1.3734 + <p><a href="#top">Back to top</a></p> 1.3735 + <hr> 1.3736 + 1.3737 + <p><a name="7.33"><strong>7.33 What does the UNIX error message:</strong> 1.3738 + <tt>TLS/SSL failure: myserver: unable to get local issuer 1.3739 + certificate</tt> <strong>mean?</strong></a></p> 1.3740 + 1.3741 + <dl> 1.3742 + <dd> 1.3743 + An SSL or TLS session encryption failed because your system does not 1.3744 + have the Certificate Authority (CA) certificates installed on OpenSSL's 1.3745 + certificates directory. On most systems, this directory is 1.3746 + /usr/local/ssl/certs). As a result, it is not possible to validate the 1.3747 + server's certificate. 1.3748 + 1.3749 + <p>If CA certificates are properly installed, you should see 1.3750 + factory.pem and about a dozen other .pem names such as 1.3751 + thawteCb.pem.</p> 1.3752 + 1.3753 + <p>As a workaround, you can use the /novalidate-cert option in the 1.3754 + mailbox name to disable validation of the certificate; however, note 1.3755 + that you are then vulnerable to various security attacks by bad 1.3756 + guys.</p> 1.3757 + 1.3758 + <p>The correct fix is to copy all the files from the certs/ directory 1.3759 + in the OpenSSL distribution to the /usr/local/ssl/certs (or whatever) 1.3760 + directory. Note that you need to do this after building OpenSSL, 1.3761 + because the OpenSSL build creates a number of needed symbolic links. 1.3762 + For some bizarre reason, the OpenSSL "make install" doesn't do this for 1.3763 + you, so you must do it manually.</p> 1.3764 + </dd> 1.3765 + </dl> 1.3766 + 1.3767 + <p><a href="#top">Back to top</a></p> 1.3768 + <hr> 1.3769 + 1.3770 + <p><a name="7.34"><strong>7.34 Why does reading certain messages hang when using 1.3771 + Netscape? It works fine with Pine!</strong></a></p> 1.3772 + 1.3773 + <dl> 1.3774 + <dd> 1.3775 + There are two possible causes. 1.3776 + 1.3777 + <p>Check the mail syslog. If you see the message "Killed (lost mailbox 1.3778 + lock)" for the impacted user(s), read the FAQ entry regarding that 1.3779 + message.</p> 1.3780 + 1.3781 + <p>Check the affected mailbox to see if there are embedded NUL 1.3782 + characters in the message. NULs in message texts are a technical 1.3783 + violation of both the message format and IMAP specifications. Most 1.3784 + clients don't care, but apparently Netscape does.</p> 1.3785 + 1.3786 + <p>You can work around this by rebuilding imapd with the 1.3787 + <strong>NETSCAPE_BRAIN_DAMAGE</strong> option set (see 1.3788 + src/imapd/Makefile); this will cause imapd to convert all NULs to 0x80 1.3789 + characters. A better solution is to enable the feature in your MTA to 1.3790 + MIME-convert messages with binary content. See the documentation for 1.3791 + your MTA for how to do this.</p> 1.3792 + </dd> 1.3793 + </dl> 1.3794 + 1.3795 + <p><a href="#top">Back to top</a></p> 1.3796 + <hr> 1.3797 + 1.3798 + <p><a name="7.35"><strong>7.35 Why does Netscape say that there's a problem with 1.3799 + the IMAP server and that I should "Contact your mail server 1.3800 + administrator."?</strong></a></p> 1.3801 + 1.3802 + <dl> 1.3803 + <dd> 1.3804 + Certain versions of Netscape do this when you click the Manage Mail 1.3805 + button, which uses an undocumented feature of Netscape's proprietary 1.3806 + IMAP server. 1.3807 + 1.3808 + <p>You can work around this by rebuilding imapd with the 1.3809 + <strong>NETSCAPE_BRAIN_DAMAGE</strong> option set (see 1.3810 + src/imapd/Makefile) to a URL that points either to an alternative IMAP 1.3811 + client (e.g. Pine) or perhaps to a homebrew mail account management 1.3812 + page.</p> 1.3813 + </dd> 1.3814 + </dl> 1.3815 + 1.3816 + <p><a href="#top">Back to top</a></p> 1.3817 + <hr> 1.3818 + 1.3819 + <p><a name="7.36"><strong>7.36 Why is one user creating huge numbers of IMAP or 1.3820 + POP server sessions?</strong></a></p> 1.3821 + 1.3822 + <dl> 1.3823 + <dd>The user is probably using Outlook Express, Eudora, or a similar 1.3824 + program. See the answer to the <a href="#7.5">Help! My load average is 1.3825 + soaring and I see hundreds of POP and IMAP servers, many logged in as the 1.3826 + same user!</a> question.</dd> 1.3827 + </dl> 1.3828 + 1.3829 + <p><a href="#top">Back to top</a></p> 1.3830 + <hr> 1.3831 + 1.3832 + <p><a name="7.37"><strong>7.37 Why don't I get any new mail notifications from 1.3833 + Outlook Express or Outlook after a while?</strong></a></p> 1.3834 + 1.3835 + <dl> 1.3836 + <dd> 1.3837 + This is a known bug in Outlook Express. Microsoft is aware of the 1.3838 + problem and its cause. They have informed us that they do not have any 1.3839 + plans to fix it at the present time. 1.3840 + 1.3841 + <p>The problem is also reported in Outlook 2000, but not verified.</p> 1.3842 + 1.3843 + <p>Outlook Express uses the IMAP IDLE command to avoid having to "ping" 1.3844 + the server every few minutes for new mail. Unfortunately, Outlook 1.3845 + Express overlooks the part in the IDLE specification which requires 1.3846 + that a client terminate and restart the IDLE before the IMAP 30 minute 1.3847 + inactivity autologout timer triggers.</p> 1.3848 + 1.3849 + <p>When this happens, Outlook Express displays "Not connected" at the 1.3850 + bottom of the window. Since it's no longer connected to the IMAP 1.3851 + server, it isn't going to notice any new mail.</p> 1.3852 + 1.3853 + <p>As soon as the user does anything that would cause an IMAP 1.3854 + operation, Outlook Express will reconnect and new mail will flow again. 1.3855 + If the user does something that causes an IMAP operation at least every 1.3856 + 29 minutes, the problem won't happen.</p> 1.3857 + 1.3858 + <p>Modern versions of imapd attempt to work around the problem by 1.3859 + automatically reporting fake new mail after 29 minutes. This causes 1.3860 + Outlook Express to exit the IDLE state; as soon as this happens imapd 1.3861 + revokes the fake new mail. As long as this behavior isn't known to 1.3862 + cause problems with other clients, this workaround will remain in 1.3863 + imapd.</p> 1.3864 + </dd> 1.3865 + </dl> 1.3866 + 1.3867 + <p><a href="#top">Back to top</a></p> 1.3868 + <hr> 1.3869 + 1.3870 + <p><a name="7.38"><strong>7.38 Why don't I get any new mail notifications from 1.3871 + Entourage?</strong></a></p> 1.3872 + 1.3873 + <dl> 1.3874 + <dd> 1.3875 + This is a known bug in Entourage. 1.3876 + 1.3877 + <p>You built an older version of imapd with the 1.3878 + <strong>MICROSOFT_BRAIN_DAMAGE</strong> option set, in order to disable 1.3879 + support for the IDLE command. However, Entourage won't get new mail 1.3880 + unless IDLE command support exists.</p> 1.3881 + 1.3882 + <p>Note: the MICROSOFT_BRAIN_DAMAGE option no longer exists in modern 1.3883 + versions, as the Outlook Express problem which it attempted to solve 1.3884 + has been worked around in another way.</p> 1.3885 + </dd> 1.3886 + </dl> 1.3887 + 1.3888 + <p><a href="#top">Back to top</a></p> 1.3889 + <hr> 1.3890 + 1.3891 + <p><a name="7.39"><strong>7.39 Why doesn't Entourage work at 1.3892 + all?</strong></a></p> 1.3893 + 1.3894 + <dl> 1.3895 + <dd> 1.3896 + It's hard to know. Entourage breaks almost every rule in the book for 1.3897 + IMAP. It is highly instructive to do a packet trace on Entourage, as an 1.3898 + example of how <em>not</em> to use IMAP. It does things like STATUS 1.3899 + (MESSAGES) on the currently selected mailbox and re-fetching the same 1.3900 + static data over and over again. 1.3901 + 1.3902 + <p>It seems that every time we understand what it is doing wrong in 1.3903 + Entourage and come up with a workaround, we learn about something else 1.3904 + that's broken.</p> 1.3905 + 1.3906 + <p>Try building imapd with the <strong>ENTOURAGE_BRAIN_DAMAGE</strong> 1.3907 + option set, in order to disable the diagnostic that occurs when doing 1.3908 + STATUS on the currently selected mailbox.</p> 1.3909 + </dd> 1.3910 + </dl> 1.3911 + 1.3912 + <p><a href="#top">Back to top</a></p> 1.3913 + <hr> 1.3914 + 1.3915 + <p><a name="7.40"><strong>7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work 1.3916 + at all?</strong></a></p> 1.3917 + 1.3918 + <dl> 1.3919 + <dd> 1.3920 + This is a bug in NSNOTIFY; it doesn't handle unsolicited data from the 1.3921 + server correctly. 1.3922 + 1.3923 + <p>Fortunately, there is no reason to use this program with IMAP; 1.3924 + NSNOTIFY is a polling program to let you know when new mail has 1.3925 + appeared in your maildrop. This is necessary with POP; but since IMAP 1.3926 + dynamically announces new mail in the session you're better off (and 1.3927 + will actually cause less load on the server!) keeping your mail reading 1.3928 + program's IMAP session open and let IMAP do the notifying for you.</p> 1.3929 + 1.3930 + <p>Consequently, the recommended fix for the NSNOTIFY problem is to 1.3931 + delete the NSNOTIFY binary.</p> 1.3932 + </dd> 1.3933 + </dl> 1.3934 + 1.3935 + <p><a href="#top">Back to top</a></p> 1.3936 + <hr> 1.3937 + 1.3938 + <p><a name="7.41"><strong>7.41 Why can't I connect via SSL to Eudora? It says 1.3939 + the connection has been broken, and in the server syslogs I see "Command 1.3940 + stream end of file".</strong></a></p> 1.3941 + 1.3942 + <dl> 1.3943 + <dd>There is a report that you can fix the problem by going into Eudora's 1.3944 + advanced network configuration menu and increasing the network buffer 1.3945 + size to 8192.</dd> 1.3946 + </dl> 1.3947 + 1.3948 + <p><a href="#top">Back to top</a></p> 1.3949 + <hr> 1.3950 + 1.3951 + <p><a name="7.42"><strong>7.42 Sheesh. Aren't there <em>any</em> good IMAP 1.3952 + clients out there?</strong></a></p> 1.3953 + 1.3954 + <dl> 1.3955 + <dd> 1.3956 + Yes! 1.3957 + 1.3958 + <p>Pine is a <em>wonderful</em> client. It's fast, it uses IMAP well, 1.3959 + and it generates text mail (life is too short to waste on HTML mail). 1.3960 + Also, there are some really wonderful things in progress in the Pine 1.3961 + world.</p> 1.3962 + 1.3963 + <p>There are some good GUI clients out there, mostly from smaller 1.3964 + vendors. Without naming names, look for the vendors who are active in 1.3965 + the IMAP protocol development community, and their products.</p> 1.3966 + 1.3967 + <p>Netscape, Eudora, and Outlook <em>can</em> be configured with enough 1.3968 + effort to be good citizens and work well for users, <em>but</em> they 1.3969 + can also be badly misconfigured, and often the misconfiguration is the 1.3970 + default.</p> 1.3971 + </dd> 1.3972 + </dl> 1.3973 + 1.3974 + <p><a href="#top">Back to top</a></p> 1.3975 + <hr> 1.3976 + 1.3977 + <p><a name="7.43"><strong>7.43 But wait! PC Pine (or other PC program build with 1.3978 + c-client) crashes with the message</strong> <tt>incomplete SecBuffer 1.3979 + exceeds maximum buffer size</tt> <strong>when I use SSL connections. 1.3980 + This is a bug in c-client, right?</strong></a></p> 1.3981 + 1.3982 + <dl> 1.3983 + <dd> 1.3984 + It's a bug in the Microsoft SChannel.DLL, which implements SSL. 1.3985 + Microsoft admits it (albeit with an unstatement: "it's not fully RFC 1.3986 + compliant"). The problem is that SChannel indicates that the maximum 1.3987 + SSL packet data size is 5 bytes smaller than the actual maximum. Thus, 1.3988 + any IMAP server which transmits a maximum sized SSL packet will not 1.3989 + work with PC Pine or any other program which uses SChannel. 1.3990 + 1.3991 + <p>It can take a while for the problem to show up. The client has to do 1.3992 + something that causes at least 16K of contiguous data. Many clients do 1.3993 + partial fetching, which tends to reduce the number of cases where this 1.3994 + can happen. However, <em>all</em> software which uses SChannel to 1.3995 + support SSL is affected by this bug.</p> 1.3996 + 1.3997 + <p>This problem does not affect UNIX code, since OpenSSL is used on 1.3998 + UNIX.</p> 1.3999 + 1.4000 + <p>This problem most recently showed up with the CommunigatePro IMAP 1.4001 + server. They have an update which trims down their maximum contiguous 1.4002 + data to less than 16K, in order to work around the problem.</p> 1.4003 + 1.4004 + <p>This problem has also shown up with the Exchange IMAP server with 1.4005 + UNIX clients (including Pine built with an older version of c-client) 1.4006 + which sends full-sized 16K SSL packets. Modern c-client works around 1.4007 + the problem by trimming down its maximum outgoing SSL packet size to 1.4008 + 8K.</p> 1.4009 + 1.4010 + <p>Microsoft has developed a hotfix for this bug. Look up MSKB article 1.4011 + number 300562. Contrary to the article text which implies that this is 1.4012 + a Pine issue, this bug also affect Microsoft Exchange server with *any* 1.4013 + UNIX based client that transmits full-sized SSL payloads.</p> 1.4014 + </dd> 1.4015 + </dl> 1.4016 + 1.4017 + <p><a href="#top">Back to top</a></p> 1.4018 + <hr> 1.4019 + 1.4020 + <p><a name="7.44"><strong>7.44 My qpopper users keep on getting the DON'T DELETE 1.4021 + THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or IMAP. How 1.4022 + can I fix this?</strong></a></p> 1.4023 + 1.4024 + <dl> 1.4025 + <dd> 1.4026 + This is an incompatibility between qpopper and the c-client library 1.4027 + used by Pine, imapd, and ipop[23]d. 1.4028 + 1.4029 + <p>Assuming that you want to continue using qpopper, look into 1.4030 + qpopper's <strong>--enable-uw-kludge-flag</strong> configuration flag, 1.4031 + which is documented as "check for and hide UW 'Folder Internal Data' 1.4032 + messages".</p> 1.4033 + 1.4034 + <p>The other alternative is to switch from qpopper to ipop3d.</p> 1.4035 + </dd> 1.4036 + </dl> 1.4037 + 1.4038 + <p><a href="#top">Back to top</a></p> 1.4039 + <hr> 1.4040 + 1.4041 + <p><a name="7.45"><strong>7.45 Help! I installed the servers but I can't connect 1.4042 + to them from my client!</strong></a></p> 1.4043 + 1.4044 + <dl> 1.4045 + <dd> 1.4046 + Review the installation instructions carefully. Make sure that you have 1.4047 + not skipped any of the steps. Make sure that you have made the correct 1.4048 + entries in the configuration files; pay careful attention to the exact 1.4049 + spelling of the service names and the path names. Make sure as well 1.4050 + that you have properly restarted inetd. 1.4051 + 1.4052 + <p>If you have a system with Yellow Pages/NIS such as Solaris, have you 1.4053 + updated the service names there as well as in /etc/services?</p> 1.4054 + 1.4055 + <p>If you have a system with TCP wrappers, have you properly updated 1.4056 + the TCP wrapper files (e.g. /etc/hosts.allow and /etc/hosts.deny) for 1.4057 + the servers?</p> 1.4058 + 1.4059 + <p>If you have a system which uses xinetd instead of inetd, have you 1.4060 + made sure that you have made the correct corresponding xinetd changes 1.4061 + for those services?</p> 1.4062 + 1.4063 + <p>Try telneting to the server port (143 for IMAP, 110 for POP3). If 1.4064 + you get a "refused" error, that probably means that you don't have the 1.4065 + service set up in inetd.conf. If the connection opens and then closes 1.4066 + with no message, the service is set up, but either the path name of the 1.4067 + server binary in inetd.conf is wrong or your TCP wrappers are 1.4068 + configured to deny access.</p> 1.4069 + 1.4070 + <p>If you don't know how to make the corresponding changes to these 1.4071 + files, seek the help of a local expert for your system.</p> 1.4072 + </dd> 1.4073 + </dl> 1.4074 + 1.4075 + <p><a href="#top">Back to top</a></p> 1.4076 + <hr> 1.4077 + 1.4078 + <p><a name="7.46"><strong>7.46 Why do I get the message</strong> <tt>Can not 1.4079 + authenticate to SMTP server: 421 SMTP connection went away!</tt> 1.4080 + <strong>and why did this happen? There was also something about</strong> 1.4081 + <tt>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</tt></a></p> 1.4082 + 1.4083 + <dl> 1.4084 + <dd> 1.4085 + Some versions of qmail, including that running on mail.smtp.yahoo.com, 1.4086 + disconnect the SMTP session if you fail to authenticate prior to 1.4087 + attempting to transmit mail. An attempt to authenticate was made, but 1.4088 + it failed because the server had already disconnected. 1.4089 + 1.4090 + <p>To work around this, you need to specify /user=... in the host name 1.4091 + specification.</p> 1.4092 + 1.4093 + <p>The SECURITY PROBLEM came about because the server advertised the 1.4094 + AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted 1.4095 + session, in violation of RFC 4616. This message is just a warning, and 1.4096 + in fact occurred after the server had disconnected.</p> 1.4097 + </dd> 1.4098 + </dl> 1.4099 + 1.4100 + <p><a href="#top">Back to top</a></p> 1.4101 + <hr> 1.4102 + 1.4103 + <p><a name="7.47"><strong>7.47 Why do I get the message</strong> <tt>SMTP 1.4104 + Authentication cancelled</tt> <strong>and why did this happen? There was 1.4105 + also something about</strong> <tt>SECURITY PROBLEM: insecure server 1.4106 + advertised AUTH=PLAIN</tt></a></p> 1.4107 + 1.4108 + <dl> 1.4109 + <dd> 1.4110 + This is a bug in the SMTP server. 1.4111 + 1.4112 + <p>Some versions of qmail, including that running on 1.4113 + mail.smtp.yahoo.com, have a bug in their implementation of SASL in 1.4114 + their SMTP server, which renders it non-compliant with the 1.4115 + standard.</p> 1.4116 + 1.4117 + <p>If the client does not provide an initial response in the command 1.4118 + line for an authentication mechanism whose profile does not have an 1.4119 + initial challenge, qmail issues a bogus response:</p> 1.4120 + <pre> 1.4121 + 334 ok, go on 1.4122 +</pre>The problem is the "ok, go on". This violates RFC 4954's requirement 1.4123 +that the text part in a 334 response be a BASE64 encoded string; in other 1.4124 +words, it is a protocol syntax error. 1.4125 + 1.4126 + <p>In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the 1.4127 + encoded string have no data. In other words, the appropropiate 1.4128 + standards-compliant server response is "334" followed by a SPACE and a 1.4129 + CRLF.</p> 1.4130 + 1.4131 + <p>The SECURITY PROBLEM came about because the server advertised the 1.4132 + AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted 1.4133 + session, in violation of RFC 4616. This message is just a warning, and 1.4134 + is not related the "Authentication cancelled" problem.</p> 1.4135 + </dd> 1.4136 + </dl> 1.4137 + 1.4138 + <p><a href="#top">Back to top</a></p> 1.4139 + <hr> 1.4140 + 1.4141 + <p><a name="7.48"><strong>7.48 Why do I get the message</strong> <tt>Invalid 1.4142 + base64 string</tt> <strong>when I try to authenticate to a Cyrus 1.4143 + server?</strong></a></p> 1.4144 + 1.4145 + <dl> 1.4146 + <dd> 1.4147 + This slightly misleading message is the way that a Cyrus server 1.4148 + indicates that an authentication exchange was cancelled. It is not 1.4149 + indicative of a bug or protocol violation. 1.4150 + 1.4151 + <p>The most common reason that this happens is if the Cyrus server 1.4152 + offers Kerberos authentication, c-client is built with Kerberos 1.4153 + support, but your client system is not within the Kerberos realm. In 1.4154 + this case, the client code will try to authenticate via Kerberos, fail 1.4155 + to get the Kerberos credentials, cancel the authentication attempt, and 1.4156 + try the next available authentication technology.</p> 1.4157 + </dd> 1.4158 + </dl> 1.4159 + 1.4160 + <p><a href="#top">Back to top</a></p> 1.4161 + <hr> 1.4162 + 1.4163 + <p><br></p> 1.4164 + 1.4165 + <h2><a name="additional">8. Where to Go For Additional Information</a></h2> 1.4166 + <hr> 1.4167 + 1.4168 + <p><a name="8.1"><strong>8.1 Where can I go to ask questions?</strong></a><br> 1.4169 + <a name="8.2"><strong>8.2 I have some ideas for enhancements to IMAP. Where 1.4170 + should I go?</strong></a></p> 1.4171 + 1.4172 + <dl> 1.4173 + <dd> 1.4174 + If you have questions about the IMAP protocol, or want to participate 1.4175 + in discussions of future directions of the IMAP protocol, the 1.4176 + appropriate mailing list is imap-protocol@u.washington.edu. You can 1.4177 + subscribe to this list via <a href= 1.4178 + "mailto:imap-protocol-request@u.washington.edu"><tt>imap-protocol-request@u.washington.edu</tt></a> 1.4179 + 1.4180 + <p>If you have questions about this software, you can send me email 1.4181 + directly or use the imap-uw@u.washington.edu mailing list. You can 1.4182 + subscribe to this list via <a href= 1.4183 + "mailto:imap-uw-request@u.washington.edu"><tt>imap-uw-request@u.washington.edu</tt></a></p> 1.4184 + 1.4185 + <p>If you have general questions about the use of IMAP software 1.4186 + (not specific to the UW IMAP toolkit) use the 1.4187 + imap-use@u.washington.edu mailing list. You can subscribe to 1.4188 + this list via <a href= 1.4189 + "mailto:imap-use-request@u.washington.edu"><tt>imap-use-request@u.washington.edu</tt></a></p> 1.4190 + 1.4191 + <p>You must be a subscriber to post to these lists. As an 1.4192 + alternative, you can use the 1.4193 + <strong>comp.mail.imap</strong> newsgroup.</p> 1.4194 + </dd> 1.4195 + </dl> 1.4196 + 1.4197 + <p><a href="#top">Back to top</a></p> 1.4198 + <hr> 1.4199 + 1.4200 + <p><a name="8.3"><strong>8.3 Where can I read more about IMAP and other email 1.4201 + protocols?</strong></a></p> 1.4202 + 1.4203 + <dl> 1.4204 + <dd>We recommend <em>Internet Email Protocols: A Developer's Guide</em>, 1.4205 + by Kevin Johnson, published by Addison Wesley, ISBN 0-201-43288-9.</dd> 1.4206 + </dl> 1.4207 + 1.4208 + <p><a href="#top">Back to top</a></p> 1.4209 + <hr> 1.4210 + 1.4211 + <p><a name="8.4"><strong>8.4 Where can I find out more about setting up and 1.4212 + administering an IMAP server?</strong></a></p> 1.4213 + 1.4214 + <dl> 1.4215 + <dd> 1.4216 + We recommend <em>Managing IMAP</em>, by Dianna Mullet & Kevin 1.4217 + Mullet, published by O'Reilly, ISBN 0-596-00012-X. 1.4218 + 1.4219 + <p>This book also has an excellent comparison of the UW and Cyrus IMAP 1.4220 + servers.<br></p> 1.4221 + </dd> 1.4222 + </dl> 1.4223 + 1.4224 + <p><a href="#top">Back to top</a></p> 1.4225 + 1.4226 + <p>Last Updated: 15 November 2007</p> 1.4227 + 1.4228 +<!--chtml include "//imap/incs/bottom.inc"--> 1.4229 +