The Postfix master daemon launches all of the other Postfix services as they are needed. The various services, and how they are run, are specified in the master.cf file.
The master configuration file works like other Postfix configuration files. A comment is marked by a # character at the beginning of a line. Comments and blank lines are ignored. Long lines can continue onto subsequent lines by starting the carry-over lines with whitespace.
Example 4-2 shows a sample file. Each column contains a specific configuration option. A dash in a column indicates the default setting for that column. Some default values come from parameters in the main.cf file.
Example 4-2. Sample master.cf file
#= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = # service type private unpriv chroot wakeup maxproc command + args # name (yes) (yes) (yes) (never) (100) #= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = smtp inet n - y - - smtpd pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - y - - smtp relay unix - - y - - smtp -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} cyrus unix - n n - - pipe user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
The following list describes each column in the file, including its default setting:
service name
The name of the component. The rules for naming a service depend on the type of service, as specified in the transport type column (see below).
transport type
Valid transport types are inet, unix, and fifo. Each of these indicates a method of communication for this service.
The inet type refers to network sockets. A network socket component can communicate with other processes on the same machine or other machines on the network. Network sockets use a combination of a system's IP address and the port used for connecting. They are commonly written in combination as the host or IP address and the port, separated by a colon. The name of an inet transport in master.cf is a socket specified as the host and port. The name can be written as just the port if it's on the local system. You can use a hostname or an IP address for the host, and the port can be the actual port number, or its symbolic name. (Symbolic names for ports come from the /etc/services file. See your system documentation.)
The unix type refers to Unix domain sockets, and fifo refers to named pipes. Both are used for communication between processes on the same machine. Both Unix domain sockets and FIFOs use special files for their communications. The names for unix and fifo components follow the same naming rules as for valid Unix filenames without directories. Postfix creates special communications files using the service name. Unix domain sockets and named pipes are standard Unix interprocess communications tools. If you would like more information about them, refer to a text on Unix programming.
Table 4-1 shows examples of valid service names for the various transport types.
Service name |
Transport type |
Description |
---|---|---|
smtp |
inet |
Name for the smtpd daemon. The name is the symbolic name for the SMTP port. |
127.0.0.1:10025 |
inet |
A component that listens on the loopback interface on port 10025. |
465 |
inet |
A component that listens on the local host on port 465. |
maildrop |
unix |
A component that is invoked through Postfix's pipe daemon. |
pickup |
fifo |
A Postfix FIFO component. |
private
Access to some components is restricted to the Postfix system itself. This column is marked with a y for private access (the default) or an n for public access. inet components must be marked n for public access, since network sockets are necessarily available to other processes.
unpriv
Postfix components run with the least amount of privilege required to accomplish their tasks. They set their identity to that of the unprivileged account specified by the mail_owner parameter. The default installation uses postfix. The default value of y for this column indicates that the service runs under the normal unprivileged account. Services that require root privileges are marked with n.
chroot
Many components can be chrooted for additional security. The chroot location is specified in the queue_directory parameter in master.cf. The default is for a service to run in a chroot environment; however, the normal installation marks all components with an n so they are not chrooted when they run. Chrooting a service adds a level of complexity that you should thoroughly understand before taking advantage of the added security. See Section 4.8 later in the chapter for more information on running Postfix services in a chroot environment.
wakeup
Some components require a wake-up timer to kick them into action at the specified interval. The pickup daemon is one example. At its default setting of 60 seconds, the master daemon wakes it up every minute to see if any new messages have arrived in the maildrop queue. The other services that require a wake-up are the qmgr and flush daemons. A question mark character (?) can be added at the end of the time to indicate that a wake-up event should be sent only if the component is being used. A 0 for the time interval indicates that no wake-up is required. The default is 0, since only the three components mentioned require a wake-up. The values as they are set in the Postfix distribution should work for almost all situations. Other services should not have wakeup enabled.
maxproc
Limits the number of processes that can be invoked simultaneously. If unspecified here, the value comes from the parameter default_process_limit in main.cf, which is set to 100 by default. A setting of 0 means no process limit. You may want to adjust maxproc settings if you run Postfix on a system with limited resources or you want to optimize different aspects of the system.
command
The actual command used to execute a service is listed in the final column. The command is specified with no path information, because it is expected to be in the Postfix daemon directory specified by the daemon_directory parameter in main.cf. By default the directory is /usr/libexec/postfix. All of the Postfix commands can be specified with one or more -v options to turn on increasingly more verbose logging information, which can be helpful if you must troubleshoot a problem. You can also enable information for a debugging program with the -D option. See the DEBUG_README file that comes with the Postfix distribution for more information on debugging if necessary.
Each of the Postfix daemons has its own set of options that can be specified after the command itself. (See the manpages for the individual daemons to learn about the available options.) You can specify only Postfix commands in the command column. If you want to execute your own commands, use the Postfix pipe daemon. See the Postfix pipe manpage for more information.
If main.cf offers configuration information for a component, you can override that information in master.cf by providing an alternative in an -o option. To create a specialized smtp client service, for example, add another entry to master.cf such as the following:
smtp-quick unix - - n - - smtp -o smtp_connect_timeout=5s
There can be no spaces between the parameter and the equals sign and the assigned value. As configured in the example, smtp-quick is a specialized smtp service that doesn't wait as long for a server to respond when it tries to connect. This SMTP client follows the configuration in main.cf, but uses a different value for the smtp_connect_timeout parameter. You'll see more examples later in this chapter and elsewhere in the book.
Introduction
Prerequisites
Postfix Architecture
General Configuration and Administration
Queue Management
Email and DNS
Local Delivery and POP/IMAP
Hosting Multiple Domains
Mail Relaying
Mailing Lists
Blocking Unsolicited Bulk Email
SASL Authentication
Transport Layer Security
Content Filtering
External Databases
Appendix A. Configuration Parameters
Appendix B. Postfix Commands
Appendix C. Compiling and Installing Postfix
Appendix D. Frequently Asked Questions