This is a beginning of a modest FAQ. Contributors:
[PP] - Patrick Price
    <sysadmin@moment.net>[RS] - Roland Schneider
    <list-courier@serv.ch>Table of contents:
configure script
        is stuck in an infinite loopgdbmobj or
        bdbobj subdirectory.make install-strip or
        make check failsgmake check fails on
        Compaq Tru64 UNIX450 Service unavailable error every
        time.configure script is stuck in an infinite
  loopA: It's not. The Courier mail server is made up of
  over thirty modular pieces, and each one has its own
  configure script. All configure scripts
  are recursively executed. configure scripts are
  generated off a template, and share a lot of common code, so when
  configure runs, it seems like the same script is
  being executed over and over again.
A: The authentication library used by the Courier mail server (and the Courier mail server-IMAP, and SqWebMail) is probably the most thorniest part of the package. Some people just breeze through authentication module configuration, others just have one problem after another. There is no single point at which people get stuck. Any one of a set of problems can materialize and brings things to a halt. This FAQ entries explains the authentication modules in greater detail. The information given here should be sufficient to get everything in working order.
The authentication modules serve three purposes:
The authentication modules are generally used in one of two ways:
A. When delivering an E-mail message, The Courier mail server uses functions #1 and #3 to figure out where the mail needs to go.
B. When the owner of the mail account logs in to read the mail, functions #1, #2, and #3 are used to open the mail account (this is all provided that maildirs are used, since the Courier mail server's IMAP, POP3, and webmail servers talk to maildirs only).
The authentication library therefore provides an
  authentication layer that cleanly separates the vague notion of
  an "E-mail address" and the actual files and directories where
  mail for this account goes. The Courier mail server
  provides several authentication modules. Not every authentication
  module will be compiled and installed on every system. Some
  authentication modules require external libraries to be present.
  The configure script inventories the system
  configuration, and tries to figure out which authentication
  modules are needed.
Usually, this is an automatic process. Occasionally, some manual intervention will be necessary.
authpwd, authshadow, and
  authpamThese three authentication modules are used in the most simple
  environment - authentication based on the system password file.
  They use the traditional pwd.h and
  group.h library functions. Mail to
  <user@domain> is delivered to the system
  account user, in the default mailbox location
  specified in the courierd configuration file. The
  IMAP, POP3, and webmail servers assume that default mailbox is
  $HOME/Maildir. The only difference between these
  three authentication modules is that authpwd reads
  the account password from the /etc/passwd file,
  authshadow reads the /etc/shadow file,
  and authpam uses the PAM library to authenticate
  passwords. This actually allows account passwords to be read from
  sources other than the passwd or shadow
  files. For example, if the pam_smb PAM module is
  used, it may be possible to authenticate passwords against an NT
  domain controller, but this is really outside the scope of this
  document.
If the configure finds that the system uses
  PAM for authentication, authpam will be
  automatically installed, and authpwd and
  authshadow will NOT be installed. This is because
  reading the passwd and shadow files is
  not recommended when PAM is used for authentication, since the
  passwd and shadow files may be (as an
  example) simply a text dump of the real account database, which
  is stored elsewhere.
NOTE: PAM is only used for authenticating password. The
  authpam module still uses the pwd.h and
  group.h library to find the account's home directory
  and mailbox.
authuserdb/authcramThis is a poor man's virtual mail account implementation. The
  authuserdb module is accompanied by a set of Perl
  scripts that are used to map arbitrary E-mail addresses to
  arbitrary make-believe "home directories" and mailboxes. The
  authuserdb module is a convenient way to implement a
  comparatively small number of mail accounts without bothering to
  create real system accounts, or using a more complicated LDAP or
  MySQL-based account database.
The E-mail addresses, the location of the corresponding
  mailboxes, and other miscellaneous information is kept in a set
  of plain text files. A couple of Perl scripts are provided to
  conveniently enter and edit the contents of the
  userdb text files, and compile them into a binary
  database format that's used directly to deliver to/read the
  mailbox for the corresponding E-mail address.
