New technology tends to mimic current technology until people begin to recognize the new technology's potential and are willing to change the way they operate. For example, current email systems generally follow the model of paper mail, except that they're faster and easier to use. Only recently have email packages begun to use the processing power of PCs to exceed paper's capabilities. And from a security perspective, many current email systems don't provide even the same level of security that paper mail does. Future systems, however, promise to go well beyond it.
Because nearly everyone is moving toward the TCP/IP-based SMTP mail as the standard--or at least as a universal backbone--SMTP is currently the best candidate to become the universal standard for secure mail. The European X.400 standard is the only serious competitor to Internet SMTP mail in the long run. Proprietary mail systems are already being relegated to running as front ends to SMTP, and they may soon pass out of favor altogether.
Quite a few proprietary email systems are in use today, including Microsoft Mail (soon to be replaced by Exchange Server), cc:Mail, and DaVinci Mail. Most designs share a common file area on a server disk and put all the intelligence in the client software. This is a passive-server design. By comparison, true client/ server designs, such as SMTP mail and X.400, have an active-server software component, called a Message Transfer Agent. The MTA accepts network protocol requests from the client software, which is called a User Agent. The client software can access only the shared file area, the Message Store, via requests to the server; therefore, the shared file area is not exposed. The MTA also handles exchanging messages between post offices.
The network protocol is a set of conventions defining the exact syntax and sequencing of messages sent over the network. Two main protocols have evolved for implementing client/server mail on the Internet: SMTP and POP3. Several refinements have been made to these basic protocols. For example, PEM and S/MIME support encrypted attachments, and S/SMTP provides encrypted server-to-server transmission.
Each site has one MTA and one Message Store. The MTA can have any number of User Agents--some can be mail-enabled software applications--connected to it. One person uses each User Agent, and each User Agent connects to one MTA. (The User Agent is what you think of as your mail program, although it's really just a small part of the overall mail system.) Thus, a User Agent needs to handle only one connection at a time and needs to run only when its user is composing or reading mail. An MTA, however, must be able to handle multiple simultaneous connections and must be available at all times. Writing a User Agent is much easier than writing an MTA. In addition, you can run a User Agent on a less sophisticated operating system (e.g., Windows 95) than you need to run an MTA (e.g., Windows NT or UNIX).
As shown in figure A, if Arnold wants to send mail to Zeke and they both use Post Office 1, Arnold uses his User Agent to transfer the message via SMTP through the MTA to the Message Store for Post Office 1. The next time Zeke accesses his User Agent to check his mail, he will see the new message and can download it via POP3 to his local Message Store. If Arnold wants to send mail to Agnes and she uses Post Office 2, Arnold uses his User Agent to transfer the message via SMTP to MTA 1 where it winds up on an outgoing message queue. The next time MTA 1 connects to MTA 2--typically within a minute--SMTP will transfer his message through MTA 2 to the Message Store at Post Office 2. When Agnes checks her mail using her User Agent, she will see the new message and can download it via POP3 to her local Message Store. This kind of operation is called store-and-forward.
If gateway MTAs are involved, the process is essentially the same, but the message may be relayed through several MTAs before being deposited in the recipient's Message Store. This relay may be for security purposes or to allow the reconfiguration of internal post offices without outside MTAs needing to know anything about it. However, unless an MTA has been configured to always relay mail to a specific gateway MTA, it will typically connect to a large number of other MTAs, also.
