| One of the most recent additions to Sendmail is protection against spam (unsolicited email) through anti-relaying rules. These rules have been available for a long time, but only recentlyas of Sendmail version 8.9has the default configuration been to disallow relaying of messages from one server to another. For a legitimate dial-up or remote user to use your SMTP server to send a message to another remote recipient, your server has to act as a relay, forwarding the message on to the recipient even if the message didn't originate from and wasn't addressed to anyone on its machine. Functionally, as illustrated in Figure 25.2, this is exactly how a spammer would send an unsolicited message to the same recipient through the same SMTP server: The spammer must relay. Figure 25.2. Relaying. Spammers and legitimate users, if they're not local to S1, must use S1 as a relay to forward their messages to S2. 
How Relaying Works Relaying is usually allowed using what's known as the "MX record," a line in the SMTP server's network DNS database (either served from the same machine as the SMTP server or another server in the same network), which tells all the machines within that network that your SMTP server (S1) is a legitimate mail exchanger for them. Sendmail, in its default configuration on FreeBSD, will accept mail from senders whose MX record points to S1, defining it as the MTA for the network. This prevents people from outside the network from using S1 as a relay; if they try, they'll get their messages bounced back with a Relaying denied error. Note You can find out what the registered MX host is for a domain by using the host command: # host somecompany.com somecompany.com has address 164.199.3.78 somecompany.com mail is handled (pri=30) by mail-1.somecompany.com
You can then connect directly to this host on port 25 to perform raw SMTP transactions (for testing purposes, for example).
Configuring S1 to Allow Users to Relay This configuration is great for ISPs or enterprise networks that have a fully defined network, DNS entries for all the hosts in that network, and a proper MX record pointing to the relaying SMTP server. But what about standalone Internet hosts, which might have users all over the world trying to use their Sendmail servers to transmit mail? Each of these users, when trying to send a message through S1, from wherever they happen to be, will get a Relaying denied error back. To avoid this problem, you can specifically configure S1 to allow these users to relay. There are a number of ways to do this, many of which are extremely inadvisable in some situations: Add "trusted" sender domains to the file /etc/mail/relay-domains, which doesn't exist in the default installation. Any host within a listed domain will be permitted to relay through your server. You have to restart Sendmail after modifying this file. This is easy and effective, but as soon as you add a large, popular domain (such as aol.com) to this file that might contain spammers as well as legitimate senders, its benefit is lost. Add domains to this file one per line, as with /etc/mail/local-host-names (which you saw earlier in this chapter): # cat /etc/mail/relay-domains good.host.com 23.144.12.115 Note that local mail senders will be rejected unless the domains specified in their addresses are in /etc/mail/local-host-names. Enable SMTP authentication, which obliges remote users to provide a username and password before the SMTP server will allow them to use it. This is an advanced topic and requires you to configure authentication using SASL (the Simple Authentication and Security Layer), usually by installing a package called cyrus-sasl or cyrus-sasl2 (both available in the security section of the ports). You should also ensure that this takes place over a connection encrypted with SSL or TLS, protecting your users' passwords. See http://www.sendmail.org/~ca/email/auth.html for more information on setting up this authentication structure and enabling SMTP authentication. Use the access database (/etc/mail/access). This feature allows you to set up an OK or RELAY rule for each known host or domain from which your users will be connecting. This works well for small impromptu networks or for a few remote hosts at easily identifiable addresses, but it doesn't scale well for lots of users on dynamic addresses. For instance, if you're running a standalone server on the Internet that hundreds of different people connect to in order to send mail, it's going to be impossible to add all their IP addresses to /etc/mail/access, because most dial-up users have dynamic addresses these days. Administrators running servers in this kind of situation should probably advise users to send their mail through their own ISPs' SMTP servers instead of through yours. Enable any of the five or six relaying exception features available in Sendmail by adding them to /etc/mail/freebsd.mc and regenerating the sendmail.cf file (as shown earlier). There's a feature that lets you allow relaying based on whether the From: header is set to an address at your domain (relay_local_from), although this is easily forged by spammers and therefore using it isn't usually advisable. There's also an optional feature to perform a check against one of the Real-time Blackhole Lists, which are centrally maintained databases of known spammers (most that exist today require paid subscription). This feature is in the default freebsd.mc but is commented out; to enable it, move the dnl to the end of the line and rebuild the config file. This may be an advisable solution for ISPs. As an absolute last resort, turn off relay checking altogether by enabling the promiscuous_relay feature. This will allow any valid user to send mail through your Sendmail server; however, it will also allow any spammer to do the same. Some independently run databases on the Internet keep records of all "open" mail servers, and some service providers use these databases as "blackhole" lists of their own. You don't want your server to end up in these databases! If it does, some legitimate mail from your users or their correspondents may be blocked due to their ISPs blocking mail to or from your server. It's an incredibly bad idea to run an open mail server.
As a general rule, the best solution to the relaying problem is simply to instruct all your users to use the SMTP servers provided by their own dial-up Internet Service Providers. These services will always have their own SMTP servers that are open to their own customers. Because the headers in a mail message (such as the From: address) are all derived from the message body and therefore completely under the control of the email client program, there's no reason for a remote user to want to use your SMTP server if he already has one of his own. The Sendmail Consortium has an excellent page on relaying rules and your various available configuration options at http://www.sendmail.org/tips/relaying.html. |
