479 lines
16 KiB
Plaintext
479 lines
16 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 manpages (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
|
||
|
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 Slackware 3.5
|
||
|
Linux Slackware 4.0
|
||
|
Linux Slackware 7.0
|
||
|
Linux SuSE 5.x
|
||
|
Linux SuSE 6.x
|
||
|
Mac OS X server
|
||
|
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.7 (Solaris 2.4..7)
|
||
|
Ultrix 4.x
|
||
|
|
||
|
or something closely resemblant.
|
||
|
|
||
|
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 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:
|
||
|
|
||
|
# sh INSTALL.sh
|
||
|
|
||
|
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.
|
||
|
|
||
|
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.
|
||
|
|
||
|
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.
|
||
|
|
||
|
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 a
|
||
|
local address. 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 are local to the
|
||
|
Postfix system.
|
||
|
|
||
|
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 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.
|
||
|
|
||
|
11 - To chroot or not to chroot
|
||
|
==============================
|
||
|
|
||
|
Most Postfix daemons can run in a chroot jail, that is, in a chroot
|
||
|
environment at fixed low privilege. This provides a significant
|
||
|
barrier against intrusion. The barrier is not impenetrable, but
|
||
|
every little bit helps.
|
||
|
|
||
|
The file /etc/postfix/master.cf by default runs no Postfix daemons
|
||
|
in a chroot jail. However, with the exception of the `local' and
|
||
|
`pipe' daemons, every Postfix daemon can run chrooted.
|
||
|
|
||
|
The examples/chroot-setup directory has a collection of scripts
|
||
|
for setting up chroot environments for Postfix systems.
|
||
|
|
||
|
12 - Security: writable versus protected maildrop directory
|
||
|
===========================================================
|
||
|
|
||
|
Postfix offers a choice of submission mechanims.
|
||
|
|
||
|
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
|
||
|
|
||
|
The second line looks for problem reports from the mail software,
|
||
|
and reports how effective the anti-relay and anti-UCE blocks are.
|