System Administration Guide: Network Services
Previous Next

Interactions of sendmail With Name Services

This section describes domain names as they apply to sendmail and name services. Furthermore, this section describes the rules for effective use of name services, and the specific interactions of sendmail with name services. For details, refer to the following topics.

If you are looking for related task information, refer to How to Use DNS With sendmail or Administering Mail Alias Files (Task Map) in Chapter 13, Mail Services (Tasks).

sendmail.cf and Mail Domains

The standard sendmail.cf file uses mail domains to determine whether mail is delivered directly or through a mail host. Intradomain mail is delivered through a direct SMTP connection, while interdomain mail is forwarded to a mail host.

In a secure network, only a few selected hosts are authorized to generate packets that are targeted to external destinations. Even if a host has the IP address of the remote host that is external to the mail domain, the establishment of an SMTP connection is not guaranteed. The standard sendmail.cf assumes the following.

  • The current host is not authorized to send packets directly to a host outside the mail domain.

  • The mail host is capable of forwarding the mail to an authorized host that can transmit packets directly to an external host. Actually, the mail host can be an authorized host.

With these assumptions, the mail host is responsible for delivering or forwarding interdomain mail.

sendmail and Name Services

sendmail imposes various requirements on name services. To improve your understanding of these requirements, this section first describes the relationship of mail domains to name service domains. Then the section describes the various requirements. Refer to the following.

Mail Domains and Name Service Domains

The mail domain name must be a suffix of the name service domain. For example, if the domain name of the name service is A.B.C.D, the mail domain name could be one of the following.

  • A.B.C.D

  • B.C.D

  • C.D

  • D

When first established, the mail domain name is often identical to the name service domain. As the network grows, the name service domain can be divided into smaller pieces to make the name service more manageable. However, the mail domain often remains undivided to provide consistent aliasing.

Requirements for Name Services

This section describes the requirements that sendmail imposes on name services.

A host table or map in a name service must be set up to support three types of gethostbyname() queries.

  • mailhost – Some name service configurations satisfy this requirement automatically.

  • Full host name (for example, smith.admin.acme.com) – Many name service configurations satisfy this requirement.

  • Short host name (for example, smith) – sendmail must connect to the mail host in order to forward external mail. To determine if a mail address is within the current mail domain, gethostbyname() is invoked with the full host name. If the entry is found, the address is considered internal.

    NIS, NIS+, and DNS support gethostbyname() with a short host name as an argument, so this requirement is automatically satisfied.

Two additional rules about the host name service need to be followed to establish efficient sendmail services within a name service.

  • gethostbyname() with full host-name argument and short host-name argument should yield consistent results. For example, gethostbyname(smith.admin.acme.com) should return the same result as gethostbyname(smith), if both functions are called from the mail domain admin.acme.com.

  • For all name service domains under a common mail domain, gethostbyname() with a short host name should yield the same result. For example, if the mail domain smith.admin.acme.com is given, gethostbyname(smith) should return the same result when the call originates from either the ebb.admin.acme.com domain or the esg.admin.acme.com domain. The mail domain name is usually shorter than the name service domain, which gives this requirement special implications for various name services.

For more information about the gethostbyname() function, refer to the gethostbyname(3NSL) man page.

Interactions of NIS and sendmail

The following list describes the interactions of sendmail and NIS and provides some guidance.

  • Mail domain name – If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as the mail domain name. For example, ebs.admin.acme.com becomes admin.acme.com.

  • Mail host name – You must have a mailhost entry in the NIS host map.

  • Full host names – The normal NIS setup does not “understand” the full host name. Rather than trying to make NIS understand the full host name, turn off this requirement from the sendmail side by editing the sendmail.cf file and replacing all occurrences of %l with %y. This change turns off sendmail's interdomain mail detection. If the target host can be resolved to an IP address, a direct SMTP delivery is attempted. Ensure that your NIS host map does not contain any host entry that is external to the current mail domain. Otherwise, you need to further customize the sendmail.cf file.

  • Matching full host names and short host names – Follow the previous instructions about how to turn off gethostbyname() for a full host name.

  • Multiple NIS domains in one mail domain – All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com. Otherwise, one address might work in one NIS domain, but fail in the other NIS domain.

