Immediately after an inbound host connects
to the listening sendmail daemon, and before the
daemon issues its initial greeting message,
sendmail performs the following steps:
It does a PTR lookup of the connecting host's
address to find the hostname.
It clears its buffers and counters, and sets all its defaults, to
ready itself for the upcoming SMTP dialog.
It presets key macros to their current values, such
${load_avg}.
It calls the srv_features rule set to tune
features so that they match the requirements of the connecting host.
The srv_features rule set is declared like this:
LOCAL_SRV_FEATURES
... your rules here
The srv_features rule set must return a
$# followed by one or more of the characters
defined in Table 19-3. When more than one character
is returned, each must be separated from the next by a space. Each
character turns a feature on or off. If the character is lowercase,
it turns the feature on. Uppercase turns the feature off. One
character, the t, is special because it causes
sendmail to temporarily fail the connection.
Table 19-3. Characters that set/clear server features
a
|
A
|
Offer the AUTH SMTP extension
|
b
|
B
|
Offer use of the SMTP VERB command
|
d
|
D
|
Offer the DSN SMTP extension
|
e
|
E
|
Offer the ETRN SMTP extension
|
l
|
L
|
Require the client to authenticate with AUTH
|
p
|
P
|
Offer the PIPELINING SMTP extension
|
s
|
S
|
Offer the STARTTLS SMTP extension
|
v
|
V
|
Verify a client certificate
|
x
|
X
|
Offer use of the SMTP EXPN command
|
If anything other than the characters shown in the table is returned,
that bad character is silently ignored.
The default setting for any character depends on the use of the
character. For example, if noetrn is specified for
the PrivacyOptions option (See this section), the default is the character
E; otherwise, the default is the character
e. Whereas if Modify=A is
specified for the DaemonPortOptions option (See this section) for the daemon's listening
port, the default is A; otherwise, it is
a. In general, B,
D, E, and X
take their defaults from the various
PrivacyOptions option settings, whereas
L and R take their defaults
from the various Modify= settings. But
P defaults to p if
sendmail was compiled with the PIPELINING
build-time macro defined; otherwise, it defaults to
P, which cannot be overridden.
The srv_feature rule set is passed the connecting
client's hostname in its workspace. Instead, you
must base your policy decisions on the various
sendmail macro values available. For example,
the following rule allows EXPN if the connecting host is the local
machine, and denies it otherwise:
LOCAL_SRV_FEATURES
R $* $: $&{client_addr}
R 127.0.0.1 $# e
R $* $# E
A special character, the t, is used to force a
temporary failure:
LOCAL_SRV_FEATURES
R $* $: $&{client_addr}
R $- . $- . $- . $- $: $1.$2.$3
R 123.45.67 $# temp
Here, the connecting host's address is found in the
$&{client_addr} macro. The second rule strips
off the host part of a class-C address. The last rule then checks to
see if that network address is that of the new network, the one that
should have no valid hosts on it yet. If it is, the connection is
deferred by returning $#t. Note that when the
returned character is t, other letters can follow
it, and they will be ignored.
In addition to your rules, there are default rules present that can
make your job easier. The default rules perform
access database lookups for entries in that
database that begin with the special prefix:
Srv_Features:
The connecting host's name, as taken from the
$&{client_name} macro, is looked up first. The
connecting host's address, as taken from the
$&{client_addr} macro, is looked up second. If
neither of those is found, the bare prefix is looked up. The earlier
example, then, if implemented in the access
database, would look like this:
Srv_Features:127.0.0.1 e
Srv_Features: E
The character letters that are returned as values by the
access database are the same as those returned
by your own rules, as shown in the table. Multiple letters can be
returned, where each must be separated from the others by a space:
Srv_Features:127.0.0.1 e b
The srv_feature access
database decisions can be combined with access
database decisions made by other rule sets to create more complex
decisions. For example:
Try_TLS:broken-host.domain NO
Srv_Features:your.domain v
Srv_Features: V
Here, we use the Try_TLS: prefix (Section 10.10.8.4) to prevent sending the STARTTLS SMTP command
to the host broken-host.domain. The second line
(the first Srv_Features: prefix) tells
sendmail (the v) to request a
client certificate during the TLS handshake only for hosts in
your.domain. The last line tells
sendmail to not request a client certificate
from any other hosts.
Note that you can use the access database (Section 7.5) only if you enabled that database with the
access_db feature in your mc
configuration file.