userdb is loosely based on the traditional
  passwd/shadow files. There are two binary database files, one
  world readable, the other not (that one contains just the
  passwords). Each "mail account" has the usual properties defined
  in the userdb database: name, "home directory", uid,
  gid, and password. This is basically an equivalent to the
  traditional passwd file, except that an efficient
  binary database format is used to search it.
All the traditional account properties - the uid and the gid -
  are present, that doesn't mean that every userdb
  account has to have unique properties. The most typical
  environment allocates a single uid/gid for all mail accounts, and
  creates all mail accounts with the same uid/gid, but different
  pseudo-homedirs and mailboxes.
The userdb database contains a couple of other
  fields that are not found in the traditional passwd
  file. The mail field specifies a non-default
  location of the mailbox for the account, and overrides the
  assumed default of $HOME/Maildir. The quota field is
  used for "Maildir quotas", a loosely-implemented cap on the
  maximum size of the given maildir. The usage of maildir quotas is
  described in the INSTALL file.
userdb records may include other arbitrary fields
  too. The Courier mail server will simply ignore them.
  They can be used to conveniently store system-specific custom
  information.
The authuserdb module is designed to handle up to
  a couple of thousand mail accounts. Beyond that, more
  "heavyweight" modules should be used, such as
  authldap and authmysql. Although the
  binary userdb database is rather quick, creating the
  binary database from the original plain text files is a
  comparatively slow process, and it must be done every time any
  changes are made to the userdb files. The conversion
  from text to binary is done by a couple of Perl scripts. Perl is
  an interpreted language, and is comparatively slow.
  userdb is not meant to handle huge lists of
  accounts, so no attempt has been made to optimize the whole
  process.
authldap, and authmysqlThese two modules are used to store all account information in
  an LDAP directory or a MySQL server. Except for the actual
  back-end, these two modules have similar functionality. Both of
  them have a corresponding configuration file which defines where
  the server is, and the name of the fields where the requisite
  information can be found. The configure script will
  automatically add these modules if it finds the requisite
  development libraries: OpenLDAP development libraries or MySQL
  development libraries.
Note that it is not sufficient to have just the runtime
  support libraries available, in order to compile
  authldap or authmysql. Some operating
  system distributions provide separate "runtime" and "development"
  packages for OpenLDAP and MySQL. The "development" package will
  contain the necessary files to compile authldap and
  authmysql. Once compiled, the modules can be
  installed on any server that contains only the runtime support
  files.
Normally, if the configure scripts detects that
  the development libraries is installed, the appropriate module
  will be automatically compiled and installed. However, for an
  external library to be detected, it must be installed wherever
  the C or the C++ compiler looks for libraries.
The Courier mail server relies on the C or the C++
  compiler to detect the availability of a particular library.
  Example: if OpenSSL is installed in the directory
  /usr/local/ssl chances are that the C or the C++
  compiler does not usually search this directory for libraries or
  include files. Most C and C++ compilers search only the
  directories /lib, /usr/lib, and
  /usr/include (for include files).
All C and C++ compilers allow you to specify any additional
  directories to search, beside the default ones. The configuration
  script uses the environment variables CPPFLAGS,
  CFLAGS, and LDFLAGS to pass extra
  options to the compiler's preprocessor, the compiler itself, and
  the linker.
For example, if OpenSSL's include files are installed in the
  directory /usr/local/ssl/include, and OpenSSL
  libraries are installed in /usr/local/ssl/lib, the
  gcc compiler needs to have the
  -I/usr/local/ssl/include option for the
  preprocessor, and the -L/usr/local/ssl/lib option
  for the linker. So, to have the configuration script detect
  OpenSSL, use the following commands:
CPPFLAGS="-I/usr/local/ssl/include" LDFLAGS="-L/usr/local/ssl/lib" export CPPFLAGS export LDFLAGS ./configure [ options ]
The same applies for OpenLDAP, MySQL, and any other library. The configuration script does not maintain a list of all the non-standard locations where various libraries get installed by default, because that's subject to change at any time. The configuration script expects that the compiler can find the development files by itself.
authcustomThis is a dummy authentication modules, it doesn't do anything. It is a placeholder to insert custom authentication code.
authdaemonauthdaemon is a "metamodule". It is not a real
  authentication modules, but acts like one. When
  authdaemon is selected, the authlib
  authentication library compiles all the other authentication
  modules into a separate program, authdaemond, that
  runs as the background process. The authdaemon
  module receives all authentication requets, and forwards them to
  the authdaemond.
