⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1427.txt

📁 <VC++网络游戏建摸与实现>源代码
💻 TXT
📖 第 1 页 / 共 2 页
字号:
Network Working Group                               J. Klensin, WG ChairRequest for Comments: 1427                     United Nations University                                                        N. Freed, Editor                                            Innosoft International, Inc.                                                                K. Moore                                                 University of Tennessee                                                           February 1993                         SMTP Service Extension                      for Message Size DeclarationStatus of this Memo   This RFC specifies an IAB standards track protocol for the Internet   community, and requests discussion and suggestions for improvements.   Please refer to the current edition of the "IAB Official Protocol   Standards" for the standardization state and status of this protocol.   Distribution of this memo is unlimited.1.  Abstract   This memo defines an extension to the SMTP service whereby an SMTP   client and server may interact to give the server an opportunity to   decline to accept a message (perhaps temporarily) based on the   client's estimate of the message size.2.  Introduction   The MIME extensions to the Internet message protocol provide for the   transmission of many kinds of data which were previously unsupported   in Internet mail.  One expected result of the use of MIME is that   SMTP will be expected to carry a much wider range of message sizes   than was previously the case.  This has an impact on the amount of   resources (e.g., disk space) required by a system acting as a server.   This memo uses the mechanism defined in [5] to define extensions to   the SMTP service whereby a client ("sender-SMTP") may declare the   size of a particular message to a server ("receiver-SMTP"), after   which the server may indicate to the client that it is or is not   willing to accept the message based on the declared message size and   whereby a server ("receiver-SMTP") may declare the maximum message   size it is willing to accept to a client ("sender-SMTP").3.  Framework for the Size Declaration Extension   The following service extension is therefore defined:Klensin, Freed & Moore                                          [Page 1]RFC 1427                 SMTP Size Declaration             February 1993(1) the name of the SMTP service extension is "Message Size    Declaration";(2) the EHLO keyword value associated with this extension is "SIZE";(3) one optional parameter is allowed with this EHLO keyword value, a    decimal number indicating the fixed maximum message size in bytes    that the server will accept.  The syntax of the parameter is as    follows, using the augmented BNF notation of [2]:        size-param ::= [1*DIGIT]    A parameter value of 0 (zero) indicates that no fixed maximum    message size is in force.  If the parameter is omitted no    information is conveyed about the server's fixed maximum message    size;(4) one optional parameter using the keyword "SIZE" is added to the MAIL    FROM command.  The value associated with this parameter is a decimal    number indicating the size of the message that is to be transmitted.    The syntax of the value is as follows, using the augmented BNF    notation of [2]:        size-value ::= 1*DIGIT(5) no additional SMTP verbs are defined by this extension.   The remainder of this memo specifies how support for the extension   affects the behavior of an SMTP client and server.4.  The Message Size Declaration service extension   An SMTP server may have a fixed upper limit on message size.  Any   attempt by a client to transfer a message which is larger than this   fixed upper limit will fail.  In addition, a server normally has   limited space with which to store incoming messages.  Transfer of a   message may therefore also fail due to a lack of storage space, but   might succeed at a later time.   A client using the unextended SMTP protocol defined in [1], can only   be informed of such failures after transmitting the entire message to   the server (which discards the transferred message).  If, however,   both client and server support the Message Size Declaration service   extension, such conditions may be detected before any transfer is   attempted.   An SMTP client wishing to relay a large content may issue the EHLO   command to start an SMTP session, to determine if the server supportsKlensin, Freed & Moore                                          [Page 2]RFC 1427                 SMTP Size Declaration             February 1993   any of several service extensions.  If the server responds with code   250 to the EHLO command, and the response includes the EHLO keyword   value SIZE, then the Message Size Declaration extension is supported.   If a numeric parameter follows the SIZE keyword value of the EHLO   response, it indicates the size of the largest message that the   server is willing to accept.  Any attempt by a client to transfer a   message which is larger than this limit will be rejected with a   permanent failure (552) reply code.   A server that supports the Message Size Declaration extension will   accept the extended version of the MAIL command described below.   When supported by the server, a client may use the extended MAIL   command (instead of the MAIL command as defined in [1]) to declare an   estimate of the size of a message it wishes to transfer.  The server   may then return an appropriate error code if it determines that an   attempt to transfer a message of that size would fail.5.  Definitions   The message size is defined as the number of octets, including CR-LF   pairs, but not the SMTP DATA command's terminating dot or doubled   quoting dots, to be transmitted by the SMTP client after receiving   reply code 354 to the DATA command.   The fixed maximum message size is defined as the message size of the   largest message that a server is ever willing to accept.  An attempt   to transfer any message larger than the fixed maximum message size   will always fail.  The fixed maximum message size may be an   implementation artifact of the SMTP server, or it may be chosen by   the administrator of the server.   The declared message size is defined as a client's estimate of the   message size for a particular message.6.  The extended MAIL command   The extended MAIL command is issued by a client when it wishes to   inform a server of the size of the message to be sent.  The extended   MAIL command is identical to the MAIL command as defined in [1],   except that a SIZE parameter appears after the address.   The complete syntax of this extended command is defined in [5]. The   esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by   the syntax for size-value shown above.   The value associated with the SIZE parameter is a decimal   representation of the declared message size in octets.  This numberKlensin, Freed & Moore                                          [Page 3]RFC 1427                 SMTP Size Declaration             February 1993   should include the message header, body, and the CR-LF sequences   between lines, but not the SMTP DATA command's terminating dot or   doubled quoting dots.   Ideally, the declared message size is equal to the true message size.   However, since exact computation of the message size may be   infeasable, the client may use a heuristically-derived estimate.   Such heuristics should be chosen so that the declared message size is   usually larger than the actual message size. (This has the effect of   making the counting or non-counting of SMTP DATA dots largely an   academic point.)   NOTE: Servers MUST NOT use the SIZE parameter to determine end of   content in the DATA command.6.1  Server action on receipt of the extended MAIL command   Upon receipt of an extended MAIL command containing a SIZE parameter,   a server should determine whether the declared message size exceeds   its fixed maximum message size.  If the declared message size is   smaller than the fixed maximum message size, the server may also wish   to determine whether sufficient resources are available to buffer a   message of the declared message size and to maintain it in stable   storage, until the message can be delivered or relayed to each of its   recipients.   A server may respond to the extended MAIL command with any of the   error codes defined in [1] for the MAIL command.  In addition, one of   the following error codes may be returned:(1) If the server currently lacks sufficient resources to accept a    message of the indicated size, but may be able to accept the message    at a later time, it responds with code "452 insufficient system    storage".(2) If the indicated size is larger than the server's fixed maximum    message size, the server responds with code "552 message size    exceeds fixed maximium message size".   A server is permitted, but not required, to accept a message which   is, in fact, larger than declared in the extended MAIL command, such   as might occur if the client employed a size-estimation heuristic   which was inaccurate.6.2  Client action on receiving response to extended MAIL command   The client, upon receiving the server's response to the extended MAIL   command, acts as follows:Klensin, Freed & Moore                                          [Page 4]

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -