Properly Configure Mail Relaying

In addition to discouraging local users from generating spam, you need to discourage remote users from using your server as a tool for distributing spam. Nobody likes spammers, and the spammers know it. They do their best to hide the true source of the spam by relaying their junk mail through other people's servers. If your mail server allows relaying, spammers can make use of it.

To discourage spam, the default configuration of sendmail properly handles local mail, but does not relay messages for any outside sources. This is just the opposite of versions of sendmail before release 8.9, which relayed all mail by default. If your system runs an older version of sendmail, you should upgrade to get the full range of anti-spam tools.

Blocking all relaying works in most cases because most systems that run sendmail are not mail servers—they're desktop Linux and Unix systems dedicated to a single user. Because the user's mail originates on the system that is running sendmail, the mail is handled as local mail, and relaying is not required.

Blocking all relaying doesn't work if the system is a mail server. Most of the mail that a mail server delivers originates on its clients—these might be Microsoft Windows PCs that don't run their own sendmail program. Blocking relaying at the server causes the client to get an error when trying to deliver mail.

To create a mail server, you must allow some level of relaying. Select the correct feature from the following list of sendmail features to relax the relay restrictions just enough to get the job done:

FEATURE(promiscuous_relay') Tells sendmail to relay mail from all sources.

FEATURE(relay_entire_domain') Tells sendmail to relay mail from any local domain; that is, any domain defined in class M. (Don't remember the sendmail classes? Refer to Chapter 5.)

FEATURE(relay_based_on_MX') Tells sendmail to relay mail for any host for which the local host is the MX server.

FEATURE(relay_local_from') Tells sendmail to relay mail that contains the local domain in the MAIL FROM: header.

FEATURE(accept_unresolvable_domains') Tells sendmail to accept mail from a host, even if it cannot be found in DNS or the host table. Normally, mail from hosts that do not exist in the domain name system is rejected.

To turn a system that blocks all relaying into a mail server, create a configuration file that allows the appropriate level of relaying. For example, you could create a variation on the foobirds.m4 DOMAIN file used in Chapter 5. Listing 11.3 shows such a variation.

Listing 11.3: Permitting Mail Relaying divert(0)

VERSIONID(~foobirds.m4 03/16/2002')

define(~confFORWARD_PATH', ~$z/.forward.$w+$h:$z/.forward+$h:$z/ A.forward.$w:$z/.forward')dnl define(~confMAX_HEADERS_LENGTH', ~32768')dnl

FEATURE(~relay_entire_domain')

FEATURE(~redirect')dnl

FEATURE(~use_cw_file')dnl

EXPOSED_USER(~root')

MASQUERADE_AS(foobirds.org)

FEATURE(masquerade_envelope)

FEATURE(genericstable)

This file contains all of the same features described in Chapter 5, plus the relay_entire_domain feature. This additional feature permits you to use the M class as a way to identify those hosts whose mail the server should relay.

Warning Be careful that you don't weaken the configuration so much that you become a spam source! All of the features listed above weaken the barrier to mail relaying, but some are worse than others. promiscuous_relay should not be used because it turns the system into a potential spam relay. Avoid the relay_local_from feature because it is very easy for spammers to write anything they want in the MAIL FROM: header, including your local domain name. Additionally, accept_unresolvable_domains should not be used unless it is absolutely required. It is intended for when sendmail really can't resolve domain names, such as on a laptop Linux system that does not always have access to a DNS server.

Was this article helpful?

0 0

Post a comment