RFC 821 SIMPLE MAIL TRANSFER P

RFC 821

SIMPLE MAIL TRANSFER PROTOCOL

Jonathan B. Postel

August 1982

Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291

(213) 822-1511

RFC 821 August 1982
Simple Mail Transfer Protocol

TABLE OF CONTENTS

1. INTRODUCTION .................................................. 1

2. THE SMTP MODEL ................................................ 2

3. THE SMTP PROCEDURE ............................................ 4

3.1. Mail ..................................................... 4
3.2. Forwarding ............................................... 7
3.3. Verifying and Expanding .................................. 8
3.4. Sending and Mailing ..................................... 11
3.5. Opening and Closing ..................................... 13
3.6. Relaying ................................................ 14
3.7. Domains ................................................. 17
3.8. Changing Roles .......................................... 18

4. THE SMTP SPECIFICATIONS ...................................... 19

4.1. SMTP Commands ........................................... 19
4.1.1. Command Semantics ..................................... 19
4.1.2. Command Syntax ........................................ 27
4.2. SMTP Replies ............................................ 34
4.2.1. Reply Codes by Function Group ......................... 35
4.2.2. Reply Codes in Numeric Order .......................... 36
4.3. Sequencing of Commands and Replies ...................... 37
4.4. State Diagrams .......................................... 39
4.5. Details ................................................. 41
4.5.1. Minimum Implementation ................................ 41
4.5.2. Transparency .......................................... 41
4.5.3. Sizes ................................................. 42

APPENDIX A: TCP ................................................. 44
APPENDIX B: NCP ................................................. 45
APPENDIX C: NITS ................................................ 46
APPENDIX D: X.25 ................................................ 47
APPENDIX E: Theory of Reply Codes ............................... 48
APPENDIX F: Scenarios ........................................... 51

GLOSSARY ......................................................... 64

REFERENCES ....................................................... 67

Network Working Group J. Postel
Request for Comments: DRAFT ISI
Replaces: RFC 788, 780, 772 August 1982

SIMPLE MAIL TRANSFER PROTOCOL

1. INTRODUCTION

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
mail reliably and efficiently.

SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. Appendices A,
B, C, and D describe the use of SMTP with various transport services.
A Glossary provides the definitions of terms as used in this
document.

An important feature of SMTP is its capability to relay mail across
transport service environments. A transport service provides an
interprocess communication environment (IPCE). An IPCE may cover one
network, several networks, or a subset of a network. It is important
to realize that transport systems (or IPCEs) are not one-to-one with
networks. A process can communicate directly with another process
through any mutually known IPCE. Mail is an application or use of
interprocess communication. Mail can be communicated between
processes in different IPCEs by relaying through a process connected
to two (or more) IPCEs. More specifically, mail can be relayed
between hosts on different transport systems by a host on both
transport systems.

Postel [Page 1]

August 1982 RFC 821
Simple Mail Transfer Protocol

2. THE SMTP MODEL

The SMTP design is based on the following model of communication: as
the result of a user mail request, the sender-SMTP establishes a
two-way transmission channel to a receiver-SMTP. The receiver-SMTP
may be either the ultimate destination or an intermediate. SMTP
commands are generated by the sender-SMTP and sent to the
receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
sender-SMTP in response to the commands.

Once the transmission channel is established, the SMTP-sender sends a
MAIL command indicating the sender of the mail. If the SMTP-receiver
can accept mail it responds with an OK reply. The SMTP-sender then
sends a RCPT command identifying a recipient of the mail. If the
SMTP-receiver can accept mail for that recipient it responds with an
OK reply; if not, it responds with a reply rejecting that recipient
(but not the whole mail transaction). The SMTP-sender and
SMTP-receiver may negotiate several recipients. When the recipients
have been negotiated the SMTP-sender sends the mail data, terminating
with a special sequence. If the SMTP-receiver successfully processes
the mail data it responds with an OK reply. The dialog is purposely
lock-step, one-at-a-time.