This approach is used to optimize database-driven modules such
  as authldap or authmysql. When invoked
  separately, authldap must log in to the server,
  process the authentication requests, then disconnect. Lather,
  rinse, repeat.
As part of the permanent authdaemond background
  process, these modules log in to the database server, and
  maintain a persistent long-running process, which is used to
  process a stream of authentication requests. The configuration
  file for the authdaemond process specifies the
  number of authdaemond processes that will be
  started. This allows the Courier mail server to handle
  heavy volumes of authentication requests.
It is possible to have more than one authentication module
  configured. For example, using authpam to
  authenticate system accounts, and authuserdb to
  authenticate virtual mail accounts. The configure
  script inventories the system configuration and will often pick
  several authentication modules that can be used with the existing
  system configuration.
There are two ways to disable unwanted authentication modules.
  The configure option
  --without-name disables module
  name. Another way is to simply disable the
  authentication module at runtime. The configuration file for the
  main the Courier mail server, the IMAP, POP3, and
  webmail servers specifies which authentication modules the
  servers use. When authdaemon is installed, the
  authdaemond configuration file lists the active
  authentication modules. Removing the name of the authentication
  module from the list will effectively disable it.
A: The Courier mail server requires either the GDBM library or the Berkeley DB library to be installed. If you have the library installed, it is possible that it is installed in a non-standard location. See "Q: I have OpenLDAP, or OpenSSL, or MySQL installed" for how to resolve this situation.
gdbmobj or
  bdbobj subdirectory.A: There are two possible causes of this error:
Another possible reason for this error is that the GDBM or the Berkeley DB library is not installed in a directory that is searched by the C and C++ compilers, by default. See "Q: I have OpenLDAP, or OpenSSL, or MySQL installed" for how to resolve this situation.
A: If you have libgdbm.so installed in
  /usr/local/lib and gdbm.h installed in
  /usr/local/include, it's possible that your compiler
  doesn't search those directories. Reconfigure your compiler to
  search those directories by default. Try setting
  CPPFLAGS and LDFLAGS when running
  configure:
CPPFLAGS="-I /usr/local/include" \ LDFLAGS="-L /usr/local/lib" ./configure [options]
It is also possible that libgdbm.so is not found
  at runtime because your dynamic linker doesn't search
  /usr/local/lib either. You will have to reconfigure
  your dynamic linker.
An alternative solution is to install soft links in
  /usr/lib and /usr/include to point to
  the GDBM library.
A: Use --with-waitfunc=wait3 option to configure.
  A better solution is to pester Sun to fix their kernel. Using
  this option is just a bandaid solution, and you might still
  experience runtime problems with zombie processes not being
  reaped, etc... One person reported that installing the fix for
  bug "4220394 wait3 library function fails after 248
  days" fixes this problem, someone else claimed that this
  continues to happen even after installing this patch.
Set the RANLIB environment variable before running the
  configure script, as follows:
RANLIB="ranlib -c" export RANLIB ./configure [ options ]
make
  install-strip failsUse make install instead.
make check failsUse the GNU make.
make check will fail if
  --enable-workarounds-for-imap-client-bugs option is
  selected. It's not a bug, it's a feature.
gmake check fails
  on Compaq Tru64 UNIXA: A patchkit for Tru64 5.x that fixes this problem is scheduled to be released by Compaq in early spring 2002. Tru64 4.x is not affected by this problem.
A: On current vesions of Fedora, building installable RPM packages is as simple as executing::
    rpmbuild -ta courier-version.tar.bz2
  This will eventually create source and binary RPM packages. This works for all Courier packages. You may need to install some development packages first, before building RPMs. If you don't have the required packages installed, RPM will tell you what you're missing. Install the required packages, and try again.
