DOMAINS
You will probably want to collect domain-dependent defines into one
file, referenced by the DOMAIN macro. For example, the Berkeley
domain file includes definitions for several internal distinguished
hosts:
| Macro | Description |
|---|
| UUCP_RELAY | The host that will accept UUCP-addressed email.
If not defined, all UUCP sites must be directly
connected. |
| BITNET_RELAY | The host that will accept BITNET-addressed email.
If not defined, the .BITNET pseudo-domain won't work. |
| DECNET_RELAY | The host that will accept DECNET-addressed email.
If not defined, the .DECNET pseudo-domain and addresses
of the form node::user will not work. |
| FAX_RELAY | The host that will accept mail to the .FAX pseudo-domain.
The "fax" mailer overrides this value. |
| LOCAL_RELAY | The site that will handle unqualified names -- that
is, names without an @domain extension.
Normally MAIL_HUB is preferred for this function.
LOCAL_RELAY is mostly useful in conjunction with
FEATURE(`stickyhost') -- see the discussion of
stickyhost below. 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 only with some user agents. |
| LUSER_RELAY | The site that will handle lusers -- that is, apparently
local names that aren't local accounts or aliases. To
specify a local user instead of a site, set this to
``local:username''. |
Any of these can be either ``mailer:hostname'' (in which case the
mailer is the internal mailer name, such as ``uucp-new'' 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.
|