		   IMAP TOOLKIT FREQUENTLY ASKED QUESTIONS
			Last Updated: 9 January 2001

GENERAL QUESTIONS:

Q: Is this software Y2K compliant?
A: Please read the files Y2K and calendar.txt.


Q: How can I use a C++ compiler with this software?
A: If you are building an application using the c-client library, use the
    new c-client.h file instead of including the other include files.  I
    think that c-client.h should define away all the troublesome names that
    conflict with C++.


Q: Can I set up a POP or IMAP server on Windows 2000, Windows 95 and 98?
A: Yes.  Refer to the NT specific notes in files CONFIG and BUILD.  Also,
    you *must* set up CRAM-MD5 authentication, as described in md5.txt.
    There is no file access control on Windows 9x, so you probably will
    have to do modifications to env_unix.c to prevent people from hacking
    others' mail.
   Note, however, that the server is not plug and play the way it is for
    UNIX.


Q: I have a Windows system.  Why isn't the server plug and play for me?
A: There is no standard for how mail is stored on NT; nor a single standard
    SMTP server.  So there's no default by which to make assumptions.  As
    the software is set up, it assumes that the each user has an NT login
    account and private home directory, and that mail is stored on that
    home directory as files in one of the popular UNIX formats.  It also
    assumes that there is some tool equivalent to inetd on UNIX that does
    the TCP/IP listening and server startup.
   Basically, unless you're an email software hacker, you probably want
    to look elsewhere if you want IMAP/POP servers for Windows.


Q: Can I set up a POP or IMAP server on Windows 3.1 or DOS?
Q: Can I set up a POP or IMAP server on Macintosh?
Q: Can I set up a POP or IMAP server on VAX/VMS?
A: It's just a small matter of programming.  Have fun.


Q: Can I set up a POP or IMAP server on TOPS-20?
A: You have a TOPS-20 system?  Cool.
   If IMAP2 (RFC 1176) is good enough for you, you can use MAPSER which
    is about the ultimate gonzo pure TOPS-20 extended addressing assembly
    language program.  Maybe someone will hack it to do IMAP4rev1 some day.
   Or you can port the IMAP server from this IMAP toolkit to it.  All
    that you need for a first stab is to port the MTX driver.  That'll
    probably be just a couple of hours of hacking.
  

Q: What is the status of internationalization?
A: The IMAP toolkit is partially internationalized and multilingualized.
    In particular, searching is supported in the following charsets:
     US-ASCII, UTF-8, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4,
     ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9,
     ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15,
     KOI8-R, KOI8-U (alias KOI8-RU), TIS-620, VISCII,
     ISO-2022-JP, ISO-2022-KR, ISO-2022-CN, ISO-2022-JP-1, ISO-2022-JP-2,
     GB2312 (alias CN-GB), CN-GB-12345, BIG5 (alias CN-BIG5),
     EUC-JP, EUC-KR, Shift_JIS, Shift-JIS, KS_C_5601-1987, KS_C_5601-1992,
     WINDOWS_874, WINDOWS-1250, WINDOWS-1251, WINDOWS-1252, WINDOWS-1253,
     WINDOWS-1254, WINDOWS-1255, WINDOWS-1256, WINDOWS-1257, WINDOWS-1258.
    All ISO-2022-?? charsets are treated identically, and support ASCII,
     JIS Roman, hankaku katakana, ISO-8859-[1 - 10], TIS, GB 2312, JIS X 0208,
     JIS X 0212, KSC 5601, and planes 1 and 2 of CNS 11643.
    EUC-JP includes support for JIS X 0212 and hankaku katakana.
    There is no support for localization (e.g. non-English error messages)
     at the present time, but such support is planned.


Q: Why do I get the message:
     CREATE failed: Can't create mailbox node xxxxxxxxx: File exists
    and how do I fix it?
