Overview

The simple mail architecture in which sendmail and popper fit includes a mail user agent (MUA), a mail transfer agent (MTA), and a mail delivery agent (MDA). An MUA is client software that a user invokes directly to send and receive email. Examples of MUAs include Eudora, Netscape Navigator, pine and elm. An MTA is software that actually routes messages from a sender's system to the receiver's system. sendmail is an MTA. It is worth noting, however, that sendmail relies on other programs to implement non-SMTP based transport (for example, UUCP-based transport as well as local delivery to a user's mail spool file). An MDA is server software that delivers received mail to a user's MUA. Popper is an example of an MDA using the POP3 protocol.

At the sender's end of the mail delivery process, the sender's MUA transmits the message to be delivered to sendmail, as shown in Figure 1.
Figure 1. Sender MUA transmits the message to sendmail
Diagram showing that the sender MUA transmits messages to sendmail using SMTP over a TCP/IP connection or UNIX pipe

This can occur in one of two ways. If the MUA is running on the local host, the message can be transmitted by executing a copy of sendmail and transmitting the message to the standard input of that process via a UNIX pipe.

Alternatively (and more commonly), a copy of sendmail will be running as a daemon, and the MUA (running on either the local host, or on a remote host) will open an SMTP connection to the sendmail daemon, transmitting the message to be delivered via that SMTP connection. In this case, sendmail is acting as an SMTP server, while the MUA is acting as an SMTP client.

In the next step, for each recipient address, sendmail transmits the message to some other SMTP server, to route the message to its final destination at the recipient's site. This is shown in Figure 2.
Figure 2. sendmail transmits the message to an intermediate SMTP server
Diagram showing that sendmail transmits the messages to the SMTP server with SMTP

The receiving SMTP server, in this case, might be a local hub that handles all mail at the sender's site, a remote hub handling all mail at the recipient's site, or an SMTP server at the recipient's host system.

In the next step, sendmail acts as an SMTP client, initiating an SMTP connection with some SMTP server, and then transmitting the message to be delivered to that server, via the SMTP connection.

At the receiver's end of the mail delivery process, a sendmail daemon receives the message from some SMTP client, as shown in Figure 3.
Figure 3. A sendmail daemon receives the message from an SMTP client
Diagram showing that, at the receiving end, a sendmail daemon gets the messages from SMTP client using SMTP protocol

The sendmail daemon, acting as an SMTP server, accepts an incoming SMTP connection, and receives a message to be delivered over that SMTP connection. (This is identical to receipt of a message from an MUA, over an SMTP connection.)

Upon receiving the message, sendmail delivers it to the local recipient by appending the message to the recipient's mail spool file. To do this, sendmail requires a local mailer program, as depicted in Figure 4.
Figure 4. sendmail delivers the message to the local recipient
Shows that sendmail sends messages to local mailer, which uses file system append to append messages to the recipient

In this step, sendmail executes a specified local mailer program, such as /usr/lib/tsmail, and transmits the message to be delivered to that mailer through a UNIX pipe. The mailer program appends the message to the recipient's mail spool file. With this sendmail's role in delivery of mail is completed.

For the recipient to now read the received message, an MUA must be used. Depending upon the MUA, this may or may not require an additional MDA, such as popper. If the receiver's MUA has direct access to the mail spool file, the MUA may retrieve the mail directly from the spool file, as depicted in Figure 5.
Figure 5. Receiver's MUA has direct access to the mail spool file
Diagram showing that the receiver MUA uses the file system read to get the messages from the mail spool file
Alternatively (and more commonly), the MUA will establish a POP3 connection with a popper daemon, and retrieve the message over that connection. This is shown in Figure 6.
Figure 6. Receiver's MUA retrieves the message over a POP3 connection with a popper daemon
Shows receiver MUA connecting over POP3 connection and using file system read to get messages from mail spool file

The popper daemon will also allow the receiver's MUA to manage the mail spool file, by allowing it to specify whether and which message should be deleted.

For security issues, sendmail has supported RFC 2487 (SMTP Service Extension for Secure SMTP over TLS) to provide private, authenticated communication over the Internet, as shown in Figure 7. z/OS® UNIX sendmail uses System SSL instead of Open SSL.

Figure 7. Using a certificate to establish a secure connection
Shows sendmail client/server using client and server certifications to protect their key rings and key databases

Also, when sendmail receives mail, a mail filter provides an interface for third-party software to validate and modify messages as they pass through the mail transport system. Filters can process messages' connection information, envelope protocol elements, headers, and body contents, and modify a message's recipients, headers, and body. The MTA configuration file specifies which filters are to be applied, and in what order, allowing you to combine multiple independently-developed filters. Mail filters are separate daemons that can be run remotely or locally. How a mail filter works is shown in Figure 8.

Figure 8. Mail filter processing
MTA receives messages, passes them to mail filter for validating and modifying, receives the processed messages back