-------------------------------------------------------------

+----------+ +----------+
+------+ | | | |
| User || | SMTP | |
+------+ | Sender- |Commands/Replies| Receiver-|
+------+ | SMTP || SMTP | +------+
| File || | and Mail | || File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+

Sender-SMTP Receiver-SMTP

Model for SMTP Use

Figure 1

-------------------------------------------------------------

The SMTP provides mechanisms for the transmission of mail; directly
from the sending user's host to the receiving user's host when the

[Page 2] Postel

RFC 821 August 1982
Simple Mail Transfer Protocol

two host are connected to the same transport service, or via one or
more relay SMTP-servers when the source and destination hosts are not
connected to the same transport service.

To be able to provide the relay capability the SMTP-server must be
supplied with the name of the ultimate destination host as well as
the destination mailbox name.

The argument to the MAIL command is a reverse-path, which specifies
who the mail is from. The argument to the RCPT command is a
forward-path, which specifies who the mail is to. The forward-path
is a source route, while the reverse-path is a return route (which
may be used to return a message to the sender when an error occurs
with a relayed message).

When the same message is sent to multiple recipients the SMTP
encourages the transmission of only one copy of the data for all the
recipients at the same destination host.

The mail commands and replies have a rigid syntax. Replies also have
a numeric code. In the following, examples appear which use actual
commands and replies. The complete lists of commands and replies
appears in Section 4 on specifications.

Commands and replies are not case sensitive. That is, a command or
reply word may be upper case, lower case, or any mixture of upper and
lower case. Note that this is not true of mailbox user names. For
some hosts the user name is case sensitive, and SMTP implementations
must take case to preserve the case of user names as they appear in
mailbox arguments. Host names are not case sensitive.

Commands and replies are composed of characters from the ASCII
character set [1]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.

When specifying the general form of a command or reply, an argument
(or special symbol) will be denoted by a meta-linguistic variable (or
constant), for example, "" or "". Here the
angle brackets indicate these are meta-linguistic variabl

RFC 821
 
 
 
 
 
 SIMPLE MAIL TRANSFER PROTOCOL
 
 
 
 Jonathan B. Postel

August 1982
 
 
 
 Information Sciences Institute
 University of Southern California
 4676 Admiralty Way
 Marina del Rey, California 90291

(213) 822-1511

RFC 821 August 1982
 Simple Mail Transfer Protocol

TABLE OF CONTENTS

1. INTRODUCTION .................................................. 1

2. THE SMTP MODEL ................................................ 2

3. THE SMTP PROCEDURE ............................................ 4

3.1. Mail ..................................................... 4
 3.2. Forwarding ............................................... 7
 3.3. Verifying and Expanding .................................. 8
 3.4. Sending and Mailing ..................................... 11
 3.5. Opening and Closing ..................................... 13
 3.6. Relaying ................................................ 14
 3.7. Domains ................................................. 17
 3.8. Changing Roles .......................................... 18

4. THE SMTP SPECIFICATIONS ...................................... 19

4.1. SMTP Commands ........................................... 19
 4.1.1. Command Semantics ..................................... 19
 4.1.2. Command Syntax ........................................ 27
 4.2. SMTP Replies ............................................ 34
 4.2.1. Reply Codes by Function Group ......................... 35
 4.2.2. Reply Codes in Numeric Order .......................... 36
 4.3. Sequencing of Commands and Replies ...................... 37
 4.4. State Diagrams .......................................... 39
 4.5. Details ................................................. 41
 4.5.1. Minimum Implementation ................................ 41
 4.5.2. Transparency .......................................... 41
 4.5.3. Sizes ................................................. 42

APPENDIX A: TCP ................................................. 44
 APPENDIX B: NCP ................................................. 45
 APPENDIX C: NITS ................................................ 46
 APPENDIX D: X.25 ................................................ 47
 APPENDIX E: Theory of Reply Codes ............................... 48
 APPENDIX F: Scenarios ........................................... 51