Building the RPMs directly from the source tarball uses the default options programmed into the tarball. Sometimes you may want to use different options. For example, you might want to enable fixes for certain bugs in some IMAP clients. Use the following procedure to build the RPMs with different options:
rpmbuild
    will create a source RPM package (filename.src.rpm)rpm -i
    courier-version.src.rpm.$HOME/rpm/package.rpmbuild -ba
    filename.specSeveral things happen when the Courier mail server receives a connection on the SMTP port 25. Sometimes those things take an excessively long time to complete, and it seems that the Courier mail server answers port 25 connections after a long delay.
This usually happens for all connections to port 25, but it's usually noticed when trying to send mail using a mail client that's set up to use a the Courier mail server server as a mail relay. Connections from other mail servers may experience similar delays, but they are less likely to be noticed. It's hard to ignore a mail client that does nothing, when it's commanded to send a message.
When a new connection is received on port 25, with the default configuration the Courier mail server performs the following checks:
The results obtained from these queries will be recorded in
  the Received: header of any message received from
  the connecting IP address.
A non-responding DNS server may result in lengthy connection delays, as the DNS query times out (which may take several minutes). A non-responding server for the connecting IP address's netblock will probably not be a major problem, since the intermediate DNS resolvers should quickly failover to any functioning backup authoritative servers for the connecting IP address, or its hostname. A bigger problem is when the local DNS resolver, listed in /etc/resolv.conf goes down. This will result in a certain percentage of all incoming connections experiencing major delays.
A local, or an intermediate firewall may also drop IDENT packets. IDENT is a fairly old protocol whose original purpose is to identify individual users of a shared network server. Some proxies may also use IDENT to identify the original source of a proxied connection. However, since IDENT is an old, and not a very well known protocol, some poorly-written firewalls may not recognize the protocol, and bit-bucket IDENT connection requests. An IDENT request times out after 30 seconds.
When investigating connection delays:
/etc/resolv.conf.
    NOTE: The Courier mail server does
    not read the hosts file. It needs a DNS server
    (although it is possible to have a working the Courier
    mail server configuration in a completely DNS-free environment,
    this excersize requires changing many configuration files, and
    perhaps will be its own FAQ entry some day).As a last resort, both of these lookups can be turned off. Add
  the -nodnslookup and -noidentlookup
  options to TCPDOPTS, in the esmtpd configuration file (usually
  /usr/lib/courier/etc/esmtpd). Example:
TCPDOPTS="-nodnslookup -noidentlookup"
There'll probably be an existing TCPDOPTS setting in there. Add the whitespace-delimited options to anything that's already in there.
NOTE: This should only be done as a last resort, if there are no options left. The information gathered by the queries may prove to be essential in investigating high-level mail delivery-related issues. If a realization hits that the DNS or IDENT information is needed to track down a particular piece of mail, it'll be already too late. It should've been there right from the start.
MX records for $domain violate section 3.3.9 of RFC 1035or
This domain's DNS violates RFC 1035.
[PP] Cause: Invalid DNS MX Records for that
  domain
Solution: Contact sysadmin for that domain and advise to fix their DNS.
A common problem appears to be that an MX record will point to an IP address rather than a domain name (FQDN) as follows:
INCORRECT MX RECORD:
domain.com preference = 20, mail exchanger = 192.68.0.10
CORRECT MX RECORD:
domain.com preference = 20, mail exchanger = mail.domain.com
Temporary Solution: Put the offending domain into the
  esmtproutes file and point it to that domain's mail
  exchanger host. Doing so bypasses checking the domains MX or A
  records and mail is sent directly to the relay specified in
  esmtproutes. Reference: man courier(8).
    517 Syntax error - your mail software violates RFC
    821.
  
  [PP] Cause: Most often generated by WinCE gizmos.
  Several reasons, most common missing required <>
  surrounding the MAIL FROM: or RCPT TO: verbs
