UNIX System Administration Handbook - Evi Nemeth [349]
LDAPROUTE_DOMAIN('synack.net')
define('confLDAP_DEFAULT_SPEC', '-h gw.synack.net -b dc=synack,dc=net')
MAILER(local)
MAILER(smtp)
The /etc/mail/local-host-names file contains the hosts and domains for which this host accepts mail (it used to be called sendmail.cw). The use_cw_file feature that would invoke it is hidden in the generic domain file; see page 594 for a listing of its contents. Relaying is turned off by default because the file /etc/mail/relay-domains is normally empty. Here, that file contains the domains that are virtually hosted by gw.synack.net. The LDAP database is configured with an ldap.conf file that sets the LDAP root distinguished name, server host, and port:
BASE dc=synack, dc=net
HOST gw.synack.net
PORT 389
The LDAP database is then built from a text file with entries such as:
dn: uid=rob, dc=synack, dc=net
objectClass: inetLocalMailRecipient
mailLocalAddress: rob@synack.net
mailRoutingAddress: bbraun@synack.net
uid:rob
dn: uid=webmaster, dc=synack, dc=net
objectClass: inetLocalMailRecipient
mailLocalAddress: webmaster@synack.net
mailRoutingAddress: bbraun@synack.net
uid:webmaster
dn: uid=teich, dc=synack, dc=net
objectClass: inetLocalMailRecipient
mailLocalAddress: teich@synack.net
mailRoutingAddress: oren@teich.net
uid:teich
dn: uid=xinetd, dc=synack, dc=net
objectClass: inetLocalMailRecipient
mailLocalAddress: xinetd@synack.net
mailRoutingAddress: xinetd
uid:xinetd
The first three entries map the login names rob, webmaster, and oren to their aliases. The fourth is a mailing list that maps to a local alias and is handled from there by Majordomo by means of these entries in the /etc/mail/aliases file:
xinetd: "|/usr/local/majordomo/wrapper resend -l test xinetd-list"
xinetd-list: :include:/usr/local/majordomo/lists/xinetd
xinetd-owner: bbraun
owner-xinetd: bbraun
xinetd-request: bbraun
xinetd-approval: bbraun
We have shown several supporting files and sample contents for this example. Our next examples keep closer to the point of illustrating how sendmail configuration works and do not show peripheral files.
Keep in mind that in any sendmail example, DNS MX records play a crucial role and need to agree with the assumptions made by your configuration.
A small but sendmail-clueful company
As our next example, we look at the config files for a small but very sendmail-savvy company, Sendmail, Inc. Their mail design includes a master mail host that serves as both the mail hub for incoming mail and the smart host for outgoing mail. We look at the clients’ configuration first, then inspect the more complicated master machine.
In all of the examples, we have modified the originals slightly, leaving out the copyright notices, adding occasional comments, and removing the m4 dnl directive at the ends of lines. If you use any of our examples as a model for your .mc file, be sure to remove the comments from the ends of lines.
Client machines at sendmail.com
The smi-client.mc file for client machines is quite simple. It uses the master machine smtp.sendmail.com, which is really just an alias (a DNS CNAME) to the machine katroo.sendmail.com. Using a CNAME is a good idea; it’s easy to change when you want to move your master mail machine.
Note that the date on this file is October 1998. sendmail has been upgraded many times since then, but the configuration file did not need to change.
divert(-1)
##### This file contains definitions for a Sendmail,
##### Inc. client machine's version 8.9.3 .mc file.
divert(0)
VERSIONID('@(#)smi-client.mc 1.0 (Sendmail) 10/14/98')
OSTYPE('bsd4.4')
FEATURE('nocanonify')
undefine('ALIAS_FILE')
define('MAIL_HUB', 'smtp.sendmail.com')
define('SMART_HOST', 'smtp.sendmail.com')
define('confFORWARD_PATH', '')
MAILER('local')
MAILER('smtp')
The MAIL_HUB and SMART_HOST lines direct incoming and outgoing mail to the host smtp.sendmail.com. MX records in DNS should cooperate and list that host with higher priority (lower number in MX record) than the individual client machines. The path for .forward