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 tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$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!

Read offline with no ads or diagram watermarks!
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 Access and Retrieval Protocols and Methods

Previous Topic/Section
TCP/IP Electronic Mail Access and Retrieval Protocols and Methods
Previous Page
Pages in Current Topic/Section
1
23
Next Page
TCP/IP Post Office Protocol (POP/POP3)
Next Topic/Section

TCP/IP Electronic Mail Mailbox Access Model, Method and Protocol Overview
(Page 1 of 3)

In an ideal world… we would all be born knowing everything there is to know about computers and networking, and I'd have become a famous novelist instead of writing thousands of pages of this stuff. J Well, that may be asking a bit too much, but wouldn't it have been nice if every device on the Internet simply ran SMTP server software? If so, then that one protocol would be sufficient to implement the entire TCP/IP e-mail system. You would just compose e-mail on your machine, and your SMTP software would send it to your recipient's, and he or she would read it. Nice and simple.

Back here in the real world, however, this is really not possible in general terms. As I explained in the overview section on e-mail and the discussion of SMTP, an SMTP server must be connected to the Internet and available around the clock to receive e-mail sent at any time by any of the millions of other computers in the world. Most of us either cannot or do not want to run machines continuously connected to the Internet, nor do we want to configure and maintain potentially-complex SMTP software. This is the reason why a complete e-mail exchange normally involves not two devices but four: a message is composed on the sender's client machine, transferred to the sender's SMTP server, then to the recipient's SMTP server, and finally, to the recipient's machine.

The Advantages of Specialized Mail Access and Retrieval Protocols

The communication between SMTP servers is of course done with SMTP. So is the initial step of sending the e-mail from the sender's machine to the sender's SMTP server. However, SMTP is not used for the last part of the process, accessing the recipient's mailbox. Instead, a set of mailbox access and retrieval protocols and methods were devised.

A fair question is… why was this done? Why not simply have mail sit “pending” on the recipient's SMTP server and then have it send the mail to the recipient client device when it comes online, using SMTP? There are two main reasons for this. The first is that SMTP was designed for the specific purpose of transporting e-mail only. Having it responsible for client mailbox access would require adding more functionality, making it difficult to keep SMTP “simple”. Also, SMTP works on a “push” model, with transactions being initiated by the sender. It would need changes to allow it to respond to requests from a client device that is only online intermittently.

But the second reason is probably more important: flexibility in how electronic mail is accessed. If we used SMTP, all we would be able to do is transfer e-mail to the recipient's client machine. This would be functional, but would greatly limit the capabilities of how e-mail is used. For example, some users might wish to access mail directly on the server and manipulate it there. Also consider the problem of people with special requirements, such as those who travel and may need to access e-mail from a number of different client devices.


Previous Topic/Section
TCP/IP Electronic Mail Access and Retrieval Protocols and Methods
Previous Page
Pages in Current Topic/Section
1
23
Next Page
TCP/IP Post Office Protocol (POP/POP3)
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 (http://www.TCPIPGuide.com)
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.