The configuration options we just discussed represent only a small amount of what can be done with Postfix. We now talk about how this all works together and what it provides to you as a mail server administrator.
Note Any parameter that starts with an SMTPD controls some part of an incoming SMTP-based connection. Similarly, any parameters starting with SMTP refer to outgoing (to other SMTP servers) connections.
Postfix's relaying policy (allowing users to send mail through the mail sever) is dictated by default via the mynetworks parameter. The mynetworks parameter tells Postfix what networks or specific hosts are "trusted" by Postfix to allow mail to be sent through the mail server to any destination based on this trust. When the mynetworks parameter has been set, you can then use the variable to explicitly tell Postfix the networks that your installation trusts.
Figure 17-1 shows an example setup for your always-connected corporate mail server. You can see where the mynetworks parameter comes into use. By default, the mynetworks parameter contains your localhost network (127.0.0.0/8) and your network connections that have been configured in your system.
In this example, you can see the Postfix server in the DMZ (demilitarized zone) on an IP address of 192.168.0.4/24. Your internal network is in the subnet of 10.0.0.0/24. Given Postfix's default mynetworks parameter, the 10.0.0.0/24 network will not be allowed to relay mail through Postfix because it is not part of the Postfix server's network. To remedy this, you need to add the 10.0.0.0/24 network to the mynetworks clause:
mynetworks = 127.0.0.0/8, 192.168.0.0/24, 10.0.0.0/24
This entry now allows relaying from localhost, the DMZ network, and also your internal network.
When mynetworks has been configured, the parameter smtpd_recipient_restrictions actually allows the relaying to take place. As you can see from the default main.cf configuration we talked about before, this parameter has two objectives:
♦ To allow all relays from machines that are in mynetworks
♦ To deny all other relays using the reject_unauth_destination (reject all unauthorized connections) clause
Be very careful with what you put into the mynetworks clause because this is the easiest way to configure Postfix to be an open relay. I pointed out the DMZ issue so you can understand that even if you think that locally the configuration is sane, as soon as you add the Internet to that equation, it can get a lot more difficult to see the bigger picture.
Postfix also allows relaying to any domains listed in relay_domains. This parameter by default contains whatever is in the $mydomain parameter, which by default is your machine's configured domain. If you use the default setting, any untrusted sender (not in mynetworks) can relay mail through Postfix to any user at $mydomain. It should be obvious why this is the default, as this would mean that Postfix would accept mail for the domain it is hosting.
Another parameter that is very useful is mydestination. In a real world example, we host our domain, palmcoder.net, and also the domain planetsuse.org. Even though by default our Postfix installation configures itself to accept mail for the palmcoder.net domain, we need to tell it that it should accept mail for the planetsuse.org domain (if we don't, the mail will be rejected). To do this, we add an updated mydestination clause.
mydestination = palmcoder.net, planetsuse.org
In this example, we are creating a virtual domain — that is, a domain that physically (in terms of our server's configuration) does not exist, but we are hosting in the same realm as palmcoder.net (our physical server domain).
Our login on this server is justin, and it exists as a real user. Any mail for [email protected] palmcoder.net is delivered to Justin's mailbox, and with the mydestination clause, any mail for [email protected] is delivered to the same mailbox.
This works because Postfix believes it is the final destination for palmcoder.net and planetsuse.org. When the mail has gone through the mail system, Postfix will decide that the user justin does indeed exist and will deliver any mail on any domain that is listed in mydestination to justin.
This type of virtual domain is called a sendmail virtual domain because it makes no distinction between one user and another regardless of the destination domain listed in the mydestination clause.
If you want to make that distinction, you use a Postfix-style virtual domain that correlates the fact that a user and domain make up a unique user on the system.
It is always advisable to make mail sent from your network as Internet friendly as possible. Why? If you are running Postfix on a laptop, and you send mail using the system's mail command, and if you have not configured address rewriting, the mail will be sent in the form of [email protected] This is not pretty to see and can prove problematic for people trying to reply to you. To get around these problems, you need to masquerade your mail headers so that they are clean before they leave the system.
The masquerade_domains parameter controls this behavior by rewriting the domain portion of a mail message before it leaves Postfix. For example, if your machine is called foo.bar.com, and your domain is bar.com, you need to remove the "foo" component. The masquerade_domains parameter can take your domain as a parameter to combat this.
masquerade_domains = bar.com
This tells Postfix that for anything that is below bar.com (which includes foo.bar.com), rewrite the address to bar.com.
If you do not want to masquerade all users' addresses, as is common for the root user so that you know what machine the email was from internally, then you use the masquerade_
masquerade_exceptions = root
Configuring an always-on server
In this section, we take our example of Figure 17-1 and modify the default configuration to set up an always-on, Internet facing mail server.
In Listing 17-2, you can see the updated configuration for the domain palmcoder.net with some omissions for clarity.
Listing 17-2: Updated Postfix main.cf Configuration mail_spool_directory = /var/mail canonical_maps = hash:/etc/postfix/canonical virtual_maps = hash:/etc/postfix/virtual relocated_maps = hash:/etc/postfix/relocated transport_maps = hash:/etc/postfix/transport sender_canonical_maps = hash:/etc/postfix/sender_canonical masquerade_exceptions = root masquerade_classes = envelope_sender, header_sender, header_recipient myhostname = laptop.palmcoder.net program_directory = /usr/lib/postfix inet_interfaces = 127.0.0.1, 192.168.0.4 masquerade_domains = palmcoder.net mydestination = $myhostname, localhost.$mydomain, $mydomain disable_dns_lookups = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_helo_required = no smtpd_recipi'ent_restri'cti'ons = permi't_mynetworks,reject_unauth_destinati'on alias_maps = hash:/etc/aliases mailbox_size_limit = 0 message_size_limit = 10240000
In this example, we have configured Postfix to accept mail for $mydomain, which is found when Postfix strips off the domain portion of $myhostname. We could have explicitly set the domain, but the less retyping of any configuration changes, the better. This is the default behavior of Postfix, but it is better to explicitly set this in the configuration for verbosity.
The i net_interfaces clause has been manually changed to listen on the real network address of the Ethernet card. (We have substituted the real address and replaced it with a non-routable one.) By default, the SUSE Postfix configuration listens only on the loopback address, which means your installation will not receive mail from the outside world.
This scenario is unlikely to be used these days as most mail clients hold off from sending mail when you are offline, but the configuration is still relevant to other situations.
When you do not have a constant connection to the Internet, it is a good idea to stop Postfix from attempting to send mail when it is not connected to the Internet. To do this, you need to defer the sending for a later date by telling Postfix that it should defer sending mail via SMTP using the defer_transports parameter.
defer_transports = smtp
When the machine is connected to the Internet, you then need to tell Postfix to send the mail it has queued. The sendmail command can be used to queue up mails, as follows:
When the command has completed, use the mailq command to query whether your mails have been sent. The mailq command also tells you if there are any mails stuck in the queue for any reason. Common problems will be that Postfix cannot communicate with another mail server because of connectivity problems or the local mail cannot be delivered because a user is over quota.
To stop your machine from unnecessarily trying to look up host names when processing mail in the queue, you need to turn off address lookups via DNS, so you need to change the default disable_dns_lookups parameter as follows:
disable_dns_lookups = yes
Usually if you are on a dial-up, you will pass on all of your mail to another, dedicated mail server for further handling, in which case you need to configure a relay host using the relayhost parameter:
relayhost = mail.palmcoder.net
Now, any mail that is not local to your mail server will be sent via SMTP to the machine mai 1 .palmcoder .net.
Note The rel ay host parameter is used in larger sites where the use of department mail servers propagates mail through an organization with a central mail hub.
Was this article helpful?