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 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                           9  TCP/IP Post Office Protocol (POP/POP3)

POP3 Transaction State: Mail and Information Exchange Process and Commands 1 TCP/IP Internet Message Access Protocol (IMAP/IMAP4)

Once the POP3 client has completed all the e-mail message access and retrieval transactions that it needed to perform, it is done with the POP3 session—except it isn't really quite done yet. The POP3 standard defines a final session state, the Update state, to perform various housekeeping functions, and then terminate both the POP3 session and the underlying TCP connection.

The transition from the Transaction state to the Update state occurs when the POP3 client issues the QUIT command. This command has no parameters, and serves to tell the POP3 server that the client is done and wishes to end the session. The POP3 standard lists this command as part of its description of the Update state, though it obviously is really issued from the Transaction state.

After the POP3 server receives the QUIT command, one thing it does is to delete any messages that were previously marked for deletion by the DELE command in the Transaction state. It's interesting that the Post Office Protocol chose to implement this two-stage deletion process. The standard doesn't describe specifically why this was done, but it seems likely that it is a precaution to insure against accidental deletion and loss of mail.

By delaying actual deletion until the Update state, the server can verify that it has received and processed all commands prior to the move to the Update state. It also allows the deletion of messages to be “undone” if necessary, using the RSET command, if the user changes his or her mind about the deletion prior to exiting the Transaction state. Finally, if any problem occurs with communication between the client and server that causes the TCP connection to be interrupted prematurely before the QUIT command is issued, no messages will be removed from the mailbox, giving the client a second chance to retrieve them in case they were not received properly.

Once the deleted messages have been removed, the server returns an acknowledgment to the client; “+OK” if the update was successful, or “-ERR” if there was some sort of a problem removing one or more of the deleted messages. Assuming there were no problems, the “+OK” response will also contain a “goodbye” message of some sort indicating that the session is about to be closed. The TCP connection between the client and server is then torn down and the session is done.

A POP3 mail retrieval session normally lasts a few seconds or minutes, but can take many minutes if the mailbox is large and the connection between the client and server is slow. There is no limit on how long the client and server can be connected, as long as commands continue to be sent by the client. A POP3 server will normally implement an inactivity timer, however, which is customizable but must have a duration of no less than 10 minutes. If the connection is idle for the full duration of the inactivity timer, the server assumes that the client has experienced some sort of a problem and shuts down the connection. If this occurs, the server doe not delete any messages marked for deletion—again, this is in order to give the client another chance to retrieve those messages if a problem occurred getting them the first time.

POP3 Transaction State: Mail and Information Exchange Process and Commands 1 TCP/IP Internet Message Access Protocol (IMAP/IMAP4)