rfc3502.Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension

Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。

rfc协议RFC (Request for Comments)协议是互联网工程任务组（IETF）发布的一系列文件，它描述了互联网的各种协议、技术和标准。

RFC文档由IETF的成员和其他网络专业人士撰写，并经过同行审查后发布。

本文将对RFC协议进行简要介绍。

RFC协议的历史可以追溯到1969年，当时互联网的前身ARPANET刚刚建立，人们需要一个组织用于记录和交流互联网的相关协议。

随着时间的推移，RFC协议逐渐成为互联网标准发展的重要组成部分。

RFC协议的目的是促进全球范围内的技术合作和共享。

它提供了一种开放的、民主的方法，使任何人都可以参与到互联网协议的发展过程中来。

RFC协议的草案可以由任何人提交。

一旦提交，草案将经过同行审查，并由IETF进行讨论和投票，最终形成正式的RFC文档。

RFC协议的内容非常丰富，涵盖了从网络协议到应用程序的各个方面。

其中一些最著名的RFC文档包括TCP/IP协议族、HTTP协议、SMTP协议等。

RFC文档的编写方式相对自由，作者可以使用他们认为合适的格式和语言进行描述。

但是，RFC文档必须包含一些必要的内容，如标题、摘要、问题陈述、解决方案、安全考虑等。

这些要求确保了RFC文档的一致性和可读性。

RFC协议的发布对互联网的发展起到了重要的推动作用。

它促进了网络标准的制定和统一，使得不同厂商的设备能够互相通信，从而实现了互联网的互联互通。

同时，RFC协议的开放性也鼓励了创新和技术发展，使互联网能够不断适应新的需求和挑战。

总之，RFC协议是互联网发展的重要支撑和推动力量。

它通过开放、民主的方式推动着互联网的各个方面的发展，使得互联网成为了一个全球范围内的共享资源。

在未来的发展中，RFC协议将继续发挥其作用，推动互联网技术的创新和进步。

