Red Hat [Electronic resources] : The Complete Reference Enterprise Linux Fedora Edition؛ The Complete Reference نسخه متنی

Postfix

Postfix is a fast, secure, and flexible MTA designed to replace Sendmail while maintaining as much compatibility as possible. Written by Wietse Venema and originally released as the IBM Secure Mailer, it is now available under the GNU license (www.postfix.org). Postfix was created with security in mind, treating all incoming mail as potential security risks. Postfix uses many of the same Sendmail directories and files and makes use of Sendmail wrappers, letting Sendmail clients interact seamlessly with Postfix servers. Postfix is also easier to configure, using its own configuration file. Red Hat now provides Postfix along with Sendmail.

Instead of one large program, Postfix is implemented as a collection of smaller programs, each designed to perform a specific mail-related task. A Postfix master daemon runs continuously and manages the use of the other Postfix daemons, running them only as needed. A bounce daemon handles undeliverable mail, a trivial-rewrite daemon redirects messages, and the showq daemon provides information on the print queues.

Postfix Commands

Several Postfix commands allow you to manage your server tasks. The

sendmail command sends messages. You use

mailq to display the status of your mail queues. The

newaliases command takes mail aliases listed in the aliases files and stores them in a database file that can be used by Postfix. The

postmap command is used to maintain various database files used by Postfix, such as the alias file for mail aliases and the access file that restricts messages received by the server. In addition, Postfix provides lower-level tools all beginning with the term

post , such as the

postalias command, which maintains the alias database, and

postcat , which displays print queue files.

Postfix Configuration: main.cf

Postfix configuration is handled by setting parameters in its configuration file, main.cf. Red Hat installs a default /etc/postfis/main.cf file with Postfix, with most of the essential configuration values already set. Parameter names tend to be user friendly. For example, directory locations are specified by parameters ending in the term

directory , such as

queue_directory for the location of Postfix queues and

daemon_directory for the location of the Postfix daemons. Defaults are already implemented for most parameters. For example, defaults are set for particular resource controls, such as message size, time limits, and the number of allowed messages per queue. You can edit the main.cf file to change the parameter values to meet your own needs. After making any changes, you only need to reload the configuration using the

postfix

reload command:

postfix reload

Network Parameters

You will most likely need to set several network parameters. To ease this process, Postfix defines parameters that hold key network information, such as

myhostname , which holds the hostname of your system, and

mydomain , which holds the domain name of your network. For example,

myhostname would be set to the host turtle.mytrek.com, whereas

mydomain would be just mytrek.com. Parameters like

myhostname and

mydomain are themselves used as values assigned to other parameters. In the next example,

myhostname and

mydomain are set to the host the mail server is running on and its network domain:

myhostname=turtle.mytrek.com
mydomain=mytrek.com

The

myorigin parameter specifies the origin address for e-mail sent by the server. By default, this is set to the value of the parameter

myhostname , as shown here. Note that a

$ precedes the

myhostname variable to evaluate it.

myorigin=$myhostname

If you are using a single system directly attached to the Internet, you may want to keep this configuration, labeling mail as being sent by your host. However, if your system is operating as a gateway for a network, your mail server is sending out mail from different hosts on that network. You may wish to change the origin address to the domain name, so that mail is perceived as sent from the domain.

myorigin=$mydomain

Local Networks

The

mydestination parameter holds the list of domains that your mail server will receive mail for. By default, these include localhost and your system's hostname.

mydestination = $myhostname localhost.$mydomain

If you want the mail server to receive mail for an entire local network, you need to also specify its domain name. That way, the server can receive mail addressed just to the domain, instead of your specific host.

mydestination = $myhostname localhost.$mydomain $mydomain

Also, if your host goes by other hostnames and there are DNS records identifying your host by those names, you need to specify those names also. For example, your host could also be a Web server to which mail could be directed. A host turtle.mytrek.com may also be identified as the Web site www.mytrek.com. Both names would have to be listed in the

mydestination parameter.

mydestination = $myhostname localhost.$mydomain $mydomain www.$mydomain

If your system is a gateway for one or more local networks, you can specify them with the

mynetworks parameter. This allows your mail server to relay mail addressed to those networks. Networks are specified using their IP addresses. The

relay_domains parameter lets you specify domain addresses of networks for which you can relay messages. By default, this is set to

mydestination :

mynetworks=192.168.0.0
relay_domains=$mydestination

Hosts within the local network connected to the Internet by a gateway need to know the identity of the relay host, the mail server. You set this with the

relayhost parameter. Also,

myorigin should be set to just

mydomain . If there is a DNS server identifying the gateway as the mail server, you can just set

relayhost to the value of

mydomain . If not, then

relayhost should be set to the specific hostname of the gateway/mail server. If your local network is not running a DNS server, be sure to set

disable_dns_lookups to

yes .

relay_host=$mydomain

Direct Connections

If your system is directly connected to the Internet and you use an ISP for receiving mail, you can configure Postfix as a null client to just send mail. Set the

relay_host parameter to just your own domain name. Also, in the master.cf file, comment out the SMTP server and local delivery agent entries.

relayhost = $mydomain

Masquerading

