UNIX System Administration Handbook - Evi Nemeth [353]
So, promiscuous relaying is bad. At the same time, some types of relaying are useful and legitimate. How can you tell which messages to relay and which to reject? Relaying is actually necessary in only two situations:
• When the transport agent acts as a gateway for hosts that are not reachable any other way; for example, UUCP hosts, hosts that are not always turned on (PPP hosts, Windows PCs), and virtual hosts. In this situation, all the recipients for which you want to relay lie within the same domain.
• When the transport agent is the outgoing mail server for other, not-so-smart hosts. In this case, all the senders’ hostnames or IP address are local.
Any other situation that appears to require relaying is probably just an indication of bad design. You can obviate the first use of relaying (above) by eliminating UUCP (it’s almost dead anyway) and designating a centralized server to receive mail (with POP or IMAP used for client access). The second case should always be allowed, but only for your own hosts. It’s better to check IP addresses than hostnames because the hostnames are easy to fake.
Although sendmail comes with relaying turned off by default, several features have been added to turn it back on, either fully or in a limited and controlled way. These features are listed below for completeness, but our recommendation is that you be careful about opening things up too much. Most sites do not need any of the really dangerous features in the second list. The access_db feature, covered in the next section, is the safest way to allow limited relaying.
• FEATURE('relay_entire_domain') – allows relaying for just your domain
• RELAY_DOMAIN('domain, ...') – adds more domains to be relayed
• RELAY_DOMAIN_FILE('filename') – same, but takes domain list from a file
• FEATURE('relay_hosts_only') – affects RELAY_DOMAIN, accessdb
You will need to make an exception if you use the SMART_HOST or MAIL_HUB designations to route mail through a particular mail server machine. That server will have to be set up to relay mail from local hosts. It should be configured with:
FEATURE('relay_entire_domain')
Sites that also do virtual hosting may need RELAY_DOMAIN as well, to allow relaying for their virtual names, although
FEATURE('use_cw_file')
effectively opens relays for those domains or hosts.
There are a few other possibilities, but they are fraught with problems:
• FEATURE('promiscuous_relay') – allows all relaying; don’t use
• FEATURE('relay_based_on_MX') – relays for anyone that MXes to you
• FEATURE('loose_relay_check') – allows “percent hack” addressing
• FEATURE('relay_local_from') – relays based on the From address
The promiscuous_relay feature allows relaying from any site to any other site. Using it is a one-way ticket to Paul Vixie’s black hole lists. Do not use this feature.
The relay_based_on_MX feature is bad because you do not control what sites are allowed to point their MX records at you. Typically, the only hosts that have an MX record pointing to your mail server are your own, but nothing prevents other sites from changing their MX records to point to you. Spammers do not usually have the ability to change MX records, but shady sites certainly could.
The loose_relay_check feature allows the “% hack” form of addressing that spammers love to use.
The relay_local_from feature trusts the sender address on the envelope of the message and relays messages that appear to be from a local address. Of course, both the envelope and the headers of mail messages are trivial to forge, and spammers are forging experts.
If you consider turning on relaying in some form, consult the sendmail