POP3 protocol analysis

POP3 protocol analysis

Chapter 4. POP3 Overview

POP3 is called Post Office Protocol version3, that is, Post Office Protocol version 3rd. It is used by the user agent to obtain the mail on the mail server. POP3 uses the C/S communication model, and the corresponding RFC document is rfc1939. This Protocol is very simple, so we only focus on the communication process. For some related concepts and terms, refer to the RFC document or another article "SMTP protocol analysis".

Chapter 4. POP3 explanation 2nd. Communication Process

The typical communication process for a user to receive a mail from the mail server is as follows.

1)
The user runs the user agent (such as Foxmail and Outlook Express ).

2)
The user agent (hereinafter referred to as the client) establishes a TCP connection with port 110 of the mail server (hereinafter referred to as the server.

3)
The client sends various commands to the server to request various services (such as querying email information and downloading an email ).

4)
The server parses the user's command, performs the corresponding action, and returns a response to the client.

5)
3) and 4) Alternate until all emails are received and forwarded to step 6), or the connection between the two is accidentally interrupted and directly exited.

6)
The User Agent parses the emails obtained from the server and presents them to the user in an appropriate form (such as readable.

2), 3), and 4) Communicate with pop3. We can see that commands and responses are the focus of POP3 communication, and we will focus on them.

2.2. commands and responses 2.2.1.
Format

There are not many POP3 commands. The general form is: Command [parameter] <CRLF>. Command is the command name in ASCII format, parameter is the corresponding command parameter, and <CRLF> is the carriage return line break (0dh, 0ah ).

A server response is composed of a single command line or multiple command lines. The response starts with "+ OK" or "-Err" and then adds some ASCII text. "+ OK" and "-Err" respectively indicate whether the operation status is successful or failed.

2.2.2.
Three statuses

The POP3 protocol has three statuses: positive status, processing status, and update status. Command Execution can change the Protocol state. For a specific command, it can only be used in a specific State. For more information, see table 1 and rfc193.

When a connection is established between the client and the server, its status is authentication. Once the client provides its identity and is successfully confirmed, the status is transferred to the processing status; after the corresponding operations are completed, the client issues the quit command (For details, refer to the subsequent content), then enters the update status, and then returns to the approval status. Of course, the quit command is executed in the approval status, releases a connection. The transfer between statuses 1 is shown.

--- Establish connection --- | approve | -- authentication successful -- | process | -- execute quit -- | update |
| _______-Quit ends _________________ |

Figure 1 POP3 status transition diagram

Approval Status

Processing status

Update Status

Establish a connection

Run quit

Quit complete

Run quit to release the connection.

Authentication successful

2.2.3.
Example

The format of commands and responses is syntax. The meaning of commands and responses is semantics. The relationship between commands and responses in time is synchronization. We still use a simple POP3 communication process to describe the three elements of the Protocol.

C: Telnet pop3.126.com 110/* connect to the 126 email server via Telnet */

S: + OK Welcome to coremail mail POP3 server (126 coms [3adb99eb4207ae5256632eecb8f8b4855])/* + OK indicates that the command is successful, and the subsequent information varies with the server */

C: User bripengandre/* plaintext authentication */

S: + OK core mail

C: Pass pop3world/* Send email password */

S: + OK 654 message (s) [30930370 byte (s)]/* authentication successful, transfer to processing status */

C: List 1/* display the information of the first email */

S: + OK 1 5184./* The first mail size is 5184 bytes */

C: UIDL 1/* return the unique identifier of the first email */

S: + OK 1 1tbisbshaex9byi9eqaasd/* The long string after the number 1 is the unique identifier of the first mail */

C: RETR 1/* download the first email */

S: + OK 5184 octets/* the size of the first mail is 5184 bytes */

S: receive... /* Specific content of the first email */

S :...

C: Quit/* Transfer to update status, and then transfer to authentication status */

S: + OK

C: Quit/* disconnect */

S: + OK core mail/* the connection is successfully exited */

For the above process, add the following content.

1)
The line starting with "C:" (excluding "C:") is the input of the client, and the line starting with "s:" (excluding "s :") is the output of the server.

