http://blog.csdn.net/bripengandre/article/details/2192111
POP3 Protocol Analysis 1th Chapter. POP3 Overview
POP3 is all called the Post office Protocol Version3, the Post Office Protocol version 3rd. It is used by the user agent to get mail from the mail server. POP3 adopts the C/s communication model, and the corresponding RFC document is RFC1939. The protocol is very simple, so we focus only on its communication process, and some concepts and terminology refer to the RfC or another article, Chapter 2nd, "SMTP protocol analysis ." POP3 detailed 2.1. Communication Process
The typical communication process for a user to receive mail from a mail server is as follows.
1) The user runs the user agent (such as Foxmail, Outlook Express).
2) the user agent (hereinafter referred to as the client) establishes a TCP connection to port 110 of the mail server (hereinafter referred to as the server side).
3) the client sends various commands to the server to request various services (such as querying mailbox information, downloading an email, etc.).
4) the server resolves the user's commands, makes the corresponding action and returns a response to the client.
5) 3) and 4) alternately, until all messages have been received go to step 6), or the connection between the two has been accidentally interrupted and exited directly.
6) the user agent resolves the messages obtained from the server side and renders them to the user in an appropriate form (such as readable).
2), 3), and 4) communicate with the POP3 protocol. It can be seen that commands and responses are the focus of POP3 communications, and we will focus on them. 2.2. Command and Response 2.2.1. Format
POP3 command is not much, its general form is: command [Parameter] <CRLF>. Where command is the name of the ASCII form, parameter is the corresponding command parameter,<crlf> is the carriage return newline character (0DH, 0AH).
The server response is made up of a separate command line, or multiple command lines, in response to the first line "+ok" or "-err", followed by some ASCII text. "+ok" and "-err" respectively indicate whether the corresponding operation state is successful or failed. 2.2.2. Three states
The POP3 protocol has three states, positive status, processing status, and update status. The execution of the command can change the state of the Protocol, and for a specific command it can only be used in a specific state, see table 1 and RFC193.
When the client and server have just established a connection with the server, it is in the state of authentication, and once the client has provided its identity and is successfully confirmed, it is transferred from the approved state to the processing state, and after the corresponding operation, the client issues a quit command (as specified in the following section). The update then returns to the approved state; Of course, the QUIT command is executed in the approved state to release the connection. Transitions between states are shown in Figure 1.
---Establish a connection---| recognition |--certification successful--| processing |--performing quit--| updates |
|_______-quit End _________________|
Figure 1 State transition diagram for POP3
Execute quit to release the connection |
2.2.3. An example
The format of commands and responses is syntax, and each command and response is semantic, and each command and response is synchronized in relation to time. We also illustrate these three elements of the protocol by using a simple POP3 communication process.
C:telnet pop3.126.com 110/* Telnet connection to 126 mail server */
S:+ok Welcome to Coremail Mail Pop3 server (126coms[3adb99eb4207ae5256632eecb8f8b4855])/* +ok, on behalf of the command succeeds, subsequent information varies with the server * /
C:user Bripengandre/* With clear Text authentication */
S:+ok Core Mail
C:pass Pop3world/* Send mailbox Password */
S:+ok 654 message (s) [30930370 byte (s)]/* Authentication successful, transferred to processing status */
C:list 1/* Display information for the first message */
S:+ok 1 5184./* The size of the first message is 5184 bytes */
C:uidl 1/* Returns the unique identifier for the first message */
S:+ok 1 1TBISBSHAEX9BYI9EQAASD/* The long string after the number 1 is the unique identifier for the first message */
C:RETR 1/* Download First e-mail * *
S:+ok 5184 octets/* The size of the first message is 5184 bytes */
S:receive .../* Specific contents of the first email */
S: ...
C:quit/* To the update status, then to the certification status */
S:+ok
C:quit/* Exit connection */
S:+ok Core Mail/* succeeded in exiting the connection */
For the above process, the following points are added.
1) the line starting with "C:" (excluding "C:") is the client's input, and the line that begins with "s:" (excluding "s:") is the output of the server.
2) The above command does not necessarily succeed at one time, the server returns an error response (beginning with "-err"), and the client should enter subsequent commands (or repeat the failed command, or reset the session, or exit the session, etc.) according to the timing specified in the protocol.
3) The above process is indicative, the actual process may be different from the other. For example, cryptographic authentication (MD5 Digest authentication) may be used in the actual process.
4) retr downloaded mail may be difficult to understand, because it may use quoted-printable encoding or base64 encoding, we can foxmail and other user agent software to decode it. 2.2.4. Common Commands and Responses
The SMTP command is case-insensitive, but the parameters are case-sensitive, please refer to RFC1939 for detailed instructions. Common commands are shown in table 1.
Command |
Parameters |
The state in which to use |
Describe |
USER |
Username |
Certification |
This command, if successful with the following pass command, causes a state transition |
PASS |
Password |
Certification |
If this command succeeds, the status is converted to an update |
APOP |
Name,digest |
Certification |
Digest is a MD5 message digest |
STAT |
None |
Processing |
Requests that the server send back statistics about the mailbox, such as the total number of messages and the total number of bytes |
UIDL |
[msg#] (mail number, same as below) |
Processing |
Returns a unique identifier for the message, and each identifier for the POP3 session will be unique |
LIST |
[msg#] |
Processing |
Returns a unique identifier for the message, and each identifier for the POP3 session will be unique |
RETR |
[msg#] |
Processing |
Returns the full text of the message identified by the parameter |
DELE |
[msg#] |
Processing |
The server marks the message identified by the parameter as deleted and executed by the QUIT command |
TOP |
[msg#] |
Processing |
The server returns the message header + first n rows of the message identified by the parameter, and n must be a positive integer |
NOOP |
None |
Processing |
The server returns a positive response to test whether the connection was successful |
QUIT |
None |
Processing, Certification |
1) If the server is in the "processing" state, it will go to the "update" status to remove any messages marked for deletion and return to the "Authentication" status. 2) If the server is in the "Authentication" state, end the session and exit the connection |
Table 1 common commands for POP3
As for the response, as described in 2.2.1, starting with "+ok" or "-err", followed by some readable instructions and some other parameters (for RETR, this parameter is the contents of the message). Please refer to RFC1939 for more detailed instructions. 3rd chapter. POP3 VS IMAP
POP3 the biggest disadvantage of IMAP (Internet Message Access Protocol) over Internet Message Access Protocol is that it is only an offline protocol, and the client's interactivity with the server is not particularly good. For example, you cannot create a folder directly in a mailbox, and it is not good to selectively download a portion of the message (although the top command partially implements this feature, but the interactivity is not very good). However, it also has its own advantages, that is, the agreement is simple, easy to implement, low cost, which is POP3 widely used and IMAP is almost eliminated the most important reason. 4th chapter. Implementation Scenarios
Id |
Protocol |
Captured contents |
User name |
Password |
Sender |
Receiver |
Subject |
Contents |
Attachments |
5 |
POP3 |
√ |
√ |
√ |
√ |
√ |
√ |
|
Table 2 POP3 Analysis Requirements
Table 2 shows the requirements for protocol analysis. It is easy to see that it is easier to get the individual fields. We can crawl client-server interaction information, and then extract the fields we want based on each command word or response word. For example, to get the user name, for clear text authentication, we only need to detect the user at this time of the client's send message, and then extract the parameters after the user command. It is necessary to note that while the information that the client interacts with the server may be encoded or encrypted, we can still decode or decrypt it to obtain the required information. 5th Chapter. References
[1] RFC document: RFC1939 corresponds to POP3 protocol, RFC821 corresponds to the SMTP protocol, RFC822 corresponding mail standards, RFC1425 corresponding esmtp,rfc1522 corresponding to the extension of the header, RFC1521 corresponding message body extension
[2] http://www.faqs.org/rfcs/, with full English RFC documentation
[3] http://www.cnpaf.net/, there are many useful protocol analysis documents, there are Chinese RFC documents, but the quality is not particularly high
[4] Stevens, W.R, TCP/IP illustrated, Vol1. Addision-wesley, mechanical industry Press, 2002