4.2 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.

4.2.1 Sendmail on the Firewall

So we have a network setup using behind a firewall. Our IP Masquerading is all set up and it works great. Now we need email, so it's time for sendmail. We need to edit “/usr/lib/sendmail-cf/cf/nuconfig.mc”. Here's an idea of what needs to go in it:

    dnl let's define our OS type. This one is mandatory.
    dnl the following line moves the default alias file location to /etc/mail and adds
    dnl a majordomo alias file just in case you need it in the future. Doing it this way
    dnl allows the newaliases command to function properly with both the aliases file
    dnl and the majordomo file.
    dnl if the net were a kinder gentler place we wouldn't need the next line
    define(`confPRIVACY_FLAGS', `authwarnings,needmailhelo,noexpn,novrfy')dnl
    dnl if it's not immediately deliverable let us know in 4 hours and return it if it's
    dnl not been delivered after 4 days.
    define(`confTO_QUEUERETURN', `4d')dnl 
    define(`confTO_QUEUEWARN', `4h')dnl
    dnl Let's tell the system where procmail lives
    dnl we don't need either one of the next two entries so lets remove the default
    undefine(`BITNET_RELAY') dnl 
    dnl when people move on we it will really help to give them an informative bounce
    dnl we are 'company.com' after all. Let's make it so
    dnl let's set up class w as a text file. It's easier to manage that way.
    dnl we defined the path to procmail now let's implement it
    dnl we won't be doing any uucp
    dnl with the mailertable we can redirect mail anywhere we want. Very handy 
    FEATURE(`mailertable', `hash -o /etc/mail/mailertable')dnl
    dnl with the virtusertable we can have multiple mail accounts with the same name
    FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable')dnl
    dnl the access file gives us fine grained control of our relay capability
    FEATURE(`access_db', `hash -o /etc/mail/access')dnl
    dnl note that we patched our version of sendmail to be able to use more than one rbl entry
    dnl see section 2.3.2 of this document for more information and a HOWTO. These next 3
    dnl entries are completely optional but recommended if you'd like to limit the amount
    dnl of spam you receive inbound to your domain
    FEATURE(rbl,`rbl.maps.vix.com',` Mail from $&{client_addr} rejected; see http://www.mail-abuse.org/rbl/')dnl
    FEATURE(rbl,`dul.maps.vix.com',`Mail from $&{client_addr} rejected; see http://www.mail-abuse.org/dul/')dnl 
    FEATURE(rbl,`relays.mail-abuse.org',` Mail from $&{client_addr} rejected; see http://www.mail-abuse.org/rss/')dnl
    dnl the default MDA with Red Hat Linux is procmail so let's use it. We need this line

Unless you have some special needs this ought to just about handle your requirements for an office mail server. This would probably be a good time to talk a bit about DNS.

4.2.2 Using/not using DNS and MX Records with firewalls

Red Hat, Inc. has a corporate environment (which is more complex than the one we're demonstrating here) with a firewall, DNS records and MX records and all. Let's look at it from the outside and see what it looks like:

    [root@ns /root]# nslookup 
    Default Server: localhost 
    > set type=any 
    > redhat.com. 
    Server: localhost 
    Non-authoritative answer: 
    redhat.com nameserver = ns.redhat.com 
    redhat.com nameserver = ns2.redhat.com 
    redhat.com nameserver = ns3.redhat.com 
    redhat.com nameserver = speedy.redhat.com 
    redhat.com internet address = 
    origin = ns.redhat.com 
    mail addr = noc.redhat.com 
              serial = 1999111200 
              refresh = 3600 (1H) 
              retry = 1800 (30M) 
              expire = 604800 (1W) 
              minimum ttl = 3600 (1H) 
    redhat.com            preference = 10, mail exchanger = mail.redhat.com
    Authoritative answers can be found from: 
    redhat.com           nameserver = ns.redhat.com 
    redhat.com           nameserver = ns2.redhat.com 
    redhat.com           nameserver = ns3.redhat.com 
    redhat.com           nameserver = speedy.redhat.com 
    ns.redhat.com           internet address = 
    ns2.redhat.com           internet address = 
    ns3.redhat.com           internet address = 
    speedy.redhat.com           internet address = 
    mail.redhat.com           internet address = 

But what about their MX records?

    > set type=mx 
    > redhat.com 
    Server: localhost 
    Non-authoritative answer: 
    redhat.com           preference = 10, mail exchanger = mail.redhat.com
    Authoritative answers can be found from: 
    redhat.com           nameserver = ns.redhat.com 
    redhat.com           nameserver = ns2.redhat.com 
    redhat.com           nameserver = ns3.redhat.com 
    redhat.com           nameserver = speedy.redhat.com 
    mail.redhat.com           internet address = 
    ns.redhat.com           internet address = 
    ns2.redhat.com           internet address = 
    ns3.redhat.com           internet address = 
    speedy.redhat.com           internet address =

In the case of Red Hat, Inc., you can see that there is only one MX host listed, but if you examine the headers from messages sent from their lists you will see that the list mail is actually handled by a different host. Here's a sample:

    From someone@mindspring.com Fri Nov 26 12:07:11 1999
    Return-Path: <redhat-list-request@redhat.com>
    Delivered-To: xxxxx@[]
    Received: from ns.somewhere.org (ns.somewhere.org [])
            by penguin.somewhere.org (MTA) with ESMTP id EF3F9BD78
            for <xxxxx@[]>; Fri, 26 Nov 1999 12:01:44 -0500 (EST)
    Received: by ns.somewhere.org (MTA)
            id D3B3A191D; Fri, 26 Nov 1999 12:08:49 -0500 (EST)
    Delivered-To: xxxxx@somewhere.org
    Received: from lists.redhat.com (lists.redhat.com [])
            by ns.somewhere.org (MTA) with SMTP id 8D16C191C
            for <xxxxx@somewhere.org>; Fri, 26 Nov 1999 12:08:48 -0500 (EST)
    Received: (qmail 27743 invoked by uid 501); 26 Nov 1999 16:38:49 -0000
    Resent-Date: 26 Nov 1999 16:38:49 -0000
    Resent-Cc: recipient list not shown: ;
    MBOX-Line: From redhat-list-request@redhat.com  Fri Nov 26 11:38:48 1999
    Date: Fri, 26 Nov 1999 12:12:37 -0500 (EST)
    From: someone <someone@mindspring.com>
    To: redhat-list@redhat.com
    Subject: this is a test
    Message-ID: <Pine.LNX.4.04.9911261210100.5233-100000@box.mindspring.com>
    MIME-Version: 1.0
    Content-Type: TEXT/PLAIN; charset=US-ASCII
    Resent-Message-ID: <"zbzPa2.0.om6.OUhFu"@lists.redhat.com>
    Resent-From: redhat-list@redhat.com
    Reply-To: redhat-list@redhat.com
    X-Mailing-List: <redhat-list@redhat.com> archive/latest/7134
    X-Loop: redhat-list@redhat.com
    Precedence: list
    Resent-Sender: redhat-list-request@redhat.com
    X-URL: http://www.redhat.com

In the first highlighted line above you can see that the Red Hat Linux mailing list mail is handled by lists.redhat.com which is at IP address The machine name does resolve correctly to that IP:

    [someone@boss someone]$ host domain name pointer lists.redhat.com

Why would you want to set this up this way? Really it's a good way to share the load among a variety of hosts. In this example, Red Hat, Inc. is using a host which is not an MX host to handle all of their list mail. This reduces the load by sharing the mail processing duty. In the second highlighted line you can see that lists.redhat.com is running qmail as its MTA. This is probably a good choice for the load their listserv host has to handle but, notably, it is not handling their corporate mail. Here's a sample which shows how that works:

    From xyz@redhat.com Fri Nov 26 12:20:42 1999
    Return-Path: <xyz@redhat.com>
    Delivered-To: boss@[]
    Received: from ns.somewhere.org (ns.somewhere.org [])
            by boss.somewhere.org (Postfix) with ESMTP id 5D4A2BD78
            for <boss@[]>; Tue, 23 Nov 1999 20:57:03 -0500 (EST)
    Received: by ns.somewhere.org (Postfix)
            id 076C6191D; Tue, 23 Nov 1999 21:03:47 -0500 (EST)
    Delivered-To: boss@[]
    Received: from server.somewhere.com (server.somewhere.com [])
            by ns.somewhere.org (MTA) with ESMTP id 1F3E5191C
            for <boss@[]>; Tue, 23 Nov 1999 21:03:45 -0500 (EST)
    Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com
            by server.somewhere.com (MTA) with ESMTP id AFFED1A803
            for <boss@somewhere.com>; Tue, 23 Nov 1999 20:56:59 -0500 (EST)
    Received: from chef.meridian.redhat.com
        (IDENT:root@chef.meridian.redhat.com [])
            by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id UAA07225
            for <boss@somwehere.com>; Tue, 23 Nov 1999 20:56:59 -0500
    Received: from chef.meridian.redhat.com (IDENT:xyz@localhost [])
            by chef.meridian.redhat.com (8.9.3/8.8.7) with ESMTP id UAA18366
            for <boss@somewhere.com>; Tue, 23 Nov 1999 20:56:46 -0500
    Message-Id: <199911240156.UAA18366@chef.meridian.redhat.com>
    To: Boss <boss@somewhere.com>
    Subject: Re: ISP? 
    In-reply-to: <Pine.LNX.4.21.9911231951510.15735-100000@boss.somewhere.org> 
        from Boss <boss@somewhere.org>  on Tue, 23 Nov 1999 19:52:55 EST.
    Date: Tue, 23 Nov 1999 20:56:46 -0500
    From: xyz@redhat.com

From the two highlighted lines above we can tell a couple of things. First of all the corporate mail server for Red Hat, Inc. is named lacrosse.corp.redhat.com and second it is running sendmail 8.9.3. You can also tell by looking at the next 3 highlighted lines that the sending host is also running sendmail but it appears that it may have an old sendmail.cf file running with the newer version of the daemon (note this (8.9.3/8.8.7) ) The Red Hat corporate environment is running a fairly complex mixture of MTAs to handle all of their mail. Using sendmail it's quite possible to do something very similiar to this by using the mailertable function to route mail based on the To: address. If sendmail was your MTA you could add something like this in the /etc/mail/mailertable on the MX host (mail.redhat.com):

    redhat-list@redhat.com            SMTP:[]
    redhat-list-request@redhat.com            SMTP:[]

This would route all mail to the list and the request address to the listserv host without using DNS to do it (the [ ] tell sendmail not to use DNS for delivery). Adding the other list addresses like cartman, RPM, security, etc. could all be done in the same way. For the user addresses the virtusertable could be used to accomplish the same the same thing. Like this:

    xyz@redhat.com            xyz@lacrosse.corp.redhat.com
    - or -
    xyz@redhat.com            xyz@[]

The mailertable could be used by itself to accomplish this task but it's generally a good idea to keep resource addresses and user addresses separated as they're easier to manage that way. There are several other ways to handle all of this but we hope that a few simple examples will help to get you thinking about different ways to handle mail getting around DNS or if a single host is performing MX duties for an entire domain. It's also important to point out that most environments should have a secondary MX backing up their primary. To be safe this should be done off-site so that if your connectivity goes down your mail gets stored until your primary MX comes back up. One “gotcha” which often occurs with sendmail running as a secondary MX host is that you do NOT want domains a host is secondary for listed in class $w on the secondary but you DO want them listed in /etc/mail/access on the secondary with a RELAY statement like this:

    secondary.dom            <------WRONG
    secondary.dom            RELAY <------ RIGHT

Why is this so? Think about it for a moment... domains listed in class $w are presumed to be local by sendmail and if you put a secondary domain in there the mail will start bouncing like crazy because the users the mail is being sent to do not exist on that host. If, on the other hand, you allow relay for that domain, all inbound mail for that domain will be queued and delivered as soon as the primary MX returns to service. The same would apply to a tertiary MX host if you had one.

4.2.2 Sendmail and Microsoft Exchange

We've already documented a bit of how to force mail to a specific destination. To protect your Exchange server place it behind your firewall and use sendmail to relay all mail both to and from the Exchange server. Exchange has a setting which allows all outgoing mail to be forwarded to your sendmail gateway. If your corporate domain was named company.com you would make a mailertable entry for like this:

    @company.com            SMTP:exchange.company.com

This way all inbound mail would be forwarded to your exchange machine but your domain would still benefit from the finely grained relay controls possible with sendmail.