Storing and Forwarding With SMTP And Message Transfer Agents

SMTP and/or ESMTP When an MUA first interacts with an MTA while sending an e-mail message, two things must occur. First the MUA must identify itself to the MTA and receive permission to send a message through it. Second the MUA must indicate whom the message is for and transport the content of the message to the MTA for transfer. SMTP and its big brother ESMTP (Extended Simple Mail Transfer Protocol) are used to transfer the message from MUAs to MTAs and from MTA to MTA. The transfer of the message can be broken into three parts--envelope, delivery method and content. The envelope consists of the recipient and sender addresses. The content of a mail message consists of additional header information and the actual body of the message, whether it be structured using MIME or unstructured. The envelope and content are fairly straightforward. The delivery method, however, has changed somewhat sinc e the SMTP protocol standard was drafted back in 1982. Delivery of a message can occur using two different methods, referred to as MAIL and SEND commands in the SMTP standard. MAIL is most commonly used and informs the MTA that the mail message should be delivered to a mailbox and stored for future delivery. The SEND command is seldom used and directs the contents of the message to the specified user on the specified terminal. If the destination user is on the terminal and accepting terminal messages, the message will be immediately delivered. For most installations, there are few terminals capable of accepting messages in this way and users will want all incoming mail to be stored in a mailbox. Two additional SMTP commands--SOML and SAML--will attempt to send or mail in the first command and send and mail in the latter command. If you are not using the SEND capability of your MTA, you should disable all three variations of the SEND command. For most Windows NT-based mail servers, these commands are more than likely not implemented or aliased to the MAIL command. Additional SMTP commands such as VRFY, which reveals the user information for a specific user name, and EXPN, which expands mailings lists, should be logged or disabled. It's important to realize that outside parties can gain access from a simple user name obtained from one of these commands and compromise your network's security. SMTP will provide all the functionality necessary for your MTA and is relatively simple (no pun intended). ESMTP is an extension mechanism for SMTP implementations. Since its conception, extensions to SMTP have included command pipelining, 8-bit MIME, DSN (Delivery Status Notification) and message size declaration. Choosing an MTA implementation capable of supporting these extensions can provide your users with faster, more efficient mail services. Perhaps one of the more interesting enhancements made possible by ESMTP is the use of SMTP pipelining. Pipelining is the ability to send mo re than one SMTP command per network packet thus reducing the delay introduced in the SMTP dialog by network latency or congestion. The concept is rather simple and allows for certain SMTP commands to be sent in batches without waiting for return or error codes. For larger network installations, SMTP pipelining could significantly improve the performance of mail systems with large amounts of network traffic. Of course in order to utilize SMTP pipelining, we'll need to wait for clients to also support the extension. The DSN extension may seem self-explanatory. However, the powerful capabilities of this extension can provide you with an invaluable tool for debugging mail delivery-associated problems. SMTP alone only provides notification of delivery failure. When an address is sent successfully, no notification is sent to the originator of the message. Furthermore, when large amounts of mail are sent at one time, for example a mailing list, excessive delivery failure notifications can confuse network administrators and offer little useful information. DSN is capable of informing the network administrator with specific error-related information potentially indicating the exact host that was the cause of the failure. With the extremities of the Internet often lying within legacy mail systems, determining the point and the reason of the failure is invaluable to the network administrator. The Message Size extension for SMTP enables the mail client to indicate message size to the MTA. This lets the MTA intelligently decide if it can handle a message of the specified size. With the use of electronic mail for larger multimedia files, relaying information concerning the size of a message will assist in the successful transport of the message itself. Although SMTP has been a highly successful transport protocol, it does have limits. The longevity of such a widely supported protocol has necessitated a need to advance its capabilities through future standards and protocols. In 1993, ov er a decade after the SMTP protocol was defined, MIME was created. Its purpose was to facilitate the inclusion of 8-bit word-oriented data into a transport mechanism that is only capable of transporting 7-bit ASCII characters. Its need has arisen from the surge in Internet usage and the increased desire for multimedia content in everyday communication. 7-bit MIME itself is not dependent on the MTA implementation. This is because the clients themselves must have already converted the 8-bit data to 7-bit ASCII prior to transmission to the MTA. Since the conception of the ESMTP extension mechanism, a newer 8-bit MIME standard has been formed. It differs from the original MIME standard in that the encoding uses 8-bit word-oriented structure which deviates from the SMTP requirement that data or content be 7-bit ASCII. The 8-bit MIME extension can only be sent via an MTA capable of the ESMTP 8-bit definition. When an 8-bit MIME encoded message arrives at an MTA (relay or destination) that does not support the 8-bit MIME standard, the message will return with a standard failure indicated as the reason for the failure. If your users are dependent on electronic mail for transfer of multimedia information and the like, support for the 8-bit MIME extension should be considered. But as with pipelining, we'll need to wait for client support to catch up. Print This Page E-mail this URL