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 [26/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc0821.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc0974.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc0974.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc0974.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc0974.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,365 @@
+
+Network Working Group Craig Partridge
+Request for Comments: 974 CSNET CIC BBN Laboratories Inc
+ January 1986
+
+ MAIL ROUTING AND THE DOMAIN SYSTEM
+
+
+Status of this Memo
+
+ This RFC presents a description of how mail systems on the Internet
+ are expected to route messages based on information from the domain
+ system described in RFCs 882, 883 and 973. Distribution of this memo
+ is unlimited.
+
+Introduction
+
+ The purpose of this memo is to explain how mailers are to decide how
+ to route a message addressed to a given Internet domain name. This
+ involves a discussion of how mailers interpret MX RRs, which are used
+ for message routing. Note that this memo makes no statement about
+ how mailers are to deal with MB and MG RRs, which are used for
+ interpreting mailbox names.
+
+ Under RFC-882 and RFC-883 certain assumptions about mail addresses
+ have been changed. Up to now, one could usually assume that if a
+ message was addressed to a mailbox, for example, at LOKI.BBN.COM,
+ that one could just open an SMTP connection to LOKI.BBN.COM and pass
+ the message along. This system broke down in certain situations,
+ such as for certain UUCP and CSNET hosts which were not directly
+ attached to the Internet, but these hosts could be handled as special
+ cases in configuration files (for example, most mailers were set up
+ to automatically forward mail addressed to a CSNET host to
+ CSNET-RELAY.ARPA).
+
+ Under domains, one cannot simply open a connection to LOKI.BBN.COM,
+ but must instead ask the domain system where messages to LOKI.BBN.COM
+ are to be delivered. And the domain system may direct a mailer to
+ deliver messages to an entirely different host, such as SH.CS.NET.
+ Or, in a more complicated case, the mailer may learn that it has a
+ choice of routes to LOKI.BBN.COM. This memo is essentially a set of
+ guidelines on how mailers should behave in this more complex world.
+
+ Readers are expected to be familiar with RFCs 882, 883, and the
+ updates to them (e.g., RFC-973).
+
+
+
+
+
+
+
+
+
+Partridge [Page 1]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+What the Domain Servers Know
+
+ The domain servers store information as a series of resource records
+ (RRs), each of which contains a particular piece of information about
+ a given domain name (which is usually, but not always, a host). The
+ simplest way to think of a RR is as a typed pair of datum, a domain
+ name matched with relevant data, and stored with some additional type
+ information to help systems determine when the RR is relevant. For
+ the purposes of message routing, the system stores RRs known as MX
+ RRs. Each MX matches a domain name with two pieces of data, a
+ preference value (an unsigned 16-bit integer), and the name of a
+ host. The preference number is used to indicate in what order the
+ mailer should attempt deliver to the MX hosts, with the lowest
+ numbered MX being the one to try first. Multiple MXs with the same
+ preference are permitted and have the same priority.
+
+ In addition to mail information, the servers store certain other
+ types of RR's which mailers may encounter or choose to use. These
+ are: the canonical name (CNAME) RR, which simply states that the
+ domain name queried for is actually an alias for another domain name,
+ which is the proper, or canonical, name; and the Well Known Service
+ (WKS) RR, which stores information about network services (such as
+ SMTP) a given domain name supports.
+
+General Routing Guidelines
+
+ Before delving into a detailed discussion of how mailers are expected
+ to do mail routing, it would seem to make sense to give a brief
+ overview of how this memo is approaching the problems that routing
+ poses.
+
+ The first major principle is derived from the definition of the
+ preference field in MX records, and is intended to prevent mail
+ looping. If the mailer is on a host which is listed as an MX for the
+ destination host, the mailer may only deliver to an MX which has a
+ lower preference count than its own host.
+
+ It is also possible to cause mail looping because routing information
+ is out of date or incomplete. Out of date information is only a
+ problem when domain tables are changed. The changes will not be
+ known to all affected hosts until their resolver caches time out.
+ There is no way to ensure that this will not happen short of
+ requiring mailers and their resolvers to always send their queries to
+ an authoritative server, and never use data stored in a cache. This
+ is an impractical solution, since eliminating resolver caching would
+ make mailing inordinately expensive. What is more, the out-of-date
+ RR problem should not happen if, when a domain table is changed,
+
+
+Partridge [Page 2]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+ affected hosts (those in the list of MXs) have their resolver caches
+ flushed. In other words, given proper precautions, mail looping as a
+ result of domain information should be avoidable, without requiring
+ mailers to query authoritative servers. (The appropriate precaution
+ is to check with a host's administrator before adding that host to a
+ list of MXs).
+
+ The incomplete data problem also requires some care when handling
+ domain queries. If the answer section of a query is incomplete
+ critical MX RRs may be left out. This may result in mail looping, or
+ in a message being mistakenly labelled undeliverable. As a result,
+ mailers may only accept responses from the domain system which have
+ complete answer sections. Note that this entire problem can be
+ avoided by only using virtual circuits for queries, but since this
+ situation is likely to be very rare and datagrams are the preferred
+ way to interact with the domain system, implementors should probably
+ just ensure that their mailer will repeat a query with virtual
+ circuits should the truncation bit ever be set.
+
+Determining Where to Send a Message
+
+ The explanation of how mailers should decide how to route a message
+ is discussed in terms of the problem of a mailer on a host with
+ domain name LOCAL trying to deliver a message addressed to the domain
+ name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
+ correct domain names. Furthermore, LOCAL is assumed to be the
+ official name for the host on which the mailer resides (i.e., it is
+ not a alias).
+
+Issuing a Query
+
+ The first step for the mailer at LOCAL is to issue a query for MX RRs
+ for REMOTE. It is strongly urged that this step be taken every time
+ a mailer attempts to send the message. The hope is that changes in
+ the domain database will rapidly be used by mailers, and thus domain
+ administrators will be able to re-route in-transit messages for
+ defective hosts by simply changing their domain databases.
+
+ Certain responses to the query are considered errors:
+
+ Getting no response to the query. The domain server the mailer
+ queried never sends anything back. (This is distinct from an
+ answer which contains no answers to the query, which is not an
+ error).
+
+ Getting a response in which the truncation field of the header is
+
+
+
+Partridge [Page 3]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+ set. (Recall discussion of incomplete queries above). Mailers
+ may not use responses of this type, and should repeat the query
+ using virtual circuits instead of datagrams.
+
+ Getting a response in which the response code is non-zero.
+
+ Mailers are expected to do something reasonable in the face of an
+ error. The behaviour for each type of error is not specified here,
+ but implementors should note that different types of errors should
+ probably be treated differently. For example, a response code of
+ "non-existent domain" should probably cause the message to be
+ returned to the sender as invalid, while a response code of "server
+ failure" should probably cause the message to be retried later.
+
+ There is one other special case. If the response contains an answer
+ which is a CNAME RR, it indicates that REMOTE is actually an alias
+ for some other domain name. The query should be repeated with the
+ canonical domain name.
+
+ If the response does not contain an error response, and does not
+ contain aliases, its answer section should be a (possibly zero
+ length) list of MX RRs for domain name REMOTE (or REMOTE's true
+ domain name if REMOTE was a alias). The next section describes how
+ this list is interpreted.
+
+Interpreting the List of MX RRs
+
+ NOTE: This section only discusses how mailers choose which names to
+ try to deliver a message to, working from a list of RR's. It does
+ not discuss how the mailers actually make delivery. Where ever
+ delivering a message is mentioned, all that is meant is that the
+ mailer should do whatever it needs to do to transfer a message to a
+ remote site, given a domain name for that site. (For example, an
+ SMTP mailer will try to get an address for the domain name, which
+ involves another query to the domain system, and then, if it gets an
+ address, connect to the SMTP TCP port). The mechanics of actually
+ transferring the message over the network to the address associated
+ with a given domain name is not within the scope of this memo.
+
+ It is possible that the list of MXs in the response to the query will
+ be empty. This is a special case. If the list is empty, mailers
+ should treat it as if it contained one RR, an MX RR with a preference
+ value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
+ MX). In addition, the mailer should do no further processing on the
+ list, but should attempt to deliver the message to REMOTE. The idea
+
+
+
+
+Partridge [Page 4]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+ here is that if a domain fails to advertise any information about a
+ particular name we will give it the benefit of the doubt and attempt
+ delivery.
+
+ If the list is not empty, the mailer should remove irrelevant RR's
+ from the list according to the following steps. Note that the order
+ is significant.
+
+ For each MX, a WKS query should be issued to see if the domain
+ name listed actually supports the mail service desired. MX RRs
+ which list domain names which do not support the service should be
+ discarded. This step is optional, but strongly encouraged.
+
+ If the domain name LOCAL is listed as an MX RR, all MX RRs with a
+ preference value greater than or equal to that of LOCAL's must be
+ discarded.
+
+ After removing irrelevant RRs, the list can again be empty. This is
+ now an error condition and can occur in several ways. The simplest
+ case is that the WKS queries have discovered that none of the hosts
+ listed supports the mail service desired. The message is thus deemed
+ undeliverable, though extremely persistent mail systems might want to
+ try a delivery to REMOTE's address (if it exists) before returning
+ the message. Another, more dangerous, possibility is that the domain
+ system believes that LOCAL is handling message for REMOTE, but the
+ mailer on LOCAL is not set up to handle mail for REMOTE. For
+ example, if the domain system lists LOCAL as the only MX for REMOTE,
+ LOCAL will delete all the entries in the list. But LOCAL is
+ presumably querying the domain system because it didn't know what to
+ do with a message addressed to REMOTE. Clearly something is wrong.
+ How a mailer chooses to handle these situations is to some extent
+ implementation dependent, and is thus left to the implementor's
+ discretion.
+
+ If the list of MX RRs is not empty, the mailer should try to deliver
+ the message to the MXs in order (lowest preference value tried
+ first). The mailer is required to attempt delivery to the lowest
+ valued MX. Implementors are encouraged to write mailers so that they
+ try the MXs in order until one of the MXs accepts the message, or all
+ the MXs have been tried. A somewhat less demanding system, in which
+ a fixed number of MXs is tried, is also reasonable. Note that
+ multiple MXs may have the same preference value. In this case, all
+ MXs at with a given value must be tried before any of a higher value
+ are tried. In addition, in the special case in which there are
+ several MXs with the lowest preference value, all of them should be
+ tried before a message is deemed undeliverable.
+
+
+
+Partridge [Page 5]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+Minor Special Issues
+
+ There are a couple of special issues left out of the preceding
+ section because they complicated the discussion. They are treated
+ here in no particular order.
+
+ Wildcard names, those containing the character '*' in them, may be
+ used for mail routing. There are likely to be servers on the network
+ which simply state that any mail to a domain is to be routed through
+ a relay. For example, at the time that this RFC is being written, all
+ mail to hosts in the domain IL is routed through RELAY.CS.NET. This
+ is done by creating a wildcard RR, which states that *.IL has an MX
+ of RELAY.CS.NET. This should be transparent to the mailer since the
+ domain servers will hide this wildcard match. (If it matches *.IL
+ with HUJI.IL for example, a domain server will return an RR
+ containing HUJI.IL, not *.IL). If by some accident a mailer receives
+ an RR with a wildcard domain name in its name or data section it
+ should discard the RR.
+
+ Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
+ a alias and the alias is listed in the MX records for REMOTE. (E.g.
+ REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
+ can be avoided if aliases are never used in the data section of MX
+ RRs.
+
+ Implementors should understand that the query and interpretation of
+ the query is only performed for REMOTE. It is not repeated for the
+ MX RRs listed for REMOTE. You cannot try to support more extravagant
+ mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX
+ for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
+ but this does not mean that UNIX.BBN.COM accepts any responsibility
+ for mail for .IL).
+
+ Finally, it should be noted that this is a standard for routing on
+ the Internet. Mailers serving hosts which lie on multiple networks
+ will presumably have to make some decisions about which network to
+ route through. This decision making is outside the scope of this
+ memo, although mailers may well use the domain system to help them
+ decide. However, once a mailer decides to deliver a message via the
+ Internet it must apply these rules to route the message.
+
+
+
+
+
+
+
+
+
+Partridge [Page 6]
+
+
+
+RFC 974 January 1986
+Mail Routing and the Domain System
+
+
+Examples
+
+ To illustrate the discussion above, here are three examples of how
+ mailers should route messages. All examples work with the following
+ database:
+
+ A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG
+ A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG
+ A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG
+ A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP
+
+ B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG
+ B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG
+ B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP
+
+ C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
+ C.EXAMP
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc0974.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1652.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1652.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1652.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1652.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,340 @@
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request for Comments: 1652 MCI
+Obsoletes: 1426 N. Freed, Editor
+Category: Standards Track Innosoft
+ M. Rose
+ Dover Beach Consulting, Inc.
+ E. Stefferud
+ Network Management Associates, Inc.
+ D. Crocker
+ Silicon Graphics, Inc.
+ July 1994
+
+
+ SMTP Service Extension for 8bit-MIMEtransport
+
+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
+ content body consisting of text containing octets outside of the US-
+ ASCII octet range (hex 00-7F) may be relayed using SMTP.
+
+1. Introduction
+
+ Although SMTP is widely and robustly deployed, various extensions
+ have been requested by parts of the Internet community. In
+ particular, a significant portion of the Internet community wishes to
+ exchange messages in which the content body consists of a MIME
+ message [3] containing arbitrary octet-aligned material. This memo
+ uses the mechanism described in [5] to define an extension to the
+ SMTP service whereby such contents may be exchanged. Note that this
+ extension does NOT eliminate the possibility of an SMTP server
+ limiting line length; servers are free to implement this extension
+ but nevertheless set a line length limit no lower than 1000 octets.
+ Given that this restriction still applies, this extension does NOT
+ provide a means for transferring unencoded binary via SMTP.
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 1]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+2. Framework for the 8bit MIME Transport Extension
+
+ The 8bit MIME transport extension is laid out as follows:
+
+ (1) the name of the SMTP service extension defined here is
+ 8bit-MIMEtransport;
+
+ (2) the EHLO keyword value associated with the extension is
+ 8BITMIME;
+
+ (3) no parameter is used with the 8BITMIME EHLO keyword;
+
+ (4) one optional parameter using the keyword BODY is added to
+ the MAIL FROM command. The value associated with this
+ parameter is a keyword indicating whether a 7bit message
+ (in strict compliance with [1]) or a MIME message (in
+ strict compliance with [3]) with arbitrary octet content
+ is being sent. The syntax of the value is as follows,
+ using the ABNF notation of [2]:
+
+ body-value ::= "7BIT" / "8BITMIME"
+
+ (5) no additional SMTP verbs are defined by this extension;
+ and,
+
+ (6) the next section specifies how support for the extension
+ affects the behavior of a server and client SMTP.
+
+3. The 8bit-MIMEtransport service extension
+
+ When a client SMTP wishes to submit (using the MAIL command) a
+ content body consisting of a MIME message containing arbitrary lines
+ of octet-aligned material, it first issues the EHLO command to the
+ server SMTP. If the server SMTP responds with code 250 to the EHLO
+ command, and the response includes the EHLO keyword value 8BITMIME,
+ then the server SMTP is indicating that it supports the extended MAIL
+ command and will accept MIME messages containing arbitrary octet-
+ aligned material.
+
+ The extended MAIL command is issued by a client SMTP when it wishes
+ to transmit a content body consisting of a MIME message containing
+ arbitrary lines of octet-aligned material. The syntax for this
+ command is identical to the MAIL command in [1], except that a BODY
+ parameter must appear after the address. Only one BODY parameter may
+ be used in a single MAIL command.
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 2]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ The complete syntax of this extended command is defined in [5]. The
+ esmtp-keyword is BODY and the syntax for esmtp-value is given by the
+ syntax for body-value shown above.
+
+ The value associated with the BODY parameter indicates whether the
+ content body which will be passed using the DATA command consists of
+ a MIME message containing some arbitrary octet-aligned material
+ ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").
+
+ A server which supports the 8-bit MIME transport service extension
+ shall preserve all bits in each octet passed using the DATA command.
+
+ Naturally, the usual SMTP data-stuffing algorithm applies so that a
+ content which contains the five-character sequence of
+
+ <CR> <LF> <DOT> <CR> <LF>
+
+ or a content that begins with the three-character sequence of
+
+ <DOT> <CR> <LF>
+
+ does not prematurely terminate the transfer of the content. Further,
+ it should be noted that the CR-LF pair immediately preceeding the
+ final dot is considered part of the content. Finally, although the
+ content body contains arbitrary lines of octet-aligned material, the
+ length of each line (number of octets between two CR-LF pairs), is
+ still subject to SMTP server line length restrictions (which may
+ allow as few as 1000 octets on a single line). This restriction means
+ that this extension MAY provide the necessary facilities for
+ transferring a MIME object with the 8BIT content-transfer-encoding,
+ it DOES NOT provide a means of transferring an object with the BINARY
+ content-transfer-encoding.
+
+ Once a server SMTP supporting the 8bit-MIMEtransport service
+ extension accepts a content body containing octets with the high-
+ order (8th) bit set, the server SMTP must deliver or relay the
+ content in such a way as to preserve all bits in each octet.
+
+ If a server SMTP does not support the 8-bit MIME transport extension
+ (either by not responding with code 250 to the EHLO command, or by
+ not including the EHLO keyword value 8BITMIME in its response), then
+ the client SMTP must not, under any circumstances, attempt to
+ transfer a content which contains characters outside the US-ASCII
+ octet range (hex 00-7F).
+
+ A client SMTP has two options in this case: first, it may implement a
+ gateway transformation to convert the message into valid 7bit MIME,
+ or second, or may treat this as a permanent error and handle it in
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 3]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ the usual manner for delivery failures. The specifics of the
+ transformation from 8bit MIME to 7bit MIME are not described by this
+ RFC; the conversion is nevertheless constrained in the following
+ ways:
+
+ (1) it must cause no loss of information; MIME transport
+ encodings must be employed as needed to insure this is
+ the case, and
+
+ (2) the resulting message must be valid 7bit MIME.
+
+4. Usage Example
+
+ The following dialogue illustrates the use of the 8bit-MIMEtransport
+ service extension:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250 8BITMIME
+ C: MAIL FROM:<ne...@ymir.claremont.edu> BODY=8BITMIME
+ S: 250 <ne...@ymir.claremont.edu>... Sender and 8BITMIME ok
+ C: RCPT TO:<mr...@dbc.mtview.ca.us>
+ S: 250 <mr...@dbc.mtview.ca.us>... Recipient ok
+ C: DATA
+ S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 OK
+ C: QUIT
+ S: 250 Goodbye
+
+5. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of [1].
+
+6. Acknowledgements
+
+ This document represents a synthesis of the ideas of many people and
+ reactions to the ideas and proposals of others. Randall Atkinson,
+ Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
+ and text sufficient to be considered co-authors. Other important
+ suggestions, text, or encouragement came from Harald Alvestrand, Jim
+ Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 4]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
+ Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John
+ Wagner, Rayan Zachariassen, and the contributions of the entire IETF
+ SMTP Working Group. Of course, none of the individuals are
+ necessarily responsible for the combination of ideas represented
+ here. Indeed, in some cases, the response to a particular criticism
+ was to accept the problem identification but to include an entirely
+ different solution from the one originally proposed.
+
+7. 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", RFC 1651, MCI, Innosoft, Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., Silicon
+ Graphics, Inc., July 1994.
+
+ [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+ 974, BBN, January 1986.
+
+8. Chair, Editor, and Authors' Addresses
+
+ John Klensin, WG Chair
+ MCI Data Services Division
+ 2100 Reston Parkway, 6th floor
+ Reston, VA 22091
+ USA
+
+ Phone:: 1 703 715 7361
+ Fax: +1 703 715 7435
+ EMail: klensin@mci.net
+
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 5]
+
+RFC 1652 SMTP 8bit-MIMEtransport July 1994
+
+
+ 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
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Moutain View, CA 94043-2186
+ USA
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+ Einar A. Stefferud
+ Network Management Associates, Inc.
+ 17301 Drey Lane
+ Huntington Beach, CA, 92647-5615
+ USA
+
+ Phone: +1 714 842 3711
+ Fax: +1 714 848 2091
+ EMail: stef@nma.com
+
+
+ Dave Crocker
+ Silicon Graphics, Inc.
+ 2011 N. Shoreline Blvd.
+ P.O. Box 7311
+ Mountain View, CA 94039
+ USA
+
+ Phone: +1 415 390 1804
+ Fax: +1 415 962 8404
+ EMail: dcrocker@sgi.com
+
+
+
+
+
+
+
+
+Klensin, Freed, Rose, Stefferud & Crocker [Page 6]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1652.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1830.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1830.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1830.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1830.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,452 @@
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 1830 Octel Network Services
+Category: Experimental August 1995
+
+
+ SMTP Service Extensions
+ for Transmission of Large
+ and Binary MIME Messages
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+1. Abstract
+
+ This memo defines two extensions to the SMTP service. The first
+ service enables a SMTP client and server to negotiate the use of an
+ alternate DATA command "BDAT" for efficiently sending large MIME
+ messages. The second extension takes advantage of the BDAT command
+ to permit the negotiated sending of unencoded binary data.
+
+2. Introduction
+
+ The MIME extensions to the Internet message protocol provides for the
+ transmission of many kinds of data which were previously unsupported
+ in Internet mail. Anticipating the need to more efficiently
+ transport the new media made possible with MIME, the SMTP protocol
+ has been extended to provide transport for new message types. RFC
+ 1426 defines one such extension for the transmission of unencoded 8
+ bit MIME messages [8BIT]. This service extension permits the
+ receiver SMTP to declare support for 8 bit body parts and the sender
+ to request 8 bit transmission of a particular message.
+
+ One expected result of the use of MIME is that the Internet mail
+ system will be expected to carry very large mail messages. In such
+ transactions, there is a need to eliminate the requirement that the
+ message be scanned for "CR LF . CR LF" sequences upon sending and
+ receiving to detect the end of message.
+
+ Independent of the need to send large messages, Internet mail is
+ increasingly multi-media there is a need to avoid the overhead of
+ base64 and quoted-printable encoding of binary objects sent using the
+ MIME message format over SMTP between hosts which support binary
+ message processing.
+
+
+
+
+Vaudreuil Experimental [Page 1]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+ This memo uses the mechanism defined in [ESMTP] to define two
+ extensions to the SMTP service whereby a client ("sender-SMTP") may
+ declare support for the message chunking transmission mode using the
+ BDAT command and support for the sending of Binary messages.
+
+3. Framework for the Large Message Extensions
+
+ The following service extension is hereby defined:
+
+ 1) The name of the data chunking service extension is
+ "CHUNKING".
+
+ 2) The EHLO keyword value associated with this extension is
+ "CHUNKING".
+
+ 3) A new SMTP verb is defined "BDAT" as an alternative to
+ the "DATA" command of [RFC821]. The BDAT verb takes two
+ arguments. The first argument indicates the length of the
+ binary data packet. The second optional argument indicates
+ that the data packet is the last.
+
+ bdat-cmd ::= "BDAT" SP chunk-size
+ [ SP end-marker ] CR LF
+ chunk-size ::= 1*DIGIT
+ end-marker ::= "LAST"
+
+
+ The CHUNKING service extension enables the use of the BDAT
+ alternative to the DATA command. This extension can be used for any
+ message, whether 7 bit, 8BITMIME or BINARYMIME.
+
+ When a client SMTP wishes to submit (using the MAIL command) a large
+ message using the CHUNKING extension, it first issues the EHLO
+ command to the server SMTP. If the server SMTP responds with code
+ 250 to the EHLO command, and the response includes the EHLO keyword
+ value CHUNKING, then the server SMTP is indicating that it supports
+ the BDAT command and will accept the sending of messages in chunks.
+
+ After all MAIL FROM and RCPT TO responses are collected and
+ processed, the message is sent using a series of BDAT commands. The
+ BDAT command takes one argument, the exact length of the data segment
+ in octets. The message data is sent immediately after the BDAT
+ command. Once the receiver-SMTP receives the specified number of
+ octets, it will return a 250 reply code.
+
+ The LAST parameter on the BDAT command indicates that this is the
+ last chunk of message data to be sent. Any BDAT command sent after
+ the BDAT LAST is illegal and must be replied to with a 503 "Bad
+
+
+
+Vaudreuil Experimental [Page 2]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+ sequence of commands" reply code. The state resulting from this error
+ is indeterminate. A RSET command must be sent to clear the
+ transaction before continuing.
+
+ A 250 response should be sent to each BDAT data block. If a 5XX code
+ is sent in response to a BDAT chunk the message should be considered
+ failed and, the sender SMTP must not send any additional BDAT
+ segments. If using the ESMTP pipelining extensions [PIPE], the
+ sender SMTP must complete the sending of the current segment and not
+ send any more BDATs. When streaming, the receiver SMTP must accept
+ and discard additional BDAT chunks after the failed BDAT. After
+ receiving a 5XX error in response to a BDAT command, the resulting
+ state is indeterminate. A RSET command must be issued to clear the
+ transaction before additional commands may be sent.
+
+ Note that an error on the receiver SMTP such as disk full or
+ imminent shutdown can only be reported after the BDAT segment has
+ been sent. It is therefore important to choose a reasonable chunk
+ size given the expected end to end bandwidth.
+
+ The RSET command when issued during after the first BDAT and before
+ the BDAT LAST clears all segments sent during that transaction and
+ resets the session.
+
+ DATA and BDAT commands cannot be used in the same transaction. If a
+ DATA statement is issued after a BDAT for the current transaction, a
+ 503 "Bad sequence of commands" must be issued. The state resulting
+ from this error is indeterminate. A RSET command must be sent to
+ clear the transaction before continuing. There is no prohibition on
+ using DATA and BDAT in the same session, so long as they are not
+ mixed in the same transaction.
+
+ The local storage size of a message may not accurately reflect the
+ actual size of the message sent due to local storage conventions. In
+ particular, text messages sent with the BDAT command must be sent in
+ the canonical MIME format with lines delimited with a <CR><LF>. It
+ may not be possible to convert the entire message to the canonical
+ format at once. Chunking provides a mechanism to convert the message
+ to canonical form, accurately count the bytes, and send the message a
+ single chunk at a time.
+
+ Note that correct byte counting is essential. If too many bytes
+ are indicated by the sender SMTP, the receiver SMTP will continue
+ to wait for the remainder of the data or will read the subsequent
+ command as additional message data. In the case where a portion
+ of the previous command was read as data, the parser will return a
+ syntax error when the incomplete command is read.
+
+
+
+
+Vaudreuil Experimental [Page 3]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+ If too few bytes are indicated by the sender SMTP, the receiver
+ SMTP will interpret the remainder of the message data as invalid
+ commands. Note that the remainder of the message data may be
+ binary and as such lexigraphical parsers must be prepared to
+ receive, process, and reject lines of arbitrary octets.
+
+4. Framework for the Binary Service Extension
+
+ The following service extension is hereby defined:
+
+ 1) The name of the binary service extension is "BINARYMIME".
+
+ 2) The EHLO keyword value associated with this extension is
+ "BINARYMIME".
+
+ 3) The BINARYMIME service extension can only be used with
+ the "CHUNKING" service extension.
+
+ 4) No parameter is used with the BINARYMIME keyword.
+
+ 5) One additional parameter to the BODY keyword defined
+ [8BIT] for the MAIL FROM command is defined, "BINARYMIME".
+ The value "BINARYMIME" associated with this parameter
+ indicates that this message is a Binary MIME message (in
+ strict compliance with [MIME]) with arbitrary octet content
+ being sent. The revised syntax of the value is as follows,
+ using the ABNF notation of [RFC822]:
+
+ body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
+
+ 6) No new verbs are defined for the BINARYMIME extension.
+
+ A sender SMTP may request that a binary MIME message be sent without
+ transport encoding by sending a BINARYMIME parameter with the MAIL
+ FROM command. When the receiver SMTP accepts a MAIL FROM command
+ with the BINARYMIME body type requested, it agrees to preserve all
+ bits in each octet passed using the BDAT command.
+
+ BINARYMIME cannot be used with the DATA command. If a DATA command
+ is issued after a MAIL FROM command containing the body-value of
+ "BINARYMIME", a 501 response should be sent. The resulting state
+ from this error condition is indeterminate and the transaction should
+ be reset with the RSET command.
+
+ It is important to note that when using BINARYMIME, it is
+ especially important to ensure that the MIME message itself is
+ properly formed. In particular, it is essential that text be
+ canonically encoded with each line properly terminated with <CR>
+
+
+
+Vaudreuil Experimental [Page 4]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+ <LF>. Any transformation of text into non-canonical MIME to
+ observe local storage conventions must be reversed before sending
+ as BINARYMIME. The usual line-oriented shortcuts will break if
+ used with BINARYMIME.
+
+ The syntax of the extended MAIL command is identical to the MAIL
+ command in [RFC821], except that a BODY parameter must appear after
+ the address. The complete syntax of this extended command is defined
+ in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value
+ is given by the syntax for body-value in [ESMTP].
+
+ If a receiver SMTP does not support the BINARYMIME message format
+ (either by not responding with code 250 to the EHLO command, or by
+ rejecting the BINARYMIME parameter to the MAIL FROM command, then the
+ client SMTP must not, under any circumstances, send binary data using
+ the DATA or BDAT commands.
+
+ If the receiver-SMTP does not support BINARYMIME and the message
+ content is a MIME object with a binary encoding, a client SMTP has
+ two options in this case: first, it may implement a gateway
+ transformation to convert the message into valid 7bit encoded MIME,
+ or second, it may treat this as a permanent error and handle it in
+ the usual manner for delivery failures. The specifics of the
+ transformation from Binary MIME to 7bit MIME are not described by
+ this RFC; the conversion is nevertheless constrained in the following
+ ways:
+
+ o The conversion must cause no loss of information; MIME
+ transport encodings must be employed as needed to insure this
+ is the case.
+
+ o The resulting message must be valid 7bit MIME.
+
+ As of present there are no mechanisms for converting a binary MIME
+ object into a 8 bit-MIME object. Such a transformation will require
+ the specification of a new MIME content-transfer-encoding, the
+ standardization of which is discouraged by [MIME].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Experimental [Page 5]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+5. Examples
+
+5.1 Simple Chunking
+
+ The following simple dialogue illustrates the use of the large
+ message extension to send a short psudo-RFC822 message to one
+ recipient using the CHUNKING extension:
+
+
+ R: <wait for connection on TCP port 25>
+ S: <open connection to server>
+ R: 220 cnri.reston.va.us SMTP service ready
+ S: EHLO ymir.claremont.edu
+ R: 250-cnri.reston.va.us says hello
+ R: 250 CHUNKING
+ S: MAIL FROM:<Sa...@Random.com>
+ R: 250 <Sa...@Random.com>... Sender ok
+ S: RCPT TO:<Su...@Random.com>
+ R: 250 <Su...@random.com>... Recipient ok
+ S: BDAT 69 LAST
+ S: To: Susan@random.com<CR><LF>
+ S: From: Sam@random.com<CR><LF>
+ S: Subject: This is a bodyless test message<CR><LF>
+ R: 250 Message OK, 69 octets received
+ S: QUIT
+ R: 221 Goodbye
+
+5.2 Pipelining Binarymime
+
+ The following dialogue illustrates the use of the large message
+ extension to send a BINARYMIME object to two recipients using the
+ CHUNKING and PIPELINING extensions:
+
+ R: <wait for connection on TCP port 25>
+ S: <open connection to server>
+ R: 220 cnri.reston.va.us SMTP service ready
+ S: EHLO ymir.claremont.edu
+ R: 250-cnri.reston.va.us says hello
+ R: 250-PIPELINING
+ R: 250-BINARYMIME
+ R: 250 CHUNKING
+ S: MAIL FROM:<ne...@ymir.claremont.edu> BODY=BINARYMIME
+ S: RCPT TO:<gv...@cnri.reston.va.us>
+ S: RCPT TO:<js...@cnri.reston.va.us>
+ R: 250 <ne...@ymir.claremont.edu>... Sender and BINARYMIME ok
+ R: 250 <gv...@cnri.reston.va.us>... Recipient ok
+ R: 250 <js...@cnri.reston.va.us>... Recipient ok
+ S: BDAT 100000
+
+
+
+Vaudreuil Experimental [Page 6]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+ S: (First 10000 octets of canonical MIME message data)
+ S: BDAT 324 LAST
+ S: (Remaining 324 octets of canonical MIME message data)
+ R: 250 100000 bytes received
+ R: 250 Message OK, 100324 octets received
+ S: QUIT
+ R: 221 Goodbye
+
+6. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of [RFC821], or otherwise
+ made possible by [MIME].
+
+7. Acknowledgments
+
+ This document is the result of numerous discussions in the IETF SMTP
+ Extensions Working Group and in particular due to the continued
+ advocacy of "chunking" by Neil Katin.
+
+8. References
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, USC/Information Sciences Institute, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
+
+ [ESMTP] 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.
+
+ [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
+ Stefferud, E., and D. Crocker, "SMTP Service Extension for
+ 8bit-MIMEtransport" RFC 1426, United Nations University,
+ Innosoft International, Inc., Dover Beach Consulting, Inc.,
+ Network Management Associates, Inc., The Branch Office,
+ February 1993.
+
+ [PIPE] Freed, N., "SMTP Service Extensions for Command
+ Pipelining", Innosoft International, Work in Progress.
+
+
+
+
+Vaudreuil Experimental [Page 7]
+
+RFC 1830 Binary and Large Message Transport August 1995
+
+
+9. Author's Address
+
+ Gregory M. Vaudreuil
+ Octel Network Services
+ 17060 Dallas Parkway
+ Suite 214
+ Dallas, TX 75248-1905
+
+ Voice/Fax: 214-733-2722
+ EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Experimental [Page 8]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1830.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/smtp/rfc1869.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/smtp/rfc1869.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/smtp/rfc1869.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/smtp/rfc1869.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,620 @@
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request For Comments: 1869 MCI
+STD: 10 N. Freed, Editor
+Obsoletes: 1651 Innosoft International, Inc.
+Category: Standards Track M. Rose
+ Dover Beach Consulting, Inc.
+ E. Stefferud
+ Network Management Associates, Inc.
+ D. Crocker
+ Brandenburg Consulting
+ November 1995
+
+
+ SMTP Service Extensions
+
+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 a framework for extending the SMTP service by
+ defining a means whereby a server SMTP can inform a client SMTP as to
+ the service extensions it supports. Extensions to the SMTP service
+ are registered with the IANA. This framework does not require
+ modification of existing SMTP clients or servers unless the features
+ of the service extensions are to be requested or provided.
+
+2. Introduction
+
+ The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable,
+ effective basis for the relay function of message transfer agents.
+ Although a decade old, SMTP has proven remarkably resilient.
+ Nevertheless, the need for a number of protocol extensions has become
+ evident. Rather than describing these extensions as separate and
+ haphazard entities, this document enhances SMTP in a straightforward
+ fashion that provides a framework in which all future extensions can
+ be built in a single consistent way.
+
+3. Framework for SMTP Extensions
+
+ For the purpose of service extensions to SMTP, SMTP relays a mail
+ object containing an envelope and a content.
+
+
+
+
+Klensin, et al Standards Track [Page 1]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ (1) The SMTP envelope is straightforward, and is sent as a
+ series of SMTP protocol units: it consists of an
+ originator address (to which error reports should be
+ directed); a delivery mode (e.g., deliver to recipient
+ mailboxes); and, one or more recipient addresses.
+
+ (2) The SMTP content is sent in the SMTP DATA protocol unit
+ and has two parts: the headers and the body. The
+ headers form a collection of field/value pairs
+ structured according to RFC 822 [2], whilst the body,
+ if structured, is defined according to MIME [3]. The
+ content is textual in nature, expressed using the US
+ ASCII repertoire (ANSI X3.4-1986). Although extensions
+ (such as MIME) may relax this restriction for the
+ content body, the content headers are always encoded
+ using the US ASCII repertoire. The algorithm defined in
+ [4] is used to represent header values outside the US
+ ASCII repertoire, whilst still encoding them using the
+ US ASCII repertoire.
+
+ Although SMTP is widely and robustly deployed, some parts of the
+ Internet community might wish to extend the SMTP service. This memo
+ defines a means whereby both an extended SMTP client and server may
+ recognize each other as such and the server can inform the client as
+ to the service extensions that it supports.
+
+ It must be emphasized that any extension to the SMTP service should
+ not be considered lightly. SMTP's strength comes primarily from its
+ simplicity. Experience with many protocols has shown that:
+
+ protocols with few options tend towards ubiquity, whilst
+ protocols with many options tend towards obscurity.
+
+ This means that each and every extension, regardless of its benefits,
+ must be carefully scrutinized with respect to its implementation,
+ deployment, and interoperability costs. In many cases, the cost of
+ extending the SMTP service will likely outweigh the benefit.
+
+ Given this environment, the framework for the extensions described in
+ this memo consists of:
+
+ (1) a new SMTP command (section 4)
+
+ (2) a registry of SMTP service extensions (section 5)
+
+ (3) additional parameters to the SMTP MAIL FROM and RCPT TO
+ commands (section 6).
+
+
+
+
+Klensin, et al Standards Track [Page 2]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+4. The EHLO command
+
+ A client SMTP supporting SMTP service extensions should start an SMTP
+ session by issuing the EHLO command instead of the HELO command. If
+ the SMTP server supports the SMTP service extensions it will give a
+ successful response (see section 4.3), a failure response (see 4.4),
+ or an error response (4.5). If the SMTP server does not support any
+ SMTP service extensions it will generate an error response (see
+ section 4.5).
+
+4.1. Changes to STD 10, RFC 821
+
+ This specification is intended to extend STD 10, RFC 821 without
+ impacting existing services in any way. The minor changes needed are
+ enumerated below.
+
+4.1.1. First command
+
+ RFC 821 states that the first command in an SMTP session must be the
+ HELO command. This requirement is hereby amended to allow a session
+ to start with either EHLO or HELO.
+
+4.1.2. Maximum command line length
+
+ This specification extends the SMTP MAIL FROM and RCPT TO to allow
+ additional parameters and parameter values. It is possible that the
+ MAIL FROM and RCPT TO lines that result will exceed the 512 character
+ limit on command line length imposed by RFC 821. This limit is
+ hereby amended to only apply to command lines without any parameters.
+ Each specification that defines new MAIL FROM or RCPT TO parameters
+ must also specify maximum parameter value lengths for each parameter
+ so that implementors of some set of extensions know how much buffer
+ space must be allocated. The maximum command length that must be
+ supported by an SMTP implementation with extensions is 512 plus the
+ sum of all the maximum parameter lengths for all the extensions
+ supported.
+
+4.2. Command syntax
+
+ The syntax for this command, using the ABNF notation of [2], is:
+
+ ehlo-cmd ::= "EHLO" SP domain CR LF
+
+ If successful, the server SMTP responds with code 250. On failure,
+ the server SMTP responds with code 550. On error, the server SMTP
+ responds with one of codes 500, 501, 502, 504, or 421.
+
+
+
+
+
+Klensin, et al Standards Track [Page 3]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ This command is issued instead of the HELO command, and may be issued
+ at any time that a HELO command would be appropriate. That is, if
+ the EHLO command is issued, and a successful response is returned,
+ then a subsequent HELO or EHLO command will result in the server SMTP
+ replying with code 503. A client SMTP must not cache any information
+ returned if the EHLO command succeeds. That is, a client SMTP must
+ issue the EHLO command at the start of each SMTP session if
+ information about extended facilities is needed.
+
+4.3. Successful response
+
+ If the server SMTP implements and is able to perform the EHLO
+ command, it will return code 250. This indicates that both the
+ server and client SMTP are in the initial state, that is, there is no
+ transaction in progress and all state tables and buffers are cleared.
+
+ Normally, this response will be a multiline reply. Each line of the
+ response contains a keyword and, optionally, one or more parameters.
+ The syntax for a positive response, using the ABNF notation of [2],
+ is:
+
+ ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
+ / ( "250-" domain [ SP greeting ] CR LF
+ *( "250-" ehlo-line CR LF )
+ "250" SP ehlo-line CR LF )
+
+ ; the usual HELO chit-chat
+ greeting ::= 1*<any character other than CR or LF>
+
+ ehlo-line ::= ehlo-keyword *( SP ehlo-param )
+
+ ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on ehlo-keyword
+ ehlo-param ::= 1*<any CHAR excluding SP and all
+ control characters (US ASCII 0-31
+ inclusive)>
+
+ ALPHA ::= <any one of the 52 alphabetic characters
+ (A through Z in upper case, and,
+ a through z in lower case)>
+ DIGIT ::= <any one of the 10 numeric characters
+ (0 through 9)>
+
+ CR ::= <the carriage-return character
+ (ASCII decimal code 13)>
+ LF ::= <the line-feed character
+ (ASCII decimal code 10)>
+
+
+
+Klensin, et al Standards Track [Page 4]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ SP ::= <the space character
+ (ASCII decimal code 32)>
+
+ Although EHLO keywords may be specified in upper, lower, or mixed
+ case, they must always be recognized and processed in a case-
+ insensitive manner. This is simply an extension of practices begun in
+ RFC 821.
+
+ The IANA maintains a registry of SMTP service extensions. Associated
+ with each such extension is a corresponding EHLO keyword value. Each
+ service extension registered with the IANA must be defined in an RFC.
+ Such RFCs must either be on the standards-track or must define an
+ IESG-approved experimental protocol. The definition must include:
+
+ (1) the textual name of the SMTP service extension;
+
+ (2) the EHLO keyword value associated with the extension;
+
+ (3) the syntax and possible values of parameters associated
+ with the EHLO keyword value;
+
+ (4) any additional SMTP verbs associated with the extension
+ (additional verbs will usually be, but are not required
+ to be, the same as the EHLO keyword value);
+
+ (5) any new parameters the extension associates with the
+ MAIL FROM or RCPT TO verbs;
+
+ (6) how support for the extension affects the behavior of a
+ server and client SMTP; and,
+
+ (7) the increment by which the extension is increasing the
+ maximum length of the commands MAIL FROM, RCPT TO, or
+ both, over that specified in RFC 821.
+
+ In addition, any EHLO keyword value that starts with an upper or
+ lower case "X" refers to a local SMTP service extension, which is
+ used through bilateral, rather than standardized, agreement. Keywords
+ beginning with "X" may not be used in a registered service extension.
+
+ Any keyword values presented in the EHLO response that do not begin
+ with "X" must correspond to a standard, standards-track, or IESG-
+ approved experimental SMTP service extension registered with IANA. A
+ conforming server must not offer non "X" prefixed keyword values that
+ are not described in a registered extension.
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 5]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ Additional verbs are bound by the same rules as EHLO keywords;
+ specifically, verbs begining with "X" are local extensions that may
+ not be registered or standardized and verbs not beginning with "X"
+ must always be registered.
+
+4.4. Failure response
+
+ If for some reason the server SMTP is unable to list the service
+ extensions it supports, it will return code 554.
+
+ In the case of a failure response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+4.5. Error responses from extended servers
+
+ If the server SMTP recognizes the EHLO command, but the command
+ argument is unacceptable, it will return code 501.
+
+ If the server SMTP recognizes, but does not implement, the EHLO
+ command, it will return code 502.
+
+ If the server SMTP determines that the SMTP service is no longer
+ available (e.g., due to imminent system shutdown), it will return
+ code 421.
+
+ In the case of any error response, the client SMTP should issue
+ either the HELO or QUIT command.
+
+4.6. Responses from servers without extensions
+
+ A server SMTP that conforms to RFC 821 but does not support the
+ extensions specified here will not recognize the EHLO command and
+ will consequently return code 500, as specified in RFC 821. The
+ server SMTP should stay in the same state after returning this code
+ (see section 4.1.1 of RFC 821). The client SMTP may then issue
+ either a HELO or a QUIT command.
+
+4.7. Responses from improperly implemented servers
+
+ Some SMTP servers are known to disconnect the SMTP transmission
+ channel upon receipt of the EHLO command. The disconnect can occur
+ immediately or after sending a response. Such behavior violates
+ section 4.1.1 of RFC 821, which explicitly states that disconnection
+ should only occur after a QUIT command is issued.
+
+ Nevertheless, in order to achieve maxmimum interoperablity it is
+ suggested that extended SMTP clients using EHLO be coded to check for
+ server connection closure after EHLO is sent, either before or after
+
+
+
+Klensin, et al Standards Track [Page 6]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ returning a reply. If this happens the client must decide if the
+ operation can be successfully completed without using any SMTP
+ extensions. If it can a new connection can be opened and the HELO
+ command can be used.
+
+ Other improperly-implemented servers will not accept a HELO command
+ after EHLO has been sent and rejected. In some cases, this problem
+ can be worked around by sending a RSET after the failure response to
+ EHLO, then sending the HELO. Clients that do this should be aware
+ that many implementations will return a failure code (e.g., 503 Bad
+ sequence of commands) in response to the RSET. This code can be
+ safely ignored.
+
+5. Initial IANA Registry
+
+ The IANA's initial registry of SMTP service extensions consists of
+ these entries:
+
+ Service Ext EHLO Keyword Parameters Verb Added Behavior
+ ------------- ------------ ---------- ---------- ------------------
+ Send SEND none SEND defined in RFC 821
+ Send or Mail SOML none SOML defined in RFC 821
+ Send and Mail SAML none SAML defined in RFC 821
+ Expand EXPN none EXPN defined in RFC 821
+ Help HELP none HELP defined in RFC 821
+ Turn TURN none TURN defined in RFC 821
+
+ which correspond to those SMTP commands which are defined as optional
+ in [5]. (The mandatory SMTP commands, according to [5], are HELO,
+ MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.)
+
+6. MAIL FROM and RCPT TO Parameters
+
+ It is recognized that several of the extensions planned for SMTP will
+ make use of additional parameters associated with the MAIL FROM and
+ RCPT TO command. The syntax for these commands, again using the ABNF
+ notation of [2] as well as underlying definitions from [1], is:
+
+ esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
+ esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
+ esmtp-parameter ::= esmtp-keyword ["=" esmtp-value]
+ esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on esmtp-keyword
+ esmtp-value ::= 1*<any CHAR excluding "=", SP, and all
+ control characters (US ASCII 0-31
+ inclusive)>
+
+
+
+
+Klensin, et al Standards Track [Page 7]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ ; The following commands are extended to
+ ; accept extended parameters.
+ inner-esmtp-cmd ::= ("MAIL FROM:" reverse-path) /
+ ("RCPT TO:" forward-path)
+
+ All esmtp-keyword values must be registered as part of the IANA
+ registration process described above. This definition only provides
+ the framework for future extension; no extended MAIL FROM or RCPT TO
+ parameters are defined by this RFC.
+
+6.1. Error responses
+
+ If the server SMTP does not recognize or cannot implement one or more
+ of the parameters associated with a particular MAIL FROM or RCPT TO
+ command, it will return code 555.
+
+ If for some reason the server is temporarily unable to accomodate one
+ or more of the parameters associated with a MAIL FROM or RCPT TO
+ command, and if the definition of the specific parameter does not
+ mandate the use of another code, it should return code 455.
+
+ Errors specific to particular parameters and their values will be
+ specified in the parameter's defining RFC.
+
+7. Received: Header Field Annotation
+
+ SMTP servers are required to add an appropriate Received: field to
+ the headers of all messages they receive. A "with ESMTP" clause
+ should be added to this field when any SMTP service extensions are
+ used. "ESMTP" is hereby added to the list of standard protocol names
+ registered with IANA.
+
+8. Usage Examples
+
+ (1) An interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250 dbc.mtview.ca.us says hello
+ ...
+
+ indicates that the server SMTP implements only those
+ SMTP commands which are defined as mandatory in [5].
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 8]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ (2) In contrast, an interaction of the form:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 250-dbc.mtview.ca.us says hello
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250-8BITMIME
+ S: 250-XONE
+ S: 250 XVRB
+ ...
+
+ indicates that the server SMTP also implements the SMTP
+ EXPN and HELP commands, one standard service extension
+ (8BITMIME), and two nonstandard and unregistered
+ service extensions (XONE and XVRB).
+
+ (3) Finally, a server that does not support SMTP service
+ extensions would act as follows:
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 dbc.mtview.ca.us SMTP service ready
+ C: EHLO ymir.claremont.edu
+ S: 500 Command not recognized: EHLO
+ ...
+
+ The 500 response indicates that the server SMTP does
+ not implement the extensions specified here. The
+ client would normally send a HELO command and proceed
+ as specified in RFC 821. See section 4.7 for
+ additional discussion.
+
+9. Security Considerations
+
+ This RFC does not discuss security issues and is not believed to
+ raise any security issues not already endemic in electronic mail and
+ present in fully conforming implementations of RFC-821. It does
+ provide an announcement of server mail capabilities via the response
+ to the EHLO verb. However, all information provided by announcement
+ of any of the initial set of service extensions defined by this RFC
+ can be readily deduced by selective probing of the verbs required to
+ transport and deliver mail. The security implications of service
+ extensions described in other RFCs should be dealt with in those
+ RFCs.
+
+
+
+
+Klensin, et al Standards Track [Page 9]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+10. Acknowledgements
+
+ This document represents a synthesis of the ideas of many people and
+ reactions to the ideas and proposals of others. Randall Atkinson,
+ Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
+ and text sufficient to be considered co-authors. Other important
+ suggestions, text, or encouragement came from Harald Alvestrand, Jim
+ Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
+ Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
+ Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan
+ Zachariassen, and the contributions of the entire IETF SMTP Working
+ Group. Of course, none of the individuals are necessarily responsible
+ for the combination of ideas represented here. Indeed, in some cases,
+ the response to a particular criticism was to accept the problem
+ identification but to include an entirely different solution from the
+ one originally proposed.
+
+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] Braden, R., "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, USC/Information Sciences Institute,
+ October 1989.
+
+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
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 10]
+
+RFC 1869 SMTP Service Extensions November 1995
+
+
+ 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
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Moutain View, CA 94043-2186
+ USA
+
+ Phone: +1 415 968 1052
+ Fax: +1 415 968 2510
+ EMail: mrose@dbc.mtview.ca.us
+
+
+ Einar A. Stefferud
+ Network Management Associates, Inc.
+ 17301 Drey Lane
+ Huntington Beach, CA, 92647-5615
+ USA
+
+ Phone: +1 714 842 3711
+ Fax: +1 714 848 2091
+ EMail: stef@nma.com
+
+
+ Dave Crocker
+ Brandenburg Consulting
+ 675 Spruce Dr.
+ Sunnyvale, CA 94086 USA
+ USA
+
+ Phone: +1 408 246 8253
+ Fax: +1 408 249 6205
+ EMail: dcrocker@mordor.stanford.edu
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 11]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/smtp/rfc1869.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