This is a beginning of a modest FAQ. Contributors:
[PP]
- Patrick Price
<sysadmin
@moment.net>
Table of contents:
configure
script is stuck in
an infinite loopgdbmobj
or bdbobj
subdirectory.make install-strip
or make
check
fails450
Service unavailable
error every time.configure
script is stuck in an
infinite loopA: It's not. Courier 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 Courier (and Courier-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, Courier 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 Courier'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. Courier 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
authpam
These 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/authcram
This 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. Courier
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 authmysql
These 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.
Courier 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++ search only the directories /lib
, /usr/lib
, and
/usr/include
(for include files).
All C and C++ compiler 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.
authvchkpw
authvchkpw
uses the vpopmail
library to handle
the authentication tasks. Vpopmail
is a virtual domain management
library that is popular on Qmail systems.
The Vpopmail
library often uses MySQL by itself, but
Courier!
doesn't have a way of knowing that. When that happens,
authvchkpw
will fail to compile because it is necessary to link
authvchkpw
with MySQL libraries. When that happens, the Makefile
must be manually edited to link authvchkpw
with MySQL.
authcustom
This is a dummy authentication modules, it doesn't do anything. It is a placeholder to insert custom authentication code.
authdaemon
authdaemon
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
Courier 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 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: Courier 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.
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.
A: You should really go out and get a copy of "Maximum RPM". It's very out of date, but if you learn the basics, you'll be able to figure the rest out by yourself. The following instructions are applicable to RPM 3.0.4, or higher. First, you need to create a mirror image of the main RPM directory in your account:
mkdir $HOME/rpm mkdir $HOME/rpm/SOURCES mkdir $HOME/rpm/SPECS mkdir $HOME/rpm/BUILD mkdir $HOME/rpm/SRPMS mkdir $HOME/rpm/RPMS mkdir $HOME/rpm/RPMS/i386
Use sparc
, or alpha
, or whatever's appropriate.
Finally:
echo "%_topdir $HOME/rpm" >> $HOME/.rpmmacros
That's it, now you can build your RPMs:
rpm -ta courier-0.20.tar.gz
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:
SOURCES
directory.courier.spec
. This
file is found at the top level of the source tree.courier.spec
to your SPECS
directory.
Edit it and make whatever changes you need to make.A: Courier does provide hooks for using the vpopmail virtual domain management library, however it will usually be necessary to tweak a couple of things in order to get it to work. The problem stems from the fact that vpopmail itself has a plethora of configuration options and different database back-ends. It is not possible to automatically figure out the right voodoo combination of link libraries to pull in all the necessary code. Use the following procedure to get Courier and vpopmail working together:
configure
. For
example:
DYNMYSQLLIBS="-L/opt/mysql/lib -lmysqlclient" export DYNMYSQLLIBS ./configure [options]
MX records for $domain violate section 3.3.9 of RFC 1035
or
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.
This message has 8-bit contents, but does not have the necessary MIME headers. Sorry, this mail server does not accept mail without the required MIME headers. See <URL:ftp://ftp.isi.edu/in-notes/rfc2045.txt> for more information.
or
The RFC 2046 nested multipart MIME boundary delimiters in this message are ambiguous, and cannot be parsed. See 'IMPLEMENTORS NOTE' in section 5.1.1 of <URL:ftp://ftp.isi.edu/in-notes/rfc2046.txt>.
or
The headers in this message contain 8-bit text, which violates RFC 2047. Sorry, I cannot accept any mail without the required MIME headers. See <URL:ftp://ftp.isi.edu/in-notes/rfc2047.txt> for more information.
[PP] [Sam]
Cause: Various bugs in poorly written software that
generates invalid MIME-formatted messages.
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 I can't really evaluate what the full consequences are and may cause various strange errors with IMAP clients that subsequently read the garbage, since IMAP relies heavily on MIME.
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!
The problem, apparently, is that S/MIME requires certain MIME headers to occur in a particular order, and S/MIME bitches loudly if these headers are reordered or changed.
Unfortunately, mail relays rewrite or modify headers all the time. Most just prepend an extra Received header. Some will append a Message-ID: header or a Date: header if one is missing. Some will automatically wrap long header lines into a smaller physical line size. Additionally, MIME does not impose any actual relative position of multiple MIME headers, so they can be freely reordered.
Courier chooses to rewrite mail headers more often than other MTAs, and its rewriting tends to be more aggressive, hence you'll see this problem more often with Courier, but, given enough time, you'll eventually get S/MIME corruption with other mail servers too.
I am not sure if S/MIME allows only the message content to be signed, or if mail headers must be included in the crypto signature. If they must, S/MIME will then appear to be a fundamentally broken standard that should not be used. PGP/GPG-signed messages are recommended instead.
Adding "MIME=none" to $sysconfdir/esmtpd might help, somewhat. This will suppress most, but not all, MIME rewriting for mail received via SMTP (but not the command line sendmail submitter).
Courier often (but not always) rewrites MIME messages. This happens for a variety of reasons: to reencode 8-bit mail for transport to/from a 7-bit mail relay; or, to fill in default values for unspecified MIME headers and values; or to fix up an inaccurate MIME transfer encoding header.
S/MIME calculates a checksum on both the MIME headers and the encoded content. Although MIME headers can be freely reordered; and MIME content can be freely reencoded, S/MIME prohibits it. The checksum will not verify if MIME headers are adjusted or reordered. S/MIME therefore requires an exception in existing MIME rewriting rules. Currently this exception processing is not implemented in Courier. Courier treats S/MIME no differently than any other MIME message.
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 Courier. 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 Courier 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 Courier 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 Courier, whose security model is based on traditional filesystem permissions.
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. Courier 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. Courier's IMAP server uses INBOX as
the folder namespace root, rather than the root hierarchy itself. Courier
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.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 Courier 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 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 or MySQL, 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 Courier 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, and userdb (also vchkpw, but that
requires some external configuration).
Note that Courier 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.
PREV: Installation | NEXT: Links |