+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.
+
projects / unix-history / blobdiff