| Previous | Table of Contents | Next |
SMTP defined how to transfer a mail message across the Internet, but did not define how to recognize a mail message. RFC822 defines the format of Internet electronic mail messages. The format is simple, as befits a standard:
The header fields are much longer than the content in the example message given here:
Return-Path: david@mail.fake.com Received: from localmail.mail.fake.com (localmail.mail.fake.com [168.9.100.10]) by gateway.oppositemail.com (8.9/8.9) with ESMTP id WAA01322 for <robert@oppositemail.com>; Sat, 22 May 1999 18:17:06 –0500 Received: from beta.mail.fake.com (beta.mail.fake.com [207.266.47.2]) by localmail.mail.fake.com (8.9/8.9) with SMTP id WAA13732 for <robert@oppositemail.com>; Sat, 22 May 1999 18:22:06 –0500 Message-Id: 199802180506.WAA13732@localmail.mail.fake.com X-Sender: pete@localmail.mail.fake.com X-Mailer: Amiga Eudora Lite Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 May 1999 18:22:08 –0500 To: robert@oppositemail.com From: David Wylie david@mail.fake.com Subject: Test message This is a test message. David
The blank line after the “Subject” line divides the header from the message body that follows. Any subsequent blank line is part of the message body and has no structural significance. Most header fields are brief and have a fairly obvious meaning (such as “Subject”), while some others are lengthy and not readily understood (such as “Received…”). For a detailed explanation of the many standard and less-standard header fields, see Chapter 35 of Costales and Allman’s sendmail, 2nd edition.
Each header line consists of a “keyword-value” pair that defines a characteristic of that message. For example, a required characteristic of a mail message is a message recipient. This characteristic is defined by the keyword To:, one or more Spacebar or Tab characters, and then the value that specifies the mailing address of the recipient. In the message above, this characteristic is defined by the following line:
To: robert@oppositemail.com
sendmail is generally considered one of the few true nightmares of UNIX system administration. sendmail is difficult to configure and can be approached in much the same way that novices approach UNIX. When someone once complained to Eric Allman (the creator of sendmail) that sendmail administration was complicated, he replied, “Configuring sendmail is complex because the world is complex.” While sendmail can do just about anything you can think of, instructing it how to do what you want it to can be a chore.
However, while sendmail is difficult to work with, recent versions have improved the tasks of configuring and administering sendmail substantially. The addition of a large set of M4 macros and the ability to use intelligible names for options in addition to the single-character switches in the configuration file has made sendmail configuration an easier task. sendmail has also become a reasonably mature product. Although flaws are still found almost monthly, sendmail is used in enterprise networks for mail delivery across a wide set of networks and in high-volume environments.
In the late 1970s, Eric Allman was at the University of California at Berkeley. He wrote the predecessor to sendmail, called delivermail, which was released in 1979 to solve the problem of transferring mail between the three networks on campus at that time. Those three networks were ARPANET (which was using NCP, or Network Control Protocol), a UUCP mail system, and an internal network called BerkNet.
The next year, ARPANET started to convert from NCP to TCP (Transmission Control Protocol). Previously, mail was delivered using FTP (File Transfer Protocol), but SMTP was developed to plan for the possible growth of the network’s mail traffic by several orders of magnitude.
In response to these changes, Allman adopted an inclusive approach to formats of electronic mail messages. If a message didn’t match the preferred format, sendmail attempted to fix the message format instead of immediately rejecting the message. Allman also chose to limit the functional goal of sendmail to be a router of mail, instead of including the functionality of an end-user mail application. The 4.1c version of BSD (Berkeley Software Distribution) UNIX included the first public release of sendmail.
Meanwhile, others were busy extending sendmail’s capabilities separately from Allman. In addition to various private efforts, several commercial vendors such as Sun and Hewlett-Packard developed their own versions of sendmail as they saw needs for improvements not included in the current versions. Out of these parallel developments came several versions of sendmail with varying levels of compatibility. In 1998, Allman took sendmail to commercial status as of version 8.9, leaving the 8.8.x version the freeware it always was.
In general, compilation and installation of the sendmail distribution is often simpler than it first appears. The source package includes make-description files tailored for many different systems, and a “build” script that chooses the correct one for the local environment. At times, an administrator might need to make minor changes to the make-description file that’s most similar to his particular environment in order to match the specific local system.
| Previous | Table of Contents | Next |