Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Searchable, convenient, complete TCP/IP information.
The TCP/IP Guide

Custom Search

Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Key Applications and Application Protocols
           9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
                9  TCP/IP Electronic Mail System: Concepts and Protocols (RFC 822, MIME, SMTP, POP3, IMAP)
                     9  TCP/IP Electronic Mail Delivery Protocol: The Simple Mail Transfer Protocol (SMTP)

Previous Topic/Section
SMTP Mail Transaction Process
Previous Page
Pages in Current Topic/Section
Next Page
SMTP Security Issues
Next Topic/Section

SMTP Special Features, Capabilities and Extensions
(Page 1 of 2)

The primary job of the Simple Mail Transfer Protocol is of course to implement the TCP/IP electronic mail delivery system. Whenever the user of an SMTP server gives it an e-mail message addressed to a non-local mailbox, the server will attempt to transfer it to the appropriate destination server, using the SMTP mail transaction process. Many billions of such transfers are performed every day on the Internet, allowing e-mail to quickly reach its destination anywhere around the world.

SMTP Special Features

In addition to the basic mail transfer mechanism, SMTP includes a number of other features and capabilities. These allow SMTP to support special requirements and auxiliary needs of the mail system, and are described in detail in RFC 2821. It would take many topics to describe them all in detail, so I will just provide a quick summary of the more important ones here so you know a bit about them:

  • Mail Relaying: As discussed in the SMTP communication overview, the protocol was once widely used in a “relaying mode” where e-mail was routed from one SMTP server to another to reach its destination. Today, the normal method of e-mail transfer on the Internet today is directly from the sender's SMTP server to the recipient's, using DNS MX records to determine the recipient SMTP server address. SMTP still includes the ability to relay mail from one server to another, provided certain conditions are met. Note that in addition to the inefficiency of relaying, many servers won't relay mail because this feature has been abused for spamming and hacking.

  • Mail Forwarding: Under certain conditions, an SMTP server may agree to accept e-mail for a non-local mailbox and forward it to the appropriate destination. This sounds similar to relaying but is used in a different way. A common example is when a user changes his or her e-mail address. If I have worked at XYZ Industries for years and then retire, the company may no longer wish to let me receive e-mail at the company's SMTP server. As a courtesy, however, they may forward e-mail sent to me there so I still receive it at my new company.

  • Mail Gatewaying: Certain SMTP servers may be configured as e-mail gateways. These devices “translate” TCP/IP e-mail into a form suitable for another e-mail system, and vice-versa. Gatewaying is a complex topic because e-mail systems can be so different; one of the more important problems is the inconsistency of addressing methods of different e-mail systems.

  • Address Debugging: SMTP includes a VRFY (verify) command, which can be used to check the validity of an e-mail address without actually sending mail to it.

  • Mailing List Expansion: The SMTP command EXPN (expand) can be used to determine the individual e-mail addresses associated with a mailing list. (Note however that this has nothing directly to do with mailing list software like Majordomo.)

  • “Turning”: The original SMTP protocol included a command that allows the SMTP sender and SMTP receiver to change roles. This could be used to allow SMTP server A to send e-mail to server B, and then have B send e-mail it has queued for A in the same session. In practice, this capability was not widely used for a variety of reasons, including security considerations. It is now officially “not recommended”, but may still be implemented in some SMTP software.
Other Capabilities and Functions of SMTP Servers

The list above represents just a few of the features that are mentioned in the SMTP standards. In addition to these, a given type of SMTP server software may be given other features as well by its developers. The HELP command is one way to determine what some of the commands that a given SMTP server supports.

SMTP servers also must perform a great deal of “background processing” that doesn't get a great deal of attention. This includes managing connections, checking for errors in commands and e-mail messages, and reacting accordingly. They must also be on the lookout for problem conditions, such as “looping” that may result in an e-mail message being passed back and forth between two SMTP servers, each thinking the other is the intended recipient. In the event of an initial failure to deliver mail, SMTP servers are also required to periodically retry communication with the destination device, and return a failure message to the sender if it cannot deliver the message after a certain period of time. Again, RFC 2821 contains more details.

Previous Topic/Section
SMTP Mail Transaction Process
Previous Page
Pages in Current Topic/Section
Next Page
SMTP Security Issues
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

The TCP/IP Guide (
Version 3.0 - Version Date: September 20, 2005

Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.