Q: Are hierarchical mailboxes supported?
A: Yes.  However, there is one important caveat.
   Some mailbox formats, including the default which is the traditional UNIX
    mailbox format, are stored as a single file containing all the messages.
    UNIX does not permit a name in the filesystem to be both a file and a
    directory; consequently you can not have a sub-mailbox within a mailbox
    that is in one of these formats.
   This is not a limitation of the software; this is a limitation of UNIX.
    For example, there are mailbox formats in which the name is a directory
    and each message is a file within that directory; these formats support
    sub-mailboxes within such mailboxes.  However, for technical reasons, the
    "flat file" formats are generally preferred since they perform better.
    Read imap-2000/docs/formats.txt for more information on this topic.
   It is always permissible to create a directory that is not a mailbox, and
    have sub-mailboxes under it.  The easiest way to create a directory is to
    create a new mailbox inside a directory that doesn't already exist.  For
    example, if you create "Mail/testbox" on UNIX, the directory "Mail/" will
    automatically be created and then the mailbox "testbox" will be created as
    a sub-mailbox of "Mail/".
   It is also possible to create the name "Mail/" directly.  Check the
    documentation for your client software to see how to do this with that
    software.
   Of course, on Windows systems you would use "\" instead of "/".


Q: Are "dual-use" mailboxes supported?
Q: Can I have a mailbox that has both messages and sub-mailboxes?
A: See the answer to the question, "Are hierarchical mailboxes supported?"


Q: What is the difference between "mailbox" and "folder"?
A: The term "mailbox" is IMAP-speak for what a lot of software calls a "folder"
    or a "mail folder".  However, "folder" is often used in other contexts to
    refer to a directory, for example, in the graphic user interface on both
    Windows and Macintosh.
   A "mailbox" is specifically defined as a named object that contains
    messages.  It is not required to be capable of containing other types of
    objects including other mailboxes; although some mailbox formats will
    permit this.
   In IMAP-speak, a mailbox which can not contain other mailboxes is called a
    "no-inferiors mailbox".  Similarly, a directory which can not contain
    messages is not a mailbox and is called a "no-select name".

BUILD AND CONFIGURATION QUESTIONS:

Q: How do I configure the IMAP and POP servers on UNIX?
Q: I built and installed the servers according to the BUILD instructions.
    It can't be that easy.  Don't I need to write a config file?
A: For ordinary "vanilla" UNIX systems, this software is plug and play; just
    build it, install it, and you're done.  If you have a modified system,
    then you may want to do additional work; most of this is to a single
    source code file (env_unix.c on UNIX systems).  Read the file CONFIG
    for more details.
   Yes, it's that easy.  There are some additional options, such as SSL or
    Kerberos, which require additional.  See the relevant questions below.


Q: How do I make the IMAP and POP servers look for INBOX at some place
    other than the mail spool directory?
Q: How do I make the IMAP server look for secondary folders at some place
    other than the user's home directory?
A: Please read the file CONFIG for discussion of this and other issues.


Q: Can I use SSL?
Q: Can I use TLS and the STARTTLS facility?
A: Yes.  imap-2000 supports SSL client functionality for IMAP, POP3, SMTP,
    and NNTP; and SSL and TLS server functionality for IMAP and POP3.  This
    is available on UNIX, and 32-bit Windows.
   UNIX SSL build requires that a third-party software package, OpenSSL, be
    installed on the system first.  Read imap-2000/docs/SSLBUILD for more
    information.
   SSL is supported via undocumented Microsoft interfaces in Windows 9x,
    Windows Millenium, and NT4; and via standard interfaces in Windows 2000.
   

Q: How do I build/install OpenSSL?
Q: How do I obtain/create certificates for use with SSL?
A: If you need help in doing this, try the contacts mentioned in the OpenSSL
    README.  We do not offer support for OpenSSL or certificates.


Q: Can I use CRAM-MD5 authentication?
Q: Can I use APOP authentication?
A: CRAM-MD5 authentication is enabled in the IMAP and POP3 client code on
    all platforms.  Read md5.txt to learn how to set up CRAM-MD5 and APOP
    authentication on UNIX and NT servers.
   There is no support for APOP client authentication.


Q: Can I use RPOP authentication?
A: There is no support for RPOP authentication.


Q: Can I use Kerberos V5?
A: Yes.  imap-2000 supports client and server functionality on UNIX and 32-bit
    Windows.
   Kerberos V5 is supported by default in Windows 2000 builds:
     nmake -f makefile.w2k
   Other builds require that a third-party software package, MIT Kerberos, be
    installed on the system first.
   To build with Kerberos V5 on UNIX, include EXTRAAUTHENTICATORS=gss in the
    make command line, e.g.
     make lnp EXTRAAUTHENTICATORS=gss
   To build with Kerberos V5 on Windows 9x, Windows Millenium, and NT4, use
    the "makefile.ntk" file instead of "makefile.nt":
     nmake -f makefile.ntk


