Single DNS Domain with Internet Connection and Separate Gateway

Although the previous section describes a completely valid sendmail configuration, it is often desirable to separate the function of the mail hub from the mail gateway. This separation enables you to put the mail hub inside a protective firewall, shielding it from direct attacks on sendmail. You would put the gateway on the firewall's DMZ network (preferred) or outside the firewall. In this way, you can monitor any attacks on the gateway. If compromised, the gateway has only its sendmail configuration file stored on it.

The following example still uses the starlight.com domain with three sendmail configuration files to implement this change.

  1. One for the gateway named gw.starlight.com.

  2. One for the mail hub named mailhost.starlight.com.

  3. One for all clients of the starlight.com domain. This file has exactly the same macro configuration file as shown in “The Client Configuration” , because mailhost.starlight.com is still the mail hub for the site.

The Gateway Configuration

The macro configuration file for the gateway contains the same directives as shown in “The Mail Hub/Gateway Configuration” ; it simply has a different name, /usr/lib/mail/gateway.mc. For your convenience, the contents of the file are repeated below.

dnl
dnl gateway.mc
dnl The Gateway macro configuration file for starlight.com
dnl
include(`/usr/lib/mail/m4/cf.m4')dnl
OSTYPE(`solaris2')dnl
dnl
dnl Now make everything look like it comes from [email protected]
dnl
MASQUERADE_AS(`starlight.com')dnl
dnl
dnl Masquerade header recipients too
dnl
FEATURE(allmasquerade)dnl
dnl
dnl And the envelope as well
dnl
FEATURE(masquerade_envelope)dnl
dnl
dnl Activate DNS-based black hole, to drop mail from known spammer sites
dnl Activate Realtime BLack hole, to drop mail from known spammer sites
dnl When upgrading to sendmail 8.10, change this to the `dnsbl' feature
dnl
FEATURE(rbl)dnl
dnl
dnl Turn on mailertable feature so that we can relay to certain domains
dnl by using gateways WE define in the /etc/mailertable file. (in 8.10, this
dnl file will move to /etc/mail/mailertable, so we're putting it there 
dnl manually for now)
dnl
FEATURE(use_cw_file)dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable')dnl
FEATURE(`domaintable',`hash -o /etc/mail/domaintable')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
FEATURE(`access_db',`hash -o /etc/mail/access')dnl
dnl
dnl Allow relaying of hosts in the starlight.com domain, but also
dnl allow us to specify more domains that we will relay in 
dnl /etc/mail/relay-domains
dnl
FEATURE(relay_entire_domain)dnl
RELAY_DOMAIN_FILE('-o /etc/mail/relay-domains')dnl
dnl
dnl Configurable options are modified here
dnl
define(`confSMTP_LOGIN_MSG',`[$j Sendmail $v/$Z; $b, starlight.com]')dnl
define(`confCW_FILE',`-o /etc/mail/sendmail.cw')dnl
dnl
dnl define MAILERs here
dnl
MAILER(`local')
MAILER(`smtp')

You use the entries in the external databases to explicitly instruct sendmail that the gateway is a separate system, not a system that acts as a combined gateway and mail hub.

The Gateway's External Databases

Make the following changes, at a minimum, to the gateway's external databases.

  • /etc/mail/mailertable

    Use this file to enable the gateway to deal properly with all incoming e-mail from the Internet bound for the common addresses of the form [email protected] or the much rarer case of [email protected]. In either case, the e-mail is transmitted through SMTP to mailhost.starlight.com for final handling. The [ ] characters surrounding mailhost.starlight.com tell sendmail not to consult DNS for MX records to determine where to send e-mail bound for mailhost.starlight.com. Instead, sendmail should simply send the e-mail directly to that host. If you don't use this construct, the e-mail loops back to the gateway again and again, forming an e-mail loop. Also, note that, because no e-mail is ever delivered into a mail spool on this machine, you don't have the local: entries. You include the local: entries only on the final mail hub.

    # This system acts as a sendmail gateway for all the DNS domains
    # listed below.
    # Note the []'s that surround the mail hub names. They ensure that
    # MX records are not looked up again by this gateway, thereby preventing
    # a nasty MX record loop!
    #
    starlight.com   smtp:[mailhost.starlight.com]
    .starlight.com  smtp:[mailhost.starlight.com]
    

Remember to use the makemap command on this file so that sendmail can use it.

  • /etc/mail/relay-domains

    Use this file to relay all e-mail with a source or destination address in the starlight.com domain by this gateway.

    # Domains listed in this file are those for which we 
    # actually relay mail. If a domain is not listed 
    # here, relaying of mail from that domain is denied.
    starlight.com
    
  • /etc/mail/sendmail.cw

    List only the names this host is known by. Don't list the starlight.com domain because only the host where the mail ultimately is delivered to the mail spool needs to do this.

    # List all the names by which the mail gateway is known so
    # that sendmail doesn't get confused into thinking that it shouldn't
    # deliver mail to this system.
    gw.starlight.com
    

The Mail Hub Configuration

The macro configuration file for the mail hub is identical to that for the gateway. Thus, the final sendmail configuration file is also identical. The behavior of this mail hub is governed by the sendmail external databases listed below.

The Mail Hub's External Databases
  • /etc/mail/mailertable

    Because this system is the mail hub, use the mailertable file to ensure that all incoming e-mail for [email protected] ultimately is delivered on this system. This file also deals with the unlikely event of e-mail that is addressed to [email protected]. Finally, because this system is not the e-mail gateway for this domain, ensure that all e-mail sent from inside this domain to the Internet is forwarded to the gateway machine (gw.starlight.com) for handling.

    #
    # Locally handle anything ending with starlight.com.
    # Also, locally handle any e-mail addressed to
    # [email protected], in case such a format ever appears.
    starlight.com     local:
    .starlight.com    local:
    # Relay EVERYTHING else to gw.starlight.com for handling
    .                 relay:gw.starlight.com.
    

    The . at the beginning of the last line acts as the final dot in a fully qualified DNS name, such as sun.com. With nothing before it, this dot (.) is interpreted as anything.{com,gov,net,org,etc.}. Because any previous, more specific rules in the configuration file override this file, we can put in rules that prevent mail that originates inside starlight.com bound for someone else inside starlight.com from going to the gateway and thus onto the Internet, where it might be intercepted by unscrupulous persons.

    Note also that the host name has a dot (.) at the end of it to ensure that it is a fully qualified host name.

    Use the makemap command to process this file into a hash map, as shown in the following example.

    # makemap hash /etc/mail/mailertable > /etc/mail/mailertable
    #
    
  • /etc/mail/relay-domains

    Put your domain name in this file to ensure that e-mail originating from within your domain is accepted for delivery to any location anywhere by this gateway.

    # List domains in this file for which we actually will relay mail.
    # If a domain is not listed here, relaying of mail from that domain is denied.
    starlight.com
    

    Because sendmail treats relay-domains as a plain text file, you need take no other action to process it.

  • /etc/mail/sendmail.cw

    Use this file to list all of the names by which this host is known so that sendmail recognizes that e-mail sent to any of those host names is truly intended for this system. Because this system is the mail hub for that domain, also list the domain name here; most e-mail is sent to [email protected], and you want sendmail to recognize that starlight.com is another way of referring to this host.

    # List all the names by which the mail hub is known so that sendmail
    # doesn't get confused into thinking that it shouldn't
    # deliver mail into the proper spool on this system. Note
    # that the DNS domain itself is at the end of the list because
    # most e-mail will be addressed to [email protected]
    mailhost.starlight.com
    starlight.com
    

    Because sendmail treats sendmail.cw as a plain text file, you need take no other action to process it.

    As always, after you make these changes you need to restart sendmail.

The DNS Configuration

To ensure that all e-mail sent from any Internet site reaches the starlight.com domain correctly, put entries that look like the following example in the starlight.com DNS server tables.

starlight.com   IN  MX  10  gw
gw              IN  A       205.172.3.46

This example assumes that the IP address of the gateway is 205.172.3.46. Any Internet site trying to send e-mail to [email protected] performs a DNS lookup and discovers that the mail exchanger (MX) record for all e-mail destined for starlight.com should be sent directly to gw.starlight.com with a preference of 10.

As you can see, all incoming e-mail goes through the gateway to get to the mail hub. This action does not affect outgoing e-mail because it is handled directly by sendmail on the mail hub and gateway without involving DNS. Remember that the e-mail clients in this domain just send everything to the mail hub for processing, so they don't look at DNS either.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.141.219