|
|
< Day Day Up > |
|
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.
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 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
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
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
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
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.
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
| Note |
See the Postfix FAQ at www.postfix.org for detailed information on how to set up Postfix for a gateway, a local workstation, or a host directly connected to the Internet (null server). |
Postfix parameters let you configure methods for controlling what it politely refers to as unsolicited commercial mail (UCM).
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.
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.
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.
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.
|
|
< Day Day Up > |
|
| This HTML Help has been published using the chm2web software. |