網絡名詞釋義IP 網際協議 Internet Protocol,(RFC-791) ICMP 網際報文控製協議 Internet Control Message Protocol,(RFC-792) IGMP 網際成組多路廣播協議 Internet Group Multicast Protocol,(RFC-1112) UDP 用戶數據報協議 User Datagram Protocol,(RFC-768) TCP 傳輸控製協議 Transmission Control Protocol,(RFC-793) TELNET Telnet協議 Telnet Protocol,(RFC-854,855) FTP 文件傳輸協議 File Transfer Protocol,(RFC-959) SMTP 簡單郵件傳輸協議 Simple Mail Transfer Protocol,(RFC-821) SMTP-SIZE 可處理大信包的擴充的SMTP協議 SMTP Service Ext for Message Size,(RFC-1870) SMTP-EXT SMTP協議擴充 SMTP Service Extensions,(RFC-1869) NTPV2 網絡時間協議版本2 Network Time Protocol (Version 2),(RFC-1119) SNMP 簡單網絡管理協議 Simple Network Management Protocol,(RFC-1157) NETBIOS NetBIOS服務協議 NetBIOS Services Protocols,(RFC-1001,1002) ECHO 應答協議 Echo Protocol DISCARD 取消協議 Discard Protocol CHARGEN 字元發生器協議 Character Generator Protocol QUOTE 氣象報告協議 Quote of the Day Protocol USERS 當前用戶報告協議 Active Users Protocol DAYTIME 日期查詢協議 Daytime Protocol TIME 標準時間服務器協議 Time Server Protocol TFTP 測試用的文件傳輸協議 Trivial File Transfer Protocol TP-TCP 基於TCP的ISO傳輸層服務 ISO Transport Service on top of the TCP ETHER-MIB 乙太網管理資訊庫 Ether-MIB PPP 點對點協議 Point-to-Point Protocol PPP-HDLC HDLC分組的PPP協議 PPP in HDLC Framing IP-SMDS 基於SMDS服務的IP數據報 IP Datagram over the SMDS Service RIP 路由資訊協議 Routing Information Protocol ARP 地址解析協議 Address Resolution Protocol,(RFC-826) RARP 逆向地址解析協議 A Reverse Address Resolution Protocol,(RFC-903) POP3 電子郵局協議,版本3 Post Office Protocol,Version 3,(RFC-1725) HTTP 超文本傳輸協議 Hyper Text Transfer Protocol RPC 遠過程調用協議 Remote Procedure Call Protocol,(RFC-1831) NICNAME WhoIs協議 WhoIs Protocol,(RFC-954) DHCP 主機動態配置協議 Dynamic Host Configuration Protocol,(RFC-1541) NNTP 網絡新聞傳輸協議 Network News Transfer Protocol,(RFC-977) IARP 反向地址解析協議 Inverse Address Resolution Protocol,(RFC-1293) RAP 網際路由存取協議 Internet Route Access Protocol,(RFC-1476) IRCP 網際轉發的閑聊協議 Internet Relay Chat Protocol,(RFC-1459) RMCP 遠程郵件檢查協議 Remote Mail Checking Protocol,(RFC-1339) MTP 多路廣播傳輸協議 Multicast Transport Protocol,(RFC-1301) GOPHER 網際Gopher協議 The Internet Gopher Protocol,(RFC-1436) LISTSERV Listserv分佈協議 Listserv Distribute Protocol,(RFC-1429)Anonymous FTP 匿名FTP,當你在一個向公眾開放的服務器上下載一個文件時,一般不需向系統登記注冊,當被問到注冊名時,敲入Anonymous,而密碼則以你的郵編地址代替. Archie 在Internet各個FTP節點上查詢文件的一種程式. Browser 瀏覽器,一種可顯示或下載文件的計算機程式,如Netscape的Navigator和Microsoft的InternetExplorer. Cyberia 新興的電腦咖啡店,提供咖啡和電腦網絡服務. Dialup 利用電話線撥號上網的過程. Domain 域網絡區域等的劃分IRC Internet Relay Chat,在Internet上與其他用戶實時網上交談的系統. Ethernet 乙太網,世界上最廣泛使用的局域網類型,支援每秒10Mbits的傳輸速度,幾乎所有Internet上的局域網都是這種類型. Firewall 防火牆,Internet上用於防止外界入侵局域網的安全裝置. FTP File Transfer Protocal 文件傳輸協議,用於在Internet上傳輸文件. Gateway 網關,數據在不同系統間傳輸時,用以統一數據格式. IP Internet協議,定義了文件以一個計算機傳到另一個主機的方式,通常與另一個協議一起稱作TCP/IP. ISO 從事國際標準化的組織,批準其他組織製定的標準(例如︰IEEE和ITU-T)的國際標準化組織. ISP ISP是Internet服務的提供者,也是Internet訪問的提供者. ITU-T ITU-T是發展和批準遠程通信標準的國際標準化組織.它包括所有主要的PTT的代表. Kermit Kermit是一種流行的糾錯文件傳輸協議,主要用於BBS. MOO 下一代的MUD稱作MOO(面向對象的MUD).它們把所有的遊戲者都當作有一定能力的對象對待.在MOO中你通常可以設計你的性格. Mosaic Mosaic是第一個瀏覽器,是由美國國家超級計算機中心製作的.它真正開始了Web的流行. MUD 多用戶地牢是一個地方,經常是一個單個主機.在那個地方你能夠遇到其他人,通常殺死他們.本質上,在MUD的遊戲中,你裝扮成一個虛構的人在MUD的'房間'裡探險,聊天,拾東西,以及參與無原由的暴力.MUD通常由文本介面來訪問,而流行的MUD經常難以進入.在http://www.cisMulticast 多路廣播,是一種特殊的廣播類型,是為網上主機的用戶電話機預定的. Newsgroup Newsgroup是Internet的公告牌,有22000左右個組,幾乎覆蓋了每一個主題.決大部分的ISP(Internet提供商)和組織有一個新聞組服務器,它定期從網上別的新聞組收集新聞素材,所有新消息都是從這些素材中得來的.然後這些素材又會被傳送到另外的新聞組服務器.這些新聞NIC NIC是網絡資訊中心的縮寫.在Internet的早期,它是包含IP地址和功能變數名稱的中心站.現在有一些NIC分散在全世界. NMS 網絡管理站,監視網上所有節點如何執行命令的計算機. NNTP 網絡新聞傳輸協議,用於新聞組服務器之間交換新聞的協議,也是用於新聞瀏覽器與新聞組服務器之間的協議. NOC Internet服務商用來監視網絡錯誤的網絡操作中心. Node 節點,任何一個連到Internet上的設備(通常是指主機,但也包括網橋,路由器,網關等)都稱作節點.實際上,有IP地址的任何東西都是節點. OSI 開發系統互連,用來簡化各種型號計算機之間通訊的國際標準. Packet Packet是網絡上傳輸的一組數據.在Internet上,一個數據包由TCP/IP協議的IP部分組成.它必須包括原地址,目的地址,包的標識(這樣接收的計算機可以分辨包的種類)和一些數據. Ping Ping是一個用TCP/IP協議發送消息到主機的網絡介面,以查看它是否存在程式,這對於網絡糾錯很有用. POP3 一種電子郵件的傳輸協議.Port 這名詞用於定義進入一個單獨計算機不同類型數據的不同入口點,如23號口可能指定成遠程訪問,而21號口是FTP.現在大部分的軟件自動檢測口的號碼,埠也指在計算機上的物理輸入輸出孔. Protocol 協議本質上是兩個網絡設備都認同的相互通訊的方法.它定義了許多東西,包括它的包格式,它怎樣校驗,路由器怎樣處理它和如果一個數據包丟失將怎樣辦. PSTN 公共電話交換網,更普遍的說法是電話系統. PTT PTT指的是電話,傳真的郵寄委託給遍及全世界的公共電話系統操作者. RFC 注釋請求,一個文檔通常被IETF的工作組之一放出來,以抽取從其他有關部分來的應答和合法定義的技術.在ftp:///rfc有一個廣泛的所有FTP的有效RFC目錄. Router 路由器,互聯網工作環境的智慧部件.路由器把所有包含Internet的網絡連接起來,並在它們之間交換數據包.它也能算出將一個數據包送達目的地所需最快最便宜的路徑. Smillies 在新聞組和電子郵件中看到的標點法,它的旁邊把人類的概念加到你的消息後,如:高興 :-) 難過 :-( 驚訝 :-0. SMTP 簡單郵件傳輸協議──為了傳輸郵件的Internet協議. Spam 發送同樣的消息到多個新聞組的專用術語,讓人皺眉. UUCP Unix到Unix的複製程式,它允許一個基於Unix的主機從另一個基於Unix的主機複製文件. WAIS 廣域資訊服務器是一個資訊恢複系統,是由Apple,ThinkingMachines和Dow Jones開發的.它允許一個客戶機在多個在線數據庫上同時進行關鍵字查找. Winsock Winsock是Windows下的應用程式與網絡協議之間的標準介面.如果你想在Windows 下訪問Internet,你需要一個叫做Winsock.DLL的程式加載到你的Windows環境中.並非所有的軟件使用同樣版本的Winsock,這是最普遍出現問題的情況之一.WWW 萬維網,環球網,有時也稱作Web.這是所有Internet上基於超文本的相互連接,並可被HTTP或Web服務器訪問的HTML文檔的統稱.WWW是已經成為殺手應用程式,主宰著網絡的潮流.MAIL 電子郵件格式規範 Format of Electionic Mail Messages,(RFC-822)CONTENT 郵件內容類型域規範 Content Type Header Field,(RFC-1049)DOMAIN 功能變數名稱系統規範 Domain Name System,(RFC-1034,1035)DNS-MX 郵件路由與功能變數名稱系統規範 Mail Routing and the Domain System,(RFC-974)SMI 管理資訊結構規範 Structure of Management Information,(RFC-1155)Concise-MIB 簡明MIB規範 Concise MIB Definitions,(RFC-1212)MIB-II 管理資訊庫-2 Management Information Base-II,(RFC-1213)MIME 多用途網際郵件擴充規範 Multipurpose Internet Mail Extensions,(RFC-1521)HTML 超文本標記語言標準 Hypertext Markup Language-2.0,(RFC-1866)URL 通用資源定位符標準 Uniform Resource Locators,(RFC-1738)。

