Down the Page

Standard Internet E-mail Protocols Message Transfer Agents User Agent to Host Communication Directory Services Mail Delivery Message Format and Encoding Message and Transmission Security Mail Server Security Encryption of Messages References

Networks and Workstations Links

Domain Name System (DNS) Internet Connection Support Network Design and Planning Network Installation and Configuration Troubleshooting Utilities Workstations Return to: Networks and Workstations Home Tech Support Home

Internet E-mail Services

E-mail (Electronic Mail) programs deliver messages from one mailbox to another on local or remote mail servers. Although the systems housing a local mail server may be diverse, all Internet mail travelling to another mail server must traverse the Internet using a standard set of protocols. The purpose of this paper is to provide a basic framework for understanding and implementing mail servers and clients for Internet mail, regardless of the platforms involved.

Standard Internet E-mail Protocols

All Internet mail must traverse the Internet using a standard TCP/IP (Transmission Control protocol/ Internet Protocol) suite of networking protocols. Standard protocols are defined in individual RFCs (Request for Comments). RFCs and general information are available through the IMC (Internet Mail Consortium) at http://www.imc.org/mail-standards.html. Although one or two RFCs generally may be associated with a particular protocol, there are hundreds of supporting RFCs that also define how these protocols interact with networks, applications, etc.

Figure 1 is a simplified table of common Internet protocols and their relative positions when compared to the OSI (Open Systems Interconnections) and DOD (Department of Defense) networking models. The IP protocol at the network layer defines how data is routed between networks. The TCP protocol at the transport layer works with upper layer protocols to establish a connection between two sites on the Internet for the transfer of data. The SMTP (Simple Mail Transfer Protocol) is the Internet standard protocol defining the transmission of electronic mail between two users. It relies on the TCP transport layer to establish a connection between two hosts and ensure reliable delivery of the data. A session is established between the two hosts based on IP numbers and a port number that identifies the service required. SMTP sessions are established on Port 25. Once the data has been transferred between the two hosts the session is terminated. This process occurs each time mail is transferred between two hosts on the Internet.

Message Transfer Agents

SMTP is an Application Layer protocol as defined by RFC 821 involving processes that use the Transport Layer TCP to deliver data between MTAs (Message Transfer Agents). Hosts use MTAs such as Sendmail on UNIX to: (1) send and receive messages and (2) provide an interface for user applications.

Client and server roles are associated with the SMTP protocol. When a sending MTA wants to establish a session with a relay agent or a receiving MTA, the sending MTA becomes a "client." The MTA on the receiving end becomes the "server." Figure 2 shows MTAs residing on two hosts. Each host can be a client or server depending on which one initiated the request. A mail server acts as an MTA and therefore can be either an SMTP client or an SMTP server. We will refer to the mail server as an SMTP host when discussing the mail transfer process.

Figure 2. Message Transfer Agents Residing on Two Hosts

Back to Top

If a mail server uses only SMTP for mail transfer (such as UNIX with Sendmail), it communicates directly with other SMTP hosts. If a mail server runs a proprietary set of e-mail programs, it might have to use an SMTP gateway to communicate with other hosts. The gateway translates the information into standard SMTP packets for transfer over the Internet. Examples of such mail servers include Novell's Groupwise and Microsoft Exchange. These work with proprietary protocols for the delivery of local mail and Internet mail transfers use an SMTP gateway.

SMTP hosts may work on a store and forward basis. Hosts queue messages for a certain length of time then forward them to the next relay host or server. This conserves bandwidth and conserves processing time on the server. Hosts work directly with DNS (Domain Naming System) to find other hosts. If an SMTP client cannot perform a DNS query it must forward mail to a smart relay host before it can be delivered. Figure 3 shows an MTA using a smart relay host to reach another MTA.

Figure 3. Relay Hosts

Most e-mail messages are sent to domain names (although messages can be sent to IP numbers). The standard format for an e-mail address is username@Internetdomain. For the message to arrive at the correct location, the Internet Domain Name must be resolved to an IP address. If a mail server is a smart relay host, the sending server MTA can perform a DNS query and deliver mail directly to the destination mail server. If a relay host is required, all mail goes through the relay host before delivery to the destination mail server.

Any SMTP host can be a relay agent (not necessarily "smart") unless this is specifically turned off. This presents security issues as spammers and other abusive e-mail users may use your host to relay unsolicited messages. Most e-mail servers now have the ability to turn off relaying for non-local hosts. MOREnet currently allows relaying by customers linked to our backbone only. For more details see MOREnet's relaying policy at http://www.more.net/security/best/relay.html.

SMTP works with the Internet Domain Naming Service to find users on the Internet. The user's address must be a registered domain name, for example user@mail.district.k12.mo.us or user@vetmed.missouri.edu. In each case, the domain mail.district.k12.mo.us or vetmed.missouri.edu must be properly registered with a DNS (domain name server) and associated with a specific IP address. This address is the actual address of the mail server (or associated SMTP gateway).

Mail servers are often registered with mx (mail exchange records). When a Mail Transfer Agent queries a DNS server for a mail domain name such as aol.com, there may be more than one mail exchange agent identified as a path to reach the mail server. These are given a preference number and the mail transfer agent picks the lowest number to try first. If the preferred mail server is not available mail is sent to the next server to be queued for delivery to the preferred mail server as it becomes available. Figure 4 shows how an mx record determines how mail is delivered.

Figure 4. DNS Requests and MX records

MX or mail exchanger records as defined by RFC 974 provide delivery reliability. An mx record determines which mail servers can accept mail for that domain. For example, the domain mail.net may have the following mx records:

mail.net preference=10, mail exchanger=server1.mail.net
mail.net preference=20, mail exchanger=server2.mail.net
mail.net preference=30, mail exchanger=server3.mail.net

