EnGarde Secure Linux Postfix HOWTO

Pete O'Hara, pete@guardiandigital.com

v1.5, 16 January 2002

This document describes configuring the Postfix mail server on the EnGarde Secure Linux operating system. Postfix attempts to be fast, easy to administer, and hopefully secure, while at the same time being sendmail compatible enough to not upset your users.

Introduction

This document outlines running Postfix on EnGarde. Wietse Venema, author of Postfix and several other staple Internet security products, describes Postfix as an "attempt to provide an alternative to the widely-used Sendmail program. Postfix attempts to be fast, easy to administer, and hopefully secure, while at the same time being sendmail compatible enough to not upset your users."

General Information

Postfix configuration is done with the files in /etc/postfix, /usr/lib/libexec/postfix contains the postfix daemons, and /var/spool/postfix contains the mail queues and various mail staging directories and the default chroot directory "etc" (if chrooting is configured).

/etc/postfix will be the most important directory as it controls postfix's behaviour. This directory holds the two configuration files and the aliases, virtual, transport, access, and other databases in maps.

Configuration

RBL

The RBL system is used to restrict who can send mail to your site. The topic is one of pros and cons and the choice is left up to the administrator as to whether they should be deployed or not, therefore by default EnGarde does not have them turned on. RBL support is provided by several postfix parameters. The "maps_rbl_domains" parameter can be set to include several rbl domains. The default is blackholes.mail-abuse.org. A multiple domain setting would look something like: 
maps_rbl_domains = blackholes.mail-abuse.org, 
	dialups.mail-abuse.org, relays.mail-abuse.org
