mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-11-18 17:00:49 +01:00
1233 lines
46 KiB
Plaintext
1233 lines
46 KiB
Plaintext
|
|
|
|
NEW SENDMAIL CONFIGURATION FILES
|
|
|
|
Eric Allman <eric@CS.Berkeley.EDU>
|
|
|
|
@(#)README 8.28 (Berkeley) 4/14/94
|
|
|
|
|
|
This document describes the sendmail configuration files being used
|
|
at Berkeley. These use features in the new (R8) sendmail, and although
|
|
there is an ``OLDSENDMAIL'' mode, they haven't really been tested on
|
|
old versions of sendmail and cannot be expected to work well.
|
|
|
|
These configuration files are probably not as general as previous
|
|
versions, and don't handle as many of the weird cases automagically.
|
|
I was able to simplify by them for two reasons. First, the network
|
|
has become more consistent -- for example, at this point, everyone
|
|
on the internet is supposed to be running a name server, so hacks to
|
|
handle NIC-registered hosts can go away. Second, I assumed that a
|
|
subdomain would be running SMTP internally -- UUCP is presumed to be
|
|
a long-haul protocol. I realize that this is not universal, but it
|
|
does describe the vast majority of sites with which I am familiar,
|
|
including those outside the US.
|
|
|
|
Of course, the downside of this is that if you do live in a weird
|
|
world, things are going to get weirder for you. I'm sorry about that,
|
|
but at the time we at Berkeley had a problem, and it seemed like the
|
|
right thing to do.
|
|
|
|
This package requires a post-V7 version of m4; if you are running the
|
|
4.2bsd, SysV.2, or 7th Edition version, I suggest finding a friend with
|
|
a newer version. You can m4-expand on their system, then run locally.
|
|
SunOS's /usr/5bin/m4 or BSD-Net/2's m4 both work. GNU m4 version 1.1
|
|
also works. Unfortunately, I'm told that the M4 on BSDI 1.0 doesn't
|
|
work -- you'll have to use a Net/2 or GNU version.
|
|
|
|
IF YOU DON'T HAVE A BERKELEY MAKE, don't despair! Just run
|
|
"m4 foo.mc > foo.cf" -- that should be all you need. There is also
|
|
a fairly crude (but functional) Makefile.dist that works on the
|
|
old version of make.
|
|
|
|
To get started, you may want to look at tcpproto.mc (for TCP-only
|
|
sites), uucpproto.mc (for UUCP-only sites), and clientproto.mc (for
|
|
clusters of clients using a single mail host). Others are versions
|
|
that we use at Berkeley, although not all are in current use. For
|
|
example, ucbarpa has gone away, but I've left ucbarpa.mc in because
|
|
it demonstrates some interesting techniques.
|
|
|
|
I'm not pretending that this README describes everything that these
|
|
configuration files can do; clever people can probably tweak them
|
|
to great effect. But it should get you started.
|
|
|
|
*******************************************************************
|
|
*** BE SURE YOU CUSTOMIZE THESE FILES! They have some ***
|
|
*** Berkeley-specific assumptions built in, such as the name ***
|
|
*** of our UUCP-relay. You'll want to create your own domain ***
|
|
*** description, and use that in place of domain/Berkeley.m4. ***
|
|
*******************************************************************
|
|
|
|
|
|
+--------------------------+
|
|
| INTRODUCTION AND EXAMPLE |
|
|
+--------------------------+
|
|
|
|
Configuration files are contained in the subdirectory "cf", with a
|
|
suffix ".mc". They must be run through "m4" to produce a ".cf" file.
|
|
|
|
Let's examine a typical .mc file (cf/cs-exposed.mc):
|
|
|
|
divert(-1)
|
|
#
|
|
# Copyright (c) 1983 Eric P. Allman
|
|
# Copyright (c) 1988 The Regents of the University of California.
|
|
# All rights reserved.
|
|
#
|
|
# Redistribution and use in source and binary forms are permitted
|
|
# provided that the above copyright notice and this paragraph are
|
|
# duplicated in all such forms and that any documentation,
|
|
# advertising materials, and other materials related to such
|
|
# distribution and use acknowledge that the software was developed
|
|
# by the University of California, Berkeley. The name of the
|
|
# University may not be used to endorse or promote products derived
|
|
# from this software without specific prior written permission.
|
|
# THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
|
|
# IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
|
|
# WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
|
#
|
|
|
|
The divert(-1) will delete the crud in the resulting output file.
|
|
The copyright notice is what your lawyers require. Our lawyers require
|
|
the one that I've included in my files. A copyleft is a copyright by
|
|
another name.
|
|
|
|
The next line MUST be
|
|
|
|
include(`../m4/cf.m4')
|
|
|
|
This will pull in the M4 macros you will need to make sense of
|
|
everything else. As the saying goes, don't think about it, just
|
|
do it. If you don't do it, don't bother reading the rest of this
|
|
file.
|
|
|
|
VERSIONID(`<SCCS or RCS version id>')
|
|
|
|
VERSIONID is a macro that stuffs the version information into the
|
|
resulting file. We use SCCS; you could use RCS, something else, or
|
|
omit it completely. This is not the same as the version id included
|
|
in SMTP greeting messages -- this is defined in m4/version.m4.
|
|
|
|
DOMAIN(cs.exposed)
|
|
|
|
This example exposes the host inside of the CS subdomain -- that is,
|
|
it doesn't try to hide the name of the workstation to the outside
|
|
world. Changing this to DOMAIN(cs.hidden) would have made outgoing
|
|
messages refer to "<username>@CS.Berkeley.EDU" instead of using the
|
|
local hostname. Internally this is effected by using
|
|
"MASQUERADE_AS(CS.Berkeley.EDU)".
|
|
|
|
MAILER(smtp)
|
|
|
|
These describe the mailers used at the default CS site site. The
|
|
local mailer is always included automatically.
|
|
|
|
|
|
+--------+
|
|
| OSTYPE |
|
|
+--------+
|
|
|
|
Note that cf/cs-exposed.mc omits an OSTYPE macro -- this assumes
|
|
default Computer Science Division environment. There are several
|
|
explicit environments available: bsd4.3, bsd4.4, hpux, irix, osf1,
|
|
riscos4.5, sunos3.5, sunos4.1, and ultrix4.1. These change things
|
|
like the location of the alias file and queue directory. Some of
|
|
these files are identical to one another.
|
|
|
|
Operating system definitions are easy to write. They may define
|
|
the following variables (everything defaults, so an ostype file
|
|
may be empty).
|
|
|
|
ALIAS_FILE [/etc/aliases] The location of the text version
|
|
of the alias file(s). It can be a comma-separated
|
|
list of names (but be sure you quote values with
|
|
comments in them -- for example, use
|
|
define(`ALIAS_FILE', `a,b')
|
|
to get "a" and "b" both listed as alias files;
|
|
otherwise the define() primitive only sees "a").
|
|
HELP_FILE [/usr/lib/sendmail.hf] The name of the file
|
|
containing information printed in response to
|
|
the SMTP HELP command.
|
|
QUEUE_DIR [/var/spool/mqueue] The directory containing
|
|
queue files.
|
|
STATUS_FILE [/etc/sendmail.st] The file containing status
|
|
information.
|
|
LOCAL_MAILER_PATH [/bin/mail] The program used to deliver local mail.
|
|
LOCAL_MAILER_FLAGS [rmn] The flags used by the local mailer. The
|
|
flags lsDFM are always included.
|
|
LOCAL_MAILER_ARGS [mail -d $u] The arguments passed to deliver local
|
|
mail.
|
|
LOCAL_SHELL_PATH [/bin/sh] The shell used to deliver piped email.
|
|
LOCAL_SHELL_FLAGS [eu] The flags used by the shell mailer. The
|
|
flags lsDFM are always included.
|
|
LOCAL_SHELL_ARGS [sh -c $u] The arguments passed to deliver "prog"
|
|
mail.
|
|
USENET_MAILER_PATH [/usr/lib/news/inews] The name of the program
|
|
used to submit news.
|
|
USENET_MAILER_FLAGS [rlsDFMmn] The mailer flags for the usenet mailer.
|
|
USENET_MAILER_ARGS [-m -h -n] The command line arguments for the
|
|
usenet mailer.
|
|
USENET_MAILER_MAX [100000] The maximum size of messages that will
|
|
be accepted by the usenet mailer.
|
|
SMTP_MAILER_FLAGS [undefined] Flags added to SMTP mailer. Default
|
|
flags are `mDFMUX' (and `a' for esmtp mailer).
|
|
SMTP_MAILER_MAX [undefined] The maximum size of messages that will
|
|
be transported using the smtp or esmtp mailers.
|
|
UUCP_MAILER_FLAGS [undefined] Flags added to UUCP mailer. Default
|
|
flags are `DFMhuU' (and `m' for suucp mailer, minus
|
|
`U' for uucp-dom mailer).
|
|
UUCP_MAILER_ARGS [uux - -r -z -a$f -gC $h!rmail ($u)] The arguments
|
|
passed to the UUCP mailer.
|
|
UUCP_MAX_SIZE [100000] The maximum size message accepted for
|
|
transmission by the UUCP mailers.
|
|
FAX_MAILER_PATH [/usr/local/lib/fax/mailfax] The program used to
|
|
submit FAX messages.
|
|
FAX_MAILER_MAX [100000] The maximum size message accepted for
|
|
transmission by FAX.
|
|
|
|
+---------+
|
|
| DOMAINS |
|
|
+---------+
|
|
|
|
You will probably want to collect domain-dependent defines into one
|
|
file, referenced by the DOMAIN macro. For example, our Berkeley
|
|
domain file includes definitions for several internal distinguished
|
|
hosts:
|
|
|
|
UUCP_RELAY The host that will forward UUCP-addressed email.
|
|
If not defined, all UUCP sites must be directly
|
|
connected.
|
|
BITNET_RELAY The host that will forward BITNET-addressed email.
|
|
If not defined, the .BITNET pseudo-domain won't work.
|
|
LOCAL_RELAY The site that will handle unqualified names -- that
|
|
is, names with out an @domain extension. If not set,
|
|
they are assumed to belong on this machine. This
|
|
allows you to have a central site to store a
|
|
company- or department-wide alias database. This
|
|
only works at small sites, and there are better
|
|
methods.
|
|
|
|
Each of these can be either ``mailer:hostname'' (in which case the
|
|
mailer is the internal mailer name, such as ``suucp'' and the hostname
|
|
is the name of the host as appropriate for that mailer) or just a
|
|
``hostname'', in which case a default mailer type (usually ``relay'',
|
|
a variant on SMTP) is used. WARNING: if you have a wildcard MX
|
|
record matching your domain, you probably want to define these to
|
|
have a trailing dot so that you won't get the mail diverted back
|
|
to yourself.
|
|
|
|
The domain file can also be used to define a domain name, if needed
|
|
(using "DD<domain>") and set certain site-wide features. If all hosts
|
|
at your site masquerade behind one email name, you could also use
|
|
MASQUERADE_AS here.
|
|
|
|
You do not have to define a domain -- in particular, if you are a
|
|
single machine sitting off somewhere, it is probably more work than
|
|
it's worth. This is just a mechanism for combining "domain dependent
|
|
knowledge" into one place.
|
|
|
|
+---------+
|
|
| MAILERS |
|
|
+---------+
|
|
|
|
There are fewer mailers supported in this version than the previous
|
|
version, owing mostly to a simpler world.
|
|
|
|
local The local and prog mailers. You will almost always
|
|
need these; the only exception is if you relay ALL
|
|
your mail to another site. This mailer is included
|
|
automatically.
|
|
|
|
smtp The Simple Mail Transport Protocol mailer. This does
|
|
not hide hosts behind a gateway or another other
|
|
such hack; it assumes a world where everyone is
|
|
running the name server. This file actually defines
|
|
three mailers: "smtp" for regular (old-style) SMTP to
|
|
other servers, "esmtp" for extended SMTP to other
|
|
servers, and "relay" for transmission to our
|
|
RELAY_HOST or MAILER_HUB.
|
|
|
|
uucp The Unix-to-Unix Copy Program mailer. Actually, this
|
|
defines two mailers, "uucp" and "suucp". The latter
|
|
is for when you know that the UUCP mailer at the other
|
|
end can handle multiple recipients in one transfer.
|
|
When you invoke this, sendmail looks for all names in
|
|
the $=U class and sends them to the uucp-old mailer; all
|
|
names in the $=Y class are sent to uucp-new; and all
|
|
names in the $=Z class are sent to uucp-uudom. Note that
|
|
this is a function of what version of rmail runs on
|
|
the receiving end, and hence may be out of your control.
|
|
If smtp is defined, it also defines "uucp-dom" and
|
|
"uucp-uudom" mailers that use domain-style rewriting.
|
|
See the section below describing UUCP mailers in more
|
|
detail.
|
|
|
|
usenet Usenet (network news) delivery. If this is specified,
|
|
an extra rule is added to ruleset 0 that forwards all
|
|
local email for users named ``group.usenet'' to the
|
|
``inews'' program. Note that this works for all groups,
|
|
and may be considered a security problem.
|
|
|
|
fax Facsimile transmission. This is experimental and based
|
|
on Sam Leffler's FlexFAX software. For more information,
|
|
see below.
|
|
|
|
pop Post Office Protocol.
|
|
|
|
|
|
+----------+
|
|
| FEATURES |
|
|
+----------+
|
|
|
|
Special features can be requested using the "FEATURE" macro. For
|
|
example, the .mc line:
|
|
|
|
FEATURE(use_cw_file)
|
|
|
|
tells sendmail that you want to have it read an /etc/sendmail.cw
|
|
file to get values for class $=w. The FEATURE may contain a single
|
|
optional parameter -- for example:
|
|
|
|
FEATURE(mailertable, dbm /usr/lib/mailertable)
|
|
|
|
Available features are:
|
|
|
|
use_cw_file Read the file /etc/sendmail.cw file to get alternate
|
|
names for this host. This might be used if you were
|
|
on a host that MXed for a dynamic set of other
|
|
hosts. If the set is static, just including the line
|
|
"Cw<name1> <name2> ..." is probably superior.
|
|
The actual filename can be overridden by redefining
|
|
confCW_FILE.
|
|
|
|
redirect Reject all mail addressed to "address.REDIRECT" with
|
|
a ``551 User not local; please try <address>'' message.
|
|
If this is set, you can alias people who have left
|
|
to their new address with ".REDIRECT" appended.
|
|
|
|
nouucp Don't do anything special with UUCP addresses at all.
|
|
|
|
nocanonify Don't pass addresses to $[ ... $] for canonification.
|
|
This would generally only be used by sites that only
|
|
act as mail gateways or which have user agents that do
|
|
full canonification themselves. You may also want to
|
|
use "define(`confBIND_OPTS',`-DNSRCH -DEFNAMES')" to
|
|
turn off the usual resolver options that do a similar
|
|
thing.
|
|
|
|
notsticky By default, email sent to "user@local.host" are marked
|
|
as "sticky" -- that is, the local addresses aren't
|
|
matched against UDB and don't go through ruleset 5.
|
|
This features disables this treatment. It would
|
|
normally be used on network gateway machines.
|
|
|
|
mailertable Include a "mailer table" which can be used to override
|
|
routing for particular domains. The argument of the
|
|
FEATURE may be the key definition. If none is specified,
|
|
the definition used is:
|
|
hash -o /etc/mailertable
|
|
Keys in this database are fully qualified domain names
|
|
or partial domains preceded by a dot -- for example,
|
|
"vangogh.CS.Berkeley.EDU" or ".CS.Berkeley.EDU".
|
|
Values must be of the form:
|
|
mailer:domain
|
|
where "mailer" is the internal mailer name, and "domain"
|
|
is where to send the message. These maps are not
|
|
reflected into the message header.
|
|
|
|
domaintable Include a "domain table" which can be used to provide
|
|
full domains on unqualified (single word) hosts. The
|
|
argument of the FEATURE may be the key definition. If
|
|
none is specified, the definition used is:
|
|
hash -o /etc/domaintable
|
|
The key in this table is the unqualified host name; the
|
|
value is the fully qualified domain. Anything in the
|
|
domaintable is reflected into headers; that is, this
|
|
is done in ruleset 3.
|
|
|
|
bitdomain Look up bitnet hosts in a table to try to turn them into
|
|
internet addresses. The table can be built using the
|
|
bitdomain program contributed by John Gardiner Myers.
|
|
The argument of the FEATURE may be the key definition; if
|
|
none is specified, the definition used is:
|
|
hash -o /etc/bitdomain.db
|
|
Keys are the bitnet hostname; values are the corresponding
|
|
internet hostname.
|
|
|
|
uucpdomain Similar feature for UUCP hosts. The default map definition
|
|
is:
|
|
hash -o /etc/uudomain.db
|
|
At the moment there is no automagic tool to build this
|
|
database.
|
|
|
|
always_add_domain
|
|
Include the local host domain even on locally delivered
|
|
mail. Normally it is not added unless it is already
|
|
present.
|
|
|
|
allmasquerade If masquerading is enabled (using MASQUERADE_AS), this
|
|
feature will cause recipient addresses to also masquerade
|
|
as being from the masquerade host. Normally they get
|
|
the local hostname. Although this may be right for
|
|
ordinary users, it can break local aliases. For example,
|
|
if you send to "localalias", the originating sendmail will
|
|
find that alias and send to all members, but send the
|
|
message with "To: localalias@masqueradehost". Since that
|
|
alias likely does not exist, replies will fail. Use this
|
|
feature ONLY if you can guarantee that the ENTIRE
|
|
namespace on your masquerade host supersets all the
|
|
local entries.
|
|
|
|
nodns We aren't running DNS at our site (for example,
|
|
we are UUCP-only connected). It's hard to consider
|
|
this a "feature", but hey, it had to go somewhere.
|
|
|
|
nullclient This is a special case -- it creates a stripped down
|
|
configuration file containing nothing but support for
|
|
forwarding all mail to a central hub via a local
|
|
SMTP-based network. The argument is the name of that
|
|
hub.
|
|
|
|
The only other feature that should be used in conjunction
|
|
with this one is "nocanonify" (this causes addresses to
|
|
be sent unqualified via the SMTP connection; normally
|
|
they are qualifed with the masquerade name, which
|
|
defaults to the name of the hub machine). No mailers
|
|
should be defined. No aliasing or forwarding is done.
|
|
|
|
|
|
+-------+
|
|
| HACKS |
|
|
+-------+
|
|
|
|
Some things just can't be called features. To make this clear,
|
|
they go in the hack subdirectory and are referenced using the HACK
|
|
macro. These will tend to be site-dependent. The release
|
|
includes the Berkeley-dependent "cssubdomain" hack (that makes
|
|
sendmail accept local names in either Berkeley.EDU or CS.Berkeley.EDU;
|
|
this is intended as a short-term aid while we move hosts into
|
|
subdomains.
|
|
|
|
|
|
+--------------------+
|
|
| SITE CONFIGURATION |
|
|
+--------------------+
|
|
|
|
Complex sites will need more local configuration information, such as
|
|
lists of UUCP hosts they speak with directly. This can get a bit more
|
|
tricky. For an example of a "complex" site, see cf/ucbvax.mc.
|
|
|
|
If your host is known by several different names, you need to augment
|
|
the $=w class. This is a list of names by which you are known, and
|
|
anything sent to an address using a host name in this list will be
|
|
treated as local mail. You can do this in two ways: either create
|
|
the file /etc/sendmail.cw containing a list of your aliases (one per
|
|
line), and use ``FEATURE(use_cw_file)'' in the .mc file, or add the
|
|
line:
|
|
|
|
Cw alias.host.name
|
|
|
|
at the end of that file. See the ``vangogh.mc'' file for an example.
|
|
Be sure you use the fully-qualified name of the host, rather than a
|
|
short name.
|
|
|
|
The SITECONFIG macro allows you to indirectly reference site-dependent
|
|
configuration information stored in the siteconfig subdirectory. For
|
|
example, the line
|
|
|
|
SITECONFIG(uucp.ucbvax, ucbvax, U)
|
|
|
|
reads the file uucp.ucbvax for local connection information. The
|
|
second parameter is the local name (in this case just "ucbvax" since
|
|
it is locally connected, and hence a UUCP hostname). The third
|
|
parameter is the name of both a macro to store the local name (in
|
|
this case, $U) and the name of the class (e.g., $=U) in which to store
|
|
the host information read from the file. Another SITECONFIG line reads
|
|
|
|
SITECONFIG(uucp.ucbarpa, ucbarpa.Berkeley.EDU, W)
|
|
|
|
This says that the file uucp.ucbarpa contains the list of UUCP sites
|
|
connected to ucbarpa.Berkeley.EDU. The $=W class will be used to
|
|
store this list, and $W is defined to be ucbarpa.Berkeley.EDU, that
|
|
is, the name of the relay to which the hosts listed in uucp.ucbarpa
|
|
are connected. [The machine ucbarpa is gone now, but I've left
|
|
this out-of-date configuration file around to demonstrate how you
|
|
might do this.]
|
|
|
|
Note that the case of SITECONFIG with a third parameter of ``U'' is
|
|
special; the second parameter is assumed to be the UUCP name of the
|
|
local site, rather than the name of a remote site, and the UUCP name
|
|
is entered into $=w (the list of local hostnames) as $U.UUCP.
|
|
|
|
The siteconfig file (e.g., siteconfig/uucp.ucbvax.m4) contains nothing
|
|
more than a sequence of SITE macros describing connectivity. For
|
|
example:
|
|
|
|
SITE(cnmat)
|
|
SITE(sgi olympus)
|
|
|
|
The second example demonstrates that you can use two names on the
|
|
same line; these are usually aliases for the same host (or are at
|
|
least in the same company).
|
|
|
|
|
|
+--------------------+
|
|
| USING UUCP MAILERS |
|
|
+--------------------+
|
|
|
|
It's hard to get UUCP mailers right because of the extremely ad hoc
|
|
nature of UUCP addressing. These config files are really designed
|
|
for domain-based addressing, even for UUCP sites.
|
|
|
|
There are four UUCP mailers available. The choice of which one to
|
|
use is partly a matter of local preferences and what is running at
|
|
the other end of your UUCP connection. Unlike good protocols that
|
|
define what will go over the wire, UUCP uses the policy that you
|
|
should do what is right for the other end; if they change, you have
|
|
to change. This makes it hard to do the right thing, and discourages
|
|
people from updating their software. In general, if you can avoid
|
|
UUCP, please do.
|
|
|
|
The major choice is whether to go for a domainized scheme or a
|
|
non-domainized scheme. This depends entirely on what the other
|
|
end will recognize. If at all possible, you should encourage the
|
|
other end to go to a domain-based system -- non-domainized addresses
|
|
don't work entirely properly.
|
|
|
|
The four mailers are:
|
|
|
|
uucp-old (obsolete name: "uucp")
|
|
This is the oldest, the worst (but the closest to UUCP) way of
|
|
sending messages accros UUCP connections. It does bangify
|
|
everything and prepends $U (your UUCP name) to the sender's
|
|
address (which can already be a bang path itself). It can
|
|
only send to one address at a time, so it spends a lot of
|
|
time copying duplicates of messages. Avoid this if at all
|
|
possible.
|
|
|
|
uucp-new (obsolete name: "suucp")
|
|
The same as above, except that it assumes that in one rmail
|
|
command you can specify several recipients. It still has a
|
|
lot of other problems.
|
|
|
|
uucp-dom
|
|
This UUCP mailer keeps everything as domain addresses.
|
|
Basically, it uses the SMTP mailer rewriting rules.
|
|
|
|
Unfortunately, a lot of UUCP mailer transport agents require
|
|
bangified addresses in the envelope, although you can use
|
|
domain-based addresses in the message header. (The envelope
|
|
shows up as the From_ line on UNIX mail.) So....
|
|
|
|
uucp-uudom
|
|
This is a cross between uucp-new (for the envelope addresses)
|
|
and uucp-dom (for the header addresses). It bangifies the
|
|
envelope sender (From_ line in messages) without adding the
|
|
local hostname, unless there is no host name on the address
|
|
at all (e.g., "wolf") or the host component is a UUCP host name
|
|
instead of a domain name ("somehost!wolf" instead of
|
|
"some.dom.ain!wolf").
|
|
|
|
Examples:
|
|
|
|
We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The
|
|
following summarizes the sender rewriting for various mailers.
|
|
|
|
Mailer sender rewriting in the envelope
|
|
------ ------ -------------------------
|
|
uucp-{old,new} wolf grasp!wolf
|
|
uucp-dom wolf wolf@grasp.insa-lyon.fr
|
|
uucp-uudom wolf grasp.insa-lyon.fr!wolf
|
|
|
|
uucp-{old,new} wolf@fr.net grasp!fr.net!wolf
|
|
uucp-dom wolf@fr.net wolf@fr.net
|
|
uucp-uudom wolf@fr.net fr.net!wolf
|
|
|
|
uucp-{old,new} somehost!wolf grasp!somehost!wolf
|
|
uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr
|
|
uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf
|
|
|
|
If you are using one of the domainized UUCP mailers, you really want
|
|
to convert all UUCP addresses to domain format -- otherwise, it will
|
|
do it for you (and probably not the way you expected). For example,
|
|
if you have the address foo!bar!baz (and you are not sending to foo),
|
|
the heuristics will add the @uucp.relay.name or @local.host.name to
|
|
this address. However, if you map foo to foo.host.name first, it
|
|
will not add the local hostname. You can do this using the uucpdomain
|
|
feature.
|
|
|
|
|
|
+-------------------+
|
|
| TWEAKING RULESETS |
|
|
+-------------------+
|
|
|
|
For more complex configurations, you can define special rules.
|
|
The macro LOCAL_RULE_3 introduces rules that are used in canonicalizing
|
|
the names. Any modifications made here are reflected in the header.
|
|
|
|
A common use is to convert old UUCP addreses to SMTP addresses using
|
|
the UUCPSMTP macro. For example:
|
|
|
|
LOCAL_RULE_3
|
|
UUCPSMTP(decvax, decvax.dec.com)
|
|
UUCPSMTP(research, research.att.com)
|
|
|
|
will cause addresses of the form "decvax!user" and "research!user"
|
|
to be converted to "user@decvax.dec.com" and "user@research.att.com"
|
|
respectively.
|
|
|
|
This could also be used to look up hosts in a database map:
|
|
|
|
LOCAL_RULE_3
|
|
R$* < @ $+ > $* $: $1 < @ $(hostmap $2 $) > $3
|
|
|
|
This map would be defined in the LOCAL_CONFIG portion, as shown below.
|
|
|
|
Similarly, LOCAL_RULE_0 can be used to introduce new parsing rules.
|
|
For example, new rules are needed to parse hostnames that you accept
|
|
via MX records. For example, you might have:
|
|
|
|
LOCAL_RULE_0
|
|
R$+ <@ host.dom.ain.> $#uucp $@ cnmat $: $1 < @ host.dom.ain.>
|
|
|
|
You would use this if you had installed an MX record for cnmat.Berkeley.EDU
|
|
pointing at this host; this rule catches the message and forwards it on
|
|
using UUCP.
|
|
|
|
You can also tweak rulesets 1 and 2 using LOCAL_RULE_1 and LOCAL_RULE_2.
|
|
These rulesets are normally empty.
|
|
|
|
A similar macro is LOCAL_CONFIG. This introduces lines added after the
|
|
boilerplate option setting but before rulesets, and can be used to
|
|
declare local database maps or whatever. For example:
|
|
|
|
LOCAL_CONFIG
|
|
Khostmap hash /etc/hostmap.db
|
|
Kyplocal nis -m hosts.byname
|
|
|
|
|
|
+---------------------------+
|
|
| MASQUERADING AND RELAYING |
|
|
+---------------------------+
|
|
|
|
You can have your host masquerade as another using
|
|
|
|
MASQUERADE_AS(host.domain)
|
|
|
|
This causes outgoing SMTP mail to be labeled as coming from the
|
|
indicated domain, rather than $j. One normally masquerades as one
|
|
of one's own subdomains (for example, it's unlikely that I would
|
|
choose to masquerade as an MIT site).
|
|
|
|
The masquerade name is not normally canonified, so it is important
|
|
that it be your One True Name, that is, fully qualified and not a
|
|
CNAME.
|
|
|
|
there are always users that need to be "exposed" -- that is, their
|
|
internal site name should be displayed instead of the masquerade name.
|
|
Root is an example. You can add users to this list using
|
|
|
|
EXPOSED_USER(usernames)
|
|
|
|
This adds users to class E; you could also use something like
|
|
|
|
FE/etc/sendmail.cE
|
|
|
|
You can also arrange to relay all unqualified names (that is, names
|
|
without @host) to a relay host. For example, if you have a central
|
|
email server, you might relay to that host so that users don't have
|
|
to have .forward files or aliases. You can do this using
|
|
|
|
define(`LOCAL_RELAY', mailer:hostname)
|
|
|
|
The ``mailer:'' can be omitted, in which case the mailer defaults to
|
|
"smtp". There are some user names that you don't want relayed, perhaps
|
|
because of local aliases. A common example is root, which may be
|
|
locally aliased. You can add entries to this list using
|
|
|
|
LOCAL_USER(usernames)
|
|
|
|
This adds users to class L; you could also use something like
|
|
|
|
FL/etc/sendmail.cL
|
|
|
|
If you want all incoming mail sent to a centralized hub, as for a
|
|
shared /var/spool/mail scheme, use
|
|
|
|
define(`MAIL_HUB', mailer:hostname)
|
|
|
|
Again, ``mailer:'' defaults to "smtp". If you define both LOCAL_RELAY
|
|
and MAIL_HUB, unqualified names will be sent to the LOCAL_RELAY and
|
|
other local names will be sent to MAIL_HUB. Names in $=L will be
|
|
delivered locally, so you MUST have aliases or .forward files for them.
|
|
|
|
For example, if are on machine mastodon.CS.Berkeley.EDU, the following
|
|
combinations of settings will have the indicated effects:
|
|
|
|
email sent to.... eric eric@mastodon.CS.Berkeley.EDU
|
|
|
|
LOCAL_RELAY set to mail.CS.Berkeley.EDU (delivered locally)
|
|
mail.CS.Berkeley.EDU
|
|
|
|
MAIL_HUB set to mammoth.CS.Berkeley.EDU mammoth.CS.Berkeley.EDU
|
|
mammoth.CS.Berkeley.EDU
|
|
|
|
Both LOCAL_RELAY and mail.CS.Berkeley.EDU mammoth.CS.Berkeley.EDU
|
|
MAIL_HUB set as above
|
|
|
|
If you want all outgoing mail to go to a central relay site, define
|
|
SMART_HOST as well. Briefly:
|
|
|
|
LOCAL_RELAY applies to unqualifed names (e.g., "eric").
|
|
MAIL_HUB applies to names qualified with the name of the
|
|
local host (e.g., "eric@mastodon.CS.Berkeley.EDU").
|
|
SMART_HOST applies to names qualified with other hosts.
|
|
|
|
However, beware that other relays (e.g., UUCP_RELAY, BITNET_RELAY, and
|
|
FAX_RELAY) take precedence over SMART_HOST, so if you really want
|
|
absolutely everything to go to a single central site you will need to
|
|
unset all the other relays -- or better yet, find or build a minimal
|
|
config file that does this.
|
|
|
|
|
|
+-------------------------------+
|
|
| NON-SMTP BASED CONFIGURATIONS |
|
|
+-------------------------------+
|
|
|
|
These configuration files are designed primarily for use by SMTP-based
|
|
sites. I don't pretend that they are well tuned for UUCP-only or
|
|
UUCP-primarily nodes (the latter is defined as a small local net
|
|
connected to the rest of the world via UUCP). However, there is one
|
|
hook to handle some special cases.
|
|
|
|
You can define a ``smart host'' that understands a richer address syntax
|
|
using:
|
|
|
|
define(`SMART_HOST', mailer:hostname)
|
|
|
|
In this case, the ``mailer:'' defaults to "relay". Any messages that
|
|
can't be handled using the usual UUCP rules are passed to this host.
|
|
|
|
If you are on a local SMTP-based net that connects to the outside
|
|
world via UUCP, you can use LOCAL_NET_CONFIG to add appropriate rules.
|
|
For example:
|
|
|
|
define(`SMART_HOST', suucp:uunet)
|
|
LOCAL_NET_CONFIG
|
|
R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3
|
|
|
|
This will cause all names that end in your domain name ($m) via
|
|
SMTP; anything else will be sent via suucp (smart UUCP) to uunet.
|
|
If you have FEATURE(nocanonify), you may need to omit the dots after
|
|
the $m. If you are running a local DNS inside your domain which is
|
|
not otherwise connected to the outside world, you probably want to
|
|
use:
|
|
|
|
define(`SMART_HOST', smtp:fire.wall.com)
|
|
LOCAL_NET_CONFIG
|
|
R$* < @ $* . > $* $#smtp $@ $2. $: $1 < @ $2. > $3
|
|
|
|
That is, send directly only to things you found in your DNS lookup;
|
|
anything else goes through SMART_HOST.
|
|
|
|
If you are not running DNS at all, it is important to use
|
|
FEATURE(nodns) to avoid having sendmail queue everything waiting
|
|
for the name server to come up.
|
|
|
|
|
|
+-----------+
|
|
| WHO AM I? |
|
|
+-----------+
|
|
|
|
Normally, the $j macro is automatically defined to be your fully
|
|
qualified domain name (FQDN). Sendmail does this by getting your
|
|
host name using gethostname and then calling gethostbyname on the
|
|
result. For example, in some environments gethostname returns
|
|
only the root of the host name (such as "foo"); gethostbyname is
|
|
supposed to return the FQDN ("foo.bar.com"). In some (fairly rare)
|
|
cases, gethostbyname may fail to return the FQDN. In this case
|
|
you MUST define confDOMAIN_NAME to be your fully qualified domain
|
|
name. This is usually done using:
|
|
|
|
Dmbar.com
|
|
define(`confDOMAIN_NAME', `$w.$m')dnl
|
|
|
|
|
|
+--------------------+
|
|
| USING MAILERTABLES |
|
|
+--------------------+
|
|
|
|
To use FEATURE(mailertable), you will have to create an external
|
|
database containing the routing information for various domains.
|
|
For example, a mailertable file in text format might be:
|
|
|
|
.my.domain xnet:%1.my.domain
|
|
uuhost1.my.domain suucp:uuhost1
|
|
.bitnet smtp:relay.bit.net
|
|
|
|
This should normally be stored in /etc/mailertable. The actual
|
|
database version of the mailertable is built using:
|
|
|
|
makemap hash /etc/mailertable.db < /etc/mailertable
|
|
|
|
The semantics are simple. Any LHS entry that does not begin with
|
|
a dot matches the full host name indicated. LHS entries beginning
|
|
with a dot match anything ending with that domain name -- that is,
|
|
they can be thought of as having a leading "*" wildcard. Matching
|
|
is done in order of most-to-least qualified -- for example, even
|
|
though ".my.domain" is listed first in the above example, an entry
|
|
of "uuhost1.my.domain" will match the second entry since it is
|
|
more explicit.
|
|
|
|
The RHS should always be a "mailer:host" pair. The mailer is the
|
|
configuration name of a mailer (that is, an `M' line in the
|
|
sendmail.cf file). The "host" will be the hostname passed to
|
|
that mailer. In domain-based matches (that is, those with leading
|
|
dots) the "%1" may be used to interpolate the wildcarded part of
|
|
the host name. For example, the first line above sends everything
|
|
addressed to "anything.my.domain" to that same host name, but using
|
|
the (presumably experimental) xnet mailer.
|
|
|
|
|
|
+--------------------------------+
|
|
| USING USERDB TO MAP FULL NAMES |
|
|
+--------------------------------+
|
|
|
|
The user database was not originally intended for mapping full names
|
|
to login names (e.g., Eric.Allman => eric), but some people are using
|
|
it that way. (I would recommend that you set up aliases for this
|
|
purpose instead -- since you can specify multiple alias files, this
|
|
is fairly easy.) The intent was to locate the default maildrop at
|
|
a site, but allow you to override this by sending to a specific host.
|
|
|
|
If you decide to set up the user database in this fashion, it is
|
|
imperative that you also specify FEATURE(notsticky) -- otherwise,
|
|
e-mail sent to Full.Name@local.host.name will be rejected.
|
|
|
|
To build the internal form of the user databae, use:
|
|
|
|
makemap btree /usr/data/base.db < /usr/data/base.txt
|
|
|
|
|
|
+------------------+
|
|
| FlexFAX SOFTWARE |
|
|
+------------------+
|
|
|
|
Sam Leffler's FlexFAX software is still in beta test -- but he expects a
|
|
public version out "later this week" [as of 3/1/93]. The following
|
|
blurb is direct from Sam:
|
|
|
|
$Header: /usr/people/sam/fax/RCS/HOWTO,v 1.14 93/05/24 11:42:16 sam Exp $
|
|
|
|
How To Obtain This Software (in case all you get is this file)
|
|
--------------------------------------------------------------
|
|
The source code is available for public ftp on
|
|
sgi.com sgi/fax/v2.1.src.tar.Z
|
|
(192.48.153.1)
|
|
|
|
You can also obtain inst'able images for Silicon Graphics machines from
|
|
sgi.com sgi/fax/v2.1.inst.tar
|
|
(192.48.153.1)
|
|
|
|
For example,
|
|
% ftp -n sgi.com
|
|
....
|
|
ftp> user anonymous
|
|
... <type in password>
|
|
ftp> cd sgi/fax
|
|
ftp> binary
|
|
ftp> get v2.1.src.tar.Z
|
|
|
|
In general, the latest version of the 2.1 release of the software is
|
|
always available as "v2.1.src.tar.Z" or "v2.1.inst.tar" in the ftp
|
|
directory. This file is a link to the appropriate released version (so
|
|
don't waste your time retrieving the linked file as well!) Any files of
|
|
the form v2.1.*.patch are shell scripts that can be used to patch older
|
|
versions of the source code. For example, the file v2.1.0.patch would
|
|
contain patches to update v2.1.0.tar.Z. (Note to beta testers: this is
|
|
different than the naming conventions used during beta testing.) Patch
|
|
files only work to go between consecutive versions, so if you are
|
|
multiple versions behind the latest release, you will need to apply
|
|
each patch file between your current version and the latest.
|
|
|
|
|
|
Obtaining the Software by Electronic Mail
|
|
-----------------------------------------
|
|
Do not send me requests for the software; they will be ignored (without
|
|
response). If you cannot use FTP at all, there is a service called
|
|
"ftpmail" available from gatekeeper.dec.com: you can send e-mail to
|
|
this machine and it will use FTP to retrieve files for you and send you
|
|
the files back again via e-mail. To find out more about the ftpmail
|
|
service, send a message to "ftpmail@gatekeeper.dec.com" whose body
|
|
consists of the single line "help".
|
|
|
|
|
|
Obtaining the Software Within Silicon Graphics
|
|
----------------------------------------------
|
|
Internal to Silicon Graphics there are inst'able images on the host
|
|
flake.asd in the directory /usr/dist. Thus you can do something like:
|
|
|
|
% inst -f flake.asd.sgi.com:/usr/dist/flexfax
|
|
|
|
to install the latest version of the software on your machine.
|
|
|
|
|
|
What to do Once You've Retrieved Stuff
|
|
--------------------------------------
|
|
The external distributions come in a compressed or uncompressed tar
|
|
file. To extract the source distribution:
|
|
|
|
% zcat v2.1.src.tar.Z | tar xf -
|
|
|
|
(uncompress and extract individual files in current directory). To
|
|
unpack and install the client portion of the inst'able distribution:
|
|
|
|
% mkdir dist
|
|
% cd dist; tar xf ../v2.1.inst.tar; cd ..
|
|
% inst -f dist/flexfax
|
|
...
|
|
inst> go
|
|
|
|
(Note, the dist subdirectory is because some versions of inst fail if
|
|
the files are in the current directory.) Server binaries are also
|
|
included in the inst'able images as flexfax.server.*. They are not
|
|
installed by default, so to get them also you need to do:
|
|
|
|
% inst -f flexfax
|
|
...
|
|
inst> install flexfax.server.*
|
|
inst> go
|
|
|
|
The SGI binaries were built for Version 4.0.5H of the IRIX operating
|
|
system. They should work w/o problem on earlier versions of the
|
|
system, but I have not fully tested this. Also, note that to install a
|
|
server on an SGI machine, you need to have installed the Display
|
|
PostScript execution environment product (dps_eoe). Otherwise, the fax
|
|
server will not be able to convert PostScript to facsimile for
|
|
transmission.
|
|
|
|
If you are working from the source distribution, look at the file
|
|
README in the top of the source tree. If you are working from the inst
|
|
images, the subsystem flexfax.man.readme contains the README file and
|
|
other useful pieces of information--the installed files are placed in
|
|
the directory /usr/local/doc/flexfax). Basically you will need to run
|
|
the faxaddmodem script to setup and configure your fax modem. Consult
|
|
the README file and the manual page for faxaddmodem for information.
|
|
|
|
|
|
FlexFAX Mail List
|
|
-----------------
|
|
A mailing list for users of this software is located on sgi.com.
|
|
If you want to join this mailing list or have a list-related request
|
|
such as getting your name removed from it, send a request to
|
|
|
|
majordomo@whizzer.wpd.sgi.com
|
|
|
|
For example, to subscribe, send the line "subscribe flexfax" in
|
|
the body of your message. The line "help" will return a list of
|
|
the commands understood by the mailing list management software.
|
|
|
|
Submissions (including bug reports) should be directed to:
|
|
|
|
flexfax@sgi.com
|
|
|
|
When corresponding about this software please always specify what
|
|
version you have, what system you're running on, and, if the problem is
|
|
specific to your modem, identify the modem and firmware revision.
|
|
|
|
|
|
+--------------------------------+
|
|
| TWEAKING CONFIGURATION OPTIONS |
|
|
+--------------------------------+
|
|
|
|
There are a large number of configuration options that don't normally
|
|
need to be changed. However, if you feel you need to tweak them, you
|
|
can define the following M4 variables. This list is shown in four
|
|
columns: the name you define, the default value for that definition,
|
|
the option or macro that is affected (either Ox for an option or Dx
|
|
for a macro), and a brief description. Greater detail of the semantics
|
|
can be found in the Installation and Operations Guide.
|
|
|
|
Some options are likely to be deprecated in future versions -- that is,
|
|
the option is only included to provide back-compatibility. These are
|
|
marked with "*".
|
|
|
|
Remember that these options are M4 variables, and hence may need to
|
|
be quoted. In particular, arguments with commas will usually have to
|
|
be ``double quoted, like this phrase'' to avoid having the comma
|
|
confuse things. This is common for alias file definitions and for
|
|
the read timeout.
|
|
|
|
M4 Variable Name Default Mac/Opt Description
|
|
================ ======= ======= ===========
|
|
confMAILER_NAME MAILER-DAEMON Dn The sender name used for
|
|
internally generated
|
|
outgoing messages.
|
|
confFROM_LINE From $g $d Dl The From_ line used when
|
|
sending to files or programs.
|
|
confFROM_HEADER $?x$x <$g>$|$g$. The format of an internally
|
|
Dq generated From: address.
|
|
confOPERATORS .:%@!^/[] Do Address operator characters.
|
|
confSMTP_LOGIN_MSG $j Sendmail $v/$Z ready at $b
|
|
De The initial (spontaneous)
|
|
SMTP greeting message.
|
|
confSEVEN_BIT_INPUT False O7 Force input to seven bits?
|
|
confALIAS_WAIT 10 Oa Wait (in minutes) for alias
|
|
file rebuild.
|
|
confMIN_FREE_BLOCKS 4 Ob Minimum number of free blocks
|
|
on queue filesystem to accept
|
|
SMTP mail.
|
|
confBLANK_SUB . OB Blank (space) substitution
|
|
character.
|
|
confCON_EXPENSIVE False Oc Avoid connecting immediately
|
|
to mailers marked expensive?
|
|
confCHECKPOINT_INTERVAL 10 OC Checkpoint queue files
|
|
every N recipients.
|
|
confDELIVERY_MODE background Od Default delivery mode.
|
|
confAUTO_REBUILD False OD Automatically rebuild
|
|
alias file if needed.
|
|
confERROR_MODE (undefined) Oe Error message mode.
|
|
confERROR_MESSAGE (undefined) OE Error message header/file.
|
|
confSAVE_FROM_LINES False Of Save extra leading
|
|
From_ lines.
|
|
confTEMP_FILE_MODE 0600 OF Temporary file mode.
|
|
confDEF_GROUP_ID 1 Og Default group id.
|
|
confMATCH_GECOS False OG Match GECOS field.
|
|
confMAX_HOP 17 Oh Maximum hop count.
|
|
confIGNORE_DOTS False Oi * Ignore dot as terminator
|
|
for incoming messages?
|
|
confBIND_OPTS (empty) OI Default options for BIND.
|
|
confMIME_FORMAT_ERRORS True Oj * Send error messages as MIME-
|
|
encapsulated messages per
|
|
RFC 1344.
|
|
confFORWARD_PATH (undefined) OJ The colon-separated list of
|
|
places to search for .forward
|
|
files.
|
|
confMCI_CACHE_SIZE 2 Ok Size of open connection cache.
|
|
confMCI_CACHE_TIMEOUT 5m OK Open connection cache timeout.
|
|
confUSE_ERRORS_TO False Ol * Use the Errors-To: header to
|
|
deliver error messages. This
|
|
should not be necessary because
|
|
of general acceptance of the
|
|
envelope/header distinction.
|
|
confLOG_LEVEL 9 OL Log level.
|
|
confME_TOO False Om Include sender in group
|
|
expansions.
|
|
confCHECK_ALIASES True On Check RHS of aliases when
|
|
running newaliases.
|
|
confOLD_STYLE_HEADERS True Oo * Assume that headers without
|
|
special chars are old style.
|
|
confDAEMON_OPTIONS (undefined) OO SMTP daemon options.
|
|
confPRIVACY_FLAGS authwarnings Op Privacy flags.
|
|
confCOPY_ERRORS_TO (undefined) OP Address for additional copies
|
|
of all error messages.
|
|
confQUEUE_FACTOR (undefined) Oq Slope of queue-only function
|
|
confREAD_TIMEOUT (undefined) Or SMTP read timeouts.
|
|
confSAFE_QUEUE True Os * Commit all messages to disk
|
|
before forking.
|
|
confMESSAGE_TIMEOUT 5d/4h OT Timeout for messages before
|
|
sending error/warning message.
|
|
confTIME_ZONE USE_SYSTEM Ot Time zone info -- can be
|
|
USE_SYSTEM to use the system's
|
|
idea, USE_TZ to use the user's
|
|
TZ envariable, or something
|
|
else to force that value.
|
|
confDEF_USER_ID 1 Ou Default user id.
|
|
confUSERDB_SPEC (undefined) OU User database specification.
|
|
confFALLBACK_MX (undefined) OV Fallback MX host.
|
|
confTRY_NULL_MX_LIST False Ow If we are the best MX for a
|
|
host and haven't made other
|
|
arrangements, try connecting
|
|
to the host directly; normally
|
|
this would be a config error.
|
|
confQUEUE_LA 8 Ox Load average at which queue-only
|
|
function kicks in.
|
|
confREFUSE_LA 12 OX Load average at which incoming
|
|
SMTP connections are refused.
|
|
confWORK_RECIPIENT_FACTOR
|
|
(undefined) Oy Cost of each recipient.
|
|
confSEPARATE_PROC False OY Run all deliveries in a
|
|
separate process.
|
|
confWORK_CLASS_FACTOR (undefined) Oz Priority multiplier for class.
|
|
confWORK_TIME_FACTOR (undefined) OZ Cost of each delivery attempt.
|
|
confCW_FILE /etc/sendmail.cw Name of file used to get the
|
|
Fw local additions to the $=w
|
|
class.
|
|
confSMTP_MAILER smtp - The mailer name used when
|
|
SMTP connectivity is required.
|
|
Either "smtp" or "esmtp".
|
|
confLOCAL_MAILER local - The mailer name used when
|
|
local connectivity is required.
|
|
Almost always "local".
|
|
confRELAY_MAILER relay - The default mailer name used
|
|
for relaying any mail (e.g.,
|
|
to a BITNET_RELAY, a
|
|
SMART_HOST, or whatever).
|
|
This can reasonably be "suucp"
|
|
if you are on a UUCP-connected
|
|
site.
|
|
confDOMAIN_NAME (undefined) Dj If defined, sets $j.
|
|
|
|
|
|
+-----------+
|
|
| HIERARCHY |
|
|
+-----------+
|
|
|
|
Within this directory are several subdirectories, to wit:
|
|
|
|
m4 General support routines. These are typically
|
|
very important and should not be changed without
|
|
very careful consideration.
|
|
|
|
cf The configuration files themselves. They have
|
|
".mc" suffixes, and must be run through m4 to
|
|
become complete. The resulting output should
|
|
have a ".cf" suffix.
|
|
|
|
ostype Definitions describing a particular operating
|
|
system type. These should always be referenced
|
|
using the OSTYPE macro in the .mc file. Examples
|
|
include "bsd4.3", "bsd4.4", "sunos3.5", and
|
|
"sunos4.1".
|
|
|
|
domain Definitions describing a particular domain, referenced
|
|
using the DOMAIN macro in the .mc file. These are
|
|
site dependent; for example, we contribute "cs.exposed.m4"
|
|
and "cs.hidden.m4" which both describe hosts in the
|
|
CS.Berkeley.EDU subdomain; the former displays the local
|
|
hostname (e.g., mammoth.CS.Berkeley.EDU), whereas the
|
|
latter does its best to hide the identity of the local
|
|
workstation inside the CS subdomain.
|
|
|
|
mailer Descriptions of mailers. These are referenced using
|
|
the MAILER macro in the .mc file.
|
|
|
|
sh Shell files used when building the .cf file from the
|
|
.mc file in the cf subdirectory.
|
|
|
|
feature These hold special orthogonal features that you might
|
|
want to include. They should be referenced using
|
|
the FEATURE macro.
|
|
|
|
hack Local hacks. These can be referenced using the HACK
|
|
macro. They shouldn't be of more than voyeuristic
|
|
interest outside the .Berkeley.EDU domain, but who knows?
|
|
We've all got our own peccadillos.
|
|
|
|
siteconfig Site configuration -- e.g., tables of locally connected
|
|
UUCP sites.
|
|
|
|
|
|
+------------------------+
|
|
| ADMINISTRATIVE DETAILS |
|
|
+------------------------+
|
|
|
|
The following sections detail usage of certain internal parts of the
|
|
sendmail.cf file. Read them carefully if you are trying to modify
|
|
the current model. If you find the above descriptions adequate, these
|
|
should be {boring, confusing, tedious, ridiculous} (pick one or more).
|
|
|
|
RULESETS (* means built in to sendmail)
|
|
|
|
0 * Parsing
|
|
1 * Sender rewriting
|
|
2 * Recipient rewriting
|
|
3 * Canonicalization
|
|
4 * Post cleanup
|
|
5 * Local address rewrite (after aliasing)
|
|
1x mailer rules (sender qualification)
|
|
2x mailer rules (recipient qualification)
|
|
3x mailer rules (sender header qualification)
|
|
4x mailer rules (recipient header qualification)
|
|
5x mailer subroutines (general)
|
|
6x mailer subroutines (general)
|
|
7x mailer subroutines (general)
|
|
8x reserved
|
|
90 Mailertable host stripping
|
|
96 Bottom half of Ruleset 3 (ruleset 6 in old sendmail)
|
|
97 Hook for recursive ruleset 0 call (ruleset 7 in old sendmail)
|
|
98 Local part of ruleset 0 (ruleset 8 in old sendmail)
|
|
|
|
|
|
MAILERS
|
|
|
|
0 local, prog local and program mailers
|
|
1 [e]smtp, relay SMTP channel
|
|
2 uucp-* UNIX-to-UNIX Copy Program
|
|
3 netnews Network News delivery
|
|
4 fax Sam Leffler's FlexFAX software
|
|
|
|
|
|
MACROS
|
|
|
|
A
|
|
B Bitnet Relay
|
|
C
|
|
D The local domain -- usually not needed
|
|
E
|
|
F FAX Relay
|
|
G
|
|
H mail Hub (for mail clusters)
|
|
I
|
|
J
|
|
K
|
|
L
|
|
M Masquerade (who I claim to be)
|
|
N
|
|
O
|
|
P
|
|
Q
|
|
R Relay (for unqualified names)
|
|
S Smart Host
|
|
T
|
|
U my UUCP name (if I have a UUCP connection)
|
|
V UUCP Relay (class V hosts)
|
|
W UUCP Relay (class W hosts)
|
|
X UUCP Relay (class X hosts)
|
|
Y UUCP Relay (all other hosts)
|
|
Z Version number
|
|
|
|
|
|
CLASSES
|
|
|
|
A
|
|
B
|
|
C
|
|
D
|
|
E addresses that should not seem to come from $M
|
|
F hosts we forward for
|
|
G
|
|
H
|
|
I
|
|
J
|
|
K
|
|
L addresses that should not be forwarded to $R
|
|
M
|
|
N
|
|
O operators that indicate network operations (cannot be in local names)
|
|
P top level pseudo-domains: BITNET, FAX, UUCP, etc.
|
|
Q
|
|
R
|
|
S
|
|
T
|
|
U locally connected UUCP hosts
|
|
V UUCP hosts connected to relay $V
|
|
W UUCP hosts connected to relay $W
|
|
X UUCP hosts connected to relay $X
|
|
Y locally connected smart UUCP hosts
|
|
Z locally connected domain-ized UUCP hosts
|
|
. the class containing only a dot
|
|
|
|
|
|
M4 DIVERSIONS
|
|
|
|
1 Local host detection and resolution
|
|
2 Local Ruleset 3 additions
|
|
3 Local Ruleset 0 additions
|
|
4 UUCP Ruleset 0 additions
|
|
5 locally interpreted names (overrides $R)
|
|
6 local configuration (at top of file)
|
|
7 mailer definitions
|
|
8
|
|
9 special local rulesets (1 and 2)
|