The OpenSource version, downloadable from www.sendmail.org, is based on version 8.11.1. The commercial version, Sendmail Pro, is based on Sendmail 8.9.3.

For the purpose of this review, I tested both versions of Sendmail on a dual Netfinity 5100 Pentium III 700-MHz server with 768 MB of RAM and five disk drives under RAID. This configuration should be big enough to support thousands of users. The OS was Linux 2.2.17 based on the RedHat 6.2 distribution. The server was attached to the LAN through two 100 Mb NICs and one FDDI card.

After downloading (and carefully checking the MD5 signatures) the 1.3 MB source code of Sendmail 8.11.1, I proceeded to compile it on the target system. Considering the scope of this beast, compiling Sendmail is not that difficult. I downloaded the file and unzipped it within a work directory. As the readme file specifies (since version 8.9.), there is a build script that comes with the source called, appropriately enough, "Build."

It is enough to launch "sh Build," which will start compiling the source. The machine trundled for about 10 minutes and then quietly created a new Sendmail binary. Once I copied that binary file to the /usr/sbin and restarted Sendmail, everything was done. It couldn’t be any easier.

Compiling and installing Sendmail is one thing. Configuring it is another. Luckily, most Linux and other Unix distributions already have a capable configuration file (Sendmail.cf).

The Sendmail.cf file has a very complex and varied syntax. Suffice to say that of all O’Reilly books (www.oreilly.com), the one on Sendmail is by far the thickest. According to the Sendmail Inc. folks, the average Sendmail.cf file is over 1,100 lines long. The Unix standard character for comments (the # sign) is significant as a configuration symbol. In fact, in Sendmail.cf every character is significant.

An m4 macro processor is only a slight consolation. It allows for a somewhat more readable macro configuration file, but even that is still overly complex, especially in these days of click-and-drag-and-drop software.

We won't discuss how to configure a Sendmail system here, since this subject is beyond the scope of any article--its even beyond that of a single-tome book. More detailed instructions describing how to build and install Sendmail.cf are available at the Sendmail Web site or in the Sendmail book by Bryan Costales and Eric Allman.

Since e-mail abuse is high on the list of computer annoyances of the connected generation, we will instead focus on how to use the modern Sendmail program to avoid spam and viruses.

Hardly an hour goes by without yet more unsolicited e-mail entering my inbox. Some people get used to this abuse, many others don’t stand for it and search for remedies to this plague.

Sendmail today provides many anti-span and security features. The spam issue is obvious: Some miscreants obtain a list of e-mail addresses and then use it to send e-mails promising fast riches, remedies for diseases or both. Mostly the sender’s true identity is not easily traceable from the sender’s e-mail address, because it is a fake. Actually responding to the sender with a request to be removed from his/her list only qualifies your e-mail address as active and thus guarantees its further spread to other mailing lists as a "quality address."

Sendmail's security features include anti-virus measures as well as the ability to prevent any unauthorized use of the relaying capabilities inherent to any MTA.

Since version 8.9 of Sendmail, there is no relaying mail unless specifically instructed to do so. And by default, Sendmail rejects messages with "envelope From" addresses  (the address mentioned in the SMTP "MAIL FROM:" command) that contain a host name that does not resolve successfully by reverse name lookup. However, relaying is not the same as forwarding. Forwarding is done at the request of the recipient rather than at the sender's request. Forwarding addresses may be specified in either a user's .forward file or the global /etc/mail/aliases or /etc/mail/virtusertable file, regardless of the system's relaying policy.

Another interesting option is:

The following option prevents Sendmail from revealing local user names to spammers and hackers:

define(`confPRIVACY_FLAGS',`goaway')dnl 

And the following command limits the number of new connections per second to Sendmail:

 define(`confCONNECTION_RATE_THROTTLE',3)dnl 

To prevent hackers and spammers from knowing which operating system you are using, it is important to turn off the Sendmail welcome message. Use the following command to do so:

define(`confSMTP_LOGIN_MSG', `$j server ready at $b')dnl

And, lastly, you can use this command to limit the number of recipients per e-mail message:

define(`confMAX_RCPTS_PER_MESSAGE,25)dnl

These features should have an immediate, noticeable and positive impact on the security and reliability of your Sendmail messaging.

For those corporations needing top-notch support for a Sendmail-based messaging solution as well as added management and configuration comfort, the commercial Sendmail Pro version might be a worthwhile alternative to the OpenSource rendition.

For one thing, Sendmail Pro includes over 300 pages of online help. But should such extensive online help not be enough, there is always technical support available from Sendmail Inc. via Web, e-mail, telephone and even onsite consulting.

• Sendmail 8.9's Access Database to filter mail by sender's address, domain or IP address
• MAPS Real-time Blackhole List (RBL), a public list of known spammers
• Filters for unrecognizable senders or domains
• Mail message size and volume limits

Sendmail published application-programming interfaces to allow developers who are plugging in programs in C, Perl or others to filter their incoming mail.

This filtering capability gives companies the opportunity to search for viruses in the incoming mail stream before they reach departmental e-mail servers. It can filter out well-known sources of spam and even spot attempts of intrusion hidden within in-coming connections.

Such content-based filtering is also a good way to control incoming and outgoing messages to prevent the use of objectionable language. The law in many countries permits companies to supervise the content of employees’ messages.

During my review, I found that both the commercial and the OpenSource versions of Sendmail were able to handle e-mails in excess of 500 per second on the above-mentioned system. When turning on filtering through C programs, that volume dropped down to about 140 per second. It is clear that housing the filter within the same address space as the Sendmail process would speed up filter processing considerably.

By analysing the Linux kernel, it became evident that most of the overhead lies in the creation, management and tearing down of the address space used to handle filtering. As with Apache, filtering modules within the same process is certainly the solution. However, e-mail traffic in the magnitude of 140 per second is certainly more of an issue for ISPs than it is for most companies. Also, the structure and algorithms for the filtering applets can have a great impact on the performance.

Even though Sendmail is already a grown-up product at the age of 19, it is still keeping up with the times. Sendmail outperforms many other commercial products and still has by far the greatest marketshare of all of them combined, handling over 76% of all the e-mail flowing across the Internet.