GLOSSARY ......................................................... 64

REFERENCES ....................................................... 67

Network Working Group J. Postel
Request for Comments: DRAFT ISI
Replaces: RFC 788, 780, 772 August 1982

SIMPLE MAIL TRANSFER PROTOCOL

1. INTRODUCTION

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
 mail reliably and efficiently.

SMTP is independent of the particular transmission subsystem and
 requires only a reliable ordered data stream channel. Appendices A,
 B, C, and D describe the use of SMTP with various transport services.
 A Glossary provides the definitions of terms as used in this
 document.

An important feature of SMTP is its capability to relay mail across
 transport service environments. A transport service provides an
 interprocess communication environment (IPCE). An IPCE may cover one
 network, several networks, or a subset of a network. It is important
 to realize that transport systems (or IPCEs) are not one-to-one with
 networks. A process can communicate directly with another process
 through any mutually known IPCE. Mail is an application or use of
 interprocess communication. Mail can be communicated between
 processes in different IPCEs by relaying through a process connected
 to two (or more) IPCEs. More specifically, mail can be relayed
 between hosts on different transport systems by a host on both
 transport systems.

Postel [Page 1]

August 1982 RFC 821
Simple Mail Transfer Protocol

2. THE SMTP MODEL

The SMTP design is based on the following model of communication: as
 the result of a user mail request, the sender-SMTP establishes a
 two-way transmission channel to a receiver-SMTP. The receiver-SMTP
 may be either the ultimate destination or an intermediate. SMTP
 commands are generated by the sender-SMTP and sent to the
 receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
 sender-SMTP in response to the commands.

Once the transmission channel is established, the SMTP-sender sends a
 MAIL command indicating the sender of the mail. If the SMTP-receiver
 can accept mail it responds with an OK reply. The SMTP-sender then
 sends a RCPT command identifying a recipient of the mail. If the
 SMTP-receiver can accept mail for that recipient it responds with an
 OK reply; if not, it responds with a reply rejecting that recipient
 (but not the whole mail transaction). The SMTP-sender and
 SMTP-receiver may negotiate several recipients. When the recipients
 have been negotiated the SMTP-sender sends the mail data, terminating
 with a special sequence. If the SMTP-receiver successfully processes
 the mail data it responds with an OK reply. The dialog is purposely
 lock-step, one-at-a-time.

-------------------------------------------------------------

+----------+ +----------+
 +------+ | | | |
 | User || | SMTP | |
 +------+ | Sender- |Commands/Replies| Receiver-|
 +------+ | SMTP || SMTP | +------+
 | File || | and Mail | || File |
 |System| | | | | |System|
 +------+ +----------+ +----------+ +------+

Sender-SMTP Receiver-SMTP

Model for SMTP Use

Figure 1

-------------------------------------------------------------

The SMTP provides mechanisms for the transmission of mail; directly
 from the sending user's host to the receiving user's host when the

[Page 2] Postel

RFC 821 August 1982
 Simple Mail Transfer Protocol

two host are connected to the same transport service, or via one or
 more relay SMTP-servers when the source and destination hosts are not
 connected to the same transport service.

To be able to provide the relay capability the SMTP-server must be
 supplied with the name of the ultimate destination host as well as
 the destination mailbox name.

The argument to the MAIL command is a reverse-path, which specifies
 who the mail is from. The argument to the RCPT command is a
 forward-path, which specifies who the mail is to. The forward-path
 is a source route, while the reverse-path is a return route (which
 may be used to return a message to the sender when an error occurs
 with a relayed message).

When the same message is sent to multiple recipients the SMTP
 encourages the transmission of only one copy of the data for all the
 recipients at the same destination host.

The mail commands and replies have a rigid syntax. Replies also have
 a numeric code. In the following, examples appear which use actual
 commands and replies. The complete lists of commands and replies
 appears in Section 4 on specifications.

