Welcome to UnixReview.com

[Advertisement]


Main Menu
  • Home
  • Archives
  • Reviews
  • Books
  • Editor's Choice
  • Geek Links
  • Contact Us

  • Sections
  • Open Source
  • Certification
  • Shell Corner
  • Unix Shows
  • Updates

  • [Advertisement]
    Newsletter
    Get the Newsletter
    Get the Newsletter

       We all know and hate it. Many consider it the litter on the side of the information superhighway. It clutters our mailboxes and clogs our mail gateways. It's spam. More than anything else on the network, unwanted mail messages have reduced the ability of network administrators to provide their users with quality service. Sometimes it seems like there's nothing we can do to stop the torrent of junk electrons. But it is possible to take control once again. Daemons & Dragons

    One of the biggest improvements in Sendmail version 8.8 is a mechanism for scanning a message upon receipt. This can be used to filter certain types of messages and reject them as they arrive. This can be a benefit not only for local recipients, but also for sites that relay mail messages. If you are using a single system as a mail gateway for your entire enterprise, the filtering can be done on the gateway before being forwarded on to the individual mail spool server. In this way, one host can filter spam for an entire company.

    RuleSets

    This new message scanning feature comes in the form of four sendmail rulesets. Sendmail uses rulesets at all stages of operation to modify addresses and make delivery decisions. A ruleset is a collection of rewrite rules, similar to the sed "substitute" operation. Each ruleset acts like a function: it is given a string as input and produces a string as output.

    Sendmail has a large collection of rulesets, all defined in the configuration file (sendmail.cf). These sets are used in predefined ways to convert addresses and to decide what should be done with a message. A ruleset can rewrite user@host as user@host.domain.org. But it also can rewrite user@domain.com into a string that tells sendmail to forward the message to another host. The interpretation of the result of a ruleset depends mostly on the ruleset itself. Sendmail applies different rulesets in different situations. Understanding a single ruleset is usually easy. The hard part is remembering which rulesets get applied when and for what purpose.

    A rule sees its input as a series of tokens. A token could be an alphanumeric string or a special character. The input string wnl@groupsys.com would be broken down into five tokens: wnl, @, groupsys, ., and com.

    SMTP Review

    Before delving into the new rulesets, let's make a quick review of the Simple Mail Transport Protocol (SMTP). A message is moved from one host to the next using an SMTP exchange. The host sending the message acts as client and the host receiving the message is the server. After connecting, the client introduces itself with a HELO command. Any number of unrelated messages can be sent in one connection. Each exchange starts with the command MAIL FROM: followed by the address of the original sender. Then the client sends RCPT TO followed by the address of the message's intended recipient. Once the server accepts the address, the client sends the command DATA and follows it with the entire mail message, including headers.

    Anti-Spam Rulesets

    Traditionally, rulesets have been known only by a number. Starting with Sendmail 8.8, rulesets can also be given names. Four named rulesets are invoked at various stages during the receipt of a message. If any of these rulesets returns a string that starts with $#error, the message is rejected. An error message also can be embedded in the response. If the ruleset returns anything else, the processing of the message proceeds normally.

    The first ruleset to be invoked is check_relay. It is called after a connection is accepted. As input, it is given the hostname and address of the client separated by the token $|. When sendmail processes the SMTP MAIL command, the ruleset check_mail is called and the sender's address is passed to it. Upon receiving the RCPT command, sendmail invokes check_rcpt and passes it the recipient's address. Finally, the ruleset check_compat is invoked with a string that contains both sender and recipient address. These addresses are separated with the token $|. An example is given in Figure 1.

    These rulesets let you hook into the early processing of a message. They can make accept or reject decisions based solely on the client host, the sender or recipient address in the envelope, or on the combination of sender and recipient. This last test is powerful because it can detect relayed messages. If you want to have sendmail reject every message that is not coming from or going to a host in your enterprise, then you could do that with a properly written check_compat ruleset.

    The check rulesets are the building blocks. But the standard configuration files do not define these rulesets. If you want to use the check rulesets, you have to find and install an existing implementation or write one yourself.

    Sendmail 8.9.0

    Just released in May, version 8.9.0 of Sendmail includes new configuration file "features" so you can enable or disable anti-spam checking. These features are part of the standard distribution located in the directory cf/feature. When you generate a customized configuration file for your site, you can choose to include any of these features in your configuration.

    If you have installed sendmail before, you are familiar with the process of creating a configuration file for your site. First you must compose a preprocessor file for m4, called an "mc" file. A collection of these files is kept in cf/cf, which probably is the best place to keep the one you write for your site. This directory also includes generic files for a variety of platforms. Start with one of these generics, then add m4 statements as needed. Once written, you generate the sendmail.cf file with the script "Build" in the same directory. This script runs m4 on the mc file to generate the configuration file. For example "./Build mysite.cf" would run the m4 preprocessor using mysite.mc as input and generate mysite.cf as output. The output should then be installed as sendmail.cf in the appropriate directory under /etc.

    Some default behavior has changed with 8.9.0. Previous versions of Sendmail did not prevent nonlocal senders from relaying mail through a site. A message going between hosts not within the local domain would be allowed unhindered passage. Spammers abuse this generosity regularly, forcing an unsuspecting site to do all the dirty work. In version 8.9.0, relaying is denied by default. If desired, you can enable the old behavior by adding the following line to the mc file: FEATURE(promiscuous_relay).

    Relaying privileges can be granted to specific domains by including them in the appropriate list. The m4 configuration file statement RELAY_DOMAIN(allowed.com) adds the domain name to the list domains allowed to relay mail through this host. These domains also can be specified via a file with RELAY_DOMAIN_FILE(/etc/allowedfile).

    A site that acts as a mail exchanger via MX records may want to permit its hosts relay privileges. The statement FEATURE(relay_based_on_MX) grants relay privileges to any host using the server in an MX record.

    By default, Sendmail 8.9.0 rejects any mail with an unresolvable host name as part of the from address. This also differs from previous versions of Sendmail. The old behavior can be obtained with FEATURE(accept_unresolvable_domains).

    The access database feature enables an administrator to selectively accept or reject mail from specified domains. If it is active, sendmail will read the map file /etc/mail/access. It should contain a list of domain names and the action to take for each. The value for each name can be one of the following:


    OK always accept
    RELAY allow relaying (implies OK)
    REJECT reject message with a generic message
    DISCARD throw message away (use "discard" mailer)
    message reject using message as the error message

    Consider the example in Figure 2. This will reject mail from user@domain.com but will allow any other message from domain.com. Any mail from the domain foo.com will be rejected with a specific error message, but mail from the host mail.foo.com will be allowed. Finally, any mail from a host in network 192.168.5.* will be rejected. The access database feature is enabled with FEATURE(access_db).

    Related Work

    Robert Harker, teacher and longtime sendmail expert, created a check_mail ruleset to do sophisticated anti-spam filtering. It provides functionality similar to what is now included with 8.9.0. Harker also worked on a check_rcpt ruleset that provides accept or reject decisions based on sender/recipient pairs and has enough flexibility to prevent outside users from sending to specific internal addresses (such as mailing lists).

    Figure 3 shows an example map for check_rcpt, called a check_fwd map. This configuration allows mail from any host in foo.com to send mail to the address list@foo.com but rejects mail to the list from anyone outside the domain. Harker's work is described in his Usenix paper from last year, and can be obtained from his Web site: http://www.harker.com.

    Summary

    The hooks provided by sendmail's check rulesets give you tremendous power and flexibility in accepting and rejecting messages. If you feel adventurous, you could undertake learning how to write sendmail rulesets and invent your own anti-spam mechanisms. The rewrite rule mechanism in Sendmail is just another type of programming language.

    The new anti-spam configurations now available in Sendmail 8.9.0 put this power directly in the hands of the average administrator. If spam is a serious problem at your site, you want to get the latest version of Sendmail. Even if you use the stock configuration for your platform, you will benefit directly from the changes made to sendmail's default behavior. Messages from faked domains will be dropped, and your site will no longer be usable as a mail relay between external sites.

    Once you have your sendmail configured to control the rejection of messages, you need to determine which sites should be blocked. The best source of information is personal experience. Look at what you and your colleagues receive, and what gets forwarded on to you by disgruntled users. There are several prominent sites that maintain lists of locations known to frequently generate spam, based on their experiences and also through the grapevine. I feel uncomfortable naming them in this article due to legal concerns, but some net surfing should reveal them.

    Sendmail is available from many locations--I always get my copies from ftp://ftp.sendmail.org/pub/sendmail/. All recent versions are archived there, up to 8.9.0.


    William LeFebvre has been banging on UNIX systems for 15 years and has been studying Internet technology for almost as long. He is the editor for the SAGE series "Short Topics in System Administration," and he currently operates Group Sys Consulting (Alpharetta, GA). Reach him at wnl@groupsys.com or via the Web at http://www.groupsys.com.

    References

    Harker, Robert, "Selectively Rejecting SPAM Using Sendmail," Proceedings of the Eleventh Systems Administration Conference (LISA '97), USENIX Association, 1997.

    Costales, Bryan and Eric Allman, Sendmail, 2nd Edition, Sebastopol, CA: O'Reilly & Associates, 1997.

    Allman, Eric, "New Sendmail Configuration Files," in Sendmail 8.9.0 as cf/README, 1998.


       

    Home | Top | Editor's Choice


    [Sys Admin Rocks!]
    Copyright © 2000 UnixReview.com ,UnixReview.com's Privacy Policy,
    Comments: rreames@cmp.com
    SDMG Web Sites: C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, Sys Admin, SD Expo, SD Magazine, UnixReview.com, Windows Developer's Journal