Each of these mail servers has a unique IP number and is authorized to deliver mail to mail.net. The lowest number assigned within a group of mx records is accorded the highest preference. In the example above mail for user@mail.net would go to server1.mail.net first to be delivered. If the mail server does not recognize the mail recipient as valid, the mail will be returned to the sender. If there is a problem with server1.mail.net (for example, if the server is down for some reason), the mail would go to server2.mail.net to be queued for delivery to server1 as it becomes available.

Back to Top

User Agent to Host Communication

Directory Services

Once the mail arrives at the mail server, it is the responsibility of the mail server to deliver it to the user. The mail server must have a database of authenticated users to work with. Some mail server software such as Mercury Mail for NT or SENDMAIL maintain a user database exclusively for mail. Other mail systems such as Mercury/Pegasus for Novell or Microsoft Exchange for NT, work in conjunction with the user database that resides on the LAN File Server. Messaging Systems such as Exchange and Novell's Groupwise work with the directory and also provide calendar and integrated application functions for the users. While these provide more functionality for the end user they often require a higher level of support. There is a push for the development and adoption of Internet Standards in messaging system components such as calendar and directory access.

LDAP (Lightweight Directory Access Protocol) as defined by RFC 2251 is a standard clientserver protocol that allows you to browse directory information regardless of the host operating systems. Recent versions of POP (Post Office Protocol) clients and browsers support LDAP. Having a standard directory access protocol will allow users to search mail servers for usernames. Microsoft Exchange, Netscape's Mail Server and Sendmail all support LDAP.

Figure 5. Searching for a user name on an LDAP Server

Mail Delivery

Incoming mail is placed in a queue for local delivery and later delivered to the user mailbox area. Once a user agent (or client) is invoked, the mail is typically downloaded from the server to the user (see Figure 2).

In a POP server/client environment, users can type in their user and host information from any location and access their mail. POP3 (Post Office Protocol Version 3) is defined in RFC 1939 and is the standard protocol for downloading new mail from a server to a client. Clients must establish a connection with the POP3 server and the mail is then downloaded to the client PC.

IMAP (Internet Messaging Access Protocol) as defined by RFC 2060 allows the user to copy or delete messages from the server and access public folders as well. An IMAP4 client with integrated LDAP support can browse Server-based address books from a remote connection (in addition to being able to search).

Message Format and Encoding

RFC 822 defines the ASCII message format originally associated with the SMTP protocol. ESMTP (Extensions to Simple Mail Transfer Protocol) define standards that enable any type of information to be carried. MIME (Multipurpose Internet Mail Extensions) is the official proposed standard format for multimedia Internet mail encapsulated inside standard Internet message. RFCs 1521 and 1522 describe multipart messages that may contain graphics, videos or any type of information. Most Internet mail clients support MIME and should be able to separate attachments and enclosures correctly. Once users download a message, they must have the applications required to interpret each part of the message.

Message and Transmission Security

There are a variety of security issues associated with the transmission and content of e-mail and it is difficult to categorize them efficiently. Security for an individual message can be taken care of at each communication point or can belong to the message. Communication points include the sending mail server, router, relay hosts, and the receiving mail server. Encryption of messages is the preferred method to ensure security but involves cooperation of the sender and receiver.

Mail Server Security

A variety of security issues are associated with Internet mail, the most common being SPAM. SPAM is not an acronym but has come to stand for any unsolicited e-mail whether it is commercial or personal (for example, threats). SPAM not only annoys recipients but can crash mail servers with the sheer volume of messages.

By default, SMTP servers are relay hosts for other SMTP servers. This means that your mail server will accept mail from anyone and relay it to the destination. The problem is that spammers usually conceal the real source of the message so the recipients only know that your server was the relay host. To prevent this problem your mail server should be configured to accept relaying only from designated hosts. To learn more about SPAM and how to avoid it, refer to the following webpages:

http://www.more.net/security/encryption/index.html

http://www.more.net/technical/netserv/servers/novell/supportpack.html

Mail servers can be put behind firewalls to protect them from direct attacks on the server. Firewalls control the access between networks and can be implemented through hardware and/or software solutions, at the router and/or the mail server. For more detailed information on firewalls refer to http://www.faqs.org/faqs/firewalls-faq/. Another security issue with mail servers is the availability of certain ports for TCP sessions. The availability of standard ports such as 21 (FTP), 23 (Telnet) and 25 (SMTP) can be points of weakness on a mail server. Port 25 must be available for SMTP but other ports should be disabled if possible.

Back to Top

Encryption of Messages

Encryption involves putting information into a form that cannot be understood without a mechanism for "decrypting." Encryption should ensure that only the recipient can read the message (privacy) and may also ensure that the sender was genuine (authentication).

Current protocols favored for encryption of messages are S/MIME and PGP/MIME. For complete definitions of these protocols refer to: http://www.imc.org/smime-pgpmime.html. Both of these protocols use public keys and provide both authentication and privacy. The protocols are different and cannot share keys but both use multipart/signed MIME as defined in RFC1847. The IMC hopes to pick one of these protocols as the standard in the near future.

Kerberos is an encryption tool developed by MIT (Massachusetts Institute of Technology) which uses secret key cryptography for secure client/server sessions and for a level of security that may become more necessary in the future. For a more detailed description of kerberos, refer to: http://web.mit.edu/kerberos/www/.

References

Albitz, Paul & Cricket Liu. DNS and BIND. O'Reily, 1998.
Feit, Dr. Sidnie. TCP/IP. McGraw-Hill Series on Computer Communications, 1997.
Heywood, Drew. Networking with Microsoft TCP/IP, 1997.
Gerber, Barry. Exchange Server 5.5. Sybex, 1998.