Network Working Group T. Showalter Request for Comments: 2971 Mirapoint, Inc. Category: Standards Track October 2000 IMAP4 ID extensionStatus of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved. AbstractThe ID extension to the Internet Message Access Protocol - Version4rev1 (IMAP4rev1) protocol allows the server and client to exchangeidentification information on their implementation in order to makebug reports and usage statistics more complete.1. IntroductionThe IMAP4rev1 protocol described in [IMAP4rev1] provides a method for accessing remote mail stores, but it provides no facility toadvertise what program a client or server uses to provide service.This makes it difficult for implementors to get complete bug reportsfrom users, as it is frequently difficult to know what client orserver is in use.Additionally, some sites may wish to assemble usage statistics basedon what clients are used, but in an an environment where users arepermitted to obtain and maintain their own clients this is difficultto accomplish.The ID command provides a facility to advertise information on whatprograms are being used along with contact information (should bugsever occur).Showalter Standards Track [Page 1]2. Conventions Used in this DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].The conventions used in this document are the same as specified in[IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by theclient and server respectively. Line breaks have been inserted forreadability.3. SpecificationThe sole purpose of the ID extension is to enable clients and servers to exchange information on their implementations for the purposes of statistical analysis and problem determination.This information is be submitted to a server by any client wishing to provide information for statistical purposes, provided the serveradvertises its willingness to take the information with the atom "ID" included in the list of capabilities returned by the CAPABILITYcommand.Implementations MUST NOT make operational changes based on the datasent as part of the ID command or response. The ID command is forhuman consumption only, and is not to be used in improving theperformance of clients or servers.This includes, but is not limited to, the following:Servers MUST NOT attempt to work around client bugs by usinginformation from the ID command. Clients MUST NOT attempt to work around server bugs based on the ID response.Servers MUST NOT provide features to a client or otherwiseoptimize for a particular client by using information from the ID command. Clients MUST NOT provide features to a server orotherwise optimize for a particular server based on the IDresponse.Servers MUST NOT deny access to or refuse service for a clientbased on information from the ID command. Clients MUST NOT refuse to operate or limit their operation with a server based on the ID response.Showalter Standards Track [Page 2]Rationale: It is imperative that this extension not supplant IMAP’sCAPABILITY mechanism with a ad-hoc approach where implementationsguess each other’s features based on who they claim to be.Implementations MUST NOT send false information in an ID command.Implementations MAY send less information than they have available or no information at all. Such behavior may be useful to preserve user privacy. See Security Considerations, section 7.3.1. ID CommandArguments: client parameter list or NILResponses: OPTIONAL untagged response: IDResult: OK identification information acceptedBAD command unknown or arguments invalidImplementation identification information is sent by the client with the ID command.This command is valid in any state.The information sent is in the form of a list of field/value pairs.Fields are permitted to be any IMAP4 string, and values are permitted to be any IMAP4 string or NIL. A value of NIL indicates that theclient can not or will not specify this information. The client may also send NIL instead of the list, indicating that it wants to sendno information, but would still accept a server response.The available fields are defined in section 3.3.Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor""Pink Floyd Music Limited")S: * ID NILS: a023 OK ID completed3.2. ID ResponseContents: server parameter listIn response to an ID command issued by the client, the server replies with a tagged response containing information on its implementation. The format is the same as the client list.Showalter Standards Track [Page 3]Example: C: a042 ID NILS: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos""os-version" "5.5" "support-url""mailto:cyrus-bugs+@")S: a042 OK ID command completedA server MUST send a tagged ID response to an ID command. However, a server MAY send NIL in place of the list.3.3. Defined Field ValuesAny string may be sent as a field, but the following are defined todescribe certain values that might be sent. Implementations are free to send none, any, or all of these. Strings are not case-sensitive. Field strings MUST NOT be longer than 30 octets. Value strings MUST NOT be longer than 1024 octets. Implementations MUST NOT send morethan 30 field-value pairs.name Name of the programversion Version number of the programos Name of the operating systemos-version Version of the operating systemvendor Vendor of the client/serversupport-url URL to contact for supportaddress Postal address of contact/vendordate Date program was released, specified as a date-time in IMAP4rev1command Command used to start the programarguments Arguments supplied on the command line, if anyif anyenvironment Description of environment, i.e., UNIX environment variables or Windows registry settingsImplementations MUST NOT use contact information to submit automatic bug reports. Implementations may include information from an IDresponse in a report automatically prepared, but are prohibited from sending the report without user authorization.It is preferable to find the name and version of the underlyingoperating system at runtime in cases where this is possible.Information sent via an ID response may violate user privacy. SeeSecurity Considerations, section 7.Implementations MUST NOT send the same field name more than once. Showalter Standards Track [Page 4]4. Formal SyntaxThis syntax is intended to augment the grammar specified in[IMAP4rev1] in order to provide for the ID command. Thisspecification uses the augmented Backus-Naur Form (BNF) notation asused in [IMAP4rev1].command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id;; adds id command to command_any in [IMAP4rev1]id ::= "ID" SPACE id_params_listid_response ::= "ID" SPACE id_params_listid_params_list ::= "(" #(string SPACE nstring) ")" / nil;; list of field value pairsresponse_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /mailbox_data / message_data / capability_data / id_response)5. Use of the ID extension with Firewalls and Other IntermediariesThere exist proxies, firewalls, and other intermediary systems thatcan intercept an IMAP session and make changes to the data exchanged in the session. Such intermediaries are not anticipated by the IMAP4 protocol design and are not within the scope of the IMAP4 standard.However, in order for the ID command to be useful in the presence of such intermediaries, those intermediaries need to take special noteof the ID command and response. In particular, if an intermediarychanges any part of the IMAP session it must also change the IDcommand to advertise its presence.A firewall MAY act to block transmission of specific informationfields in the ID command and response that it believes revealinformation that could expose a security vulnerability. However, afirewall SHOULD NOT disable the extension, when present, entirely,and SHOULD NOT unconditionally remove either the client or serverlist.Finally, it should be noted that a firewall, when handling aCAPABILITY response, MUST NOT allow the names of extensions to bereturned to the client that the firewall has no knowledge of. Showalter Standards Track [Page 5]6. References[KEYWORDS] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", RFC 2119, March 1997.[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, October 1996.[RFC-822] Crocker, D., "Standard for the Format of ARPA InternetText Messages", STD 11, RFC 822, August 1982.7. Security ConsiderationsThis extension has the danger of violating the privacy of users ifmisused. Clients and servers should notify users that they implement and enable the ID command.It is highly desirable that implementations provide a method ofdisabling ID support, perhaps by not sending ID at all, or by sending NIL as the argument to the ID command or response.Implementors must exercise extreme care in adding fields sent as part of an ID command or response. Some fields, including a processor ID number, Ethernet address, or other unique (or mostly unique)identifier allow tracking of users in ways that violate user privacy expectations.Having implementation information of a given client or server maymake it easier for an attacker to gain unauthorized access due tosecurity holes.Since this command includes arbitrary data and does not require theuser to authenticate, server implementations are cautioned to guardagainst an attacker sending arbitrary garbage data in order to fillup the ID log. In particular, if a server naively logs each IDcommand to disk without inspecting it, an attacker can simply fire up thousands of connections and send a few kilobytes of random data.Servers have to guard against this. Methods include truncatingabnormally large responses; collating responses by storing only asingle copy, then keeping a counter of the number of times thatresponse has been seen; keeping only particularly interesting partsof responses; and only logging responses of users who actually login.Security is affected by firewalls which modify the IMAP protocolstream; see section 5, Use of the ID Extension with Firewalls andOther Intermediaries, for more information.Showalter Standards Track [Page 6]8. Author’s AddressTim ShowalterMirapoint, Inc.909 Hermosa Ct.Sunnyvale, CA 94095EMail: tjs@Showalter Standards Track [Page 7]9. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Showalter Standards Track [Page 8]。

