Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
How to Enable and Interpret the Pop3.log File
Article ID: 155515 - View products that this article applies to.
This article was previously published under Q155515
This article discusses the entries found in the Pop3.log file, and is intended to be used as a reference after you try all other troubleshooting steps. Most POP3 transmission errors are related to either hardware configuration errors (modem, serial port, initialization string), TCP/IP connectivity problems, or problems with the client computer. In addition, this article provides basic background information on POP3.
Please note that the information contained within this article is based on information obtained from documents made freely available by the Internet Engineering Task Force (IETF). These documents, called Requests-for- Comments (RFCs), are living documents. As such, the information presented here is only as current as the RFCs used to research these articles.
When RFCs are updated or made obsolete, the original RFC number is preserved. Any RFC that has been updated or made obsolete is modified to contain the newer RFC number.
POP3 is defined in RFC1939, and can be obtained, free of charge, on the Internet at ds.internic.net. This site accepts HTTP, anonymous FTP, and TELNET connections.
The remainder of this article is organized into two sections: "POP3 Basics" and "Interpreting the Pop3.log File."
POP3 BasicsFor information about how to enable the Pop3 log in Outlook Express, please see the following article in the Microsoft Knowledge Base:
ARTICLE-ID: 176548This section includes a general introduction to POP3 design, connections, and session commands and syntax.
(http://support.microsoft.com/kb/176548/EN-US/ )How to Create a Pop3.log File for Outlook Express
Special conventions used in this article follow.
The following abbreviations are used frequently:
SP : SPACE <ASCII 20h (32d)>
CRLF : CARRIAGE RETURN+LINEFEED <ASCII 0Dh+0Ah (13d+10d)>
POP3 was developed to satisfy a need for a dynamically accessible mail delivery system. In the early days of ARPA, the ultimate destination of an email message was usually a large host system that was continually connected to the network. There was no need for mail to be stored for later retrieval as the message was delivered to the user's terminal when it was received. However, with the proliferation of inexpensive dial-up access to the Internet, the need arose for a mail storage mechanism because users are not always connected to their service providers.
The POP3 protocol is used only as a delivery mechanism between a mail client and a mail host (post office). The messages that reside in the client's mail drop are delivered there by the Simple Mail Transfer Protocol (SMTP). For more information on SMTP and its use with Microsoft products, please see the following article in the Microsoft Knowledge Base:
155455POP3 transfers involve a client-server model where each participant can send, receive, and interpret session status messages from the other. The client usually initiates and terminates the connection to the host.
(http://support.microsoft.com/kb/155455/EN-US/ )How to Enable and Interpret the Smtp.log File
One very important difference between SMTP and POP3 is that SMTP, being basically a mail relay agent, does not require user authentication before allowing access to SMTP functions. Since POP3 is a 'post office protocol,' and POP3 servers have multiple mail drops, it implements several methods to authenticate clients.
NOTE: This article only covers the use of the USER and PASS keywords for POP3 authentication. For more information regarding POP3 authentication techniques, please see either the POP3 specification  or RFC 1734.
A second important difference between SMTP and POP3 servers is that the POP3 server employs a state machine, similar to the finite-state automaton in PPP, that passes through several states during the course of a connection. State transitions are driven by events triggered by the client.
NOTE: To change this value in Microsoft Internet Mail and News (IMN), use the following steps:
<keyword> SP <arguments> CRLFThe <arguments> field may contain several parameters, each being up to 40 characters long. Not all command keywords have arguments and not all command keywords that use arguments require that they are used.
<status indicator> SP (<keyword> / <additional information>) CRLFWith regards to responses, the following semantics must be followed:
The scope of this article covers the commands most likely to be seen while examining the Pop3.log produced by IMN, with the exception of the TOP command. For a complete listing and explanation of POP3 commands, see RFC 1939.
The rest of this section will be organized according to the commands that you should expect to see used within a given POP3 state. Not all commands can be issued in all states. The primary commands that can be issued within a given state will be covered first, and then any additional commands that may be common to multiple states will follow.
The order of the commands presented below does not imply that there are No other possible sequences of commands. The following commands and explanations outline a simple connection.
When the connection is established, the POP3 host responds with a one-line greeting in the following format:
+OK (server ready) CRLFIf when troubleshooting a POP3 connection a greeting is not received, the server may be malfunctioning or down.
For more information on troubleshooting POP3 connections, please see the following article in the Microsoft Knowledge Base:
154578After issuing the greeting, the POP3 state machine transitions to the AUTHORIZATION state.
(http://support.microsoft.com/kb/154578/EN-US/ )Troubleshooting Problems Connecting to Mail Servers.
NOTE: Some POP3 implementations, in order to guard against intrusion attempts based on repetition, may not issue a negative response, but will instead request a password. An example of this is provided later.
Syntax : USER SP <user-id> CRLF Expected responses : +OK (name is a valid mailbox) -ERR (never heard of mailbox name)
If the USER command generates a positive response, the client will then send the PASS command.
The +OK response will usually contain a message that indicates the number of waiting messages and total mail drop size in octets. Since no significant information is derived from this response (other than the user was logged in successfully), only the +OK portion is needed.
Syntax : PASS SP <password> CRLF Expected responses : +OK (mailbox locked and ready) -ERR (invalid password) -ERR (unable to lock mail drop)
The second -ERR response usually indicates that the user is already logged in on another connection. It is also possible that the user's mail drop could be corrupted and the host cannot parse it, or the resource containing the mail drop be temporarily unavailable. Finally, in some POP3 server implementations, particularly on UNIX hosts, the 'unable to lock mail drop' response is typical of other error conditions present on the server. As such, the error message may not properly represent the problem. Either way, the user needs contact whomever is responsible for administrating their POP3 server.
When the QUIT command is issued in the AUTHORIZATION state, the POP3 server does not transition to the UPDATE state (covered later), it simply closes the current connection and beings listening for another.
Syntax : QUIT <no arguments> CRLF Expected response : +OK (host closing connection)
If authentication succeeds, the POP3 state machine will transition to the TRANSACTION state.
The +OK response is the only possible response as defined in the current specification for POP3 .
Syntax : STAT <no arguments> CRLF Expected Response : +OK n yyyy
The format of the +OK response is the same whether or not the <message number> argument is specified or not:
Syntax : LIST SP <message number> CRLF [argument is optional] Expected Responses : +OK (scan listing follows) -ERR (no such message)
Where 'n' is a decimal value indicating either an individual message number or the total number of messages in a mail drop; and 'yyyy' is a decimal value representing either the size of an individual message or the entire mail drop in octets. What follows depends on whether or not the <message number> argument is used.
+OK n yyyy
If the <message number> argument is used, it must refer to a message number that has not been marked for deletion using the DELE command(covered later). The host will echo the message number and return the size of the message in octets. Being a single-line response, there is no termination sequence. For example:
If the <message number> argument is not used, this command returns a multi-line response. The listing starts with the +OK response containing the mail drop statistics, followed by one line listings for each message, and then terminated with the CRLF.CRLF sequence.
C: LIST 1 H: +OK 1 2039
NOTE: In Pop3.log, all that is shown is the +OK response.
For example, this is what was actually sent from the POP3 host:
C: LISTThis is what Pop3.log shows:
H: +OK 7 messages (15423 octets)
H: 1 1903
H: 2 4255
H: 7 2458
POP3: 10:25:43 [tx] LIST POP3: 10:25:43 [rx] +OK 7 messages (15423 octets)
It is stated in the POP3 specification  that the unique-id value should never be duplicated in a mail drop. This idea is similar to not being able to have to files of the same name in the same directory - even if it was possible, how would you tell them apart?
If Internet Mail is configured to leave a copy of the messages on the POP3 server, this information is cached in a file called POP3UIDL.DAT. Later, when the user checks for mail, the UIDL command is issued to the POP3 server and the information returned is checked against what is in POP3UIDL.DAT. If a message's unique-id is not found in the DAT file, it is retrieved. If it is found, it is left alone.
If this file is deleted, IMN will download all the messages on the host, regardless of whether or not they have been retrieved previously.
If the user disables the "Leave a copy of messages on server" option, two things will happen the next time they connect to the POP3 server:
The format of the +OK response is the same whether the <message number> argument is supplied or not:
Syntax : UIDL SP <message number> CRLF [argument is optional] Expected Responses : +OK (unique-d listing follows) -ERR (no such message)
Where 'n' is the message number, and 'yyyy' is the unique-id listing. If the <message number> argument is provided, the response will be one line. If it is not, the responses will be formatted similarly, but will follow multiple-line conventions.
+OK n yyyy
NOTE: In Pop3.log, all that is shown is the +OK response.
For example, this is what was actually sent from the POP3 host:
C: UIDLThis is what Pop3.log shows:
H: 1 19960819154006293.AAA137
H: 2 19960819154010920.AAA139
H: 6 19960819161045578.AAA126
This truncated version of the host's output, as was done with the LIST command's response, is done largely to keep the size of the logfile down and because the actual response information is not important to the user.
POP3: 10:25:43 [tx] UIDL POP3: 10:25:43 [rx] +OK
NOTE: Not all servers implement the UIDL command. In the event the server indicates that the UIDL command is not supported, IMN will fall back to the TOP command, and use the message-id contained in the message's headers. This value, like the unique-id, is assumed to be completely unique.
The <message number> argument specifies which message the user would like to see the TOP of. The <nn> argument is a non-negative integer value indicating the number of lines of the message to be sent.
Syntax : TOP SP <message number> SP <nn> CRLF Expected Responses : +OK (top of message follows) -ERR (no such message)
If <number of lines> is zero, only the message's headers will be sent by the host.
If <number of lines> is greater than zero the message headers, a blank line, and then 'nn' lines of the message will be sent by the host.
When the RETR command is issued, the message referenced in the argument is transmitted in its entirety to the client. Note that the use of this command and subsequent retrieval of a message does not imply that the message will be deleted afterwards. This is the job of the DELE command, covered next.
Syntax : RETR SP <message number> CRLF Expected Responses : +OK (message follows) -ERR (no such message)
Pop3.log does not log the contents of each message, rather, it only logs the command being issued and whatever immediate response is returned. For example, here is what the host sends when this command is issued:
C: RETR 1This is what Pop3.log shows:
H: +OK 476 octets
H: <message headers>
H: <blank line>
H: <body text and attachments>
POP3: 10:25:43 [tx] RETR 1 POP3: 10:25:43 [rx] +OK 476 octets
When the DELE command is issued, the message referenced in the argument is marked for deletion, it hasn't actually been removed from the mail drop yet. The significance of being marked for deletion is that the client can no longer issue a command with that message's number as an argument, any such attempt will generate an error.
Syntax : DELE SP <message number> CRLF Expected Responses : +OK (message deleted) -ERR (message already deleted) -ERR (no such message)
The DELE command can be countermanded if the client issues the RSET command, which is covered later. The command sequence below illustrates the use and effect of the DELE command.
H: +OK pop3.host.com POP3 server ready . . <client logs into the POP3 host> . H: +OK user's mail drop has 1 messages (476 octets) C: LIST 1 H: +OK 1 476 C: DELE 1 H: +OK Message 1 deleted. C: RETR 1 H: -ERR Message 1 was deleted. C: RSET H: +OK user's mail drop has 1 messages (476 octets) C: LIST 1 H: +OK 1 476 . . <session continues> . C: QUIT H: +OK pop3.host.com closing connection. Good Night.
The POP3 specification  does not mandate that any information follow the '+OK' portion of the response. There is no provision for an -ERR response, the server must respond with the positive reply.
Syntax : RSET CRLF Expected Response : +OK
A negative response is not provided. This command has no effect on the server's state machine or any messages in the user's mail drop.
Syntax : NOOP CRLF Expected Response : +OK
Normally, the positive response is returned to the client, and the host terminates the session. If the host encounters a problem while removing messages, the negative response is issued.
Syntax : QUIT <no arguments> CRLF Expected response : +OK (host closing connection) -ERR (some messages note removed)
If the session terminates abnormally, that is, the connection was dropped or terminated, the host will not enter the UPDATE state and any messages marked for deletion will be reset.
Interpreting the Pop3.log FilePOP3 logging is not enabled by default. To enable POP3 logging in Outlook Express, click Options on the Tools menu, click the Advanced tab, and then click the Mail Transport check box to select it. To enable POP3 logging in Internet Mail and News, you must add or change the following entries in the registry::
In order to fit all the pertinent data for each entry on one line, the 'POP3:' tag and the time stamp at the beginning of each line have been removed.
HKEY_CURRENT_USER\Software\Microsoft\Internet Mail and News\Mail Value Name : "Log POP3 (0/1)" (without quotes) Value Type : dword Value Data : 00000001 Value Name : "Log File (POP3)" (without quotes) Value Type : string Value Data : <path to log file>
To view the Pop3.log file, follow these steps:
Log Example - Typical Session
Lines 1 and 2 are plugged in every time Internet Mail and News is launched.
01) Microsoft(r) Plus! for Windows(r) 95 4.70.1155 02) POP3 Log started at Sun Aug 18 16:27:52
Lines 3 and 4 indicate the friendly name and the IP address of the POP3 server specified in the Internet Mail and News configuration.
03) [db] Connecting to 'pop3.host.com.' 04) [db] srv_addr = nnn.nnn.nnn.nnn
Line 5 indicates that the communications channel between the client and the host has been successfully opened.
05) [rx] +OK pop3.host.com POP3 server ready Sun, 18 Aug 1996 14:28:31 - 0700 06) [tx] AUTH twinkie 07) [rx] -ERR Command unknown: AUTH 08) [tx] USER joe 09) [rx] +OK Password required for joe 10) [tx] PASS ******** 11) [rx] +OK joe's mail drop has 28 messages (215096 octets)
In Line 6, the AUTH command  is issued to the server with a dummy value of 'twinkie.' The AUTH command is an authentication method used by a post office specification known as the Internet Message Access Protocol - 4 (IMAP4) . The command's failure is indicated by the negative response in Line 7. This command was included to test for authentication methods supported by the POP3 server. In Line 8, the client begins authenticating itself by issuing the USER command with 'joe' as the user-id. Line 9 indicates that the user-id has been accepted and prompts for a password. As mentioned before, POP3 servers will typically not indicate that a user-id is invalid. The only time a negative response will be seen here is if a character outside of the 21h-7Eh range finds its way into the string.
Line 10 shows that the password has been transmitted. Since the password is transmitted in the clear, it is masked by asterisks in the Pop3.log file.
The positive response on Line 11 indicates that authentication was successful. The server transitions to the TRANSACTION state at this time.
The STAT command is issued to obtain the number of messages in the mail drop, and its size.
12) [tx] STAT 13) [rx] +OK 28 215096
The UIDL command is issued in Line 14 with the parameter '1.' The server returns the unique-id string of the first message in the mail drop. Then, in Line 16, the command is issued again with no parameters. This will return the unique-id strings for all the messages in the mail drop.
14) [tx] UIDL 1 15) [rx] +OK 1 19960814211633540.AAA85@smtp.host.com 16) [tx] UIDL 17) [rx] +OK
In line 18, the LIST command is sent with no parameters. The response generated is multiple-line, and all that is shown in Pop3.log is the response status. This command is useful to determine the size of each message in the user's mailbox. If the user has specified that they do not want to download messages over a given size, that information is checked here.
18) [tx] LIST 19) [rx] +OK 28 messages (215096 octets)
Here is where the information gained from the UIDL command is used. This log file was generated after the "Leave copy..." was disabled. The first three messages in the mail drop had already been retrieved prior to this connection, and are now being removed.
20) [tx] DELE 1 21) [rx] +OK Message 1 deleted 22) [tx] DELE 2 23) [rx] +OK Message 2 deleted 24) [tx] DELE 3 25) [rx] +OK Message 3 deleted
Line 26 shows the beginning of message retrieval. Unless the user has chosen to preserve the messages on the server, each message is marked for deletion after it is downloaded. Remember that the message is not actually removed from the mail drop until the QUIT command is issued.
26) [tx] RETR 4 27) [rx] +OK 8875 octets 28) [tx] DELE 4 29) [rx] +OK Message 4 deleted . . . 30) [tx] RETR 28 31) [rx] +OK 14288 octets 32) [tx] DELE 28 33) [rx] +OK Message 28 deleted
After all messages have been downloaded, the client issues the QUIT command, which triggers the POP3 server's transition to the UPDATE state. This is when messages are removed from the mail drop. When all the messages have been removed, the +OK response is issued, and the host closes the TCP/IP connection.
34) [tx] QUIT 35) [rx] +OK pop3.host.com POP3 server closing connection 36) [db] Connection to 'pop3.host.com' closed.
Log Example - Failed LoginIn this example, the user account is valid, but the password is wrong.
In this example, the user account is invalid, so the password does not matter.
01) [db] Connecting to 'pop3.host.com.' 02) [db] srv_addr = nnn.nnn.nnn.nnn 03) [rx] +OK pop3.host.com POP3 server ready Sun, 18 Aug 1996 14:28:31 - 0700 04) [tx] AUTH twinkie 05) [rx] -ERR Command unknown: AUTH 06) [tx] USER joe 07) [rx] +OK Password required for joe 08) [tx] PASS ****** 09) [rx] -ERR Password failed for joe 10) [tx] QUIT 11) [rx] +OK pop3.host.com POP3 server closing connection 12) [db] Connection to 'pop3.host.com' closed.
This article is intended as a reference to be used when all other troubleshooting has failed. The majority of POP3 transmission errors are going to be related to either hardware configuration errors (modem, serial port, initialization string), TCP/IP connectivity problems, or client-side malfunction.
01) [db] Connecting to 'pop3.host.com.' 02) [db] srv_addr = nnn.nnn.nnn.nnn 03) [rx] +OK pop3.host.com POP3 server ready Sun, 18 Aug 1996 14:28:31 - 0700 04) [tx] AUTH twinkie 05) [rx] -ERR Command unknown: AUTH 06) [tx] USER jdoe 07) [rx] +OK Password required for jdoe 08) [tx] PASS ****** 09) [rx] -ERR jdoe unknown, or access denied from [xxx.xxx.xxx.xxx] 10) [tx] QUIT 11) [rx] +OK pop3.host.com POP3 server closing connection 12) [db] Connection to 'pop3.host.com' closed.
As a general rule, always rule out any other possible source of error before troubleshooting an odd log file entry.
Article ID: 155515 - Last Review: January 19, 2007 - Revision: 4.1