summaryrefslogtreecommitdiffstats
path: root/proto/INSTALL.html
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-06 01:46:30 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-06 01:46:30 +0000
commitb5896ba9f6047e7031e2bdee0622d543e11a6734 (patch)
treefd7b460593a2fee1be579bec5697e6d887ea3421 /proto/INSTALL.html
parentInitial commit. (diff)
downloadpostfix-b5896ba9f6047e7031e2bdee0622d543e11a6734.tar.xz
postfix-b5896ba9f6047e7031e2bdee0622d543e11a6734.zip
Adding upstream version 3.4.23.upstream/3.4.23upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'proto/INSTALL.html')
-rw-r--r--proto/INSTALL.html1672
1 files changed, 1672 insertions, 0 deletions
diff --git a/proto/INSTALL.html b/proto/INSTALL.html
new file mode 100644
index 0000000..984528c
--- /dev/null
+++ b/proto/INSTALL.html
@@ -0,0 +1,1672 @@
+<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+
+<head>
+
+<title>Postfix Installation From Source Code </title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+
+</head>
+
+<body>
+
+<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
+Installation From Source Code </h1>
+
+<hr>
+
+<h2> <a name="1">1 - Purpose of this document</a> </h2>
+
+<p> If you are using a pre-compiled version of Postfix, you should
+start with BASIC_CONFIGURATION_README and the general documentation
+referenced by it. INSTALL is only a bootstrap document to get
+Postfix up and running from scratch with the minimal number of
+steps; it should not be considered part of the general documentation.
+</p>
+
+<p> This document describes how to build, install and configure a
+Postfix system so that it can do one of the following: </p>
+
+<ul>
+
+<li> Send mail only, without changing an existing Sendmail
+installation.
+
+<li> Send and receive mail via a virtual host interface, still
+without any change to an existing Sendmail installation.
+
+<li> Run Postfix instead of Sendmail.
+
+</ul>
+
+<p> Topics covered in this document: </p>
+
+<ol>
+
+<li> <a href="#1">Purpose of this document</a>
+
+<li> <a href="#2">Typographical conventions</a>
+
+<li> <a href="#3">Documentation</a>
+
+<li> <a href="#4">Building on a supported system</a>
+
+<li> <a href="#5">Porting Postfix to an unsupported system</a>
+
+<li> <a href="#install">Installing the software after successful
+compilation </a>
+
+<li> <a href="#send_only">Configuring Postfix to send mail
+only </a>
+
+<li> <a href="#send_receive">Configuring Postfix to send and
+receive mail via virtual interface </a>
+
+<li> <a href="#replace">Running Postfix instead of Sendmail</a>
+
+<li> <a href="#mandatory">Mandatory configuration file edits</a>
+
+<li> <a href="#hamlet">To chroot or not to chroot</a>
+
+<li> <a href="#care">Care and feeding of the Postfix system</a>
+
+</ol>
+
+<h2> <a name="2">2 - Typographical conventions</a> </h2>
+
+<p> In the instructions below, a command written as </p>
+
+<blockquote>
+<pre>
+# command
+</pre>
+</blockquote>
+
+<p> should be executed as the superuser. </p>
+
+<p> A command written as </p>
+
+<blockquote>
+<pre>
+$ command
+</pre>
+</blockquote>
+
+<p> should be executed as an unprivileged user. </p>
+
+<h2> <a name="3">3 - Documentation</a> </h2>
+
+<p> Documentation is available as README files (start with the file
+README_FILES/AAAREADME), as HTML web pages (point your browser to
+"html/index.html") and as UNIX-style manual pages. </p>
+
+<p> You should view the README files with a pager such as more(1)
+or less(1), because the files use backspace characters in order to
+produce <b>bold</b> font. To print a README file without backspace
+characters, use the col(1) command. For example: </p>
+
+<blockquote>
+<pre>
+$ col -bx &lt;file | lpr
+</pre>
+</blockquote>
+
+<p> In order to view the manual pages before installing Postfix,
+point your MANPATH environment variable to the "man" subdirectory;
+be sure to use an absolute path. </p>
+
+<blockquote>
+<pre>
+$ export MANPATH; MANPATH="`pwd`/man:$MANPATH"
+$ setenv MANPATH "`pwd`/man:$MANPATH"
+</pre>
+</blockquote>
+
+<p> Of particular interest is the postconf(5) manual page that
+lists all the 500+ configuration parameters. The HTML version of
+this text makes it easy to navigate around. </p>
+
+<p> All Postfix source files have their own built-in manual page.
+Tools to extract those embedded manual pages are available in the
+mantools directory. </p>
+
+<h2> <a name="4">4 - Building on a supported system</a> </h2>
+
+<p> Postfix development happens on FreeBSD and MacOS X, with regular
+tests on Linux (Fedora, Ubuntu) and Solaris. Support for other
+systems relies on feedback from their users, and may not always be
+up-to-date. </p>
+
+<p> OpenBSD is partially supported. The libc resolver does not
+implement the documented "internal resolver options which are [...]
+set by changing fields in the _res structure" (documented in the
+OpenBSD 5.6 resolver(3) manpage). This results in too many DNS
+queries, and false positives for queries that should fail. </p>
+
+<!--
+
+<p> At some point in time, a version of Postfix was supported on: </p>
+
+<blockquote>
+<p>
+AIX 3.2.5, 4.1.x, 4.2.0, 4.3.x, 5.2 <br>
+BSD/OS 2.x, 3.x, 4.x <br>
+FreeBSD 2.x .. 9.x <br>
+HP-UX 9.x, 10.x, 11.x <br>
+IRIX 5.x, 6.x <br>
+Linux Debian 1.3.1 and later <br>
+Linux RedHat 3.x (January 2004) and later <br>
+Linux Slackware 3.x and later <br>
+Linux SuSE 5.x and later <br>
+Linux Ubuntu 4.10 and later<br>
+Mac OS X <br>
+NEXTSTEP 3.x <br>
+NetBSD 1.x and later <br>
+OPENSTEP 4.x <br>
+OSF1.V3 - OSF1.V5 (Digital UNIX) <br>
+Reliant UNIX 5.x <br>
+SunOS 4.1.4 (March 2007) <br>
+SunOS 5.4 - 5.10 (Solaris 2.4..10) <br>
+Ultrix 4.x (well, that was long ago) <br>
+</p>
+</blockquote>
+
+<p> or something closely resemblant. </p>
+
+-->
+
+<p> Overview of topics: </p>
+
+<ul>
+
+<li><a href="#build_first">4.1 - Getting started</a>
+
+<li><a href="#build_cc">4.2 - What compiler to use</a>
+
+<li><a href="#build_pie">4.3 - Building with Postfix position-independent
+executables (Postfix &ge; 3.0)</a>
+
+<li><a href="#build_dll">4.4 - Building with Postfix dynamically-linked
+libraries and database plugins (Postfix &ge; 3.0)</a>
+
+<li><a href="#build_opt">4.5 - Building with optional features</a>
+
+<li><a href="#build_over">4.6 - Overriding built-in parameter default
+settings</a>
+
+<li><a href="#build_other">4.7 - Overriding other compile-time
+features</a>
+
+<li><a href="#build_proc">4.8 - Support for thousands of processes</a>
+
+<li><a href="#build_final">4.9 - Compiling Postfix, at last</a>
+
+</ul>
+
+
+<h3><a name="build_first">4.1 - Getting started</a> </h3>
+
+<p> On Solaris, the "make" command and other development utilities
+are in /usr/ccs/bin, so you MUST have /usr/ccs/bin in your command
+search path. If these files do not exist, you need to install the
+development packages first. </p>
+
+<p> If you need to build Postfix for multiple architectures from a
+single source-code tree, use the "lndir" command to build a shadow
+tree with symbolic links to the source files. </p>
+
+<p> 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: </p>
+
+<blockquote>
+<pre>
+$ make -f Makefile.init makefiles
+</pre>
+</blockquote>
+
+<p> 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
+first do this:</p>
+
+<blockquote>
+<pre>
+$ make tidy
+</pre>
+</blockquote>
+
+<p> This will get rid of any system dependencies left over from
+compiling the software elsewhere. </p>
+
+<h3><a name="build_cc">4.2 - What compiler to use</a></h3>
+
+<p> 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: </p>
+
+<blockquote>
+<pre>
+$ make
+</pre>
+</blockquote>
+
+<p> To build with a non-default compiler, you need to specify the name
+of the compiler. Here are a few examples: </p>
+
+<blockquote>
+<pre>
+$ 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
+</pre>
+</blockquote>
+
+<p> and so on. In some cases, optimization will be turned off
+automatically. </p>
+
+<h3><a name="build_pie">4.3 - Building with Postfix position-independent
+executables (Postfix &ge; 3.0)</a> </h3>
+
+<p> On some systems Postfix can be built with Position-Independent
+Executables. PIE is used by the ASLR exploit mitigation technique
+(ASLR = Address-Space Layout Randomization): </p>
+
+<blockquote>
+<pre>
+$ make makefiles pie=yes ...other arguments...
+</pre>
+</blockquote>
+
+<p> (Specify "make makefiles pie=no" to explicitly disable Postfix
+position-independent executable support). </p>
+
+<p> Postfix PIE support appears to work on Fedora Core 20, Ubuntu
+14.04, FreeBSD 9 and 10, and NetBSD 6 (all with the default system
+compilers). </p>
+
+<p> Whether the "pie=yes" above has any effect depends on the
+compiler. Some compilers always produce PIE executables, and some
+may even complain that the Postfix build option is redundant. </p>
+
+<h3><a name="build_dll">4.4 - Building with Postfix dynamically-linked
+libraries and database plugins (Postfix &ge; 3.0)</a> </h3>
+
+<p> Postfix dynamically-linked library and database plugin support
+exists for recent versions of Linux, FreeBSD and MacOS X.
+Dynamically-linked library builds may become the default at some
+point in the future. </p>
+
+<p> Overview of topics: </p>
+
+<ul>
+
+<li><a href="#shared_enable">4.4.1 Turning on Postfix dynamically-linked
+library support</a>
+
+<li><a href="#dynamicmaps_enable">4.4.2 Turning on Postfix database-plugin
+support</a>
+
+<li><a href="#shared_custom">4.4.3 Customizing Postfix dynamically-linked
+libraries and database plugins</a>
+
+<li><a href="#shared_tips">4.4.4 Tips for distribution maintainers</a>
+
+</ul>
+
+<p> Note: directories with Postfix dynamically-linked libraries
+or database plugins should contain only postfix-related files.
+Postfix dynamically-linked libraries and database plugins should
+not be installed in a "public" system directory such as /usr/lib
+or /usr/local/lib. Linking Postfix dynamically-linked library or
+database-plugin files into non-Postfix programs is not supported.
+Postfix dynamically-linked libraries and database plugins implement
+a Postfix-internal API that changes without maintaining compatibility.
+</p>
+
+<h4><a name="shared_enable"> 4.4.1 Turning on Postfix dynamically-linked
+library support </a></h4>
+
+<p> Postfix can be built with Postfix dynamically-linked libraries
+(files typically named <tt>libpostfix-*.so</tt>). Postfix
+dynamically-linked libraries add minor run-time overhead and result
+in significantly-smaller Postfix executable files. </p>
+
+<p> Specify "shared=yes" on the "make makefiles" command line to
+build Postfix with dynamically-linked library support. </p>
+
+<blockquote>
+<pre>
+$ make makefiles shared=yes ...other arguments...
+$ make
+</pre>
+</blockquote>
+
+<p> (Specify "make makefiles shared=no" to explicitly disable Postfix
+dynamically-linked library support). </p>
+
+<p> This installs dynamically-linked libraries in $shlib_directory,
+typically /usr/lib/postfix or /usr/local/lib/postfix, with file
+names libpostfix-<i>name</i>.so, where the <i>name</i> is a source-code
+directory name such as "util" or "global". </p>
+
+<p> See section 4.4.3 "<a href="#shared_custom">Customizing Postfix
+dynamically-linked libraries and database plugins</a>" below for
+how to customize the Postfix dynamically-linked library location,
+including support to upgrade a running mail system safely. </p>
+
+<h4><a name="dynamicmaps_enable"> 4.4.2 Turning on Postfix
+database-plugin support </a></h4>
+
+<p> Additionally, Postfix can be built to support dynamic loading
+of Postfix database clients (database plugins) with the Debian-style
+dynamicmaps feature. Postfix 3.0 supports dynamic loading of cdb:,
+ldap:, lmdb:, mysql:, pcre:, pgsql:, sdbm:, and sqlite: database
+clients. Dynamic loading is useful when you distribute or install
+pre-compiled Postfix packages. </p>
+
+<p> Specify "dynamicmaps=yes" on the "make makefiles" command line
+to build Postfix with support to dynamically load Postfix database
+clients with the Debian-style dynamicmaps feature.
+</p>
+
+<blockquote>
+<pre>
+$ make makefiles dynamicmaps=yes ...other arguments...
+$ make
+</pre>
+</blockquote>
+
+<p> (Specify "make makefiles dynamicmaps=no" to explicitly disable
+Postfix database-plugin support). </p>
+
+<p> This implicitly enables dynamically-linked library support,
+installs the configuration file dynamicmaps.cf in $meta_directory
+(usually, /etc/postfix or /usr/local/etc/postfix), and installs
+database plugins in $shlib_directory (see above). Database plugins
+are named postfix-<i>type</i>.so where the <i>type</i> is a database
+type such as "cdb" or "ldap". </p>
+
+<blockquote>
+
+<p> NOTE: The Postfix 3.0 build procedure expects that you specify
+database library dependencies with variables named AUXLIBS_CDB,
+AUXLIBS_LDAP, etc. With Postfix 3.0 and later, the old AUXLIBS
+variable still supports building a statically-loaded database client,
+but only the new AUXLIBS_CDB etc. variables support building a
+dynamically-loaded or statically-loaded CDB etc. database client.
+See CDB_README, LDAP_README, etc. for details. </p>
+
+<p> Failure to follow this advice will defeat the purpose of dynamic
+database client loading. Every Postfix executable file will have
+database library dependencies. And that was exactly what dynamic
+database client loading was meant to avoid. </p>
+
+</blockquote>
+
+<p> See the next section for how to customize the location and
+version of Postfix database plugins and the location of the file
+dynamicmaps.cf. </p>
+
+<h4><a name="shared_custom"> 4.4.3 Customizing Postfix dynamically-linked
+libraries and database plugins </a></h4>
+
+<h5> Customizing build-time and run-time options for Postfix
+dynamically-linked libraries and database plugins </h5>
+
+<p> The build-time environment variables SHLIB_CFLAGS, SHLIB_RPATH,
+and SHLIB_SUFFIX provide control over how Postfix libraries and
+plugins are compiled, linked, and named.
+
+<blockquote>
+<pre>
+$ make makefiles SHLIB_CFLAGS=flags SHLIB_RPATH=rpath SHLIB_SUFFIX=suffix ...other arguments...
+$ make
+</pre>
+</blockquote>
+
+<p> See section 4.7 "<a href="#build_other">Overriding other
+compile-time features</a>" below for details. </p>
+
+<h5> Customizing the location of Postfix dynamically-linked libraries
+and database plugins </h5>
+
+<p> As a reminder, the directories with Postfix dynamically-linked
+libraries or database plugins should contain only Postfix-related
+files. Linking these files into other programs is not supported.
+</p>
+
+<p> To override the default location of Postfix dynamically-linked
+libraries and database plugins specify, for example: </p>
+
+<blockquote>
+<pre>
+$ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
+</pre>
+</blockquote>
+
+<p> If you intend to upgrade Postfix without stopping the mail
+system, then you should append the Postfix release version to the
+shlib_directory pathname, to eliminate the possibility that programs
+will link with dynamically-linked libraries or database plugins
+from the wrong Postfix version. For example: </p>
+
+<blockquote>
+<pre>
+$ make makefiles shared=yes \
+ shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+</pre>
+</blockquote>
+
+<p> The command "make makefiles name=value..." will replace the
+string MAIL_VERSION at the end of a configuration parameter value
+with the Postfix release version. Do not try to specify something
+like $mail_version on this command line. This produces inconsistent
+results with different versions of the make(1) command. </p>
+
+<p> You can change the shlib_directory setting after Postfix is
+built, with "make install" or "make upgrade". However, you may have
+to run ldconfig if you change shlib_directory after Postfix is built
+(the symptom is that Postfix programs fail because the run-time
+linker cannot find the files libpostfix-*.so). No ldconfig command
+is needed if you keep the files libpostfix-*.so in the compiled-in
+default $shlib_directory location. </p>
+
+<blockquote>
+<pre>
+# make upgrade shlib_directory=/usr/local/lib/postfix ...
+# make install shlib_directory=/usr/local/lib/postfix ...
+</pre>
+</blockquote>
+
+<p> To append the Postfix release version to the pathname if you
+intend to upgrade Postfix without stopping the mail system: </p>
+
+<blockquote>
+<pre>
+# make upgrade shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+# make install shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+</pre>
+</blockquote>
+
+<p> See also the comments above for appending MAIL_VERSION with
+the "make makefiles" command. </p>
+
+<h5> Customizing the location of dynamicmaps.cf and other files
+</h5>
+
+<p> The meta_directory parameter has the same default setting as
+the config_directory parameter, typically /etc/postfix or
+/usr/local/etc/postfix. </p>
+
+<p> You can override the default meta_directory location at compile
+time or after Postfix is built. To override the default location
+at compile time specify, for example: </p>
+
+<blockquote>
+<pre>
+% make makefiles meta_directory=/usr/libexec/postfix ...
+</pre>
+</blockquote>
+
+<p> Here is a tip if you want to make a pathname dependent on the
+Postfix release version: the command "make makefiles name=value..."
+will replace the string MAIL_VERSION at the end of a configuration
+parameter value with the Postfix release version. Do not try to
+specify something like $mail_version on this command line. This
+produces inconsistent results with different versions of the make(1)
+command. </p>
+
+<p> You can override the meta_directory setting after Postfix is
+built, with "make install" or "make upgrade". </p>
+
+<blockquote>
+<pre>
+# make upgrade meta_directory=/usr/libexec/postfix ...
+# make install meta_directory=/usr/libexec/postfix ...
+</pre>
+</blockquote>
+
+<p> As with the command "make makefiles, the command "make
+install/upgrade name=value..." will replace the string MAIL_VERSION
+at the end of a configuration parameter value with the Postfix
+release version. Do not try to specify something like $mail_version
+on this command line. This produces inconsistent results with
+different versions of the make(1) command. </p>
+
+<h4><a name="shared_tips"> 4.4.4 Tips for distribution maintainers
+</a></h4>
+
+<ul>
+
+<li> <p> The shlib_directory parameter setting also provides the
+default directory for database plugin files with a relative pathname
+in the file dynamicmaps.cf. </p>
+
+<li> <p> The meta_directory parameter specifies the location of the
+files dynamicmaps.cf, postfix-files, and some multi-instance template
+files. The meta_directory parameter has the same default value as
+the config_directory parameter (typically, /etc/postfix or
+/usr/local/etc/postfix). For backwards compatibility with Postfix
+2.6 .. 2.11, specify "meta_directory = $daemon_directory" in main.cf
+before installing or upgrading Postfix, or specify "meta_directory
+= /path/name" on the "make makefiles", "make install" or "make
+upgrade" command line. </p>
+
+<li> <p> The configuration file dynamicmaps.cf will automatically
+include files under the directory dynamicmaps.cf.d, just like the
+configuration file postfix-files will automatically include files
+under the directory postfix-files.d. Thanks to this, you can install
+or deinstall a database plugin package without having to edit
+postfix-files or dynamicmaps.cf. Instead, you give that plugin its
+own configuration files under dynamicmaps.cf.d and postfix-files.d, and
+you add or remove those configuration files along with the database
+plugin dynamically-linked object. </p>
+
+<li> <p> Each configuration file under the directory dynamicmaps.cf.d
+must have the same format as the configuration file dynamicmaps.cf.
+There is no requirement that these configuration file *names* have a
+specific format. </p>
+
+<li> <p> Each configuration file under the directory postfix-files.d
+must have the same format as the configuration file postfix-files.
+There is no requirement that these configuration file *names* have a
+specific format. </p>
+
+</ul>
+
+<h3><a name="build_opt">4.5 - Building with optional features</a></h3>
+
+By default, Postfix builds as a mail system with relatively few
+bells and whistles. Support for third-party databases etc.
+must be configured when Postfix is compiled. The following documents
+describe how to build Postfix with support for optional features:
+
+<blockquote>
+<table border="1">
+
+<tr> <th>Optional feature </th> <th>Document </th> <th>Availability</th>
+</tr>
+
+<tr> <td> Berkeley DB database</td> <td>DB_README</td> <td> Postfix
+1.0 </td> </tr>
+
+<tr> <td> LMDB database</td> <td>LMDB_README</td> <td> Postfix
+2.11 </td> </tr>
+
+<tr> <td> LDAP database</td> <td>LDAP_README</td> <td> Postfix
+1.0 </td> </tr>
+
+<tr> <td> MySQL database</td> <td>MYSQL_README</td> <td> Postfix
+1.0 </td> </tr>
+
+<tr> <td> Perl compatible regular expression</td> <td>PCRE_README</td>
+<td> Postfix 1.0 </td> </tr>
+
+<tr> <td> PostgreSQL database</td> <td>PGSQL_README</td> <td>
+Postfix 2.0 </td> </tr>
+
+<tr> <td> SASL authentication </td> <td>SASL_README</td> <td>
+Postfix 1.0 </td> </tr>
+
+<tr> <td> SQLite database</td> <td>SQLITE_README</td> <td> Postfix
+2.8 </td> </tr>
+
+<tr> <td> STARTTLS session encryption </td> <td>TLS_README</td> <td>
+Postfix 2.2 </td> </tr>
+
+</table>
+
+</blockquote>
+
+<p> Note: IP version 6 support is compiled into Postfix on operating
+systems that have IPv6 support. See the IPV6_README file for details.
+</p>
+
+<h3><a name="build_over">4.6 - Overriding built-in parameter default
+settings</a></h3>
+
+<h4>4.6.1 - Postfix 3.0 and later </h4>
+
+<p> All Postfix configuration parameters can be changed by editing
+a Postfix configuration file, except for one: the parameter that
+specifies the location of Postfix configuration files. In order to
+build Postfix with a configuration directory other than /etc/postfix,
+use: </p>
+
+<blockquote>
+<pre>
+$ make makefiles config_directory=/some/where ...other arguments...
+$ make
+</pre>
+</blockquote>
+
+<p> The command "make makefiles name=value ..." will replace the
+string MAIL_VERSION at the end of a configuration parameter value
+with the Postfix release version. Do not try to specify something
+like $mail_version on this command line. This produces inconsistent
+results with different versions of the make(1) command. </p>
+
+<p> Parameters whose defaults can be specified in this way are
+listed below. See the postconf(5) manpage for a description
+(command: "<tt>nroff -man man/man5/postconf.5 | less</tt>"). </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>parameter name</th> <th>typical default</th> </tr>
+
+<tr> <td>command_directory</td> <td>/usr/sbin</td> </tr>
+
+<tr> <td>config_directory</td> <td>/etc/postfix</td> </tr>
+
+<tr> <td>default_database_type</td> <td>hash</td> </tr>
+
+<tr> <td>daemon_directory</td> <td>/usr/libexec/postfix</td> </tr>
+
+<tr> <td>data_directory</td> <td>/var/lib/postfix</td> </tr>
+
+<tr> <td>html_directory</td> <td>no</td> </tr>
+
+<tr> <td>mail_spool_directory</td> <td>/var/mail</td> </tr>
+
+<tr> <td>mailq_path</td> <td>/usr/bin/mailq</td> </tr>
+
+<tr> <td>manpage_directory</td> <td>/usr/local/man</td> </tr>
+
+<tr> <td>meta_directory</td> <td>/etc/postfix</td> </tr>
+
+<tr> <td>newaliases_path</td> <td>/usr/bin/newaliases</td> </tr>
+
+<tr> <td>openssl_path</td> <td>openssl</td> </tr>
+
+<tr> <td>queue_directory</td> <td>/var/spool/postfix</td> </tr>
+
+<tr> <td>readme_directory</td> <td>no</td> </tr>
+
+<tr> <td>sendmail_path</td> <td>/usr/sbin/sendmail</td> </tr>
+
+<tr> <td>shlib_directory</td> <td>/usr/lib/postfix</td> </tr>
+
+</table>
+
+</blockquote>
+
+<h4>4.6.2 - All Postfix versions </h4>
+
+<p> All Postfix configuration parameters can be changed by editing
+a Postfix configuration file, except for one: the parameter that
+specifies the location of Postfix configuration files. In order to
+build Postfix with a configuration directory other than /etc/postfix,
+use: </p>
+
+<blockquote>
+<pre>
+$ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
+$ make
+</pre>
+</blockquote>
+
+<p> IMPORTANT: Be sure to get the quotes right. These details matter
+a lot. </p>
+
+<p> Parameters whose defaults can be specified in this way are
+listed below. See the postconf(5) manpage for a description
+(command: "<tt>nroff -man man/man5/postconf.5 | less</tt>"). </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr><th> Macro name </th> <th>default value for</th> <th>typical
+default</th> </tr>
+
+<tr> <td>DEF_COMMAND_DIR</td> <td>command_directory</td>
+<td>/usr/sbin</td> </tr>
+
+<tr> <td>DEF_CONFIG_DIR</td> <td>config_directory</td>
+<td>/etc/postfix</td> </tr>
+
+<tr> <td>DEF_DB_TYPE</td> <td>default_database_type</td>
+<td>hash</td> </tr>
+
+<tr> <td>DEF_DAEMON_DIR</td> <td>daemon_directory</td>
+<td>/usr/libexec/postfix</td> </tr>
+
+<tr> <td>DEF_DATA_DIR</td> <td>data_directory</td>
+<td>/var/lib/postfix</td> </tr>
+
+<tr> <td>DEF_MAILQ_PATH</td> <td>mailq_path</td> <td>/usr/bin/mailq</td>
+</tr>
+
+<tr> <td>DEF_HTML_DIR</td> <td>html_directory</td>
+<td>no</td> </tr>
+
+<tr> <td>DEF_MANPAGE_DIR</td> <td>manpage_directory</td>
+<td>/usr/local/man</td> </tr>
+
+<tr> <td>DEF_NEWALIAS_PATH</td> <td>newaliases_path</td>
+<td>/usr/bin/newaliases</td> </tr>
+
+<tr> <td>DEF_QUEUE_DIR</td> <td>queue_directory</td>
+<td>/var/spool/postfix</td> </tr>
+
+<tr> <td>DEF_README_DIR</td> <td>readme_directory</td>
+<td>no</td> </tr>
+
+<tr> <td>DEF_SENDMAIL_PATH</td> <td>sendmail_path</td>
+<td>/usr/sbin/sendmail</td> </tr>
+
+</table>
+
+</blockquote>
+
+<p> Note: the data_directory parameter (for caches and pseudo-random
+numbers) was introduced with Postfix version 2.5. </p>
+
+<h3><a name="build_other">4.7 - Overriding other compile-time
+features</a></h3>
+
+<p> The general method to override Postfix compile-time features
+is as follows: </p>
+
+<blockquote>
+<pre>
+$ make makefiles name=value name=value...
+$ make
+</pre>
+</blockquote>
+
+<p> The following is an extensive list of names and values. </p>
+
+<table border="1">
+
+<tr> <th colspan="2"> Name/Value </th> <th> Description </th> </tr>
+
+<tr> <td colspan="2"> AUXLIBS="object_library..."</td> <td> Specifies
+one or more non-default object libraries. Postfix 3.0 and later
+specify some of their database library dependencies with AUXLIBS_CDB,
+AUXLIBS_LDAP, AUXLIBS_LMDB, AUXLIBS_MYSQL, AUXLIBS_PCRE, AUXLIBS_PGSQL,
+AUXLIBS_SDBM, and AUXLIBS_SQLITE, respectively. </td> </tr>
+
+<tr> <td colspan="2"> CC=compiler_command</td> <td> Specifies a
+non-default compiler. On many systems, the default is <tt>gcc</tt>.
+</td> </tr>
+
+<tr> <td colspan="2"> CCARGS="compiler_arguments..."</td> <td>
+Specifies non-default compiler arguments, for example, a non-default
+<tt>include</tt> directory. The following directives turn
+off Postfix features at compile time:</td> </tr>
+
+<tr> <td> </td> <td> -DNO_DB </td> <td> Do not build with Berkeley
+DB support. By default, Berkeley DB support is compiled in on
+platforms that are known to support this feature. If you override
+this, then you probably should also override DEF_DB_TYPE as described
+in section 4.6. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_DNSSEC </td> <td> Do not build with DNSSEC
+support, even if the resolver library appears to support it. </td>
+</tr>
+
+<tr> <td> </td> <td> -DNO_DEVPOLL </td> <td> Do not build with
+Solaris <tt>/dev/poll</tt> support. By default, <tt>/dev/poll</tt>
+support is compiled in on Solaris versions that are known to support
+this feature. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_EPOLL </td> <td> Do not build with Linux
+EPOLL support. By default, EPOLL support is compiled in on platforms
+that are known to support this feature. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_EAI </td> <td> Do not build with EAI
+(SMTPUTF8) support. By default, EAI support is compiled in when
+the "icuuc" library and header files are found. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_INLINE </td> <td> Do not require support
+for C99 "inline" functions. Instead, implement argument typechecks
+for non-printf/scanf-like functions with ternary operators and
+unreachable code. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_IPV6 </td> <td> Do not build with IPv6
+support. By default, IPv6 support is compiled in on platforms that
+are known to have IPv6 support. Note: this directive is for debugging
+And testing only. It is not guaranteed to work on all platforms.
+If you don't want IPv6 support, set "inet_protocols = ipv4" in
+main.cf.
+</td> </tr>
+
+<tr> <td> </td> <td> -DNO_KQUEUE </td> <td> Do not build with FreeBSD
+/ NetBSD / OpenBSD / MacOSX KQUEUE support. By default, KQUEUE
+support is compiled in on platforms that are known to support it.
+</td> </tr>
+
+<tr> <td> </td> <td> -DNO_NIS </td> <td> Do not build with NIS or
+NISPLUS support. NIS is not available on some recent Linux
+distributions. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_NISPLUS </td> <td> Do not build with
+NISPLUS support. NISPLUS is not available on some recent Solaris
+distributions. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_PCRE </td> <td> Do not build with PCRE
+support. By default, PCRE support is compiled in when the
+<tt>pcre-config</tt> utility is installed. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_POSIX_GETPW_R </td> <td> Disable support
+for POSIX <tt>getpwnam_r/getpwuid_r</tt>. By default Postfix uses
+these where they are known to be available. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_SIGSETJMP </td> <td> Use
+<tt>setjmp()/longjmp()</tt> instead of <tt>sigsetjmp()/siglongjmp()</tt>.
+By default, Postfix uses <tt>sigsetjmp()/siglongjmp()</tt> when
+they are known to be available. </td> </tr>
+
+<tr> <td> </td> <td> -DNO_SNPRINTF </td> <td> Use <tt>sprintf()</tt>
+instead of <tt>snprintf()</tt>. By default, Postfix uses
+<tt>snprintf()</tt> except on ancient systems. </td> </tr>
+
+<tr> <td colspan="2"> DEBUG=debug_level </td> <td> Specifies a
+non-default compiler debugging level. The default is "<tt>-g</tt>".
+Specify DEBUG= to turn off debugging. </td> </tr>
+
+<tr> <td colspan="2"> OPT=optimization_level </td> <td> Specifies
+a non-default optimization level. The default is "<tt>-O</tt>".
+Specify OPT= to turn off optimization. </td> </tr>
+
+<tr> <td colspan="2"> POSTFIX_INSTALL_OPTS=-option... </td> <td>
+Specifies options for the <tt>postfix-install</tt> command, separated
+by whitespace. Currently, the only supported option is
+"<tt>-keep-build-mtime</tt>". </td> </tr>
+
+<tr> <td colspan="2"> SHLIB_CFLAGS=flags </td> <td> Specifies
+non-default compiler options for building Postfix dynamically-linked
+libraries and database plugins. The typical default is "-fPIC".
+</td> </tr>
+
+<tr> <td colspan="2"> SHLIB_RPATH=rpath </td> <td> Specifies
+a non-default runpath for Postfix dynamically-linked libraries. The
+typical default is "'-Wl,-rpath,${SHLIB_DIR}'". </td> </tr>
+
+<tr> <td colspan="2"> SHLIB_SUFFIX=suffix </td> <td> Specifies
+a non-default suffix for Postfix dynamically-linked libraries and
+database plugins. The typical default is "<tt>.so</tt>". </td>
+</tr>
+
+<tr> <td colspan="2"> WARN="warning_flags..." </td> <td> Specifies
+non-default compiler warning options for use when "<tt>make</tt>"
+is invoked in a source subdirectory only. </td>
+</tr>
+
+</table>
+
+<h3><a name="build_proc">4.8 - Support for thousands of processes</a></h3>
+
+<p> The number of connections that Postfix can manage simultaneously
+is limited by the number of processes that it can run. This number
+in turn is limited by the number of files and sockets that a single
+process can open. For example, the Postfix queue manager has a
+separate connection to each delivery process, and the anvil(8)
+server has one connection per smtpd(8) process. </p>
+
+<p> Postfix version 2.4 and later have no built-in limits on the
+number of open files or sockets, when compiled on systems that
+support one of the following: </p>
+
+<ul>
+
+<li> BSD kqueue(2) (FreeBSD 4.1, NetBSD 2.0, OpenBSD 2.9),
+
+<li> Solaris 8 /dev/poll,
+
+<li> Linux 2.6 epoll(4).
+
+</ul>
+
+
+<p> With other Postfix versions or operating systems, the number
+of file descriptors per process is limited by the value of the
+FD_SETSIZE macro. If you expect to run more than 1000 mail delivery
+processes, you may need to override the definition of the FD_SETSIZE
+macro to make select() work correctly: </p>
+
+<blockquote>
+<pre>
+$ make makefiles CCARGS=-DFD_SETSIZE=2048
+</pre>
+</blockquote>
+
+<p> Warning: the above has no effect on some Linux versions.
+Apparently, on these systems the FD_SETSIZE value can be changed
+only by using undocumented interfaces. Currently, that means
+including &lt;bits/types.h&gt; directly (which is not allowed) and
+overriding the __FD_SETSIZE macro. Beware, undocumented interfaces
+can change at any time and without warning. </p>
+
+<p> But wait, there is more: none of this will work unless the
+operating system is configured to handle thousands of connections.
+See the TUNING_README guide for examples of how to increase the
+number of open sockets or files. </p>
+
+<h3><a name="build_final">4.9 - Compiling Postfix, at last</a></h3>
+
+<p> If the command </p>
+
+<blockquote>
+<pre>
+$ make
+</pre>
+</blockquote>
+
+<p> is successful, then you can proceed to <a href="#install">install</a>
+Postfix (section 6).
+
+<p> If the command produces compiler error messages, it may be time
+to search the web or to ask the postfix-users@postfix.org mailing
+list, but be sure to search the mailing list archives first. Some
+mailing list archives are linked from http://www.postfix.org/. </p>
+
+<h2> <a name="5">5 - Porting Postfix to an unsupported system</a> </h2>
+
+<p> Each system type that Postfix knows is identified by a unique
+name. Examples: SUNOS5, FREEBSD4, and so on. When porting Postfix
+to a new system, the first step is to choose a SYSTEMTYPE name for
+the new system. You must use a name that includes at least 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. </p>
+
+<p> Add a case statement to the "makedefs" shell script in the
+source code 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, instead of the emulated one. </p>
+
+<p> Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h
+include file. You may have to invent new feature macro names.
+Please choose sensible feature macro names such as HAS_DBM or
+FIONREAD_IN_SYS_FILIO_H.
+
+<p> I strongly recommend against using "#ifdef SYSTEMTYPE" in
+individual source files. While this may look like the quickest
+solution, it will create a mess when newer versions of the same
+SYSTEMTYPE need to be supported. You're likely to end up placing
+"#ifdef" sections all over the source code again. </p>
+
+<h2><a name="install">6 - Installing the software after successful
+compilation</a></h2>
+
+<p> This text describes how to install Postfix from source code.
+See the PACKAGE_README file if you are building a package for
+distribution to other systems. </p>
+
+<h3>6.1 - Save existing Sendmail binaries</h3>
+
+<p> <a name="save">IMPORTANT</a>: 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. </p>
+
+<ul>
+
+<li> <p> Some systems implement a mail switch mechanism where
+different MTAs (Postfix, Sendmail, etc.) can be installed at the
+same time, while only one of them is actually being used. Examples
+of such switching mechanisms are the FreeBSD mailwrapper(8) or the
+Linux mail switch. In this case you should try to "flip" the switch
+to "Postfix" before installing Postfix. </p>
+
+<li> <p> If your system has no mail switch mechanism, execute the
+following commands (your sendmail, newaliases and mailq programs
+may be in a different place): </p>
+
+<pre>
+# 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
+</pre>
+
+</ul>
+
+<h3>6.2 - Create account and groups</h3>
+
+<p> Before you install Postfix for the first time you need to
+create an account and a group:</p>
+
+<ul>
+
+<li> <p> Create a user account "postfix" with a user id and group
+id that are not used by any other user account. 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 and group file entries look like this: </p>
+
+<blockquote>
+<pre>
+/etc/passwd:
+ postfix:*:12345:12345:postfix:/no/where:/no/shell
+
+/etc/group:
+ postfix:*:12345:
+</pre>
+</blockquote>
+
+<p> Note: there should be no whitespace before "postfix:". </p>
+
+<li> <p> Create a group "postdrop" with a group id that is not used
+by any other user account. Not even by the postfix user account.
+My group file entry looks like:
+
+<blockquote>
+<pre>
+/etc/group:
+ postdrop:*:54321:
+</pre>
+</blockquote>
+
+<p> Note: there should be no whitespace before "postdrop:". </p>
+
+</ul>
+
+<h3>6.3 - Install Postfix</h3>
+
+<p> To install or upgrade Postfix from compiled source code, run
+one of the following commands as the super-user:</p>
+
+<blockquote>
+<pre>
+# make install (interactive version, first time install)
+
+# make upgrade (non-interactive version, for upgrades)
+</pre>
+</blockquote>
+
+<ul>
+
+<li> <p> The interactive version ("make install") asks for pathnames
+for Postfix data and program files, and stores your preferences in
+the main.cf file. <b> If you don't want Postfix to overwrite
+non-Postfix "sendmail", "mailq" and "newaliases" files, specify
+pathnames that end in ".postfix"</b>. </p>
+
+<li> <p> The non-interactive version ("make upgrade") needs the
+/etc/postfix/main.cf file from a previous installation. If the file
+does not exist, use interactive installation ("make install")
+instead. </p>
+
+<li> <p> If you specify name=value arguments on the "make install"
+or "make upgrade" command line, then these will take precedence
+over compiled-in default settings or main.cf settings. </p>
+
+<p> The command "make install/upgrade name=value ..." will replace
+the string MAIL_VERSION at the end of a configuration parameter
+value with the Postfix release version. Do not try to specify
+something like $mail_version on this command line. This produces
+inconsistent results with different versions of the make(1) command.
+</p>
+
+</ul>
+
+<h3>6.4 - Configure Postfix</h3>
+
+<p> Proceed to the section on how you wish to run Postfix on
+your particular machine: </p>
+
+<ul>
+
+<li> <p> <a href="#send_only">Send</a> mail only, without changing
+an existing Sendmail installation (section 7). </p>
+
+<li> <p> <a href="#send_receive">Send and receive</a> mail via a
+virtual host interface, still without any change to an existing
+Sendmail installation (section 8). </p>
+
+<li> <p> Run Postfix <a href="#replace">instead of</a> Sendmail
+(section 9). </p>
+
+</ul>
+
+<h2><a name="send_only">7 - Configuring Postfix to send mail
+only</a></h2>
+
+<p> 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. </p>
+
+<p> Follow the instructions in the "<a href="#mandatory">Mandatory
+configuration file edits</a>" in section 10, and review the "<a
+href="#hamlet">To chroot or not to chroot</a>" text in section
+11. </p>
+
+<p> You MUST comment out the "smtp inet" entry in /etc/postfix/master.cf,
+in order to avoid conflicts with the real sendmail. Put a "#"
+character in front of the line that defines the smtpd service: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/master.cf:
+ #smtp inet n - n - - smtpd
+</pre>
+</blockquote>
+
+<p> Start the Postfix system: </p>
+
+<blockquote>
+<pre>
+# postfix start
+</pre>
+</blockquote>
+
+<p> or, if you feel nostalgic, use the Postfix sendmail command: </p>
+
+<blockquote>
+<pre>
+# sendmail -bd -qwhatever
+</pre>
+</blockquote>
+
+<p> and watch your maillog file for any error messages. The pathname
+is /var/log/maillog, /var/log/mail, /var/log/syslog, or something
+else. Typically, the pathname is defined in the /etc/syslog.conf
+file. </p>
+
+<blockquote>
+<pre>
+$ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+</pre>
+</blockquote>
+
+<p> Note: the most important error message is logged first. Later
+messages are not as useful. </p>
+
+<p> In order to inspect the mail queue, use one of the following
+commands: </p>
+
+<blockquote>
+<pre>
+$ mailq
+
+$ sendmail -bp
+
+$ postqueue -p
+</pre>
+</blockquote>
+
+<p> See also the "<a href="#care">Care and feeding</a>" section 12
+below. </p>
+
+<h2><a name="send_receive">8 - Configuring Postfix to send and
+receive mail via virtual interface</a></h2>
+
+<p> 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. </p>
+
+<p> To create a virtual network interface address, study your
+system ifconfig manual page. The command syntax could be any
+of: </p>
+
+<blockquote>
+<pre>
+# <b>ifconfig le0:1 &lt;address&gt; netmask &lt;mask&gt; up</b>
+# <b>ifconfig en0 alias &lt;address&gt; netmask 255.255.255.255</b>
+</pre>
+</blockquote>
+
+<p> In the /etc/postfix/main.cf file, I would specify </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ myhostname = virtual.host.tld
+ inet_interfaces = $myhostname
+ mydestination = $myhostname
+</pre>
+</blockquote>
+
+<p> Follow the instructions in the "<a href="#mandatory">Mandatory
+configuration file edits</a>" in section 10, and review the "<a
+name="#hamlet">To chroot or not to chroot</a>" text in section
+11. </p>
+
+<p> Start the Postfix system: </p>
+
+<blockquote>
+<pre>
+# postfix start
+</pre>
+</blockquote>
+
+<p> or, if you feel nostalgic, use the Postfix sendmail command: </p>
+
+<blockquote>
+<pre>
+# sendmail -bd -qwhatever
+</pre>
+</blockquote>
+
+<p> and watch your maillog file for any error messages. The pathname
+is /var/log/maillog, /var/log/mail, /var/log/syslog, or something
+else. Typically, the pathname is defined in the /etc/syslog.conf
+file. </p>
+
+<blockquote>
+<pre>
+$ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+</pre>
+</blockquote>
+
+<p> Note: the most important error message is logged first. Later
+messages are not as useful. </p>
+
+<p> In order to inspect the mail queue, use one of the following
+commands: </p>
+
+<blockquote>
+<pre>
+$ mailq
+
+$ sendmail -bp
+
+$ postqueue -p
+</pre>
+</blockquote>
+
+<p> See also the "<a href="#care">Care and feeding</a>" section 12
+below. </p>
+
+<h2><a name="replace">9 - Running Postfix instead of Sendmail</a></h2>
+
+<p> Prior to installing Postfix you should <a href="#save">save</a>
+any 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: </p>
+
+<blockquote>
+<pre>
+# /usr/sbin/sendmail.OFF -q
+</pre>
+</blockquote>
+
+<p> Note: this is old sendmail syntax. Newer versions use separate
+processes for mail submission and for running the queue. </p>
+
+<p> After you have visited the "<a href="#mandatory">Mandatory
+configuration file edits</a>" section below, you can start the
+Postfix system with: </p>
+
+<blockquote>
+<pre>
+# postfix start
+</pre>
+</blockquote>
+
+<p> or, if you feel nostalgic, use the Postfix sendmail command: </p>
+
+<blockquote>
+<pre>
+# sendmail -bd -qwhatever
+</pre>
+</blockquote>
+
+<p> and watch your maillog file for any error messages. The pathname
+is /var/log/maillog, /var/log/mail, /var/log/syslog, or something
+else. Typically, the pathname is defined in the /etc/syslog.conf
+file. </p>
+
+<blockquote>
+<pre>
+$ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+</pre>
+</blockquote>
+
+<p> Note: the most important error message is logged first. Later
+messages are not as useful. </p>
+
+<p> In order to inspect the mail queue, use one of the following
+commands: </p>
+
+<blockquote>
+<pre>
+$ mailq
+
+$ sendmail -bp
+
+$ postqueue -p
+</pre>
+</blockquote>
+
+<p> See also the "<a href="#care">Care and feeding</a>" section 12
+below. </p>
+
+<h2><a name="mandatory">10 - Mandatory configuration file edits</a></h2>
+
+<p> Note: the material covered in this section is covered in more
+detail in the BASIC_CONFIGURATION_README document. The information
+presented below is targeted at experienced system administrators.
+</p>
+
+<h3>10.1 - Postfix configuration files</h3>
+
+<p> By default, Postfix configuration files are in /etc/postfix.
+The two most important files are main.cf and master.cf; these files
+must be owned by root. Giving someone else write permission to
+main.cf or master.cf (or to their parent directories) means giving
+root privileges to that person. </p>
+
+<p> In /etc/postfix/main.cf, you will have to set up a minimal number
+of configuration parameters. Postfix configuration parameters
+resemble shell variables, with two important differences: the first
+one is that Postfix does not know about quotes like the UNIX shell
+does.</p>
+
+<p> You specify a configuration parameter as: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ parameter = value
+</pre>
+</blockquote>
+
+<p> and you use it by putting a "$" character in front of its name: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ other_parameter = $parameter
+</pre>
+</blockquote>
+
+<p> You can use $parameter before it is given a value (that is the
+second main difference with UNIX shell variables). The Postfix
+configuration language uses lazy evaluation, and does not look at
+a parameter value until it is needed at runtime. </p>
+
+<p> Whenever you make a change to the main.cf or master.cf file,
+execute the following command in order to refresh a running mail
+system: </p>
+
+<blockquote>
+<pre>
+# postfix reload
+</pre>
+</blockquote>
+
+<h3>10.2 - Default domain for unqualified addresses</h3>
+
+<p> First of all, you must specify what domain will be appended to an
+unqualified address (i.e. an address without @domain.tld). The
+"myorigin" parameter defaults to the local hostname, but that is
+probably OK only for very small sites. </p>
+
+<p> Some examples (use only one): </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ myorigin = $myhostname (send mail as "user@$myhostname")
+ myorigin = $mydomain (send mail as "user@$mydomain")
+</pre>
+</blockquote>
+
+<h3>10.3 - What domains to receive locally</h3>
+
+<p> Next you need to specify what mail addresses Postfix should deliver
+locally. </p>
+
+<p> Some examples (use only one): </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ mydestination = $myhostname, localhost.$mydomain, localhost
+ mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
+ mydestination = $myhostname
+</pre>
+</blockquote>
+
+<p>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.</p>
+
+<h3>10.4 - Proxy/NAT interface addresses </h3>
+
+<p> The proxy_interfaces parameter specifies all network addresses
+that Postfix receives mail on by way of a proxy or network address
+translation unit. You may specify symbolic hostnames instead of
+network addresses. </p>
+
+<p> IMPORTANT: You must specify your proxy/NAT external addresses
+when your system is a backup MX host for other domains, otherwise
+mail delivery loops will happen when the primary MX host is down.
+</p>
+
+<p> Example: host behind NAT box running a backup MX host. </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+</pre>
+</blockquote>
+
+<h3>10.5 - What local clients to relay mail from </h3>
+
+<p> 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 into the Internet. The default setting includes all
+subnetworks that the machine is attached to. This may give relay
+permission to too many clients. My own settings are: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ mynetworks = 168.100.189.0/28, 127.0.0.0/8
+</pre>
+</blockquote>
+
+<h3>10.6 - What relay destinations to accept from strangers </h3>
+
+<p> If your machine is on an open network then you must also specify
+whether Postfix will forward mail from strangers. The default
+setting will forward mail to all domains (and subdomains of) what
+is listed in $mydestination. This may give relay permission for
+too many destinations. Recommended settings (use only one): </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ relay_domains = (do not forward mail from strangers)
+ relay_domains = $mydomain (my domain and subdomains)
+ relay_domains = $mydomain, other.domain.tld, ...
+</pre>
+</blockquote>
+
+<h3>10.7 - Optional: configure a smart host for remote delivery</h3>
+
+<p> 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. </p>
+
+<p> Some examples (use only one): </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ relayhost = $mydomain
+ relayhost = [mail.$mydomain]
+</pre>
+</blockquote>
+
+<p> The form enclosed with <tt>[]</tt> eliminates DNS MX lookups. </p>
+
+<p> By default, the SMTP client will do DNS lookups 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: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ disable_dns_lookups = yes
+</pre>
+</blockquote>
+
+<p> The STANDARD_CONFIGURATION_README file has more hints and tips for
+firewalled and/or dial-up networks. </p>
+
+<h3>10.8 - Create the aliases database</h3>
+
+<p> Postfix uses a Sendmail-compatible aliases(5) table to redirect
+mail for local(8) recipients. Typically, this information is kept
+in two files: in a text file /etc/aliases and in an indexed file
+/etc/aliases.db. The command "postconf alias_maps" will tell you
+the exact location of the text file. </p>
+
+<p> First, be sure to update the text file with aliases for root,
+postmaster and "postfix" that forward mail to a real person. Postfix
+has a sample aliases file /etc/postfix/aliases that you can adapt
+to local conditions. </p>
+
+<blockquote>
+<pre>
+/etc/aliases:
+ root: you
+ postmaster: root
+ postfix: root
+ bin: root
+ <i>etcetera...</i>
+</pre>
+</blockquote>
+
+<p> Note: there should be no whitespace before the ":". </p>
+
+<p> Finally, build the indexed aliases file with one of the
+following commands: </p>
+
+<blockquote>
+<pre>
+# newaliases
+# sendmail -bi
+</pre>
+</blockquote>
+
+<h2><a name="hamlet">11 - To chroot or not to chroot</a></h2>
+
+<p> Postfix daemon processes can be configured (via master.cf) to
+run in a chroot jail. 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. </p>
+
+<p> With the exception of Postfix daemons that deliver mail locally
+and/or that execute non-Postfix commands, every Postfix daemon can
+run chrooted. </p>
+
+<p> Sites with high security requirements should consider to chroot
+all daemons that talk to the network: the smtp(8) and smtpd(8)
+processes, and perhaps also the lmtp(8) client. The author's own
+porcupine.org mail server runs all daemons chrooted that can be
+chrooted. </p>
+
+<p> 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.
+</p>
+
+<p> 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
+in the source code distribution has a collection of scripts that
+help you set up Postfix chroot environments on different operating
+systems. </p>
+
+<p> Additionally, you almost certainly need to configure syslogd
+so that it listens on a socket inside the Postfix queue directory.
+Examples for specific systems: </p>
+
+<dl>
+
+<dt> FreeBSD: </dt>
+
+<dd> <pre>
+# mkdir -p /var/spool/postfix/var/run
+# syslogd -l /var/spool/postfix/var/run/log
+</pre> </dd>
+
+<dt> Linux, OpenBSD: </dt>
+
+<dd> <pre>
+# mkdir -p /var/spool/postfix/dev
+# syslogd -a /var/spool/postfix/dev/log
+</pre> </dd>
+
+</dl>
+
+<h2><a name="care">12 - Care and feeding of the Postfix system</a></h2>
+
+<p> Postfix daemon processes run in the background, and log problems
+and normal activity to the syslog daemon. The names of logfiles
+are specified in /etc/syslog.conf. At the very least you need
+something like: </p>
+
+<blockquote>
+<pre>
+/etc/syslog.conf:
+ mail.err /dev/console
+ mail.debug /var/log/maillog
+</pre>
+</blockquote>
+
+<p> IMPORTANT: the syslogd will not create files. You must create
+them before (re)starting syslogd. </p>
+
+<p> IMPORTANT: on Linux you need to put a "-" character before
+the pathname, e.g., -/var/log/maillog, otherwise the syslogd
+will use more system resources than Postfix does. </p>
+
+<p> Hopefully, the number of problems will be small, but it is a good
+idea to run every night before the syslog files are rotated: </p>
+
+<blockquote>
+<pre>
+# postfix check
+# egrep '(reject|warning|error|fatal|panic):' /some/log/file
+</pre>
+</blockquote>
+
+<ul>
+
+<li> <p> The first line (postfix check) causes Postfix to report
+file permission/ownership discrepancies. </p>
+
+<li> <p> The second line looks for problem reports from the mail
+software, and reports how effective the relay and junk mail access
+blocks are. This may produce a lot of output. You will want to
+apply some postprocessing to eliminate uninteresting information.
+</p>
+
+</ul>
+
+<p> The <a href="DEBUG_README.html#logging"> DEBUG_README </a>
+document describes the meaning of the "warning" etc. labels in
+Postfix logging. </p>
+
+</body>
+
+</html>