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.
Several 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.