You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ba...@apache.org on 2006/07/29 15:16:01 UTC
svn commit: r426798 [27/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1870.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1870.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1870.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1870.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,508 @@
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request For Comments: 1870 MCI
+STD: 10 N. Freed, Editor
+Obsoletes: 1653 Innosoft International, Inc.
+Category: Standards Track K. Moore
+ University of Tennessee
+ November 1995
+
+
+ SMTP Service Extension
+ for Message Size Declaration
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) 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").
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 1]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+3. Framework for the Size Declaration Extension
+
+ The following service extension is therefore defined:
+
+ (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*20DIGIT
+
+ (5) the maximum length of a MAIL FROM command line is increased by 26
+ characters by the possible addition of the SIZE keyword and
+ value;
+
+ (6) 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.
+
+
+
+
+
+Klensin, et al Standards Track [Page 2]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+ 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 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 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.
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 3]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+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 number
+ 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. Only one SIZE parameter may be specified in a
+ single MAIL command.
+
+ 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".
+
+
+
+Klensin, et al Standards Track [Page 4]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+ (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:
+
+ (1) If the code "452 insufficient system 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 exceeds fixed maximum message 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.
+
+6.3 Messages larger than the declared size.
+
+ Once a server has agreed (via the extended MAIL command) to accept a
+ message of a particular size, it should not return a 552 reply code
+ after the transfer phase of the DATA command, unless the actual size
+ of the message transferred is greater than the declared message size.
+ A server may also choose to accept a message which is somewhat larger
+ than the declared message size.
+
+ A client is permitted to declare a message to be smaller than its
+ actual 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.
+
+
+
+Klensin, et al Standards Track [Page 5]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+6.4 Per-recipient rejection based on message size.
+
+ A server that implements this extension may return a 452 or 552 reply
+ code in response to a RCPT command, based on its unwillingness to
+ accept a message of the declared size for a particular recipient.
+
+ (1) If a 452 code is returned, the client may requeue the message for
+ later delivery to the same recipient.
+
+ (2) If a 552 code is returned, the client may not requeue the message
+ for later delivery to the same recipient.
+
+7. Minimal usage
+
+ A "minimal" client may use this extension to simply compare its
+ (perhaps estimated) size of the message that it wishes to relay, with
+ the server's fixed maximum message size (from the parameter to the
+ SIZE keyword in the EHLO response), to determine whether the server
+ will ever accept the message. Such an implementation need not
+ declare message sizes via the extended MAIL command. However,
+ neither will it be able to discover temporary limits on message size
+ due to server resource limitations, nor per-recipient limitations on
+ message size.
+
+ A minimal server that employs this service extension may simply use
+ the SIZE keyword value to inform the client of the size of the
+ largest message it will accept, or to inform the client that there is
+ no fixed limit on message size. Such a server must accept the
+ extended MAIL command and return a 552 reply code if the client's
+ declared size exceeds its fixed size limit (if any), but it need not
+ detect "temporary" limitations on message size.
+
+ The numeric parameter to the EHLO SIZE keyword is optional. If the
+ parameter is omitted entirely it indicates that the server does not
+ advertise a fixed maximum message size. A server that returns the
+ SIZE keyword with no parameter in response to the EHLO command may
+ not issue a positive (250) response to an extended MAIL command
+ containing a SIZE specification without first checking to see if
+ sufficient resources are available to transfer a message of the
+ declared size, 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 storage space to transfer the
+ message.
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 6]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+8. Example
+
+ The following example illustrates the use of size declaration with
+ some permanent and temporary failures.
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+ C: EHLO ymir.claremont.edu
+ S: 250-sigurd.innosoft.com
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250 SIZE 1000000
+ C: MAIL FROM:<ne...@thor.innosoft.com> SIZE=500000
+ S: 250 Address Ok.
+ C: RCPT TO:<ne...@innosoft.com>
+ S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
+ C: RCPT TO:<ne...@ymir.claremont.edu>
+ S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
+ C: RCPT TO:<ne...@hmcvax.claremont.edu>
+ S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
+ C: DATA
+ S: 354 Send message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 Some recipients OK
+ C: QUIT
+ S: 221 Goodbye
+
+9. Security Considerations
+
+ The 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. However,
+ unless implementations are very weak, these extensions do not create
+ any vulnerability that has not always existed with SMTP. In addition,
+ no issues are addressed involving trusted systems and possible
+ release of information via the mechanisms described in this RFC.
+
+10. Acknowledgements
+
+ This document was derived from an earlier Working Group work in
+ progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot
+ Lear, Marshall T. Rose, and Einar Stefferud provided extensive
+ comments in response to earlier works in progress of both this and
+ the previous memo.
+
+
+
+Klensin, et al Standards Track [Page 7]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+11. References
+
+ [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 Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+ "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
+ International, Inc., Dover Beach Consulting, Inc., Network
+ Management Associates, Inc., Brandenburg Consulting, November
+ 1995.
+
+ [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+ 974, BBN, January 1986.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 8]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+12. Chair, Editor, and Author Addresses
+
+ John Klensin, WG Chair
+ MCI
+ 2100 Reston Parkway
+ Reston, VA 22091
+
+ Phone: +1 703 715-7361
+ Fax: +1 703 715-7436
+ EMail: klensin@mci.net
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Keith Moore
+ Computer Science Dept.
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville, TN 37996-1301
+ USA
+
+ EMail: moore@cs.utk.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 9]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1870.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1891.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1891.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1891.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1891.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,521 @@
+
+
+
+
+
+Network Working Group K. Moore
+Request for Comments: 1891 University of Tennessee
+Category: Standards Track January 1996
+
+
+ SMTP Service Extension
+ for Delivery Status Notifications
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) 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, which allows an
+ SMTP client to specify (a) that delivery status notifications (DSNs)
+ should be generated under certain conditions, (b) whether such
+ notifications should return the contents of the message, and (c)
+ additional information, to be returned with a DSN, that allows the
+ sender to identify both the recipient(s) for which the DSN was
+ issued, and the transaction in which the original message was sent.
+
+ Any questions, comments, and reports of defects or ambiguities in
+ this specification may be sent to the mailing list for the NOTARY
+ working group of the IETF, using the address
+ <no...@cs.utk.edu>. Requests to subscribe to the mailing
+ list should be addressed to <no...@cs.utk.edu>.
+ Implementors of this specification are encouraged to subscribe to the
+ mailing list, so that they will quickly be informed of any problems
+ which might hinder interoperability.
+
+ NOTE: This document is a Proposed Standard. If and when this
+ protocol is submitted for Draft Standard status, any normative text
+ (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
+ this document will be re-evaluated in light of implementation
+ experience, and are thus subject to change.
+
+2. Introduction
+
+ The SMTP protocol [1] requires that an SMTP server provide
+ notification of delivery failure, if it determines that a message
+ cannot be delivered to one or more recipients. Traditionally, such
+ notification consists of an ordinary Internet mail message (format
+ defined by [2]), sent to the envelope sender address (the argument of
+
+
+
+Moore Standards Track [Page 1]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ the SMTP MAIL command), containing an explanation of the error and at
+ least the headers of the failed message.
+
+ Experience with large mail distribution lists [3] indicates that such
+ messages are often insufficient to diagnose problems, or even to
+ determine at which host or for which recipients a problem occurred.
+ In addition, the lack of a standardized format for delivery
+ notifications in Internet mail makes it difficult to exchange such
+ notifications with other message handling systems.
+
+ Such experience has demonstrated a need for a delivery status
+ notification service for Internet electronic mail, which:
+
+(a) is reliable, in the sense that any DSN request will either be
+ honored at the time of final delivery, or result in a response
+ that indicates that the request cannot be honored,
+
+(b) when both success and failure notifications are requested,
+ provides an unambiguous and nonconflicting indication of whether
+ delivery of a message to a recipient succeeded or failed,
+
+(c) is stable, in that a failed attempt to deliver a DSN should never
+ result in the transmission of another DSN over the network,
+
+(d) preserves sufficient information to allow the sender to identify
+ both the mail transaction and the recipient address which caused
+ the notification, even when mail is forwarded or gatewayed to
+ foreign environments, and
+
+(e) interfaces acceptably with non-SMTP and non-822-based mail
+ systems, both so that notifications returned from foreign mail
+ systems may be useful to Internet users, and so that the
+ notification requests from foreign environments may be honored.
+ Among the requirements implied by this goal are the ability to
+ request non-return-of-content, and the ability to specify whether
+ positive delivery notifications, negative delivery notifications,
+ both, or neither, should be issued.
+
+ In an attempt to provide such a service, this memo uses the mechanism
+ defined in [4] to define an extension to the SMTP protocol. Using
+ this mechanism, an SMTP client may request that an SMTP server issue
+ or not issue a delivery status notification (DSN) under certain
+ conditions. The format of a DSN is defined in [5].
+
+
+
+
+
+
+
+
+Moore Standards Track [Page 2]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+3. Framework for the Delivery Status Notification Extension
+
+ The following service extension is therefore defined:
+
+(1) The name of the SMTP service extension is "Delivery Status
+ Notification";
+
+(2) the EHLO keyword value associated with this extension is "DSN",
+ the meaning of which is defined in section 4 of this memo;
+
+(3) no parameters are allowed with this EHLO keyword value;
+
+(4) two optional parameters are added to the RCPT command, and two
+ optional parameters are added to the MAIL command:
+
+ An optional parameter for the RCPT command, using the
+ esmtp-keyword "NOTIFY", (to specify the conditions under which a
+ delivery status notification should be generated), is defined in
+ section 5.1,
+
+ An optional parameter for the RCPT command, using the
+ esmtp-keyword "ORCPT", (used to convey the "original"
+ (sender-specified) recipient address), is defined in section 5.2,
+ and
+
+ An optional parameter for the MAIL command, using the
+ esmtp-keyword "RET", (to request that DSNs containing an
+ indication of delivery failure either return the entire contents
+ of a message or only the message headers), is defined in section
+ 5.3,
+
+ An optional parameter for the MAIL command, using the
+ esmtp-keyword "ENVID", (used to propagate an identifier for this
+ message transmission envelope, which is also known to the sender
+ and will, if present, be returned in any DSNs issued for this
+ transmission), is defined in section 5.4;
+
+(5) no additional SMTP verbs are defined by this extension.
+
+ The remainder of this memo specifies how support for the extension
+ effects the behavior of a message transfer agent.
+
+4. The Delivery Status Notification service extension
+
+ An SMTP client wishing to request a DSN for a message 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
+
+
+
+Moore Standards Track [Page 3]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ keyword DSN, then the Delivery Status Notification extension (as
+ described in this memo) is supported.
+
+ Ordinarily, when an SMTP server returns a positive (2xx) reply code
+ in response to a RCPT command, it agrees to accept responsibility for
+ either delivering the message to the named recipient, or sending a
+ notification to the sender of the message indicating that delivery
+ has failed. However, an extended SMTP ("ESMTP") server which
+ implements this service extension will accept an optional NOTIFY
+ parameter with the RCPT command. If present, the NOTIFY parameter
+ alters the conditions for generation of delivery status notifications
+ from the default (issue notifications only on failure) specified in
+ [1]. The ESMTP client may also request (via the RET parameter)
+ whether the entire contents of the original message should be
+ returned (as opposed to just the headers of that message), along with
+ the DSN.
+
+ In general, an ESMTP server which implements this service extension
+ will propagate delivery status notification requests when relaying
+ mail to other SMTP-based MTAs which also support this extension, and
+ make a "best effort" to ensure that such requests are honored when
+ messages are passed into other environments.
+
+ In order that any delivery status notifications thus generated will
+ be meaningful to the sender, any ESMTP server which supports this
+ extension will attempt to propagate the following information to any
+ other MTAs that are used to relay the message, for use in generating
+ DSNs:
+
+(a) for each recipient, a copy of the original recipient address, as
+ used by the sender of the message.
+
+ This address need not be the same as the mailbox specified in the
+ RCPT command. For example, if a message was originally addressed
+ to A@B.C and later forwarded to A@D.E, after such forwarding has
+ taken place, the RCPT command will specify a mailbox of A@D.E.
+ However, the original recipient address remains A@B.C.
+
+ Also, if the message originated from an environment which does not
+ use Internet-style user@domain addresses, and was gatewayed into
+ SMTP, the original recipient address will preserve the original
+ form of the recipient address.
+
+(b) for the entire SMTP transaction, an envelope identification
+ string, which may be used by the sender to associate any delivery
+ status notifications with the transaction used to send the
+ original message.
+
+
+
+
+Moore Standards Track [Page 4]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+5. Additional parameters for RCPT and MAIL commands
+
+ The extended RCPT and MAIL commands are issued by a client when it
+ wishes to request a DSN from the server, under certain conditions,
+ for a particular recipient. The extended RCPT and MAIL commands are
+ identical to the RCPT and MAIL commands defined in [1], except that
+ one or more of the following parameters appear after the sender or
+ recipient address, respectively. The general syntax for extended
+ SMTP commands is defined in [4].
+
+ NOTE: Although RFC 822 ABNF is used to describe the syntax of these
+ parameters, they are not, in the language of that document,
+ "structured field bodies". Therefore, while parentheses MAY appear
+ within an emstp-value, they are not recognized as comment delimiters.
+
+ The syntax for "esmtp-value" in [4] does not allow SP, "=", control
+ characters, or characters outside the traditional ASCII range of 1-
+ 127 decimal to be transmitted in an esmtp-value. Because the ENVID
+ and ORCPT parameters may need to convey values outside this range,
+ the esmtp-values for these parameters are encoded as "xtext".
+ "xtext" is formally defined as follows:
+
+ xtext = *( xchar / hexchar )
+
+ xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
+ except for "+" and "=".
+
+; "hexchar"s are intended to encode octets that cannot appear
+; as ASCII characters within an esmtp-value.
+
+ hexchar = ASCII "+" immediately followed by two upper case
+ hexadecimal digits
+
+When encoding an octet sequence as xtext:
+
++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
+ MAY be encoded as itself. (A CHAR in this range MAY instead be
+ encoded as a "hexchar", at the implementor's discretion.)
+
++ ASCII CHARs that fall outside the range above must be encoded as
+ "hexchar".
+
+5.1 The NOTIFY parameter of the ESMTP RCPT command
+
+ A RCPT command issued by a client may contain the optional esmtp-
+ keyword "NOTIFY", to specify the conditions under which the SMTP
+ server should generate DSNs for that recipient. If the NOTIFY
+ esmtp-keyword is used, it MUST have an associated esmtp-value,
+
+
+
+Moore Standards Track [Page 5]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ formatted according to the following rules, using the ABNF of RFC
+ 822:
+
+ notify-esmtp-value = "NEVER" / 1#notify-list-element
+
+ notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
+
+Notes:
+
+a. Multiple notify-list-elements, separated by commas, MAY appear in a
+ NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
+
+b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled
+ in any combination of upper and lower case letters.
+
+The meaning of the NOTIFY parameter values is generally as follows:
+
++ A NOTIFY parameter value of "NEVER" requests that a DSN not be
+ returned to the sender under any conditions.
+
++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE"
+ keywords requests that a DSN be issued on successful delivery or
+ delivery failure, respectively.
+
++ A NOTIFY parameter value containing the keyword "DELAY" indicates the
+ sender's willingness to receive "delayed" DSNs. Delayed DSNs may be
+ issued if delivery of a message has been delayed for an unusual amount
+ of time (as determined by the MTA at which the message is delayed),
+ but the final delivery status (whether successful or failure) cannot
+ be determined. The absence of the DELAY keyword in a NOTIFY parameter
+ requests that a "delayed" DSN NOT be issued under any conditions.
+
+ The actual rules governing interpretation of the NOTIFY parameter are
+ given in section 6.
+
+ For compatibility with SMTP clients that do not use the NOTIFY
+ facility, the absence of a NOTIFY parameter in a RCPT command may be
+ interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
+
+5.2 The ORCPT parameter to the ESMTP RCPT command
+
+ The ORCPT esmtp-keyword of the RCPT command is used to specify an
+ "original" recipient address that corresponds to the actual recipient
+ to which the message is to be delivered. If the ORCPT esmtp-keyword
+ is used, it MUST have an associated esmtp-value, which consists of
+ the original recipient address, encoded according to the rules below.
+ The ABNF for the ORCPT parameter is:
+
+
+
+
+Moore Standards Track [Page 6]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ orcpt-parameter = "ORCPT=" original-recipient-address
+
+ original-recipient-address = addr-type ";" xtext
+
+ addr-type = atom
+
+ The "addr-type" portion MUST be an IANA-registered electronic mail
+ address-type (as defined in [5]), while the "xtext" portion contains
+ an encoded representation of the original recipient address using the
+ rules in section 5 of this document. The entire ORCPT parameter MAY
+ be up to 500 characters in length.
+
+ When initially submitting a message via SMTP, if the ORCPT parameter
+ is used, it MUST contain the same address as the RCPT TO address
+ (unlike the RCPT TO address, the ORCPT parameter will be encoded as
+ xtext). Likewise, when a mailing list submits a message via SMTP to
+ be distributed to the list subscribers, if ORCPT is used, the ORCPT
+ parameter MUST match the new RCPT TO address of each recipient, not
+ the address specified by the original sender of the message.)
+
+ The "addr-type" portion of the original-recipient-address is used to
+ indicate the "type" of the address which appears in the ORCPT
+ parameter value. However, the address associated with the ORCPT
+ keyword is NOT constrained to conform to the syntax rules for that
+ "addr-type".
+
+ Ideally, the "xtext" portion of the original-recipient-address should
+ contain, in encoded form, the same sequence of characters that the
+ sender used to specify the recipient. However, for a message
+ gatewayed from an environment (such as X.400) in which a recipient
+ address is not a simple string of printable characters, the
+ representation of recipient address must be defined by a
+ specification for gatewaying between DSNs and that environment.
+
+5.3 The RET parameter of the ESMTP MAIL command
+
+ The RET esmtp-keyword on the extended MAIL command specifies whether
+ or not the message should be included in any failed DSN issued for
+ this message transmission. If the RET esmtp-keyword is used, it MUST
+ have an associated esmtp-value, which is one of the following
+ keywords:
+
+ FULL requests that the entire message be returned in any "failed"
+ delivery status notification issued for this recipient.
+
+ HDRS requests that only the headers of the message be returned.
+
+
+
+
+
+Moore Standards Track [Page 7]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ The FULL and HDRS keywords may be spelled in any combination of upper
+ and lower case letters.
+
+ If no RET parameter is supplied, the MTA MAY return either the
+ headers of the message or the entire message for any DSN containing
+ indication of failed deliveries.
+
+ Note that the RET parameter only applies to DSNs that indicate
+ delivery failure for at least one recipient. If a DSN contains no
+ indications of delivery failure, only the headers of the message
+ should be returned.
+
+5.4 The ENVID parameter to the ESMTP MAIL command
+
+ The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
+ an "envelope identifier" to be transmitted along with the message and
+ included in any DSNs issued for any of the recipients named in this
+ SMTP transaction. The purpose of the envelope identifier is to allow
+ the sender of a message to identify the transaction for which the DSN
+ was issued.
+
+ The ABNF for the ENVID parameter is:
+
+ envid-parameter = "ENVID=" xtext
+
+ The ENVID esmtp-keyword MUST have an associated esmtp-value. No
+ meaning is assigned by the mail system to the presence or absence of
+ this parameter or to any esmtp-value associated with this parameter;
+ the information is used only by the sender or his user agent. The
+ ENVID parameter MAY be up to 100 characters in length.
+
+5.5 Restrictions on the use of Delivery Status Notification parameters
+
+ The RET and ENVID parameters MUST NOT appear more than once each in
+ any single MAIL command. If more than one of either of these
+ parameters appears in a MAIL command, the ESMTP server SHOULD respond
+ with "501 syntax error in parameters or arguments".
+
+ The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
+ RCPT command. If more than one of either of these parameters appears
+ in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
+ error in parameters or arguments".
+
+6. Conformance requirements
+
+ The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
+ Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
+ as User Agents (UAs) when submitting mail to the mail transport
+
+
+
+Moore Standards Track [Page 8]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+ system. The DSN extension to SMTP may be used to allow UAs to convey
+ the sender's requests as to when DSNs should be issued. A UA which
+ claims to conform to this specification must meet certain
+ requirements as described below.
+
+ Typically, a message transfer agent (MTA) which supports SMTP will
+ assume, at different times, both the role of a SMTP client and an
+ SMTP server, and may also provide local delivery, gatewaying to
+ foreign environments, forwarding, and mailing list expansion. An MTA
+ which, when acting as an SMTP server, issues the DSN keyword in
+ response to the EHLO command, MUST obey the rules below for a
+ "conforming SMTP client" when acting as a client, and a "conforming
+ SMTP server" when acting as a server. The term "conforming MTA"
+ refers to an MTA which conforms to this specification, independent of
+ its role of client or server.
+
+6.1 SMTP protocol interactions
+
+ The following rules apply to SMTP transactions in which any of the
+ ENVID, NOTIFY, RET, or ORCPT keywords are used:
+
+(a) If an SMTP client issues a MAIL command containing a valid ENVID
+ parameter and associated esmtp-value and/or a valid RET parameter
+ and associated esmtp-value, a conforming SMTP server MUST return
+ the same reply-code as it would to the same MAIL command without
+ the ENVID and/or RET parameters. A conforming SMTP server MUST
+ NOT refuse a MAIL command based on the absence or presence of
+ valid ENVID or RET parameters, or on their associated
+ esmtp-values.
+
+ However, if the associated esmtp-value is not valid (i.e. contains
+ illegal characters), or if there is more than one ENVID or RET
+ parameter in a particular MAIL command, the server MUST issue the
+ reply-code 501 with an appropriate message (e.g. "syntax error in
+ parameter").
+
+(b) If an SMTP client issues a RCPT command containing any valid
+ NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
+ return the same response as it would to the same RCPT command
+ without those NOTIFY and/or ORCPT parameters. A conforming SMTP
+ server MUST NOT refuse a RCPT command based on the presence or
+ absence of any of these parameters.
+
+ However, if any of the associated esmtp-values are not valid, or
+ if there is more than one of any of these parameters in a
+ particular RCPT command, the server SHOULD issue the response "501
+ syntax error in parameter".
+
+
+
+
+Moore Standards Track [Page 9]
+
+RFC 1891 SMTP Delivery Status Notifications January 1996
+
+
+6.2 Handling of messages received via SMTP
+
+ This section describes how a conforming MTA should handle any
+ messages received via SMTP.
+
+ NOTE: A DSN MUST NOT be returned to the sender for any message for
+ which the return address from the SMTP MAIL command was NULL ("<>"),
+ even if the sender's address is available from other sources (e.g.
+ the message header). However, the MTA which would otherwise issue a
+ DSN SHOULD inform the local postmaster of delivery failures through
+ some appropriate mechanism that will not itself
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1891.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1893.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1893.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1893.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1893.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,844 @@
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 1893 Octel Network Services
+Category: Standards Track January 1996
+
+
+ Enhanced Mail System Status Codes
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Overview
+
+ There currently is not a standard mechanism for the reporting of mail
+ system errors except for the limited set offered by SMTP and the
+ system specific text descriptions sent in mail messages. There is a
+ pressing need for a rich machine readable status code for use in
+ delivery status notifications [DSN]. This document proposes a new
+ set of status codes for this purpose.
+
+ SMTP [SMTP] error codes have historically been used for reporting
+ mail system errors. Because of limitations in the SMTP code design,
+ these are not suitable for use in delivery status notifications.
+ SMTP provides about 12 useful codes for delivery reports. The
+ majority of the codes are protocol specific response codes such as
+ the 354 response to the SMTP data command. Each of the 12 useful
+ codes are each overloaded to indicate several error conditions each.
+ SMTP suffers some scars from history, most notably the unfortunate
+ damage to the reply code extension mechanism by uncontrolled use.
+ This proposal facilitates future extensibility by requiring the
+ client to interpret unknown error codes according to the theory of
+ codes while requiring servers to register new response codes.
+
+ The SMTP theory of reply codes partitioned in the number space such a
+ manner that the remaining available codes will not provide the space
+ needed. The most critical example is the existence of only 5
+ remaining codes for mail system errors. The mail system
+ classification includes both host and mailbox error conditions. The
+ remaining third digit space would be completely consumed as needed to
+ indicate MIME and media conversion errors and security system errors.
+
+ A revision to the SMTP theory of reply codes to better distribute the
+ error conditions in the number space will necessarily be incompatible
+ with SMTP. Further, consumption of the remaining reply-code number
+
+
+
+Vaudreuil Standards Track [Page 1]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ space for delivery notification reporting will reduce the available
+ codes for new ESMTP extensions.
+
+ The following proposal is based on the SMTP theory of reply codes.
+ It adopts the success, permanent error, and transient error semantics
+ of the first value, with a further description and classification in
+ the second. This proposal re-distributes the classifications to
+ better distribute the error conditions, such as separating mailbox
+ from host errors.
+
+2. Status Codes
+
+ This document defines a new set of status codes to report mail system
+ conditions. These status codes are intended to be used for media and
+ language independent status reporting. They are not intended for
+ system specific diagnostics.
+
+ The syntax of the new status codes is defined as:
+
+ status-code = class "." subject "." detail
+ class = "2"/"4"/"5"
+ subject = 1*3digit
+ detail = 1*3digit
+
+ White-space characters and comments are NOT allowed within a status-
+ code. Each numeric sub-code within the status-code MUST be expressed
+ without leading zero digits.
+
+ Status codes consist of three numerical fields separated by ".". The
+ first sub-code indicates whether the delivery attempt was successful.
+ The second sub-code indicates the probable source of any delivery
+ anomalies, and the third sub-code indicates a precise error
+ condition.
+
+ The codes space defined is intended to be extensible only by
+ standards track documents. Mail system specific status codes should
+ be mapped as close as possible to the standard status codes. Servers
+ should send only defined, registered status codes. System specific
+ errors and diagnostics should be carried by means other than status
+ codes.
+
+ New subject and detail codes will be added over time. Because the
+ number space is large, it is not intended that published status codes
+ will ever be redefined or eliminated. Clients should preserve the
+ extensibility of the code space by reporting the general error
+ described in the subject sub-code when the specific detail is
+ unrecognized.
+
+
+
+
+Vaudreuil Standards Track [Page 2]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ The class sub-code provides a broad classification of the status.
+ The enumerated values the class are defined as:
+
+ 2.X.X Success
+
+ Success specifies that the DSN is reporting a positive delivery
+ action. Detail sub-codes may provide notification of
+ transformations required for delivery.
+
+ 4.X.X Persistent Transient Failure
+
+ A persistent transient failure is one in which the message as
+ sent is valid, but some temporary event prevents the successful
+ sending of the message. Sending in the future may be successful.
+
+ 5.X.X Permanent Failure
+
+ A permanent failure is one which is not likely to be resolved by
+ resending the message in the current form. Some change to the
+ message or the destination must be made for successful delivery.
+
+ A client must recognize and report class sub-code even where
+ subsequent subject sub-codes are unrecognized.
+
+ The subject sub-code classifies the status. This value applies to
+ each of the three classifications. The subject sub-code, if
+ recognized, must be reported even if the additional detail provided
+ by the detail sub-code is not recognized. The enumerated values for
+ the subject sub-code are:
+
+ X.0.X Other or Undefined Status
+
+ There is no additional subject information available.
+
+ X.1.X Addressing Status
+
+ The address status reports on the originator or destination
+ address. It may include address syntax or validity. These
+ errors can generally be corrected by the sender and retried.
+
+ X.2.X Mailbox Status
+
+ Mailbox status indicates that something having to do with the
+ mailbox has cause this DSN. Mailbox issues are assumed to be
+ under the general control of the recipient.
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 3]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.3.X Mail System Status
+
+ Mail system status indicates that something having to do
+ with the destination system has caused this DSN. System
+ issues are assumed to be under the general control of the
+ destination system administrator.
+
+ X.4.X Network and Routing Status
+
+ The networking or routing codes report status about the
+ delivery system itself. These system components include any
+ necessary infrastructure such as directory and routing
+ services. Network issues are assumed to be under the
+ control of the destination or intermediate system
+ administrator.
+
+ X.5.X Mail Delivery Protocol Status
+
+ The mail delivery protocol status codes report failures
+ involving the message delivery protocol. These failures
+ include the full range of problems resulting from
+ implementation errors or an unreliable connection. Mail
+ delivery protocol issues may be controlled by many parties
+ including the originating system, destination system, or
+ intermediate system administrators.
+
+ X.6.X Message Content or Media Status
+
+ The message content or media status codes report failures
+ involving the content of the message. These codes report
+ failures due to translation, transcoding, or otherwise
+ unsupported message media. Message content or media issues
+ are under the control of both the sender and the receiver,
+ both of whom must support a common set of supported
+ content-types.
+
+ X.7.X Security or Policy Status
+
+ The security or policy status codes report failures
+ involving policies such as per-recipient or per-host
+ filtering and cryptographic operations. Security and policy
+ status issues are assumed to be under the control of either
+ or both the sender and recipient. Both the sender and
+ recipient must permit the exchange of messages and arrange
+ the exchange of necessary keys and certificates for
+ cryptographic operations.
+
+
+
+
+
+Vaudreuil Standards Track [Page 4]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+3. Enumerated Status Codes
+
+ The following section defines and describes the detail sub-code. The
+ detail value provides more information about the status and is
+ defined relative to the subject of the status.
+
+ 3.1 Other or Undefined Status
+
+ X.0.0 Other undefined Status
+
+ Other undefined status is the only undefined error code. It
+ should be used for all errors for which only the class of the
+ error is known.
+
+ 3.2 Address Status
+
+ X.1.0 Other address status
+
+ Something about the address specified in the message caused
+ this DSN.
+
+ X.1.1 Bad destination mailbox address
+
+ The mailbox specified in the address does not exist. For
+ Internet mail names, this means the address portion to the
+ left of the "@" sign is invalid. This code is only useful
+ for permanent failures.
+
+ X.1.2 Bad destination system address
+
+ The destination system specified in the address does not
+ exist or is incapable of accepting mail. For Internet mail
+ names, this means the address portion to the right of the
+ "@" is invalid for mail. This codes is only useful for
+ permanent failures.
+
+ X.1.3 Bad destination mailbox address syntax
+
+ The destination address was syntactically invalid. This can
+ apply to any field in the address. This code is only useful
+ for permanent failures.
+
+ X.1.4 Destination mailbox address ambiguous
+
+ The mailbox address as specified matches one or more
+ recipients on the destination system. This may result if a
+ heuristic address mapping algorithm is used to map the
+ specified address to a local mailbox name.
+
+
+
+Vaudreuil Standards Track [Page 5]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.1.5 Destination address valid
+
+ This mailbox address as specified was valid. This status
+ code should be used for positive delivery reports.
+
+ X.1.6 Destination mailbox has moved, No forwarding address
+
+ The mailbox address provided was at one time valid, but mail
+ is no longer being accepted for that address. This code is
+ only useful for permanent failures.
+
+ X.1.7 Bad sender's mailbox address syntax
+
+ The sender's address was syntactically invalid. This can
+ apply to any field in the address.
+
+ X.1.8 Bad sender's system address
+
+ The sender's system specified in the address does not exist
+ or is incapable of accepting return mail. For domain names,
+ this means the address portion to the right of the "@" is
+ invalid for mail.
+
+ 3.3 Mailbox Status
+
+ X.2.0 Other or undefined mailbox status
+
+ The mailbox exists, but something about the destination
+ mailbox has caused the sending of this DSN.
+
+ X.2.1 Mailbox disabled, not accepting messages
+
+ The mailbox exists, but is not accepting messages. This may
+ be a permanent error if the mailbox will never be re-enabled
+ or a transient error if the mailbox is only temporarily
+ disabled.
+
+ X.2.2 Mailbox full
+
+ The mailbox is full because the user has exceeded a
+ per-mailbox administrative quota or physical capacity. The
+ general semantics implies that the recipient can delete
+ messages to make more space available. This code should be
+ used as a persistent transient failure.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 6]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.2.3 Message length exceeds administrative limit
+
+ A per-mailbox administrative message length limit has been
+ exceeded. This status code should be used when the
+ per-mailbox message length limit is less than the general
+ system limit. This code should be used as a permanent
+ failure.
+
+ X.2.4 Mailing list expansion problem
+
+ The mailbox is a mailing list address and the mailing list
+ was unable to be expanded. This code may represent a
+ permanent failure or a persistent transient failure.
+
+ 3.4 Mail system status
+
+ X.3.0 Other or undefined mail system status
+
+ The destination system exists and normally accepts mail, but
+ something about the system has caused the generation of this
+ DSN.
+
+ X.3.1 Mail system full
+
+ Mail system storage has been exceeded. The general
+ semantics imply that the individual recipient may not be
+ able to delete material to make room for additional
+ messages. This is useful only as a persistent transient
+ error.
+
+ X.3.2 System not accepting network messages
+
+ The host on which the mailbox is resident is not accepting
+ messages. Examples of such conditions include an immanent
+ shutdown, excessive load, or system maintenance. This is
+ useful for both permanent and permanent transient errors.
+
+ X.3.3 System not capable of selected features
+
+ Selected features specified for the message are not
+ supported by the destination system. This can occur in
+ gateways when features from one domain cannot be mapped onto
+ the supported feature in another.
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 7]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.3.4 Message too big for system
+
+ The message is larger than per-message size limit. This
+ limit may either be for physical or administrative reasons.
+ This is useful only as a permanent error.
+
+ X.3.5 System incorrectly configured
+
+ The system is not configured in a manner which will permit
+ it to accept this message.
+
+ 3.5 Network and Routing Status
+
+ X.4.0 Other or undefined network or routing status
+
+ Something went wrong with the networking, but it is not
+ clear what the problem is, or the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.4.1 No answer from host
+
+ The outbound connection attempt was not answered, either
+ because the remote system was busy, or otherwise unable to
+ take a call. This is useful only as a persistent transient
+ error.
+
+ X.4.2 Bad connection
+
+ The outbound connection was established, but was otherwise
+ unable to complete the message transaction, either because
+ of time-out, or inadequate connection quality. This is
+ useful only as a persistent transient error.
+
+ X.4.3 Directory server failure
+
+ The network system was unable to forward the message,
+ because a directory server was unavailable. This is useful
+ only as a persistent transient error.
+
+ The inability to connect to an Internet DNS server is one
+ example of the directory server failure error.
+
+ X.4.4 Unable to route
+
+ The mail system was unable to determine the next hop for the
+ message because the necessary routing information was
+ unavailable from the directory server. This is useful for
+ both permanent and persistent transient errors.
+
+
+
+Vaudreuil Standards Track [Page 8]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ A DNS lookup returning only an SOA (Start of Administration)
+ record for a domain name is one example of the unable to
+ route error.
+
+ X.4.5 Mail system congestion
+
+ The mail system was unable to deliver the message because
+ the mail system was congested. This is useful only as a
+ persistent transient error.
+
+ X.4.6 Routing loop detected
+
+ A routing loop caused the message to be forwarded too many
+ times, either because of incorrect routing tables or a user
+ forwarding loop. This is useful only as a persistent
+ transient error.
+
+ X.4.7 Delivery time expired
+
+ The message was considered too old by the rejecting system,
+ either because it remained on that host too long or because
+ the time-to-live value specified by the sender of the
+ message was exceeded. If possible, the code for the actual
+ problem found when delivery was attempted should be returned
+ rather than this code. This is useful only as a persistent
+ transient error.
+
+ 3.6 Mail Delivery Protocol Status
+
+ X.5.0 Other or undefined protocol status
+
+ Something was wrong with the protocol necessary to deliver
+ the message to the next hop and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.5.1 Invalid command
+
+ A mail transaction protocol command was issued which was
+ either out of sequence or unsupported. This is useful only
+ as a permanent error.
+
+ X.5.2 Syntax error
+
+ A mail transaction protocol command was issued which could
+ not be interpreted, either because the syntax was wrong or
+ the command is unrecognized. This is useful only as a
+ permanent error.
+
+
+
+
+Vaudreuil Standards Track [Page 9]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.5.3 Too many recipients
+
+ More recipients were specified for the message than could
+ have been delivered by the protocol. This error should
+ normally result in the segmentation of the message into two,
+ the remainder of the recipients to be delivered on a
+ subsequent delivery attempt. It is included in this list in
+ the event that such segmentation is not possible.
+
+ X.5.4 Invalid command arguments
+
+ A valid mail transaction protocol command was issued with
+ invalid arguments, either because the arguments were out of
+ range or represented unrecognized features. This is useful
+ only as a permanent error.
+
+ X.5.5 Wrong protocol version
+
+ A protocol version mis-match existed which could not be
+ automatically resolved by the communicating parties.
+
+ 3.7 Message Content or Message Media Status
+
+ X.6.0 Other or undefined media error
+
+ Something about the content of a message caused it to be
+ considered undeliverable and the problem cannot be well
+ expressed with any of the other provided detail codes.
+
+ X.6.1 Media not supported
+
+ The media of the message is not supported by either the
+ delivery protocol or the next system in the forwarding path.
+ This is useful only as a permanent error.
+
+ X.6.2 Conversion required and prohibited
+
+ The content of the message must be converted before it can
+ be delivered and such conversion is not permitted. Such
+ prohibitions may be the expression of the sender in the
+ message itself or the policy of the sending host.
+
+ X.6.3 Conversion required but not supported
+
+ The message content must be converted to be forwarded but
+ such conversion is not possible or is not practical by a
+ host in the forwarding path. This condition may result when
+ an ESMTP gateway supports 8bit transport but is not able to
+
+
+
+Vaudreuil Standards Track [Page 10]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ downgrade the message to 7 bit as required for the next hop.
+
+ X.6.4 Conversion with loss performed
+
+ This is a warning sent to the sender when message delivery
+ was successfully but when the delivery required a conversion
+ in which some data was lost. This may also be a permanant
+ error if the sender has indicated that conversion with loss
+ is prohibited for the message.
+
+ X.6.5 Conversion Failed
+
+ A conversion was required but was unsuccessful. This may be
+ useful as a permanent or persistent temporary notification.
+
+ 3.8 Security or Policy Status
+
+ X.7.0 Other or undefined security status
+
+ Something related to security caused the message to be
+ returned, and the problem cannot be well expressed with any
+ of the other provided detail codes. This status code may
+ also be used when the condition cannot be further described
+ because of security policies in force.
+
+ X.7.1 Delivery not authorized, message refused
+
+ The sender is not authorized to send to the destination.
+ This can be the result of per-host or per-recipient
+ filtering. This memo does not discuss the merits of any
+ such filtering, but provides a mechanism to report such.
+ This is useful only as a permanent error.
+
+ X.7.2 Mailing list expansion prohibited
+
+ The sender is not authorized to send a message to the
+ intended mailing list. This is useful only as a permanent
+ error.
+
+ X.7.3 Security conversion required but not possible
+
+ A conversion from one secure messaging protocol to another
+ was required for delivery and such conversion was not
+ possible. This is useful only as a permanent error.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 11]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.7.4 Security features not supported
+
+ A message contained security features such as secure
+ authentication which could not be supported on the delivery
+ protocol. This is useful only as a permanent error.
+
+ X.7.5 Cryptographic failure
+
+ A transport system otherwise authorized to validate or
+ decrypt a message in transport was unable to do so because
+ necessary information such as key was not available or such
+ information was invalid.
+
+ X.7.6 Cryptographic algorithm not supported
+
+ A transport system otherwise authorized to validate or
+ decrypt a message was unable to do so because the necessary
+ algorithm was not supported.
+
+ X.7.7 Message integrity failure
+
+ A transport system otherwise authorized to validate a
+ message was unable to do so because the message was
+ corrupted or altered. This may be useful as a permanent,
+ transient persistent, or successful delivery code.
+
+4. References
+
+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+ Delivery Status Notifications", RFC 1894, University of
+ Tennessee, Octel Network Services, January 1996.
+
+5. Security Considerations
+
+ This document describes a status code system with increased
+ precision. Use of these status codes may disclose additional
+ information about how an internal mail system is implemented beyond
+ that currently available.
+
+6. Acknowledgments
+
+ The author wishes to offer special thanks to Harald Alvestrand, Marko
+ Kaittola, and Keith Moore for their extensive review and constructive
+ suggestions.
+
+
+
+
+Vaudreuil Standards Track [Page 12]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+7. Author's Address
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17060 Dallas Parkway
+ Suite 214
+ Dallas, TX 75248-1905
+
+ Voice/Fax: +1-214-733-2722
+ EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 13]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+8. Appendix - Collected Status Codes
+
+ X.1.0 Other address status
+ X.1.1 Bad destination mailbox address
+ X.1.2 Bad destination system address
+ X.1.3 Bad destination mailbox address syntax
+ X.1.4 Destination mailbox address ambiguous
+ X.1.5 Destination mailbox address valid
+ X.1.6 Mailbox has moved
+ X.1.7 Bad sender's mailbox address syntax
+ X.1.8 Bad sender's system address
+
+ X.2.0 Other or undefined mailbox status
+ X.2.1 Mailbox disabled, not accepting messages
+ X.2.2 Mailbox full
+ X.2.3 Message length exceeds administrative limit.
+ X.2.4 Mailing list expansion problem
+
+ X.3.0 Other or undefined mail system status
+ X.3.1 Mail system full
+ X.3.2 System not accepting network messages
+ X.3.3 System not capable of selected features
+ X.3.4 Message too big for system
+
+ X.4.0 Other or undefined network or routing status
+ X.4.1 No answer from host
+ X.4.2 Bad connection
+ X.4.3 Routing server failure
+ X.4.4 Unable to route
+ X.4.5 Network congestion
+ X.4.6 Routing loop detected
+ X.4.7 Delivery time expired
+
+ X.5.0 Other or undefined protocol status
+ X.5.1 Invalid command
+ X.5.2 Syntax error
+ X.5.3 Too many recipients
+ X.5.4 Invalid command arguments
+ X.5.5 Wrong protocol version
+
+ X.6.0 Other or undefined media error
+ X.6.1 Media not supported
+ X.6.2 Conversion required and prohibited
+ X.6.3 Conversion required but not supported
+ X.6.4 Conversion with loss performed
+ X.6.5 Conversion failed
+
+
+
+
+
+Vaudreuil Standards Track [Page 14]
+
+RFC 1893 Mail System Status Codes January 1996
+
+
+ X.7.0 Other or undefined security status
+ X.7.1 Delivery not authorized, message refused
+ X.7.2 Mailing list expansion prohibited
+ X.7.3 Security conversion required but not possible
+ X.7.4 Security features not supported
+ X.7.5 Cryptographic failure
+ X.7.6 Cryptographic algorithm not supported
+ X.7.7 Message integrity failure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 15]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1893.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1985.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1985.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1985.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1985.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,396 @@
+
+
+
+
+
+Network Working Group J. De Winter
+Request for Comments: 1985 Wildbear Consulting, Inc.
+Category: Standards Track August 1996
+
+
+ SMTP Service Extension
+ for Remote Message Queue Starting
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+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
+ start the processing of its queues for messages to go to a given
+ host. This extension is meant to be used in startup conditions as
+ well as for mail nodes that have transient connections to their
+ service providers.
+
+1. Introduction
+
+ The TURN command was a valid attempt to address the problem of having
+ to start the processing for the mail queue on a remote machine.
+ However, the TURN command presents a large security loophole. As
+ there is no verification of the remote host name, the TURN command
+ could be used by a rogue system to download the mail for a site other
+ than itself.
+
+ Therefore, this memo introduces the ETRN command. This command uses
+ the mechanism defined in [4] to define extensions to the SMTP service
+ whereby a client ("sender-SMTP") may request that the server
+ ("receiver-SMTP") start the processing of its mail queues for
+ messages that are waiting at the server for the client machine. If
+ any messages are at the server for the client, then the server should
+ create a new SMTP session and send the messages at that time.
+
+
+
+
+
+
+
+
+
+
+De Winter Standards Track [Page 1]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+2. Framework for the ETRN Extension
+
+ The following service extension is therefore defined:
+
+ (1) the name of the SMTP service extension is "Remote Queue
+ Processing Declaration";
+
+ (2) the EHLO keyword value associated with this extension is "ETRN",
+ with no associated parameters;
+
+ (3) one additional verb, ETRN, with a single parameter that
+ specifies the name of the client(s) to start processing for;
+
+ (4) 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 Remote Queue Processing Declaration service extension
+
+ To save money, many small companies want to only maintain transient
+ connections to their service providers. In addition, there are some
+ situations where the client sites depend on their mail arriving
+ quickly, so forcing the queues on the server belonging to their
+ service provider may be more desirable than waiting for the retry
+ timeout to occur.
+
+ Both of these situations could currently be fixed using the TURN
+ command defined in [1], if it were not for a large security loophole
+ in the TURN command. As it stands, the TURN command will reverse the
+ direction of the SMTP connection and assume that the remote host is
+ being honest about what its name is. The security loophole is that
+ there is no documented stipulation for checking the authenticity of
+ the remote host name, as given in the HELO or EHLO command. As such,
+ most SMTP and ESMTP implementations do not implement the TURN command
+ to avoid this security loophole.
+
+ This has been addressed in the design of the ETRN command. This
+ extended turn command was written with the points in the first
+ paragraph in mind, yet paying attention to the problems that
+ currently exist with the TURN command. The security loophole is
+ avoided by asking the server to start a new connection aimed at the
+ specified client.
+
+ In this manner, the server has a lot more certainty that it is
+ talking to the correct SMTP client. This mechanism can just be seen
+ as a more immediate version of the retry queues that appear in most
+ SMTP implementations. In addition, as this command will take a
+
+
+
+De Winter Standards Track [Page 2]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+ single parameter, the name of the remote host(s) to start the queues
+ for, the server can decide whether it wishes to respect the request
+ or deny it for any local administrative reasons.
+
+4. Definitions
+
+ Remote queue processing means that using an SMTP or ESMTP connection,
+ the client may request that the server start to process parts of its
+ messaging queue. This processing is performed using the existing
+ SMTP infrastructure and will occur at some point after the processing
+ is initiated.
+
+ The server host is the node that is responding to the ETRN
+ command.
+
+ The client host is the node that is initiating the ETRN command.
+
+ The remote host name is defined to be a plain-text field that
+ specifies a name for the remote host(s). This remote host name may
+ also include an alias for the specified remote host or special
+ commands to identify other types of queues.
+
+5. The extended ETRN command
+
+ The extended ETRN command is issued by the client host when it wishes
+ to start the SMTP queue processing of a given server host. The
+ syntax of this command is as follows:
+
+ ETRN [<option character>]<node name><CR><LF>
+
+ This command may be issued at any time once a session is established,
+ as long as there is not a transaction occuring. Thus, this command
+ is illegal between a MAIL FROM: command and the end of the DATA
+ commands and responses.
+
+ The specified node name must be a fully qualified domain name for the
+ node, which may refer to a CNAME or MX pointer in the DNS. If an
+ alias is used for the node, multiple ETRN commands may be needed to
+ start the processing for the node as it may be listed at the remote
+ site under multiple names. This can also be addressed using the
+ options discussed in section 5.3.
+
+ The option character under normal circumstances is not used.
+
+
+
+
+
+
+
+
+De Winter Standards Track [Page 3]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+5.1 Server action on receipt of the extended ETRN command
+
+ When the server host receives the ETRN command, it should have a look
+ at the node name that is specified in the command and make a local
+ decision if it should honour the request. If not, the appropriate
+ error codes should be returned to the client.
+
+ Otherwise, the server host should force its retry queues to start
+ sending messages to that remote site, using another SMTP connection.
+ At the moment, there is no requirement that a connection must occur,
+ or that the connection must occur within a given time frame. This
+ should be noted in the case where there are no messages for the
+ client host at the server host and only the 250 response is used.
+
+ Since the processing of the queues may take an indeterminate amount
+ of time, this command should return immediately with a response to
+ the client host. The valid return codes for this command are:
+
+ 250 OK, queuing for node <x> started
+ 251 OK, no messages waiting for node <x>
+ 252 OK, pending messages for node <x> started
+ 253 OK, <n> pending messages for node <x> started
+ 458 Unable to queue messages for node <x>
+ 459 Node <x> not allowed: <reason>
+ 500 Syntax Error
+ 501 Syntax Error in Parameters
+
+ The 250 response code does not indicate that messages will be sent to
+ the system in question, just that the queue has been started and some
+ action will occur. If the server is capable of supporting it, the
+ 251, 252 or 253 response codes should be used to give more
+ information to the client side. In this case, if there are messages
+ waiting for the client side node, a check can be performed using
+ these responses codes as an indication of when there are no more
+ pending messages in the queue for that node.
+
+ The 458 and 459 result codes should be used to give more information
+ back to the client host as to why the action was not performed. If
+ the syntax of the request is not correct, then the 500 and 501 result
+ codes should be used.
+
+5.2 Client action on receiving response to extended ETRN command
+
+ If one of the 500 level error codes (550 or 551) are sent, the client
+ should assume that the protocol is not supported in the remote host
+ or that the protocol has not been implemented correctly on either the
+ client or server host. In this case, multiple ETRN commands (dealing
+ with the aliases for the system) should not be sent.
+
+
+
+De Winter Standards Track [Page 4]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+ If the 250 response is received, then the client host can assume that
+ the server host found its request to be satisfactory and it will send
+ any queued messages. This process may involve going through a very
+ large retry queue, and may take some time.
+
+ If the 400 level response is received, then the client can assume
+ that the server supports the command, but for some local reason does
+ not want to accept the ETRN command as is. In most cases, it will
+ mean that there is a list of nodes that it will accept the command
+ from and the current client is not on that list. The 459 response
+ code is presented to allow for a more in-depth reason as to why the
+ remote queuing cannot be started.
+
+5.3 Use Of ETRN to release mail for a subdomain or queue
+
+ If the requesting server wishes to release all of the mail for a
+ given subdomain, a variation on the ETRN command can be used. To
+ perform this request, the option character '@' should be used in
+ front of the node name. In this manner, any domain names that are
+ formed with a suffix of the specified node name are released.
+
+ For example, if the command ETRN @foo.com was issued, then any
+ accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
+ may be released. It should be noted that the receiving side of the
+ ETRN command should make a decision based on the client in question
+ and only allow certain combinations for each of the nodes. This is
+ more of a security issue than anything else.
+
+ In a similar vein, it might be necessary under some circumstances to
+ release a certain queue, where that queue does not correspond to a
+ given domain name. To this end, the option character '#' can be used
+ to force the processing of a given queue. In this case, the node
+ name would be used as a queue name instead, and its syntactical
+ structure would be dependant on the receiving server. An example of
+ this would be using the command ETRN #uucp to force the flush of a
+ UUCP queue. Note that the use of this option is entirely a local
+ matter and there is no way for a client to find a list of any such
+ queues that exist.
+
+6. Minimal usage
+
+ A "minimal" client may use this extension with its host name to start
+ the queues on the server host. This minimal usage will not handle
+ cases where mail for 'x.y' is sent to 's.x.y'.
+
+ A minimal server may use this extensions to start the processing of
+ the queues for all remote sites. In this case, the 458 error
+ response will not be seen, and it should always return the 250
+
+
+
+De Winter Standards Track [Page 5]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+ response as it will always try and start the processing for any
+ request.
+
+7. Example
+
+ The following example illustrates the use of remote queue processing
+ with some permanent and temporary failures.
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+ C: EHLO ymir.claremont.edu
+ S: 250-sigurd.innosoft.com
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250 ETRN
+ C: ETRN
+ S: 500 Syntax Error
+ C: ETRN localname
+ S: 501 Syntax Error in Parameters
+ C: ETRN uu.net
+ S: 458 Unable to queue messages for node uu.net
+ ...
+
+ C: ETRN sigurd.innosoft.com
+ S: 250 OK, queuing for node sigurd.innosoft.com started
+ C: ETRN innosoft.com
+ S: 250 OK, queuing for node innosoft.com started
+
+ OR
+
+ C: ETRN sigurd.innosoft.com
+ S: 251 OK, no messages waiting for node sigurd.innosoft.com
+ C: ETRN innosoft.com
+ S: 252 OK, pending messages for node innosoft.com started
+ C: ETRN mysoft.com
+ S: 253 OK, 14 pending messages for node mysoft.com started
+
+ ...
+ C: ETRN foo.bar
+ S: 459 Node foo.bar not allowed: Unable to resolve name.
+ ...
+ C: QUIT
+ S: 250 Goodbye
+
+
+
+
+
+
+
+De Winter Standards Track [Page 6]
+
+RFC 1985 SMTP Service Extension - ETRN August 1996
+
+
+8. Security Considerations
+
+ This command does not compromise any security considerations of any
+ existing SMTP or ESMTP protocols as it merely shortens the time that
+ a client needs to wait before their messages are retried.
+
+ Precautions should be taken to make sure that any client server can
+ only use the @ and # option characters for systems that make sense.
+ Failure to implement some kind of sanity checking on the parameters
+ could lead to congestion. This would be evident if a person asking
+ to release @com, which would release mail for any address that ended
+ with com.
+
+9. Acknowledgements
+
+ This document was created with lots of support from the users of our
+ products, who have given some input to the functionality that they
+ would like to see in the software that they bought.
+
+10. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [2] 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.
+
+11. Author's Address
+
+ Jack De Winter
+ Wildbear Consulting, Inc.
+ 17 Brock Street
+ Kitchener, Ontario, Canada
+ N2M 1X2
+
+ Phone: +1 519 576 3873
+ EMail: jack@wildbear.on.ca
+
+
+
+
+
+
+
+
+
+
+
+De Winter Standards Track [Page 7]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1985.txt
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org