[SV] This problem is apparently present in the
  Microsoft Outlook client too. See item #7 in 
  http://support.microsoft.com/support/kb/articles/Q180/4/84.ASP.
  Note: contrary to the information in that article, this address
  specification format is REQUIRED by RFC 821, and
  Microsoft is simply ignoring another Internet standard, here.
[PP] Solution: The usual solution for a 517 is to
  tell people to explicitly put <> around all E-mail
  addresses. That is, program their WinCE gizmo to believe that
  their return address is "<user@domain.com>" instead of
  "user@domain.com", and have them enter each recipient's address
  in a similar way.
Mail received by the received is replaced by the following text, with the original message attached.
I received the following message for delivery to your address. Unfortunately, the sender's mail software did not properly format the following message properly, in accordance with Internet mail formatting protocols, and I can only deliver mail which has been properly formatted according to Internet standards. Instead of returning the following message as undeliverable, it is saved, in its original form, in the following attachment, which you can open with any editor or word processor.
[PP] [Sam] Cause: Various bugs in poorly written
  software that generates invalid MIME-formatted messages. Previous
  versions of the Courier mail server used to
  automatically return mis-formatted mail as undeliverable.
  Starting with version 0.36.1, mis-formatted mail is replaced by
  this canned message text, and the original message is attached as
  plain text.
Solution: for now, manually edit
  SubmitFile::MessageEnd() in
  courier/submit2.C, and remove the code that reports
  both 8-bit related errors, RFC2045_ERR8BITHEADER and
  RFC2045_ERR8BITCONTENT (the first and the third
  error message).
This will suppress the error and accept the garbage mail, but expect random mail access problems. Certain versions of Outlook have known bugs handling misformatted mail, so you're on your own.
NOTE: Do not remove the code that reports RFC2045_ERR2COMPLEX, this error indicates a denial-of-service attack.
NOTE: Removing the check for RFC2045_ERRBADBOUNDARY suppresses the second error message, however think long and hard before you do this. You are virtually guaranteed to end up with corrupted MIME mail if this check is removed!
450 Service unavailable error every
  time.authdaemon, and the
    authdaemond process is not running.smtpaccess configuration subdirectory, then run
  makesmtpaccess. See makesmtpaccess(8) and couriertcpd(8). For example, to enable
  relaying for IP address 10.192.64.0 - 10.192.64.255, put the
  following into smtpaccess:
  10.192.64<TAB>allow,RELAYCLIENT"
<TAB>" is a single TAB character.
  There are literally a dozen different ways to do it. If you are comfortable with how virtual domains are implemented by Qmail, you can do something similar with the Courier mail server. If you are used to implementing virtual domains with sendmail, you'll be able to do something similar too. Additionally, you can use LDAP directories or MySQL databases to store your mail account configuration. Or, you can simply enter virtual account information in text files, and run a script to convert the text file database to a binary GDBM or DB database that the Courier mail server can use to map arbitrary mail addresses to home directories and mailboxes. In all cases, the same configuration is automatically shared by ESMTP, IMAP, POP3, and webmail components. They all use the same authentication back-end.
NOTE: in all cases you are still responsible for creating the home directories and/or mailboxes for each account, with the appropriate ownership and permissions. You will still need to do that in all cases.
The authuserdb authentication module is included
  by default. To use it, create a file or a subdirectory named
  userdb in the configuration directory (the default
  location is /usr/lib/courier/etc, but that may vary
  on your platform). If userdb is a subdirectory, the
  contents of files in that subdirectory are simply concatenated.
  Use the following commands to create a virtual account:
userdb john@example.com set home=/home/virtual/example.com/john \
             uid=999 gid=999
          
userdbpw | userdb john@example.com set systempw
  If userdb is a subdirectory instead of a file,
  replace "john@example.com" with
  "filename/john@example.com".
On systems that use MD5 password hashes, instead of crypt-ed
  passwords, specify the -md5 option to
  userdbpw.
The home directory of this virtual account must now be
  created, as well as its default system mailbox (usually
  $HOME/Maildir).
When a virtual account does not really have a home directory,
  just the system mailbox, set both the home and
  mail fields to the same pathname:
userdb john@example.com set home=/home/virtual/example.com/john \
             mail=/home/virtual/example.com/john \
             uid=999 gid=999
          
  In this case /home/virtual/example.com/john is
  the system mailbox.
Run the makeuserdb command to rebuild the
  userdb database.
Finally, example.com must be configured as a
  virtual domain. Edit the hosteddomains configuration
  file, add example.com to the file, then run
  makehosteddomains. See courier(8) for more information.
userdb can completely replace the functionality
  of the traditional /etc/passwd file. With a large
  passwd file, converting the flat text file to a fast database
  file can greatly improve performance. The pw2userdb
  script convert /etc/passwd to userdb
  format.
Append the following to the aliases configuration
  file:
@example.com: john
If aliases is a subdirectory, append this to any
  file in the subdirectory (or create a new one). In all cases, run
  makealiases for the change to take effect.
Mail to anything@example.com gets delivered to
  local address john-anything. The local
  john account may install dot-courier(5) delivery instructions for
  any particular anything address.
Append the following to the aliases configuration
  file:
john@example.com: john1
If aliases is a subdirectory, append this to any
  file in the subdirectory (or create a new one). In all cases, run
  makealiases for the change to take effect.
Mail to john@example.com will be delivered to the
  local account john1.
LDAP or MySQL back-endsVirtual domains can also be supported by storing the account
  information in an LDAP directory or a MySQL database. This is
  implemented by installing the authldap and
  authmysql authentication module.
It will be necessary to initialize hosteddomains,
  and run makehosteddomains in order to configure the
  Courier mail server to pass virtual domains to the local
  mail module. Additionally, authldap and
  authmysql come with their corresponding
  configuration files, authldaprc and
  authmysqlrc, that specify the gory details such as
  the location of the back-end server, and the name of the tables
  or records involved. Consult that configuration file for more
  information.
You are running an operating system kernel that's been altered with one of several nonstandard modifications that aim to improve system security by rejecting certain kinds of operating system calls. You will need to disable these non-standard patches. They completely modify the traditional file permission semantics, in the name of security. This breaks the Courier mail server, whose security model is based on traditional filesystem permissions.
To configure a the Courier mail server server as a
  backup MX, meaning that the Courier mail server receives
  mail for @domain.com, and forwards it to the primary
  MX server for domain.com when it becomes available (presumably
  the primary MX server is not available at this moment):
domain.com into the
    esmtpacceptmailfor configuration file (or the
    esmtpacceptmailfor.dir directory, then run
    makeacceptmailfor).domain.com's primary MX.
    Furthermore, the hostname in the MX record must be one of the
    hostnames in the locals configuration file. For
    example:
      domain.com MX 10 primary.domain.com domain.com MX 20 backupmx.domain.com primary.domain.com A 192.168.0.4 backupmx.domain.com A 192.168.0.5 # IP address of the backup MX server locals: backupmx.domain.com esmtpacceptmailfor: domain.com
domain.com: [192.168.0.4]
A: You can set the maximum number of recipients for a single email by adding the line:
maxrcpts number
to etc/bofh.
A: Both IMAP clients do not correctly implement certain parts
  of IMAP4rev1. Rerun configure, and use
  --enable-workarounds-for-imap-client-bugs option.
  Note that make check will fail when this option is used.