Q: Can I use Kerberos V4?
A: Kerberos V4 is not supported.  Kerberos V4 client-only contributed code
    is available as:
     ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z
   This is a patchkit which must be applied to the IMAP toolkit according
    to the instructions in the patchkit's README.  I can not promise that
    this code works.


Q: Can I use PAM for plaintext passwords?
A: On Linux systems, use the lnp port, e.g.
     make lnp
   On Solaris systems and other systems with defective PAM implementations,
    build with PASSWDTYPE=pmb, e.g.
     make sol PASSWDTYPE=pmb
   On all other systems, build with PASSWDTYPE=pam, e.g
     make foo PASSWDTYPE=pam
   If you build with PASSWDTYPE=pam and authentication does not work, try
    rebuilding (after a "make clean") with PASSWDTYPE=pmb.


Q: Can I use AFS for plaintext passwords?
A: Build with PASSWDTYPE=afs, e.g
     make sol PASSWDTYPE=afs


Q: Can I use DCE for plaintext passwords?
A: Build with PASSWDTYPE=dce, e.g
     make sol PASSWDTYPE=dce


Q: Can I use the CRAM-MD5 database for plaintext passwords?
A: The CRAM-MD5 password database is automatically used for plaintext
    password if it exists.
   Note that this gives you the worst of both worlds -- plaintext passwords
    over the network and plaintext passwords stored on the server!  You
    probably don't want to do this unless all access is through SSL.  It
    is recommended that you disable plaintext passwords (see the next
    question).


Q: Can I disable plaintext passwords?
A: Server-level plaintext passwords can be disabled by setting
    PASSWDTYPE=nul, e.g.
     make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
   Note that you must have a CRAM-MD5 database installed or specify at least
    one EXTRAAUTHENTICATOR, otherwise it will not be possible to log in to
    the server.
   When plaintext passwords are disabled, the IMAP server will advertise
    the LOGINDISABLED capability and the POP3 server will not advertise
    the USER capability.


Q: Can I use virtual hosts?
A: Yes, with certain restrictions.
   The most important one is that each virtual host must have its own IP
    address; otherwise the server has no way of knowing which virtual
    host is desired.
   As distributed, the software uses a global password file; hence user
    "fred" on one virtual host is "fred" on all virtual hosts.  You may
    want to modify the checkpw() routine to implement some other policy
    (e.g. separate password files).
   Note that the security model assumes that all users have their own
    unique UNIX UID number.  So if you use separate password files you
    should make certain that the UID numbers do not overlap between
    different files.


Q: Is there support for S/Key or OTP?
A: There is currently no support for S/Key or OTP.  There may be an OTP
    SASL authenticator available from third parties.


Q: Is there support for NTLM or SPA?
A: There is currently no support for NTLM or SPA, nor are there any plans
    to add such support.  In general, we avoid vendor-specific mechanisms.
    We also believe that these mechanisms are being deprecated by their
    vendor.


Q: Is there support for mh?
A: Yes, but only as a legacy format.  Your mh format INBOX is accessed by
    the name "#mhinbox", and all other mh format mailboxes are accessed by
    prefixing "#mh/" to the name, e.g. "#mh/foo".  The mh support uses the
    "Path:" entry in your .mh_profile file to identify the root directory
    of your mh format mailboxes.
   Non-legacy use of mh format is not encouraged.  There is no support for
    permanent flags or unique identifiers; furthermore there are known
    severe performance problems with the mh format.


Q: Is there support for qmail and the maildir format?
A: There is no support for qmail or the maildir format in our distribution,
    nor are there any plans to add such support.  There may be maildir
    support available from third parties.

OPERATIONAL QUESTIONS:

Q: How can I enable anonymous IMAP logins?
A: Create the file /etc/anonymous.newsgroups.  At the present time, this
    file should be empty.  This will permit IMAP logins as anonymous as
    well as the ANONYMOUS SASL authenticator.  Anonymous users have access
    to mailboxes in the #news., #ftp/, and #public/ namespaces only.


