As per Relevance of the word extended, we have this rfc below:
Network Working Group J. Klensin, WG
Request for Comments: 1427 United Nations
N. Freed,
Innosoft International, Inc
K.
University of
February 1993
SMTP Service
for Message Size
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
1.
This memo defines an extension to the SMTP service whereby an
client and server may interact to give the server an opportunity
decline to accept a message (perhaps temporarily) based on
client's estimate of the message size
2.
The MIME extensions to the Internet message protocol provide for
transmission of many kinds of data which were previously
in Internet mail. One expected result of the use of MIME is
SMTP will be expected to carry a much wider range of message
than was previously the case. This has an impact on the amount
resources (e.g., disk space) required by a system acting as a server
This memo uses the mechanism defined in [5] to define extensions
the SMTP service whereby a client ("sender-SMTP") may declare
size of a particular message to a server ("receiver-SMTP"),
which the server may indicate to the client that it is or is
willing to accept the message based on the declared message size
whereby a server ("receiver-SMTP") may declare the maximum
size it is willing to accept to a client ("sender-SMTP").
3. Framework for the Size Declaration
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
Declaration";
(2) the EHLO keyword value associated with this extension is "SIZE";
(3) one optional parameter is allowed with this EHLO keyword value,
decimal number indicating the fixed maximum message size in
that the server will accept. The syntax of the parameter is
follows, using the augmented BNF notation of [2]:
size-param ::= [1*DIGIT
A parameter value of 0 (zero) indicates that no fixed
message size is in force. If the parameter is omitted
information is conveyed about the server's fixed maximum
size
(4) one optional parameter using the keyword "SIZE" is added to the
FROM command. The value associated with this parameter is a
number indicating the size of the message that is to be transmitted
The syntax of the value is as follows, using the augmented
notation of [2]:
size-value ::= 1*
(5) no additional SMTP verbs are defined by this extension
The remainder of this memo specifies how support for the
affects the behavior of an SMTP client and server
4. The Message Size Declaration service
An SMTP server may have a fixed upper limit on message size.
attempt by a client to transfer a message which is larger than
fixed upper limit will fail. In addition, a server normally
limited space with which to store incoming messages. Transfer of
message may therefore also fail due to a lack of storage space,
might succeed at a later time
A client using the unextended SMTP protocol defined in [1], can
be informed of such failures after transmitting the entire message
the server (which discards the transferred message). If, however
both client and server support the Message Size Declaration
extension, such conditions may be detected before any transfer
attempted
An SMTP client wishing to relay a large content may issue the
command to start an SMTP session, to determine if the server
Klensin, Freed & Moore [Page 2]
RFC 1427 SMTP Size Declaration February 1993
any of several service extensions. If the server responds with
250 to the EHLO command, and the response includes the EHLO
value SIZE, then the Message Size Declaration extension is supported
If a numeric parameter follows the SIZE keyword value of the
response, it indicates the size of the largest message that
server is willing to accept. Any attempt by a client to transfer
message which is larger than this limit will be rejected with
permanent failure (552) reply code
A server that supports the Message Size Declaration extension
accept the extended version of the MAIL command described below
When supported by the server, a client may use the extended
command (instead of the MAIL command as defined in [1]) to declare
estimate of the size of a message it wishes to transfer. The
may then return an appropriate error code if it determines that
attempt to transfer a message of that size would fail
5.
The message size is defined as the number of octets, including CR-
pairs, but not the SMTP DATA command's terminating dot or
quoting dots, to be transmitted by the SMTP client after
reply code 354 to the DATA command
The fixed maximum message size is defined as the message size of
largest message that a server is ever willing to accept. An
to transfer any message larger than the fixed maximum message
will always fail. The fixed maximum message size may be
implementation artifact of the SMTP server, or it may be chosen
the administrator of the server
The declared message size is defined as a client's estimate of
message size for a particular message
6. The extended MAIL
The extended MAIL command is issued by a client when it wishes
inform a server of the size of the message to be sent. The
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].
esmtp-keyword is "SIZE" and the syntax for esmtp-value is given
the syntax for size-value shown above
The value associated with the SIZE parameter is a
representation of the declared message size in octets. This
Klensin, Freed & Moore [Page 3]
RFC 1427 SMTP Size Declaration February 1993
should include the message header, body, and the CR-LF
between lines, but not the SMTP DATA command's terminating dot
doubled quoting dots
Ideally, the declared message size is equal to the true message size
However, since exact computation of the message size may
infeasable, the client may use a heuristically-derived estimate
Such heuristics should be chosen so that the declared message size
usually larger than the actual message size. (This has the effect
making the counting or non-counting of SMTP DATA dots largely
academic point.)
NOTE: Servers MUST NOT use the SIZE parameter to determine end
content in the DATA command
6.1 Server action on receipt of the extended MAIL
Upon receipt of an extended MAIL command containing a SIZE parameter
a server should determine whether the declared message size
its fixed maximum message size. If the declared message size
smaller than the fixed maximum message size, the server may also
to determine whether sufficient resources are available to buffer
message of the declared message size and to maintain it in
storage, until the message can be delivered or relayed to each of
recipients
A server may respond to the extended MAIL command with any of
error codes defined in [1] for the MAIL command. In addition, one
the following error codes may be returned
(1) If the server currently lacks sufficient resources to accept
message of the indicated size, but may be able to accept the
at a later time, it responds with code "452 insufficient
storage".
(2) If the indicated size is larger than the server's fixed
message size, the server responds with code "552 message
exceeds fixed maximium message size".
A server is permitted, but not required, to accept a message
is, in fact, larger than declared in the extended MAIL command,
as might occur if the client employed a size-estimation
which was inaccurate
6.2 Client action on receiving response to extended MAIL
The client, upon receiving the server's response to the extended
command, acts as follows
Klensin, Freed & Moore [Page 4]
RFC 1427 SMTP Size Declaration February 1993
(1) If the code "452 insufficient system storage" is returned,
client should next send either a RSET command (if it wishes
attempt to send other messages) or a QUIT command. The client
then repeat the attempt to send the message to the server at a
time
(2) If the code "552 message exceeds fixed maximum message size"
received, the client should immediately send either a RSET
(if it wishes to attempt to send additional messages), or a
command. The client should then declare the message
and return appropriate notification to the sender (if a
address was present in the MAIL command).
A successful (250) reply code in response to the extended
command does not constitute an absolute guarantee that the
transfer will succeed. SMTP clients using the extended MAIL
must still be prepared to handle both temporary and permanent
reply codes (including codes 452 and 552), either immediately
issuing the DATA command, or after transfer of the message
6.3 Messages larger than the declared size
Once a server has agreed (via the extended MAIL command) to accept
message of a particular size, it should not return a 552 reply
after the transfer phase of the DATA command, unless the actual
of the message transferred is greater than the declared message size
A server may also choose to accept a message which is somewhat
than the declared message size
A client is permitted to declare a message to be smaller than
actual size. However, in this case, a successful (250) reply code
no assurance that the server will accept the message or
sufficient resources to do so. The server may reject such a
after its DATA transfer
6.4 Per-recipient rejection based on message size
A server that implements this extension may return a 452 or 552
code in response to a RCPT command, based on its unwillingness
accept a message of the declared size for a particular recipient
(1) If a 452 code is returned, the client may requeue the message
later delivery to the same recipient
(2) If a 552 code is returned, the client may not requeue the
for later delivery to the same recipient
Klensin, Freed & Moore [Page 5]
RFC 1427 SMTP Size Declaration February 1993
7. Minimal
A "minimal" client may use this extension to simply compare
(perhaps estimated) size of the message that it wishes to relay,
the server's fixed maximum message size (from the parameter to
SIZE keyword in the EHLO response), to determine whether the
will ever accept the message. Such an implementation need
declare message sizes via the extended MAIL command. However
neither will it be able to discover temporary limits on message
due to server resource limitations, nor per-recipient limitations
message size
A minimal server that employs this service extension may simply
the SIZE keyword value to inform the client of the size of
largest message it will accept, or to inform the client that there
no fixed limit on message size. Such a server must accept
extended MAIL command and return a 552 reply code if the client'
declared size exceeds its fixed size limit (if any), but it need
detect "temporary" limitations on message size
The numeric parameter to the EHLO SIZE keyword is optional. If
parameter is omitted entirely it indicates that the server does
advertise a fixed maximum message size. A server that returns
SIZE keyword with no parameter in response to the EHLO command
not issue a positive (250) response to an extended MAIL
containing a SIZE specification without first checking to see
sufficient resources are available to transfer a message of
declared size, and to retain it in stable storage until it can
relayed or delivered to its recipients. If possible, the
should actually reserve sufficient storage space to transfer
message
8.
The following example illustrates the use of size declaration
some permanent and temporary failures
S: connection on TCP port 25>
C: connection to server
S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
C: EHLO ymir.claremont.
S: 250-sigurd.innosoft.
S: 250-
S: 250-
S: 250 SIZE 1000000
C: MAIL FROM: SIZE=500000
S: 250 Address Ok
C: RCPT TO:
Klensin, Freed & Moore [Page 6]
RFC 1427 SMTP Size Declaration February 1993
S: 250 ned@innosoft.com OK; can accomodate 500000 byte
C: RCPT TO:
S: 552 channel size limit exceeded: ned@YMIR.CLAREMONT.
C: RCPT TO:
S: 452 insufficient channel storage: ned@hmcvax.CLAREMONT.
C:
S: 354 Send message, ending in CRLF.CRLF
...
C: .
S: 250 Some recipients
C:
S: 250
9. Security
The size declaration extensions described in this memo
conceivably be used to facilitate crude service denial attacks
Specifically, both the information contained in the SIZE
and use of the extended MAIL command make it somewhat quicker
easier to devise an efficacious service denial attack. However
unless implementations are very weak, these extensions do not
any vulnerability that has not always existed with SMTP. In addition
no issues are addressed involving trusted systems and
release of information via the mechanisms described in this RFC
10.
This document was derived from an earlier Working Group
contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot Lear
Marshall T. Rose, and Einar Stefferud provided extensive comments
response to earlier drafts of both this and the previous memo
11.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Borenstein, N., and N. Freed, "Multipurpose Internet
Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
[4] Moore, K., "Representation of Non-ASCII Text in Internet
Headers", RFC 1342, University of Tennessee, June 1992.
Klensin, Freed & Moore [Page 7]
RFC 1427 SMTP Size Declaration February 1993
[5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud
E., and D. Crocker, "SMTP Service Extensions" RFC 1425,
Nations University, Innosoft International, Inc., Dover
Consulting, Inc., Network Management Associates, Inc., The
Office, February 1993.
[6] Partridge, C., "Mail Routing and the Domain System", RFC 974,
BBN, January 1986.
12. Chair, Editor, and Author's
John Klensin, WG
United Nations
PO Box 500, Charles Street
Boston, MA 02114-0500
Phone: +1 617 227 8747
Fax: +1 617 491 6266
Email: klensin@infoods.unu.
Ned Freed,
Innosoft International, Inc
250 West First Street, Suite 240
Claremont, CA 91711
Phone: +1 909 624 7907
Fax: +1 909 621 5319
Email: ned@innosoft.
Keith
Computer Science Dept
University of
107 Ayres
Knoxville, TN 37996-1301
Email: moore@cs.utk.
Klensin, Freed & Moore [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