Commands and replies are not case sensitive. That is, a command or
 reply word may be upper case, lower case, or any mixture of upper and
 lower case. Note that this is not true of mailbox user names. For
 some hosts the user name is case sensitive, and SMTP implementations
 must take case to preserve the case of user names as they appear in
 mailbox arguments. Host names are not case sensitive.

Commands and replies are composed of characters from the ASCII
 character set [1]. When the transport service provides an 8-bit byte
 (octet) transmission channel, each 7-bit character is transmitted
 right justified in an octet with the high order bit cleared to zero.

When specifying the general form of a command or reply, an argument
 (or special symbol) will be denoted by a meta-linguistic variable (or
 constant), for example, "" or "". Here the
 angle brackets indicate these are meta-linguistic variabl

0/5000

Từ: -

Sang: -

Kết quả (Việt) 1: [Sao chép]

Sao chép!

RFC 821 SIMPLE MAIL TRANSFER PROTOCOL Jonathan B. Postel Tháng 8 năm 1982 Viện khoa học thông tin University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 (213) 822-1511 RFC 821 tháng tám 1982 Simple Mail Transfer Protocol BẢNG NỘI DUNG 1. INTRODUCTION .................................................. 1 2. THE SMTP MODEL ................................................ 2 3. THỦ TỤC SMTP... 4 3.1. Mail ..................................................... 4 3.2. Forwarding ............................................... 7 3.3. xác minh và mở rộng... 8 3.4. gửi và gửi thư... 11 3.5. mở và đóng cửa... 13 3.6. Relaying ................................................ 14 3.7. Domains ................................................. 17 3.8. thay đổi vai trò... 18 4. CÁC THÔNG SỐ KỸ THUẬT SMTP... 19 4.1. SMTP lệnh... 19 4.1.1. lệnh ngữ nghĩa... 19 4.1.2. lệnh cú pháp... 27 4.2. SMTP trả lời... 34 4.2.1. trả lời mã bởi chức năng nhóm... 35 4.2.2. Reply Codes in Numeric Order .......................... 36 4.3. Sequencing of Commands and Replies ...................... 37 4.4. State Diagrams .......................................... 39 4.5. Details ................................................. 41 4.5.1. Minimum Implementation ................................ 41 4.5.2. Transparency .......................................... 41 4.5.3. Sizes ................................................. 42 APPENDIX A: TCP ................................................. 44 APPENDIX B: NCP ................................................. 45 APPENDIX C: NITS ................................................ 46 APPENDIX D: X.25 ................................................ 47 APPENDIX E: Theory of Reply Codes ............................... 48 APPENDIX F: Scenarios ........................................... 51 GLOSSARY ......................................................... 64 REFERENCES ....................................................... 67Network Working Group J. PostelRequest for Comments: DRAFT ISIReplaces: RFC 788, 780, 772 August 1982 SIMPLE MAIL TRANSFER PROTOCOL1. INTRODUCTION The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Appendices A, B, C, and D describe the use of SMTP with various transport services. A Glossary provides the definitions of terms as used in this document. An important feature of SMTP is its capability to relay mail across transport service environments. A transport service provides an interprocess communication environment (IPCE). An IPCE may cover one network, several networks, or a subset of a network. It is important to realize that transport systems (or IPCEs) are not one-to-one with networks. A process can communicate directly with another process through any mutually known IPCE. Mail is an application or use of interprocess communication. Mail can be communicated between processes in different IPCEs by relaying through a process connected to two (or more) IPCEs. More specifically, mail can be relayed between hosts on different transport systems by a host on both transport systems.Postel [Page 1] August 1982 RFC 821Simple Mail Transfer Protocol 2. THE SMTP MODEL The SMTP design is based on the following model of communication: as the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP. The receiver-SMTP may be either the ultimate destination or an intermediate. SMTP commands are generated by the sender-SMTP and sent to the receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in response to the commands. Once the transmission channel is established, the SMTP-sender sends a MAIL command indicating the sender of the mail. If the SMTP-receiver can accept mail it responds with an OK reply. The SMTP-sender then sends a RCPT command identifying a recipient of the mail. If the SMTP-receiver can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The SMTP-sender and SMTP-receiver may negotiate several recipients. When the recipients have been negotiated the SMTP-sender sends the mail data, terminating with a special sequence. If the SMTP-receiver successfully processes the mail data it responds with an OK reply. The dialog is purposely lock-step, one-at-a-time. ------------------------------------------------------------- +----------+ +----------+ +------+ | | | | | User |<-->| | SMTP | | +------+ | Sender- |Commands/Replies| Receiver-| +------+ | SMTP |<-------------->| SMTP | +------+ | File |<-->| | and Mail | |<-->| File | |System| | | | | |System| +------+ +----------+ +----------+ +------+ Sender-SMTP Receiver-SMTP Model for SMTP Use Figure 1 ------------------------------------------------------------- The SMTP provides mechanisms for the transmission of mail; directly from the sending user's host to the receiving user's host when the[Page 2] Postel RFC 821 August 1982 Simple Mail Transfer Protocol two host are connected to the same transport service, or via one or more relay SMTP-servers when the source and destination hosts are not connected to the same transport service. To be able to provide the relay capability the SMTP-server must be supplied with the name of the ultimate destination host as well as the destination mailbox name. The argument to the MAIL command is a reverse-path, which specifies who the mail is from. The argument to the RCPT command is a forward-path, which specifies who the mail is to. The forward-path is a source route, while the reverse-path is a return route (which may be used to return a message to the sender when an error occurs with a relayed message). When the same message is sent to multiple recipients the SMTP encourages the transmission of only one copy of the data for all the recipients at the same destination host. The mail commands and replies have a rigid syntax. Replies also have a numeric code. In the following, examples appear which use actual commands and replies. The complete lists of commands and replies appears in Section 4 on specifications. Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive. Commands and replies are composed of characters from the ASCII character set [1]. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted right justified in an octet with the high order bit cleared to zero.
When specifying the general form of a command or reply, an argument
(or special symbol) will be denoted by a meta-linguistic variable (or
constant), for example, "" or "". Here the
angle brackets indicate these are meta-linguistic variabl