RFC821 简单邮件传输协议（SMTP）(RFC821 SIMPLE MAIL TRANSFER PROTOCOL)目录1. 介绍 22. SMTP模型 33. SMTP过程 43.1. MAIL 43.2. 转发 53.3. 确认和扩展 63.4. 发送信件(mailing)和获得信件(sending) 7 3.5. 打开和关闭73.6. 转发 83.7. 域93.8. 改变角色94. SMTP说明94.1. SMTP命令94.1.1. 命令语法94.1.2. COMMAND语法格式134.2. SMTP响应154.3. 命令和应答序列164.4. 状态图174.5. 详细内容184.5.1. 最小实现184.5.2. 透明性194.5.3. 大小19附录 A TCP传输服务19附录 B NCP传输服务20附录 C NITS 20附录 D X.25传输服务 20附录 E 应答码构成方法20附录 F 一些例子22参考资料361. 介绍简单邮件传输协议（SMTP）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。

附录A，B，C和D描述了不同传送服务下SMTP的使用。

在名词表中还定义了本文档中使用的术语。

SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境（IPCE），此环境可以包括一个网络，几个网络或一个网络的子网。

理解到传送系统（或IPCE）不是一对一的是很重要的。

进程可能直接和其它进程通过已知的IPCE通信。

邮件是一个应用程序或进程间通信。

邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。

更特别的是，邮件可以通过不同网络上的主机接力式传送。

2. SMTP模型SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。

接收SMTP可以是最终接收者也可以是中间传送者。

SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。

rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。

RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。

在本文中，我们将介绍RFC相关的设置和使用。

1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。

RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。

RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。

2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。

这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。

通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。

阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。

3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。

它们提供了协议规范、算法实现、安全性和隐私等方面的建议。

网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。

此外，RFC文档还常用于进行互联网协议的实现、编程和配置。

4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。

任何人都可以参与到RFC的制定过程中。

要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。

通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。

5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。

这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。

遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。

总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。

翻译者：MagicalbombPS：由于本人的英语水平很有限，并且精力有限，所以只翻译Section1-4，并且部分无力翻译的部分，提供了原版的英语。

并且比较多的地方翻译的不是很流畅。

但是即使是这样，若能够帮助到你，我也会非常高兴RFC：2822地址：https:///html/rfc2822.htmlObsoleted by: 5322 PROPOSED STANDARD Updated by: 5335, 5336 Errata ExistNetwork Working Group P. Resnick, EditorRequest for Comments: 2822 QUALCOMM Incorporated Obsoletes: 822Category: Standards Track--------------互联网信息格式(Internet Messsage Format)------------本备忘录的状态这个文档为互联网社区规范了互联网标准跟踪协议(Internet standards track protocol)，并且本文档希望能够得到大家的建议和讨论从而变得更加完善。

