This document describes (in some detail, though undoubtedly not enough!)
the sendmail configuration files currently in use at Berkeley as distributed
with version 5.61 of sendmail. It discusses the configuration file
directory hierarchy, how the files are processed by m4(1), what functionality
the files provide, what m4(1) options can be used to produce specific
results, and goes through an example or two. It concludes with a list
of things that will change in the next release of the configuration files.
This is a working draft; your comments are appreciated. Please send your
suggestions to Phil Lapsley, phil@ucbvax.berkeley.edu, ...!ucbvax!phil.
The "cf" subdirectory is organized as follows:
+---------------+---------------+
where the directories contain the following:
sitedep Site dependent parts of configuration files
m4 Site independent parts of configuration files
cf Includes "master configuration" (.mc) files
that include m4 files from ../m4 and ../sitedep.
.mc files are processed by m4(1) and result in
configuration files (.cf).
In the remainder of this document, all path names are referenced
relative to the top level "cf" directory. Hence, the m4 subdirectory
WHERE m4(1) FITS INTO ALL OF THIS:
----------------------------------
Configuration files are built by typing "make" in cf/cf. This
runs m4(1) on the .mc files in cf/cf and produces .cf files.
The philosophy at Berkeley is to place as much information into
one .mc file as possible, and then use m4 conditional substitution
(ifdef, for example) to produce other configuration files from it.
This results in a substantial reduction of duplicated code that must
be maintained separately.
The main master configuration file that contains all this information
is "cf/proto.mc". This file has a number of m4 conditional substitutions
that can be controlled by other .mc files that include "cf/proto.mc".
For example, most hosts at Berkeley have only SMTP (TCP) connections
to other hosts. A file called "ucbproto.cf" takes care of these
machines by defining the m4 flags needed to produce only SMTP mailer
definitions from "cf/proto.mc". Since this is default behavior, very
little needs to be defined.
But some hosts at Berkeley (e.g., cad.Berkeley.EDU) have both SMTP
connections and UUCP connections as well. Thus, they need to
produce a configuration file that contains both SMTP and UUCP mailer
definitions, and they need to include a list of directly connected
UUCP neighbors. The file "cf/cad.mc" does this by setting the m4
flags for "cf/proto.mc" that say "(1) I am a UUCP host with hostname "ucbcad",
(2) a list of my UUCP neighbors can be found in ../sitedep/uucp.cad.m4".
Thus, there are many .mc files in cf/cf that simply define m4 flags and
then include "cf/proto.mc" to produce a specific configuration file.
IT IS STRONGLY SUGGESTED THAT YOU, THE SYSTEM MANAGER,
CONTINUE TO MAINTAIN CONFIGURATION FILES BY USING THIS
m4(1) METHOD. TRYING TO MAINTAIN MULTIPLE .CF FILES
ON SEPARATE MACHINES WILL LEAD TO INSANITY.
With that out of the way, we should now examine the functionality
provided by the supplied sendmail configuration files, and then
talk in detail about the m4(1) options that control this.
FUNCTIONALITY PROVIDED BY THE SUPPLIED SENDMAIL CONFIGURATIONS:
---------------------------------------------------------------
The sendmail configuration files come with the following mailers:
local For delivery of messages to users on the
tcp For SMTP delivery of messages across the
tcpld For SMTP delivery of messages within the
uucp For delivery of messages to a UUCP neighbor.
smtpuucp For delivery of messages to a UUCP neighbor
with whom we also share Internet connectivity.
The tcp/tcpld mailers and the smtpuucp mailers deserve a little more
The "tcp" and "tcpld" mailers:
------------------------------
As regards tcp and tcpld: in theory, there should be only one mailer
here, called "smtp", that deals with addresses in the form "user@host.domain".
Everyone on the Internet would use this, regardless of what domain
they were in. Host name lookups would be performed via the domain naming
system (DNS), and no central registry of machine names would be necessary.
Unfortunately, this is not the case. The MILNET community is still
in transition towards the DNS, and until this transition is complete,
they do not have to use the nameserver. Rather, they can "legally"
still use the host table supplied by SRI-NIC to translate names to
addresses. This means that to be strictly legal, we must send out
messages in the form "user@host.domain" ONLY FOR machines that are
registered with SRI NIC. Machines that are not registered with the
NIC must be "hidden" behind a relay machine, e.g.,
user%unregistered_host@registered_host.domain. This, when MILNET folks
reply to this, the mail passes through "registered_host.domain" first.
Currently this "hiding" behind NIC registered hosts is performed by
Since you don't want to register all the hosts at your site with
the NIC (and they don't want you to!), the "tcpld" mailer was created.
The idea here is that you KNOW all the hosts in your local domain
use the nameserver, so there is no need to hide mail behind a NIC
registered relay -- that would only slow things down. So the "tcpld"
does not do any hiding of unregistered hosts behind a registered relay.
Eventually the "tcpld" mailer will become the "smtp" mailer mentioned above.
The "smtpuucp" mailer is another fun one. As time progresses, many
hosts with whom one has UUCP connections join the Internet. Unfortunately,
if the UUCP connection existed for any length of time, people are
probably used to using it, complete with the bangist syntax that comes
with UUCP. As a result, many sites elect to keep their
UUCP connections even though they have TCP/IP connectivity to the sites
in question. This turns out not be such a good idea because of the
double-queuing incurred by UUCP, explained in the following example.
For concreteness, consider the following scenario: ucbvax.Berkeley.EDU
(UUCP host "ucbvax") and decvax.dec.com (UUCP host "decvax") have shared
a cross county UUCP link that is heavily used by many people. Let's say
that a piece of mail is routed through the ucbvax-decvax link via UUCP.
1 ucbvax incoming mail is accepted via UUCP
2 ucbvax uuxqt is queued to invoke sendmail.
3 ucbvax sendmail parses the message.
4 ucbvax sendmail passes the message to the UUCP
mailer for delivery to decvax.
5 ucbvax message is placed in the outgoing UUCP queue for decvax
6 decvax uucico takes the message from ucbvax
7 decvax uuxqt is queued to invoke sendmail
8 decvax sendmail parses the message
9 decvax sendmail passes the message to someplace else.
Note that the message transited the inbound UUCP queue on ucbvax, the sendmail
queue on ucbvax, the outbound UUCP queue on ucbvax, the inbound UUCP queue
Now, if decvax and ucbvax have SMTP connectivity, the session is more
1 ucbvax incoming mail is accepted via UUCP
2 ucbvax uuxqt is queued to invoke sendmail.
3 ucbvax sendmail parses the message
4a ucbvax sendmail delivers it to decvax.dec.com via SMTP.
a decvax sendmail accepts the message from ucbvax via SMTP.
8 decvax sendmail parses the message.
9 decvax sendmail passes it to someplace else.
Note that old steps (5) and (7), the UUCP queueing, are avoided entirely.
The only trick to the "smtpuucp" mailer is that even though it uses
SMTP to communicate with its neighbors, it must use the UUCP syntax
and rewriting rulesets so that the operation is transparent to the
outside world. This is easy enough to do.
Aside from the mailers supplied, the basic configuration files
support the following features:
* Domains. Addresses of the form "user@host.domain" are
considered to be the basic type of address we deal with.
* Fake domains. Addresses of the form:
are forwarded to a CSNET relay host and a BITNET relay host,
Note: this feature exists for convenience. As CSNET and
BITNET convert to domains, it will go away. In particular,
"user@host.CSNET" is slated to get the axe in the next release.
m4(1) OPTIONS USED IN THE .MC FILES:
------------------------------------
The following options, from "most important" to "trivial", can be
used to control what configuration file you get from running m4(1)
on "cf/proto.mc". As explained earlier, the standard practice is to
create an ".mc" file for a particular configuration that contains
all the m4(1) macro definitions/flags you want, and then have
that .mc file include "mc/proto.mc".
Macro name Example (you must include the ` and ')!
---------- ---------------------------------------
This MUST be defined to be your Internet domain.
INTERNET_RELAY `DAcad.Berkeley.EDU'
If defined, this will be the machine behind which non-NIC registered
hosts are hidden, resulting in addresses of the form
user%host@internet_relay.domain
moore%prefect@cad.Berkeley.EDU
If not defined, outgoing addresses will always be of the form
regardless of whether "host.domain" is registered with the NIC.
If defined, includes the UUCP mailer and assumes you have local
UUCP connections. The UUCP_NAME macro is used to define your
canonical UUCP hostname. See also: UUCP_ALIASES and UUCP_HOSTS_FILE.
UUCP_ALIASES `CUucbcad cad'
Used only if UUCP_NAME is defined, this macro lists any UUCP
aliases for your machine. See also: UUCP_NAME and UUCP_HOSTS_FILE.
UUCP_HOSTS_FILE `../sitedep/uucp.cad.m4'
Used only if UUCP_NAME is defined. Defines class V of
local UUCP hosts by including the appropriate m4 file. See also:
UUCP_NAME and UUCP_ALIASES.
UUCP_RELAY `DRcad.Berkeley.EDU'
If defined, this will be the machine to which non-local UUCP traffic
is forwarded. That is, any address that ends in ".UUCP" that is
not listed in the V class (as defined by UUCP_HOSTS_FILE) will be
forwarded to the UUCP_RELAY host via the "tcpld" mailer.
If defined, makes sure that no TCP/IP based mailers will be
put in the resulting configuration file. Normally undefined.
SMTPUUCP `../sitedep/smtpuucp.cad.m4'
If defined, use SMTP to resolve certain UUCP connections (while
keeping UUCP syntax). Should be defined to be a file that
contains the list of pairs of UUCP names and their corresponding
Internet names. See "machdep/smtpuucp.ucbvax.m4" for an example
of what this should look like.
BITNET_RELAY `DBjade.Berkeley.EDU'
If defined, this will be the machine to which BITNET traffic
(i.e., mail to user@host.bitnet) is forwarded. If not defined,
addresses of the form "user@host.bitnet" will bounce.
CSNET_RELAY `DCrelay.cs.net'
If defined, this will be the machine to which CSNET traffic
(i.e., mail to user@host.csnet) is forwarded. If not defined, addresses
of that form will bounce.
If defined, this turns on a kludge to reduce mail load on your
INTERNET_GATEWAY. What is done is the following: if mail is outgoing
to a machine in the ".arpa" domain and we're not registered with the
NIC, we hide ourselves behind our INTERNET_GATEWAY. If the machine
to which mail is being delivered is NOT in the ".arpa" domain, we
assume they use the domain name system and can reply to our address --
hence, we don't hide anywhere.
Let's consider a hypothetical system at Foo, Inc. Foo, Inc. is on the
ARPA Internet and is the proud owner of the domain "foo.com". Machines
in "foo.com" exchange mail with other hosts on the Internet via SMTP.
Foo, Inc. also has customers with whom they have UUCP links -- these
links are all on the machine "uucp-gw.foo.com". Mail to any address
that ends in ".UUCP" should be forwarded to "uucp-gw.foo.com". They
also have a gateway to the bitnet through their local machine
"bitnet-gw.foo.com"; mail to any address ending in ".bitnet" should go
there. They intend to take advantage of the kind folks at CSNET by
forwarding mail to "host.csnet" to the machine "relay.cs.net".
The master configuration file for a generic machine on the corporate
ethernet might look like this:
define(DOMAIN, `DDfoo.com')
define(UUCP_RELAY, `DRuucp-gw.foo.com')
define(BITNET_RELAY, `DBbitnet-gw.foo.com')
define(CSNET_RELAY, `DCrelay.cs.net')
And that's it! The system manager at "foo.com" would simply install
this in the "cf" subdirectory, add a production to the make file,
and type "make foo.cf". This would run m4(1) on the .mc file and
Now let's turn to the machine "uucp-gw.foo.com". It obviously needs
to have the UUCP mailer compiled in, and it needs a list of UUCP
neighbors with whom it is connected. Of course, it also needs a TCP/IP
(SMTP) based mailer so it can talk to the rest of the company.
On the UUCP network, "uucp-gw.foo.com" is known as "foo".
The master configuration file might be:
define(DOMAIN, `DDfoo.com')
define(UUCP_NAME, `DUfoo')
define(UUCP_ALIASES, `CUfoo')
define(UUCP_HOSTS_FILE, `../sitedep/uucp.foo.m4')
define(BITNET_RELAY, `DBbitnet-gw.foo.com')
define(CSNET_RELAY, `DCrelay.cs.net')
Note that we didn't define UUCP_RELAY here, since we ARE the UUCP relay.
The file "../sitedep/uucp.foo.m4" contains a list of our UUCP neighbors:
indicating that "uucp-gw.foo.com" is directly connected to three other
machines via UUCP: "oink", "bletch", and "spam."
WHAT WILL BE CHANGING IN THE NEXT RELEASE:
------------------------------------------
In the next release, the following things should change:
1. The MILNET should have gotten its act together. This means
that the "tcp" mailer goes away. The "tcpld" mailer will
be renamed "smtp". The "N" class (NIC registered hosts)
gets axed. The ARPAKLUDGE and INTERNET_RELAY m4(1) options
2. The CSNET "fake domain" (i.e., user@host.csnet) will cease
3. The "smtp" mailer rulesets (currently 17/27) will be rewritten,
along with much of rulesets 0 and 3.
projects / unix-history / blob