This is a configuration issue with your mail client. IMAP
  servers are free to use any folder namespace arrangement that's
  technically convenient for them. The Courier mail server
  uses "INBOX." as the namespace for private folders, and "shared."
  as the namespace for public, shared, folders. The IMAP NAMESPACE
  extension (see http://www.rfc-editor.org/rfc/rfc2342.txt)
  allows IMAP clients to automatically discover where the server
  creates folders, and your IMAP client should implement it.
This should be completely transparent to you, if your IMAP
  client properly uses the NAMESPACE extension. If
  your IMAP client were to automatically take advantage of
  self-configuration features offered by RFC 2060 and RFC 2342, it
  would automatically discover, without any additional
  configuration from the user, that:
INBOX." hierarchyshared." hierarchyIf you have to explicitly create folders that are subfolders
  of INBOX, or if you explicitly have to name that
  "INBOX.foldername", this is due to your IMAP client
  not being able to configure itself accordingly.
A: Correct. IMAP servers are free to define any root of the
  folder namespace tree that's convenient for them. The
  Courier mail server's IMAP server uses INBOX as the
  folder namespace root, rather than the root hierarchy itself. The
  Courier mail server supports the NAMESPACE
  IMAP extension which allows compliant IMAP clients to
  automatically configure themselves so that the folder namespace
  root is transparent. Submit an enhancement request to have your
  IMAP client gracefully handle the folder namespace root.
A: Check the following:
/etc/inetd.conf.imapd
    configuration file (usually
    /usr/lib/courier/etc/imapd).A: Check the following
AUTHMODULES in the imapd
    configuration file is correct.authdaemon authentication proxy is
    used, check the authdaemonrc configuration file.
    Check that authdaemond is running.authldap and authmysql). If you're
    using authpam, you need to configure your PAM
    library to authenticate the "imap" service. This is a
    separate task, and is specific to your PAM library and
    operating system.$HOME/Maildir), it doesn't support mailbox
    files.This means that the Courier mail server was compiled with File Alteration Monitor (FAM), but FAM is not running, or is not configured. If you have FAM installed you can add it to a runlevel and start it. Some FAM configuration use portmapper, so you will need to have portmap running also. You can also see "man 8 imapd" for more information.
A: This topic deserves its own web page. See http://www.courier-mta.org/fud/ for more information.
A: Check the following:
/etc/inetd.conf.pop3d
    configuration file (usually
    /usr/lib/courier/etc/pop3d).A: Check the following
AUTHMODULES in the pop3d
    configuration file is correct.authdaemon authentication proxy is
    used, check the authdaemonrc configuration file.
    Check that authdaemond is running.authldap and authmysql). If you're
    using authpam, you need to configure your PAM
    library to authenticate the "pop3" service. This is a
    separate task, and is specific to your PAM library and
    operating system.$HOME/Maildir), it doesn't support mailbox
    files.A: Write your own CGI script for this. Not everyone wants this ability, plus with all the different authentication module there are literally dozens of different ways accounts can be set up, and there's no way to provide a uniform interface for this purpose.
A: Mainly for the same reason, there's no uniform way to
  change system passwords, so the webmail server maintains its own
  passwords, which are initialized from the system password. You
  can reconfigure the Courier mail server with the
  --enable-webpass=no flag (see INSTALL), and lose the
  ability to change passwords in the webmail interface, so all
  password changes must now be done on the system level.
A: The courier-users (list archive) or the courier-imap (list archive) mailing list should be the first place to look for assistance with resolving any issues. You only need to observe a few simple rules in order to increase your chances of getting a quick and helpful response:
/var/log/messages).There are several ways to implement virtual mailboxes, to address different situations and environments. The simplest case involved simply redirecting certain mail addresses to a local mailbox:
user@domain.com: localuser
This entry in the aliases configuration file (run
  the makealiases script after editing
  aliases) causes mail for <user@domain.com> to
  be delivered to localuser, which must be an existing
  system account. If IMAP/POP3/Webmail access has been configured,
  it is necessary to log in as localuser to pick up
  this mail.
A slightly different syntax in aliases results in
  mail for an entire mail domain to be controlled by a local system
  account:
@domain.com: localuser
Here, any mail address <foo@domain.com> will be
  redirected to the local address <localuser-foo>. Note, the
  address is <localuser-foo>, not <localuser>. This
  means that the account owner <localuser> gets to control
  the mailboxes in this domain. In this case, the file
  $HOME/.courier-foo will control disposition of mail
  addressed to foo@domain.com. See the dot-courier(5) man page for more
  information. In this case, there is no default way to access mail
  to various mailboxes via IMAP/POP3/Webmail. If
  $HOME/.courier-default is used to deliver all mail
  for this domain to the default mailbox for the
  localuser account, mail can be read via
  IMAP/POP3/Webmail by loggin in as localuser.
