DNS Domain and a Subdomain with One Internet Connection
This section describes a more complex example with a parent DNS domain—starlight.com—for the corporate headquarters of the Starlight company, and a child DNS domain—eng.starlight.com—for the engineering division of the company. Consider the following issues for this configuration.
Each domain needs to send internal and external e-mail independently of the other.
The two domains must be able to send e-mail to each other.
Only one of the domains (starlight.com) has a connection to the Internet but both need to send and receive e-mail with Internet sites. The networks of both domains are interconnected.
At first, this example looks quite complex but you can handle it with five configuration files.
One for the gateway named gw.starlight.com.
One for the corporate mail hub named mailhost.starlight.com.
One for the engineering mail hub named mailhost.eng.starlight.com.
One for each client of the starlight.com domain.
One for each client of the eng.starlight.com domain.
The Gateway Configuration
This gateway uses the same macro configuration file as “The Gateway Configuration” . Again, you specify the differences with the external database files.
The Gateway's External Databases
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 following forms: [email protected], [email protected], or the much rarer cases of [email protected] and [email protected]. When bound for the corporate domain, the e-mail is transmitted through SMTP to mailhost.starlight.com for final handling. When bound for the engineering domain, the e-mail is transmitted through SMTP to mailhost.eng.starlight.com for final handling.
# This systems acts as a sendmail gateway for all the DNS domains # listed below. # Note the []'s that surround the mail hub names 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] eng.starlight.com smtp:[mailhost.eng.starlight.com] .eng.starlight.com smtp:[mailhost.eng.starlight.com]
Remember to run the makemap command on this file so that sendmail can use it.
Use this file to ensure that sendmail relays all e-mail to this gateway with a source or destination address in the starlight.com or eng.starlight.com domains.
# List domains in this file for which we actually relay mail. # If a domain is not listed here, relaying of mail from that domain is denied. starlight.com eng.starlight.com
List the names by which this host is known. Don't list the starlight.com or eng.starlight.com domains because only the host(s) 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 Corporate 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 Corporate Mail Hub's External Databases
Because this system is the mail hub, use this file to ensure that all incoming e-mail for [email protected] is ultimately delivered on this system. This file also deals with the unlikely event that e-mail arrives addressed to [email protected]. Because this system is not the e-mail gateway for this domain, make sure that all e-mail sent from inside this domain to the Internet is forwarded to the gateway machine (gw.starlight.com) for handling.
Finally, if e-mail originates within this domain bound for the engineering domain, don't send it through the gateway, Instead, send it directly to the engineering mail hub.
# # Locally handle anything ending with starlight.com # Also, locally handle any e-mail addressed to # [email protected], starlight.com local: .starlight.com local: # Send all e-mail bound for the Engineering domain to the engineering mail # hub eng.starlight.com relay:mailhost.eng.starlight.com .eng.starlight.com relay:mailhost.eng.starlight.com # 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.
Process this file into a hash map with the makemap command, as shown in the following example.
# makemap hash /etc/mail/mailertable > /etc/mail/mailertable #Include your domain name in this file to ensure that e-mail originating from within your domain is accepted by this gateway for delivery to any location anywhere. Also, relay anything to or from the eng.starlight.com domain.
# List domains in this file for which we actually relay mail. # If a domain is not listed here, relaying of mail from that domain is denied. starlight.com eng.starlight.com
Because sendmail treats relay-domains as a plain text file, you need take no other action to process it.
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. Also, because this system is the mail hub for the domain, list the starlight.com 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 is 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, once you make these changes, restart sendmail.
The Corporate Client Configuration
Use the following macro configuration file to generate sendmail.cf files for each of the clients in the starlight.com corporate domain.
dnl dnl corp-client.mc: dnl Client macro configuration file for starlight.com dnl include(`/usr/lib/mail/m4/cf.m4') OSTYPE(`solaris2') FEATURE(`nullclient',`mailhost.starlight.com')
Notice that only the nullclient feature is activated. This feature tells all clients to send all e-mail generated locally to mailhost.starlight.com without doing any header rewriting.
Use the following command to create the client sendmail configuration file.
# m4 /usr/lib/mail/corp-client.mc > /usr/lib/mail/corp-client.cf
#
Copy the corp-client.cf configuration file to /etc/mail/sendmail.cf on each of the corporate client workstations.
The Engineering Mail Hub Configuration
The macro configuration file for the corporate 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 Engineering Mail Hub's External Databases
Because this system is the mail hub for the domain, use the mailertable file to ensure that all incoming e-mail for [email protected] is ultimately delivered on this system. This file also deals with the unlikely event that e-mail arrives that is addressed to [email protected]. 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.
Finally, if e-mail originates within this domain bound for the corporate domain, don't send it through the gateway. Instead, send it directly to the corporate mail hub.
# # Locally handle anything ending with eng.starlight.com # Also, locally handle any e-mail addressed to # [email protected], eng.starlight.com local: .eng.starlight.com local: # Send all e-mail bound for the Corporate domain to the corporate mail # hub starlight.com relay:mailhost.starlight.com .starlight.com relay:mailhost.starlight.com # 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 eng.starlight.com bound for someone else inside eng.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, as shown in the following example.
# makemap hash /etc/mail/mailertable > /etc/mail/mailertable #Include 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. Also, relay anything to or from the starlight.com domain.
# List domains in this file for which we actually relay mail. # If a domain is not listed here, relaying of mail from that domain is denied. starlight.com eng.starlight.com
Because sendmail treats relay-domains as a plain text file, you need take no other action to process it.
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. Also, because this system is the mail hub for the domain, list the domain name here because 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 is addressed to [email protected] mailhost.eng.starlight.com eng.starlight.com
Because sendmail treats sendmail.cw as a plain text file, you need take no other action to process it.
As always, once you make these changes, restart sendmail.
The Engineering Client Configuration
Use the following macro configuration file to generate sendmail.cf files for each of the clients in the eng.starlight.com corporate domain.
dnl dnl eng-client.mc: dnl Client macro configuration file for eng.starlight.com dnl include(`/usr/lib/mail/m4/cf.m4') OSTYPE(`solaris2') FEATURE(`nullclient',`mailhost.eng.starlight.com')
Notice that only the nullclient feature is activated. This feature tells all clients to send all e-mail generated locally to mailhost.eng.starlight.com without doing any header rewriting.
Use the following command to create the client sendmail configuration file.
# m4 /usr/lib/mail/eng-client.mc > /usr/lib/mail/eng-client.cf
#
Copy the eng-client.cf configuration file to /etc/mail/sendmail.cf on each of the engineering client workstations.
The DNS Configuration
Put entries like those in the following example in the starlight.com DNS server tables to ensure that all e-mail sent from any Internet site reaches the starlight.com or eng.starlight.com domains correctly.
starlight.com IN MX 10 gw eng.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] or [email protected] performs a DNS lookup and discovers that the mail exchanger (MX) record for all e-mail destined for these domains is 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 hubs. This behavior does not affect outgoing e-mail because it is handled directly by sendmail on the mail hubs and gateway without involving DNS. Remember that the e-mail clients in both domains just send everything to their respective mail hubs for processing, so they don't look at DNS either.