If your mail server is operating on a gateway for a local network and you want to hide the hosts in that network, you can opt to masquerade the local hosts, letting it appear that all mail is coming from the domain in general, instead of a particular host. To set this option, you use the

masquerade_domains parameter. In the following example, all mail sent by a local host such as rabbit.mytrek.com will be addressed as just coming from mytrek.com. Thus a message sent by the user chris@rabbit.mytrek.com is sent out as coming from chris@mytrek.com.

masquerade_domains = $mydomain

Received mail is not masqueraded by default. This allows Postfix to still deliver received mail to particular hosts. If you want received mail to also be masqueraded, you have to add the

envelope_recipients parameter to the list of values assigned to the

masquerade_class parameter. In that case, Postfix will no longer be able to deliver received mail.

Virtual Domains

If your network has implemented virtual domains, you will need to set up a virtual domain table and then specify that table with the

virtual_maps option. Setting up a table is a simple matter of listing virtual names and their real addresses in a text file such as /etc/postfix/virtual. Then use the

postmap command to create a Postfix table:

postmap /etc/postfix/virtual

In the main.cf file, specify the table with the

virtual_maps parameter. Postfix will then use this table to look up virtual domains.

virtual_maps = hash:/etc/postfix/virtual

Security: UCM

Postfix parameters let you configure methods for controlling what it politely refers to as unsolicited commercial mail (UCM).

Controlling User and Host Access

With an access file, you can control access by certain users, hosts, and domains. The access file works much like the one used for Sendmail. Entries are made in a text file beginning with the user, host, or domain name or address, followed by an action to be take. A user, host, or domain can be accepted, rejected, or rejected with a message. Once entries are made, they can be installed in a Postfix database file with the

postmap command:

postmap /etc/postfix/access

You can then use the access file in various Postfix operations to control clients, recipients, and senders.

Blocking Access

Access can also be controlled by use of the Mail Abuse Prevention System (MAPS), which provides the RBL+ service, a collection of mail address DNS-based databases (mail-abuse.org). These databases, like the Realtime Blackhole List (RBL), list mail addresses that are known to be used by mail abusers. A domain or host is matched against a list maintained by the service. The service can be accessed on a local server or or directly from an online site. Various Postfix operations let you use MAPS databases to control access by clients, recipients, senders.

Header and Body Checks

With the

header_checks parameter, you can specify a Postfix table where you can list criteria for rejecting messages. The criteria are patterns that can match message headers. You can have matching messages rejected, rejected with a reply, simply deleted, or a warning logged. You have the option of taking several actions including REJECT, DISCARD, WARN, HOLD, and IGNORE.

header_checks = regexp:/etc/postfix/header_checks

The database, in this case /etc/postfix/header_checks, will have lines, each with a regular expression and a corresponding action. The regular expression can be either a standard regular expression as denoted by

regexp in the

header_checks parameter (see Chapter 8), or it can conform to a Perl Compatible Regular Expression,

prece .

The

body_checks parameters lets you check the body of text messages, line by line, using regular expressions and actions like those used for

header_checks .

Controlling Client, Senders, and Recipients

With the

smtpd_client_restrictions parameter, you can restrict access to the mail server by certain clients. Restrictions you can apply include

reject_unknown_client , which will reject any clients with unresolved addresses;

permit_mynetworks , which allows access by any clients defined by

mynetworks; and

check_client_access , which will check an access database to see if a client should be accepted or rejected. The

reject_

rbl_client and

reject_rhsbl_client will reject clients from specified domains.

smtpd_client_restrictions = permit_mynetworks, reject_unknown_client,
 check_client_access, reject_maps_rbl

The

reject_rbl_client restriction rejects domain addresses based on a specified MAPS service. The site can be an online site or a local one set up to provide it. The

reject_rhsbl_client restriction rejects host addresses.

smtpd_client_restrictions = reject_rbl_client relays.mail-abuse.org

To implement restrictions from a access file, you can use the

hash directive and the name of file.

smtpd_client_restrictions = hash:/etc/postfix/access

The corresponding

smtpd_sender_restrictions parameter works much the same way as its client counterpart but controls access from specific senders. It has many of the same restrictions and adds

reject_non_fqdn_sender , which will reject any mail header without a fully qualified domain name, and

reject_sender_login_mismatch , which will require sender verification. The

reject_rhsbl_sender restriction rejects domain addresses based on a specified MAPS service.

The

smtpd_recipient_restrictions parameter will restrict the recipients the server will accept mail for. Restrictions include

permit_auth_destination , which allows authorized messages, and

reject_auth_destination , which rejects unauthorized messages. The

check_recipient_address restriction will check local networks for recipient address, and

check_recipient_maps will reject an address not verified in recipient tables listing local, relay, and virtual recipients along with aliases. The

reject_unknown recipient_domain restriction rejects recipient addresses with no DNS entry. The

reject_rhsbl_recipient restriction rejects domain addresses based on a specified MAPS service.

You can further refine restrictions with the parameters like

smtpd_helo_restrictions , which requires a HELO command from a client. Restriction parameters include

reject_ invalid_hostname , which checks for faulty syntax,

reject_unknown_hostname for hosts with no DNS entry, and

reject_non_fqdn_hostname for hosts whose names are not fully qualified. The

strict_rfc821_envelopes parameter will implement strict envelope protocol compliance.