The other way to implement virtual domains is by using a
  custom authentication back-end, such as LDAP, MySQL, and
  PostgreSQL, to explicitly administer virtual domains. The first
  step is to add domain.com to the
  hosteddomains configuration file, and run the
  makehosteddomains script. This tells the
  Courier mail server to deliver mail for this domain
  locally. The next step is to appropriately configure the
  authentication library, and define the valid mailboxes in this
  domain. See the authlib(8) man page
  for information on setting up the various authentication
  back-ends. The authentication back-ends that can support virtual
  domains are LDAP, MySQL, PostgreSQL, and userdb (also vchkpw, but
  that requires some external configuration).
Note that the Courier mail server does not automatically create the maildirs for virtual mail accounts. After setting up a virtual mail account it is still necessary to create and initialize the virtual home directory, and the virtual maildir directory, with the correct permission and ownership.
Most authentication modules require their own specific
  configuration files to be initialized. Most authentication
  modules also require that they be compiled into the
  authdaemon authentication proxy. This means that it
  will be necessary to arrange to have authdaemond
  started at system startup. See the authlib(8) man page for more information.
fetchmailSince the Courier mail server provides both IMAP and
  POP3 services, nothing unusual is required to download mail from
  a the Courier mail server-hosted mailbox, using either
  protocol. Here is a suggested fetchmail.rc
  configuration file to download mail from an external mail account
  into a local mailbox. For readability, some long lines below have
  been split across multiple lines, and they should be manually
  combined. Insert your account information in the appropriate
  place, and run fetchmail from the account's
  crontab:
    
### [RS]
        
### global options
# set logfile /relay/home/var/log/fetchmail
set syslog
# set idfile /root/.fetchids
set postmaster postmaster@hostname.dom
set no bouncemail
set no spambounce
set no showdots
# set invisible
defaults
        ### server options (qmail-style headers)
        via pop.provider.dom protocol POP3 auth cram-md5 timeout 15
        no dns no checkalias no uidl
        envelope Delivered-To qvirtual mydomain.dom.ch-
        localdomains mydomain.dom
        # tracepolls
        ### user options (courierpop3d)
        fetchlimit 32 batchlimit 16 limit 6000000 warnings 3600 antispam -1
        no rewrite no idle pass8bits fetchall
        # mda "/relay/bin/sendmail -N delay,fail -R full -f %F %T"
        # postconnect "exec /bin/sleep 5"
        smtphost 127.0.0.1 smtpaddress hostname.dom
        is * here
        # keep
poll username interval 4 user "username@mydomain.dom" pass "whatever"
mda "/relay/bin/env USER=relay HOME=/relay/home/username \
   DEFAULT=./ SENDER=%F RECIPIENT=%T \
   /usr/lib/courier/bin/maildrop -V 1 -f '%F' /home/username/.mailfilter"
  
  This example is for a basic system that uses traditional
  system accounts, and with an existing
  $HOME/.mailfilter (which can be generated via the
  webmail server). This can be used with virtual accounts, provided
  that additional steps are added to run maildrop under the correct
  system uid/gid, and the explicit pathname to the virtual
  account's .mailfilter is provided, and that the
  virtual account's MAILDIR/mailfilterfilterconfig is
  manually initialized to contain absolute pathnames (so that the
  generated .mailfilter file itself uses absolute
  paths).
This is a simple example that downloads one external mailbox
  to a local mailbox. Some external mail providers offer a service
  to deliver all mail for an entire domain into a single mailbox.
  This example will also work for downloading all such mail into a
  single local mailbox. This approach cannot be reliable modified
  to distribute domain mail to multiple local mailboxes, no matter
  what anyone else tells you, even though fetchmail
  contains facilities for doing so. If that's what you want to do,
  have your mail delivered by ESMTP or UUCP. Delivering mail to a
  mailbox automatically discards all the required recipient
  information, and by redistributing mail locally you're going to
  attempt to reconstruct this information from mail headers. This
  is never going to be a 100% reliable process, and unless you
  fully understand all these issues, you're likely to end up with
  occasional mail loops and bounces, which will annoy many people.
  You've been warned.