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