SMTP protocol Specification (Chinese version)

Source: Internet
Author: User

Simple Mail Transfer Protocol (SMTP)

1. introduce

The goal of Simple Mail Transfer Protocol (SMTP) is to deliver mail reliably and efficiently, independent of the transport subsystem and requiring only one channel that guarantees the order in which the data cells are delivered. Appendices A,b,c and D describe the use of SMTP under different transport services. The terminology used in this document is also defined in the noun table.

An important feature of SMTP is its ability to relay mail in transit, which provides a interprocess communication environment (IPCE), which can include a network, several networks, or subnets of a network. It is important to understand that the delivery system (or IPCE) is not one-to-one. Processes may communicate directly with other processes through known ipce. A message is an application or interprocess communication. Messages can be routed across the network through processes connected to different ipce. More specifically, messages can be relayed through host relays on different networks.

2. SMTP model

The SMTP design is based on the following communication model: for mail requests to users, sending SMTP establishes a two-way delivery channel between receiving SMTP. The receiving SMTP can be the final receiver or intermediate transporter. SMTP commands are sent by the sending SMTP, received by receiving SMTP, and the response is transmitted in reverse.

Once the delivery channel is established, the SMTP sender sends the Mail command to indicate the sender of the message. If the SMTP recipient can receive the message, the OK answer is returned. The SMTP sender then issues the RCPT command to confirm that the message was received. If the SMTP recipient receives it, the OK answer is returned, and if it is not received, a reject receive answer is issued (but the entire message operation is not aborted), and the two sides will repeat so many times. When the recipient receives all the messages, they receive a special sequence, and if the recipient successfully processes the message, return the OK answer.


SMTP provides the mechanism for sending messages, and if the recipient is connected to the sender under the same transport service, the message can be delivered directly to the receiving host by the sender's host, or through a relay SMTP server when the two are not in the same delivery service. In order to be able to provide relay capabilities to an SMTP server, it must have the final destination host address and mailbox name.

The Mail command parameter is the reply path, which specifies where the message comes from, and the RCPT Command's argument is the forwarding path, which specifies where the message will go. The forward path is the source path, and the reply path is the return path (it is used to return the message when an error occurs).

When the same message is sent to a different recipient, SMTP encounters a problem of sending copies of the same data to different receivers, a strange syntax for mail commands and replies, and a numeric code for the answer. In the following example, you can see which of the actual commands and responses are used. Complete command and answer in section fourth.

Commands and answers are not case sensitive, that is, commands and answers can be uppercase, lowercase, or both, but this is not necessarily right for user mail names, because some hosts are sensitive to user name capitalization. In this way, the user mailbox name is preserved as initially in the SMTP implementation, and the host name is insensitive to capitalization.

Commands and replies consist of an ASCII alphabet, where the delivery service provides a 8-bit byte delivery channel, each 7-bit character is transferred correctly, and the highest bit is populated with 0. When you specify a generic command or answer format, the parameters are represented by some language-like strings, such as "" or "", where the angle brackets indicate that this is a language-like variable.


3. SMTP Process

This section provides some of the procedures in SMTP. The first one describes the basic send process (defined as the send operation). Down to describe forwarding mail forward, confirm mailbox name and extended mailing list, send to terminal and turn off swap. At the end of this section is a description of the interrupt, the mail domain. The examples in this section are just a sequence of commands and responses, as shown in Appendix F for a complete example.


3.1. MAIL


There are three steps in the SMTP send operation, which are given by the Mail command to the sender identity. A series or more RCPT commands follow, giving the recipient information, followed by the data command to list the content of the message sent, and the final message content indicator to confirm the operation.

The first step in the process is the Mail command,< reverse-path > includes the source mailbox.

MAIL from:

This command tells the receiver that a new send operation has begun, and resets all state tables and buffers. It gives a reverse path to return the error message. If the request is received, the receiver returns a OK response. Includes not only mailboxes, but the reverse routing of host and source mailboxes, the first of which is the host that sent the command.

The second step in the process is to send the RCPT command.

RCPT to:

This command gives the forward path identifier recipient, and if the command is received, the receiver returns a OK response and stores the forward path. If the receiver is unknown, the receiver returns a failure reply. This process may be repeated several times.

Not only the mail, it is the routing table for the host and destination mailboxes, where the first host is the host that receives the command.

