UNIX System Administration Handbook - Evi Nemeth [346]
define('MAIL_HUB', 'smtp:mailhub.cs.colorado.edu')
The SMART_HOST designation causes a host to deliver local mail but to punt external mail to SMART_HOST. This feature is useful for machines behind a firewall that cannot use DNS directly. Its syntax parallels that of MAIL_HUB; the default delivery agent is again relay. For example:
define('SMART_HOST', 'smtp:mailhub.cs.colorado.edu')
In these examples, the same machine acts as the server for both incoming and outgoing mail. A larger site might split these into separate machines.
Masquerading and routing
With all these features and macros ready and waiting to massage your email addresses, we thought it might be nice to try to compare the various mechanisms in terms of whether they change the headers, the envelope, or the delivery of a message, whether they apply to incoming or outgoing messages, sender or recipient addresses, etc. If the page were double or triple width, we might have succeeded in really illustrating the differences among the various constructs.
Instead, we give you just a hint; you will have to look up the details in the sendmail documentation to get all the nuances of the different variations.
Entries in Table 19.12 that are all capital letters are m4 macros; lowercase entries are the names of features that are invoked with the FEATURE macro. Indented items depend on the items above; for example, a feature that modifies the MASQUERADE_AS behavior does nothing unless MASQUERADE_AS has been turned on. In the table, the feature would be indented to indicate this dependency. Masquerading affects the header addresses on outgoing mail and whether a message can be replied to; routing affects the actual delivery of the mail.
Table 19.12 Comparison of masquerading and routing features
a. S = sender, R = recipient, D = delivery, H = header, E = envelope, M = mailer, A = address
b. Once envelope rewriting has been enabled with the masquerade_envelope feature, all other masquerading constructs rewrite not only the header but the envelope as well.
The nullclient feature
This feature is used for a host that should never receive mail directly and that sends all its outgoing mail to a central server. The .mc file for such a host has only two lines.
OSTYPE('ostype')
FEATURE('nullclient', 'mail_server')
The nullclient feature overrides many other features. All mail, without exception, is delivered to mail_server for processing.23
Note that the server must allow the client to relay through it if users regularly originate mail on the client and don’t use a separate server for outgoing mail. Recent versions of sendmail have relaying turned off by default. See the spam section (page 595) for details on how to control relaying. A nullclient configuration masquerades as mail_server, so you might want to include an EXPOSED_USER clause for root.
The client that uses the nullclient feature must have an associated MX record that points to the server. It must also be included in the server’s cw file, which is usually /etc/mail/local-host-names. These settings let the server accept mail for the client.
A host with a nullclient configuration should not accept incoming mail. If it did, it would just forward the mail to the server anyway. Start sendmail without the -bd flag so that it doesn’t listen for SMTP connections on port 25. Leave the -q30m flag on the command line so that if mail_server goes down, the client can queue outgoing mail and try to send it to mail_server later.
nullclient is appropriate for leaf nodes at sites that have a central mail machine. At larger sites, consider the mail load on the hub machine. You may want to separate the incoming and outgoing servers or adopt a hierarchical approach.
The local_lmtp and smrsh features
/bin/mail is getting pretty tired as UNIX’s local mailer. If the local_lmtp