Q: How do I set up an alert message that each IMAP user will see?
A: Create the file /etc/imapd.alert with the text of the message.  This
    text should be kept to one line if possible.  Note that this will
    cause an alert to every IMAP user every time they initiate an IMAP
    session, so it should only be used for critical messages.

SECURITY QUESTIONS:

Q: I've heard that IMAP servers are insecure.  Is this true?
A: There are no known security problems in this version of the IMAP
    toolkit, including the IMAP and POP servers.  The IMAP and POP
    servers limit what can be done while not logged in, and as part of
    the login process discard all privileges except those of the user.
   As with other software packages, there have been buffer overflow
    vulnerabilities in past versions.  All known problems of this nature
    are fixed in this version.
   There is every reason to believe that the bad guys are engaged in an
    ongoing effort to find vulnerabilities in the IMAP toolkit.  Judging
    from CERT reports, they've had much greater success in other software.
    We look for such problems ourselves, and when we find one we fix it.
   We are unhappy that any vulnerabilities existed in past versions, and
    we're doing our best to keep the IMAP toolkit free of vulnerabilities.
   Beware of vendors who claim that their implementations can not have
    vulnerabilities.  Any vendor who claims this is either naive or lying.


Q: Those /tmp lock files are protected 666, is that really right?
A: Yes.  Shared mailboxes won't work otherwise.  Also, you get into
    accidental denial of service problems (see the previous FAQs)
    with old lock files left lying around; this happens fairly
    frequently.
   The deliberate mischief that can be caused by fiddling with the
    lock files is small-scale; harassment level at most.  There are
    many -- and much more effective -- other ways of harassing another
    user on UNIX.  It's usually not difficult to determine the culprit.
   Before worrying about deliberate mischief, worry first about things
    happening by accident!

PROBLEMS AND ANNOYANCES:

Q: Why does mail disappear even though I set "keep mail on server"?
Q: Why do I get the message
     Moved ##### bytes of new mail to /home/user/mbox from /var/spool/mail/mbox
    and why did this happen?
A: This is probably caused by the mbox driver.  If the file "mbox" exists on
    the user's home directory and is in UNIX mailbox format, then when INBOX
    is opened this file will be selected as INBOX instead of the mail spool
    file.  Messages will be automatically transferred from the mail spool file
    into the mbox file.
   To disable this behavior, delete "mbox" from the EXTRADRIVERS list in the
    top-level Makefile and rebuild.  Note that if you do this, users won't
    be able to access the messages that have already been moved to mbox
    unless they open mbox instead of INBOX.


Q: Why isn't it showing the local host name as a fully-qualified domain
    name?
Q: Why is the local host name in the From/Sender/Message-ID headers of
    outgoing mail not coming out as a fully-qualified domain name?
A: Your UNIX system is misconfigured.  The entry for your system in
    /etc/hosts must have the fully-qualified domain name first, e.g.
	105.69.1.234	bombastic.blurdybloop.com bombastic
   A common mistake of novice system administrators is to have the
    short name first, e.g.
	105.69.1.234	bombastic bombastic.blurdybloop.com
    or to omit the fully qualified domain name entirely, e.g.
	105.69.1.234	bombastic
   The result of this is that when the IMAP toolkit does a gethostbyname()
    call to get the fully-qualified domain name, it would get "bombastic"
    instead of "bombastic.blurdybloop.com".
   On some systems, a configuration file (typically named /etc/svc.conf,
    /etc/netsvc.conf, or /etc/nsswitch.conf) can be used to configure the
    system to use the domain name system (DNS) instead of /etc/hosts, so
    it doesn't matter if /etc/hosts is misconfigured.
   Check the man pages for gethostbyname, hosts, svc, and/or netsvc for
    more information.
   Unfortunately, certain vendors, most notably SUN, have failed to
    make this clear in their documentation.  Most of SUN's documentation
    assumes a corporate network that is not connected to the Internet.
   net.folklore once (late 1980s) held that the proper procedure was to
    append the results of getdomainname(), and some versions of sendmail
    configuration files were distributed that did this.  This was
    incorrect; the string returned from getdomainname() is the Yellow
    Pages (a.k.a NIS) domain name, which is a completely different
    (albeit unfortunately named) entity from an Internet domain.  These
    were often fortuitously the same string, except when they weren't.
    Frequently, domain names would be spuriously doubled, e.g.
    "bombastic.blurdybloop.com.blurdybloop.com".  This practice has been
    thoroughly discredited for many years, but folklore dies hard.


