7.1 The Local_check_ Rule Sets
The rapid spread of the Internet has led to an increase of mail
abuses. Prior to V8.8 sendmail, detecting and
rejecting abusive email required that you write C-language code for
use in the checkcompat/( ) routine (see Appendix D). Beginning with V8.8
sendmail, important and useful checking and
rejecting can be done from within four pairs of complementary rule
sets. They are presented in the order that
sendmail calls them:
- Local_check_relay and check_relay
-
Validate the host initiating the SMTP connection.
- Local_check_mail and check_mail
-
Validate the envelope-sender address given to the SMTP MAIL command.
- Local_check_rcpt and check_rcpt
-
Validate the envelope-recipient address given to the SMTP RCPT
command.
- check_compat
-
Compare or contrast each pair of envelope-sender and
envelope-recipient addresses before delivery, and validate them based
on the result.
These routines are all handled in the same manner. If the rule set
returns anything other than a #error or a
#discard delivery agent, the message is accepted.
Otherwise, the #error delivery agent causes the
message to be rejected or deferred (error),
whereas the #discard delivery agent causes the
message to be accepted, then discarded (discard).
7.1.1 Local_check_relay and check_relay
V8.8
sendmail supports two mechanisms for screening
incoming SMTP connections. One is the libwrap.a
mechanism, the other is this check_relay rule set.
V8.9 sendmail adds a third mechanism, the
access database (Section 7.5).
The Local_check_relay rule set provides a hook
into the check_relay rule set, which is used to
screen incoming network connections and accept or reject them based
on the hostname, domain, or IP number. It is called just before the
libwrap.a code and can be used even if that code
was omitted from your release of sendmail. The
check_relay rule set is not called if
sendmail was run with the -bs
command-line switch (-bs).
The check_relay rule set is called with a
workspace that looks like this:
host $| IPnumber
The hostname and IP number are separated by the $|
operator. The host is the fully qualified
canonical name of the connecting host. The
IPnumber is the IP number of that host in
dotted-quad form without surrounding square brackets, or the IPv6
number prefixed with a literal IPv6:.
By default, the check_relay rule set allows all
connections. This behavior can be overridden or enforced in the
access database by prefixing leftmost keys with
a literal Connect: (Section 7.5.3):
Connect:bad.host REJECT
Here, for example, any connection from the host
bad.host is rejected.
The default behavior of the check_relay rule set
can also be overridden by the various DNS blacklist features (see
Section 7.2).
In the event you need to add checks to this
check_relay rule set, you can do so by adding a
Local_check_relay rule set. Declaring this latter
rule set gives you a hook into the start of
check_relay, which means your rules are applied
before the default rules.
One way to use Local_check_relay might be to list
offensive sites in a database and reject any connections from those
sites. Consider a database that contains hostnames or addresses
as its keys and descriptions of each host's offense
as its values:
hostA.edu Spamming site
hostB.com Mail Bombing site
123.45.6 Offensive domain
IPv6:2002:c0a8:51d2::23f4 Offending host
Notice that the keys can be hostnames, or IPv4 or IPv6 addresses.
Such a database might be declared in the configuration file like
this:
LOCAL_CONFIG
Kbadhosts dbm -a<> /etc/mail/badhosts
Now, each time a site connects to your running daemon, the following
rule set will be called:
SLocal_check_relay
R $* $| $* $: $(badhosts $1 $) $| $2 look up hostname
R $*<> $| $* $#error $@ 5.1.3 $: 550 Sorry, $1 denied
R $* $| $* $: $2 select the IP number
R $-.$-.$-.$- $: $(badhosts $1.$2.$3.$4 $) look up host address
R IPv6 : $+ $: $(badhosts IPv6:$1 $) look up host or network
address
R $*<> $#error $@ 5.1.3 $: 550 Sorry, $1 denied
R $* $@ ok otherwise OK
The first rule looks up the host part in the database. If it is
found, the value (reason for rejection) is returned and the two
characters < > are
appended. The second rule looks for anything to the left of the
$| that ends in <
> and, if anything is found, issues the
error:
550 5.1.3 Sorry, reason for rejectdenied
Rejected connections are handled in the same way as connections
rejected by the access database (Section 7.5).
The rest of the rules do the same thing, but also check for the IP
number.
If the Local_check_relay rule set returns a
#error or #discard delivery
agent, the connection is rejected. If it returns a
$#OK, the connection is
accepted and subsequent check_relay rule set rules
are skipped:
SLocal_check_relay
R $* $# OK skip check_relay rule set rules
But if it returns a $@OK, further
check_relay rule set rules are allowed which might
themselves reject the connection:
SLocal_check_relay
R $* $@ OK allow check_relay rule set rules
Note that the rules presented here are not nearly as complex or
sophisticated as your site will likely need. They do not, for
example, reject on the basis of the domain part of the hostname, nor
do they reject on the basis of the individual host IP addresses.
Note that the rules in the Local_check_relay and
check_relay rule sets cannot be tested in
rule-testing mode because that mode wrongly interprets the expression
$| (when you enter it at the > prompt) as two
separate text characters instead of as a single operator. To test an
address that contains an embedded $| operator, we
suggest that you create a translation rule set something like this:
LOCAL_RULESETS
STranslate
R $* $$| $* $: $1 $| $2 fake for -bt mode
This rule set changes a literal $ and
| into a $| operator so that
you can test rule sets such as Local_check_relay
from rule-testing mode:
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> Translate,Local_check_relay bogus.host.domain $| 123.45.67.89
Here, the comma-separated list of rule sets begins with
Translate, which changes the two-character text
expression "$|"
into the single operator $|. The result, an
address expression that is suitable for the
Local_check_relay rule set, can then be
successfully tested.
7.1.2 Local_check_mail and check_mail
The
Local_check_mail rule set provides a hook into the
check_mail rule set, which is used to validate the
envelope-sender address given in the MAIL command of the SMTP dialog:
MAIL From:<sender@host.domain>
The check_mail rule set is called immediately
after the MAIL command is read. The workspace passed to
check_mail is the address following the colon in
the MAIL command. That envelope-sender address might or might not be
surrounded by angle braces.
If sendmail's delivery mode is
anything other than deferred (-bd), the check_mail rule set
performs the following default actions:
Calls the tls_client rule set (Section 10.10.8.2) to perform TLS verification, if needed.
Accepts all envelope-sender addresses of the form
< >.
Makes certain that the host and domain part of the envelope-sender
address exists.
If the access database (Section 7.5) is used, it looks up the envelope-sender in
that database and rejects, accepts, or defers the message based on
the returned lookup value.
The Local_check_mail rule set provides a hook into
check_mail before the preceding checks are made,
and provides a place for you to insert your own rules.
To illustrate one use for the Local_check_mail
rule set, consider the need to accept all mail from an internal
domain, even when many of the hosts in that domain cannot be looked
up with DNS. One method might look
like this:
LOCAL_RULESETS
SLocal_check_mail
R $* $: $>canonify $1 focus on the host
R $* <@ $+. > $* $1 <@ $2> $3 strip trailing dots
R $* <@ $+ > $* $: $2 isolate the host
R $* . $+ . $+ $2 . $3 strip subdomains
R internal.org $# OK
Here, we force the rule set named canonify to
preprocess the address so that any RFC2822 comments will be thrown
away and the host part of the address will be focused. We then strip any trailing dots from the
hostname to prevent a trailing dot from wrongly affecting our
validation. In the third line, we throw away everything but the
hostname. In the fourth line, we throw away all but the rightmost two
components of the hostname to eliminate the host part and any
subdomain prefixes. What remains is the domain name. We then compare
that domain name to the hostname internal.org.
If they match, we accept the sender. If they don't
match, the default rules in the check_mail rule
set continue to process the address.
Note that if this Local_check_mail rule set
returns $#OK, all subsequent
check_mail rule set checks of the envelope-sender
will be suppressed:
SLocal_check_mail
R $* $# OK skip check_mail rule set checks
But if it returns $@OK, further envelope-sender
check_mail rule set checks are processed (such as
looking up the user and host parts in the access
database, or trying to resolve the host part):
SLocal_check_mail
R $* $@ OK allow check_mail rule set checks
After this rule set is installed (and the
sendmail daemon had been restarted), all mail
from internal.org will be accepted during the
SMTP dialog even if the hostname does not exist.
Other uses for the Local_check_mail rule set might
include limiting certain senders to only a few outbound messages per
day, by using an external database to record attempts; rejecting the
user part of sender addresses for special reasons, such as being all
numeric; and rejecting mail from a specific list of users at a given
site.
If you need to base a decision to reject mail on both the sender and
the recipient, you might be able to use the
check_compat rule set described next, or design
your own rules for this rule set using $&f
($f).
7.1.3 Local_check_rcpt and check_rcpt
The
Local_check_rcpt rule set provides a hook into the
check_rcpt rule set, which is used to validate the
recipient-sender address given in the RCPT command in the SMTP
dialog:
RCPT To:<recipient@host.domain>
The check_rcpt rule set is called immediately
after the RCPT command is read. The workspace that is passed to
check_rcpt is the address following the colon. The
envelope-recipient address might or might not be surrounded by angle
brackets and might or might not have other RFC2822 comments
associated with it.
The check_rcpt rule set has default rules that do
the following:
Reject empty envelope-recipient addresses, such as
< >, and those which have
nothing following the RCPT TO:.
Ensure that the envelope-recipient address is either local, or one
that is allowed to be relayed.
If the access database (Section 7.5) is used, looks up the
envelope-recipient's host in that database and
rejects, accepts, or defers the message based on the returned lookup
value. If the blacklist_recipients feature (Section 7.5.5) is declared, it also looks up the
envelope-recipient in that database.
The Local_check_rcpt gives you a hook into the
check_rcpt rule set before any of the default
rules are called. To illustrate one use for the
Local_check_rcpt rule set, consider the need to
reject all incoming mail destined for the recipient named
fax. One method might look like this:
LOCAL_RULESETS
SLocal_check_rcpt
R $* $: $>canonify $1 focus on host
R fax <@ $=w . > $* $#error $@ 5.1.3 $: "cannot send mail to fax"
Here, the first rule calls the rule set named
canonify to focus on the host part of the address
and normalize it. The second rule rejects anything to
fax in any of our local domains (the
$=w). A recipient address of
fax at any other domain will pass through these
rules and be accepted:
RCPT To: <fax@ourhost>
553 5.1.3 <fax@ourhost>... cannot send mail to fax
Other uses for this Local_check_rcpt rule set
(documented elsewhere in this book) include the following:
Create a special bounce-handling machine that accepts all bounced
mail, then logs and discards it (Section 6.3.2)
Create a special performance-testing blackhole machine that accepts
all outside mail and silently discards it (Section 6.3.3)
Note that if this Local_check_rcpt rule set
returns $#OK, all subsequent
checks with the check_rcpt rule set will be
suppressed:
SLocal_check_rcpt
R $* $# OK skip check_rcpt rule set checks
But if it returns $@OK, further checks with the
check_rcpt rule set are processed (such as looking
up the user and host parts in the access
database, and such as validating that the host part is local):
SLocal_check_rcpt
R $* $@ OK allow check_rcpt rule set checks
If you need to base a decision to reject mail on both the sender and
the recipient, you can either use the check_compat
rule set described next, or design you own rules for this rule set
using $&f ($f).
Note that check_rcpt rule set rules apply only to
mail that arrives via SMTP. If your site submits mail using SMTP you
might find locally originating mail being wrongly rejected. If yours
is such a site, you can add the following rules to
Local_check_rcpt, which should fix the problem:
SLocal_check_rcpt
R $* $: $&{client_addr}
R 127.0.0.1 $@ OK
7.1.4 The check_compat Rule Set
Not all situations can be resolved by
simply checking the RCPT TO: or MAIL FROM: address. Sometimes you
will need to make judgments based on pairs of addresses, or non-SMTP
addresses or other information. To handle this situation, V8.8
introduced the check_compat rule set. Unlike
check_mail and check_rcpt,
check_compat is called for all deliveries, not
just SMTP transactions. It is called after an address has undergone
aliases translation, just after the check for
too large a size (as defined by M=; see M=), and just before the
checkcompat( ) routine (see Appendix D).
Note that although with V8.12 and above you can still write you own
check_compat rule set, doing so has been made
unnecessary by the compat_check feature (Section 7.5.7). But also note that, as of V8.12, you cannot
both declare the check_compat feature and use this
check_compat rule set.
The check_compat rule set is called with a
workspace that looks like this:
sender $| recipient
The sender and recipient addresses are separated by the
$| operator. Each has undergone aliasing and
~/.forward file processing.
One use for the check_compat rule set is to
prevent a certain user (here operator/) from
sending mail offsite:
LOCAL_RULESETS
SGet_domain
R $* $: $>canonify $1 focus on host
R $* <@ $+. > $* $1 <@ $2> $3 strip trailing dots
R $* <@ $+ > $* $: $2 isolate the host
R $* . $+ . $+ $2 . $3 strip host and subdomains
SGet_user
R $* $: $>3 $1 focus on host
R $* <@ $+ > $* $@ $1 discard host
Scheck_compat
R $* $| $* $: $1 $| $>Get_domain $2 fetch recipient domain
R $* $| $=w $@ ok local is OK
R $* $| $=m $@ ok local is OK
R $* $| $* $: $>Get_user $1 fetch sender user
R operator $#error $@ 5.1.3 $: "operator might not mail off site"
First, we set up two subroutines patterned after the code in the
previous two sections. The first reduces its workspace to just the
domain part of an address. The second reduces an address to just the
user part. These two subroutines are called by
check_compat.
The first rule in check_compat uses the
Get_domain subroutine to convert the address on
the right of the $| (the recipient) into just a
domain name. That right side is compared to the local hostnames
($=w and $=m). If the domain is
a local one, delivery is allowed (we return anything but a
#error or a $#discard).
But if the domain is an offsite one, we call
Get_user to fetch the user part of the address to
the left of the $| (the sender). If that user is
operator, delivery is denied and the message
bounces.
Other uses for the check_compat rule set might
include the following:
Logging a record of when a DSN NOTIFY request of success is requested
(${dsn_notify})
Creating a class of users who, possibly for security reasons, might
send mail inside the organization but not outside it
Screening a particular recipient to prevent that user from receiving
objectionable mail from a specific source
Note that such rule sets cannot be tested in rule-testing mode
because that mode wrongly interprets the expression
$| (when you enter it at the > prompt) as two
separate text characters instead of a single one. See Section 7.1.1 for one suggested solution to this problem.
|