9.3 The Corporate Environment

This section of this document makes the following assumptions about your environment; your domain is both local and registered (real, in other words), your net access is dedicated with a static IP address, you are using DNS and you control it directly or can get your upstream provider to implement changes. We're going to use a fictional company called company.com to implement our examples.

9.3.1 Postfix on the Firewall

So we have a network setup using 10.0.0.0 behind a firewall. Our IP Masquerading is all set up and it works great. Now we need e-mail and we need it now. You've heard about this lightning quick MTA called Postfix and you want to get it running quickly on your brand new Red Hat Linux machine. Not a problem... Get and install the i686 RPM for Postfix. Now we need to edit “/etc/postfix/main.cf”. Here's what needs to go in it:

    #/etc/postfix/main.cf
    #
    # config file for bosshog.company.com
    # date: 11 Nov 1999
    # created by: Joe Sysadmin <joe@company.com>
    #
    # we need to know who we are
    myhostname = bosshog.company.com
    mydomain = company.com
    mydestination = $mydomain, $myhostname, localhost.$mydomain
    myorigin = $mydomain
    #
    # listen for everything both inside and out
    #
    inet_interfaces = all
    #
    # gotta make sure our networks are listed
    #
    mynetworks = 10.0.0.0/8, 127.0.0.0/8
    #
    # tell the postmaster about mail problems
    #
    notify_classes = resource, software, bounce, policy
    #
    # lets keep the spam to a bare minimum
    #
    maps_rbl_domains = rbl.maps.vix.com, dul.maps.vix.com
    smtpd_client_restrictions = 
    					 permit_mynetworks, 
					 check_client_access hash:/etc/postfix/access, 
					 reject_maps_rbl, 
					 reject_unknown_hostname
    smtpd_sender_restrictions = 
    					 permit_mynetworks, 
					 check_sender_access hash:/etc/postfix/access
    # notice the use of the same access file in both entries above. 
    # This allows you to map [45]XX, OK and REJECT entries in the same file
    # which means less work for you and for me
    # lets set up the virtual table... we will probably need it
    # don't forget to map it “postmap virtual”
    virtual_maps = hash:/etc/postfix/virtual 
    # let's also set up a relocation map for folks who leave the company
    # oh... don't forget to map it “postmap relocated”
    relocated_maps = hash:/etc/postfix/relocated
    # the rest of the mandatory stuff
    #
    # we need simple aliases and we might decide to start some mailing lists
    #
    alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/majordomo
    #
    # we don't do uucp here 
    # 
    default_transport = smtp
    #
    # who we run as 
    # 
    mail_owner = postfix
    #
    # privileges have to be set 
    # 
    default_privs = nobody
    #
    # where is everything?
    #
    queue_directory = /var/spool/postfix 
    program_directory = /usr/libexec/postfix 
    command_directory = /usr/sbin 
    daemon_directory = /usr/libexec/postfix 
    mail_spool_directory = /var/spool/mail 
    mailbox_command = /usr/bin/procmail
    #
    # rate limiting please
    #
    local_destination_concurrency_limit = 2 
    default_destination_concurrency_limit = 10 
    #
    # debugging stuff just in case
    #
    debug_peer_level = 2
    #
    # the next command is very useful if we have troubles... let's comment it out but we don't want to lose it
    #
    #debugger_command = /usr/bin/strace -p $process_id -o /tmp/smtpd.$process_id & sleep 5
    #
    # end of config
    

That's it, our configuration is done. Now we have to issue the following commands:

    cd /etc/postfix
    newaliases
    postmap virtual
    postmap access
    postmap relocated
    /etc/rc.d/init.d/postfix start
    

In order, this hashes our aliases and majordomo files and then maps each of our map files. Finally, we start Postfix.

9.3.2 About the map files

In our example for company.com we used several map files and it would probably be a big help if you had some idea about what goes in them. What follows is an example for each:

    #virtual map file
    #
    # not used in this scenario as we only have one domain
    #
    
    #access map file
    #
    # note: this file only accepts 3 forms of input
    # [45]XX $message, REJECT, OK
    #
    ispy99@spamnet.cn     550 Go away
    makeabuck@mlm.dom     550 You've got to be kidding me
    allspam.dom     550 Spam is not accepted here
    badguy.net     REJECT
    250.192     REJECT
    goodguy@somewhere.com     OK
    #
    
    #relocated map file
    #
    # note: all of these people have moved on
    sarah@company.com     sarah.smith@newcompany.com
    bob@company.com     robert.smith@newcompany.com
    

9.3.3 What if I want an internal (protected) mail host?

If company.com needs to protect their mail host by putting it inside the firewall you will need to do a couple of things. First of all the firewall host itself will have to accept connections on port 25 (SMTP) and redirect traffic to the internal host. It can do this with firewall rules or by running an MTA itself which does nothing but forward inbound mail to the internal machine and accepting and forwarding outbound mail from the internal host. The firewall choice is not within the scope of this document. If you choose to run an MTA on the firewall its configuration should be very simple. Essentially you will need everything we just discussed but we will add recipient_canonical_maps = hash:/etc/postfix/recipient_canonical. With this file we can redirect mail to the internal host. We would do it like this:

    #recipient_canonical map file
    #
    # send all mail for company.com to our internal host
    user@company.com     	user@our.internal.host
    otheruser@company.com	otheruser@our.internal.host

    etc.
    

We could also route all mail for company.com to the internal host without this mapping but this could cause some problems as all mail inbound for company.com would always go to the internal host and there may be some mail which you wouldn't want to go there. For example, what if you wanted to run a listserv for company.com. Would you want all of this mail to traverse your local area network? That might not be such a good idea. Note that the same thing could be done using the plain old aliases file but the aliases file only works for this if the user has a local account on the machine where the alias file exists.

9.3.4 What about .forward files?

Ah... the end all, be all, of personal control. Postfix works fine with these but file permissions are an issue. Here's a sample:

    #.forward file
    me@somewhere-else.net
    #end
    

Don't forget to set the permissions on this file. chmod 0640 ~/.forward should do nicely.

    # this is a .procmailrc file and not a .forward file
    #forward all mail to my home address
    :0 
    *
    ! myname@home.dom
    #end
    

Now why would you want to use a .procmailrc file instead of a .forward file? Simple... more power and much finer control. Lets say you wanted to extend control of this a little more by limiting the size of what gets forwarded. Here's how:

    #this is also a .procmailrc instead of a .forward file
    # forward all mail less than 2k in size to my home address
    :0
    * < 2000
    ! myname@home.dom
    #end
    

If you need some more examples have a close look at man procmailex. With the latest version of procmail the required permissions for a .procmailrc file are 0640 so don't forget to set them.