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 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	DEPRECATED. 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 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.

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.