Q: What does the message:
     Mailbox vulnerable - directory /var/spool/mail must have 1777 protection
    mean?  How can I fix this?
A: In order to update a mailbox in the default UNIX format, it is necessary
    to create a lock file to prevent the mailer from delivering mail while
    an update is in progress.  Some systems use a directory protection of
    775, requiring that all mail handling programs be setgid mail; or of
    755, requiring that all mail handling programs be setuid root.
   The IMAP toolkit does not run with any special privileges, and we plan
    to keep it that way.  It is antithetical to the concept of a toolkit
    if users can't write their own programs to use it.  Also, we've had
    enough bad experiences with security bugs while running privileged;
    the IMAP and POP servers have to be root when not logged in, in order
    to be able to log themselves in.  We don't want to go any deeper down
    that slippery slope.
   Directory protection 1777 is secure enough on most well-managed systems.
    If you can't trust your users with a 1777 mail spool (petty harassment
    is about the limit of the abuse exposure), then you have much worse
    problems then that.
   If you absolutely insist upon requiring privileges to create a lock file,
    external file locking can be done via a setgid mail program named
    /etc/mlock (this is defined by LOCKPGM in the c-client Makefile).  If
    the toolkit is unable to create a <mailbox>.lock file in the directory
    by itself, it will try to call mlock to do it.  We do not recommend
    doing this for performance reasons.
   A sample mlock program is part of the imap-utils package:
     ftp://ftp.cac.washington.edu/mail/imap-utils.tar.Z
    We have tried to make this sample program reasonably secure, but it
    has not been thoroughly audited.


Q: What does the message:
     Mailbox is open by another process, access is readonly
    mean?
A: A problem occurred in applying a lock to a /tmp lock file.  Either some
    other program has the mailbox open and won't relenquish it, or
    something is wrong with the protection of /tmp or the lock.


Q: What does the message:
     Can't get write access to mailbox, access is readonly
    mean?
A: The mailbox file is write-protected against you.


Q: What does the syslog message:
     imap/tcp server failing (looping)
    mean?  When it happens, IMAP service shuts down.  How can I fix this?
Q: What does the syslog message:
     pop3/tcp server failing (looping)
    mean?  When it happens, POP3 service shuts down.  How can I fix this?
A: The error message "server failing (looping), service terminated" is not
    from either the IMAP or POP servers.  Instead, it comes from inetd, the
    daemon which listens for TCP connections to a number of servers,
    including the IMAP and POP servers.
   inetd has a limit of 40 new server sessions per minute for any particular
    service.  If more than 40 sessions are initiated in a minute, inetd will
    issue the "failing (looping), service terminated" message and shut
    down the service for 10 minutes. 
   For larger server systems, the limit of 40 is much too low.  The limit was
    established many years ago when a system typically only ran a few dozen
    servers.
   On some versions of inetd, such as the one distributed with most versions
    of Linux, you can modify the /etc/inetd.conf file to have a larger number
    of servers by appending a colon followed by a number after the "nowait"
    word for the server entry.  For example, if your existing /etc/inetd.conf
    line reads:
     imap    stream  tcp     nowait  root    /usr/etc/imapd imapd
    try changing it to be:
     imap    stream  tcp     nowait:100  root    /usr/etc/imapd imapd
    Another example (using TCP wrappers):
     imap    stream  tcp     nowait  root    /usr/sbin/tcpd  imapd
    try changing it to be:
     imap    stream  tcp     nowait:100  root    /usr/sbin/tcpd  imapd
    to increase the limit to 100 sessions/minute.
   Before making this change, please read the information in "man inetd" to
    determine whether or not your inetd has this feature.  If it does not, and
    you make this change, the likely outcome is that you will disable IMAP
    service entirely.
  Another way to fix this problem is to edit the inetd.c source code
   (provided by your UNIX system vendor) to set higher limits, rebuild inetd,
   install the new binary, and reboot your system.  This should only be done
   by a UNIX system expert.  In the inetd.c source code, the limits TOOMANY
   (normally 40) is the maximum number of new server sessions permitted per
   minute, and RETRYTIME (normally 600) is the number of seconds inetd will
   shut down the server after it exceeds TOOMANY.


