UNIX System Administration Handbook - Evi Nemeth [354]
There are mismatched configurations in which your host might be convinced to relay weird addresses that misuse the UUCP addressing syntax. Just to be sure, if you have no UUCP (or BITNET or DECnet) connectivity, you can use
FEATURE('nouucp', 'reject')
undefine('UUCP_RELAY')
undefine('BITNET_RELAY')
undefine('DECNET_RELAY')
to forestall this possibility. A good spot for these lines is in your DOMAIN file.
Another relay that is often defined in the DOMAIN file is the LUSER_RELAY for local users who do not exist. A site with sendmail misconfigured sometimes leaks unqualified local user names (usually on the Cc line) out to the Internet. Someone trying to reply to the mail will be addressing their reply to an apparent local user who does not exist. This relay is often called the “loser relay” and is directed to the error mailer with an entry such as
define('LUSER_RELAY', 'error:No such user')
The access database
sendmail includes support for an access database that you can use to build a mail-specific firewall for your site. It checks mail coming in from the outside world and rejects it if it comes from specific users or domains. You can also use the access database to specify which domains a machine is willing to relay for.
The access database is enabled with the line
FEATURE('access_db', 'type filename')
If type and filename are not specified, the database defaults to type hash built from the file /etc/mail/access. As always, create the database with makemap:
# makemap hash /etc/mail/access < /etc/mail/access
The key field of the access file can contain email addresses, user names, domain names, or network numbers. For example:
cyberspammer.com 550 Spam not accepted
okguy@cyberspammer.com OK
badguy@aol.com REJECT
sendmail.org RELAY
128.32 RELAY
170.201.180.16 REJECT
hotlivesex@ 550 Spam not accepted
friend@ 550 You are not my friend!
The value part must contain one of the items shown in Table 19.14.
Table 19.14 Things that can appear in the value field of the access database
a. For example, 550 is the single-error code.
This database file would allow messages from okguy at cyberspammer.com but would reject all other mail from cyberspammer.com with the indicated error message. Mail from either sendmail.org or 128.32.0.0/16 (UC Berkeley’s network) would be relayed. Mail from badguy at AOL and from hotlivesex or friend at any domain would also be rejected.
IPv6 addresses in their colon-separated form can be used on the left-hand side as well. The @ after the usernames hotlivesex and friend is required to differentiate them from domain names.
550 is an RFC821 error code. The RFC1893 error codes (or “delivery status notification messages,” as they are called) are more extensive. First digit 4 indicates a temporary error; 5 means a permanent error. We’ve listed a few in Table 19.15.
Table 19.15 RFC1893 delivery status codes
For even finer control, the key field (left side) can contain the tags Connect, To, and From to control the way in which the filter is applied. Connect refers to connection information such as client address or client name. To and From refer to the envelope addresses, not the headers. These tags provide finer control over relaying and can be used to override other restrictions.
If one of these tags is used, the lookup is tried first with the tag info and then without, to maintain backward compatibility with older access databases.
Here are some examples:
From:spammer@some.domain REJECT
To:friend.domain RELAY
Connect:friend.domain OK
Mail from spammer@some.domain would be blocked, but you could still send mail to that address, even if it was blacklisted. Mail will be relayed to friend.domain, but not from it (assuming that relaying has been disabled elsewhere). Connections to friend.domain would be allowed