546 lines
18 KiB
Plaintext
546 lines
18 KiB
Plaintext
1 - Purpose of this document
|
|
============================
|
|
|
|
This document describes how to build, install and configure a
|
|
Postfix system so that it can do one of the following:
|
|
|
|
- Send mail only, without changing an existing sendmail
|
|
installation.
|
|
|
|
- Send and receive mail via a virtual host interface, still
|
|
without any change to an existing sendmail installation.
|
|
|
|
- Replace sendmail altogether.
|
|
|
|
2 - Typographical conventions
|
|
=============================
|
|
|
|
In the instructions below, a command written as
|
|
|
|
# command
|
|
|
|
should be executed as the superuser.
|
|
|
|
A command written as
|
|
|
|
% command
|
|
|
|
should be executed as an unprivileged user.
|
|
|
|
3 - Documentation
|
|
=================
|
|
|
|
Documentation is available as HTML web pages (point your browser
|
|
to html/index.html) and as UNIX-style man pages (point your MANPATH
|
|
environment variable to the `man' subdirectory; be sure to use an
|
|
absolute path).
|
|
|
|
The sample configuration files in the `conf' directory have extensive
|
|
comments, but they may not describe every nuance of every feature.
|
|
|
|
Many files have their own built-in manual page. Tools to extract
|
|
those embedded manual pages are available in the mantools directory.
|
|
|
|
4 - Building on a supported system
|
|
==================================
|
|
|
|
If your system is supported, it is one of
|
|
|
|
AIX 3.2.5
|
|
AIX 4.1.x
|
|
AIX 4.2.0
|
|
BSD/OS 2.x
|
|
BSD/OS 3.x
|
|
BSD/OS 4.x
|
|
FreeBSD 2.x
|
|
FreeBSD 3.x
|
|
FreeBSD 4.x
|
|
FreeBSD 5.x
|
|
HP-UX 9.x
|
|
HP-UX 10.x
|
|
HP-UX 11.x
|
|
IRIX 5.x
|
|
IRIX 6.x
|
|
Linux Debian 1.3.1
|
|
Linux Debian 2.x
|
|
Linux RedHat 4.x
|
|
Linux RedHat 5.x
|
|
Linux RedHat 6.x
|
|
Linux RedHat 7.x
|
|
Linux Slackware 3.x
|
|
Linux Slackware 4.x
|
|
Linux Slackware 7.x
|
|
Linux SuSE 5.x
|
|
Linux SuSE 6.x
|
|
Linux SuSE 7.x
|
|
Mac OS X server
|
|
Mac OS X Public Beta
|
|
NEXTSTEP 3.x
|
|
NetBSD 1.x
|
|
OPENSTEP 4.x
|
|
OSF1.V3 (Digital UNIX)
|
|
OSF1.V4 aka Digital UNIX V4
|
|
OSF1.V5 aka Digital UNIX V5
|
|
OpenBSD 2.x
|
|
Reliant UNIX 5.x
|
|
Rhapsody 5.x
|
|
SunOS 4.1.x
|
|
SunOS 5.4..5.8 (Solaris 2.4..8)
|
|
Ultrix 4.x (well, that was long ago)
|
|
|
|
or something closely resemblant.
|
|
|
|
On Solaris, the "make" command and other utilities for software
|
|
development are in /usr/ccs/bin, so you MUST have /usr/ccs/bin in
|
|
your command search path.
|
|
|
|
If you need to build Postfix for multiple architectures, use the
|
|
lndir command to build a shadow tree with symbolic links to the
|
|
source files. lndir is part of X11R6.
|
|
|
|
If at any time in the build process you get messages like: "make:
|
|
don't know how to ..." you should be able to recover by running
|
|
the following command from the Postfix top-level directory:
|
|
|
|
% make -f Makefile.init makefiles
|
|
|
|
If you copied the Postfix source code after building it on another
|
|
machine, it is a good idea to cd into the top-level directory and
|
|
|
|
% make tidy
|
|
|
|
first. This will get rid of any system dependencies left over from
|
|
compiling the software elsewhere.
|
|
|
|
To build with GCC, or with the native compiler if people told me
|
|
that is better for your system, just cd into the top-level Postfix
|
|
directory of the source tree and type:
|
|
|
|
% make
|
|
|
|
To build with a non-default compiler, you need to specify the name
|
|
of the compiler:
|
|
|
|
% make makefiles CC=/opt/SUNWspro/bin/cc (Solaris)
|
|
% make
|
|
|
|
% make makefiles CC="/opt/ansic/bin/cc -Ae" (HP-UX)
|
|
% make
|
|
|
|
% make makefiles CC="purify cc"
|
|
% make
|
|
|
|
and so on. In some cases, optimization is turned off automatically.
|
|
|
|
In order to build with non-default settings, for example, with a
|
|
configuration directory other than /etc/postfix, use:
|
|
|
|
% make makefiles CCARGS=-DDEF_CONFIG_DIR=\\\\\\\"/some/where\\\\\\\"
|
|
% make
|
|
|
|
That's seven backslashes :-) But at least this works with sh and csh.
|
|
|
|
In order to build Postfix for very large applications, where you
|
|
expect to run more than 1000 delivery processes, you may need to
|
|
override the definition of the FD_SETSIZE macro to make select()
|
|
work correctly:
|
|
|
|
% make makefiles CCARGS=-DFD_SETSIZE=2048
|
|
|
|
In any case, if the command
|
|
|
|
% make
|
|
|
|
produces compiler error messages, it may be time to examine the
|
|
FAQ document.
|
|
|
|
5 - Porting to on an unsupported system
|
|
=======================================
|
|
|
|
- Choose a SYSTEMTYPE name for the new system. Please use a name
|
|
that includes the major version of the operating system (such as
|
|
SUNOS4 or LINUX2), so that different releases of the same system
|
|
can be supported without confusion.
|
|
|
|
- Add a case statement to the "makedefs" shell script in the
|
|
top-level directory that recognizes the new system reliably, and
|
|
that emits the right system-specific information. Be sure to make
|
|
the code robust against user PATH settings; if the system offers
|
|
multiple UNIX flavors (e.g. BSD and SYSV) be sure to build for the
|
|
native flavor, not the emulated one.
|
|
|
|
- Add an #ifdef SYSTEMTYPE section to the central util/sys_defs.h
|
|
include file. You may have to invent new feature macros. Please
|
|
choose sensible feature macro names such as HAS_DBM or
|
|
FIONREAD_IN_SYS_FILIO_H. I strongly recommend against #ifdef
|
|
SYSTEMTYPE dependencies in individual source files. This may seem
|
|
to be the quickest solution, but it will create a mess that becomes
|
|
increasingly difficult to maintain over time. Moreover, with the
|
|
next port you'd have to place #ifdefs all over the source code
|
|
again.
|
|
|
|
6 - Installing the software after successful compilation
|
|
========================================================
|
|
|
|
IMPORTANT: if you are REPLACING an existing sendmail installation
|
|
with Postfix, you may need to keep the old sendmail program running
|
|
for some time in order to flush the mail queue. As superuser,
|
|
execute the following commands (your sendmail, newaliases and mailq
|
|
programs may be in a different place):
|
|
|
|
# mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
|
|
# mv /usr/bin/newaliases /usr/bin/newaliases.OFF
|
|
# mv /usr/bin/mailq /usr/bin/mailq.OFF
|
|
# chmod 755 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF \
|
|
/usr/bin/mailq.OFF
|
|
|
|
In order to install or upgrade Postfix:
|
|
|
|
- Create a user "postfix" with a unique user id and group id.
|
|
Preferably, this is an account that no-one can log into. The
|
|
account does not need an executable login shell, and needs no
|
|
existing home directory. My password file entry looks like this:
|
|
|
|
postfix:*:12345:12345:postfix:/no/where:/no/shell
|
|
|
|
- Make sure there is a corresponding alias in /etc/aliases:
|
|
|
|
postfix: root
|
|
|
|
- Review section 12 of this file, and decide if a world-writable
|
|
maildrop is OK, or if Postfix needs a set-gid posting agent.
|
|
|
|
- Run the INSTALL.sh script as the super-user:
|
|
|
|
# make install (interactive version, first time install)
|
|
# make install </dev/null (non-interactive version, for upgrades)
|
|
|
|
The non-interactive version needs the /etc/postfix/install.cf
|
|
file from a previous installation. If the file does not exist,
|
|
use interactive installation instead.
|
|
|
|
The INSTALL.sh script offers suggestions for pathnames that you
|
|
can override, either by editing INSTALL.sh or by specifying your
|
|
preferences interactively. INSTALL.sh stores your preferences in
|
|
the Postfix configuration directory in order to ease future installs.
|
|
|
|
- Proceed to the section on how you wish to run Postfix on your
|
|
particular machine:
|
|
|
|
- Send mail only, without changing an existing sendmail
|
|
installation (section 7).
|
|
|
|
- Send and receive mail via a virtual host interface, still
|
|
without any change to an existing sendmail installation
|
|
(section 8).
|
|
|
|
- Replace sendmail altogether (section 9).
|
|
|
|
7 - Configuring Postfix to send mail only
|
|
=========================================
|
|
|
|
If you are going to use Postfix to send mail only, there is no need
|
|
to change your existing sendmail setup. Instead, set up your mail
|
|
user agent so that it calls the Postfix sendmail program directly.
|
|
|
|
Follow the instructions in the "Mandatory configuration file edits"
|
|
in section 10, review the "To chroot or not to chroot" text in
|
|
section 11, and choose a security model according to section 12.
|
|
|
|
You MUST comment out the `smtp inet' entry in /etc/postfix/master.cf,
|
|
in order to avoid conflicts with the real sendmail.
|
|
|
|
Start the Postfix system:
|
|
|
|
# postfix start
|
|
|
|
or, if you feel nostalgic, use the Postfix sendmail command:
|
|
|
|
# sendmail -bd -qwhatever
|
|
|
|
and watch your syslog file for any error messages.
|
|
|
|
% egrep '(reject|warning|error|fatal|panic):' /some/log/file
|
|
|
|
Typical logfile names are: /var/log/maillog or /var/log/syslog.
|
|
See /etc/syslog.conf for actual logfile names.
|
|
|
|
When it is run for the first time, the Postfix startup shell script
|
|
will create a bunch of subdirectories below the Postfix spool
|
|
directory.
|
|
|
|
In order to inspect the mail queue, use
|
|
|
|
% sendmail -bp
|
|
|
|
See also the "Care and feeding" section 13 below.
|
|
|
|
8 - Configuring Postfix to send and receive mail (virtual interface)
|
|
====================================================================
|
|
|
|
Alternatively, you can use the Postfix system to send AND receive
|
|
mail while leaving your sendmail setup intact, by running Postfix
|
|
on a virtual interface address. Simply configure your mail user
|
|
agent to directly invoke the Postfix sendmail program.
|
|
|
|
The examples/virtual-setup directory gives instructions for setting
|
|
up virtual interfaces for a variety of UNIX versions.
|
|
|
|
In the /etc/postfix/main.cf file, I would specify
|
|
|
|
myhostname = virtual.host.name
|
|
inet_interfaces = $myhostname
|
|
mydestination = $myhostname
|
|
|
|
Follow the instructions in the "Mandatory configuration file edits"
|
|
in section 10, review the "To chroot or not to chroot" text in
|
|
section 11, and choose a security model according to section 12.
|
|
|
|
Start the mail system:
|
|
|
|
# postfix start
|
|
|
|
or, if you feel nostalgic, use the Postfix sendmail program:
|
|
|
|
# sendmail -bd -qwhatever
|
|
|
|
and watch your syslog file for any error messages.
|
|
|
|
% egrep '(reject|warning|error|fatal|panic):' /some/log/file
|
|
|
|
Typical logfile names are: /var/log/maillog or /var/log/syslog.
|
|
See /etc/syslog.conf for actual logfile names.
|
|
|
|
When it is run for the first time, the Postfix startup shell script
|
|
will create a bunch of subdirectories below the Postfix spool
|
|
directory.
|
|
|
|
In order to inspect the mail queue, use
|
|
|
|
% sendmail -bp
|
|
|
|
See also the "Care and feeding" section 13 below.
|
|
|
|
9 - Turning off sendmail forever
|
|
================================
|
|
|
|
Prior to installing Postfix you should save the existing sendmail
|
|
program files as described in section 6.
|
|
|
|
Be sure to keep the old sendmail running for at least a couple
|
|
days to flush any unsent mail. To do so, stop the sendmail daemon
|
|
and restart it as:
|
|
|
|
# /usr/sbin/sendmail.OFF -q
|
|
|
|
After you have visited the "Mandatory configuration file edits"
|
|
section below, you can start the Postfix system with
|
|
|
|
# postfix start
|
|
|
|
But the good old sendmail way works just as well:
|
|
|
|
# sendmail -bd -qwhatever
|
|
|
|
and watch the syslog file for any complaints from the mail system.
|
|
|
|
% egrep '(reject|warning|error|fatal|panic):' /some/log/file
|
|
|
|
Typical logfile names are: /var/log/maillog or /var/log/syslog.
|
|
See /etc/syslog.conf for actual logfile names.
|
|
|
|
When it is run for the first time, the Postfix startup shell script
|
|
will create a bunch of subdirectories below the Postfix spool
|
|
directory.
|
|
|
|
See also the "Care and feeding" section 13 below.
|
|
|
|
10 - Mandatory configuration file edits
|
|
=======================================
|
|
|
|
By default, Postfix configuration files are in /etc/postfix, and
|
|
must be owned by root. Giving someone else write permission to
|
|
main.cf or master.cf means giving root privileges to that person.
|
|
|
|
Whenever you make a change to a config file, execute the following
|
|
command in order to refresh a running mail system:
|
|
|
|
# postfix reload
|
|
|
|
In /etc/postfix/main.cf you will have to set up a minimal number of
|
|
configuration parameters. Postfix configuration parameters
|
|
resemble shell variables. You specify a variable as
|
|
|
|
parameter = value
|
|
|
|
and you use it by putting a $ in front of its name:
|
|
|
|
other_parameter = $parameter
|
|
|
|
You can use $parameter before it is given a value. The Postfix
|
|
configuration language uses lazy evaluation, and does not look at
|
|
a parameter value until it is needed at runtime.
|
|
|
|
First of all, you must specify what domain will be appended to an
|
|
unqualified address (i.e. an address without @domain.name). The
|
|
"myorigin" parameter defaults to the local hostname, but that is
|
|
probably OK only for very small sites.
|
|
|
|
Some examples:
|
|
|
|
myorigin = $myhostname
|
|
myorigin = $mydomain
|
|
|
|
In the first case, local mail goes out as user@$myhostname, in
|
|
the second case the sender address is user@$mydomain.
|
|
|
|
Next you need to specify what mail addresses Postfix should deliver
|
|
locally.
|
|
|
|
Some examples:
|
|
|
|
mydestination = $myhostname, localhost.$mydomain
|
|
mydestination = $myhostname, localhost.$mydomain, $mydomain
|
|
mydestination = $myhostname
|
|
|
|
The first example is appropriate for a workstation, the second is
|
|
appropriate for the mailserver for an entire domain. The third
|
|
example should be used when running on a virtual host interface.
|
|
|
|
If your machine is on an open network then you must specify what
|
|
client IP addresses are authorized to relay their mail through your
|
|
machine. The default setting includes all class A, B or C networks
|
|
that the machine is attached to. Often, that gives relay permission
|
|
to too many clients. My own settings are:
|
|
|
|
mynetworks = 168.100.189.0/28, 127.0.0.0/8
|
|
|
|
If you're behind a firewall, you should set up a relayhost. If
|
|
you can, specify the organizational domain name so that Postfix
|
|
can use DNS lookups, and so that it can fall back to a secondary
|
|
MX host when the primary MX host is down. Otherwise just specify
|
|
a hard-coded hostname.
|
|
|
|
Some examples:
|
|
|
|
relayhost = $mydomain
|
|
relayhost = mail.$mydomain
|
|
relayhost = [mail.$mydomain]
|
|
|
|
The form enclosed with [] eliminates DNS MX lookups.
|
|
|
|
By default, the SMTP client will do DNS lookups for sender and
|
|
recipient addresses even when you specify a relay host. If your
|
|
machine has no access to a DNS server, turn off SMTP client DNS
|
|
lookups like this:
|
|
|
|
disable_dns_lookups = yes
|
|
|
|
The FAQ (html/faq.html) has more hints and tips for firewalled
|
|
and/or dial-up networks.
|
|
|
|
Finally, if you haven't used Sendmail prior to using Postfix, you
|
|
will have to build the alias database (with: sendmail -bi, or:
|
|
newaliases). Be sure to set up aliases for root and postmaster that
|
|
forward mail to a real person. Postfix has a sample aliases file
|
|
conf/aliases that you can adapt to local conditions.
|
|
|
|
11 - To chroot or not to chroot
|
|
===============================
|
|
|
|
Postfix can run most daemon processes in a chroot jail, that is,
|
|
the processes run at a fixed low privilege and with access only to
|
|
the Postfix queue directories (/var/spool/postfix). This provides
|
|
a significant barrier against intrusion. The barrier is not
|
|
impenetrable, but every little bit helps.
|
|
|
|
With the exception of the Postfix local delivery and `pipe' daemons,
|
|
every Postfix daemon can run chrooted.
|
|
|
|
Sites with high security requirements should consider to chroot
|
|
all daemons that talk to the network: the smtp and smtpd processes,
|
|
and perhaps also the lmtp client.
|
|
|
|
The default /etc/postfix/master.cf file specifies that no Postfix
|
|
daemon runs chrooted. In order to enable chroot operation, edit
|
|
the file /etc/postfix/master.cf. Instructions are in the file.
|
|
|
|
Note that a chrooted daemon resolves all filenames relative to the
|
|
Postfix queue directory (/var/spool/postfix). For successful use
|
|
of a chroot jail, most UNIX systems require you to bring in some
|
|
files or device nodes. The examples/chroot-setup directory has a
|
|
collection of scripts that help you set up chroot environments for
|
|
Postfix systems.
|
|
|
|
12 - Security: writable versus protected maildrop directory
|
|
===========================================================
|
|
|
|
Postfix offers a choice of submission mechanisms.
|
|
|
|
1 - Postfix can use a world-writable, sticky, mode 1733 maildrop
|
|
directory where local users can submit mail. This approach
|
|
avoids the need for set-uid or set-gid software. Mail can be
|
|
posted even while the mail system is down. Queue files in the
|
|
maildrop directory have no read/write/execute permission for
|
|
other users. The maildrop directory is not used for mail
|
|
received via the network.
|
|
|
|
With directory world write permission come opportunities for
|
|
annoyance: a local user can make hard links to someone else's
|
|
maildrop files so they don't go away and may be delivered
|
|
multiple times; a local user can fill the maildrop directory
|
|
with junk and try to crash the mail system; and a local user
|
|
can hard link someone else's files into the maildrop directory
|
|
and try to have them delivered as mail. However, Postfix queue
|
|
files have a specific format; less than one in 10^12 non-Postfix
|
|
files would be recognized as a valid Postfix queue file.
|
|
|
|
In order to enable maildrop world-write permission:
|
|
|
|
- Specify "no" when asked by the INSTALL.sh script whether
|
|
Postfix needs set-gid privileges.
|
|
|
|
2 - On systems with many users it may be desirable to revoke maildrop
|
|
directory world write permission, and to enable set-gid privileges
|
|
on a small "maildrop" command that is provided for this purpose.
|
|
|
|
In order to revoke maildrop world-write permission:
|
|
|
|
- Create a group "maildrop" that is unique and that does not
|
|
share its group ID with any other user, certainly not with
|
|
the postfix account,
|
|
|
|
- Specify "maildrop" when asked by the INSTALL.sh script whether
|
|
Postfix needs set-gid privileges.
|
|
|
|
The sendmail posting program will automatically invoke the
|
|
postdrop command when maildrop directory write permission is
|
|
restricted.
|
|
|
|
13 - Care and feeding of the Postfix system
|
|
===========================================
|
|
|
|
The Postfix programs log all problems to the syslog daemon. The
|
|
names of logfiles are specified in /etc/syslog.conf. Note: the
|
|
syslogd will not create files. You must create them ahead of time
|
|
before (re)starting syslogd. At the very least you need something
|
|
like:
|
|
|
|
mail.err /dev/console
|
|
mail.debug /var/log/maillog
|
|
|
|
Hopefully, the number of problems will be small, but it is a good
|
|
idea to run every night before the syslog files are rotated:
|
|
|
|
# postfix check
|
|
# egrep '(reject|warning|error|fatal|panic):' /some/log/file
|
|
|
|
Typical logfile names are: /var/log/maillog or /var/log/syslog.
|
|
See /etc/syslog.conf for actual logfile names.
|
|
|
|
The first line (postfix check) causes Postfix to report file
|
|
permission/ownership discrepancies.
|
|
|
|
The second line looks for problem reports from the mail software,
|
|
and reports how effective the anti-relay and anti-UCE blocks are.
|