Q: What does the syslog message:
     Mailbox lock file /tmp/.600.1df3 open failure: Permission denied
    mean?
A: This usually means that some "helpful" person has protected /tmp so
    that it is no longer world-writeable.  /tmp must be world-writeable
    because lots of applications use it for scratch space.  To fix this,
    do "chmod 1777 /tmp" as root.
   If that isn't the answer, check the protection of the named file.  If
    it is something other than 666, then either someone is hacking or
    some "helpful" person modified the code to have a different default
    lock file protection.


Q: What do the syslog messages:
     Command stream end of file, while reading line user=... host=...
     Command stream end of file, while reading char user=... host=...
     Command stream end of file, while writing text user=... host=...
    mean?
A: This message occurs when the session is disconnected without a proper
    LOGOUT (IMAP) or QUIT (POP) command being received by the server first.
   In many cases, this is perfectly normal; many client implementations
    are impolite and do this.  Some programmers think this sort of rudeness
    is "more efficient".
   The condition could, however, indicate a client or network connectivity
    problem.  The server has no way of knowing whether there's a problem or
    just a rude client, so it issues this message instead of a Logout.
   If the user isn't reporting a problem, you can probably ignore this
    message.


Q: What does the syslog message:
     Killed (lost mailbox lock) user=... host=...
    mean?
A: This message only happens when either the traditional UNIX mailbox format
    or MMDF format is in use.  This format only allows one session to have
    the mailbox open read/write at a time.
   The servers assume that if a second session attempts to open the mailbox,
    that means that the first session is probably owned by an abandoned client.
    The common scenario here is a user who leaves his client running at the
    office, and then tries to read his mail from home.  Through an internal
    mechanism called "kiss of death", the second session requests the first
    session to kill itself.  When the first session receives this "kiss of
    death", it issues the "Killed (lost mailbox lock)" syslog message and
    terminates.  The second session then seizes read/write access, and becomes
    the new "first" session.
   Certain poorly-designed clients routinely open multiple sessions to the
    same mailbox; the users of those clients tend to get this message a lot.
   Another cause of this message is a background "check for new mail" task
    which does its work by opening a POP session to server every few seconds.
    They do this because POP doesn't have a way to announce new mail.
   The solution to both situations is to replace the client with a good
    online IMAP client such as Pine.  Life is too short to waste on POP
    clients and poorly-designed IMAP clients.


Q: Why does my IMAP client show all of my files, recursively from my UNIX
    home directory?
A: By default, you are connected to your home directory.  Most clients have
    an option to configure your connected directory on the IMAP server.  In
    Pine, you specify this as the "Path" in your folder-collection, e.g.
     Nickname  : Secondary Folders
     Server    : imap.blurdybloop.com
     Path      : mail/
     View      : 
    In this example, the user is connected to the "mail" subdirectory of
    his home directory.
   Other servers call this the "folder prefix" or similar term.
   It is possible to modify the IMAP server so that all users are
    automatically connected to some other directory, e.g. a subdirectory
    of the user's home directory.  Read the file CONFIG for more details.


Q: Why does my client show that I have mailboxes named "#mhinbox", "#mh",
    "#shared", "#ftp", "#news", and "#public"?
A: These are IMAP namespace names.  They represent other hierarchies in
    which messages may exist.  These hierarchies may not necessarily exist
    on a server, but the namespace name is still in the namespace list in
    order to mark it as reserved.
   A few poorly-designed clients display all namespace names as if they
    were top-level mailboxes in a user's list of mailboxes, whether or
    not they actually exist.  This is a flaw in those clients.


Q: Why does my IMAP client show all my files in my home directory?
A: As distributed, the IMAP server is connected to your home directory by
    default.  It has no way of knowing what you might call "mail" as
    opposed to "some other file"; in fact, you can use IMAP to access any
    file.
   It is possible to modify the software so that the default connected
    directory is someplace else.  Please read the file CONFIG for
    discussion of this and other issues.


Q: Why is there a long delay in mail_open() before I get connected to the
    IMAP server?