The third step in the process is to send the data command.


If the command is received, the receiver returns a 354 intermediate answer and determines that the following lines are the contents of the letter. When the end of the letter is received and stored, the receiver sends a OK response. Because the message is sent on the delivery channel, you must indicate the end of the message so that the answer dialog can start again. SMTP indicates the end of the message's content by sending only a full period on the last line, and, on the receiving side, a process that is transparent to the user filters the symbol so that it does not affect the normal data.

Note: The message content includes the following prompts: Date, Subject, to, Cc, from.

The message content indicator confirms the message operation and informs the receiver that the data can be stored and sent again. If this command is received, the receiver returns a OK response. The data command fails only if the message operation is incomplete or the source is not valid.

The procedure described above is a send operation. These commands can only be used in the order listed above. The following example indicates the use of these commands in a send operation.


SMTP Process Example This example is the Jones,green and Brown of the BETA.ARPA host in the host's Smith Mail, where the host alpha is assumed to be directly connected to the host beta.

S:mail from:

r:250 OK


S:RCPT to:

r:250 OK


S:RCPT to:

r:550 No such user here


S:RCPT to:

r:250 OK



r:354 Start mail input; End With.

S:blah blah blah ...

S:.. Wait a minute


r:250 OK


This letter was received by the first two people, and the third person does not have a mailbox on this host.



3.2. Forwarding below is an example of some of the incorrect destination addresses, but the receiver knows the correct destination address. In these examples, one of the following answers should allow the sender to obtain the correct address.

251: The user is not local;

This response means that the recipient SMTP knows that the user's mailbox is on another host, and that it means that the correct steering path will be used in the future. Note that the host or user, or both, are different. The receiver is responsible for sending messages.

551: The user is not local, please try

This answer means that the receiving SMTP knows that the user's mailbox is on another host and that the correct forwarding path is used. Note that the host or user, or both, are different. The receiver refuses to receive the user's letter, and the sender must resend or return an error message to the original sender based on the information provided.

The following example shows the application of these responses.


Examples of forwarding


S:RCPT to:

r:251 User not local; Would forward to




S:RCPT to:

r:551 User not local; Please try



3.3. Recognition and extension

SMTP provides additional features for confirming user names and extending mailing lists. These features are completed by the Vref and EXPN commands, all with strings as arguments. For the Vref command, the string parameter refers to the user name, and the response to the command includes the user's name and the user's mailbox. For the expn command, the string parameter refers to the mailing list, with more than one response to the command, which includes the names of the users in all lists and their mailboxes.

"Username" is an unwanted item and it is deliberately added. If the host uses the Vref command and the EXPN command, the last local mailbox must provide the username so that it is acknowledged by the host. It is also allowed if the host chooses a different string as the user name.

In some hosts, the nominee of a mailbox list and a mailbox is unclear, since the general data structure may include two types of portals. If you want to send a confirmation of the mailing list, you should give a definite response. When this message is received, the host sends the message to all the addresses on the list, and if no response is received, the error is reported. For example, the ' is ' a mail list, not a user name. If the request is used to extend a user name, a determined response may be formed by returning a list that includes a name, and if no response is received, an error is reported. (For example, "This is a user name, not a mailing list").

In the case of multiple responses (usually for expn), each answer specifies a mailbox. In the case of vague requests, such as "VRFY Smith", the response of two Smith here must be "553 User ambiguous".

The confirmation of the user name is shown in the following example: Example 3:



Confirm User Name

S:vrfy Smith r:250 Fred Smith




S:vrfy Smith

r:251 User not local; Would forward to




S:vrfy Jones

r:550 String does not match anything.




S:vrfy Jones

r:551 User not local; Please try




S:vrfy Gourzenkyinplatz

r:553 User ambiguous.



The mailbox list requires multiple responses as shown in the following example:


Examples of extended mailing lists

S:EXPN Example-people

R:250-jon Postel

R:250-fred Fonebone

R:250-sam Q. Smith

R:250-quincy Smith < @USC-isif.>





S:EXPN executive-washroom-list

r:550 Access Denied to you.



The string command parameters for the Verf and EXPN commands cannot be restricted because of the different implementations. On some systems, the parameters of the EXPN command may be a file name that contains a mailing list, but there are many different file structures on the Internet.

