+MAIL_HUB set as above (no local aliasing) (aliasing done)
+
+If you do not have FEATURE(stickyhost) set, then LOCAL_RELAY and
+MAIL_HUB act identically, with MAIL_HUB taking precedence.
+
+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,
+DECNET_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.
+
+In some cases you may want to temporarily turn off MX records,
+particularly on gateways. For example, you may want to MX
+everything in a domain to one machine that then forwards it
+directly. To do this, you might use the DNS configuration:
+
+ *.domain. IN MX 0 relay.machine
+
+and on relay.machine use the mailertable:
+
+ .domain smtp:[gateway.domain]
+
+The [square brackets] turn off MX records for this host only.
+If you didn't do this, the mailertable would use the MX record
+again, which would give you an MX loop.
+
+
++--------------------------------+
+| 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 not use FEATURE(stickyhost) -- otherwise,
+e-mail sent to Full.Name@local.host.name will be rejected.
+
+To build the internal form of the user database, use:
+
+ makemap btree /usr/data/base.db < /usr/data/base.txt
+
+As a general rule, I am adamantly opposed to using full names as
+e-mail addresses, since they are not in any sense unique. For example,
+the Unix software-development community has two Andy Tannenbaums,
+at least two well-known Peter Deutsches, and at one time Bell Labs
+had two Stephen R. Bournes with offices along the same hallway.
+Which one will be forced to suffer the indignity of being
+Stephen_R_Bourne_2? The less famous of the two, or the one that
+was hired later?
+
+Finger should handle full names (and be fuzzy). Mail should use
+handles, and not be fuzzy. [Not that I expect anyone to pay any
+attention to my opinions.]
+
+
++--------------------------------+
+| MISCELLANEOUS SPECIAL FEATURES |
++--------------------------------+
+
+Plussed users
+ Sometimes it is convenient to merge configuration on a
+ centralized mail machine, for example, to forward all
+ root mail to a mail server. In this case it might be
+ useful to be able to treat the root addresses as a class
+ of addresses with subtle differences. You can do this
+ using plussed users. For example, a client might include
+ the alias:
+
+ root: root+client1@server
+
+ On the server, this will match an alias for "root+client1".
+ If that is not found, the alias "root+*" will be tried,
+ then "root".
+
+
++----------------+
+| SECURITY NOTES |
++----------------+
+
+A lot of sendmail security comes down to you. Sendmail 8 is much
+more careful about checking for security problems than previous
+versions, but there are some things that you still need to watch
+for. In particular:
+
+* Make sure the aliases file isn't writable except by trusted
+ system personnel. This includes both the text and database
+ version.
+
+* Make sure that other files that sendmail reads, such as the
+ mailertable, is only writable by trusted system personnel.
+
+* The queue directory should not be world writable PARTICULARLY
+ if your system allows "file giveaways" (that is, if a non-root
+ user can chown any file they own to any other user).
+
+* If your system allows file giveaways, DO NOT create a publically
+ writable directory for forward files. This will allow anyone
+ to steal anyone else's e-mail. Instead, create a script that
+ copies the .forward file from users' home directories once a
+ night (if you want the non-NFS-mounted forward directory).
+
+* If your system allows file giveaways, you'll find that
+ sendmail is much less trusting of :include: files -- in
+ particular, you'll have to have /SENDMAIL/ANY/SHELL/ in
+ /etc/shells before they will be trusted (that is, before
+ files and programs listed in them will be honored).
+
+In general, file giveaways are a mistake -- if you can turn them
+off I recommend you do so.
+
+
++------------------+
+| 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.
+