A: By default, the c-client library attempts to make a connection through
    rsh (and ssh, if you enable that).  If the command:
     rsh imapserver exec /etc/rimapd
    (or ssh if that is enabled) returns with a "* PREAUTH" response, it
    will use the resulting rsh session as the IMAP session and not require
    an authentication step on the server.
   Unfortunately, rsh has a design error that treats "TCP connection
    refused" as "temporary failure, try again"; it expects the "rsh not
    allowed" case to be implemented as a successful connection followed
    by an error message and close the connection.
   It must be emphasized that this is a bug in rsh.  It is NOT a bug in the
    IMAP toolkit.
   The use of rsh can be disabled in any the following ways:
    (1) You can disable it for this particular session by either:
	(a) setting an explicit port number in the mailbox name, e.g.
	    {imapserver.foo.com:143}INBOX
	(b) using SSL (the /ssl switch)
    (2) You can disable it globally by setting the rsh timeout value to 0
	with the call: mail_parameters (NIL,SET_RSHTIMEOUT,0);


Q: Why does a message sometimes get split into two or more messages on my
    SUN system?
A: This is caused by an interaction of two independent design problems in
    SUN mail software.  The first problem is that the "forward message"
    option in SUN's "mail tool" program includes the internal "From "
    header line in the text that it forwarded.  This internal header line
    is specific to traditional UNIX mailbox files and is not suitable for
    use in forwarded messages.
   The second problem is that the mail delivery agent assumes that mail
    reading problems will not use the traditional UNIX mailbox format but
    instead an incompatible variant that depends upon a "Content-Length:"
    message header.
   Content-Length is widely recognized to have been a terrible mistake,
    and is no longer recommended for use anywhere.
   One symptom of the problem is that under certain circumstances, a
    message may get broken up into several messages.
   I'm also aware of security bugs caused by programs that foolishly
    trust "Content-Length:" headers with evil values.
   To fix the mailer on your system, edit your sendmail.cf to change the
    Mlocal line to have the -E flag.  A typical entry will lool like:
	Mlocal,	P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20,
		A=mail.local -d $u
   This fix will also work around the problem with "mail tool", because
    it will insert a ">" before the internal header line to prevent it
    from being interpreted by mail reading software as an internal header
    line.


Q: Why did my IMAP session suddenly disconnect?  The syslog has the message:
     Autologout user=<...my user name...> host=<...my imap server...>
A: This is a bug in your IMAP client.  It failed to communicate with the
    IMAP server for over 30 minutes.


Q: Why does reading certain messages hang when using Netscape?  It works
    fine with Pine!
A: There are two possible causes.
   Check the mail syslog.  If you see the message "Killed (lost mailbox
    lock)" for the impacted user(s), read the FAQ entry regarding this
     message.
   Check the affected mailbox to see if there are embedded NUL characters
    in the message.  NULs in message texts are a technical violation of both
    the message format and IMAP specifications.  Most clients don't care, but
    apparently Netscape does.  You can work around this by rebuilding imapd
    with the NETSCAPE_BRAIN_DAMAGE option set (see src/imapd/Makefile); this
    will cause imapd to convert all NULs to 0x80 characters.  A better
    solution is to enable the feature in your MTA to MIME-convert messages
    with binary content.  See the documentation for your MTA for how to do
    this.


Q: Why does Netscape say that there's a problem with the IMAP server and that
    I should "Contact your mail server administrator."?
A: Certain versions of Netscape do this when you click the Manage Mail button,
    which uses an undocumented feature of Netscape's proprietary IMAP server.
    You can work around this by rebuilding imapd with the
    NETSCAPE_BRAIN_DAMAGE option set (see src/imapd/Makefile) to a URL that
    points either to an alternative IMAP client (e.g. Pine) or perhaps to a
    homebrew mail account management page.

WHERE TO GO FOR ADDITIONAL INFORMATION:

Q: Where can I read more about IMAP and other email protocols?
A: I recommend "Internet Email Protocols: A Developer's Guide", by Kevin
    Johnson, published by Addison Wesley, ISBN 0-201-43288-9.


Q: Where can I find out more about setting up and administering an IMAP
    server?
A: I recommend "Managing IMAP", by Dianna Mullet & Kevin Mullet, published
    by O'Reilly, ISBN 0-596-00012-X.