请参考当前的"Internet Official Protocol Standards"(STD 1) 。

为本备忘录做出贡献是没有限制的--Copyright NoticeCopyright (C) The Internet Society (2001). All Rights Reserved.--抽象它是一种语法，针对一个在多台计算机之间传输的电子邮件消息。

这个标准取代了RFC822中所提到的标准，“ARPA网中的标准消息格式”。

为了适应实际的情况和不断的变化，对于更新的本备忘录将会记载在其他的RFC中。

目录1. Introduction (3)1.1. Scope (3)1.2. Notational conventions (4)1.2.1. Requirements notation (4)1.2.2. Syntactic notation (4)1.3. Structure of this document (4)2. Lexical Analysis of Messages (5)2.1. General Description (5)2.1.1. Line Length Limits (6)2.2. Header Fields (7)2.2.1. Unstructured Header Field Bodies (7)2.2.2. Structured Header Field Bodies (7)2.2.3. Long Header Fields (7)2.3. Body (8)3. Syntax (9)3.1. Introduction (9)3.2. Lexical Tokens (9)Resnick Standards Track [Page 1] RFC 2822 Internet Message Format April 20013.2.1. Primitive Tokens (9)3.2.2. Quoted characters (10)3.2.3. Folding white space and comments (11)3.2.4. Atom (12)3.2.5. Quoted strings (13)3.2.6. Miscellaneous tokens (13)3.3. Date and Time Specification (14)3.4. Address Specification (15)3.4.1. Addr-spec specification (16)3.5 Overall message syntax (17)3.6. Field definitions (18)3.6.1. The origination date field (20)3.6.2. Originator fields (21)3.6.3. Destination address fields (22)3.6.4. Identification fields (23)3.6.5. Informational fields (26)3.6.6. Resent fields (26)3.6.7. Trace fields (28)3.6.8. Optional fields (29)4. Obsolete Syntax (29)4.1. Miscellaneous obsolete tokens (30)4.2. Obsolete folding white space (31)4.3. Obsolete Date and Time (31)4.4. Obsolete Addressing (33)4.5. Obsolete header fields (33)4.5.1. Obsolete origination date field (34)4.5.2. Obsolete originator fields (34)4.5.3. Obsolete destination address fields (34)4.5.4. Obsolete identification fields (35)4.5.5. Obsolete informational fields (35)4.5.6. Obsolete resent fields (35)4.5.7. Obsolete trace fields (36)4.5.8. Obsolete optional fields (36)5. Security Considerations (36)6. Bibliography (37)7. Editor's Address (38)8. Acknowledgements (39)Appendix A. Example messages (41)A.1. Addressing examples (41)A.1.1. A message from one person to another with simpleaddressing (41)A.1.2. Different types of mailboxes (42)A.1.3. Group addresses (43)A.2. Reply messages (43)A.3. Resent messages (44)A.4. Messages with trace fields (46)A.5. White space, comments, and other oddities (47)A.6. Obsoleted forms (47)Resnick Standards Track [Page 2]RFC 2822 Internet Message Format April 2001A.6.1. Obsolete addressing (48)A.6.2. Obsolete dates (48)A.6.3. Obsolete white space and comments (48)Appendix B. Differences from earlier standards (49)Appendix C. Notices (50)Full Copyright Statement (51)------------------------1. 介绍----------------------- 1.1. 讨论范围这个文档规范了互联网的消息格式（IMF），它是一种语法，针对一个在多台计算机之间传输的电子邮件消息。