2)
The preceding command may not succeed at one time. The server will return an error response (starting with "-Err"). The client should follow the time sequence specified by the Protocol, to enter Subsequent commands (or re-Execute failed commands, reset sessions, or quit sessions ).

3)
The above process is schematic, and the actual process may be quite different from it. For example, encryption authentication (MD5 Digest authentication) may be used in the actual process ).

4)
Emails downloaded by RETR may be hard to understand, because they may use quoted-printable or base64 encoding. We can use user agent software such as Foxmail to decode them.

2.2.4.
Common commands and responses

SMTP commands are case-insensitive, but the parameters are case-sensitive. For more information, see rfc1939. Common commands are shown in table 1.

Command	Parameters	In what status	Description
User	Username	Authentication	If this command is successful with the following PASS Command, status conversion will occur.
Pass	Password	Authentication	If this command is successful, the status is changed to update
APOP	Name, digest	Authentication	Digest is the MD5 message digest.
Stat	None	Processing	The request server sends back the mailbox statistics, such as the total number of mails and the total number of bytes.
UIDL	[MSG #] (email number, the same below)	Processing	The unique identifier of the returned message. Each identifier of a POP3 session will be unique.
List	[MSG #]	Processing	The unique identifier of the returned message. Each identifier of a POP3 session will be unique.
RETR	[MSG #]	Processing	Returns all text of a message identified by a parameter.
Dele	[MSG #]	Processing	The server marks the emails marked by parameters as deleted and is executed by the quit command.
Top	[MSG #]	Processing	The server returns the mail header + the first n lines of content of the email identified by the parameter. N must be a positive integer.
Noop	None	Processing	The server returns a positive response to test whether the connection is successful.
Quit	None	Processing and authentication	1) If the server is in the "processing" status, it will enter the "Update" status to delete any emails marked as deleted and return to the "authentication" status. 2) If the server is in the "authenticated" status, end the session and exit the connection.

Table 1 Common POP3 commands

As for the response, as described in 2.2.1, the response starts with "+ OK" or "-Err", followed by some readable descriptions and other parameters (for RETR, this parameter is the content of the email ). For more information, see rfc1939.

Chapter 4. POP3 vs IMAP

Compared with the Internet Message Access Protocol IMAP (Internet Message Access Protocol), POP3 is only an offline protocol, and the interaction between customers and servers is not particularly good. For example, you cannot directly create folders in your mailbox, and you may not be able to selectively download a part of the email (although the TOP Command partially implements this function, it is not interactive. However, it also has its own advantages, that is, the Protocol is simple, easy to implement, and the cost is low. This is the most important reason why POP3 is widely used and IMAP is almost eliminated.

Chapter 2. Implementation Solution

ID	Protocol	Captured Contents
		User Name	Password	Sender	Cycler	Subject	Contents	Attachments
5	POP3	√	√	√	√	√	√

Table 2 POP3 Analysis Requirements

Table 2 provides protocol analysis requirements. It is easy to see that it is easier to obtain fields. We can capture the interaction information between the client and the server, and then extract the desired field based on each command word or response word. For example, to obtain the user name, for plaintext verification, we only need to detect the user in the sending information of the client, and then extract the parameter after the USER command. It should be noted that, although the client-server interaction information may be encoded or encrypted, we can still obtain the required information through decoding or decryption.

Chapter 4. References

[1]
RFC: rfc1939 corresponds to the POP3 protocol, rfc821 corresponds to the SMTP protocol, rfc822 corresponds to the mail standard, rfc1425 corresponds to ESMTP, rfc1522 corresponds to the expansion of the mail header, and rfc1521 corresponds to the expansion of the mail body

[2]

Http://www.faqs.org/rfcs/, all English rfcdocumentation

[3]

Http://www.cnpaf.net/, there are some useful analysis documents, there are also Chinese RFC documents, but the quality is not particularly high

[4]
Steven S, W. R., TCP/IP replicated strated, vol1. addision-Wesley, Mechanical Industry Press, 2002

 

From: http://blog.csdn.net/bripengandre/article/details/2192111