V.Shveidel Internet Draft A.Erev Document: draft-shveidel-mediasize-00.txt Comverse Expires: 2003 June 2002 SMTP Service Extension for message Media Size declaration Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 general message size and sizes of media parts the message contains. [9] lists a number of issues and requirements for the use of internet messaging in the context of Unified Messaging and Telephone User Interface. This memo elaborates and suggests an implementation for chapter 3.2 of [9]. This memo extends facilities of "SMTP Service Extension for Message Size Declaration" [3]. As such, the authors of this memo used portions of the text in [3] as a basis for this memo. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction...................................................2 2. Framework for the Per Media Size Declaration Extension.........3 3. The Message Media Size Declaration service extension...........4 4. Definitions....................................................5 Shveidel/Erev Internet draft - Expires February 2003 1 SMTP Per Media Size Declaration June 2002 5. The extended MAIL command......................................5 5.1 Server action on receipt of the extended MAIL command..........6 5.2 Client action on receiving response to extended MAIL command...7 5.3 Messages containing media parts larger than the declared media size...............................................................7 6. Minimal usage..................................................8 7. Example........................................................8 8. Security considerations........................................9 9. IANA Considerations............................................9 9.1. Message Context size units Registrations.....................10 9.2. Registration Template........................................10 10. References....................................................11 11. Author's Addresses............................................11 1. 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 and message media types 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 general size of a particular message and a per media size 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 æper-media sizeÆ of the message and whereby a server ("receiver-SMTP") may declare the maximum æper-media sizeÆ for a message it is willing to accept from a client ("sender-SMTP"). This memo extends facilities of "SMTP Service Extension for Message Size Declaration" [3]. As mentioned above, the proposed extension allows an SMTP client and an SMTP server to coordinate transmission of a message based on its size, classified by specific media type(s). This allows the server to manage quota per media or per message-context (see [6]). There are basically two alternatives to manage per-media/context quota: (1) Associate the media size of the whole message to a "Message-Context" category (see [6]). Or, (2) Associate each body part to a specific Quota class, based on its content/media type. ( An example of (1) is a "voice-message" message-context, which may include a text attachment. Both the voice and the text parts will be accounted on the "voice-message" Quota. Shveidel Informational - Expires February 2003 2 SMTP Per Media Size Declaration June 2002 An example of (2) is a "video message" that contains a body part with video content-type and another body part with audio content- type û each of them accounted to different quota classes "video" and "audio" respectively. An implementation may decide which of the above alternatives to use. 2. Framework for the Per Media Size Declaration Extension The following service extension is therefore defined: (1) The name of the SMTP service extension is "Message MediaSize Declaration"; (2) The EHLO keyword value associated with this extension is "MEDIASIZE"; (3) Some optional parameters are allowed with this EHLO keyword. Each parameter is a string indicating the fixed maximum size of media parts of the message in special units that the server will accept. The syntax of the parameter is as follows, using the augmented BNF notation of [2]: mediasize-params ::= [*(SP media_size_dsc)] media_size_dsc ::= media:maxsize unit *([;maxsize unit]) media ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") maxsize ::= [1*(DIGIT)] unit ::= ALPHA *(ALPHA / "-") A maxsize value of 0 (zero) indicates that no fixed maximum message media size is in force. If some parameter is omitted no information is conveyed about the server's fixed maximum message size for corresponding media. (4) One optional parameter using the keyword "SIZE" is added to the MAIL FROM command. The value associated with this parameter is a string indicating the general size and the per-media size of the message that is to be transmitted. The syntax of the value is as follows, using the augmented BNF notation of [2]: mediasize-value ::= general_size[*(;media_size)] general_size ::= size-value media_size ::= [media:size-value unit] Shveidel Informational - Expires February 2003 3 SMTP Per Media Size Declaration June 2002 media ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") unit ::= ALPHA *(ALPHA / "-") 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. 3. The Message Media Size Declaration service extension An SMTP server may have a fixed upper limit not only on general message size but also an upper limit on each media type, which may be contained in the message. Any attempt by a client to transfer a message containing a media part whose size is larger than this fixed upper limit will fail. In addition, a server normally has limited space for storing incoming messages. Transfer of a message may therefore fail due to lack of storage space for a specific media, but may succeed at a later time. A client using the SMTP protocol defined in [1] (with no extensions) or the SMTP protocol with "Message Size Declaration service extension" [3] 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 Media Size Declaration service extension, such conditions may be detected before any transfer is attempted. An SMTP client wishing to relay large media content may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword value MEDIASIZE, then the Message Media Size Declaration extension is supported. If a string of parameters follows the MEDIASIZE keyword value of the EHLO response, each of the parameters indicates the maximal size and units for a specific media type of the message, or parts of the message, that the server is willing to accept. Any attempt by a client to transfer a message containing a media part that is larger than this limit will be rejected with a permanent failure (552) reply code. If the SMTP server has no fixed maximum size limitation for a specific media, it still should include this media type in the MEDIASIZE EHLO response (with the maximum size set to 0) so that the client knows that this media type is supported by the server and the media unit(s) supported in the context of MEDIASIZE processing. Shveidel Informational - Expires February 2003 4 SMTP Per Media Size Declaration June 2002 A server that supports the Message Media 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] and extension defined in [3]) 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 with media part of that size would fail. 4. Definitions The per media message size is defined as the sequence of general message size (as it is defined in [3]), and one or more media size items describing duration of media parts of the message. A Media size item is defined as the sequence of the character ";", media name, the character ":", media size (or duration) and immediately following it, the unit measurement name. Media name is defined as alphabetical string and is subject for future standardization. Size is defined as number of octets. Measurement unit is defined as alphabetical string and is subject for future standardization. The fixed maximum message per media size is defined as the set of the fixed maximum message sizes for specific media potentially contained in the message that a server is ever willing to accept. An attempt to transfer any message with media part larger than the fixed maximum for this media will always fail. The fixed maximum message media size may be an implementation artifact of the SMTP server, or it may be chosen by the administrator of the server. The fixed maximum size for specific media is defined as the sequence of media name, the character ":" and one or more pairs of media size followed by the measurement unit. Pairs are delimited by a ";". Each pair gives an alternative for media size/duration representation supported by the server. The declared message media size is defined as a client's estimate of the message media size for a particular message. 5. The extended MAIL command The extended MAIL command is issued by a client when it wishes to inform a server of the media size(s) of the message to be sent. The extended MAIL command is identical to the MAIL command as defined in [3], except that a SIZE parameter contains not only general message size but also the media size (or duration). The complete syntax of thee extended command is defined in [5]. The esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by the syntax for mediasize-value shown above. Shveidel Informational - Expires February 2003 5 SMTP Per Media Size Declaration June 2002 The value associated with the SIZE parameter is a string representation of the declared message media size in specific units for each media type. General message size is represented as it is defined in [3]. Ideally, the declared message media size is equal to the true message size. However, since exact computation of the message media size may be infeasible, the client may use a heuristically-derived estimate. Such heuristics should be chosen so that the declared message media size is larger than the actual message size. NOTE: Servers MUST NOT use the SIZE parameter to determine end of content in the DATA command. 5.1 Server action on receipt of the extended MAIL command Upon receipt of an extended MAIL command containing a media extended SIZE parameter, a server should determine whether the declared general message size exceeds its (current) fixed maximum message size and whether declared media size(s) exceed corresponding fixed maximum media sizes. If the declared general message size and all of declared media sizes are smaller than the corresponding fixed maximum message sizes, the server may also wish to determine whether sufficient resources are available to buffer a message of the declared media 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] and [3] for the MAIL command. In addition, one of the following error codes may be returned: (1) If the server does not support the measurement unit for a specific media that was specified by the client in the MAIL command, the server should respond with code "501 Syntax error in parameter, illegal unit name" (2) If the server currently lacks sufficient resources to accept a message of the indicated media size, but may be able to accept the message at a later time, it should respond with code "452 insufficient system media-specific storage". (3) If the indicated per media size is larger than the server's fixed maximum message per media size, the server should respond with code "552 message media size exceeds fixed maximum message media 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 (produced a lower result). Shveidel Informational - Expires February 2003 6 SMTP Per Media Size Declaration June 2002 5.2 Client action on receiving response to extended MAIL command (1) If the code "452 insufficient system media storage" is returned, the client should next send either a RSET command (if it wishes to attempt to send other messages) or a QUIT command. The client should then repeat the attempt to send the message to the server at a later time. (2) If the code "552 message media size exceeds fixed maximum message media size" is received, the client should immediately send either a RSET command (if it wishes to attempt to send additional messages), or a QUIT command. The client should then declare the message undeliverable and return appropriate notification to the sender (if a sender address was present in the MAIL command). A successful (250) reply code in response to the extended MAIL command does not constitute an absolute guarantee that the message transfer will succeed. SMTP clients using the extended MAIL command must still be prepared to handle both temporary and permanent error reply codes (including codes 452 and 552), either immediately after issuing the DATA command, or after transfer of the message. 5.3 Messages containing media parts larger than the declared media size. Once a server has agreed (via the extended MAIL command) to accept a message of a particular media size, it should not return a 552 reply code after the transfer phase of the DATA command, unless the actual per media size of the message transferred is greater than the declared message per media size. A server may also choose to accept a message containing media parts which are somewhat larger than the declared media size. A client is permitted to declare a message to be smaller than its actual per media size. However, in this case, a successful (250 reply code is no assurance that the server will accept the message or has sufficient resources to do so. The server may reject such a message after its DATA transfer. 5.4 Per-recipient rejection based on message per media size. A server that implements this extension may return a 452 or 552 reply code (as it is explained in 5.1) in response to a RCPT command, based on its unwillingness to accept a message of the declared per media size for a particular recipient. (1) If a 452 code is returned, the client is expected to requeue the message for later delivery to the same recipient. Shveidel Informational - Expires February 2003 7 SMTP Per Media Size Declaration June 2002 (2) If a 552 code is returned, the client is expected to refrain from any later retry delivery to the same recipient. 6. Minimal usage A "minimal" client may use this extension to simply compare the (perhaps estimated) per media size of the message that it wishes to relay, with the server's fixed maximum message per media size (from the parameter to the MEDIASIZE keyword in the EHLO response), to determine whether the server will ever accept the message. Such an implementation need not declare message per media size via the extended MAIL command. However, neither will it be able to discover temporary limits on message media size due to server resource limitations, nor per-recipient limitations on message media size. A "minimal" server that employs this service extension may simply use the MEDIASIZE keyword value to inform the client of the size of the largest media parts of message it will accept, or to inform the client that there is no fixed limit on message media sizes. Such a server must accept the extended MAIL command and return a 552 reply code if the client's declared media size exceeds its fixed media size limit (if any), but it need not detect "temporary" limitations on message media size. The string parameters to the EHLO MEDIASIZE keyword are optional. If some parameter is omitted entirely it indicates that the server does not advertise a fixed maximum for this media size. A server that returns the MEDIASIZE keyword with no parameter or with omitted parameter for specific media in response to the EHLO command should not issue a positive (250) response to an extended MAIL command containing a media-extended SIZE specification without first checking to see if sufficient resources are available to transfer a message of the declared media sizes, and to retain it in stable storage until it can be relayed or delivered to its recipients. If possible, the server should actually reserve sufficient message storage space to transfer the message. 7. Example The following example illustrates the use of per media size declaration with some permanent and temporary failures. S: C: S: 220 il-tlv-vis.icomverse.com ESMTP Service ready C: EHLO merlot.comverse.com S: 250- merlot.comverse.com S: 250-EXPN S: 250-HELP S: 250 SIZE 1000000 Shveidel Informational - Expires February 2003 8 SMTP Per Media Size Declaration June 2002 S: 250 MEDIASIZE video:100sec;10000kb fax:20pages;2000kb voice:10sec C: MAIL FROM: SIZE=80000;video:7sec;fax:3pages S: 250 Address Ok. C: RCPT TO: S: 250 v@comverse.com OK; can accept 80000;video:7sec;fax:3pages C: RCPT TO: S: 452 insufficient system media storage (fax): x@comverse.com C: DATA S: 354 Send message, ending in CRLF.CRLF. ... C: . S: 250 OK C: QUIT S: 250 Goodbye 8. Security considerations The media size declaration extensions described in this memo can conceivably be used to facilitate crude service denial attacks. Specifically, both the information contained in the SIZE parameter and use of the extended MAIL command make it somewhat quicker and easier to devise an efficacious service denial attack. It is recommended that an implementation supports internal mapping between media size units and compares the declared size and the actually received size (if in different units) to validate that the two relate to each other reasonably. This should prevent cases where the declared size (expressed in some unit) defers from the actual sent size (possibly measured in another unit). Describing the mapping algorithm (which may be dependent on specific file formats and encoding schemes) is out of the scope of this draft. Other than that this extension does not create any vulnerability that has not existed with SMTP or with SMTP with the original SIZE extension. 9. IANA Considerations To promote interoperability and coherent interpretations of different media types, a central repository for well-known media types and possible measurement units should be maintained. As mentioned above (see "Introduction"), there are two alternatives to manage per-media/context quota. When media size is associated with the "Message-Context" (i.e., the whole message is considered as one entity for quota purposes) û then the central repository is the IANA-managed Message-Context repository. Shveidel Informational - Expires February 2003 9 SMTP Per Media Size Declaration June 2002 When per-media quota is calculated based on each media part element in the message (possibly using multiple media quota per message) the recommended registry of media type to use is the IANA-managed "Content-Type" registry û specifically, the type (as opposed to the sub-type) in the content-type value. In both cases, there is a need to register the available units to go with the message-context or content-type identifying the media. The following is a suggested list for initial values for registration. 9.1. Message Context size units Registrations Internet Message-Context Size Units ====================================== Media Type (referenced Possible Unit(s) Message-Context value) first is default) Reference ----------------------- --------------------- ----------- voice-message "kb" (kilobytes) this RFC "sec" (seconds) fax-message "kb"(kilobytes) this RFC "pages" video-message "kb"(kilobytes) this RFC "sec" (seconds) text-message "kb"(kilobytes) this RFC 9.2. Registration Template In the following template, a pipe symbol, "|", precedes instructions or other helpful material. Be sure to replace "" with the media type name you are defining. Media Type name: |Referenced Message-Context (or Content-Type) value Default measurement unit: | Name of default measurement unit for the media (not longer | than 10 characters) Possible measurement units: | List of possible names of measurement unit for the media | type (each name must be not longer than 10 characters) Person & email address to contact for further information: Shveidel Informational - Expires February 2003 10 SMTP Per Media Size Declaration June 2002 | Name & e-mail 10. References [1] Klensin J, "Simple Mail Transfer Protocol", STD 10, RFC 2821, AT&T Laboratories, April 2001. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] J. Klensin, WG Chair, "SMTP Service Extension for Message Size Declaration", RFC 1427, University of Tennessee, February 1993. [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. [5] J. Klensin, WG Chair, " SMTP Service Extensions ", RFC 1869, Brandenburg Consulting, November 1995. [6] E. Burger, C. Eliot, G. Klyne, E. Candell, "Message Context for Internet Mail", Internet draft, Microsoft, Comverse, Baltimore Technologies, SnowShore Networks June 2001. [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [8] J. Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997. [9] Greg Vaudreuil, "Messaging Profile For Telephone-based Messaging Clients". http://www.ietf.org/internet-drafts/draft-vaudreuil-um- issues-00.txt 11. Author's Addresses Vladimir Shveidel Comverse 29 Habarzel St. Tel-Aviv 69710 Israel EMail: Vladimir.Shveidel@comverse.com Ari Erev Shveidel Informational - Expires February 2003 11 SMTP Per Media Size Declaration June 2002 Comverse 29 Habarzel St. Tel-Aviv 69710 Israel EMail: Ari.Erev@comverse.com Shveidel Informational - Expires February 2003 12