For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 13, Mail Services (Tasks).

Interactions of sendmail With NIS and DNS

The following list describes the interactions of sendmail with NIS and DNS and provides some guidance.

  • Mail domain name – If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as the mail domain name. For example, ebs.admin.acme.com becomes admin.acme.com.

  • Mail host name – When the DNS forwarding feature is turned on, queries that NIS cannot resolve are forwarded to DNS, so you do not need a mailhost entry in the NIS host map.

  • Full host names – Although NIS does not “understand” full host names, DNS does understand. This requirement is satisfied when you follow the regular procedure for setting up NIS and DNS.

  • Matching full host names and short host names – For every host entry in the NIS host table, you must have a corresponding host entry in DNS.

  • Multiple NIS domains in one mail domain – All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com domain. Otherwise, one address might work in one NIS domain, but fail in the other NIS domain.

For task information, refer to How to Use DNS With sendmail and Administering Mail Alias Files (Task Map) in Chapter 13, Mail Services (Tasks).

Interactions of NIS+ and sendmail

The following list describes the interactions of sendmail with NIS+ and provides some guidance.

  • Mail domain name – If you are setting up NIS+ as your primary name service, sendmail can check the mail domain from the NIS+ sendmailvars table. This NIS+ table has one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to your mail domain name. An example is admin.acme.com. Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomain entry to the sendmailvars table. Notice in the following example that the mail domain is a suffix of the NIS+ domain.

    nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>
  • Mailhost host name – You must have a mailhost entry in the NIS+ hosts table.

  • Full host names – NIS+ “understands” the full host name. Following the regular NIS+ setup procedure satisfies this requirement.

  • Matching full host names and short host names – To satisfy this requirement, you can duplicate the entries in the host table. Otherwise, you can enter all host entries in the user name-service domains into a master host table at mail domain level.

  • Multiple NIS domains in one mail domain – To satisfy this requirement, you can duplicate the entries in all the host tables. Otherwise, you can type all host entries in the user name service domains into a master host table at mail domain level. Effectively, you are merging multiple host tables that are logical or physical into one host table. Therefore, the same host name cannot be reused in the multiple name service domain that shares a common mail domain.

For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 13, Mail Services (Tasks).

Interactions of sendmail With NIS+ and DNS

The following list describes the interactions of sendmail with NIS+ and DNS and provides some guidance.

  • Mail domain name – If you are setting up NIS+ as your primary name service, sendmail can check the mail domain from the NIS+ sendmailvars table. This NIS+ table has one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to your mail domain name. An example is admin.acme.com. Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomain entry to the sendmailvars table. Notice in the following example that the mail domain is a suffix of the NIS+ domain.

    nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>
  • Mailhost host name – If your network uses both NIS+ and DNS as the source for the host database, you can put the mailhost entry in either the NIS+ or DNS host table. Ensure that your users include both NIS+ and DNS as the source for the host database in the /etc/nsswitch.conf file.

  • Full host names – Both NIS+ and DNS “understand” full host names. Following the regular NIS+ and DNS setup procedures satisfies this requirement.

  • Matching full host names and short host names – For every host entry in the NIS+ host table, you must have a corresponding host entry in DNS.

  • Multiple NIS domains in one mail domain – To satisfy this requirement, you can duplicate the entries in all the host tables. Alternately, you can type all host entries in the user name-service domains into a master host table at the mail domain level.

For task information, refer to Administering Mail Alias Files (Task Map) and How to Use DNS With sendmail in Chapter 13, Mail Services (Tasks).

Previous Next