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.
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 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:
divert(-1)
include(`/usr/lib/sendmail-cf/m4/cf.m4')
dnl let's define our OS type. This one is mandatory.
OSTYPE(`linux')dnl
define(`confDEF_USER_ID',``8:12'')
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.
define(`ALIAS_FILE',`/etc/mail/aliases,/etc/mail/majordomo')dnl
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
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
dnl we don't need either one of the next two entries so lets remove the default
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY') dnl
dnl when people move on we it will really help to give them an informative bounce
FEATURE(`redirect')dnl
dnl we are 'company.com' after all. Let's make it so
FEATURE(`always_add_domain')dnl
dnl let's set up class w as a text file. It's easier to manage that way.
FEATURE(`use_cw_file')dnl
dnl we defined the path to procmail now let's implement it
FEATURE(`local_procmail')dnl
dnl we won't be doing any uucp
FEATURE(`nouucp')dnl
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
FEATURE(`blacklist_recipients')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
MAILER(procmail)dnl
MAILER(smtp)dnl
|
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.
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
Address: 127.0.0.1
> set type=any
> redhat.com.
Server: localhost
Address: 127.0.0.1
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 = 207.175.42.154
redhat.com
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 = 207.175.42.153
ns2.redhat.com internet address = 208.178.165.229
ns3.redhat.com internet address = 206.132.41.213
speedy.redhat.com internet address = 199.183.24.251
mail.redhat.com internet address = 199.183.24.239
|
But what about their MX records?
> set type=mx
> redhat.com
Server: localhost
Address: 127.0.0.1
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 = 199.183.24.239
ns.redhat.com internet address = 207.175.42.153
ns2.redhat.com internet address = 208.178.165.229
ns3.redhat.com internet address = 206.132.41.213
speedy.redhat.com internet address = 199.183.24.251
|
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@[10.0.0.50]
Received: from ns.somewhere.org (ns.somewhere.org [10.0.0.6])
by penguin.somewhere.org (MTA) with ESMTP id EF3F9BD78
for <xxxxx@[10.0.0.50]>; 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 [199.183.24.247])
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 199.183.24.247. The machine name does resolve correctly to that IP:
[someone@boss someone]$ host 199.183.24.247
247.24.183.199.IN-ADDR.ARPA 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@[10.0.0.50]
Received: from ns.somewhere.org (ns.somewhere.org [10.0.0.6])
by boss.somewhere.org (Postfix) with ESMTP id 5D4A2BD78
for <boss@[10.0.0.50]>; 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@[121.40.131.146]
Received: from server.somewhere.com (server.somewhere.com [211.28.95.220])
by ns.somewhere.org (MTA) with ESMTP id 1F3E5191C
for <boss@[121.40.131.146]>; Tue, 23 Nov 1999 21:03:45 -0500 (EST)
Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com
[207.175.42.154])
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 [207.175.42.11])
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 [127.0.0.1])
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:[199.183.24.247]
redhat-list-request@redhat.com SMTP:[199.183.24.247]
|
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@[207.175.42.154]
|
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:
#/etc/sendmail.cw
secondary.dom <------WRONG
#/etc/mail/access
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.
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.