Note: - THE ABOVE IS ONLY AN EXAMPLE AND IS OUTDATED DUE TO RECENT CHANGES TO MAPS POLICY. AS OF 07/31/01 MAPS - Mail Abuse Prevention System (mail-abuse.org) SERVICE IS NOW AVAILABLE BY SUBSCRIPTION ONLY. THEREFORE IT IS UP TO THE MAIL ADMININSTRATOR AS TO WHAT TO USE AS A REPLACEMENT, IF ANY.
Note: Any whitespace character can be used as line-continuation.
Once the maps_rbl_domains parameter is set it can now be referenced by several other mail restriction type parameters by putting reject_maps_rbl in the options list. Here is an example of including it in the smtpd_recipient_restrictions parameter. (You typically want to add RBL checks at the end of the list as a DNS lookup is performed when doing an RBL check - by putting them at the end of a list you avoid performing the check as much as possible as the smtp connection in question may be caught by a more leftmost restriction. There is an exception to this: at least in postfix-20010329 postfix's smtpd sends a warning if the options are listed AFTER check_relay_domains. (The options list is processed from left to right). This is because check_relay_domains returns either OK or REJECT and therefore no further restrictions are evaluated.

smtpd[25690]: warning: restriction `reject_maps_rbl' after 
`check_relay_domains' is ignored
So putting reject_maps_rbl after all of the other options and BEFORE check_relay_domains works. 
smtpd_recipient_restrictions = reject_unknown_client, permit_mynetworks,
  reject_maps_rbl, check_relay_domains

Sample Postfix with EnGarde Secure Linux Setup via the WebTool

Here is simple example of setting up a top level mail server to receive mail for two domains, acme.com and wiley-coyote.org. The server is smtp.acme.com and therefore it is in the acme.com domain. As a courtesy to one of Acme's biggest customers, smtp.acme.com will receive and forward mail for the wiley-coyote.org domain to mail.wiley-coyote.orig as well as store Acme's mail locally in the standard /var/spool/mail directory using the WebTool.

  1. This assumes that you have the WebTool running on your new mail server and you are connected and logged into the WebTool as "admin".

    From the main page follow the links "System Management" -> "Mail Server Management" -> "Mail Server Configuration". If this is server is going to have a connection to the Internet (most likely through some sort of protection like a firewall) you would leave the "Deliver directly" button set. This is the setting we are going to use as our example is to configure a top level mail server. (If this were some internal server you would set up a connection to a relay server instead by clicking on the button to the left of the text field and filling in the field with the FQDN of the the mail relay. You may need to check with your network administrator/architect for the appropriate server name).

    Finish by clicking on "Save Options".

  2. Back out of this page and go into "Domain Management". Here you would enter the domain into the "Domain" text field that you would like to receive mail for and store locally. In this case it would be acme.com. You would also enter an email address for the person who would be postmaster of this domain into the "Postmaster" text field.

    Finish by clicking on "Add New Domain". You should now see the name acme.com listed in blue lettering below the "Domain Management" title bar at the top of the page verifying that the new domain has been created.

  3. To add users to this domain click on the blue acme.com text and you will enter a page where you can add users. Here you define username-recipient pairs. For example to create the local user joe@acme.com enter "joe" in the E-Mail Username text field and "joe" in the "Recipient" text field. Click on "Add New" and you will see "joe@acme.com" appear in the "E-Mail Address" field in the lower portion of the page with a cooresponding "joe" in the "Recipient" field.

    Note: Local users such as "joe" above must be actual local users on this server. If they don't currently exist they can be created via "Main Page -> "System Management" under the "Local User Management" section. Refer to the Guardian Digital EnGarde Linux User Manual on how to create new users.
    We can also create users with remote destinations by entering their remote address in the recipient field. To create "bob@acme.com" and have his mail sent to "bob@guardiandigital.com" enter "bob" in the "E-Mail Username" field and "bob@guardiandigital.com" in the "Recipient" field.

  4. Now to set up mail routing for the domain "wiley-coyote.org" back out 2 levels of pages and enter the "Mail Routing" link. Enter "wiley-coyote.org" in the "Domain" field and an the mail server "mail.wiley-coyote.org" in the "Relay mail to" field. Follow this by clicking on "Add New" and "wiley-coyote.org" will appear as an "Existing Mail Route" verifying that the new mail relay was created.

  5. The mail server configuration for our example is now complete. Our server "smtp.acme.com" will now receive mail for "joe" and store in /var/spool/mail/joe. It will also receive mail for "bob@acme.com" and forward it to "bob@guardiandigital.com" and it will forward all mail for "wiley-coyote.org" to mail.wiley-coyote.org.

    Note: Obviously to forward mail to "wiley-coyote.org" it would have to receive mail for "wiley-coyote.org". This means that smtp.acme.com would have to defined somewhere as a mail server for "wiley-coyote.org". This would most commonly be done through smtp.acme.com being defined via an MX for the "wiley-coyote.org" domain in DNS.

Under the Hood of the WebTool Mail Server Configuration

Here is a more behind the scenes look at the Postfix configuration.

  1. Alias Database

    Almost everything will be done in the /etc/postfix directory. Let's start setting up the "aliases" file. The default aliases file has most of your typical administrative users: 

    postmaster:	root
MAILER-DAEMON:  postmaster
bin:            root
daemon:         root
games:          root
ingres:         root
nobody:         root
system:         root
toor:           root
foo:            root
falken:         root
admin:          root
manager:        root
dumper:         root
operator:       root
	.
	.
	.
postfix:        postmaster
root: 		SOME REAL PERSON
    Note: In many versions the above "postfix: root" used to be "root: postfix" accompanied by a comment to change the "postfix" to some real person. Now the last two lines above are recommended instead. The most likely candidate for the "root" alias would be an administrator type of person. The new line should look like this: 
    root: 		joe@acme.com
    In many situations this could be the only change that needs to be made to this file. Once you have finished editing aliases you need to create the aliases.db file by running 
    postalias hash:/etc/postfix/aliases
    Or, simply run newaliases with no command line options.

  2. Virtual Domain Database

    The next step would be to define the two virtual domains. This is done in the virtual map so we will edit /etc/postfix/virtual following the format described above: 

    acme.com		ACME.COM VIRTUAL DOMAIN
joe@acme.com		joe
bill@acme.com		bill
jack@acme.com		jack@slacker.com
admins@acme.com		joe, jack@slacker.com	

wiley-coyote.org 		WILEY-COYOTE.ORG VIRTUAL DOMAIN
wiley@wiley-coyote.org		wiley
roadrunner@wiley-coyote.org	roadrunner
    Remember that on the first line of each domain section there needs to be some sort of text field following the domain name, here I used "ACME.COM VIRTUAL DOMAIN". We have just defined the users for acme.com. The local users (the ones where this a just a user name WITHOUT the @domainname suffix) must be local users on this server such as "joe". Any mail sent to "joe" will typically end up in /var/spool/mail/joe. Any mail received by this mail server for user jack@acme.com will get forwarded to jack@slacker.com. Once again, once editing the text file "virtual" has been completed, the database file "virtual.db" must be created with 
    postmap hash:/etc/postfix/virtual
  3. Transport Database

    You may have noticed that we did not define the virtual domain "wiley-coyote.org". This is because, as stated above, all of the mail received for this domain will be forwarded on to a mail server at wiley-coyote.org. This is defined in the "transport" map and the /etc/postfix/transport text file should look something like this: 

    wiley-coyote.org	smtp:mail.wiley-coyote.org
.wiley-coyote.org	smtp:mail.wiley-coyote.org
    The first line says that all mail received for wiley-coyote.org will be sent to the mail server mail.wiley-coyote.org via the "smtp" transport. The smtp specifies the postfix smtp daemon found in /usr/libexec/postfix directory which utilizes the standard SMTP protocol. This will be the most commonly used transport for most situations. The second line with the "." prepended to it says to send mail addressed to any subdomains of wiley-coyote.org to mail.wiley-coyote.org as well. Since this example is describing a typical real life scenario it is included as more often than not you would want subdomain mail to go to the same top level mail server as the parent domain.

    If we had multiple domains to forward to we would just simply add an extra two lines to the transport file for each domain: 

    wiley-coyote.org	smtp:mail.wiley-coyote.org
.wiley-coyote.org	smtp:mail.wiley-coyote.org
jack-jill.com		smtp:smtp.jack-jill.com
.jack-jill.com		smtp:smtp.jack-jill.com
bugsbunny.net		smtp:mail.bugsbunny.net
.bugsbunny.net		smtp:mail.bugsbunny.net
    Now create the transport.db database file with 
    postmap hash:/etc/postfix/transport
  4. Main.cf Configuration File

    The last thing to do is to edit /etc/postfix/main.cf file. This is where we tell Postfix about the newly created databases along with other configuration settings. As previously mentioned, there are around 200 parameters that can be set in this file to alter the behaviour of Postfix operation. I will leave most of those to you to explore. The default main.cf that comes with the EnGarde distribution will function just as it is as a workstation mail server. This means that it will handle mail for itself only. This mainly determined by several parameters with their default values being:

    If Postfix is serving as just a workstation mail service mydestination will be defined as "$myhostname, localhost.$mydomain". "mydestination" defines what addresses will be received locally. Here only mail addressed to the hosts' FQDN (as stated by $myhostname) or "localhost.this-machines-domainname" (as stated by $mydomain) will be received.

    To change the server from a workstation server to a domain server you would alter mydestination to include an additional definition of $mydomain to state that it recieves mail for any machine or subdomain of $mydomain and would look like this: 

    mydestination = $myhostname, localhost.$mydomain, $mydomain
    Note: Many times a domain server will also have relay_domains to include more than just its own domain, which is discussed shortly.

    The myorigin = $myhostname parameter specifies the address that locally posted mail appears to come from.

    The main.cf also refers to the maps that we have just created with the following lines: 

    alias_maps = hash:/etc/postfix/aliases
virtual_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport
    The SMTP command VRFY is disabled for security reasons: 
    disable_vrfy_command = yes
    Note: THE FOLLOWING IS A CHANGE THAT MUST BE MADE BY HAND

    The relay_domains parameter states what domains this server will relay mail for. By default this is set to $mydestination which represents the local machine's hostname smtp.acme.com and localhost.acme.com.

    YOU WILL NEED TO ADD ANY DOMAINS DEFINED IN THE VIRTUAL AND TRANSPORT MAPS TO THIS PARAMETER OR MAIL WILL NOT BE RELAYED TO THEM!

    So for our example the relay_domains parameter in main.cf will look like this: 

    relay_domains = $mydestination, acme.com, wiley-coyote.org
    Our example is of a top level mail server, meaning that it is the mail gateway that is connected to the Internet by which all mail coming in to and going out of the organization will pass. Therefore no "relayhost" needs to be defined as it delivers mail directly to/from the Internet. If this were an internal mail server it would need to define a "relayhost" to send outgoing mail to. The "relayhost" parameter needs to be set to do this. Although it does not fit this example server many mail servers are not top level servers and this parameter will have to be set to be able to deliver mail properly. Check with your network/mail administrator to determine what would be a suitable server to define for this role. The "relayhost" parameter can either be set to a hostname or an IP address: 
    relayhost = RELAYSERVERNAME
    OR 
    relayhost = 111.222.333.444
  5. Start Postfix

    Postfix is now ready to go and can be started by running the initscript: 

    /etc/init.d/postfix start
    It would be a good idea at this point to monitor /var/log/mail.log and verify that Postfix has started without error. You may want to send a couple of test e-mails now and watch the entries as the mail gets delivered.

Maintenance

Debugging

  1. If things are acting strangely here is a simple and quick first step that could save you a lot of time.

    To check the current configuration: 

    /usr/sbin/postfix check
    validates the Postfix mail system configuration and will warn about bad directory/file ownership or permissions, and create missing directories.

  2. In debug mode Postfix will spew out more info than you might ever want so look at /var/log/mail.log to verify that you need more information first. If more information is needed then restart the postfix daemon in "verbose" mode with the "-v" option. To do this you would stop the daemon first: 
    /etc/init.d/postfix stop
    then start by hand with the "-v" option and put on the reading glasses to view /var/log/mail.log: 
    /usr/sbin/postfix -v start
  3. Another cool Postfix debug feature is accessible through 2 configuration parameters: 
    debug_peer_level = 2
debug_peer_list = some.domain
    The "debug_peer_level" parameter specifies the increment in verbose logging level when an SMTP client or server host name or address matches a pattern in the "debug_peer_list" parameter.

    The "debug_peer_list" parameter specifies an optional list of domain or network patterns, /file/name patterns or type:name tables. When an SMTP client or server host name or address matches a pattern, increase the verbose logging level by the amount specified in the "debug_peer_level" parameter.

Conclusion

I would like to express thanks to Ralf Hildebrandt for taking the time to review this HOWTO. I value his expertise of Postfix and have incorporated his suggestions which are always welcome. - P. O'Hara