đang được dịch, vui lòng đợi..

Kết quả (Việt) 2:[Sao chép]

Sao chép!

RFC 821 Simple Mail Transfer Protocol Jonathan B. Postel tháng 8 năm 1982 Khoa học Thông tin Viện Đại học Nam California 4676 Admiralty Way Marina del Rey, California 90.291

(213) 822-1511(213) 822-1511

RFC 821 Tháng 8 năm 1982
Simple Mail Transfer Nghị định thư MỤC LỤC 1. GIỚI THIỆU ................................................. . 1 2. THE SMTP MODEL ........................................... ..... 2 3. CÁC THỦ TỤC SMTP ....................................... ..... 4 3.1. Thư ................................................. .... 4 3.2. Chuyển tiếp ............................................... 7 3.3 . Xác minh và mở rộng .................................. 8 3.4. Gửi và nhận thư ..................................... 11 3.5. Lễ khai mạc và bế mạc ..................................... 13 3.6. Chuyển tiếp ................................................ 14 3.7. Tên miền ................................................. 17 3.8. Thay đổi vai trò .......................................... 18 4. CÁC ĐẶC SMTP ...................................... 19 4.1. SMTP lệnh ........................................... 19 4.1.1. Lệnh Semantics ..................................... 19 4.1.2. Cú pháp lệnh ........................................ 27 4.2. SMTP Trả lời ............................................ 34 4.2.1 . Trả lời Codes bởi Nhóm chức năng ......................... 35 4.2.2. Trả lời Codes trong Numeric tự .......................... 36 4.3. Trình tự các lệnh và trả lời ...................... 37 4.4. Sơ đồ nhà nước .......................................... 39 4.5. Chi tiết ................................................. 41 4.5.1. Thực hiện tối thiểu ................................ 41 4.5.2. Minh bạch .......................................... 41 4.5.3. Kích thước ................................................. 42 PHỤ LỤC A: TCP ............................................. .... 44 PHỤ LỤC B: NCP ......................................... ........ 45 PHỤ LỤC C: nits ..................................... ........... 46 PHỤ LỤC D: X.25 ................................ ................ 47 PHỤ LỤC E: Lý thuyết Trả lời Codes .......................... ..... 48 PHỤ LỤC F: Các kịch bản ........................................ ... 51 CHÚ GIẢI ............................................. ............ 64 THAM KHẢO .................................... ................... 67 Nhóm công tác Mạng lưới J. Postel Yêu cầu Bình luận: DỰ THẢO ISI Thay thế: RFC 788, 780, 772 tháng 8 năm 1982 MAIL CHUYỂN GIAO GIẢN ĐƠN PROTOCOL 1. GIỚI THIỆU Mục tiêu của Simple Mail Transfer Protocol (SMTP) là để chuyển email đáng tin cậy và hiệu quả. SMTP là độc lập của các hệ thống phụ truyền đặc biệt và chỉ đòi hỏi một đáng tin cậy ra lệnh dữ liệu dòng kênh. Phụ lục A, B, C, D và mô tả việc sử dụng SMTP với dịch vụ vận tải khác nhau. Một điển cung cấp các định nghĩa các thuật ngữ được sử dụng trong này tài liệu. Một tính năng quan trọng của SMTP là khả năng của nó để chuyển tiếp mail trên môi trường dịch vụ vận tải. Một dịch vụ vận tải cung cấp một môi trường truyền thông interprocess (IPCE). Một IPCE có thể bao gồm một mạng lưới, một số mạng, hoặc một tập hợp con của một mạng. Điều quan trọng là nhận ra rằng hệ thống giao thông (hoặc IPCEs) không phải là một-đối-một với mạng. Một quá trình có thể giao tiếp trực tiếp với các quá trình khác thông qua bất kỳ IPCE cùng biết. Mail là một ứng dụng hoặc sử dụng thông tin liên lạc interprocess. Mail có thể được trao đổi giữa các quá trình trong IPCEs khác nhau bằng cách chuyển tiếp thông qua một quá trình kết nối hai (hoặc nhiều hơn) IPCEs. Cụ thể hơn, mail có thể được chuyển tiếp giữa các host trên các hệ thống giao thông vận tải khác nhau bởi một máy chủ trên cả hai hệ thống giao thông. Postel [Trang 1] Tháng 8 năm 1982 RFC 821 Simple Mail Transfer Protocol 2. MÔ HÌNH SMTP SMTP được thiết kế dựa trên mô hình sau đây của thông tin liên lạc: là kết quả của một yêu cầu thư cho người, người gửi-SMTP thiết lập một kênh truyền dẫn hai chiều với một máy thu-SMTP. Các thu-SMTP có thể là điểm đến cuối cùng hoặc trung gian. SMTP lệnh được tạo ra bởi người gửi-SMTP và gửi cho thu-SMTP. Trả lời SMTP được gửi từ máy thu-SMTP để gửi-SMTP để đáp ứng với các lệnh. Một khi các kênh truyền dẫn được thiết lập, SMTP, người gửi sẽ gửi một lệnh MAIL chỉ người gửi mail. Nếu SMTP-receiver có thể chấp nhận thư nó phản ứng với một thư trả lời OK. SMTP-người gửi sau đó gửi một lệnh RCPT xác định một người nhận mail. Nếu SMTP-receiver có thể chấp nhận thư cho người nhận rằng nó đáp ứng với một bài trả lời OK; nếu không, nó trả lời bằng một câu trả lời từ chối mà người nhận (nhưng không phải là toàn bộ giao dịch mail). SMTP-người gửi và SMTP-receiver có thể đàm phán nhiều người nhận. Khi người nhận đã được đàm phán SMTP-người gửi gửi dữ liệu mail, chấm dứt với một trình tự đặc biệt. Nếu SMTP-receiver xử lý thành công dữ liệu mail của nó phản ứng với một thư trả lời OK. Hộp thoại là cố khóa bước, một-at-a-thời gian. ---------------------------------- --------------------------- + ---------- + + ---------- + + ------ + | | | | | tài khoản | <-> | | SMTP | | + ------ + | Sender- | Commands / Trả lời | Receiver- | + ----- - + | SMTP | <--------------> | SMTP | + ------ + | File | <-> | | và Mail | | <-> | tập | | Hệ thống | | | | | | System | + ------ + + + ---------- + ---------- + + ----- - + Sender-SMTP Receiver-SMTP Mô hình sử dụng SMTP Hình 1 ------------------------------------ ------------------------- SMTP cung cấp cơ chế cho việc truyền tải mail; trực tiếp từ máy chủ của người dùng gửi đến máy chủ của người dùng nhận được khi [Trang 2] Postel RFC 821 Tháng 8 năm 1982 Simple Mail Transfer Protocol hai máy chủ được kết nối với các dịch vụ vận tải như nhau, hoặc thông qua một hoặc nhiều SMTP relay-server khi nguồn và đích host không được kết nối với các dịch vụ vận tải tương tự. Để có thể cung cấp khả năng chuyển tiếp SMTP-server phải được cung cấp với tên của các máy chủ đích đến cuối cùng cũng như tên hộp thư đến. Đối số cho lệnh MAIL là một đảo ngược -path, trong đó xác định người thư từ. Đối số cho lệnh RCPT là một con đường phía trước, trong đó xác định ai là mail là. Phía trước con đường là một tuyến đường nguồn, trong khi ngược lại con đường là một con đường trở lại (mà có thể được sử dụng để trả lại một thông điệp cho người gửi khi một lỗi xảy ra với một tin nhắn chuyển tiếp). Khi cùng một thông điệp được gửi tới nhiều người những SMTP khuyến khích việc truyền tải chỉ có một bản sao của dữ liệu cho tất cả các người nhận ở máy đích tương tự. Các lệnh mail và trả lời có một cú pháp cứng nhắc. Trả lời cũng có một mã số. Trong phần tiếp theo, ví dụ xuất hiện mà sử dụng thực tế các lệnh và trả lời. Các danh sách đầy đủ các lệnh và trả lời xuất hiện trong phần 4 trên thông số kỹ thuật. lệnh và trả lời không được trường hợp nhạy cảm. Đó là một lệnh hoặc trả lời từ có thể được trường hợp trên, trường hợp thấp hơn, hoặc bất kỳ hỗn hợp trên và trường hợp thấp hơn. Lưu ý rằng điều này là không đúng sự thật của tên người dùng hộp thư. Đối với một số máy chủ tên người dùng là trường hợp nhạy cảm, và triển khai SMTP phải trường hợp để bảo vệ trường hợp của tên người dùng như chúng xuất hiện trong hộp thư của đối số. Tên máy chủ không được trường hợp nhạy cảm. lệnh và trả lời bao gồm các ký tự từ ASCII ký tự [1]. Khi các dịch vụ vận tải cung cấp một 8-bit byte kênh truyền dẫn (octet), mỗi nhân vật 7-bit được truyền đúng hợp lý trong một octet với chút tự cao xóa không. Khi xác định hình thức chung của một lệnh hoặc trả lời, một cuộc tranh cãi (hoặc ký hiệu đặc biệt) sẽ được biểu thị bằng một biến meta-ngôn ngữ (hoặc đổi), ví dụ, "

"Hoặc"". Ở đây,
dấu ngoặc nhọn chỉ là những variabl meta-ngôn ngữ

đang được dịch, vui lòng đợi..

Kết quả (Việt) 3:[Sao chép]

Sao chép!

đang được dịch, vui lòng đợi..

Các ngôn ngữ khác

Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.