The Vrfy and EXPN commands are not included in the minimum implementation, and when they are implemented, they do not require to be implemented between the routes.


3.4. Sending letters (mailing) and obtaining letters (sending)

The primary purpose of SMTP is to send a message to a user's mailbox. A similar function provided by some hosts is to send the message to the user's terminal (if the user is opening the terminal). Sending a message to a user's mailbox is referred to as a Send letter (mailing), and to a user terminal is called a Get letter (sending). Because the implementations of the two are very similar on some hosts, they are also placed in SMTP. However, obtaining a letter command is not available in the minimal implementation of SMTP. Users should have the ability to control the writing of information to the terminal. Most hosts allow users to accept or reject similar information.

The following three commands are defined to support the acquisition of a letter. They are used for mail commands rather than mail commands, which indicate the special meaning of receiving SMTP operations:


SEND from:


The Send command requires that the message content be delivered directly to the user terminal. If the user does not open the terminal (or does not receive terminal information), the 450 response returns a RCPT command. This operation succeeds if the information is sent successfully.


SOML from:


The Send or mail command requires that the content of the message be sent directly to the user's terminal (if the user is on the terminal). If the user is not on the terminal, the message content goes directly into the mailbox. If the message is sent to the user terminal or user's mailbox, the send operation is successful.


SAML from:


The Send and mail commands require that the message content be sent directly to the user terminal (if the user is on the terminal). In any case, the letter will enter the mailbox. If the letter enters the mailbox, the send operation succeeds.


The response for the Mail command is the same as the response for these commands.


3.5. Open and Close

When you open the delivery channel, exchange some information to determine the identity of both parties. The following commands are used to turn on and off:






In the Hello command, the host sends its own commands, which can be interpreted as: "Hello, I am xx".


Open the example of a join


r:220 Bbn-unix. ARPA simple Mail Transfer Service Ready

S:helo Usc-isif. Arpa

r:250 Bbn-unix. Arpa




Examples of closing joins



r:221 Bbn-unix. ARPA Service closing transmission channel



3.6. Forwarding

The forwarding path may be the following format: "@ONE, @TWO: Joe@three", where One,two and THREE are hosts. This format is used to emphasize the difference between addresses and paths. The mailbox is an absolute address and the path is information about how to get there. These two concepts should not be confused.

Conceptually, the elements of the forwarding path are moved to the reply path as information from one SMTP server to another SMTP server. The reply path is a reverse data source path, such as from the position of the current information to the location of the initiator. When an SMTP server deletes its own token from the forwarding path and inserts it into the reply path, it must use the name it sends to the environment to understand, in case its name is understood differently in different contexts.

If the first element of the forwarding path to which SMTP receives information is not a token for this SMTP, this element is not removed from the forwarding path and is used to determine the next SMTP server that should be sent to. In any case, SMTP adds its own markup to the reverse path.

When you use the source path, receive SMTP receives forwarded messages and sends them to another receiving SMTP server. The receiving server can accept or deny forwarding of mail to local users. Receive SMTP changes the command parameters by moving its own token from the forwarding path to the beginning of the reply path. At this point, the receive SMTP becomes sent SMTP, and the channel to SMTP in the next forwarding path is established, and then it sends mail to this SMTP.

The first host on the reply path should be the host that sent the SMTP command, and the primary host on the forwarding path should be the host that receives the SMTP command.

Note: the forwarding path and reply path appear in the SMTP command and answer, but do not necessarily appear in the message. That is, there are no paths that have to be this particular format appears in the "To:" and "From:" and "CC:" Fields of the message header.

If the SMTP server accepts a forwarding task, but it later finds that the forwarding path is incorrect or other principles fail to send the message, it must create a "undeliverable mail" signal to send it to the sender of the letter.

This signal must be sent from the SMTP service on this host and, of course, the server should not report error messages. One way to prevent this error reporting loop is to empty the reply path of the message command for the signal. When this information is passed, the reply path is allowed to be empty as well. The reply path after a mail command is null and behaves as follows:

MAIL from:<>

The following example shows the message information that is not delivered. This information is a response to a message that was sent from Joe on the HOSTW when the HOSTX required Hostz to reach Hosty. The examples we have seen are between HOSTX and Hosty.



Examples of non-shipping message information


S:mail from:<>

r:250 OK

S:RCPT to:< @HOSTX. Arpa:joe@host

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.