Chapter I1. What is the difference between a host and an end system? List the types of endsystems. Is a Web server an end system?2. What is a client program? What is a server program? Does a server program requestand receive services from a client program?3. List six access technologies. Classify each one as residential access, companyaccess, or mobile access.4. Dial-up modems, HFC, and DSL are all used for residential access. For each ofthese access technologies, provide a range of transmission rates and comment on whether the transmission rate is shared or dedicated.5. Describe the most popular wireless Internet access technologies today. Compareand contrast them.6. What advantage does a circuit-switched network have over a packet-switchednetwork? What advantages does TDM have over FDM in a circuit-switched network?7. Consider sending a packet from a source host to a destination host over a fixedroute. List the delay components in the end-to-end delay. Which of these delays are constant and which are variable?8. How long does it take a packet of length 2,000 bytes to propagate over a linkof distance 2,000 km, propagation speed 8102⨯ m/s, and transmission rate 2 Mbps? More generally, how long does it take a packet of length L to propagate over a link of distance d, propagation speed s, and transmission rate R bps? Does this delay depend on packet length? Does this delay depend on transmission rate?9. What are the five layers in the Internet protocol stack? What are the principalresponsibilities of each of these layers?10. Which layers in the Internet protocol stack does a router process? Which layersdoes a link-layer switch process? Which layers does a host process?11. What is an application-layer message? A transport-layer segment? A network-layerdatagram? A link-layer frame?12. This elementary problem begins to explore propagation delay and transmissiondelay, two central concepts in data networking. Consider two hosts, A and B, connected by a single link of rate R bps. Suppose that the two hosts are separated by m meters, and suppose the propagation speed along the link is s meters/sec. Host A is to send a packet of size L bits to Host B.a. Express the propagation delay, prop d , in terms of m and s.b. Determine the transmission time of the packet,trans d , in terms of L and R.c. Ignoring processing and queuing delays, obtain an expression for the end-to-end delay.d. Suppose Host A begins to transmit the packet at time t = 0. At time trans d t =,where is the last bit of the packet?e. Suppose prop d is greater than trans d . At time t = trans d ,where is the first bit of the packet?f. Suppose prop d is less than trans d . At time t = trans d , where is the first bit of the packet?g. Suppose 8105.2⨯=s , L = 100bits, and R = 28 kbps. Find the distance m so that prop d equals trans d .13. In modern packet-switched networks, the source host segments long,application-layer messages (for example, an image or a music file) into smaller packets and sends the packets into the network. The receiver then reassembles the packets back into the original message. We refer to this process as message segmentation. Figure 1.24 illustrates the end-to-end transport of a message with and without message segmentation. Consider a message that is 6108⨯ bits long that is to be sent from source to destination in Figure 1.24. Suppose each link in the figure is 2 Mbps. Ignore propagation, queuing, and processing delays.a. Consider sending the message from source to destination without message segmentation. How long does it take to move the message from the source host to the first packet switch? Keeping in mind that each switch uses store-and-forward packet switching, what is the total time to move the message from source host to destination host?b. Now suppose that the message is segmented into 4,000 packets, with each packet being 2,000 bits long. How long does it take to move the first packet from source host to the first switch? When the first packet is being sent from the first switch to the second switch, the second packet is being sent from the source host to the first switch. At what time will the second packet be fully received at the first switch?c. How long does it take to move the file from source host to destination hostwhen message segmentation is used? Compare this result with your answer in part(a) and comment.d. Discuss the drawbacks of message segmentation.14.下列说法中,正确的是( )。

TCP学习笔记-RFC1122（⼆）学习TCP/UDP过程中，有⼀些基本概念需要搞清楚。

其中如下定义请注意：SegmentA segment is the unit of end-to-end transmission in the TCP protocol. A segment consists of a TCP header followed by application data. A segment is transmitted by encapsulation inside an IP datagram.MessageIn this description of the lower-layer protocols, a message is the unit of transmission in a transport layer protocol. In particular, a TCP segment is a message. A message consists of a transport protocol header followed by application protocol data. To be transmitted end-to end through the Internet, a message must be encapsulated inside a datagram.IP DatagramAn IP datagram is the unit of end-to-end transmission in the IP protocol. An IP datagram consists of an IP header followed by transport layer data, i.e., of an IP header followed by a message. In the description of the internet layer (Section 3), the unqualified term "datagram" should be understood to refer to an IP datagram.PacketA packet is the unit of data passed across the interface between the internet layer and the link layer. It includes an IP header and data. A packet may be a complete IP datagram or a fragment of an IP datagram.FrameA frame is the unit of transmission in a link layer protocol, and consists of a link-layer header followed by a packet.。